Published by Marco on 18. Mar 2016 10:05:13

This first-ever "Voxxed Zürich"  was hosted at
the cinema in the SihlCity shopping center in Zürich on March 3rd. All
presentations were in English. The conference was relatively small -- 333
participants -- and largely vendor-free. The overal technical level of the
presentations and participants was quite high. I had a really nice time and
enjoyed a lot of the presentations.

There was a nice common thread running through all of the presentations,
starting with the Keynote. There's a focus on performance and reliability
through immutabiliy, sequences, events, actors, delayed execution (lambdas,
which are relatively new to Java), instances in the cloud, etc. It sounds very
BUZZWORDY, but instead it came as a very technically polished conference that
reminded me of how many good developers there are trying to do the right thing.
Looking forward to next year; hopefully Encodo can submit a presentation.

You can take a look at the "VoxxedDays Zürich -- Schedule"
. The talks that I
visited are included below, with links to the presentation page, the video on
YouTube and my notes and impressions. YMMV.

[Keynote: Life beyond the Illusion of the Present]

"Life beyond the Illusion of the Present"

-- Jonas Bonér



  * He strongly recommended reading "The Network is reliable"
     by Peter Bailis.
  * This talk is about event-driven, CQRS programming.
  * Focus on  immutable state, very much like JoeDuffy, etc. transactional
    accrual of facts. 
  * Never delete data, annotate with more facts.
  * The reality at any point can be calculated for a point in time by
    aggregating facts up to that point. Like the talk I once wrote up some notes
    about ("Runaway Complexity in Big Data, and a Plan to Stop It" by Nathan
    Marz ). 
  * Everything else is a performance optimization. Database views, tables are
    all caches on the transaction log. Stop throwing the log away, though.
  * Define smaller atomic units. Not a whole database. Smaller. Consistency
    boundary.  Services?
  * Availability trumps consistency. Use causal consistency through mechanisms
    other than time stamps. Local partial better than global.
  * He talked about data-flow programming; fingers crossed that we get some
    language support in C# 7
  * Akka (Akka.NET) is the main product.

[Kotlin - Ready for production]

"Kotlin - Ready for production"

-- Hadi Hariri


  * Used at JetBrains, open-source. 14k+ users. It's not a ground-breaking
    language. They tried Scala and Scala was the first language they tried to
    use (Java already being off the table) but they didn't like it, so they
    invented Kotlin.
  * Interoperable with Java (of course). Usable from all sorts of systems, but
    intelliJ Idea has first-class support.
  * Much less code, less maintenance. Encapsulates some concepts like "data
    classes" which do what they're supposed for DTO definitions.
    * Inferred type on declarations. No nulls. Null-safe by design. Opt-in for
    * Implicit casts as well
    * Interface delegation
    * Lazy delegation
    * Deconstruction
    * Global infix operators; very expressive
    * Also defaults to/focuses on immutability
    * Algebraic data types/ data flow
    * Anglo is statically typed XML views for android
  * JavaScript target exists and is the focus of work. Replacement for

[Reactive Apps with Akka and AngularJS]

"Reactive Apps with Akka and AngularJS"

