WeAreDevelopers 2018 conference notes – Day 2
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
this['ale'+(!![]+[])[-~[]]+(!![]+[])[+[]]]()
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). gridtoflex.com 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: austria, technology, wearedevs, webdevelopment