Voxxed Zürich 2016: Notes

3/18/2016 - Marco (updated on 9/18/2020)

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 nulls.
    • 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 TypeScript?

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 up/down/out
  • 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 files)

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 persistence.
  • 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 ask).

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.



expect("poo").length.toBe(1) -- Philip Hofstetter1


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.2
  • String is not a collection of bytes. It's a sequence of graphemes. string <> char[]
  • 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 constructed.
  • 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 by 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 by 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 purposes)
  • 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 lot).

  • 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 confused

  • 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 already

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.

  2. 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.

Sign up for our Newsletter