For the second time and with great pleasure, Streamdata.io was at Devoxx France with a booth and also several talks.
Here is a compilation of what the team has attended and liked.
Devoxx Day 1 – Universities
Vert.x – passez de 0 à (micro-) héros by Clement Escoffier and Julien Viet
Vert.x – From Zero to (micro-) hero
Vert.x is a polyglot library (Java, Groovy, JavaScript, Ceylon, Ruby, etc.) to develop reactive applications. Based on the event loop pattern, Vert.x is designed to develop non-blocking code and fits well when it comes to develop « micro-services » (if you like buzzwords). This Hands-on Labs demonstrated how to develop a « micro-servi ces » application of trading. Each part of the application was deployed on a docker container to guarantee the isolation of the services.
The first part of the session was a short but complete introduction to Vert.x by Clement and Julien. They talked about event loop or reactor pattern. Vert.x is based on an event loop where the code is executed. The golden rule is « Never block the event loop ». To respect this rule, the backbone of Vert.x programming is the use of Handlers that will receive the result of an asynchronous operation. Hence, you will often see this kind of code:
void operation(param1, param2, Handler handler) {
...
handler.handle(.);
...
};
Vert.x guarantees the handler is always executed in the same event loop. Asynchronous done right…
There is one event loop per CPU. If you have multiple CPUs (and nowadays, you certainly have), you can then run several event loops: that’s the multi-reactor pattern. If ever you’ve got some blocking code, Vert.x offers several tools to encapsulate it in a non-blocking way: vertx.executeBlocking(.) methods or workers.
One other cool stuff provided by Vert.x is an EventBus that allows the different Vert.x services to communicate with each other. The EventBus offers several types of communication:
- publish / subscribe
- point to point
- request-response
The hands-on labs demonstrated these different possibilities as well as some HTTP server and HTTP client code. That was an handy labs. Useful to grasp some Vert.x concepts and possibilities. I had no time to finish it but will replay it (may be, by using the RxJava extension too). Thanks, Clément and Julien! It was nice to see you at Devoxx.
Pourquoi il ne suffira pas de faire du HTTP 2.0 pour faire des applications performantes… by Cyrille Dupuydauby, Raphaël Luta and Thomas Pierrain
Why it will not be enough to have HTTP/2 to get efficient applications
This Devoxx university was about network for the developpers. Often, for developers, network is a less loved subject. That should not be the case anymore if you attended (or watch the coming soon Devoxx video) this university.
The three mates started with an interactive game based on the Montessori method. To illustrate the way TCP is working, Raphaël played the role of a server that sends messages (paper envelopes with messages) over the network (the audience) to the client personified by Thomas. The public was given the envelops and had to pass them to their neighbors till Thomas. It was fun. Messages were passed un-ordered, then ordered. Some were lost, etc. Really nice live-demo on how TCP works! « TCP is a reliable way to pass messages over unreliable layers and a good trade-off between speed and reliability » was one of the message of this presentation.
Raphaël then discussed about the network. With a nice metaphor of road, he presented the characteristics of the network:
- bandwidth
- latency
- error rate
- duplex
- MTU (maximum transmission unit)
- Jitter (variation of latency)
- and BDP (= Bandwidth * Latency)
If bandwidth has increased these years, latency has not followed the same evolution. In short, with nice interactive graphs, Raphaël showed that latency is linear and bandwidth has less impact: it’s useless to have too much bandwidth, you just need to have enough. The latency is the key point.
Still with nice animated graphs, HTTP/2 was also presented. How it works, what we could expect, what dev habits (sharding, etc.) will change with it, etc. But HTTP/2 is not the Graal. You need to pay attention on the lower layers. To be able to test / debug all the network stuff, the speakers gave some tools: Chrome Dev Tools for web devs to emulate different networks (edge, 2G, 3G, 4G, wifi, etc.), Charles Proxy, Network Link Conditioner (MacOS), tc (Linux), netsh (Windows) and pftcl and dntcl. You also need to manage your connections: adjust the size of the TCP windows and buffers, check the limit of the file descriptors, minimize the TCP slow-start, increase the connections number, recycle the ports, etc. Lots of interesting hints!
On a higher level, Thomas talked about messaging. Pay attention to the size of messages: have you ever checked percentage of useful information compared to the size of a message for a SOAP message? Dreadful! And thus, pay attention of the format / serialization of the message. Depending on the usage, some may be better: Avro, FlatBuffers, Protobuf, etc. Thomas also gave an insight of the different messaging paradigm (RPC, REST, MOM, etc.).
Finally, Cyrille ended the talk with 7 fallacies of distributed systems (Peter Deutsch):
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn’t change
- There is on administrator
- Transport cost is zero
Really nice talk. Thanks guys!
JGiven : enfin une réelle documentation vivante by Clément Heliou and Marie-Laure Thuret
JGiven: a real living documentation!
This was a tools-in-action and a feedback about JGiven. JGiven is a Java BDD (Behavior-Driven Development) tool and a challenger to Cucumber. Clément and Marie-Laure have also experiences with Cucumber. From their point of view, Cucumber has some drawbacks: scenarii and code are in separate files, refactoring is not easy because of regexp which is the backbone of this tool and html reports are not nice and hard to use.
With JGiven, scenarii are written in their enterity in Java. Good point for refactoring: it’s easier. Reports are pretty nice by default. Besides the nice-looking, you’ve got search functions and the ability to have a hierarchy of scenarii. You can also classify your scenarii by tags you’ve added as annotations in your Java scenarii. You can include whatever in your scenarii: text, screenshots, etc.
I have looked at JGiven for a while. Marie-Laure and Clément gave a really nice and interesting feedback with a demo and some hints (use the imperative for your scenarii in order to mark your intention).
Toast Tk : l’automatisation de tests facile, collaborative et open source by Sallah Kokaina
Toast Tk: easy collaborative and open-source tests automation
Toast Tk is a solution for the acceptance tests automation. It has 3 parts: an engine, agents and a web UI.
You can use a recorder to capture and replay the user actions. Once this step done, you can execute these steps at will. With the web UI, you can organize your scenarii into tests campaigns, tag them to ease the search according to different criteria. The web platform also enables to visualise the reports. Toast Tk targets both Web and Java Swing applications.
To be continued… Stay tuned, we will soon publish day 2 of Devoxx France!
This post has been written in four hands: Jean-François Marquet and Cédric Tran-Xuan.
DevoxxFr 2016 – Part 2
DevoxxFr 2016 – Part 3