Random thoughts
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
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 karriere.at 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 oauth.io or auth0.com, 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 jsonapi.org 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
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 karriere.at 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 oauth.io or auth0.com, 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 jsonapi.org 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: austria, technology, wearedevs, webdevelopment