Performance Battle of NoSQL blob storages #2: Apache Kafka

The first article of this series brought scaling factors for blob-based content on Apache Cassandra. It’s well know piece of software, requiring full installation on nodes, management application and so on. You also need to tune various configs to achieve best performance results. I’ve spend nice time playing with yamls on ubuntu 🙂

The configuration is sometimes tricky. I was little bit confused once or twice so I planned to hire Cassandra guru to our team as issues I encountered seems really complicated 🙂

Well, we do not need much functionality in HP Service Virtualization. The core is to replicate messages to achieve reliability. The next steps is to process them. Yes, the last part is to aggregate the results. Sounds exactly like map and reduce ala hadoop. Evaluation of Apache Storm or Apache Samza are different stories, but they allow me to find Apache Kafka.

Kafka is pretty nice software, much more simpler comparing to Cassandra how I’ve described it above. The only operation to use it is to depend on kafka jars in your pom files. That’s it! Maven downloads couple of dependent jar files and your environment is (almost) ready.

As you can see below, Kafka is incredibly fast, much more faster than Cassandra. Last year I read some article. An author labels Redis as most incredible software he had met so far. I agreed. Now there are two candidates for this label 🙂

It was also very beneficial to read their technical documentation for me as for technical engineer. The guys did performance research how to store data on hard drives and they also employed founded approaches in Kafka implementation. Their documentation contains interesting technical papers, like e.g. lmax pdf does with disruptor.


The setup was identical to the described in first article.

Performance Measurement of Kafka Cluster

Batch Size

  • 8 topics
  • two partitions per one topic
Blob size \ Batch Size [TPS] 128 256 512 1024 32768
100 b 392k 432k 433k 495k 396k
20 kb 9k

There is little difference between various batch sizes so you can tune the value according your needs. Note that overall throughput is incredible: raw 400 mbits/s.

Number of Connections

  • batch size is 512

Blob size \ Connections [TPS per connection] 1 2 4 8 16 32
100 b 84k 74k 62k 58k 37k 17k
20 kb 3.2k 2.5k 1.7k

You can see that number of connections significantly increases the throughput of Kafka during writes. Two connections handles 150k but, 8 ones allows 464k messages per all connections.

Number of Partitions

  • 8 connections

Blob size \ Partitions [TPS] 1 2 4 8 16 64
100 b 535k 457k 493k 284k

Two partitions brought little difference in the overall score. There is same approach or pattern like in hyper threading.

Long Running

The goal of this test is to verify the behavior once the cluster is under the continual heavy load for couple of minutes – as the underlying storage goes out of space (150GB). As Kafka is really fast, such space lasts couple of minutes.

Blob size \ [TPS]
100b 490k

The test generates 150GB of data successfully stored by Kafka. The throughput result is almost the same as in short test.


This is crucial verification how is Kafka affected by the replication.

Blob size \ Replicas [TPS] 1 2
100 b 577k 536k

There is difference less than 10% when two nodes are involved in the replication. Great! Both nodes handles 400mbits throughput.

Large Messages

Previous tests use relatively small messages, how does it behave with larger message?

Blob size \ [TPS]
100b 640k
20 kb 6k
500kb 314

The best throughput achieved last – large – message. Even for so large entity, it handles unbelievable 1.2Gbits/s. Note that all of this is a remote communication, we have 10gbps network.

Occupied Space

As the kafka stores byte array, the occupied space for this system depends on the serialization framework. I used famous kryo.

Blob size \ [Occupied space in bytes per message]
100b 183b

Here is the structure of serialized entity.
class Message {

