Recap of the Schneide Dev Brunch 2018-02-11

brunch64-borderedOn Sunday, February 11th, we held another Schneide Dev Brunch, a regular brunch on the second sunday of every other (even) month, only that all attendees want to talk about software development and various other topics. This brunch was well-attended, with two new guests that seemed to feel comfortable after just a few minutes. The table provided just enough space for us. As usual, the main theme was that if you bring a software-related topic along with your food, everyone has something to share. Because we were a larger group, we discussed with an agenda. As usual, a lot of topics and chatter were exchanged. This recapitulation tries to highlight the main topics of the brunch, but cannot reiterate everything that was spoken. If you were there, you probably find this list inconclusive:


Our first topic was a presentation of the asciidoc syntax and the asciidoctor converter. The asciidoc syntax can be used to describe structured textual content in a concise manner with a few funny special characters. It looks like markdown at the first glance, but has the benefit of being fully standardized and extensible instead of one of several competing dialects.

The asciidoctor is an active rewrite of the first asciidoc converter. Given the right set of formatters, you can generate a PDF, a self-contained interactive HTML presentation and a static web page from one single source. This follows the “one true source, many derived artifacts”-approach that every software developer should know by heart (Don’t Repeat Yourself!).

Because setting up a productive asciidoctor environment is still some manual work, one of our attendees has published a github repository that automates the manual work as much as possible: asciidoc presentation.

If you need an alternative to markdown or even TeX/LaTeX, have a look at asciidoc. It seems specifically aimed at software developers and is probably already integrated in your favorite IDE (the integration in IntelliJ is seamless).


We discussed the two extreme approaches to handle dependencies for your project. The first extreme is to only include links to other projects/repositories that need to be fetched manually or automatically. Most modern build tools orientate towards this approach, even if there are some disadvantages like the recent Go/Github disturbance.

The second extreme is to include everything that’s needed in your repository. For a Javascript project that means that you provide your own, probably out-dated version of leftpad and thousand other libraries. You need a way to deal with transitive dependencies and keep an eye on all the versions to mitigate the risk of long-fixed vulnerabilities.

The second extreme is extremely helpful if you don’t have internet access but want to develop.

A good compromise is the local offline mirror, something that build tools/dependency managers like maven have for over a decade. This local repository is filled with all the leftpads and apache-commons that your projects need. If you checkout a new project, remember to make the build tool download the dependencies to your local repository before you go offline.

for Javascript, this concept seems a bit foreign. Who would develop for the web without the web, anyways? Yarn seems to provide a working offline mirror functionality for npm packages, though. Perhaps it is worth a look.

Opt-Out explained with groceries

During out dependency management discussion, we also compared downloadable installers with malware droppers. But that’s not where our comparisons stopped. We also came up with a good metaphor for Opt-In vs. Opt-Out methods.

If you enter a grocery store and grab a shopping cart, only to find that it already contains two or three packages of sweets and some overpriced milk, you chose an Opt-Out store. Your responsibility is to return the goods to their aisle or to buy them.

You’re probably used to Opt-In type grocery stores.

Book review: Functional Programming in Java

We took a look at Pierre-Yves Saumont’s book “Functional Programming in Java”. This book is a little bit odd in that you shouldn’t read it, you are meant to program it. Or at least try to solve the numerous training exercises and riddles. This makes it hard to read the paper version of the book, because it’s a pick-two situation of keyboard, mouse and book on your desk.

The book explains real functional programming and not the functional additions of Java 8. It explains it on top of the JVM, using Java’s language constructs. But, you will learn it from the origins and develop abstractions like Function oder Supplier yourself. Imagine you had all compiler magic of Java 8 but no JDK classes to leverage it – this book tells you how to use it.

It’s a good book, but unique in its style. It grounds on exercises and your own understanding of the material. It isn’t spoon-fed, you have to work for it yourself. It didn’t chose any existing pure functional language, but plain Java for this. So you have no excuse about weird syntax or unfamiliar ecosystems. It’s boring old Java turned in an exciting new way.

And if you are lazy and don’t feel like writing your own functional groundwork toolkit, you might want to look at vavr, a functional programming library for Java.

Polyglot language idioms

We discussed the portability of language idioms and highlighted the Curiously Recurring Template Pattern (CRTP) from C++. Then we spent some time explaining and understanding the CRTP and finally comparing it to similar things like Java’s Enum<E extends Enum<E>>. It can get wicked complex fast with those constructs.

Laser printer identification

Since 2011, we know that every single page of a color laser printer can be individually identified and traced back to your printer. This is common knowledge as stated on Wikipedia, but it still was a surprise to some of us. Why do we need such tracking? On request of many goverments.

Spectre and Meltdown

We didn’t repeat the fresh common knowledge about the nearly universal CPU security vulnaribilities Meltdown and Spectre. But we noted that it got eerily quiet, as if everybody holds their breath and waits for the morning clock to wake them up.

Some rumors has it that the current prototypes of ARM and Intel CPUs are not vulnerable, as if the manufacturers changed their speculative code execution unit long before the exploits came to light. Maybe they circumvented the problem by pure luck?

