streamdata.io at Mix-IT – Day #1

Thanks to Human Talks Lyon, I had a chance to attend Mix-IT, a nice conference, focused on development, agility and innovation.

In a few figures, Mix-IT, was:

• 7 keynotes
• 37 talks
• 20 workshops
• 19 lightning talks of 5 minutes
• 72 speakers
• 550 attendees
• around 1400 “crêpes” (thin Brittany pancakes)

In two days for only 50€! The tickets were sold out 2h30! Fortunately, the keynotes and talks will be soon available on InfoQ, so stay tuned!
The organization was great, thanks to the Mix-IT team who did a fabulous job: there were “viennoiseries” in the morning,  unlimited coffee, tea and fruit at every break-time, a tasty and healthy lunch (baos, salad and a desert) and unlimited crêpes  (amazing!!!). It seems that the organizers paid attention to delivering tasty  and high quality food.  Crêpes seemed to be a “staple” at Mix-IT , so many thanks to the Mix-IT team and the volunteers!

The day started “with a 30 seconds to convince” by each speaker before a 20 min keynote. The first keynote was “The three ages of innovation” by Dan North, who made a wonderful talk at QConLondon.

The three ages of innovation – Dan North

According to Dan North, Innovation has three ages:

1. Explore
2. Stabilize
3. Commoditize

The goal of “Explore” is about “maximizing discovery”. This can be done by experimenting (and Dan to quote Isaac Asimov: « The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’, but ‘That’s funny …’ »), analyzing, studying, researching, sketching and playing.
“Stabilize” aims to “minimize variance”. This goes through by categorizing, validating, articulating (as a metaphor, a story, etc.), structuring and with repeatability, teachability and predictability.
At last, cost, time, activity, effort, economics and scale are factors to achieve the target of “Commoditize”: maximizing efficiency.
This was a nice talk (one of Dan North has the secret). “Explore”, “Stabilize” and “Commoditize” were written in Red, White and Blue. A wink to the French flag?

Agilité par le code grâce à CQRS et EventSourcing – Clément Bouillier, Jean Helou, Emilien Pecoul and Florent Pellet

This was a workshop about CQRS (Command Query Responsibility Segregation) and EventSourcing. Well, it was a tough workshop from the beginning. The four tutors had indeed proposed another workshop that was supposed to introduce this one.  Unfortunately, it was not accepted as a workshop, so, it was a bit hard to start the exercises. After a while and explanation of the speakers, the code began to be more and more clear. The code and the different exercises aimed to illustrate the different faces of CQRS and EventSourcing and some practices (as projections to handle the state of the events flow, event handlers, etc.). It was a bit too short to end the workshop and grasp all the details concepts,  but what we saw gives us a rough idea about the “simplicity” of the architecture and code induced by EventSourcing and CQRS. It made me want to terminate the exercise and then the reading of the blue book and the one of Vaughn Vernon. So, thanks! Oh, by the way, the workshop can be found here (for C#, Java, JavaScript and Php).

Le JavaScript du futur au bout des doigts – Julien Roche

Another workshop. This time about ES6 also known as EcmaScript 2015, the next version of JavaScript that will be supported soon in the next generation of the browsers. There are already some features supported by the different browsers. You can find a compatibility matrix here. According to Julien, it is worth studying ES6 now because it will arrive soon in our browsers and brings some cool stuff that enhance the way of writing and reading JavaScript: for … of loop, arrow functions, classes, modules to cite a few. And indeed, with all these features, it seems to be simpler to write nice and readable code (I find it starts to look like Java, Scala or Groovy code). The hands-on was focused on a very simple example. We first started to write it in ES5-ish style (the JavaScript of today in the early 2015) and steps by steps, modified the code to use some ES6 features. It was quite nice. The sample was maybe a bit too simple. We also covered Babel, an ES6 to ES5 transpiler which enables to convert ES6 code into ES5 code so that browsers of nowadays can interpret JavaScript programs written in ES6 (so, no excuse not to write ES6 code ;)). I have also had a look at the other materials Julien gave us and the presentation gives a nice overview of the ES6 features and tooling. I think I will bookmark them with my ES6 notes. Finally, you can locate the workshop code here (it’s in French).