    private UUID messageId;
private UUID virtualServiceId;
private String targetUrlSuffix;
private int responseStatusCode;
private long time;
private byte[] data;


Kafka surprised me a lot. It’s performance is incredible. The installation is just the dependency on a jar file, the configuration is very easy. The API is really simple, It’s up to you what kind and form of the content you prefer.

The only drawback is that this piece of software is pretty young. In the time this article was being written, beta version 0.8 is out. For example, async API is now in a proposal only.

On the other hand, there is large set of various articles, videos and other materials, how one used it in his project, especially along with Apache Storm.

Well,  if you want to use messaging within your new solution you should definitely look at Apache Kafka.

Performance Battle of NoSQL blob storages #1: Cassandra


We spend last five years on HP Service Virtualization using MsSQL database. Non-clustered server. Our app utilizes this system for all kinds of persistence. No polyglot so far. As we tuned the performance of the response time – we started at 700ms/call and we achieved couple milliseconds per call at the end when DB involved – we had to learn a lot of stuff.

Transactions, lock escalation, isolation levels, clustered and non clustered indexes, buffered reading, index structure and it’s persistence, GUID ids in clustered indexes, bulk importing, omit slow joins, sparse indexes, and so on. We also rewrite part of NHibernate to support multiple tables for one entity type which allows use scaling up without lock escalation. It was good time. The end also showed us that famous Oracle has half of our favorite features once we decided to support this database.

Well, as I’m thinking about all issues which we encountered during the development, unpredictive behavior is the feeling I have once I did all this with my DB specialist colleague. When we started to care about the performance more and more we must have understood those features and we usually took out default behavior and plug-in some special one – we could have done that as we understood essentials of the system. This is the way.

As I’ve described those features above, a lot of NoSQL storages allow to use them on your own. You can easily provide inverted index in key-value store even if the database itself does not support such functionality. What you need to do is to write error-less code and maintain indexes by your own code. Look at twitter example for famous key-value store Redis. It is not so simple as three/four tables in MySql with build-in indexing, isn’t it?

There is nothing bad about SQL databases. I still believe that they fit the purpose of 80% of programs as they are best for difficult querying and/or less than massive scaling. But who need real massive scaling? Everyone?

Why we are going to use NoSQL?

Here in this article and the whole series, I’m going to evaluate certain attributes of storages for persistence of binary data of variable length. The goal is to persist network traffic in binary data format.
No relation decomposition, no querying of particular attributes of particular messages. No implicit transactions complying with ACID. No indexes and so on. You can find the reasons in the preface, we just hope that we know what we do 🙂


The first evaluated storage is Cassandra. It’s famous NoSQL database, commercial support provides virtual confidence for fast support and so on.
Cassandra is somewhere in the middle between schemaless and schemaware (SQL like) databases as it supports schema and CQL query language. I was pretty surprised when I have saw features like time series with dynamic columns, build-in lists and sets. Next good stuff is OpsCenter monitoring tool, I always show some screenshots from the application when I want to demonstrate easy-of-use monitor for some distributed app. Pretty nice.


Hardware used within the tests:
  • DB cluster:
    • HP Proliant BL460c gen 8, 32core 2.6 GHZ, 32GB RAM, W12k server
    • HP Proliant BL460c gen 8, 32core 2.6 GHZ, 192GB RAM, ubuntu 12 server
  • Tests executor:
    • xeon, 16 cores, 32gb ram, w8k server
  • 10Gbps network
  • Java 7

Performance Measurement of Cassandra Cluster

The setup used one seed and one replica, java tests use datastax driver. Replication factor two when not explicitly defined. After some issues:


… my final CQL create script was:

  1. CREATE COLUMNFAMILY recording (


  3. ID uuid,

  4. VS_ID uuid,

  5. URL ascii,




  9. );

Batch Size

Datastax driver allows to use queries in batches, how does it scale?

Blob size \ Batch Size [TPS] 128 256 512 1024 8196 32768
100 bytes (8 clients) 67 100 63 900 55 400 55 800 23 500 Timeouted
1 kb (4 clients) 15 600 20 600 20 300 19 400 5 500 N/A
5 kb (1 client) N/A 8 300 9 200 10 000 3 000

256 rows seems like best size of the batch.

Number of Connections

The tests utilizes variable count of connections to the Cassandra cluster. Note that the batch size was 256 and consistency was set to ONE.

Blob size \ Connections [TPS] 1 2 4 8 24
100 b 27 000 53 000 75 000 62 000 62 000
1 kb 17 900 31 000 42 000 40 000
5 kb 9 000 14 600 16 000 10 300
20 kb 3 300 4 500 3 800

You can see that 2 or 4 connections per one client are enough whilst one connection slows down the overall performance.

Number of Partitions

The table contains partition key, see the CQL code snippet. The test generates variable values for the partition key. Batch size was also 256 and consistency one.

Blob size \ Partitions [TPS] 1 8 64
100 b 58 000 71 000 70 000
10 kb 13 200 9100 7 300
Partition key says where the data will reside, it defines target machine. As two nodes are involved in my tests, its better to use more than one partition.

Variable Consistency

Tuning of consistency is the most beautiful attribute in Cassandra. You can define consistency level in every aspect of the communication with cassandra driver in any language. There are different levels, see the documentation.

The test used 8 partitions, 8 connections and 256 batch size.

Blob size \ Consisency [TPS] Any One Two
100 b 67 000 66 000 66 000

Well, I’m surprised. There is almost no difference between consistency levels for such blob size despite totally different purpose or implementation. This could happen due to almost ideal environment, very fast network and machines as well.

Variable Replicas

I used two replicas by default but this tests tries to reveal the price for second copy of the data.

Blob size \ Replicas [TPS] 1 2
100 b 121 000 72 000
10 kb 19 200 8 200

There is apparent penalty for second replica.

Long Running

Previous tests used a few millions of inserts/rows but the current one uses hundred of millions. This is the way how to definitely omit the advantage of various caches and clever algorithms. This simulates heavy weight load test to the server.

8 partitions, 8 connections, 256 batch size.

Blob size \ Replicas+Consistency [TPS] 1+ONE 2+ONE 2+TWO
100 b (1 billion) 121 000 63 000 62 00
10 kb (30 m) 8 200

Large Messages

The largest message in these tests has 20 kb so far, but what is the behavior when our app would meet some large file as a attachment?
Consistency One, 2 partitions, 2 connections, 2 batch size.

Blob size  [TPS]
500 kb 90
5 mb 9.5

Occupied Space

Apache Cassandra automatically enables compression since 1.1 version.

Blob size \ [Occupied space in bytes per message]
100b 89b

Here is the structure of serialized entity.