-- Heiko Seeberger


  * He strongly recommended reading "the reactive manifesto"
  * Responsive: timely response / non-functional / also under load / scale
  * Resilient: fail early
  * Message-driven: async message-passing is a way of getting
    reactive/responsive. Automatic decoupling leads to better error-handling, no
    data loss
  * Akka provides support for:
    * Actor-based model (actors are services); watch video from Channel Nine
    * Akka HTTP Server is relatively new
    * Akka is written in Scala
    * There's a Scala DSL for defining the controller (define routes)
    * The Scala compiler is pure crap. Sooooo slooooowww (62 seconds for 12

During his talk, he took us through the following stages of building a scalable,
resilient actor-based application with Akka.

  * First he started with static HTML
  * Then he moved on to something connected to AKKA, but not refreshing
  * W3C Server-sent events is unidirectional channel from the server to the
    client. He next used this to have instant refresh on the client; not
    available on IE. Probably used by SignalR (or whatever replaced it)? Nothing
    is typed, though, just plain old JavaScript
  * Then he set up sharding
  * Then persistence (Cassandra, Kafka)

AKKA Distributed Data

  * Deals with keeping replicas consistent without central coordination
  * Conflict-free replicated data types
  * Fully distributed, has pub/sub semantics
  * Uses the Gossip protocol
  * Support various consistency strategies
  * Using AKKA gives you automated scaling support (unlike the SignalR demo Urs
    and I did over 2 years ago, but that was a chat app as well)

AKKA Cluster Sharding

  * Partitioning of actors/services across clusters
  * Supports various strategies
  * Default strategy is to distribute unbalanced actors to new shards
  * The ShardRegion is another actor that manages communication with sharded
    actors (entities). This introduces a new level of indirection, which must be
    honored in the code (?)

AKKA Persistence

  * Event-sourcing: validate commands, journal events, apply the event after
  * Application is applied to local state only after the journal/persistence has
    indicated that the command was journaled
  * On recovery, events are replayed
  * Supports snapshotting (caching points in time)
  * Requires a change to the actor/entity to use it. All written in Scala.

Akka looks pretty good. It guarantees the ordering because ACTORS. Any given
actor only exists on any shard once. If a shard goes down, the actor is
recreated on a different shard, and filled with information from the persistent
store to "recreate" the state of that actor.

DDD (Domain-Driven Design) and the actor model. Watch "Hewitt, Meijer and
Szyperski: The Actor Model (everything you wanted to know, but were afraid to

Code is on GitHub: seeberger/reactive_flows

[Lambda core - hardcore]

"Lambda core - hardcore"

-- Jarek Ratajski


Focus on immutability and no side-effects. Enforced by the lambda calculus.
Pretty low-level talk about lambda calculus. Interesting, but not applicable. He
admitted as much at the top of the talk.


  * "Dixin's Blog" 
  * "Badlam visualization" 
  * "His presentation engine" 



-- Philip Hofstetter [1]


This was a talk about expectations of the length of a character. The presenter
was very passionate about his talk and went into an incredible amount of detail.

  * What is a string? This is the kind of stuff every programmer needs to know.
  * String is not a collection of bytes. It's a sequence of graphemes. string <>
  * UTF-16 is crap. What about the in-memory representation? Why in God's name
    did Python 3 use UTF32? Unicode Transformation format.
  * What is the length of a string? ä is how many? Single character (diuresis
    included) or a with combining diuresis?
  * In-memory representation in Java and C# are UCS-2 (UNICODE 1); stuck in
    1996, before Unicode 2.0 came out. This leaks into APIs because of how
    strings are returned ... string APIs use UTF-16, encoding with surrogate
    pairs to get to characters outside of the BMP (understood by convention, but
    not by the APIs that expect UTF-16 ... which has no idea what surrogate
    pairs are ... and counting algorithms, find, etc. won't work).
  * ECMAScript hasn't really fixed this, either. substr() can break strings
    charAt() is still available and has no idea about code points. Does this
    apply to ES6? String-equality doesn't work for the diuresis above.
  * So we're stuck with server-side. Who does it right? Perl. Swift. Python.
    Ruby. Python went through hell with backwards compatibility but with 3.3
    they're doing OK again. Ruby strings are a tuple of encoding and data. All
    of the others have their string libraries dealing in graphemes. How did Perl
    always get it right? Perl has three methods for asking questions about
    length, in graphemes, code points or bytes
  * What about those of us using JavaScript? C#? Java? There are external
    libraries that we should be using. Not just for DateTime, but for
    string-handling as well. Even EcmaScript15 still uses code points rather
    than graphemes, so the count varies depending on how the grapheme is
  * Security concerns: certificate authorities have to be aware of homographs
    (e.g. a character that looks like another one, but has a different
    encoding/byte sequence).
  * He recommended the book "Unicode explained"
    Jukka K. Korpela.

[How usability fits in UX - it's no PICNIC]

"How usability fits in UX - it's no PICNIC"

-- Myriam Jessier


What should a UI be?

   1. Functional
   2. Reliable
   3. Usable
   4. Convenient
   5. Pleasurable

Also nice to have:

   1. Desirable
   2. Delightful
   3. memorable
   4. Learnable
   5. 3 more

Book recommendation: "Don't make me think"
Steve Krug

  * Avoid mindless and unambiguous clicks. Don't count clicks, count useless
    shit you need to do.
  * Let the words go. People's attention will wander.
  * UX is going to be somewhat subjective. Don't try to please everyone.
  * OMG She uses hyphens correctly.
  * She discussed the difference between UX, CX, UI.
  * Personas are placeholders for your users. See "Personapp"
     to get started working with personas.


  * Consistent and standardized UI
  * Guide the user (use visual cues, nudging)
  * Make the CallToAction (CTA) interactive objects obvious
  * Give feedback on progress, interaction
  * Never make a user repeat something they already told you. You're software,
    you should have eidetic memory
  * Always have default values in forms (e.g. show the expected format)
  * Explain how the inputed information will be used (e.g. for marketing
  * No more "reset" button or mass-delete buttons. Don't make it possible/easy
    to wipe out all someone's data
  * Have clear and explanatory error or success messages (be encouraging)
  * Include a clear and visual hierarchy and navigation

Guidelines for mobile:

  * Make sure it works on all phones
  * Give incentives for sharing and purpose (engagement rates make marketing
    happy. CLICK THE BUTTON)
  * Keep usability and conversion in mind (not necessarily money, but you
    actually want people to be using your app correctly)
  * Usability (can you use your app on the lowest screen-brightness?)
  * ...and more...
  * Make it pretty (some people don't care, e.g. She very clearly said that
    she's not aesthetically driven, it's not her field; other people do care. A
  * Give all the information a customer needs to purchase
  * Design for quick movement (no lag)
  * Do usability testing through video

  * Leverage expectations. Fit in to the environment. Search is on the left?
    Behind a button? Do that. Don't make a new way of searching.
  * If you offer a choice, then make them as mutually exclusive as possible.
    When a company talks to itself (e.g. industry jargon), then users get
  * The registration process should be commensurate to the thing that you're
    registering for
  * Small clickable ads on mobile. Make click targets appropriate.
  * Don't blame negative feedback on "fear of change". It's probably you. If
    people don't like it, then it might not be user-friendly. The example with
    Twitter's star vs. heart. It's interesting how we let the world frame our
    interactions. Why not both? Too complex? Would people really be confused by
    two buttons? One to "like" and one for "read later"?

Suggested usability testing tools:

  * Crazy Egg is $9 per month for heatmaps.
  * Qualaroo
  * Optimizely (A/B testing)
  * Usabilia
  * Userfeel
  * Trymyui

[React - A trip to Russia isn't all it seems]

"React - A trip to Russia isn't all it seems"

-- Josh Sephton [3]


This talk was about Web UI frameworks and how his team settled on React.

  * Angular too "all or nothing".
  * Backbone has no data-binding.
  * React looks good. Has its own routing for SPAs. Very component-heavy.
    Everything's a component. Nothing new here so far.
  * They built their React to replace a Wordpress-based administration form
  * Stateful components are a bad idea
  * React components are like self-contained actors/services
  * They started with Flux, but ended up with Redux. We're using Redux in our
    samples. I'm eyeballing how to integrate Akka.Net (although I'm not sure if
    that has anything to do with this.
  * ReactNative: write once, use on any device
  * Kind of superficial and kinda short but I knew all about this in React

[The reactor programming model for composable distributed computing]

"The reactor programming model for composable distributed computing"

-- Aleksandar Prokopec [4]


  * Reactive programming, with events as sequences of event objects
  * Events are equivalent to a list/sequence/streams (enumerable in C#)
  * This talk is also about managing concurrency
  * There must be a boundary between outer concurrent events vs. how your
    application works on them
  * That's why most UI toolkits are single-threaded
  * Asynchronous is the antonym of concurrency (at least in the dictionary)
  * Filter the stream of events to compress them to frames, then render and log,
    so the events come in, are marshaled through the serializing bottleneck and
    are then dispatched asynchronously to different tasks
  * Reactor lets clients create their own channels (actors) from which they read
    events and which they register with a server so that it can publish
  * Akka supports setting up these things, Reactor is another implementation?
  * Dammit I want destructuring of function results (C# 7?)
  * It's very easy to build client/server and broadcast and even ordered
    synchronization using UIDs (or that pattern mentioned by Jonas in the
    keynote) The UID needs to be location-specific, though. That's not
    sufficient either, what you need is client-specific. For this, you need
    special data structures to store the data in a way that edits are
    automatically correctly ordered. Events sent for these changes make the
    events are ordered correctly
  * What is the CRDT? We just implemented an online collaborative editor:
    composes nicely and provides a very declarative, safe and scalable way of
    defining software. This is just a function (feeds back into the idea of
    lambdas here, actually, immutability, encapsulation)
  * "Reactors" 


[1] I am aware of the irony that the emoji symbol for "poo" is not supported on
    this blogging software. That was basically the point of the presentation --
    that encoding support is difficult to get right. There's an issue for it:
    "Add support for UTF8 as the default encoding"

[1] In my near-constant striving to be the worst conversational partner ever,  I
    once gave a similar encoding lesson to my wife on a two-hour walk around a
    lake when she dared ask why mails sometimes have those "stupid characters"
    in them.