Thursday, May 17, 2018


WeAreDevelopers 2018 conference notes – Day 2

Thursday was another busy day at the WeAreDevelopers 2018 world congress in Vienna. Some of the logistics challenges with missing or unannounced overflow areas have been resolved, and I did even see a picture posted of the afternoon snacks, so they do exist but seem to be going fast. The ÖBB booth at least had some nibbles left.

A major upgrade of a JavaScript framework or switching to a different framework altogether can be quite a hassle, as most of us probably have experienced. Tracy Lee (@ladyleet) started day 2 with the bold promise of writing highly reusable, future proof code. The secret sauce to enable this magic is Reactive programming and the RxJS library for reactive programming using Observables.

Following Tracy’s intro, Michael Hladky (@michael_hladky) looked into the gory details of RxJS schedulers, with live coding and cool demos on stage. There are several types of schedulers, asapScheduler, asyncScheduler, queueScheduler,  animationFrameScheduler, virtualTimeScheduler, and testScheduler.

 The execution order of events depends on the type of scheduler. Little known and hardly documented is the fact that introducing a non-zero delay effectively turns any scheduler into an asyncScheduler, which may lead to unexpected results.

Security analyst Florian Grunow (@0x79) shared his security hall of shame with examples of insecure Web Applications and creative but futile countermeasures. Surprisingly, the security issues are still largely the same as a decade ago, like clear text credentials, missing authorization checks, sequential ids, autocomplete passwords, and cross-site scripting attacks.

Non-alphanumeric cross-site scripting is a good example of why input validation and stripping some special characters is not sufficient, for example


Colm Doyle (@colmisainmdom) showed how companies are using #slack to enable ChatOps 2.0: Bringing ChatOps Principles to the Whole Organization. Organizations are wider than just technical teams, and command line interfaces may not be for everyone. Shopify, one of the companies mentioned, has a pretty detailed description of their incident management procedure on their engineering site.

In the afternoon, Horst Kargl of Sparx Systems gave an introduction into modelling using Enterprise Architecture tools and languages like UML and SysML; not sure if the agile aspect was covered in greater detail later, as I had to leave the session.

Writing Perfect Code with Standard and ESLint by Feross Aboukhadijeh (@feross) could have been the shortest talk ever:  npm --install standard; done. Fortunately there was more on programmer errors, best practices, and style issues, and how linters can help with these. Pretty neat examples of broken or otherwise surprising JavaScript code, for example

[]==![]    // true
[]==false  // true
![]==false // also true, yikes!

Continuing the awesomeness was Una Kravets (@una) with an exciting story about the past, the present and the future of CSS. The past was ugly hacks and lots of browser specific code, been there, done that. The present already held some surprises unless you have been following CSS developments closely, and the future capabilities range from “Wow, I had no idea you could ever do this” to some really crazy stuff.

@supports, display: grid, the will-change property, CSS variables, variable fonts, font animation, ambient light media queries are among the more recent features, with varying browser support (read: mostly not working in IE). comes handy when implementing a grid design using flexbox. What was particularly nice was the fact that the presentation deck itself was HTML+CSS, allowing live demos of most features from the debug console.

Flavia Sequeira and Ernst Naezer of ING shared the evolution of their API journey at ING, from the initial API discussions to a working API management practice, and the benefits of regulatory pressure in the form of PSD2. What makes a good API? APIs are different from Web services in that they should be designed from the outside in.

The categorization into self, screen and stage APIs depending on who they are made for sounds about right, and the POST to GET is a commonly seen pattern both for security reasons and request size restrictions. The one thing I wish we had thought of when designing APIs a while back is the /me pattern for the authenticated user, instead of passing the user identification again in the request.

Rounding off the day, Matthias Huttar (@matthuttar) took the audience on the journey to trunk based development, explaining the importance of successful builds and being on time at kindergarten, and energizing the crowd for the last session with a superfast round of high fives.

Trunk development is great for well integrated teams that value speed over safety, and can help reduce cycle times, conflicts and ultimately errors and rollbacks if done right. There are scenarios where trunk development may be less suitable, including highly regulated environments such as financial services or utilities, as well as open source projects where the circle of trust is much smaller than the circle of contributors.

Related links

Labels: , , ,

Comments: Post a Comment

Subscribe to Post Comments [Atom]

Page tools