    ID uuid,
    VS_ID uuid,
    URL ascii,
    MESSAGE_TIME bigint,
    DATA blob,


This kind of testing is almost opposite in comparison to neflix tests. They analyzed scalability but we have done testing of simple cluster having two machines only. We need to figure out the performance of one node (obviously in cluster deployment).
I was impressed as the numbers above are good, the overall throughput on the network reached hundred mbps coming out from one client. 
What next. Same kinds of tests agains Kafka, Redis, Couchbase, Aerospike, Couchbase.

Kryonet: simple but super-fast TCP communication in Java + performance benchmarks

We have designed cluster-aware and cloud-based solution of service virtualization for some time. Incredible work as distributed system is next dimension of thinking – and learning as well 🙂

We was deciding to split atomic piece of our domain work to multiple nodes. Such step would hopefully provide us to point certain messages to certain nodes. We can than store data in main memory and avoid distributed locking above some remote store, probably Redis. This is usual approach how to achieve better response time of the whole solution to avoid database search for all calls. Obviously with well designed replication.

I was really worried about latency. We need really low response time in couple of milliseconds at most under heavy load. I’m talking about the whole solution which consumes CPU a lot because of the calculations of simulated response under the hood, so no space for any wasting.

What is the best latency of such transmission between two nodes? What is the throughput of one or multiple connections? Except theoretical analysis I also did our own proof of concept to verify our thoughts in the reality.

I like kryo serialization framework. It’s very fast, very simple and the boot of anybody is in level of minutes. Hopefully I discovered that guys from Esoteric Software think about remote communication and they did very logic step. They developed framework allowing TCP communication using kryo serialization – kryonet.

Well, I believe that nobody is surprised that the solution is very fast and super easy as well. Like kryo itself.

There are some benchmarks how TCP communication can be fast, in level o microseconds, but what is the real response time, performance, when I need to transfer some domain object to another node in real environment using gigabit network. I mean no laboratory environment but just real one where our app will probably run in couple of months?

Well, in short it’s hundred of microseconds.

Kryonet via Kryo

It is built above java nio, kryo serialization and asynchronous approach when the response is being received.
It’s better to read the manual on github as coding around the sending and the receiving is very easy.

Kryo preserves the way that the serializators are separated classes, later registered to the system, so you do no have to affect your domain classes. But obviously, you have to open them to support injections of fields from outside. Or you can use the reflection too.

The response is received asynchronously to the processing of the original request. Kryonet exposes TCP port on the server side and uses TCP under the hood. But don’t worry, you almost can’t touch complexity of TCP messaging.

Number meaning and setup

What was my message? It contains identifier, uuid, and map of elements. The element contains the data but the important thing is the overall size of the message.

Response time is the whole round-trip:

  1. Serialization on the client side
  2. To send the request to the server
  3. Deserialization of the message on server side
  4. To respond the message identifier back to the client
  5. The deserialization of received message on the client size

Well, the response time is just the number you can expect when you want to push some message to remote component and wait for the acknowledgment – ACK.

Both client and server are HP Proliant, 24 and 32 cores, >1 gigabit network.

Performance Benchmarks

One TCP Connection

First of all, I used one TCP connection.

Message Size [bytes]/Number of elements Average RT [micro-seconds] Median RT [micro-seconds] Buffer size Throughput [msgs/s] Rough Load [msgs/s]
48 / 2 190 160 256 B 5400 100k
48 / 2 202 170 16 kB 5400 100k
48 / 2 672 157 1kB 18300 1M
48 / 2 418 130 16kB 19300 4M
3216 / 200 316 313 16 kB 650 1k
3216 / 200 332 331 256 B 1k

Message size: size of serialized message into raw byte[].

Average vs. median: as my test keeps all response time value, it was very interesting to analyze them. Average value reflects all edge cases, mostly the divergence during the flushing of buffers etc., but median value does not. What does it mean in real? The difference between average and median value indicates growing number of slower responses.

Buffer: kryo uses serialization and object buffer, see the documentation.

Rough load: all calls are asynchronous which means that I had to limit incoming load generated by my generator. The approach I chose was to call standard java thread sleep after certain messages. The operation in milliseconds is not quite accurate but it was fine for rough limitation of input load. 4M means that the generator thread sleeps for 1 milliseconds once it generates four thousand of messages.

The discussion:

  • there is only two times slower response time for 100 times larger message
  • there is almost no different response time for various buffer sizes
  • increasing load means almost the same median value but highly increased average response time. Well, the response time is not stable at all which indicates that you can’t rely on response time in the case of massive load

Multiple Client Connections to One TCP Server Port

The approach having multiple clients using one TCP port usually scales well, but not for kryonet as it uses limited buffer size, see following table. I used 10 concurrent clients for the measure.

Message Size [bytes]/Number of elements Average RT [micro-seconds] Median RT [micro-seconds] Buffer size (client/server) Throughput [msgs/s] Rough Load [msgs/s]
48 / 2 256 254 16k/16k 9000 1k
48 / 2 580 535 16k/160k 42000 5k
48 / 2 33000 23000 16k/300k 80000 10k

The discussion:

  • kryo itself is very fast but single threaded deserialization brings certains limits so huge throughput was achieved for the cost of really high latency
  • the increasing of the buffer size within the server allows to serve much more requests as they just fall into buffer and were not rejected as before for lower buffer size

Multiple Connections to Multiple Ports

The last includes multiple clients connected to the multiple server ports. It brought the best performance as expected.

Message Size [bytes]/Number of elements Connections Average RT [micro-seconds] Median RT [micro-seconds] Buffer size (client/server) Throughput [msgs/s] Rough Load [msgs/s]
48 / 2 10 542 486 256/256 54000 100k
48 / 2 10 5000 518 16k/16k 155000 500k
48 / 2 20 2008 1423 16k/32k 210000 500k
48 / 2 50 1460 404 16k/32k 182000 100k
48 / 2 50 2024 378 256k/256k 220000 100m
48 / 2 100 3120 404 256k/256k 231000 100m
3216 / 200 10 405 368 8k/32k 21000 3k
3216 / 200 10 415 353 16k/32k 21000 3k
3216 / 200 20 399 350 16k/32k 32300 2k
3216 / 200 50 380 327 16k/32k 43700 1k
3216 / 200 50 410 344 64k/128k 78000 2k

The discussion:

