TopConf Linz 2017 Notes

For the second time I visited the TopConf in Linz, again as a speaker talking about the new skills required for technical leaders in network organizations. You can watch a periscope recording of the talk here, the slides are here.

During the conference, I took some notes about the things I found interesting in our tech Slack channel. Some of you might find these interesting, so here you go:

Day 1

The keynote from a Google Infrastructure Expert was interesting, but their problems are special. Good thing that we can source this problem out to AWS ;-)

Next one was the Intro to Elm. He built a Prezi clone (Source, Slides) and used that example to walk through most of the parts of elm-lang.org. It produces JavaScript code without runtime errors but that requires you to define a solution to the 100%. Which is tough for prototyping, but you will have code that is easier to refactor in order to add new features. I think it might be a good choice for features that are complete and to rebuild them in Elm to make the even safer.

So, back from the Rust Talk (bad Wifi there). If you want to build server side micro service applications, Rust is the way to go. It has a lot of advantages over Go and is now already widely used at Mozilla. I think we don't need to go in that direction as long as we don't have scaling issues. Running node code at AWS scales, but the price will be way higher compared to the same service running as a native binary.

I knew the book but Corinna's talk was very interesting and entertaining. Especially to learn how Sipgate does Budgeting. They basically have no Budgets and no tight control, only through transparency. Like Netflix: "Spend in the best interest of the company." Even for education, they have no limit and it works out great for them.

Cool presentation on projects or the problems with them: #BeyondNoProjects.

Flowtype and The Wonders of Statically Typed JavaScript: Because we have now Babel available everywhere, it might be a good time to look again at flow. I mean, we barely have runtime errors. But compared to tcomb it provides additional features like automatic documentation and more sanity checks that can't be discovered by tcomb. Because tcomb only works at runtime. So, a strategy could be: use tcomb for runtime checks (e.g. at boundaries / public APIs, where you can't enforce the calling code). And flow anywhere else. It's great that you can use flow opt-in too and you can start small.

The session on UX was meh. Nothing interesing to report, besides: use PageSpeed.

Then I was in the Panel on Distributed Teams: you can watch it here … my battery died after 50mins, though. The panel starts at around 7:30mins.

Day 2

Keynote: Thirty months of microservices. Stairway to heaven or highway to hell? : Nice: The Zalando Tech guidelines on building RESTful APIs.

A book recommendation from #NoProjects talk: The Principles of Product Development Flow.

The Skillful Sailor talk was pretty boring. A very simplified overview of how organizational change works.

In the Frequent Releases & Major Changes from @mmozuras he went through the basics of continuous delivery and developing in parallel: feature flags, which enables things like A/B tests.