We hope to hit snooze soon.

Planned obsolescence

We discussed the notion of planned obsolescence. Typical consumer products have a flaw or weakness that is bound to break soon after manufacturer guarantee is void. Or it is deliberately incorporated into the product like page counters, waste tanks with limited capacity or the infamous short-lived light bulb.

A good start on the topic is the documentary “buy it for the waste” or “Kaufen für die Müllhalde” on german.

Given the recent noise around Apple battery life, we are now in an era where planned obsolescence is sold like a feature. Twenty-five years ago, this was Science Fiction. The author of this blog entry remembers a science fiction story by Robert Sheckley (“Utopia mit kleinen Fehlern” or “A Ticket to Tranai” in english). The protagonist reaches a planet that seems to be perfect. It is so perfect that nothing breaks anymore. The industry is desperate and sees the protagonist as a genius when he invents “planned obsolescence” and “designed discomfort” as means to raise sales. The planet has several other flaws as well. The story and the whole book is worthwhile and right on topic.

Book review (again): Clean Architecture

At last, we spoke about Robert C. Martin’s (Uncle Bob’s) new book “Clean Architecture”. I’ve already published my book review on our blog, but added some impressions and context after thinking about the book for some more time. Summary: The book is good, even if nearly half the pages might qualify as filler material and there are only two main messages. If the announcement of Uncle Bob on the last page in the Appendix becomes true, you might want to skip his next book, though.

Another book review for the future might be the new Effective Java, 3rd edition.


As usual, the Dev Brunch contained a lot more chatter and talk than listed here. The number of attendees makes for an unique experience every time. We are looking forward to the next Dev Brunch at the Softwareschneiderei in April. We even have some topics still on the agenda (like a report about first-hand experiences with the programming language Rust). And as always, we are open for guests and future regulars. Just drop us a notice and we’ll invite you over next time.


The fallacy of “the right tool”

Let me start this blog post with a disclaimer: I’m really convinced of the value of multilingual programming and also think that applying the “right tool for the job” is a good thing. But there is a fallacy around this concept in programming that i want to point out here. The fallacy doesn’t invalidate the concept, keep that in mind.

Polyglot cineasts

Let me start with an odd thought: What if there was a movie, a complicated international thriller around a political intrigue, playing in over half a dozen countries. The actors of each country speak their native tongue and no subtitles are provided. Who would be able to follow the plot? Only a chosen few of really polyglot cineasts would ever appreciate the movie. Most of us wouldn’t want to see it.

Polyglot programming

Our last web application project was comprised of that half a dozen languages (Groovy, Java, HTML, CSS, HQL/SQL, Ant). We could easily include more programming languages if we feel the need to do it. Adding Clojure, Scala or Ruby/JRuby doesn’t sound absurd to us. A programmer capable of knowing and switching between numerous programming languages is called a “Polyglot Programmer“.

The main justification for heterogeneous (polyglot) projects often is the concept of “using the right tool for the job”. The job often is a subtask of the whole project, like building the project, accessing the database, implementing the ever-changing business logic. For each subtask, some other language might outshine the competitors. Besides some reasonable doubt concerning the hidden cost of this approach, there is a misconception of the term “tool”.

Programming languages aren’t tools

If you use a tool in (basic or advanced) engineering, let’s say a hammer to drive some nails into a wooden plate or a screwdriver to decompose your computer, you’ll put the tool aside as soon as “the job” is finished. The resulting product (a new wooden cabinet or a collection of circuit boards) doesn’t include the tool. Most of the times, your job is really finished, without “change requests” to the product.

If your tool happens to be a programming language, you’ll produce source code bound to the tool. Without the tool, the product isn’t working at all. If you regard your compiled binaries as “the product”, you can’t deal with “change requests”, a concept that programmers learn early and painful. The product of a programmer obviously is source code. And programming languages don’t act as tools, but as materials in this respect. Tools go away, materials stick.

Programming languages are materials

As source code is tied to its programming language, they form a conceptional union. So I suggest to change the term to “using the right material for the job” when speaking about programming languages. This is a more profound decision to make in comparision to choosing between a Phillips style or a TORX screwdriver. Materials need to outlast when the tools are long put aside.

But there are tools, too

In my web application example above, we used a lot of tools. Grails is our framework of choice, Jetty our web container to deploy to, the Spring Framework provides mighty utilities and we used IDEA to bolt it all together. We could easily exchange Tomcat for Jetty or IDEA with Eclipse without changing the source code (the example doesn’t work that easy for Grails and Spring, though). Tools need to be replaceable or even disposable.


The term “the right tool for the job” cannot easily be applied to programming languages, as they aren’t tools, but materials. This is why polyglot programming is dangerous to when used heavily in a single project. It’s easy to end up with a tangled “amalgam project”.

Two more disclaimers:

  • If chosen right, “composite construction” is a powerful concept that unifies the advantages of two materials instead of adding up their drawbacks.
  • Being multilingual is advantageous for a programmer. Just don’t show it all off in one project.