  • incredible load for 100/50 clients per second in no bad time as I would originally expected
  • as I’ve already discuss the stuff above, there is huge different between median and average RT as well
  • there is no such difference between 20 and 100 clients in throughtput but in average/median RT


Well, usually the transport of a message from one to another node is not your business case. It’s important that both client and server is able to do it’s core logic – message processing of received throughput is always the core.
One client does not almost burden the server, see htop screenshot for the most approach having the best throughput:
On the other hand, 10 concurrent clients to one server side port is almost the same even if the number of transported messages is 5x time higher:
As you can see, 50 concurrent clients and ports is more likely theoretical stuff for this measure than usable solution as the server do not any other thing then deserialize incoming throughtput 🙂


It’s fast and easy. Almost 20k transmitted small messages for one client per second is incredible number for me. On the other hand, 150-200 micro seconds response time is surprise for me as well.
The only thing to consider is to carefully define the size of all buffers. There is no queuing and just the rejection of a message can happen if the connection is under heavy load.

Jasně cílených 25 + 5 minut v pomodoro

Když bude chtít netrénovaný jedinec uběhnout pět kilometrů, velmi pravděpodobně zažije lepší požitek ze sportu, když si místo celého běhu najednou rozkrájí trať na 10 pětisemetrových částí a mezi nimi udělá určitý odpočinek.

Proč? Doběhnout k další lampě na cyklostezce je pro psychiku – a také fyzičku – méně náročný úkol než doběhnout do další vesnice a pak zpět. Psychiku se stejně jako fyzičku můžete vyčerpat.

Takhle nějak funguje pomodoro v práci.

O co jde?

Pomodoro je celkem starý a jednoduchý postup, který velmi napomáhá mojí efektivitě. Je to vlastně jediná věc, kterou jsem zkusil a používal i po pár dnech dál. Respektive pomodoro pomáhá mému soustředění a schopnosti řešit smysluplně problémy.

Pomodoro říká, že byste měli dvacetpět minut pracovat a pět minut dělat něco jiného – odpočinout si od té hlavní činnosti – a takto dokola. Po třech opakováních si dát větší patnáctiminutovou pauzu. Takhle lze rozkrájet celý den.

Jak to funguje?

Přijdete do práce, pustíte čas a pracujete dvacetpět minut. Tento časový úsek je dedikován vaší přímé práci, žádné rozptylování, žádné odbíhání, čistý focus na prácí. Po pětadvaceti minutách je čas pět minut na pauzu. Její výplň záleží na každém z nás. Důležité je, aby tento úsek trávil člověk něčím jiným než tou konkrétní prací.

Časy lze při troše dobré vůle poměnit. Přece jen, když mám nosou myšlenku a bije mi 24:59, neodejdu, abych ji zapomněl 🙂 Na druhou stranu vypustit ale pauzu je nežádoucí, protože v ní je kouzlo pomodora.

Proč mi to funguje?

Určitě každý znáte moment, kdy se rozjedete v práci, hloubáte a hloubáte nad nevyřešitelným problémem a najednou je konec dne a jdete domů. Práce vás pohltila, ale ten problém jste nerozlouskli. Pravděpodobně se vám to povede druhý den ráno. Krom psychické únavy to má ještě jeden faktor. Přes stromy nevidíme les.

Když člověk kontinuálně přemýšlí, prochází slepé cestičky problému, mozek je v určitém kontextu. Jeho granularita je na úrovni těch dílčích řešených problémů – nikoli celku. Během pauzy z toho kontextu logicky vypadne. Když uplyně pět minut a člověk začne hloubat znovu, musí si kontext obnovit. To se mu povede tím, že začne nad problémem znovu přemýšlet, sestupovat hlouběji a hlouběji. A tohle je právě ono.

Jakmile znovu sestupujete do toho kontextu, procházíte věci znova a dost často vás napadne něco jiného, jiné řešení, jiné problémy nebo postupy. To mi většinou vede k rozuzlení celé úlohy.

Efektivita přemýšlení

Podstatnou věcí je efektivita sama o sobě. Mozek má jisté limity. Nedokáže se plně soustředit a přemýšlet hodiny po sobě, tak jako fyzická práce potřebuje odpočinek, tak i psychická. Všechno je to logicky vysvětlené v Pragmatic Thinking and Learning.

Plánovat dvou, tří nebo dokonce čtyřhodinový meeting je mrháním času. Nejenže nevznikne žádný tlak na řešení daných problémů jednoduše proto, že tolik času svádí k řešení všeho okolo, taktéž každý na daném meetingu se bude efektivně soustředit maximálně minut čtyřicet.

A pomodoro řeší kousknováním i tohle.

Jak to používám?

25 minut práce

Na barcampu někdo říkal, že jeho den začíná kafem vedle notebooku. Můj den začíná tím, že kliknu na rajské jablko v chromu a začne mi odpočítávat čas. Jelikož mám vidinu dvacetipěti minut práce před sebou a ne osmi, deseti či dvanácti hodin, nenechám se snadno rozptýlit.

Nejdu číst weby, sociální sítě, nejdu vařit čaj, nejdu jíst ani nejdu přemýšlet na víkendem. Jednak mám v hlavě focus na těch krátkých dvacet pět minut, které chci strávit efektivně, druhak se mi odpočítávaný čas krátí.

Proč používám chromový doplněk? Má to jednu super výhodu. Blokování stránek. Když už mám slabší chvilku a chtěl bych se podívat na facebook, pomodoro doplněk mi to neumožní 🙂 Prostě stránku nezobrazí, resp. zobrazí přes ní logo rajčete. Tohle funguje ikdyž jste měli tu stránku otevřenou předem, prostě se překryje šedým podkladem a logem. Má to nedozírné nasledky 🙂 Například vám to neumožní pokračovat v rozjetém dialogu na sociální síti. Máte na dvacetpět minut smůlu 🙂

5 minut pauza

Tohle je asi nejlepší část. Přišlo mi škoda koukat z okna a relaxovat. Proto těchto pět minut trávím prací, ke které bych se normálně nedostal. Má jiný kontext, takže mi to funguje!

Moje typická normální praxe je taková, že člověk začne pracovat na nové věci a za tři měsíce zjistí, že neodpovídal celou dobu na emaily, které se netýkaly té nove featury. Těch pět pauzovních minut mi tak slouži na dělání dílčích úkolů. Odpovědět na dotaz kolegovi, naplánovat schůzku, zavolat klempířům na parapety nebo si vložit do getpocket články.

Pokud totiž pracujete 8 hodin denně, máte takových pauz celkem 16. Za to lze už stihnout hodně dalších věcí. Vzhledem ke zefektivnění práce byste tenhle čas stejně pravděpodobně nevyužili moc dobře.

Pokud nejsem v dohledu chromu, používám clockwork tomato pro android. Úplně se nabízí integrace s nějakou toolou na management tásků, třeba kanbanflow tohle pěkně umí.


Dost mi to pomáhá, řeší mi to totiž hodně problémů:

  1. Efektivita, rozptylování, odcházení od problému
  2. Dokážu zase vidět les přes stromy, nezapadnu nesmyslně do problému na celé hodiny
  3. Dokážu dělat věci, ke kterým bych se nedostal a stále je odsouval na budoucno
  4. Jelikož ten čas dělím na kratší úseky, nemám pocit, že budu zase celý den v práci
Pomodoro má jen jedno pravidlo 25+5, tolikrát vzpomínané v tomhle článku. Tedy žádný overmanagement – to je také velká výhoda.

Musí vás to bavit!

K tomuhle blogpostu mě motivovala přednáška a následná diskuze o deseti vychytávkách na plzeňském barcampu. Pár věcí jak to dělám já nikdo nezmínil, tak je zkusím probrat tady.

Celkem úsměvný moment jsem zažil hned první týden po barcampu, kdy jsem si uvědomil, že každému funguje něco jiného. Pár pracovních dní jsem zkoušet toggl.

Během nich mi ale došlo, že od roku 1984 už něco málo uběhlo a nebudu sám sebe sledovat, ať si to dělá ČSU, NSA, ETC, teda etc. 🙂 Ještě bych něco zjistil. Teď vážně: pro mě to nedává smysl, otravuje mě to a zapomínám na to. Jelikož se k tomu nevracím, nevidím v tom hodnotu. Uninstall. Takhle skončila moje bitva s toolou, která byla široce zmiňovaná.

Co mi tedy v diskuzi o efektivitě chybělo? No prostě …

Musí vás to bavit!

Tohle si ne každý uvědomuje. Spoustu lidí honí efektivitu Evernotem, kalendářem, togglem, kanban toolou, blockem stránek v pomodoru nebo trello. Jenže nejvíc do toho dá člověk, kterého ten úkol baví.

Ale jak udělat, aby Vás všechno bavilo? Všechno? To nejde, ale jde tomu pomoct.

Kdysi jsem chodil k Lukáši Konečnému na box. Byla to makačka! Jednou jsme jeli kruháč a najednou slyším jak řvě na kluka vedle mě: “ty debile! Jak to děláš? Vždyť to děláš pro sebe ty vole!”. Tahle věta mi utkvěla v hlavě. Kluk byl výrazně lepší než já, ale flákal to.

Na box jsme chodili rádi a dobrovolně, a jen na nás bylo, jestli jsme si něco odnesli nebo ne. Nemuseli jsme, stačilo to odchodit, což by asi stálo Lukáše hlasivky, ale nic víc. S prací je to stejné, zaleží na každém, co si z toho dne odnese.

Co z toho plyne? Jak moc zajímavou si práci uděláte, tak vás bude bavit.

Tak třeba: kdysi jsme měli generální problém s testy. Dlouhá exekuce, kvůli natažení celé infrastruktury pro jednoduché testy, spousta abstraktních předků, spousta nepěkně vonícího kódu. Po malé změně aplikačníhé kódu se musela měnit podstatná část testů. prostě manintance vázla. Testování není moc populární část developerské práce a tak to vyžadovalo přemoct svého slona. Jak to dopadlo? Kopli jsme do toho, přečetl jsem si dvě knížky, trošku jsme mákli, opravili jsme to a teď mám i po dlouhé době v hlavě vrytou velkou znalost a zkušenost testování. A ten pocit vítězství taky k nezaplacení 🙂

Při vývoji jakékoliv komponenty tuhle zkušenost opráším, nikdy už neopakuju tu původní chybu. Proč? Sice to nebyla práce po které by Vás šéf poplácal uznale po zádech a objevili jste se na předních stránkách dzone. Ale stačilo to pojmout tak, že se naučíme testování a později to mnohokrát reusneme, prostě během té práce uděláme něco pro sebe.

V rámci každého úkolu můžete udělat něco pro sebe, naučit se něco nového, co se vám hodí, co potom použijete i jinde. Stačí dobře volit.

Američané stále cosi povídají o tom, že všechno je výzva. Ráno se sprchovat studenou vodou, učit se francouzsky nebo do práce rovnou běhat desítku crossem přes park. Výrazně víc mě baví práce, kde si najdu něco zajímavého, co mě někam posune. Tohle mi funguje jako největší hybná síla, jak se posunout dál.

Poslední věc která se k tomu váže. V každé firmě něco nefunguje, ideální firma je mýtus. Jen to někde jde líp a někde hůř. Jeden kolega kdysi vyřkl pěknou myšlenku: “dobrým se nestanete, tím, že se přidáte k dobré firmě. Dobrým se stanete, když něco dobrého uděláte”. Někdy je nejlepším krokem pokořit věci, které nás nejvíc rozčilují, ikdyž to není vaše zodpovědnost nebo starost. Tím se naučíte úplně nejvíc.

Koukám, že se původní myšlenka rozlezla na celý článek, takže až příště něco o tom, proč dělám věci ráno a jak používám těch pět minut v pomodoru.

Plzeňský Barcamp 2014

S komunitou se to lépe táhne a po parádním data hackatonu se v kalendáři v sobotu 12.4. objevila další akce. Protože jsme s double-ex-kolegou Petrem Juzou oba studovali v Plzni na FAV, vyrazil jsem do města piva – jednotné číslo, protože Petr už tam bydlí 🙂

V sobotu se v Plzni konal plzeňský Barcamp ve Vědeckotechnickém parku.

Co to je?

Program vybraných přednášek už na první pohled ukazoval, že se nejedná o vývojářskou ani technickou akci. Čas byl vyplněn spíše soft-skills nebo networkingem. S tím jsem tam jel. Nakonec jsme ale zašli i na dvě technické sessions.

Zpětně jsme udělali stejnou chybu jako na data hackatonu a to, že jsme se nepřipravili. Kolik akcí bude ještě trvat, než se poučíme z krizového vývoje? 🙂 Přednášky jsme vybírali až na místě, ať už z telefonu nebo z mnoha velmi pečlivě vylepených programů. Takhle z místa generála po bitvě šlo určitě vybrat lépe průřez barcampem a ochutnat od každého něco – víc.


Po uvítací půlhodince, jež zaplnila twitter fotkama zumby, jsme si vybrali něco z našeho soudku – přednášku Honzy Švece o machine learningu. Honza ze ZČU poodkryl inteligentní hlasovou asistentku, nastřelil něco málo technických atributů “učení se” a velmi pěkně pro lajky ukázal, jak na práci s hlasem. Presentace sama byla paradní. Slidy projížděly nad jakousi mind-mapou na obrovském plátně. To chci taky!

Jan Švec – Machine learning

Jelikož jsem měl šanci pobýt před pár týdny v Malajsii, o čemž sepíšu něco málo později, rozhodně nás zajímali digitální nomádi. Vítek Ježek žije dost netradičním životem a ten shrnul do přednášky. Nejdřív pár slov a fotek ze zřejmě dost povedených recesistických akcí via Děsír, potom povídání o fungování demokratických clevis s.r.o. spolu s digitálním nomádstvím. O co šlo? Odjet někam za teplem na pár týdnů a odtud pracovat. Původně jsem čekal spíš něco ve stylu jak jsem pracoval pro softwarovou firmu v emirátech ale i tohle bylo velmi zajímavé.

Vítek Ježek – Digitální nomádi

Po přesunu do hlavní místnosti začala přednáška energické Marie Gráfové o deseti vychytávkách efektivného života. Opět mě dost zaujaly slidy. Povídání o tom jak se samo-organizovat, zefektivnit a zacílit. V delší verzi najdete všechno s omáčkou v Konci prokrastinace. Ze zmiňovaných apps jsem si dneska zkusil znovu toggl – ale zase jsem to zapomněl vypnout :-), zajímavý bude určitě i Boomerang do Gmailu. Nápad již zažitý v iOS’ Mailboxu. Diskuze k tématu byla dlouhá. Někoho ze životní letargie zvedl pes, někoho bezlepková strava, jiného zase sport. Nicméně já to dělám docela jinak, tak o tom něco málo napíšu.