Look Ma, I’m a core developer – Emmanuel Hugonnet

Emmanuel is one of the AlpesJUG founders and is a core developer of Wildfly / JBoss EAP, the open-source JEE server, at RedHat. First, Emmanuel presented some characteristics of a “real” open-source project. Besides having open- sources, an open-source project must:

• have various actors
• have a community
• have a license
• have its own rules (commits, coding conventions, pull-requests acceptance, etc.)
• have its own agenda. If this project is supported by a company with an enterprise version, still the open-source project should have an agenda decoupled from the one of the enterprise one

The second part of the talk was a feedback of Emmanuel in his team, the Wildfly team. How they are organized? What are their open-source “policies”? The Wildfly team is spread all over the world (Australia, China, Europe, USA, etc.). So forget, the daily meeting… You can work in the morning with Australian guys and in the evening with American developers, but basically all the communication is asynchronous (a kind of RxCommunication ;)). So, if you have an issue to fix and one of your mates can give you more insight about it, you can be pretty sure this mate is sleeping (at least not working) while you are working, but this leads you to be autonomous. You have to do on your own, to cope with the fact you will get the answer the day after. So, distributed world team leads to asynchronous communitcation which, in turn, leads to less meetings and more autonomy.
Responsibility is one of the pillars of  team organization: every teammate is responsible for taking an issue, developing a feature or reviewing a pull request. Code review by a pair also plays an important role. When your code is reviewed, you get feedbacks (e.g. typos to fix, reminder of coding convention, some code hints or best practices) and, thus, can improve yourself and deliver better code. When you review code, you can get knowledge from parts of the code you don’t know (and thus, get a more detailed picture of the whole project) and learn some goodies on how other people code. So, it’s a rich experience that favor helping to improve the team-mates. Emmanuel said “mentoring”. Lastly, openness rules the project: every subject is discussed through public mailing-lists and everyone (Wildfly team or external people) can contribute.
Emmanuel is convinced that all of these practices can be incorporated into the enterprises for their benefit. The talk was interesting and touched with humor. I enjoyed it. Thanks!

Si le TDD est mort, alors pratiquons une autopsie – Thomas Pierrain and Bruno Boucard

The goal of talk was to answer why many developers give up with TDD. I guess the title was a reference to the “TDD is dead” controversy… It was a very interesting talk as well.
If TDD can be reassuring (you know rapidly when something is broken), effective (YAGNI principle) and personally satisfying (you get positive feedback when your test become green which is a bit gratifying), TDD must not be reduced just to the “Red -> Green -> Refactor” motto. It’s a set of “tools”, practices we need to exercise.
The first one is to avoid straight coding (the developer temptation!) but investigating your subject first: the better your understanding, the better and cleaner your code will be. Expressing aloud can help to clear your ideas and wipe out dark blur reasoning. The use of the “should” in your test method or class names can complete this method: by using “should” (for instance, “aNewAccountShouldHaveAZeroBalance()” instead of “testZeroBalanceOfNewAccount()”), you help to express an emergent design.
Instead of simple “Red, Green, Refactor”, you switch to the double loop outside-in (see the schema here and the first chapter of this blog post), which is basically not only having unit test failing but also having an acceptance test failing, making them pass and refactoring. By doing this, you can get a more global insight of your system and its behavior.
Discussing is another important part: it helps to better understand the specifications and share the knowledge. So, discuss with teammates, users and other teams. You will learn a lot. Thomas and Bruno cited the 3 Amigos model which seems to be a pretty interesting way as well as techniques of “the 5 why?” and impact mapping.
Paying attention to test behaviors not methods also matters. Only behaviors reflect how the system reacts, methods do not.
At last, regularly training is also a key aspect. If you train, your brain won’t consider what you do as a pain and will be able to focus on other tasks. Julien and Bruno compare this to the JVM JIT: the JVM needs to start and runs a while before JIT can perform optimisation of the runtime. So, training lets you optimize your brain… To do so, there some “tools”: code kata, coding dojos and so on.
Finally, they gave us some resources links they estimate really useful:

• The coding Dojo Handbook by Emily Bache
• Fifty Quick Ideas to Improve your User Stories, by Gojko Adzic and David Evans
• Impact Mapping: Making a big impact with software products and projects, by Gojko Adzic
• Thinking, Fast and Slow by Daniel Kahneman
• Growing Object-Oriented Software Guided by Tests by Steve Freeman and Nat Pryce

Not to spoil too much, I did not mention that Thomas drew an interesting parallel between Michael Ange and a craftman developer. There were also books about Michael Ange, but unfortunately my photo was cut off  🙁

10 ways to kill your startup – Paul Bakaus

Paul Bakaus is a developer advocate at Google. The title of his talk is pretty explicit.

Main points:

1. untested code and undocumented code
2. ego: “I can build all from scratch”. Really? You may rewrite a library for your project but are you sure you will be able to build one of the same quality as a team whose job is focused on building and maintaining such a library
3. micro-optimisation: good enough is probably enough for what you do. Don’t spend your time trying to micro-optimize. Perfection can be time consuming and may not even be reachable.
4. handle every edge case: while you may never meet them. Paul stated that if you hear “well, you could theoritically meet this case…”, then this case might be a good candidate for not being taken in account. If you know you have few chances the case occurs then it may not be worthwhile spending time and money on dealing with it
5. jump into conclusions: it’s about the syndrome “it works on my environment, so it works”. Paul took an example of an application that needs wifi. You have tested it in your office where the wifi is blazing fast. But have you tested it in another environment where wifi can be unreliable?
6. choose unsupported tech: you may have found a killer technology. But is it well maintained (by more than one guy or girl who builds it during his free time)? Can you get support for it? and so on
7. micro-manage: I’ve just retained “iterate fast, fail fast, break often”
8. look at your infrastructure: sorry, you will have to look at the InfoQ video: I did not manage to take notes…
9. build upon prototype: you made a prototype to validate your idea. Great! Don’t use it, to build your product. Throw away the code of the prototype and the architecture and re-build your product from scratch
10. treat security as afterthought performance: you will regret it

Cloud et vie privée – Tristan Nitot

Tristan Nitot introduces himself as C3PO, which stands for Cozy Cloud Chief Product Officer. Cozy Cloud is a private cloud you can install at home (on a RaspberryPi 2 for instance) to manage your emails, contacts, documents or photos. That seems to be an interesting product and it may be worthwhile having a look at it.
IT came in our home through the PC (Personal Computer), then came the revolution of the Internet, now there is cloud computing, which allows us to store mails, docs or photos in the cloud. All of these services are free. Are they actually free? That’s Tristan’s question. Why are these services free for us? Maybe because someone pays for them, and this one is the real customer: the one who pays is the customer. All these services are actually financed by the advertising which has become more and more intrusive in our life, since it has access to more and more information about us. Tristan showed us a Geek and Poke comic about the “free” model and drew a parallel between us and the pigs. Nice one. So, keep in mind that if you are using something free, you may be the pig in the pigsty. No more.
Our privacy can be not only threatened by private companies, but also by government. The French law about intelligence that was voted at first reading by 25 deputies (on the 577) is an example according to Tristan. Believing that we have nothing to hide is an illusion as we all have things to hide. Our privacy is first, and protecting it must not be synonymous with illegality.
The talk was great, with touches of humor, for a serious subject which should concern us all. I especially loved the reference to the panoptic jail and Foucault’s point of view: “seeing without being seen” can lead to dictate peoples behavior. I recommend  that you have a look at this keynote once available on InfoQ. It was very inspiring.