{"id":1479,"date":"2018-03-14T14:06:32","date_gmt":"2018-03-14T14:06:32","guid":{"rendered":"http:\/\/dlang.org\/blog\/?p=1479"},"modified":"2021-10-08T11:05:10","modified_gmt":"2021-10-08T11:05:10","slug":"user-stories-funkwerk","status":"publish","type":"post","link":"https:\/\/dlang.org\/blog\/2018\/03\/14\/user-stories-funkwerk\/","title":{"rendered":"User Stories: Funkwerk"},"content":{"rendered":"

The deadline for the early-bird registration for DConf 2018 in Munich<\/a> is coming up on March 17th. The price will go up from $340 to $400. If you\u2019d like to go, hurry and sign up to save yourself $60. And remember, the NH Munich Messe hotel, the conference venue, is offering a special deal on single rooms plus breakfast<\/a> for attendees.<\/p>\n

\n

<\/p>\n

A few of the DConf attendees are coming from a local company called Funkwerk<\/a>. They\u2019re a D shop that we\u2019ve highlighted here on this blog in a series of posts<\/a> about their projects (you\u2019ll see one of their products in action<\/a> if you take the subway or local train service in Munich).<\/p>\n

In this post, we cap off the Funkwerk series with the launch of a new feature we creatively call \u201cUser Stories\u201d. Now and again, we\u2019ll publish a post in which D users talk of their experiences with D, not about specific projects, but about the language itself. They\u2019ll tell of things like their favorite features, why they use it, how it has changed the way they write code, or anything they\u2019d like to say that expresses how they feel about programming in D.<\/p>\n

For this inaugural post, we\u2019ve got three programmers from Funkwerk. First up, Michael Schnelle talks about the power of ranges. Next, Ronny Spiegel tells why generated code is better code. Finally, Stefan Rohe enlightens us on Funkwerk\u2019s community outreach.<\/p>\n

The power of ranges<\/h2>\n

Michael Schnelle has been working as a software developer for about 5 years. Before starting with D 3 years ago, he worked in (Web)Application Development, mostly with Java, Ruby on Rails, and C++, and did Thread Modeling for Applications. He enjoys coding in D and likes how it helps programmers write clean code.<\/em><\/p>\n

In my experience, no matter what I am programming, I always end up applying functions to a set of data and filter this set of data. Occasionally I also execute something with side effects in between. Let\u2019s look at a simplified use case: the transformation of a given set of data and filtering for a condition afterwards. I could simply write:<\/p>\n

foreach(element; elements) {\r\n  auto transformed = transform(element);\r\n  if (metCondition(transformed) {\r\n     results ~= transformed\r\n  } \r\n}<\/pre>\n
Using the power from std.algorithm<\/code><\/a>, I can instead write:<\/p>\n
filter!(element => metCondition(element))\r\n       (map!(element => transform(element))(elements));<\/pre>\n
At this point, we have a mixture of functional and object-oriented code, which is quite nice, but still not quite as readable or easy to understand as it could be. Let\u2019s combine it with UFCS (Uniform Function Call Syntax)<\/a>:<\/p>\n
elements.map!(element => element.transform)\r\n        .filter!(element => element.metCondition);<\/pre>\n
I really like this kind of code, because it is clearly self-explanatory. The foreach<\/code> loop, on the other hand, only tells me how it is being done. If I look through our code at Funkwerk, it is almost impossible to find traditional loops.<\/p>\n
But this only takes you one step further. In many cases, there happen to be side effects which need to be executed during the workflow of the program. For this kind of thing, the library provides functions like std.range.tee<\/code><\/a>. Let\u2019s say I want to execute something external with the transformed value before filtering:<\/p>\n
elements\r\n  .map!(element => element.transform)\r\n  .tee!(element => operation(element))\r\n  .filter!(element => element.metCondition)\r\n  .array;<\/pre>\n
It is crucial that operations with side effects are only executed with higher-order functions that are built for that purpose.<\/p>\n
int square(int a) { writefln(\"square value\"); return a*a; }\r\n\r\n[4, 5, 8]\r\n  .map!(a => square(a))\r\n  .tee!(a => writeln(a))\r\n  .array;<\/pre>\n
The code above would print out the square value six times, because tee<\/code> calls range.front<\/code> twice. It is possible to avoid this by using functions like std.algorithm.iteration.cache<\/code><\/a>, but in my opinion, the nice way would be to avoid side effects in functions that are not meant for that.<\/p>\n
In the end, D gives you the possibility to combine the advantages of object-oriented and functional programming, resulting in more readable and maintainable code.<\/p>\n
Generated code is better code<\/h2>\n
Ronny Spiegel has worked as a professional software developer for almost 20 years. He started out using C and C++, but when he joined Funkwerk he really started to love the D language and the tools it provides to introspect code and to automate things at compile time.<\/em><\/p>\n
In a previous blog post<\/a>, I gave a short overview of the evolution of the accessors library. As you might imagine, I really like the idea of using the compiler to generate code; in the end this usually results in less work for me and, as a direct result, causes fewer errors.<\/p>\n
The establishment of coding guidelines is crucial for a team in order to create maintainable software, and so we have them here at Funkwerk. There is a rule that every value object (or entity) has to implement the toString<\/code> method in order to provide diagnostic output. The provided string shall be unambiguous so that it\u2019s more like Python\u2019s __repr__<\/code> than __str__<\/code>.<\/p>\n
Example:<\/p>\n
StationMessage(GeneralMessage(4711, 2017-12-12T10:00:00Z), station=\"BAR\", \u2026)<\/pre>\n
The generated string should follow some conventions:<\/p>\n