Na obědě se ukázalo, že dorazilo pár ostravaků – chybějící diakritika tam opravdu má chybět 🙂 Chatting nad tématy vedení projektů nám přelezl do první várky odpoledních přednášek, takže jsme stihli až Davida Šmehlíka s prací z kavárny. Rozebíral, jak pracovat remotně.

Předposlední přednáška se konala v trošku odlehlé posluchárně a tak bylo celkem prázdno. Slibná upoutávka o crowdfundingu se trošku vymkla kontrole. Kluci z málo mluvili obecně o tématu a hodně rozebírali svůj skoro nerozjetý web. Škoda, protože znalostí měli zřejmě hodně, ale UX verifikace webu na barcamp IMO moc nepatřila.

Závěrečná session byla ale perfektní, ta to vynahradila. Štěpán Bechyňský mluvil a ukazoval 3D tiskárny. Svoji vlastní si vzal s sebou na barcamp, takže během povídání tlačil dvě kočičky z plastového vlákna. Tohle jsem viděl poprvé naživo, takže informace maximálně relevantní 🙂 Po téhle presentaci bude určitě nejeden z účastníků hodně přemýšlet, jak si těch 25 tisíc obhájit před manželkou 🙂

Nakonec přišla rozlučovací hodinka a párty dole v hale.

