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: , , ,

Wednesday, May 16, 2018


WeAreDevelopers 2018 conference notes – Day 1

Some 8,000 developers are getting together this week in Vienna for the WeAreDevelopers 2018 world congress.

Registration was surprisingly fast and painless, a Graham roll and an energy drink as developer breakfast maybe slightly too clichéic (or I am getting old), but fortunately there was plenty of coffee available all day, including decent cappuccino at one of the sponsor booths.

Asked at the conference opening what topics people would be most interested in hearing about, Blockchain came out first, followed by machine learning and, still, devops.

Steve Wozniak rocked the Austria Center with an inspiring “fireside chat”. Talking with the brilliant Monty Munford, The Woz answered questions submitted by the audience and shared his views on anything from the early days of computing and why being a developer was great then (“Developers can do things that other people can’t.”) to self-driving electric cars (overselling and underdelivering) and the Blockchain (too early, similar to the dot com bubble), interspersed with personal anecdotes and, as a running gag, promoting the Apple iCloud.

As a long-time mainframe guy, I liked his claimed his programming language skills too, FORTRAN, COBOL, PL/I, and IBM System/360 assembler, although he did mention playing more with the Raspberry Pi these days.

Mobile payments was a good example of the design principles that made Apple famous and successful. Steve mentioned how painful early mobile payment solutions were, requiring multiple manual steps to initiate and eventually sign off a transaction, compared to Apple Pay where you don’t even need to unlock your device (I haven’t tried either one, and they don’t seem to be too popular yet.)

The most valuable advice though was to do what you are good at and what you like (“money is secondary”), to keep things simple, and live your life instead of showing it off, which is why he left Facebook, feeling that he didn’t get enough back in return. For an absolutely brilliant graphical summary of the session, see Katja Budnikov’s real-time sketch note.

Johannes Pichler of followed an ambitious plan to explain OAuth 2.0 from the protocol to to a sample PHP implementation in just 45 minutes. I may need to take another look at the presentation deck later to work through the gory details.

A quick deployment option is to use one of the popular shared services such as or, but it comes at the price of completely outsourcing authentication and authorization and having to transfer user data to the cloud. For the development of an OAuth server, several frameworks are available including node.oauth2 server for NodeJS, Sprint Security OAuth2 for Java, and the Slim framework for PHP.

In the afternoon, Jan Mendling of the WU Executive Academy looked at how disruptive technologies like Blockchain, Robotic Process Automation, and Process Mining shape business processes of the future. One interesting observation is about product innovation versus process innovation: most disruptive companies like Uber or Foodora still offer the same products, like getting you from A to B, serving food, etc. but with different processes.

Tasks can be further classified as routine versus non-routine, and cognitive versus manual. Traditionally, computerization has focused on routine, repetitive cognitive tasks only. Increasingly we are seeing computers also take on non-routine cognitive tasks (for example, Watson interpreting medical images), and routine manual, physical tasks (for example, Amazon warehouse automation). 

Creating Enterprise Web Applications with Node.js was so popular that security did not let more people in, and there was no overflow area available either, so I missed this one and will have to go with the presentation only.

Equally crowded was Jeremiah Lee’s session JSON API: Your smart default. Talking about his experience at Fitbit with huge data volumes and evolving data needs, he made the case why should be the default style for most applications, making use of HTTP caching features and enabling “right-sized” APIs.

Hitting on GraphQL, Jeremiah made the point that developer experience is not more important than end user performance. That said, small resources and lots of HTTP request s should be okay now. The debate between response size vs number of requests is partially resolved by improvements of the network communication, namely HTTP/2 header compression and pipelining, reduced latency with TLS 1.3 and faster and more resilient LTE mobile networks, and by mechanisms to selectively include data on demand using the include and fields attributes.

Data model normalization and keeping the data model between the clients and the server consistent was another important point, and the basis for efficient synchronizatiion and caching. There is even a JSON Patch format for selectively changing JSON documents.

Niklas Heidoff of IBM compared Serverless and Kubernetes and recommended to always use Istio with Kubernetes deployments. There is not a single approach for Serverless. The focus of this talk was on Apache OpenWhisk.

Kubernetes was originally used at Google internally, therefore it is considered pretty mature already despite being open source for only a short time. Minikube or Docker can be used to run Kubernetes locally. Composer is a programming model for orchestrating OpenWhisk functions.

Niklas went on to show a demo how to use Istio for versioning and a/b testing. This cannot be done easily with Serverless, which is mostly concerned about simplicity, just offering (unversioned) functions.

The workshop on Interledger and Website monetization gave an overview of the Interledger architecture, introducing layers for sending transactions very much like TCP/IP layers are used for sending packets over a network. Unlike Lightning, which is source routed so everyone has to know the routing table, Interledger allows nodes to maintain simply routing tables for locally known resources, and route other requests elsewhere

Labels: , , ,

Page tools