Štěpán Bechyňský – 3D tiskárny

Jaké to bylo?

Příjemný den na příjemných přednáškách. Technické session na střídačku se skillama by byly lepší. Ale i tak jsem rozhodně nelitoval.

Schopnost přednášet

Co mě tedy nejvíc upoutalo nebyl David Grundl, jak asi všechny ostatní :-), ale přednášecí skill lídí, co sebrali odvahu vystoupit před publikem. Gratulace! To bylo sakra dobré. Hezké a příjemné presentace – příjemná změna po těch našich korporátních – klidné vystupování, vtipné reakce na dotazy a žádná nervozita. Dobře se na to koukalo. Dost mě tohle motivovalo příště si to zkusit taky, abych trošku zkazil průměr. Nejden posluchač měl totiž určitě dojem, že takovéhle pěkné presentování jde samo. Mě teda ne 🙂

Organizace barcampu

Jestli mě něco uchvátilo tak tohle. Klobou dolů. Přestože bylo vše zdarma, tak jsme za celý den nepřekonali to množství jídla, které organizátoři připravili. Všechno pěkně klapalo, nikde nic nevypadávalo, všechno bylo perfektně zařízené. Ještě jednou klobouk dolů. Speciálně před Jirkou Kolaříkem, Denisou a Verčou.

Vědecko-technický park

Tohle taky stálo za to. Jelikož moje první práce sídlila kousínek vedle, tak jsem prostředí znal. Za těch pár let tam ale vyrostl pěkný park budov, posluchárny pro dvě stovky lidí, výborné zázemí. A to na rozdíl od Prahy, všechno pěkně v zeleni a v lese. Věřím, že se tam hezky pracuje.

Suma sumárum to bylo velmi dobré! Plzeň je příjemná a barcamp byl taky!

Data Hackaton – motivační víkend

Poslední únorový víkend patříl díky Petru Ocáskovi v Node5 eventu jménem Data Hackaton. Akce to byla početná, celkem se přihlásilo přes 70 lidí. Každý s trošku jiným očekáváním. Jelikož jsme se něčeho podobného účastnili poprvé, vyrazili jsme spíše poznat komunitu lidí, networking, než si zahackovat a udělat nějaký reálný výsledek v podobě zanalyzovaných dat. Ve finále jsme se o to do poslední chvíle snažili, bohužel, řečeno sportovní hantýrkou, jsme zaplatili nováčkovskou daň a padli 🙂

Ale od začátku.


Ten patřil úvodu akce, pár přednáškám. Po nezbytném přivítání od Petra, následovalo pár mini-přednášek. Jelikož tématem hackatonu byla data, jednalo se převážně o představení problémů, které chceme na eventu řešit, popř. co vlastně nabízíme a nebo které problémy vám vyřešíme/pomůžeme řešit.

Zdroje dat byly ruzné. Akcie a tweety, hluk na D1čce, vývoj kriminality popř. data o firmách. Všecho znělo docela lákavě. Tady jsme udělali první chybu 🙂 Přestože networking, chtěli jsme vlastní téma. Náležitě jsme rozhodili sítě a sešlo se nám pár kandidátů, které bychom za víkend mohli zanalyzovat. Výběr pokračoval do soboty.

Během pátečního večera jsme potkali především kluky z keboole. Petr Šimeček nám dal úvodní intro jak do keboole, tak gooddata tak nakonec i do HP Vertica. Za posledně jmenovanou věc nám bylo trošku stydno, protože jako zaměstnanci HP jsme Verticu neměli nikdy v ruce. Nakonec se ukázalo, že po dlouhé instalaci by nás asi čekalo zklamaní. Slovy klasika: prostě někdo musel ukázat, že vyfukováním cigaretového kouře do vody zlato nevznikne.

Po přečtení Petrova blogpostu si vlastně vzpomínám ještě na pár zajímavých věcí prvního dne. Jednak o excelovském power query jsem neměl ani páru. Po prvotním failu Stěpán Bechynský ukázal sílu excelu a já se nestačil divit. “Big data” excel asi nedá, ale na něco menšího by to nemuselo být vůbec špatné.

Kluci z ukázali trošku promo svojí firmě. Zaujalo mě jejich dost profesionální vystupování před kamerou (i ta tam byla), na jejich věk tleskám 🙂

Jelo se v pátek i ve 22:30.


Plni velmi pozitivních zkušeností z prvního dne jsme ráno natěšeně dorazili na devátou do node5. Petr nám představil Radovana, který nás ubezpečil, že obě vyprofilovaná témata jsou dobrý nápad. Bohužel zpětně se ukázalo, že to nebyla pravda, ale po bitvě …

Pro jistotu jsme udělali rychlý research, jak de-mixing bitcoin servisy, která měla neutralizovat spletení proudu bitcoinů, tak i analýzy jsonu, který produkuje Na obědě jsme udělali druhou a asi nejvíc podstatnou chybu – nad pizzou jsme si plácli na to, že rozemeleme bitcoiny.

Po návratu z oběda jsme to commitnuli na standup meetingu. Během odpoledne začalo studium a naše nervozita exponencielně rostla. Zhruba v šest večer jsme měli mavenem staženou bitcoinj knihovnu připojenou do lokální peněženky, ze které to četlo bloky dat.

Během odpoledne nás Petr ještě provedl Node5. Nádhera. Velmi inspirativní prostředí, pěkný prorůstový koncept. Speciálně sekci startupistů, kde se několik měsíců žere rýže a kečup by mělo navštívit hodně lidí.

Tou dobou kluci odvedle, kterým Petr a jeho kolegové z keboole pomáhal dostat data do gooddaty – tady bych udělal menší vsuvku, protože mi přijde divné to tohle skloňovat, na hackaton zaznělo třeba i v gooddatě, já bych to prostě neskloňoval – skončili a šli hotovy domů.

My jsme měli pár řádků kódu, nic moc networking, protože s tím nám nědokázal nikdo pomoct a plnou hlavu toho, jak ten doménový model asi funguje. Kluci z keboola nás ještě obešli, zda něco máme a nechtěli bychom to dostat do gooddata platformy, popř. Verticy. V koutku duše jsme si ještě mysleli, že možná něco v neděli dáme.

Nicméně v osm jsme to vzdali. Kluci z click2streamu dřeli na gooddata via keboole ještě při našem odchodu.


Celou noc jsem nemohl spát. Snažím se být co nejvíc produktivní a nedokázal jsem si představit, že nemáme vlastně vůbec nic – protože sen o tom, že se naučíme strukturu bitcoinů, knihovnu a datový model plus ještě na papír vymyslíme demixer a to vše během jednoho a půl dne byla naprosto bláhová 🙂

V záchvěvu ranní inspirace jsme ještě něco zkusili. Nevyšlo to. Tak jsme si řekli, že je čas uznat porážku a hecnout se něco udělat neboť až ve 14:30 je deadline.

Štefan s toptopicem a bagetou ze včerejšího dne a já se starou houskou z Lídlu v ruce jsme započali straighforward plán, jak skončit se ctí. V jedenáct jsme se rozhodli, že dodáme analyzer flighradaru, ze kterého si vybereme nějakou stats a tu spočítáme v čase.

Java, maven, Redis = to byl náš plán. Redis má tak jednoduché a geniální API, že volit cokoliv jiného byl nesmysl. Jedna servisa parsovala kontinuálně json a plnila data do Redisu, ta druhá kontinuálně přepočítávala průměrnou letovou hladinu. Já programoval, Štefan dělal ops, protože Redis jede na linuxu a v Node5 VPN zase nejede k nám do firmy. Nakonec se tam dostal.

Začali jsme plnit data a pár minut před deadlinou jsme měli spočtenou první průměrnou letovou hladinu. Bohužel na graf se už nedostalo, stejně tak jako na nějakou více smysluplnou analýzu dat. Jedna či dvě hodiny navíc a něco presentovatelného by z toho vypadlo.

Tak jsme si poslechli ostatní. Výsledky byly opravdu povznášející, protože ostatní týmy do toho opravdu šláply a ukázaly, jak se chopit dvoudenní akce. V hlasování všech aktérů zvítězil bluetooth monitoring lidí via, druhý agilní Adam Kurzok s analýzou firem via v závěsu za futurelytics s analýzou kriminality.

Zajímé byly i výsledky analýzy akcií a tweetu, především Štěpán měl velmi pěknou presentaci i pro nezasvěcené.

Na závěr dorazil i Zdeněk Farana a tak jsme se mohli pobavit s někým, kdo dělá realně ve scale.


  • Petr Ocásek uspořádal parádní event, díky!
  • Gazdinka parádně navařila a nemohli jsme neochutnat, díky!
  • Kluci z keboole nám dali čichnout jak funguje jejich BI via goodata a tak všechno okolo, díky!
  • Všichni ostatní vytvořili velmi inspirativní atmosféru, díky!
  • Node5 sám za sebe, protože myšlenka i provedení je úctyhodné, díky!


  • přijít nepřipravení byl kámen úrazu – měli jsme přijít s tématem a využít nabízených platforem, gooddata či google big query, a něco do toho nalít a prostě si to vyzkoušet + někoho k tomu strhnout
  • ikdyž jsme něpřišli s tématem, měli jsme alespoň vsadit na networking a seznámit se s lidmi – dát s nimi něco dohromady
  • potkat se s namotivovanými lidmi je nová krev do žil
  • Node5 je dechberoucí místo, tiše doufáme, že tam někdy uspořádáme podobný event v budoucnu okolo Service Virtualizací
  • když má člověk nosnou myšlenku, lze za víkend udělat dost práce
  • sušený ibišek je neskutečně dobrý
  • po nakládaných hermelínech se těžko běhá 🙂