!Map:[["42-first-principles",{"subtitle":"A New Year's resolution","title":"42 first principles","abstract":"In 2022 I am turning 42 and therefore I am writing down my 42 first principles.","date":"2022-01-04T00:00:00.000Z","html":"\n

\n In 2022 I am turning 42 and therefore I am writing down my 42\n first principles. This is most likely going to take the\n entire year, and I plan to publish rough drafts on a weekly basis in this blog.\n

\n I want to take the time to get them into a form that is more permanent, and more\n stringent than the list of GitHub issues,\n I've collected already.\n

\n ~~The first principle #1 is not yet on that list, though.~~ I have to start\n with putting these principles into context. They are mine only and not intended\n to be a list of shoulds, and therefore I must talk first about the\n privilege I have to be working in the tech industry\n since 1997, and being able to work in it uninterrupted now in the 25th year.\n

\n You can follow me on Twitter, or if you\n prefer to receive an email,\n shoot me a reminder.\n

First Principles

Privilege
Push to deploy
5 whys
The 20 percent trick to continuously keep learning

\n","slug":"42-first-principles","hero":"!undefined"}],["I-make-euro-101750-in-non-monetary-compensation-a-year",{"title":"I make €101,750 in non-monetary compensation a year","subtitle":"Some thoughs on salary.","abstract":"Salary is probably one of the most dreadful topics, especially because it is a hygiene factor: earning *not enough* money will affect your satisfaction greatly, but earning more than you need won't improve your performance equally strong.\n","date":"2016-12-27T14:00+02:00","html":"\n

\n Salary is probably one of the most dreadful topics, especially because it is a\n hygiene factor: earning not enough money will affect your satisfaction\n greatly, but earning more than you need won't improve your performance equally\n strong.\n

What is enough?

\n Let's talk a little bit about enough: the actual sum that you need to live\n depends on your fixed costs for basics like food, rent and savings for your\n retirement. If you have kids or other relatives to take care of, add this on\n top. Once those are paid you usually spend money on vacation, hobbies, and other\n activities like going to a concert, eating out, etc. Your enough quickly\n amounts to a sum that is already greater than the average salary in Germany\n (roughly €44,000 per year gross). But let's take that sum as enough.\n

\n Of course, I don't want to make what is enough but optimize for what is\nadequate for my position. But how much exactly is that? If we take open salary\n examples from around the world, many feature a market-average base-salary:\n developers are rare, thus they will earn more money than accountants. It is easy\n to get an overview about the typical salary for your market by looking at sites\n like glassdoor; for Germany the salary overview by Robert Half is\n very helpful if your industry is IT.\n

\n Where you are in the range depends on many factors, mostly experience, but even\n greater, your ability to (over-)sell yourself has a big impact on your salary\n especially in Germany, where you rarely find a role which compensation is made\n public in the job offer. The motivation to make compensations an individual\n agreement seems obvious: to save the company money, because they can try to\n negotiate the lowest possible salary for each employee. This is a fallacy,\n though. Studies show that making compensation transparent and comparable\n within an organization, will save money.\n

The gap between enough and adequate is your playing field!

\n It's important to remember: monetary compensation has no benefit, above the\n individual threshold that is perceived to be enough. For organizations that\n hire talent that is in high demand it is important to understand that you need\n to match this threshold. But: the gap between enough and adequate is\n your playing field; you can't keep employees below their enough for a\n sustainable amount of time, but they are flexible in the range above that.\n

\n Organizations can even overcompensate here, and this is what this blog post is\n about. Don't get me wrong, it's not about sugarcoating low salaries by just\n giving them another name. It's about understanding that the money a company\n spends on salary can be spent—in parts—in better ways. For companies this can\n make a big difference, increase your runway (the amount of time until your\n startup goes out of business), hire more talent, invest more in new products,\n etc.\n

I make €101,750 in non-monetary compensation a year

\n There is real money to make, if you find the perks, that really matter (not\n foosball tables and fruit baskets). To give you a concrete example, I compiled\n the list of my non-monetary compensations and assigned a price tag to them.\n

\n | Perk | Price tag (€/year) |\n | ----------------------------------------------------------------------------------- | -----------------: |\n | Shares (real shares, not VESOP) | 20,000 |\n | Work where I want (no commute!) | 10,000 |\n | A job with a purpose (we turn organizations into a place where people love to work) | 10,000 |\n | Awesome team | 10,000 |\n | No estimates | 5,000 |\n | Unlimited vacation | 5,000 |\n | Being my own boss (work self-directed, voluntarily, how and when I want) | 5,000 |\n | No stupid meetings | 5,000 |\n | Working with tech I love | 5,000 |\n | The hardware I want | 3,000 |\n | Conference + Usergroups expenses covered | 2,500 |\n | Getting to meet awesome people | 2,500 |\n | 0% Bureaucracy | 2,500 |\n | No VC-Invest | 2,500 |\n | No stupid KPIs | 2,500 |\n | Customer-driven development | 2,500 |\n | Never wear a suit | 2,000 |\n | No politics | 1,500 |\n | Google Docs | 1,200 |\n | Slack (No more emails) | 1,200 |\n | Transparency | 1,000 |\n | Company Phone Plan | 600 |\n | No time tracking | 500 |\n | Company Credit Card (no questions asked expenses) | 500 |\n | Bahncard 50 | 250 |\n

\n The total of the list above sums up to €101,750 per year in non-monetary\ncompensation! Which makes me a happy man to get a compensation in total which\n is way above the market average for a comparable position.\n

\n The tricky part is, especially when talking to developers: they are\n bird-in-the-hand-people and it will take some effort to have this talk about a\n lower-than-average fixed salary with them. This will greatly affect your hiring,\n especially if you are secretive about your organization. Because no one will\n believe the advertorial speak of a founder because of what I described earlier:\n they expect tactics to reduce salary behind it. A better approach will be to be\n open about your culture and encourage your employees to evangelize working at\n your company. See? Openness and transparency, they are key for the next\n generation of organizations.\n

\n Yes, some of the perks listed above are real spendings for the company, but the\n net-worth of an Euro spent there is €1 compared to an Euro spent with my net\n salary will equal roughly €0.49. So in the end, both the company and me will\n benefit greatly from having this discussion.\n

\n","slug":"I-make-euro-101750-in-non-monetary-compensation-a-year","hero":"!undefined"}],["advent-of-code-2020",{"subtitle":"End-of-year code katas","title":"Advent of Code 2020","abstract":"I am participating in AOC again","date":"2020-12-07T08:00:00.000Z","html":"\n

\n For the third year now I am participating in\n Advent of Code, which provides a daily programming\n challenge with increasing difficulty.\n

\n I am publishing my solutions written in TypeScript and following TDD\n on GitHub.\n

\n","slug":"advent-of-code-2020","hero":"!undefined"}],["agile-cologne-xxl-2016",{"title":"Agile as a starter for organizational transformation?","abstract":"Impressions from the Agile Cologne XXL 2016","date":"2016-10-03T18:00:00.000Z","html":"\n

\n I was a first-timer at this years Agile Cologne XXL, a two-day open-space\n dedicated to the exchange about the Agile Movement. Needless to say I was\n not sure, what to expect, given that I didn't know anybody from the roughly 80\n attendees. But it turned out to be a very well organized event and I had two\n great days, learning and sharing in an open-space format (you can find the\n session plans here: Sunday, Monday). Most of the attendees were\n either scrum masters, product owners or consultants that teach people how to\n fill this roles. Tech people were rather underrepresented, which actually is a\n good thing: I find getting to know other perspectives to be very helpful in your\n day to day work. Especially we as developers are notoriously sticking to \"our\n people\" … if we leave our workplace at all.\n

Agile as a starter for organizational transformation?

\n Now for the part that kept me busy during these two days; a lot of the sessions\n dealt with variants of this question:\n

\n
\n How can my team and I work in an agile fashion, while the rest of my\n organisation is not agile?\n
\n

\n The experience of many attendees is, that many companies are running their agile\n projects mainly for two reasons that are driven by management\n

increase the output of IT projects,
make more profit.

\n Oftentimes it seems to be a decision based on hearsay (\"We've heard about this\nnew thing, that everyone else does, so lets do it, too!\"). Improving\n product quality and customer satisfactions rarely are the driving factors nor is\n improving the working conditions for employees.\n

\n The missing understanding of the core values behind the agile movement and the\n disposition as experiments obviously leads to a lot of friction and conflicts\n between the agile teams and the rest of the company and puts these teams under\n extra pressure. Now they are not only quested with the success of the project\n using a new way to work with which they have no experience but with leading the\n implementing agile within the whole organization.\n

\n These endeavors are bound to fail and the failure will be attributed to\n shortcomings of the agile methodology and not to the inability of classical,\n hierarchical structures to support agile teams at all.\n

\n To ask for advice how to make these agile teams or projects \"work\" in these\n circumstances is one option, but that does not fix the root cause of the\n problem: the organization itself.\n

\n Network organizations are an enabler for agility, self-organisation and creates\n a focus on delivering customer value. These are environments in which agile\n teams can thrive and will be successful.\n

\n So I set out and collected problems agile teams face in order to show, that\n there are indeed solutions to these problem, but they usually are not that\n obvious and need to be applied at a different level in order to become\n effective.\n

\n You can find the long list here, and I'm sure it can easily be extended\n even further. After I had this material, I used the evening in the hotel to\n compile our tools and measures of choice we use to fix these problems. I wanted\n to show, that there is a solution to every single problem. It might not be\n simple, but we've done it in the past. This flipchart gives you an\n idea. \"Unfortunately\" we had a very lively discussion, so the note-taking-part\n on my side came a little short but I was able to show a fix for every problem,\n and I might go into some of them in the comments, if you are interested.\n

Agile is a seed, and seeds need a soil

\n My takeaway from the conference is that agile practitioners need to identify the\n root causes for the problems and stop trying to handle the symptoms.\n

\n You can't just plant an agile project into your organization without providing\n the grounds for it to grow roots.\n

\n","slug":"agile-cologne-xxl-2016","hero":"!undefined"}],["alle-iso-dateien-in-einem-verzeichnis-nach-utf-8-konvertieren",{"title":"Alle ISO-Dateien in einem Verzeichnis nach UTF-8 konvertieren","abstract":"Dieses Bash-Script konvertiert alle Nicht-UTF-8-Dateien in einem Verzeichnis und in allen Unterverzeichnissen nach UTF-8.","date":"2010-05-13T00:00:00.000Z","lang":"de","html":"\n

\n Dieses Bash-Script konvertiert alle Nicht-UTF-8-Dateien in einem Verzeichnis und\n in allen Unterverzeichnissen nach UTF-8.\n

find ./ -type f -name \"*.php\" \\\n  | xargs file \\\n  | grep ISO-8859 \\\n  | awk '{print substr( $1, 0, length($1) - 1); }' \\\n  | xargs -i recode ISO-8859-1..UTF-8 {}\n

\n","slug":"alle-iso-dateien-in-einem-verzeichnis-nach-utf-8-konvertieren","hero":"!undefined"}],["an-everyone-culture",{"title":"An Everyone Culture","abstract":"Book review of An Everyone Culture by Robert Kegan and Lisa Laskow Lahey\n","date":"2016-09-10T16:00:00.000Z","html":"\n

\n In An Everyone Culture the authors Robert Kegan and Lisa Laskow Lahey\n explore Deliberately Developmental Organizations (DDOs).\n

\n In these organizations adult development is part of the core business model:\n they don't invest into the personal development of their employees because they\n must but because they believe that there is a fundamental different concept of\n the employee: they are part of the organization with all their warts. The idea\n is: in many organizations a lot of effort is invested into appearing to be\n perfect or flawless, to cover up ones insecurities and to cover for others\n insecurities (\"I let you get through with this because you will do the same\n for me on another occasion\"). The authors call this having a second, unpaid\njob. How organizations where able to eliminite this second, unpaid job by\n bringing your full self to work in order to work on your shortcomings on company\n time is explained with a lot of real-life examples.\n

\n You get to look inside three organizations from completely different industries:\n movie-theaters / real estate, hedge fund managament, and IT. You get to\n experience working in such an environment basically from a first person view and\n are taken directly into real situations. All have one astounding similarity in\n common: these organizations have created a safe environment to be yourself and\n be open about your problems. They go even so far to make them publically\n available for everyone in the organization to look up. And this is the crucial\n part: creating a nurturing and helpful environment is not easy to build, and it\n changes the understanding of what being at work means so radically, that it\n does not fit everybody. Constantly working on yourself, personally and\n professionally, is nothing everybody is able to do. But the results are\n fascinating; they are only postive in this book, though.\n

\n The second important concept in the book is the removal of professional\n seniority. The idea that one can keep working in your job basically forever is\n discarded. Which makes perfectly sense today because of two things: no job role\n will be there forever and not change, things you've learned two years ago are\n soon outdated. But more important the longer you do a job the less creative and\n open you are for new and better ideas and change. In DDOs, as soon as you master\n your current role you are rotated to a coaching role for this position and after\n that assigned to a new role where you start over as a newbie. And this is true\n for every job in those organizations not only for those employees that want to\n work like this anyway. This creates a constant influx of new ideas in all parts\n of the organization and enabled the three examples in the book to become\n respected industry leaders.\n

\n I've taken away a lot of new ideas about how organizations can be run, and\n learned how attractive personal development in the context of your organization\n can be and that the benefits are bigger then I would have estimated.\n

\n This book is also a great example for the saying \"Culture eats strategy for\n breakfast\": no strategy can deal with crisis like a team where everybody knows\n everyones shortcomings and how to work with them.\n

Highly recommended!

\n","slug":"an-everyone-culture","hero":"!undefined"}],["ant-build-commons-von-qafoo",{"title":"Ant Build Commons von qafoo","abstract":"Die qafoo GmbH aus Gelsenkirchen, ein Zusammenschluss von vier deutschen PHP-Experten liefert mit den Ant Build Commons einen Standard-Satz an Build-Task für Ant, die alle wichtigen Aufgaben zum Prüfen, Testen und Veröffentlichen in PHP-basierten Projekten abdecken.","date":"2012-09-14T00:00:00.000Z","lang":"de","html":"\n

\n Die qafoo GmbH aus Gelsenkirchen, ein Zusammenschluss von vier deutschen\nPHP-Experten liefert mit den Ant Build Commons einen Standard-Satz an\n Build-Task für Ant, die alle wichtigen Aufgaben zum Prüfen, Testen und\n Veröffentlichen in PHP-basierten Projekten abdecken.\n

\n
\n ABC (Ant Build Commons) aims to provide standard build tasks for web based\n projects. It started by supporting various different PHP related tools, but by\n now also support JavaScript and CSS related tools. This involves tools for\n verification, testing, static analysis, packaging, deployment and more.\n
\n

\n Sie liefern so eine einfach anpassbare Vorlage, um der Software-Qualität im\n eigenen Projekt einfach auf die Sprünge zu helfen.\n

Ausführliche Infos finden sich unter
http://abc.tools.qafoo.com/.

Der Quellcode des Projekts findet sich auf GitHub unter
https://github.com/Qafoo/build-commons.

\n","slug":"ant-build-commons-von-qafoo","hero":"!undefined"}],["auslastung-januar-2012-update",{"title":"Auslastung Januar 2012 Update","date":"2012-01-02T00:00:00.000Z","html":" $\"Auslastung\"$ \n

Über die Feiertage habe ich Auslastung um einige Funktionen erweitert.

Die wichtigsten Änderungen im Überlick:

\n Es gibt nun eine übergeordnete Spalte für Termine und Feiertage (#6 und\n #42)\n
Aufgaben können als \"im HomeOffice\" markiert werden (#43).
\n Namen von Personen, Units und Disziplinen müssen nicht mehr mindestens 3\n Buchstaben lang sein (#38).\n
Pläne mit vielen Daten laden jetzt auch (#31).

Die Liste aller Änderungen findet sich in der Timeline.

\n Eine vollwertige Test-Version der Anwendung findet sich unter\n http://auslastung.coderbyheart.de/.\n

Screenshots? Gerne.

\n","slug":"auslastung-januar-2012-update","hero":"!undefined"}],["auszeichnung-zum-top-coder-erhalten",{"title":"Auszeichnung zum Top Coder erhalten","abstract":"Beim Top Coder Gewinnspiel der Mayflower GmbH habe ich mit meiner Einreichung den ersten Preis gewonnen: ein iPad 2.\n","date":"2011-08-04T00:00:00.000Z","html":"

\n Top Coder Gewinnspiel der Mayflower GmbH habe ich mit meiner Einreichung\n den ersten Preis gewonnen: ein iPad 2.\n

Für das Gewinnspiel mussten drei Aufgaben erfüllt werden:

\n Gesucht wurde ein SQL-Query mit dem die Anzahl der P und H in einem String\n ermittelt werden kann.\n
\n Gesucht wurde eine Funktion, die aus einem gegebenen String durch\n vertauschen, hinzufügen und entfernen von Zeichen den Namen einer\n PHP-Funktion ermittelt.\n
\n Gesucht wurde die Größe eines MySQL-Indexes, wenn statt Bytes Trytes\n verwendet werden.\n

\n","slug":"auszeichnung-zum-top-coder-erhalten","hero":"!undefined"}],["autoload-environment-variables",{"title":"Autoload environment variables","abstract":"When developing stateless microservices it can be tedious to set up the correct environment variables. You can teach your bash/zsh to load them on a per directory basis.","date":"2016-04-07T00:00:00.000Z","html":"\n

\n When developing stateless microservices it can be tedious to set up the correct\n environment variables. You can teach your bash/zsh to load them on a per\n directory basis.\n

\n If you add this to your .bashrc or .zshrc.local environment variables will\n be set from a file called .env if it is present in the directory you are\n cd-ing into:\n

function readEnv\n{\n        if [ -f $PWD/.env ]\n        then\n                cat $PWD/.env\n                export $(cat $PWD/.env | xargs)\n        fi\n}\n\ncd()\n{\n        builtin cd \"$@\"\n        readEnv\n}\nreadEnv\n

In my project directory I have a .env file with these contents:

export MY_FOO_ENV=bar\necho MY_FOO_ENV=$MY_FOO_ENV\n

Now everytime I run my project the correct environment is set.

\n","slug":"autoload-environment-variables","hero":"!undefined"}],["automagically-version-javascript-libraries-with-semantic-release",{"title":"Versioning JavaScript libraries with semantic-release","subtitle":"Automation","abstract":"In this post I will explain how you can automate releasing of your JavaScript libraries to npm.","date":"2018-08-07T16:00+02:00","html":"\n

\n We use semantic-release\n to automatically determine the next version of a library and release it to\n our npm organization.\n

\n The next version is determined by scanning the commit messages. They must follow\n the Angular commit message rules,\n and in every library a hook will\n check commit messages against these rules.\n

\n
\n ⚠️ The package.json of a project should only contain 0.0.0-development as\n the version property, semantic-release will ignore the value.
⚠️ Only the published package on npm will contain the correct version number.\n
\n

How to release a new version of a package

Let's assume we have a library, which has the npm version 2.3.4.

\n A new version will be publish by the respective project's CI run. All you have\n to do is to use commit messages that follow the\n schema describe here.\n

There are three commit messages that will trigger a release:

Patch release:

fix: <commit message>\n

Feature release:

feat: <commit message>\n

Breaking Release:

<scope>: <commit message>\n\nBREAKING CHANGE:\n\n<description of breaking change>\n

⚠️ Note that any other commit message format will not trigger a release.

Patch release 🐞 (`fix`) `2.3.4 -> 2.3.5`

\n 👉 A fix is a change to the implementation which removes a bug without\nchanging the public API (method names and signatures, exports) of the library.\n The consumer of the library must not need to change their implementation when\n installing the fixed version.\n

\n $\"Oopsie\"$ \n

\n To release a fix (which will update the version from 2.3.4 to 2.3.5, use the\n type fix in the commit message:\n

fix: <commit message>\n

\n You can optionally add a scope, which is a lowercase string used to identify the\n affected component.\n

fix(<scope>): <commit message>\n

Scopes are useful when the project is rather big.

Feature release 🚀 (`feat`) `2.3.4 -> 2.4.0`

\n 👉 A feature is a change to the implementation of a library which adds\n additional functionality without changing the public API of the library. You\n may add new exports, methods and even extra, optional method arguments, but the\n consumer of the library must not need to change their implementation when\n installing the library with the new feature.\n

\n $\"Yeah\"$ \n

\n To release a feature (which will update the version from 2.3.4 to 2.4.0, use\n the type feat in the commit message:\n

feat: <commit message>\n

You can optionally add a scope as well.

Breaking Release 🚨 (`BREAKING CHANGE:`) `2.3.4 -> 3.0.0`

\n 👉 Every time the public API of the library changes in a way that requires the\n consumer to update their implementation you must mark the change as\nbreaking. This can happen if method names and arguments are renamed,\n previously optional arguments become required, arguments get removed, classes\n get renamed. Even if the change is very small, as soon as you are breaking the\n library's contract (it's public API) it is considered a breaking change,\n according to semver.\n

\n $\"Boom\"$ \n

\n To release a breaking release (which will update the version from 2.3.4 to\n 3.0.0, use the text BREAKING CHANGE: (followed by a space of two new-lines)\n in the commit message:\n

refactor: <commit message>\n\nBREAKING CHANGE:\n\n<description of breaking change>\n

You can optionally add a scope as well.

\n Not that in the case of a breaking release the message type (here refactor)\n can be any valid type.\n

Typical changes

Updated dependencies

\n If you are manually updating dependencies in a library, you should commit the\n change as a fix, so that consumers are also using the updated dependencies.\n

Refactoring

\n If you do a pure refactoring of a library without changing the features and the\n public API but want to use the refactored version in your consumers, commit\n the refactoring as a feature. After all, you are improving the library which\n qualifies as a feature, e.g. it could be a performance-improvement.\n

How releases are published

\n After you have pushed your changes to the remote repository, a job will be run\n on the CI runner. If the job completes successfully (e.g. if all tests pass and\n the linter does not report any errors), semantic-release will determine the\n next version to be released.\n

\n The \"highest\" commit will win (fix > feat > breaking change). This\n means if the list of commit messages since the last release contains only\n fixes, the patch version will be incremented (2.3.4 -> 2.3.5). If the list of\n commits contains at least one new feature, then the minor version will be\n incremented and the patch version will be set to 0 (2.3.4 -> 2.4.0). If the\n list of commits contains at least one breaking change, then the major version\n will be incremented and the minor and patch versions will be set to 0\n (2.3.4 -> 3.0.0).\n

\n This new version will be written to the package.json and the package will be\n published to the npm registry.\n

Happy releasing!

\n $\"Lift$ \n

\n","slug":"automagically-version-javascript-libraries-with-semantic-release","hero":"!undefined"}],["aws-sdk-v3",{"subtitle":"Cloud Native","title":"Migrating to AWS SDK v3 for JavaScript","abstract":"Notes on migrating Bifravst to the completely rewritten AWS SDK for JavaScript/TypeScript","date":"2021-01-05T16:00:00.000Z","html":"\n

\n AWS recently\n announced the general availability\n of the\n version 3 of their SDK for JavaScript.\n

The most notable changes are

\n the switch to providing modular packages: this allows to reduce the overall\n size of the dependencies and makes bundling, for example for web applications,\n faster,\n
first-class Promise support: the infamous .promise() is no more,
\n first-class TypeScript support: the SDK has now been written in TypeScript, so\n the definitions (which are maintained in\n DefinitlyTyped for\n version 2 of the SDK) will not longer lag behind,\n
a new middleware stack that improves debuggability,
\n the ability to abort pending requests\n which is especially interesting for web applications.\n

\n In this blog post I will summarize my findings when migrating the AWS flavour of\n Bifravst to version 3 of the AWS SDK.\n

Command is the new method

\n Instead of calling methods on the client instance directly, e.g.\n s3.putObject().promise(), in v3 the client's send() method has to be called\n with an instance of a command for the operation:\n s3.send(new PutObjectCommand()).\n

So the general pattern to migrate to v3 is:

- service.operation()\n+ service.send(new OperationCommand({}))\n

\n This worked in without issues in most cases. The arguments for the command class\n stay the same. Operations without arguments need to get passed an empty object\n ({}).\n

Constructing a client

\n Client instances are constructed as before using new.
You always need to pass an object to the constructor, even if not providing any\n configuration.\n

const iot = new IoTClient({});\n

Calling an operation

Operations are now called by sending a command:

const { things } = await iot.send(new ListThingsCommand({}));\n

\n Here, again, you always need to pass an object to the constructor of the\n command, even if not providing any parameters to the operation.\n

A complete example:

- import { Iot } from 'aws-sdk'\n+ import {\n+ \tIoTClient,\n+ \tListThingsCommand,\n+ } from '@aws-sdk/client-iot'\n\n- const iot = new Iot()\n+ const iot = new IoTClient({})\n\n- const { things } = await iot.listThings().promise()\n+ const { things } = await iot.send(new ListThingsCommand({}))\n

Updating imports

\n Instead of pulling the dependency from\n aws-sdk, find the needed client\n package in the\n API reference for the v3 SDK,\n in the case above we need the\n @aws-sdk/client-iot.\n

\n
Note: IoT now has a capital T at the end.
\n

\n The IotData client from v2 is now located in\n @aws-sdk/client-iot-data-plane\n and called IoTDataPlaneClient.\n

IoT: Payload is now `Uint8Array`

\n Some operations, like DescribeThingShadowCommand\n return a JSON string now as Uint8Array.\n These need to be decoded using the TextEncoder util in Node.js:\n

+ import { TextDecoder } from 'util'\n\n- const { statusCode, body } = JSON.parse(Payload?.toString() ?? '')\n+ const { statusCode, body } = JSON.parse(\n+   new TextDecoder('utf-8').decode(Payload),\n+ )\n

\n or the\n @aws-sdk/util-utf8-browser\n helpers for browser applications:\n

+ import { toUtf8 } from '@aws-sdk/util-utf8-browser'\n\n- const { statusCode, body } = JSON.parse(Payload?.toString() ?? '')\n+ const { statusCode, body } = JSON.parse(toUtf8(Payload?.toString() ?? ''))\n

Not in v3: StepFunctions

\n The StepFunctions client has not been ported to v3 because the service\n does not support CORS,\n because browsers cannot interact with it.\n

S3

createPresignedPost

S3.createPresignedPost() is now in @aws-sdk/s3-presigned-post

- import { S3 } from 'aws-sdk'\n+ import { S3Client } from '@aws-sdk/client-s3'\n+ import { createPresignedPost } from '@aws-sdk/s3-presigned-post'\n+ import { CreateJobCommand, IoTClient } from '@aws-sdk/client-iot'\n\n- const s3 = new S3()\n+ const s3 = new S3Client({})\n\n- const { url, fields } = s3.createPresignedPost({\n-   Bucket: bucketName,\n-   Fields: {\n-     key: `${jobId}.json`,\n-   },\n- })\n+ const { url, fields } = await createPresignedPost(s3, {\n+   Bucket: bucketName,\n+   Key: `${jobId}.json`,\n+ })\n

\n
Note: It was made async and the Key field needs to be at the top level.
\n

SignatureDoesNotMatch error when uploading a file

\n There is currently a bug\n when uploading a file with a custom content-type. The workaround is to\n add a custom middleware that removes the extra header:\n

s3.middlewareStack.add(\n  (next) => async (args) => {\n    delete args.request.headers[\"content-type\"];\n    return next(args);\n  },\n  { step: \"build\" },\n);\n\nawait s3.putObject({\n  Bucket: bucket,\n  Key: key,\n  Body: body,\n  ContentType: contentType,\n});\n

Custom signed HTTP requests

\n In case you need to construct your own signed requests, the AWS.Signers.V4\n have also been moved:\n

- import * as AWS from 'aws-sdk'\n- import { Credentials, Endpoint, HttpRequest } from 'aws-sdk'\n+ import { SignatureV4 } from '@aws-sdk/signature-v4'\n+ import { Credentials, Endpoint } from '@aws-sdk/types'\n+ import { HttpRequest } from '@aws-sdk/protocol-http'\n+ import { parse } from 'url'\n

Credentials now longer have a class, but a type:

- const credentials = new Credentials(AccessKeyId, SecretKey, SessionToken)\n+ const credentials: Credentials = {\n+\t  accessKeyId,\n+\t  secretAccessKey,\n+\t  sessionToken,\n+ }\n

Also the Endpoint class has been removed, so some URL parsing is nedded.

-\tconst httpRequest = new HttpRequest(new Endpoint(endpoint), region)\n+\tconst httpRequest = new HttpRequest(\n+\t\t((p: ReturnType<typeof parse>): Endpoint =>\n+\t\t\t({\n+\t\t\t\t...p,\n+\t\t\t\tport: p.port !== null ? parseInt(p.port, 10) : undefined,\n+\t\t\t} as Endpoint))(parse(endpoint)),\n+\t)\n

Finally a signer can be created:

-\tconst signer = new AWS.Signers.V4(httpRequest, 'appsync', true)\n+\tconst signer = new SignatureV4(httpRequest, 'appsync', true)\n

Removed types

\n Some types have been removed or better, replaced with their idiomatic TypeScript\n equivalent.\n

\n For example in the Timestream client, previously there was a\n type Records = Record[], which now no longer exists:\n

- import { TimestreamWrite } from 'aws-sdk'\n+ import { _Record } from '@aws-sdk/client-timestream-write'\n\n-\treturn Records.filter(isNotNullOrUndefined) as TimestreamWrite.Records\n+\treturn Records.filter(isNotNullOrUndefined) as _Record[]\n

\n This needs a little bit of digging through the TypeScript definitions to figure\n out which types still exist and which need to be replaced.\n

\n The migration was relatively straight forward and because of the BDD tests in\n the project this refactoring could be done without a hassle. I will keep\n updating this post in case there are more noteworthy findings.\n

\n","slug":"aws-sdk-v3","hero":"!undefined"}],["backend-languages-panel-at-code-talks-hamburg-2018",{"title":"Backend languages panel at code.talks Hamburg 2018","subtitle":"Panel","abstract":"Extracts of a panel on backend languages at code.talks Hamburg 2018.","date":"2018-11-18T13:00+01:00","html":"\n

\n At code.talks Hamburg 2018 I was in the panel about\n backend languages.\n

https://twitter.coderbyheart.com/status/1053254437026914304

You can see the whole session on YouTube:

https://www.youtube.com/embed/7n3ROn3yABY

\n Here are the sections where I speak on behalf of the language that I love:\n JavaScript!\n

https://twitter.coderbyheart.com/status/1064131345058856961

Where will JavaScript be in 5 years?

https://twitter.coderbyheart.com/status/1064131350767288321

And will JavaScript still be there in 5 years?

https://twitter.coderbyheart.com/status/1064131358879031296

Does JavaScript scale both in the technical sense and within teams?

https://twitter.coderbyheart.com/status/1064131366416195584

Is JavaScript a good language for programming beginners?

https://twitter.coderbyheart.com/status/1064131378634268672

\n Check out CodeDoor - they help people from\n underrepresented groups learn to program!\n

Not everything is perfect with JavaScript

https://twitter.coderbyheart.com/status/1064131386318176257

\n","slug":"backend-languages-panel-at-code-talks-hamburg-2018","hero":"!undefined"}],["backup-your-business",{"title":"Backup your business: Advice for non-technical co-founders","abstract":"How to make sure you never lose the source code of your business.\n","date":"2015-03-07T22:30:00.000Z","html":"\n

\n Software is an amazing thing: a few thousand lines of text can power an entire\n business. One thing should be obvious: make sure you never lose the source code\n of your business. This is something your technical co-founder will take care of\n from day one. And that creates a problem that I want to shed some light on.\n

\n Making proper backups of software is a complicated task. And it usually involves\n setting up tools and processes that are created with developers in mind. It\n involves things like encryption, off-site copies, grandfathers, fathers and\n sons.\n

\n If one day you and your technical co-founder part ways in a bad way, you will\n find it impossible to get hold of a copy of your companies most valuable asset\n that can be used to keep operating your business with another partner.\n

\n You can prepare for this unlikely event, though. Do it in the beginning of your\n business and your technical co-founder will happily assist you in setting this\n up. He gets another level of safety and if you are not in an evil mindset there\n is no real argument why not to constantly ensure every co-founder of a business\n has unlimited access to a copy of the current source code.\n

\n Your mileage may vary but here are some practical ideas how to set up an easy to\n use system:\n

\n If you can, open-source your software and put it on GitHub. Make sure that\n this is your primary source code repository used by the development team to\n ensure it's up to date all the time.\n
\n Have a daily ZIP archive of all your source code on a backup server. Make sure\n that this server is rented by your company not by your co-founder or his\n buddies. If you don't mind third-parties snooping through your files, use\n Google Drive, Dropbox or Amazon S3 for the backup. Then make daily backups of\n the files there to storage devices that only you have access to (flashdisk,\n external hard drives or your laptop).\n

\n Trust but verify: Let a tech-savvy friend you trust verify the backups you\n have once in a while to get the extra certainty that you can't be left out in\n the cold.\n

\n Photo credits:\n Five Days' Backup by\n daryl_mitchell (CC BY-SA 2.0)\n

\n","slug":"backup-your-business","hero":"!undefined"}],["bash-absoluten-pfad-des-aktuellen-scripts-auslesen",{"title":"Bash: Absoluten Pfad des aktuellen Scripts auslesen","abstract":"Oft ruft man Bash-Scripte ja mit relativen Pfaden auf:","date":"2010-06-18T00:00:00.000Z","lang":"de","html":"\n

Oft ruft man Bash-Scripte ja mit relativen Pfaden auf:

$ ./util.sh\n

\n Dieses kleine Snippet liefert einem in diesem Fall den absoluten Pfad zum\n aktuellen Script.\n

#!/bin/bash\nMYDIR=\"`cd $0; pwd`\"\necho $MYDIR\n

\n Möchte man den absoluten Pfad zu einem Verzeichnis weiter oben, nimmt man dieses\n Snippet:\n

#!/bin/bash\nMYDIR=`dirname $0`\nPARENT=\"`cd $MYDIR/../; pwd`\"\n

\n","slug":"bash-absoluten-pfad-des-aktuellen-scripts-auslesen","hero":"!undefined"}],["bash-bestimmte-dateien-oder-verzeichne-beim-auto-vervollstandigen-ignorieren",{"title":"Bash: Bestimmte Dateien oder Verzeichnisse beim Auto-Vervollständigen ignorieren","abstract":"Die Bash hat eine tolle Funktion: Mittels der Tab-Taste erhält man eine Liste mit Dateien und Verzeichnissem im aktuell eingegeben Pfad-Abschnitt.\n","date":"2010-09-28T00:00:00.000Z","html":"\n

\n Die Bash hat eine tolle Funktion: Mittels der Tab-Taste erhält man eine Liste\n mit Dateien und Verzeichnissem im aktuell eingegeben Pfad-Abschnitt.\n

\n Allerdings nerven da z.B. Verzeichnisse wie .svn von Subversion, in die man\n normalerweise nie hinein navigieren möchte.\n

Zu Hilfe kommt da die Umgebungsvariable FIGNORE.

\n
\n A colon-separated list of suffixes to ignore when performing filename\n completion (see READLINE below). A filename whose suffix matches one of the\n entries in FIGNORE is excluded from the list of matched filenames. A sample\n value is .o:~.\n
\n

\n Ein praktischer Eintrag für Subversion ist dementsprechend: .svn. Unter Mac OS\n bietet sich noch an, .DS_Store hinzu zu nehmen.\n

Diese Zeile wird dann in der Datei ˜/.profile oder ähnlich eingetragen:

export FIGNORE=\".svn:.DS_Store\"

\n","slug":"bash-bestimmte-dateien-oder-verzeichne-beim-auto-vervollstandigen-ignorieren","hero":"!undefined"}],["bdd-book-formulation-review",{"title":"The BDD Books: Formulation","subtitle":"Book Review","abstract":"An indepth guide for software teams to engage all stakeholders in creating up-to-date documentation that drives tests","date":"2021-04-22T23:00+01:00","html":"\n

\n Let me start by stating something most of you most likely know, I am a big fan\n of Behavioural Driven Design (BDD),\n I have spoken about it at multiple conferences\n and I use it on a daily basis. Therefore I was really excited to learn from\n Gáspár and Seb\n who are without a doubt some of the most knowledgeable people to write about\n this topic ... which they are not shy to tell you directly in the beginning of\n the book:\n

\n
\n Together Seb and Gáspár have over 60 years of software experience which they\n put to good use developing and delivering training and coaching for\n organizations worldwide.\n
\n

\n It's a somewhat bold disclaimer in the beginning of the book, and I wish they\n wouldn't have chosen this \"let me tell you...\" move, because the content in this\n book really speaks for itself.\n

The Book to understand the toolset Gherkin provides

\n Gherkin is a language to describe behaviour\n of any system in feature files with three words: Given, When,\n Then. There, now you have learned the language, however it takes a lot of\n practice to apply this tool in practice. And here is where the book takes us on\n a journey with a team implementing a pizza ordering software.\n

\n Along this example we learn the fundamentals of the language, and many hands-on,\n very well explained best practice on how to use Gherkin to not only describe the\n properties of the software system, but also how to do it in a way that enables\n all stakeholder to take part and in such a way that it creates a living\ndocumentation; one that never is outdated.\n

\n This promise is magically and the authors manage to lift the curtain and share\n their years of experience with this tool.\n

BDD is reverse decoupled TDD

\n
Start with the end in mind.
\n

\n As with test-driven-development (TDD), BDD is ideally written before the\n implementation, and this is one of the big take-aways for me: where I would TDD\n with small examples working towards a complete feature, BDD works best if the\n end-result is written first: if the Then ... is defined first, it is easier to\n focus only on the absolute necessary Givens and Whens—a point that the\n books stresses at multiple occasions: focus on keeping scenarios brief (or\n BRIEF, the acronym that is used in the book).\n

BDD is for everyone, and any time

\n You should pick up this book today and learn about this tool, because it can be\n introduced in a project at any time: a chapter about legacy code is included.\n

\n I especially liked their description of how feature files can serve different\n audiences and pick them up where they need the documentation to be, for example\n using a different domain language, or (how I typically use BDD) on a lower\n level, without implementing steps but driving an API client.\n

\n While most of the book centers around writing feature files that can be used to\n drive automation tests, the author specifically mention the importance of\n testers and their expertise, because it is not about automating tests, but about\n aligning all stakeholders and the software that is getting build:\n

\n
\n Never underestimate the domain knowledge of the people who worked on the\n project. Testers in particular will have acquired a deep understanding of the\n product through their time spent testing it.\n
\n

When I read The BDD Books: Formulation
Then I become a better Software Crafter

\n I really like the overall structure of the book, the chapters are not too long\n and don't overstretch their topic. Throughout the book the authors provide their\n personal view which helps to underline important aspects. It will be a good\n source to revisit again and again.\n

\n The BDD Books: Formulation is available\n on LeanPub and\n on Amazon.\n

\n I've read the Kindle version of the book which I would not fully recommend\n because even the smallest font size would not fit the feature listings on my\n screen (a 10th generation Kindle Paperwhite). This is fine if you are familier\n with the Gherkin syntax and can skim the feature definitions. I would recommend\n to read the PDF version which has a better layout, or get the printed version\n (from the PDF).\n

\n","slug":"bdd-book-formulation-review","hero":"!undefined"}],["become-a-certified-software-craftsperson",{"title":"Become a Certified Software Craftsperson","subtitle":"One weird trick","abstract":"Follow this one weird trick to become a Certified Software Crafter","date":"2018-04-28T20:30+02:00","html":"\n

Here is a question for you to think about:

\n
How can I make a better job tomorrow?
\n

\n Congratulations, I hereby certify you to be a full-fledged, badass Software\n Craftsperson. You are welcome! *\n

\n Do not let book authors, speakers, consultancies or anybody tell you which steps\n are required to be considered a true Software Crafter. It usually involves\n giving them money as the first step, so I would call them biased.\n

\n * Quite literally: we welcome everybody to join\n our community Slack, regardless of\n profession, experience, skin color, gender, or other attributes because we\n believe that only diversity will help us to find the best solutions to the big\n and small problems we are lucky to be facing every day.\n

\n","slug":"become-a-certified-software-craftsperson","hero":"!undefined"}],["boosterconf-2023",{"title":"BoosterConf 2023","subtitle":"Conferences","abstract":"A review of BoosterConf 2023 in Bergen","date":"2023-04-07T14:00+01:00","html":"\n

\n Last year was the first time for me attending\n BoosterConf and I was happy to re-visit it again this\n year.\n

\n Around 400 participants gather in one of Norway's most beautiful cities:\n Bergen. During three conference days, the\n BoosterConf program offers keynotes, lightning talks, experience reports,\n workshops and even an OpenSpace during one afternoon. The program is very\n varied, and offers content and inspiration for the entire team. That is also the\n reason why the audience was a good mixture of all roles involved in digital\n projects.\n

\n The agenda offers a nice pacing and long enough breaks so there is time to\n connect with other attendees and reflect on what was just heard.\n

\n I really liked the opportunity to discuss relevant topics with participants\n during the open space, which this year was 3 hours long without any program at\n the side, so there was no distraction. I wished the OpenSpace was however split\n in multiple rooms and not run as multiple chair circle in the big hall.\n

\n The conference has already published the video recordings on\n Vimeo, so you can get yourself an impression of\n the talks. However, the workshops and the OpenSpace was not recorded.\n

\n Lisi has also written about her impressions on her blog:\n Lisi Hocke: Booster Conference 2023 - Changing Perspectives.\n

\n Here are the sessions that I attended; I shared them live on Mastodon using the\n hashtag #BoosterConf.\n

Day 1

https://chaos.social/@coderbyheart/110105299932319333/embed

https://chaos.social/@coderbyheart/110105348296102607/embed

Opening keynote

https://chaos.social/@coderbyheart/110105403371093294/embed

\n The #BoosterConf opening keynote is by\n Anne Landro, a Norwegian service\n designer, and she talks about how to build innovative solutions that people\n really want (however they won't honestly tell you).\n

\n She gave us a quick assignment: talk to each other 2 minutes about a specific\n time when you were showering.\n

\n Very interesting to see how few managed very essential things like: were you wet\n when you left the shower, were you dry when you entered?\n

That shows that users, when interviewing them, can't share many important facts.

\n Users are too used to the (suboptimal) processes that they are using, they can't\n see the problems with it.\n

\n In order to find good solutions we need to dig deep into the problem and resist\n the urge to jump to the immediate, obvious solution.\n

\n But just talking is not enough, and getting to the true needs of a user is\n challenging, because users are often not honest about their true needs.\n

\n [ I love the 5 Why's for that: https://en.m.wikipedia.org/wiki/Five_whys ...\n and she just mentioned it. ]\n

\n There is a less offensive way to dig into the root cause (5 Why's can feel\n offensive), you can ask users about the benefits they solution they have in mind\n will yield for them. This can lead onto the path of finding out why they have a\n specific solution in mind.\n

\n Nevertheless, the best way to find out what your users need is to observe them\n find the user's pain points.\n

\n But make sure that does not influence them too much. Because users that are\n aware that they are watched, often behave differently.\n

https://vimeo.com/812976108/embed

Lightning talks

https://chaos.social/@coderbyheart/110105689011221411/embed

\n First set of lightning talks at #BoosterConf starts with\n Einar W. Høst who reminds us\n that developers should be emancipated enough to understand their role with the\n same confidence as the so called business people do. They are, in the end, the\n ones who need to take ownership over the decisions they make and how they\n influence the business.\n

https://chaos.social/@coderbyheart/110105729764807207/embed

https://vimeo.com/812979855/embed

\n The second talk is by\n Daria Kostiuk who speaks\n about the dangers of scope creep.\n

\n Don't forget that any new feature you accept has a tendency to cause unintended\n side-effects and cause other things to take longer than expected.\n

https://chaos.social/@coderbyheart/110105773885756845/embed

https://vimeo.com/812979950/embed

\n The third talk is by Kjersti Berg, who talks\n about reviving a code base from a state where it was practically unmaintainable.\n

\n She used an ensemble approach to get out of this mess. They used one hour every\n day to get everyone together. Ensembling helps here because it improves\n knowledge sharing and decision making; both are key to make confident decision.\n

\n After a year this improved code quality, ability to fix bugs and overall team\n happiness!\n

https://vimeo.com/812980074/embed

https://chaos.social/@coderbyheart/110105819627330976/embed

\n Finally in this slot of Lightning Talks at #BoosterConf\n Dalibor Jovic has also a talk about\n technical debt and he proposes a few things you can do about it (because\n sometimes it is not avoidable).\n

https://chaos.social/@coderbyheart/110105991859742366/embed

https://vimeo.com/812980178/embed

\n Now in the second slot of Lightning Talks at #BoosterConf\n Nora Gjøen-Gjøsæter gives us a very\n important reminder how biased AI models are.\n

\n They all are, but some are more than others and effort is needed to not\n reinforce and proliferate the biases the models get from their source data.\n

https://chaos.social/@coderbyheart/110106029163172924/embed

https://vimeo.com/812978922/embed

\n Karianne Berg shares her best practices for\n making awesome database indexes. Some strong language included 🤣.\n

\n Make sure to understand your database schemas when building your applications,\n otherwise your performance will suck!\n

\n Monitor in production to spot queries that need to be optimized (often the\n problem only becomes apparent with production data).\n

https://chaos.social/@coderbyheart/110106317749585353/embed

https://vimeo.com/812979000/embed

\n Very cool lightning talk by Embla Flatlandsmo\n explaining how keyboards just™️ work when you plug them into your computer. Love\n the hand-drawn slides!\n

https://vimeo.com/812979094/embed

Architecture Workshop with Oliver Zeigermann

https://chaos.social/@coderbyheart/110106420255302087/embed

\n we are working on a car insurance architecture Kata. First we are looking at a\n very simplistic implementation.\n

\n Then we are reviewing potential solutions by trying a few simple examples on\n https://ml-playground.com/ which is a really great idea to explain\n architectural tradeoffs.\n

\n Finally, we got 30 minutes to discuss potential solutions in teams. That was\n fun!\n

Fishbowl

https://chaos.social/@coderbyheart/110105827972761842/embed

https://chaos.social/@coderbyheart/110106940802730380/embed

\n Now it's time for the fishbowl at #BoosterConf with controversial questions from\n the audience:\n

Is HTML a programming language? Doesn't matter.
Uncertainty is mandatory: yes
Should we fear AI? No, potential is real.
There is no such thing as a full-stack developer: right, there is not.
\n There is nothing every developer must know: probably Git today is a common\n denominator. But for every given profession there is a set of tools you need\n to know.\n
Technology should not be seen as magic.
\n Psychological safety is just a lazy excuse for doing nothing: absolutely not.\n There is research that shows that high performance and psychological safety\n correlates.\n
\n Cloud vendor independence is not needed and wasteful: maybe, but some\n standardization is useful.\n

Day 2

https://chaos.social/@coderbyheart/110111000689327084/embed

\n Second day of #BoosterConf starts with a #refactoring workshop run by Karoline\n Skylstad and\n Siv Midtun Rollup, we\n are going to dive into a #Java codebase while applying some constraints.\n

The project source we work with is https://github.com/kantega/refaktorama.

OpenSpace

https://chaos.social/@coderbyheart/110112027695532354/embed

Really cool to have two slots for #OpenSpace sessions at #BoosterConf.

https://chaos.social/@coderbyheart/110112058673684939/embed

The topics.

https://chaos.social/@coderbyheart/110112137524008976/embed

First round: talking about quality.

https://chaos.social/@coderbyheart/110112642743962719/embed

\n Second round at the #BoosterConf #OpenSpace: why do do many companies require CS\n degrees?\n

\n This is where I learned about\n https://www.vilbli.no/nb/nb/no/informasjonsteknologi-og-medieproduksjon/program/v.im\n which teaches media and programming skills which allows workers to enter the\n workforce much earlier with relevant skills. It's still a certified training, so\n companies get a reliable level of education.\n

Talk by Elisabeth Whiteley about side-projects

https://chaos.social/@coderbyheart/110112691160134601/embed

\n Elisabeth Whiteley\n shares great insights on how she deals with finding a way for side projects so\n it doesn't feel like work.\n

Make it fun, and don't replicate the same constraints that you have for work!

https://vimeo.com/814008986/embed

Day 3

Talk by Hege Dreiem about API Design

https://chaos.social/@coderbyheart/110116700672549731/embed

\n Final day of #BoosterConf and I am starting with a session on API Design from\n Hege Dreiem.\n

\n She talks about the challenges of designing a ticket booking API for the\n Norwegian railway.\n

\n It's important to design an API that gets used by many clients that you don't\n control to be open for extensions from the start.\n

\n Developing a ubiquitous language is important in the beginning to develop an\n understanding of what the API needs to express.\n

Talk by Aleksander Olavsrud about Machine Learning

https://chaos.social/@coderbyheart/110116753113476303/embed

\n Marius Aleksander Olavsrud\n explains how he and his team used Machine Learning to reduce the number of\n wasted breads at a Norwegian supermarket chain.\n

\n Building a ML solution that works requires the right data. However that often is\n not there. Make sure to get the input data right. The implementation is only\n half of the project. Don't underestimate the effort needed to change their\n processes according to the findings.\n

\n They used Facebook Prophet because it can account very good for seasonal and\n holiday events (and it's open source).\n

Unfortunately he did not share how successful this project was in the end.

https://vimeo.com/814014896/embed

Talk about GraphQL by Pål Thomassen

https://chaos.social/@coderbyheart/110117215000547075/embed

\n Pål Thomassen now\n shares his bad experience with GraphQL for building an API for traffic data at\n Statens Vegvesen.\n

\n He starts with a basic introduction to #GraphQL. The bug advantage he mentions\n is that it is great to document the contract between server and clients, and\n there are many tools that can generate consumer code.\n

\n The goal was to provide public access to the data they collect, and in 2018 when\n they need to pick a new technology it looked like a good choice, addressing the\n shortcomings of REST. The initial evaluation and internal tests went quite well,\n and even though there was some hesitation because it was uncertain if it was the\n right choice over REST, it was decided to continue with the approach. It was\n easy to model the API according to the business domain. And they went on to\n launch it.\n

Now for the downsides:

it introduces a bunch of new and complex concepts for implementing it properly
\n from a client point of view it can be challenging to build clients that need\n to retrieve a lot of deep, nested data\n
\n Many users often want spreadsheet exports, that's hard to match from a nested\n structure\n
\n Because of the complexity the internal adoption of the new API was not a full\n success, which is a good indication that it's not an optimal solution\n
\n a lot of consumers wanted access to Gigabytes of data, and transferring this\n via #GraphQL creates a huge overhead.\n

\n So it turned out that it a traditional REST API would have been a better choice,\n both it would be easier to maintain with a smaller team, and it's a more\n established technology that would scale better for this specific project.\n

https://vimeo.com/814015103/embed

Talk by Andrew Harmel-Law about Architecture

https://chaos.social/@coderbyheart/110117723882154948/embed

\n In his session at #BoosterConf\n Andrew Harmel-Law talks about how\n architects can change their behaviour to not keep teams back, but to enable them\n making their own architecture decisions. #AnybodyArchitecture\n

He proposes The Advice Process:

\n \"Anyone can make any decision But before doing so they must: seek advice from\n all affected parties & people with expertise in the matter.\"\n

\n But how to keep people from making bad decisions? Use ADRs to document the\n decision to be made and iterate on it.\n

\n In the draft phase the team pulls in advice from all affected parties and\n document this advice.\n

\n All of this effort gets synchronized in weekly meetings of the Architectural\n Advice Forum.\n

\n It's important to track progress of ADRs to have an eye on those ADRs that get\n stuck.\n

Finally he points out to watch out for potential causes this approach can fail:

\"Bad\" decisions (there are none really)
Old guard == New guard (not giving room for others to make decisions)
Off-the-grid decisions (teams not using the process)
No trust

\n This is the detailed blog post for this talk:\n https://martinfowler.com/articles/scaling-architecture-conversationally.html\n

https://vimeo.com/814014311/embed

Closing

https://chaos.social/@coderbyheart/110117947182962966/embed

Daan van Berkel closes #BoosterConf for this year.

https://chaos.social/@coderbyheart/110118043651086506/embed

Thanks to the #BoosterConf organizers and team, that was a blast!

\n","slug":"boosterconf-2023","hero":"!undefined"}],["bring-your-inexperience-to-a-conference",{"title":"Bring your inexperience to a conference","subtitle":"On contributing to a community","abstract":"As a newbie you have something to contribute to a conference as well!\n","date":"2017-04-23T13:00+02:00","html":"\n

\n In August there will be the 7th\n International Software Craft and Testing Conference\n in Soltau, Germany. For me, the SoCraTes is the most important event in my\n profession every year, because I get to so see so many inspiring people.\n

\n But it’s not only the high concentration of incredibly skilled professionals\n that gather in this remote location in northern Germany that provides so much\n value to me.\n

It’s the Newbies as well.

\n It might not be obvious to you as a first-time attendee or if you are new to the\n field of professional software development: you have something to contribute,\ntoo!\n

\n Since 2016, tickets for the SoCraTes are raffled and this provides a much higher\n influx of participants which haven’t attended any conference before that focuses\n on software as a craft. If you are one of those, I’d like to encourage you to\n offer a session, ask for support on a topic (this is called a pull session),\n and not to hesitate to offer your opinion during other sessions.\n

Because your are adding value, even by asking a question!

\n Your How? questions are making us better teachers. Being a Software\n Craftsperson one of the most important goals is to become great at explaining\n the value of certain behaviour or technique. Because we loathe dogmatic\n application of \"best practices\" but strive for developing an understanding of\n the underlying principles of software development, so we can find the best\n solution for a problem, not the most obvious one. We can’t expect this from our\n peers, if we fail to explain it to them.\n

\n Your Why? questions are making us more effective. There are many biases that\n favor repeating decisions that have worked in the past, but in a chaotic market\n this strategy of our mind is not always a good fit. Being confronted with an\n honest question about the reasons for a certain decision forces us the make our\n oftentimes only implicitly known reasons and assumptions that lead to that\n decision explicit. It’s very helpful to shake one's belief system openly once in\n a while, because we are then challenged to do this honestly.\n

\n You get to do all what's mentioned above (offering knowledge, asking questions,\n challenging decisions) in a safe environment which is very unique to the\n Software Craft Community: everybody understands that there is never only one\n good solution to a problem, because in Software everything depends. Therefore\n you will never hear someone dismissing an idea as wrong, even if their own idea\n about it is highly controversial to what they are presented.\n

\n They will offer their advice and experience in a non judgemental way. And that’s\n why the SoCraTes and this community is awesome for Software Craftspeople of\nevery skill level.\n

\n","slug":"bring-your-inexperience-to-a-conference","hero":"!undefined"}],["build-a-professional-network",{"title":"Build a professional network","subtitle":"Markus, How do I ...","abstract":"My recommendations on how to build a professional network if you are early in your career.","date":"2017-11-05T14:00+01:00","html":"\n

\n Since I just was interviewed about this topic, I'll try to write down some of my\n recommendations on how to build a professional network if you are early in your\n career and how to progress from there. Actually I am practicing all of these\n actions even today.\n

\n I'll focus on building a network to other professionals in your industry, since\n this will enable you to learn about new technologies, improve you skills based\n on experiences they are sharing and ask for support, find mentors and later on\n jobs and hires.\n

\n In my experience the tech scene is especially good approachable on Twitter.\n I find myself following a lot developers there\n and this way I get daily access to what is going on tech-wise. The real-time\n character of the network has it's advantages: you can easily interact on a given\n topic but it rarely happens that someone resurrects a old post. It's very easy\n to approach someone with a question there, and they usually will answer right\n away.\n

\n But make now mistake, following someone on Twitter is a one-way street, to\n build a network you have to share something so people can become aware of\n you. And since connections are built on trust, it means you have to expose\n yourself to some degree. And this exposure needs to happen in the physical\n world, only there will you be able to build connections that support exchange\n about personal and confidential matters which is the basis for finding good\n advisors and mentors.\n

\n The first step is to go to local meetups. Do not fear to go there as a\n beginner, the first step to learning something is to embrace the unknown. It's\n a great opportunity to learn to know new people and find out who you would be\n interested to talk to. You will find that approaching someone there is a lot\n easier compared to a contacting them only e.g. through LinkedIn. Since you are\n both part of the same interest group, and you took the time to be present at the\n meetup will give you already some credibility. Also, it's harder to turn down\n someone who is approaching you face to face.\n

\n Early in your career you should develop the confidence to give your first\ntalk. Watch other speakers and try to find someone with experience as a\n speaker to give you feedback on your talk. Most meetups will be happy to host a\n beginner talk,\n since they always provide really valuable input.\n Giving talks will put you in the spotlight—doing it at a small meetup where you\n know people can be even more uncomfortable compared to a huge conference—but it\n also gives you a lot of visibility. I can highly recommend\n the software crafter communities around the\n world as a very inclusive and beginner-friendly community of professionals.\n

\n Every talk creates the opportunity to reuse the content in multiple ways. You\n can use it to share your findings on your blog, but even better: submit it to a\n conference.\n

\n The next step of building a valuable network is to attend conferences. At\n conferences you will be able connect with a great variety of people. Those that\n share the same problems as you do and other beginners which will be a great\n resource when learning a new topic since you can exchange about your findings\n and problems. Since last year, it became common to connect through a Slack\n instance for that conference. Here you can also easily approach speakers, with\n your questions or on general to just give them feedback on their talk. In both\n case they will usually be very open and happy to help you. It's a good idea to\n check out a conference schedule beforehand and follow the speakers on Twitter,\n doing that you can start building a connection to them even before the event.\n

\n You should submit your beginner talk to conferences, because giving a talk\n will teach you so many great things that improve your skills on many levels. You\n can find conferences that accept proposals (Call for Papers, or CfP for short)\n on papercall.io or through\n lanyrd. Karolina has a great post on\n How to write a successful conference proposal.\n Becoming a speaker on a conference will give you a lot of visibility and\n provides a great opportunity to meet other industry experts on eye-level.\n

\n","slug":"build-a-professional-network","hero":"!undefined"}],["build-this-opendata-hackers-and-datanauts",{"title":"Build this, OpenData Hackers and Datanauts [Updated]","abstract":"OpenData projects must be useful not just interesting, so here is my idea\n","date":"2015-05-31T13:00:00.000Z","html":"\n

\n I recently participated in the first meeting of the\n Open Knowledge Lab Frankfurt.\n The verdict of the meeting was that local OKLabs should focus on building\n projects that serve a real need and not just be interesting from a developers\n perspektive … otherwise it wont get noticed by the public and ultimately by\n local authorities–which are an important source of open data.\n

So here is my idea:
find the best place to live given the criteria that are important to me and\nvisualize this on a map.

\n Let me show you some pictures to illustrate my idea: heat maps help to visualize\n geologically coded events. The first example from\n umwelthaus.org is\n a heat map of the aircraft noise measured during the day:\n

\n The second example from crime-radar.com is the\n number of crimes committed in Frankfurt's city limits:\n

\n If you combine those two you'll get a good idea which neighbourhoods to avoid if\n you were to move into this region.\n

\n And those are just two possible datasource. For me I'd like to see visualization\n for:\n

public transport time to my workplace
prices for land and houses
availability of fast internet access
proximity to bioreserves, hiking trails, lakes
population density
election results

\n This would enable me to pan around a map and find places that would fit my\n preferred living conditions.\n

\n Feel free to submit it to the\n TEDxRheinMain Datanauts Contest, I won't\n because I'd be forced to comply to their\n overly one-sided terms and conditions.\n

\n Also there is the\n Open Data Hackathon this\n Saturday at the best coworking space around:\n Die Zentrale. A perfect event to getting this\n started …\n

Update

\n One of the 10 winning ideas of the event is\n settlement spotter–which\n is exactly what I asked them to build!\n

\n
\n Use big data and feedback from various independent sources, leverage federal\n and public sources, open sources from the industry to create a map that will\n allow a user to draw a picture. Create an online environment to help an\n individual decide and plan his move to a place where his living requirements\n are met perfectly.\n
\n

I'm looking forward to seeing this project come to life.

\n","slug":"build-this-opendata-hackers-and-datanauts","hero":"!undefined"}],["call-for-proposals-lightning-talk",{"title":"About: Call for Proposals","subtitle":"Lightning Talk","abstract":"At 2019's Global Diversity CFP Day I gave a lightning talk about Call for Proposals.","date":"2019-03-02T11:00+01:00","card":"../media/call-for-proposals-lightning-talk.png","html":"\n

\n At 2019's Global Diversity CFP Day I\n gave a lightning talk about Call for Proposals.\n

https://www.youtube.com/embed/jzqCzGXT7hw

\n The slides are available\n here.\n

Below is are the main talking points I cover

Structure of a Proposal

\n In order to prepare a good proposal we need to look at what conference\n organizers expect from a submission.\n

These are the elements that you need to prepare:

Speaker Profile

\n You might think that only what you talk about matters, but it is actually the\n other way around. Conference organizers create a space to network, and the time\n around the talks is actually where most attendees will see the value in. It\n matters very much to find a diverse set of speakers and that is why you should\n not miss out the oportunity to answer the question: Why should I talk to you?.\n

A good speaker profile should have:

less than 100 words
\n be written in third person (conference organizers will copy&paste this to\n their website)\n
\n have a mix of background information on your experience and interesting trivia\n about you\n

Here is how my speaker profile looks like (92 words, 596 characters):

\n
\n Markus is a coder by heart and an organizational hacker by passion. As a\n software crafter he uses his 20+ years of experience working as a software\n developer, consultant, coach, mentor, and founder to build cloud-based\n solutions for the Internet of Things using JavaScript. His professional career\n has been greatly influenced by taking an active role in communities, whether\n as a participant, contributor, initiator, or speaker. He especially enjoys the\n diverse and deep discussion of the Software Craft Community. He lives in\n Trondheim, Norway and enjoys plowing through deep snow on snowshoes.\n
\n

Abstract

\n A great abstract distilles down the main takeaway of your talk into a very\nshort form. It takes a lot of work to remove the unneccessary fluff from the\n text and highlight what the main takeaway of your talk is.\n

Part of the abstract is the title which also needs to be an eye-catcher.

\n Remember, your proposal can be one of hundreds so you need to catch the\n attention of the conference committee member within a few seconds.\n

In your abstract

make the title 100 characters or less
fit the main idea in a tweet 280 characters

\n On many submission forms there is often not much more space for the abstract.\n 500 characters is still safe, and if you absolutely cannot fit your idea in a\n tweet, prepare multiple variants of the abstract.\n

\n Here is how my abstract looks like (title has 63 characters, text has 288\n characters):\n

\n
\n Integration testing a cloud-native application with JavaScript
In this talk I will take you through the challenge of testing a cloud-native\n application. I will cover the challenges when developing solutions on top of\n serverless components which you cannot run on your own machine and how I\n designed a BDD driven approach to run the integration tests.\n
\n

Notes

\n Once you have prepared this abstract, basically all conferences allow for to\n provide additional notes. This is your opportunity to provide more context to\n your abstract and also a second chance to highlight the most important\n aspects of your talk. This is also a good place to provide more background\n information on why you are passionate to share this talk.\n

The notes for my submissions look like this:

\n
\n In my current project at Nordic Semiconductor I am building a RESTful API for\n interacting with the next generation of IoT devices. This solution is build on\n top of AWS using serverless components. Not only the implementation of the\n business logic is done in JavaScript, but I have developed the entire CI/CD\n solution in JavaScript. In this talk I will cover the challenges when\n developing solutions on top of serverless components which you cannot run on\n your own machine and how I designed a BDD driven approach to run the\n integration tests, because I absolutely love tests. It showcases that\n JavaScript can be used in a truly full-stack manner today and that we can\n cover Development, DevOps and Testing with the one language we love. I am also\n really passionate about showcasing the BDD approach to testing which is in my\n opinion a fantastic way to drive test and at the same time have a living\n documentation.\n
\n

5 key learnings

\n I see conferences which have started to explicitely ask for it, but in my\n experience providing this list in the notes is really helpful for the conference\n committee. Explain in 5 bullet points what your audience will take away from\n your talk, the most important one first.\n

The first key learning is easy, rephrase your abstract and you are done.
I spoke about this because it really helps to understand the topic.
This is also important, but might not apply everywhere.
If you were really listening this is a cool bit to remember.
Stretch goal!

Here is the real example from my talk:

\n
\n
How the cloud native test-pyramid looks like
\n
\n Infrastructure as code is key, because configuration of cloud-native\n services are part of the solution\n
\n
how BDD can be used to write re-usable test instructions
\n
\n to write tests that behave like real users (retry if failed multiple times)\n instead of programming shortcuts, because this will give better information\n to system design\n
\n
use “real” test doubles backed by queues to monitor outcome of test cases
\n
\n

Keywords

\n The SEO for talks is mainly used to cluster talk submission for the commitee,\n but some websites also publish them for the attendees to filter talks. They are\n not used that often, but you should prepare 5-10 keywords in advance.\n

These are the keywords for my talk:

\n
JavaScript IoT BDD Serverless AWS
\n

Where to find CfPs

\n Once you have your proposal ready it is time to submit it. The most important\n place to find out about Call for Proposals is Twitter. Follow conferences and\n speakers because this will be the first place were you will learn about new\n announcements.\n

\n There are also sites that aggregate CfPs and provide a list and a regular email\n about new CfPs. Check out:\n

Submitting

https://twitter.com/mary_grace/status/1090988453226074113

\n Once start submitting remember that you will receive rejections, and quite a lot\n of them. It's hard to give a ratio, because it depends on your talk and which\n conferences you select, but getting 9 out of 10 submissions rejected is totally\n normal. So oversubmit!\n

\n Another reason for that is that it is hard to plan month ahead. Some CfP end\n more than half a year in advance. It is impossible to know whether you will be\n actually able to attend. You always will be asked after your proposal has been\n accepted to confirm your attendence. This typically happens at a time where it\n is easier to plan ahead and figure out those conflicts. Don't feel bad to turn\n down an opportunity to talk, the conference will not have a hard time finding a\n replacement, especially if you decline right away.\n

\n It helps to track your submissions, I use a\n Trello board\n to keep an overview. Because you also do not want to submit to the same\n conference twice...\n

#paytospeak

\n I also need to mention\n #paytospeak here, because\n it's important to understand that we as speakers are actively hindering the\n diversification of the speaking community if we accept speaking opportunities\n for which we pay the expenses out of our own pockets.\n

If you are not getting reimburst for your expenses as a speaker there is a\nhigh chance that you are benefiting off someone who cannot afford to attend.

\n There are two great blog posts on this topics which I highly recommend you to\n read:\n

Code of Conducts

https://twitter.com/pati_gallardo/status/1058282328177471488

\n If you apply to a conference I highly encourage you to check out their Code of\n Conduct. Having no is a red flag, but having a single-paragraph one mit even\n be worse.\n

There are Code of Conducts, like

\n
“Don’t be a jerk.”
\n

and there are good Code of Conducts because they are

concrete, so it is clear to everyone what inacceptable behaviour is
\n enforcible, so there are clear guidelines on what will happen in case\n something happens\n
and everyone has of the staff has been trained on how to handle incidents

\n A good example is the\n JSConf Code of Conduct.\n

Now, go and become a speaker!

https://twitter.com/devdevcharlie/status/1090367939889397760

You can find more resources on public speaking here:

\n I am also always\n happy to help.\n Feel free to reach out to me! If I can help you with your talk proposal, send me\n a Google Doc!\n

\n","slug":"call-for-proposals-lightning-talk","hero":"!undefined"}],["call-for-your-first-conference-proposal",{"title":"Call for your first conference proposal","subtitle":"My segment on why YOU should propose a talk to a conference NOW! from J On The Beach 2018","abstract":"My segment on why YOU should propose a talk to a conference NOW! from J On The Beach 2018","date":"2018-09-16T21:00+02:00","html":"\n

https://twitter.coderbyheart.com/status/1041408149276774400

\n If you think you want to talk about something you are passionate about you are\n already a step further than 99%.\n

Write a proposal — 99.9% don’t.

\n See speaking.io for great resources on how to get\n started. Also check out\n this thread on\n Twitter.\n

\n Submit to conferences that cover travel expenses\n (#paytospeak)
and\n have a good Code of Conduct.\n

If they don’t, ask why!

\n Find conferences who are calling for proposals on: SeeCFP\n or Papercall.\n

More resources on public speaking:

\n Speak Easy mentors speakers to encourage\n diversity at tech conferences\n

\n","slug":"call-for-your-first-conference-proposal","hero":"!undefined"}],["clean-architecture",{"title":"Clean Architecture","subtitle":"Book Review","abstract":"Despite its excess Uncle Bob Grandeur and idiotic and pointless cartoons I would recommend this book to experienced architects and software developers since it reinforces and clarifies proven concepts, which I am using on a daily basis.","date":"2018-01-03T06:00+01:00","html":"\n

\n Clean Architecture is the latest book in the Clean\n[...] series, following Clean Code, and The Clean Coder written by the\n Software Craftsman Robert C. \"Uncle Bob\" Martin who most recently became an\n outcast of the worldwide Software Crafters Community for opinions he expressed\n in his personal blog regarding diversity.\n

\n In the book we are spared from his personal opinions, and only slightly\n confronted with a tiny dose of everyday sexism, and another big portion of\n \"Uncle Bob has seen it all\" in the 50 page Appendix on Architecture\nArchaeology in which Martin uncovers stories about his work dating back to the\n early 70s which merely serves to support the validity of the ideas and concepts\n that have been presented in the previous chapters. It reads like another attempt\n to infuse Martin's legend with substance, which is odd, since he spent the\n Preface and Introduction chapters on this topic already.\n

\n What I liked about the book is his attempt to guide the reader through\n techniques and principles that lead to good architecture but also provide a\n slightly superficial explanation of these topics. He debunks object-operation\n and is able to reveal the core principles of every software and what good\n architecture should enable:\n

good architecture makes software easy to change

\n and easy to change means that the cost of change is magnitudes lower than the\n value the change provides. His concepts are designed to enable a very long\n software lifetime by keeping developer productivity high of years into a\n software project.\n

\n For me personally there weren't any new revelations to be discovered but I liked\n Martin's way to re-define and sharpen existing ideas using simple language. The\n chapters surf just below the surface and never dive too deep, which will be\n problem for unexperienced software developers and architects since they will\n most likely not be able to connect the dots.\n

what matters is the domain

\n I especially like Part IV of the book in where Martin stresses the idea that\n good architecture abstracts away concrete implementations from the beginning.\n This idea has been presented in the previous chapters already with a focus on\n implementation on the module level. Part IV makes this idea more tangible by\n explaining why and how secondary components (I'd call them that) like databases,\n UI and frameworks should be separated from the software core.\n

\n By page 210 you have already encountered all there is to know in the book so\n don't be taken away away by the page count. The remaining chapters flesh out the\n main idea:\n

\n
\n Write high-level abstractions for everything that is not your core business\n domain, and don't let secondary component concepts leak into your business\n domain.\n
\n

\n Despite its excess Uncle Bob Grandeur and idiotic and pointless cartoons I\n would recommend this book to experienced architects and software developers\n since it reinforces and clarifies proven concepts, which I am using on a daily\n basis.\n

\n","slug":"clean-architecture","hero":"!undefined"}],["clean-gitignore-files",{"title":"Clean .gitignore files","subtitle":"Best practice","abstract":"A .gitignore in a project should only cover artifacts caused by the contained source code, not those caused by the personal choice of editor and/or environment of a developer.","date":"2025-12-28T12:38+01:00","html":"\n

\n A .gitignore in a project should only cover artifacts caused by the contained\n source code, not those caused by the personal choice of editor and/or\n environment of a developer. Use\n a global git ignore file\n for that.\n

\n Yes, you can solve it also with a well maintained .gitignore file that covers\n everything in all projects but this can get\n quite extensive to cover all cases.\n

\n I consider it noise if entries are in the .gitignore that have no relation to\n the specific project: I want a clean .gitignore file.\n

\n Maintaining a global .gitignore file for your personal setup also has the\n advantage that it affects all existing and future projects on your machine, thus\n eliminating the possibility of accidentally committing those files. Otherwise\n you would need to remember to add your IDE files to EVERY projects .gitignore.\n

\n Additionally, changes to the .gitignore of a project are not free: they\n trigger CI runs, releases, reviews. Having people constantly add their favourite\n rules creates noise. I don't want that.\n

\n Having a huge catch-all .gitignore is no solution either, it will only cover\n known files. Additions trigger noise.\n

\n Adding files to a git repository is a deliberate action, if developers add files\n that do not belong to a feature or change they need to be better educated about\n it. If this is done, an accident-preventing-gitignore is no longer needed.\n

Good example

dist/\nnode_modules/\n

Bad example

.idea\n.vscode\n.DS_Store\n

Tip

Have a local folder to put your crap in which won't get accidentally committed

\n","slug":"clean-gitignore-files","hero":"!undefined"}],["clone-all-repos-of-a-github-team",{"title":"Clone all repositories of a GitHub team","subtitle":"snippets","abstract":"This is a small snipped that clones all repositories of a GitHub team","date":"2022-11-01T13:00:00+01:00","html":"\n

\n First, ensure you have your GitHub token available. If you are using a .netrc,\n you can acquire it from there:\n

GITHUB_TOKEN=`cat ~/.netrc | grep 'machine github.com' | awk '{ print $6; }'`\n

Then, using the organization name and team slug, clone all repositories:

ORG=my-org\nTEAM=my-team\nhttp https://api.github.com/orgs/${ORG}/teams/${TEAM}/repos\\?per_page\\=100 \\\n    Authorization:\"token ${GITHUB_TOKEN}\" | jq '.[].clone_url' | xargs -I@ git clone @ --depth 1\n

\n","slug":"clone-all-repos-of-a-github-team","hero":"!undefined"}],["cloud-connectivity-and-protocols-for-the-internet-of-things",{"title":"Cloud connectivity and protocols for the Internet of Things","subtitle":"Webinar","abstract":"This is a webinar for everyone who wants to get an introduction to protocols to consider when developing a cellular IoT product.","date":"2020-10-21","card":"https://webinars.nordicsemi.com/60650860/64311747/957cd4b4fcdc7aebf637ffbe16e10720/large/download-5-thumbnail.jpg","html":"\n

\n This is a webinar I did for\n Nordic Semiconductor Tech Webinars\n together with my colleague Carl Richard Fosse, but it applies to everyone who\n wants to get an introduction to protocols to consider when developing a cellular\n IoT product.\n

\n It provides an overview over the important factors that need to be considered\n when it comes to picking the right solution for sending your products' data to\n the cloud.\n

https://www.youtube.com/embed/pNaBB_OFbgg

\n You can find the interactive, browser-based slides\n here, and a PDF\n with all notes\n here.\n

\n","slug":"cloud-connectivity-and-protocols-for-the-internet-of-things","hero":"!undefined"}],["code-craft",{"title":"Code Craft","subtitle":"Book Review","abstract":"A critique of the book Code Craft by Pete Goodliffe","date":"2018-07-16T20:00+02:00","html":"\n

\n It's amazing what Pete Goodliffe managed to compile in the 558 pages of\n this book on software development (subtitle The\nPractice of Writing Excellent Code) which was published back in 2007.\n

\n The author takes the long road of not only explaining how software is made but\n also detailing which individual skills and techniques are needed to produce\n software which is of high quality in all aspects. He tackles software-related\n topics like architecture, maintainability, documentation, performance,\n optimization, source-code management, but does not miss the opportunity to\n highlight the importance of communications and that great teamwork is paramount\n to producing great software.\n

\n I especially liked the way every chapter is structured like a course: following\n a short overview, we are taken from the fundamentals of every topic to the state\n of the art, and closing with a set of tasks and questions to get the reader\n thinking, in parts alone but also as a team.\n

\n The book has aged well, everything is still relevant today and I can highly\n recommend this book for any aspiring software developer. It is also a great\n workbook if you are developing an internal apprenticeship program or software\n developer curriculum.\n

It may be the best software developer compendium available today.

\n","slug":"code-craft","hero":"!undefined"}],["code-of-conducts",{"title":"Code of Conducts","abstract":"I recently proposed to establish a Code of Conduct for the BarCamp RheinMain. Here is my rationale why.\n","date":"2016-08-15T23:00:00.000Z","html":"\n

I recently proposed to establish a Code of Conduct for the\nBarCamp RheinMain. Here is my rationale why.

\n tl;dr: Your every word influences other humans. I believe it is worth\n scrutinizing your own behaviour.\n

\n Germany is a society dominated by CIS\n white males. Who doesn't acknowledge this as a deficit is part of the problem.\n Acknowledgement is the first step if we want to change the status quo. A Code of\n Conduct like this one with a very stark\n focus on sexual harrassment puts a spotlight on the fact that it is actually a\n huge problem how our society treats humans that do not identify with the simple\n black and white idea of man / woman = strong / weak.\n

\n Behaviour is always influenced by experiences, only if we change the environment\n in which we interact with other and challenge the way how we do so, change can\n be achieved. In my opinion it is our duty as event organizers to take on this\n task.\n

\n Given that we welcome many young participants at our BarCamps we have the chance\n to support them in the development of their personality in a good way or at\n least to not harm them.\n

For further reading on the topic, check out\nthis awesome list of resources\nby Lena Reinhard.

\n","slug":"code-of-conducts","hero":"!undefined"}],["codedoor-apac",{"subtitle":"Mentoring","title":"CodeDoor and Asia Pacific College","date":"2020-12-03T09:16:00.000Z","abstract":"I am mentoring 4 teams from the Philippines","html":"\n

\n I'm really excited to be mentoring 4 teams (of 50) from the\n Asia Pacific College on the Philippines as part of a\n three months CodeDoor and\n IBM SkillsBuild bootcamp that teaches students how\n software can be used to tackle important problems. They will be focusing on\n natural disasters. This is going to be amazing!\n

https://twitter.coderbyheart.com/status/1334426175565934592

\n","slug":"codedoor-apac","hero":"!undefined"}],["codefreeze-brings-the-magic-of-socrates-to-lapland",{"title":"codefreeze brings the magic of SoCraTes to Lapland","subtitle":"A conference about Software Craft like no other","abstract":"About codefreeze, the software craft and testing conference in the arctic circle","date":"2017-01-21T10:00+02:00","html":"\n

\n For the last week we have been in Kiilopää, a national park in the\n arctic circle to attend codefreeze which brings the Software Craft and\nTesting Conferences to one of the most remote places I have ever\n visited. I was drawn there by the pictures I saw on Twitter of last\n year and this year, I could contribute a fair share of my own.\n

\n The conference has been a breathtaking experience and we will definitely be go\n there again, not only for the conference, but for the beautiful nature that the\n national park offers. And with a direct flight from Frankfurt to Ivalo, which is\n just a 40 minute bus drive from Kiilopää it is easy to go there for us. We even\n had Finns, that had longer journeys to reach this remote spot in the arctic\n circle where there is basically nothing for hundreds of kilometers.\n

\n The national park itself is around 40 kilometers in diameter and preservers a\n natural fern forest with very old trees, they can reach up to 300 years before\n they die and will then keep standing for another 50 or more years.\n

\n Soumen Latu is a charitable organization in Finland that aims to preserve\n the nature which operates the Fjell Center where we stayed. It's a small village\n with a main building where you will get great food basically all day, which has\n a rental shop and a public sauna that is on all day. Next to it is a hostel for\n groups and a hotel with rooms for one to two persons. We stayed in one of the\n roughly 40 cabins that house two to ten people. Our log cabin of 50 m² was\n equipped with it's own sauna and a fireplace.\n

Absolute Silence

\n With the next supermarket being 26 km away and the airport around 40 km, no\n industry a ban for snowmobiles in the area the nights were absolutely silent.\n And even at day, when being just a few hundred meters away from the main\n building, you would hear not a thing.\n

\n The masses of snow, that blanketed the area created an incredible atmosphere and\n a fascinating black and white backdrop for the many outdoor activities you could\n have: between 1000 and 1500 the sun was above the horizon—not visible from the\n fjell center, though—and here we did nordic skiing, snowshoe trips and\n backcountry ski trips guided by the volunteers of the Soumen Latu association\n that come to Kiilopää to stay there for two or more weeks receiving free\n accommodation for their services. The trips were free of charge, you only had to\n rent the necessary equipment in the rental shop at the main building for a\n reasonable price—e.g a pair of snowshoes and poles for 10 € per day.\n

Perfect winter vacation: snow and sauna

\n The trips would take you to the area around which offers a lot of variety: dense\n forests with deep snow, prepared tracks for nordic skiing or you could go above\n the treeline on top of the Kiilopää—the 600m high mountain that the center is\n named after. Usually you would start in the morning around 10—that's when\n breakfast ends—and be home in the early afternoon—it got dark around 1500—to\n take a nap and then go to the sauna. And even with sauna there is variety: you\n have the normal finnish sauna in the cabin with an electric oven, it heats up\n quickly to 100° and you can set it up in advance, to time it perfectly for your\n return. But there is also smoke sauna, a big sauna for roughly 30 people that is\n warmed at noon with a open wooden fire which heats up a big pile of stones that\n keep the warmth for hours. The smoke sauna can then be used between 1500 and\n 2000 and has a totally different heat which is less intense and you can stay\n there for three hours—once in a while you will go out and take the dip, a\n small pond that is kept ice-free by a flowing water source and has a temperature\n of around 1°. It sounds scary at first, but it's actually a great feeling,\n especially when your feet start to freeze to the ground after leaving the water\n …\n

The codefreeze unconference

\n To be honest, we never planned to make this trip about the conference, it was a\n great occasion to be there but it was clear that this would be more of a leisure\n trip, which is why I didn't make this trip on the company budget. But we had\n three and a half days, starting on Monday afternoon where we had a proper\n unconference, you can see for yourself on the trello board for the\nweek, given the small group—around 20 attendees—we still managed to\n fill the timetable with a great variety of topics. But a lot of discussion\n happened outside of the sessions and that's what made it especially great to be\n here. Although you had so many outdoor activities, everybody would always return\n to the main building for food, or the sauna, or some of the cabins where the\n discussions continued or new topics arised.\n

\n For me it was the best conference experience I could imagine and it was also the\n best winter vacation I ever had. We will definitely return to Kiilopää and not\n only during codefreeze season but also in the summer, to hike in the woods there\n from hut to hut. I'm very grateful for Aki adding this experience to my\n life. I will never forget my first codefreeze.\n

\n","slug":"codefreeze-brings-the-magic-of-socrates-to-lapland","hero":"!undefined"}],["conferencebuddy-at-socrates-2018",{"title":"ConferenceBuddy at SoCraTes 2018","subtitle":"No one needed a ConfBuddy, and why this is a good thing","abstract":"I was a Conference Buddy at SoCraTes 2018—but nobody needed one.","date":"2018-09-01T16:00+02:00","html":"\n

\n The SoCraTes conferences are dear to my heart, and\n the one in Soltau every year is my most\n important conference date every year. This year some of us shared that we were\n attending and happy to be a ConferenceBuddy:\n

https://twitter.com/benjamin/status/1029742801767067648

https://twitter.coderbyheart.com/status/1030010907840192513

\n I also created a public #buddies channel in the\n conference Slack, where I posted\n opportunities for buddies to meet at the first night of the conference (the\n evening where everyone arrives). 26 people joined.\n

\n On the first day of the open-space at the marketplace in the morning, I\n announced that if somebody felt that they would like to meet a buddy, I would be\n happy to meet during lunch.\n

And then, nobody showed up.

\n But this is totally what I expected to happen. SoCraTes Soltau is by far the\n most inclusive tech event I know, and everybody behaves incredibly welcoming and\n respectful. It is a safe space and also still kind of an insider-event, since it\n is organized by the community and non-profit. You usually know about SoCraTes\n because you know someone, who knows it.\n

\n But (!) I have received positiv feedback explicitlty referring to\n ConferenceBuddy and how it reduced the barrier for newcomers to feel welcome at\n the event.\n

\n So, this is actually a success story for ConferenceBuddy, because it's like the\n phone number in a conference code of conduct: it needs to be there and you have\n to make sure that somebody answers it all the time, but its a good thing if\n nobody calls.\n

And here is how a participant put it:

https://twitter.com/tdpauw/status/1030076022153199616

https://twitter.com/tdpauw/status/1033731158918475776

\n","slug":"conferencebuddy-at-socrates-2018","hero":"!undefined"}],["connect-to-dead-com-connection-timed-out",{"title":"connect to dead.com: Connection timed out","abstract":"Wie könnte es auch anders sein?!","date":"2010-05-11T00:00:00.000Z","lang":"de","html":"\n

Oct 21 10:08:07 jayla postfix/error[24545]: B13623382E: to=<8b067c20a9cccde27038d13a1c1df64a@dead.com>, relay=none, delay=36297, delays=36267/30/0/0.01, dsn=4.4.1,\nstatus=deferred (delivery temporarily suspended:\nconnect to dead.com[66.240.173.8]:25: Connection timed out)\n

Wie könnte es auch anders sein?!

\n","slug":"connect-to-dead-com-connection-timed-out","hero":"!undefined"}],["covid-19-guide-for-aid-workers-built-with-gatsbyjs-from-a-google-drive",{"title":"COVID-19 guide for Aid Workers built with GatsbyJS from a Google Drive folder","subtitle":"resources.distributeaid.org","abstract":"resources.distributeaid.org provides a browser-friendly UI for a Google Drive folder.","date":"2020-05-19T18:00+02:00","html":"\n

\n Last year in October I joined Distribute Aid as a\n volunteer. I craft software for them which helps with their mission: build tools\n that help refugee aid groups discover and connect with each other, collaborate\n on aid shipments, share knowledge, and engage volunteers.\n

\n End of March we launched a landing page for a collection of information about\n COVID-19 and how to safely organize community aid during the outbreak which has\n been reviewed by front-line medical and refugee aid workers and which was\n provided for readers in\n this Google Drive folder.\n

\n Google Drive is amazing for collaborating on these resources but is a heavy web\n application which includes a lot of features for editing content, which is not\n needed when reading the content.\n

\n In April I started experimenting towards a solution that would keep the great\n editing capabilities of Google Drive (which are essential for incorporating\n feedback from dozens of contributors) but on the same hand improve the usability\n for readers.\n

\n After implementing an exporter, which uses pandoc to\n convert the HTML files which\n can be exported using the Google Drive API\n to Markdown, I fed them into GitBook, a great\n service which turns a collection of Markdown files into a nice website. GitBook\n is ideal for content heavy, documentation style projects. However for use the\n options to customize the design of the generated website was too limited.\n

\n I then turned to GatsbyJS, a great static site\ngenerator which allows to customize every aspect of the generated website and\n helped me to build a nicely designed guide that follows Distribute Aid's\n corporate identity, including a great mobile experience.\n

\n Because of the richt ecosystem of Gatsby adding full text search with\n Algolia was done very quick and could be integrated\n exactly where it makes sense for a guide.\n

\n Please check out and share the guide:\n resources.distributeaid.org.\n

\n The source code for the project can be located\n on GitHub.\n

\n","slug":"covid-19-guide-for-aid-workers-built-with-gatsbyjs-from-a-google-drive","hero":"!undefined"}],["daring-greatly-talking-about-shame-is-inevitable-if-we-want-to-change",{"title":"Daring Greatly: Talking about shame is inevitable if we want to change","abstract":"Book review of Daring Greatly by Brené Brown\n","date":"2016-03-13T16:30:00.000Z","html":"\n

\n Daring Greatly by\n Brené Brown message is simple: We use other\n people's shame to protect ourselves from shame. A vicious circle that starts as\n early as kindergarten and becomes part of our everyday behaviour. It is so\n powerful that we build armory around our personalities that change who we are\n and limit what we could become.\n

\n Watch her TEDx talk for an\n introduction to her topic. But I recommend you to read this book, too. It is\n highly readable and provides important insights backed by years of research and\n thousands of interviews.\n

\n The message is clear: we need to embrace shame and put ourselves out there. We\n will be criticized, we will fail, we will struggle but if we don't we are\n missing out.\n

\n In times where big corporations are shifting they way the operate towards an\n open and transparent culture this book is especially important. Giving employees\n the power to decide on their own when, how and on what they will work also\n shifts the responsibility for their actions from their former bosses towards\n them. More and more will they make their daily work public and open for\n scrutiny. But for decades we have learned and perfected the finger-pointing\n game. If organizations fail to understand that the change not only requires new\n ways to organize work but also requires everyone to develop new communication\n skills and empathy, change will fail.\n

\n A remarkable quote from the book is this one from Kevin Surace, Inc.com's\n Entrepreneur of the Year 2009. Below is a verbatim copy from\n this article in fastcompany.com\n which is freely available:\n

Brené asked him: What's the most significant barrier to creativity and\ninnovation?

\n
\n I don't know if it has a name, but honestly, it's the fear of introducing an\n idea and being ridiculed, laughed at, and belittled. If you're willing to\n subject yourself to that experience, and if you survive it, then it becomes\n the fear of failure and the fear of being wrong. People believe they're only\n as good as their ideas and that their ideas can't seem too ‘out there' and\n they can't ‘not know' everything. The problem is that innovative ideas often\n sound crazy and failure and learning are part of revolution. Evolution and\n incremental change is important and we need it, but we're desperate for real\n revolution and that requires a different type of courage and creativity.\n
\n

\n I can recommend this book to everyone who is trying to change how people behave\n in organizations. But this book will not only help you with your work but also\n help you understand your own behaviour better.\n

\n","slug":"daring-greatly-talking-about-shame-is-inevitable-if-we-want-to-change","hero":"!undefined"}],["darstellung-von-git-diff-verbessern",{"title":"Darstellung von git diff verbessern","abstract":"Hier sind ein paar Einstellungen die die Darstellung der Ausgabe von git diff und weiteren git-Kommandos lesbarer machen:","date":"2012-06-27T00:00:00.000Z","lang":"de","html":"\n

\n Hier sind ein paar Einstellungen die die Darstellung der Ausgabe von git diff\n und weiteren git-Kommandos lesbarer machen:\n

Farbige Ausgabe aktivieren, für alle Ausgaben:

git config --global color.ui true

Lange Zeile umbrechen:

git config --global core.pager 'less -r'

\n Hat man wenige Änderungen in langen Zeilen vorgenommen, ist der Switch\n --word-diff sehr hilfreich. Dieser Zeigt in geänderten Zeilen zusätzlich die\n geänderten Wörter an:\n

git diff --word-diff

\n","slug":"darstellung-von-git-diff-verbessern","hero":"!undefined"}],["default-werte-fur-methoden-argumente-sollten-null-sein",{"title":"Default-Werte für Methoden-Argumente sollten null sein","abstract":"Oft genug sieht man Methodendefinitionen mit Standardwerten für Argumente, da viele Programmiersprachen das Überladen von Methoden, wie z.B. in Java, nicht unterstützen.\n","date":"2011-08-04T00:00:00.000Z","html":"\n

\n Oft genug sieht man Methodendefinitionen mit Standardwerten für Argumente, da\n viele Programmiersprachen das Überladen von Methoden, wie z.B. in Java, nicht\n unterstützen.\n

Ein einfaches Beispiel einer Methode mit zwei optionalen Argumenten:
function connect($host, $port = 1234, $timeout = 60) { ... }

\n Möchte man nun diese Methode verwenden, und den letzten der beiden Parameter\n überschreiben, ist man gezwungen, auch den zweiten an zu geben,
connect('server', 1234, 10);\n

Eigentlich meint man aber
connect('server', {default}, 10);

\n Und genau hier liegt das Problem: das Übernehmen des Standardwertes aus der\n Definition führt dazu, dass bei einer Änderung des Standardwertes sich diese\n Änderung nicht auf den Teil des Codes auswirkt, in dem die Methode aufgerufen\n wird — obwohl das eigentlich das Verhalten ist, dass der Verwender\n erwartet hätte.\n

Deswegen sollten Standardwerte immer mit null definiert werden:

function connect($host, $port = null, $timeout = null) {\n    if ($port === null) $port = 1234;\n    if ($timeout === null) $timeout = 10;\n    ...\n}\n

\n So muss der Aufrufer Standardwerten nur Beachtung schenken, wenn er sie explizit\n überschreiben will. Ansonsten kann er einfach null übergeben:
connect('server', null, 10);\n

\n Übrigens hat Python, in dem das Überladen von Methoden nicht unterstützt wird,\n eine clevere Lösung dafür: beim Aufrufen einer Methode kann man die Argumente\nexplizit mit ihrem Namen ansprechen.\n

\n","slug":"default-werte-fur-methoden-argumente-sollten-null-sein","hero":"!undefined"}],["define-a-communication-policy-so-slack-doesnt-kill-you",{"title":"Define a communication policy so Slack doesn't kill you","subtitle":"Distributed Teams","abstract":"Not matter which tool you use to communicate, one of the most important actions to tackle communication chaos is defining a communication policy.","date":"2017-06-20T10:00+02:00","html":"\n

\n Twist is the Doist team's answer to the overwhelming\n amount of real-time interaction\n they have experienced\n using Slack:\n

\n
\n It wasn’t healthy for our team, and it wasn’t helping us focus on the hard\n work that really moves projects forward.\n
\n

\n Ironically, instead of changing their habits, which are the root cause for their\n issues, they set out to solve the problem by building a new tool, essentially a\n forum, with stricter rules applied to how communication should work.\n

\n Every powerful tool, like Slack, comes with the responsibility to learn how to\n use it properly. And if you do, it's general purpose makes it so easily\n adaptable for many use cases. It's the same with Trello where boards can become\n very chaotic and overwhelming for users that don't know how which features are\n there to organize cards.\n

\n Not matter which tool you use to communicate, one of the most important\n actions to tackle communication chaos is defining a communication policy.\n (You can read about the rules at one of my former workplaces here.)\n This means that you establish a common, (written!), understanding within your\n team, which communication tool you use for what and what the expected response\n times are.\n

Especially for a highly invasive tool like Slack rules like these can help:

\n we don't expect to answer to Slack messages immediately, but within 4 hours on\n a work day\n
\n we use the Do Not Disturb feature to signal if we need uninterrupted time to\n work\n
we don't send Slack messages an Weekends or Holidays
we rarely ever use @channel in general topic channels
we switch to Video Chat if we observe that a ping-pong discussion is happening

\n It's also important to educate every team member about the features of each tool\n to manage notifications, and how to turn them off.\n

\n So the next time when you start blaming a tool for limiting your ability to be\n productive, try taking a step back and find the root cause for the symptom.\n

\n","slug":"define-a-communication-policy-so-slack-doesnt-kill-you","hero":"!undefined"}],["developer-happiness-questionnaire",{"title":"(developer) happiness questionnaire","abstract":"I use the (developer) happiness questionnaire to collect honest feedback about the happiness of my colleagues\n","date":"2016-01-26T15:00:00.000Z","html":"\n

\n I use the (developer) happiness questionnaire to collect honest feedback about\n the happiness of my colleagues. It is based on the book\n First break all the rules by the Gallup Institute but\n has been slightly modified.\n

\n Gallup tested thousands of questions\n on millions of employees to find the right questions with the exact wording that\n provided the highest correlation to business results most companies regularly\n measure — profitability, productivity, turnover, and safety.\n

My modified version alters the phrasing of question 9, which originally reads

\n
Are my associates or fellow employees committed to doing quality work.
\n

This is split into two questions:

\n
\n Are all colleagues working with all their possibilites for the company's\n goal?
Is it favored to deliver high-quality work results?\n
\n

\n This enables to distinguish between individual commitment to qualitity and the\n overall notion about quality throughout the organization.\n

\n A new question is the\n net promotor score for teams:\n

\n
\n If I had a good friend who is looking for a new job, would I recommend them to\n apply here?\n
\n

\n If there is one question that summarizes my understanding of a great place to\n work is: would I want my friends to work here, too?\n

\n I let my colleagues fill out the anonymous form every other month, prior to\n all-hands meetings.\n

\n I use Google Forms and give all colleagues an exact date and time when to fill\n out the form. This disables any form of tracking / assigning individual answers\n to team members.\n

\n During the all-hands meeting we go through the (accumulated) results and talk\n about what we can do to improve the ratings. The discussion alone is brilliant\n and the questionnaire is a great starter for this (necessary) discussion.\n Nevertheless, it helps you to keep track of the progress in tackling the issues\n that arise.\n

\n These are the 14 questions, I've also translated them into German for a better\n understanding. Questions are answered in a range between 1 to 10. I keep the\n resulting median of all answers in a wiki as a history.\n

\n
Do I know what is expected of me at work?
Weiß ich, was man von mir auf der Arbeit erwartet?
\n
\n
Do I have the materials and equipment I need to do my work right?
Verfüge ich über die Mittel und Ausstattung um meine Arbeit richtig zu\nmachen?
\n
\n
Do I have the opportunity to do what I do best everyday?
Habe ich jeden Tag die Gelegenheit, mein Bestes zu geben?
\n
\n
\n In the last 7 days, have I received recognition or praise for doing good\n work?
Habe ich in den letzten 7 Tagen Anerkennung oder Lob für meine Arbeit\nerhalten?\n
\n
\n
Does my supervisor or someone at work seem to care about me as a person?
Schätzt mich mein Vorgesetzter oder jemand anderes auf der Arbeit als\nPerson?
\n
\n
Is there someone at work who encourages my development?
Gibt es jemanden auf der Arbeit, der mich zur Weiterentwicklung ermutigt?
\n
\n
At work, do my opinions seem to count?
Wird meine Meinung auf der Arbeit gewürdigt?
\n
\n
Does the mission / purpose of my company make me feel my job is important?
Gibt mir das Unternehmensziel das Gefühl, einen wichtigen Job zumachen?
\n
\n
\n Are all colleagues working with all their possibilites for the company's\n goal?
Engagieren sich alle Mitarbeiter voll für das Unternehmensziel?\n
\n
\n
Is it favored to deliver high-quality work results?
Ist es gewünscht, dass qualitativ hochwertige Arbeitsergebnisse erzielt\nwerden?
\n
\n
Am I confident that the company's goals are actually achievable?
Bin ich davon überzeugt, dass das gesteckte Unternehmensziel erreicht\nwerden kann?
\n
\n
In the last 6 months, has someone talked to me about my progress?
Hat jemand in den letzten 6 Monaten mit mir über meinen Fortschritt\ngesprochen?
\n
\n
Do I have the opportunity at work to learn and grow?
Habe ich die Möglichkeit auf der Arbeit zu lernen und mich weiter zu\nentwickeln?
\n
\n
\n If I had a good friend who is looking for a new job, would I recommend them\n to apply here?
Würde ich einem guten Freund/in, der/die auf Jobsuche ist, empfehlen sich\nhier zu bewerben?\n
\n

\n","slug":"developer-happiness-questionnaire","hero":"!undefined"}],["die-browserkompatibilitatsklausel",{"title":"Die Browserkompatibilitätsklausel","abstract":"Wenn man in der glücklichen Situation ist, ein Angebot zu schreiben, ist dessen Basis in der Regel auch eine möglichst genaue Beschreibung über den Umfang des Auftrags, im Allgemeinen Pflichtenheft genannt.","date":"2011-10-09T00:00:00.000Z","lang":"de","html":"\n

\n Wenn man in der glücklichen Situation ist, ein Angebot zu schreiben, ist dessen\n Basis in der Regel auch eine möglichst genaue Beschreibung über den Umfang des\n Auftrags, im Allgemeinen Pflichtenheft genannt.\n

\n Die Ausformulierung ist dabei entscheidend um im Fall von\n Meinungsverschiedenheiten klar bestimmen zu können, welche Partei Recht hat.\n Speziell bei Software kann aber die Beschreibung von Funktionen oft nicht exakt\n erfolgen — läuft die Software in einem vorher nicht genau bekannten Umfeld\n trifft man unweigerlich auf dieses Problem.\n

\n Die Regel ist das bei Anwendungen, die im Webbrowser dargestellt werden. Die\n Vielzahl existierender Browser und Platformen macht es praktisch unmöglich, die\n exakte Darstellung in verschiedenen Browsern zu garantieren. Dieser Umstand\n ist allgemein akzeptiert und inzwischen existiert das Bewußtsein dafür auch auf\n Kundenseite.\n

Wie aber formuliert man solche “Ungenauigkeiten” möglichst genau?

Den folgenden Absatz verwende ich in Pflichtenheften.

\n
Browser-Unterstützung
\n
Unterstützt werden:
\n
\n
Internet-Explorer 7-9
\n
Firefox 3.6-6
\n
Safari 5
\n
\n
\n Browser-Unterstützung, der aufgelisteten Browser und Versionen, bedeutet, dass\n die volle Funktionalität der Anwendung in diesen Browsern gewährleistet ist.\n Eine pixelgenaue, identische Darstellung in allen Browsern und unter allen\n Plattformen kann nicht gewährleistet werden, jedoch wird eine, im Sinne der\n Gestaltung und aus Sicht des Benutzers, fehlerfreie Darstellung angestrebt.\n
\n
Eine Plattform ist ein Computer, Smartphone, Spielekonsole etc.
\n

\n Die Wahl der Browser und Versionen ist dabei natürlich an das jeweilige Projekt\n angepasst. Als Faustregel sollte man die Browserversionen unterstützen, die in\n den Webserverstatistiken der Website (falls vorhanden) von mehr als 3% der\n Besucher verwendet werden — eine Ausnahme ist hier der IE6, eine Unterstützung\n für diesen Browser sollte in der Aufwandsschätzung für die Umsetzung in HTML und\n JS mit einem Aufschlag von 30% berücksichtigt werden.\n

\n Wichtig ist noch, dass man auf keinen Fall eine Aufwärtskompatibilität\n garantieren darf, z.B. mit Formulierungen wie “IE 9+”, dies führt zu\n unkalkulierbaren Aufwänden, und der Kunde hat den Eindruck, dass seine Website\n auch noch in 10 Jahren einwandfrei funktionieren wird.\n

\n","slug":"die-browserkompatibilitatsklausel","hero":"!undefined"}],["distributeaid-contributor-spotlight",{"subtitle":"Impact","title":"Why I contribute to DistributeAid","abstract":"In this post I introduce myself for a DistributeAid contributor spotlight and talk about the work I do for the non-profit.","date":"2022-03-14T21:00:00.000Z","html":"\n

\n
\n In this post I introduce myself for a\n DistributeAid contributor spotlight and talk\n about the work I do for the non-profit.\n
\n

\n I first heard about DistributeAid at Øredev 2019 in Malmö, and was immediately\n inspired by their idea to use technology to improve the distribution of donated\n goods for displaced people. And in the last three years we have seen that the\n network of grassroots organizations which DistributeAid supports is needed to\n help people who have been affected by political and ecological disasters, caused\n after all by the global north, which I have the privilege and luck to be born\n in. Besides the ongoing imprisonment of migrants and asylum-seekers on the\n southern European borders, DistributeAid's team helped with logistics during the\n COVID-19 pandemic in Europe and the United States. And most recently got\n involved in welcoming Afghan families to the United States after Kabul was taken\n over by the Taliban in 2021. The invasion of Ukraine by the Russian dictator\n Putin in 2022 created yet another region where DistributeAid is involved to\n provide people with basic everyday items.\n

\n As a code contributor to DistributeAid's projects, which you can find on their\n GitHub repository github.com/distributeaid,\n I can work on digital tools that are used to achieve the organization's goals. I\n worked on a digital COVID-19 guide for aid organizations, integrated APIs from\n shipping partners, and most recently built a low-code tools used to assess the\n needs of aid groups they support. I enjoy that DistributeAid has a people-first\n approach to contributions and we try to provide software projects that are both\n easy to get started with and easy to change. After all, done is better than\n perfect and areas of focus can change quickly. Because we contributors are\n distributed around the world, we need to keep our codebases well in shape, which\n means that we write a lot of tests, and keep our documentation up to date, so\n others can contribute big and small features without needing to be in the loop\n constantly and new contributes can start with smaller items quickly.\n

\n What has kept me engaged with DistributeAid over nearly three years now is\n knowing that the code that I write is making a difference. And I am extremely\n impressed by Sara, Taylor and many other contributors who put their professional\n skills into this project without making this about themselves. Everyone is\n extremely humble and helpful. I wish all tech projects could be like this. And\n then I wish we wouldn't need DistributeAid. This is the dichotomy we all face\n when engaging with DistributAid. But this team has your back, because everyone\n knows that you can't burn the candle at both ends and you need to be in good\n mental state, before you can help others.\n

\n If you are interested to contribute to our projects, just reach out to me, or\n any other Distribute Aid team member!\n

\n","slug":"distributeaid-contributor-spotlight","hero":"!undefined"}],["do-not-change-two-different-things-in-one-pull-request",{"title":"Do not change two different things in one Pull Request","subtitle":"Best practice","abstract":"A pull request should only address one change at a time.","date":"2026-01-02T00:10:00+01:00","html":"\n

A Pull Request should only address one change at a time.

\n Reviewers might not have an in-depth understanding of how things relate to each\n other in a project so do not mix conceptually different changes in one PR.\n

Some examples of what not to do:

\n fix a bug AND update all dependencies. If a bug fix requires a new dependency\n or an update to one, then only add this single dependency change.\n
\n implement a new feature AND fix a small bug on an unrelated file. Those should\n be two PRs.\n

\n","slug":"do-not-change-two-different-things-in-one-pull-request","hero":"!undefined"}],["do-not-expect-an-llm-to-think",{"title":"Do not expect an LLM to think","subtitle":"Lessons learned","abstract":"LLMs are excellent at scaffolding code that follows an existing pattern. They are not equipped to design new domain concepts. When you let one do design work, you get code that looks right, tests that pass, and an implementation that quietly misses the point. Worse: you own none of the understanding, so when something breaks, you're debugging a library you didn't write.","date":"2026-05-14T11:37:00+02:00","html":"\n

\n
\n tl;dr LLMs are excellent at scaffolding code that follows an existing\n pattern. They are not equipped to design new domain concepts. When you let one\n do design work, you get code that looks right, tests that pass, and an\n implementation that quietly misses the point. Worse: you own none of the\n understanding, so when something breaks, you're debugging a library you didn't\n write.\n
\n

\n When all the tests are green but the implementation is wrong, you have a\n problem. And you have made that problem yourself.\n

\n This week I introduced a new concept into an existing billing system. We\n currently bill on a per-project basis. The new requirement was to introduce\n organizations: an organization owns multiple projects, and instead of one\n invoice per project, the organization owner gets a single consolidated invoice.\n

Same billing rules. Same pricing logic. Just applied to a higher-level entity.

\n The existing implementation was well-tested and solid. This looked like a\n perfect LLM task: the pattern is established, the tests are clear, the scope is\n bounded. I asked the LLM to introduce the organization concept, told it to look\n at the existing tests, and make it work for an organization owning multiple\n projects.\n

\n The initial results were promising. New modules, new method names, new test\n files, good coverage. There was a small bit of hand-holding needed around how we\n identify organizations—they use a different ID format than projects—but overall\n it looked like a win.\n

\n Then I started wiring the new domain logic into the actual consumers, and the\n cracks appeared.\n

The tests were lying

\n The issues were not dramatic. No obvious failures. They were subtle—quiet\n mismatches between what the tests assumed and what the business actually\n required. I went back to the domain implementation to fix something. Then again.\n Then again. Four times in total.\n

\n A concrete example: our billing has a minimum charge rule. If your total monthly\n usage comes to less than $2.00, you still pay $2.00.\n

\n In the per-project billing, this is simple: sum the usage, apply the rate, check\n against the floor. The LLM ported this rule to the organization level by\n applying it per project. Three projects using\n $0.10 each would result in a\n $6.00 bill instead of $2.00, because each project\n individually hits the minimum.\n

\n The minimum charge belongs on the organization invoice—the thing the customer\n actually pays—not on each individual project. But the concept of the invoice\n was implicit in the per-project implementation. It was just the natural unit. At\n the organization level it becomes a derived concept, only meaningful after\n summing across all projects. The LLM didn't understand that this rule needed to\n be lifted to a higher abstraction level. It only saw the mechanics: here is a\n rule, apply it at each step.\n

\n The tests didn't catch this because the generated test data wasn't adversarial.\n Two projects, charges above the minimum, everything sums correctly—all green.\n The discrepancy only surfaced when I ran real customer usage data through both\n the old and new implementations side by side.\n

Debugging code you didn't write

What I underestimated is the cost of not having written the code yourself.

\n Every time I hit a bug I was in the position of debugging a third-party library\n I didn't write and don't fully understand. I'd look at the symptom, form a\n hypothesis, and ask the LLM for a targeted fix—without truly grasping whether\n that fix would hold in other situations. This is the console.log debugging\n mode: poking at the surface, observing behavior, inferring structure. Slow,\n fragile, and deeply unsatisfying.\n

\n A feedback loop makes it worse: each fix feels small. Just change this one\nthing, then it will work. So you keep delegating back to the LLM. But the LLM\n can only act on what you describe. It doesn't understand your goal—it\n understands your instruction. It will dutifully add a parameter, loop over\n projects, apply the calculation, and miss the point entirely.\n

Scaffolding vs. design

The mistake was misclassifying the task.

\n There are things LLMs are excellent at in an existing codebase. Scaffolding a\n new REST route that follows the same pattern as the 25 others in the project?\n Perfect. Generate the handler, the CDK construct, wire it into the existing\n infrastructure. The output is obviously correct by inspection because the\n pattern is unambiguous.\n

\n Introducing a new domain concept that changes how the entire billing model is\n structured is a design task. It requires understanding intent. It requires\n knowing which implicit assumptions need to become explicit, which rules belong\n at which level of abstraction, what the code is for—not just what it does.\n

LLMs can replicate structure. They cannot reason about intent.

What I should have done

Written it myself.

\n Not because the LLM couldn't produce working-looking code—it clearly could. But\n because the process of writing domain logic is how you discover the domain.\n The resistance you feel when you try to implement a rule at the wrong\n abstraction level, the moment you realize the minimum charge can't live on the\n project anymore—those are discoveries that only happen when you are making the\n decisions.\n

\n By outsourcing the implementation, I outsourced the understanding. And\n understanding is not optional when things go wrong.\n

\n The LLM saved me roughly two hours of initial implementation and cost me several\n times that in confused debugging and rework. The irony is that the task that\n looked most suited to LLM delegation—structured, well-precedented, bounded—\n turned out to require exactly the kind of judgment LLMs don't have.\n

Use an LLM to follow a pattern. Don't use it to design one.

\n","slug":"do-not-expect-an-llm-to-think","hero":"!undefined"}],["dont-use-global-state-like-env-vars-in-modules",{"title":"Don't use global state like env variables in modules","subtitle":"Best practice","abstract":"This hides dependencies to configuration values and makes them hard to spot.","date":"2025-12-28T12:38+01:00","html":"\n

\n Don't use global state like env variables in modules, only on the very top-level\n or in one central location. Pass it in the constructor.\n

This hides dependencies to configuration values and makes them hard to spot.

Bad

class Foo {\n  doSomething() {\n    console.log(process.env.MY_ENV);\n  }\n}\n\nnew Foo().doSomething();\n

Good

class Foo {\n  constructor(myEnv) {\n    this.myEnv = myEnv;\n  }\n  doSomething() {\n    console.log(this.myEnv);\n  }\n}\n\nnew Foo(process.env.MY_ENV).doSomething();\n

\n","slug":"dont-use-global-state-like-env-vars-in-modules","hero":"!undefined"}],["duplicity-fehler-ioerror-gnupg-exited-non-zero-with-code-2-unter-ubuntu-beheben",{"title":"duplicity Fehler “IOError: GnuPG exited non-zero, with code 2” unter Ubuntu beheben","abstract":"Zum Sichern von Daten auf FTP-Server bietet sich duplicity. Es bietet, ähnlich wie rdiff-backup, die Möglichkeit, volle und inkrementelle Backups zu erzeugen, aber im Gegensatz zu rdiff-Backup eben auf FTP-Server und noch dazu verschlüsselt.","date":"2010-05-09T00:00:00.000Z","lang":"de","html":"\n

\n Zum Sichern von Daten auf FTP-Server bietet sich duplicity. Es bietet,\n ähnlich wie rdiff-backup, die Möglichkeit, volle und inkrementelle Backups\n zu erzeugen, aber im Gegensatz zu rdiff-Backup eben auf FTP-Server und noch dazu\n verschlüsselt.\n

\n Allerdings hat die Version in Ubuntu 9.04 (Jaunty Jackalope) einen Bug, der\n bewirkt, dass duplicity mit folgender Fehlermeldung den Dienst quittiert:\n

IOError: GnuPG exited non-zero, with code 2\n

Das lässt sich relativ einfach beheben: duplicity manuell installieren.

Dazu geht man wie folgt vor:

Ubuntu's duplicity entfernen:

aptitude purge duplicity\n

python-dev und librsync-dev werden zum kompilieren von duplicity benötigt:

aptitude install python-dev librsync-dev\n

Die aktuelle Version herunterladen und installieren

cd /opt\nwget http://code.launchpad.net/duplicity/0.6-series/0.6.08b/+download/duplicity-0.6.08b.tar.gz\ntar xvzf duplicity-0.6.08b.tar.gz\ncd duplicity-0.6.08b\npython setup.py install\n

Nun ist duplicity installiert.

\n Tritt der Fehler auf, nachdem bereits eine Weile das Backup problemlos\n funktioniert hat, muss man die alten Dateien leider entsorgen und mit einem\n neuen Full-Backup starten.\n

\n","slug":"duplicity-fehler-ioerror-gnupg-exited-non-zero-with-code-2-unter-ubuntu-beheben","hero":"!undefined"}],["eclipse-clean-refresh",{"title":"Eclipse: -clean -refresh","abstract":"Manchmal, also eigentlich regelmäßig, hängt Eclipse.","date":"2010-12-21T00:00:00.000Z","lang":"de","html":"\n

Manchmal, also eigentlich regelmäßig, hängt Eclipse.

\n
The User Operation is waiting for background work to complete
\n

\n oder ähnliche extrem hilfreiche Statusmeldungen hängen dann gerne mal\n ungefragt bis zum Sankt-Nimmerleins-Tag auf dem Bildschirm rum.\n

Da hilft nur ein

\n
eclipse -clean -refresh
\n

\n Das dauert zwar etwas länger, beseitigt aber z.B. Deadlocks, die für die Hänger\n verantwortlich sind.\n

\n","slug":"eclipse-clean-refresh","hero":"!undefined"}],["eclipse-standard-wert-fur-author-in-javadoc-andern",{"title":"Eclipse: Standard-Wert für @author in JavaDoc ändern","abstract":"Der Standard-Werte für den @author-Tag in JavaDoc ist der Username des Accounts, der Eclipse gestartet hat.","date":"2010-06-13T00:00:00.000Z","lang":"de","html":"\n

\n Der Standard-Werte für den @author-Tag in JavaDoc ist der Username des\n Accounts, der Eclipse gestartet hat.\n

\n Dies lässt sich einfach überschreiben, in dem man in der\n eclipse.ini, die sich im Programm-Ordner\n von eclipse findet, diese Zeile einfügt:\n

-Duser.name=Some User <someuser@example.com>\n

\n","slug":"eclipse-standard-wert-fur-author-in-javadoc-andern","hero":"!undefined"}],["encrypt-login-links",{"title":"Encrypt Login Links","abstract":"Encrypt login links with the users public PGP key to add a simple but effective layer of security with only a small usability impact.\n","date":"2015-01-03T16:40:00.000Z","html":"\n

\n I believe that logging into a web based application using a username and a\n password should be abolished. If you want to learn more about the advantages of\npassword-less logins, read this article.\n

\n If you implement a password-less login, your users will receive a login link in\n ther email inbox which will be valid for some time.\n

\n Unfortunately this creates a potential attack surface as anyone who has access\n to the user's mailbox or can intercept unecrypted communication of the users\n email client with their mailserver can use the link to access their account.\n There are various options to ensure that an attacker can do nothing harmful with\n the access to a users account (like creating extra out-of-band challenges for\n dangerious account modifications) but there exists an easy one: encrypt the\nlogin link with the users public PGP key.\n

\n If a user knows how to handle PGP you should provide an option in the\n application's dashboard to provide his public PGP key for his account. Make sure\n you verify this key bevore using it, though. Once enabled this adds a simple but\n effective layer of security with only a small usability impact.\n

\n","slug":"encrypt-login-links","hero":"!undefined"}],["entwickler-und-projektmanager",{"title":"Entwickler und Projektmanager","abstract":"Diese zwei Kollegen stehen immer auf meinem Schreibtisch bei meinem aktuellen Arbeitgeber. Vor ein paar Monaten standen sie bei Scholz&Volkmer und als ich mit einem Kollegen darüber sprach, ist ein interessantes Bildnis entstanden.","date":"2011-11-24T00:00:00.000Z","lang":"de","html":"\n

\n $\"Entwickler$ Diese\n zwei Kollegen stehen immer auf meinem Schreibtisch bei meinem aktuellen\n Arbeitgeber. Vor ein paar Monaten standen sie bei\n Scholz&Volkmer und\n als ich mit einem Kollegen darüber sprach, ist ein interessantes Bildnis\n entstanden.\n

\n Der Große (der Marine aus dem Computerspiel “Quake II”) ist ein Entwickler:\n ziemlich grobschlächtig mit dem Hang zu schnellen einfachen Lösungen, aber halt\n für die dreckige Aufgabe des codens bestens geeignet — die Waffe benutzt er um\n Bugs zu töten.\n

\n Aber ohne den Projektmanager davor ist der Entwickler aufgeschmissen. Mit\n seiner Lampe sucht und findet der Projektmanager Bugs und weißt dem Entwickler\n den Weg durch den Projektdschungel. Die Schutzausrüstung braucht er dabei vor\n allem im Umgang mit dem Kunden — das kann nämlich manchmal sehr giftig werden.\n

\n Wichtig dabei ist aber, dass beide nur gut als Team funktionieren können, weil\n sie sich so gut ergänzen — arbeiten sie nicht zusammen, oder sogar\n gegeneinander, wird die Arbeit am Projekt viel schwieriger als nötig.\n

\n","slug":"entwickler-und-projektmanager","hero":"!undefined"}],["es-and-cqrs-on-aws-simplified",{"title":"ES+CQRS on AWS: the simplest version yet","abstract":"I have been iterating on Event Sourcing and CQRS architectures for nearly a decade. When I first started with this pattern around 2016 and 2017, the implementation was considerably more complex — a lot of ceremony, a lot of infrastructure, and a lot of things that could go wrong. Over the years I have stripped it back again and again, and what I have arrived at now is something I'm genuinely happy with: a small, focused TypeScript library backed by DynamoDB that does exactly what it needs to and nothing more.","date":"2026-05-17T15:00:00+02:00","html":"\n

\n I have been iterating on Event Sourcing and CQRS architectures for nearly a\n decade. When I first started with this pattern around 2016 and 2017, the\n implementation was considerably more complex — a lot of ceremony, a lot of\n infrastructure, and a lot of things that could go wrong. Over the years I have\n stripped it back again and again, and what I have arrived at now is something\n I'm genuinely happy with: a small, focused TypeScript library backed by DynamoDB\n that does exactly what it needs to and nothing more.\n

\n The code is available at\n github.com/coderbyheart/aws-dynamodb-es-cqrs.\n

What ES+CQRS gives you

\n The core idea is simple: instead of storing the current state of a thing, you\n store the sequence of events that produced that state. Event Sourcing (ES) is\n the \"store events\" part. CQRS (Command Query Responsibility Segregation) is the\n recognition that writing and reading are fundamentally different concerns that\n benefit from being handled separately.\n

\n In practice this means that when someone publishes a blog post, you don't update\n a published = true column. You append a BlogPostPublished event to the event\n log. The current state — the aggregate — is derived by replaying those events.\n This gives you a full audit trail for free, the ability to rebuild projections,\n and a natural boundary for business logic.\n

The anatomy of an event

\n Every event in the system is an AggregateEvent. The type is intentionally\n minimal:\n

export type AggregateEvent = {\n  eventId: ULID;\n  eventName: string;\n  aggregateName: string;\n  aggregateId: ULID;\n  aggregateVersion: AggregateVersion;\n  actorId: string;\n};\n

\n A few things worth noting here. eventId and aggregateId use\n ULIDs — universally unique, lexicographically\n sortable identifiers. This means events stored in DynamoDB are naturally ordered\n by creation time without needing a separate timestamp index. aggregateVersion\n is an incrementing integer that starts at 1 and tracks how many events have\n been applied to a given aggregate. actorId records who or what triggered the\n event.\n

\n Domain events extend this base type and add their own payload fields. A\n BlogPostCreatedEvent, for example, adds title and whatever else the domain\n needs.\n

Reducing events to state

\n The event sourcing half of the pattern lives in reduceEvents. It takes an\n applyEvent function and returns a function that folds a list of events into an\n aggregate:\n

export const reduceEvents =\n  <A extends Record<string, any> & { $meta: AggregateMeta }>(\n    applyEvent: ApplyEventFn<A>,\n  ): ApplyEventsFn<A> =>\n  (events: Array<AggregateEvent>, aggregate?: A) => {\n    if (events.length === 0) throw new Error(\"No events to reduce!\");\n    return events.reduce<A | undefined>((agg, event) => {\n      const result = applyEvent(event, agg);\n      if (result === undefined)\n        throw new Error(\n          `Unhandled event: ${event.eventName} (aggregateVersion: ${event.aggregateVersion})`,\n        );\n      return result;\n    }, aggregate) as A;\n  };\n

\n The domain-specific reducer wires this together. The blog post reducer handles\n three events — created, published, and title changed — using typed event guards\n (isNamedEvent) and assertions (assertAggregateEvent) to make the TypeScript\n types precise:\n

export const blogpostReducer = reduceEvents<BlogPostAggregate>(\n  (event, aggregate) => {\n    if (isBlogPostCreatedEvent(event)) {\n      return {\n        $meta: fromEvent(event),\n        authorId: event.actorId,\n        title: event.title,\n      };\n    }\n    if (isBlogPostPublishedEvent(event)) {\n      assertAggregateEvent(aggregate, event);\n      return {\n        ...aggregate,\n        $meta: updateFromEvent(aggregate.$meta, event),\n        isPublic: true,\n      };\n    }\n    if (isBlogPostTitleChangedEvent(event)) {\n      assertAggregateEvent(aggregate, event);\n      return {\n        ...aggregate,\n        $meta: updateFromEvent(aggregate.$meta, event),\n        title: event.title,\n      };\n    }\n    return undefined;\n  },\n);\n

\n The assertAggregateEvent call on the update and publish handlers is doing\n something important: it verifies that an aggregate already exists before trying\n to apply a state-changing event. You cannot publish a blog post that was never\n created.\n

Commands: the write side

\n Commands live on the write side of the CQRS split. They are plain async\n functions that take some input and a persistence function, validate\n preconditions against the current aggregate state, produce an event, apply it\n through the reducer, persist both the resulting aggregate and the event, and\n return the updated aggregate.\n

Here is what creating a blog post looks like:

export const createBlogPostCommand =\n  (\n    persistBlogPost: PersistBlogPostFn,\n    reducer: ApplyEventsFn<BlogPostAggregate>,\n  ) =>\n  async (\n    data: Omit<BlogPostAggregate, \"$meta\" | \"authorId\">,\n    actorId: string,\n  ): Promise<BlogPostAggregate> => {\n    const id = ulid() as ULID;\n    const event: BlogPostCreatedEvent = {\n      eventId: ulid() as ULID,\n      eventName: EventNames.BlogPostCreated,\n      aggregateName: AggregateNames.BlogPost,\n      aggregateId: id,\n      aggregateVersion: v1,\n      actorId,\n      ...data,\n    };\n    const applied = reducer([event]);\n    await persistBlogPost(applied, event);\n    return applied;\n  };\n

\n The reducer is injected alongside the persist function rather than imported\n directly. This keeps commands decoupled from any specific reducer implementation\n and makes them straightforward to test in isolation. A command for updating an\n existing aggregate (like publishBlogPostCommand) follows the same pattern:\n inject both the persist function and the reducer, load the current state, verify\n preconditions, produce a new event at the next version. Concurrency conflicts\n are detected at the persistence layer using optimistic locking, so you get a\n ConflictError if two commands race on the same aggregate.\n

Persistence: one transaction, two tables

\n The most interesting part of this design is the persistence layer. Everything\n happens in a single DynamoDB TransactWriteItems call that touches two tables\n atomically:\n

\n
\n The aggregate table is upserted with an optimistic concurrency check. For\n a new aggregate, the condition is attribute_not_exists(aggregateId). For an\n update, it is #version = :prevVersion. If either condition fails, DynamoDB\n cancels the whole transaction and the application surfaces a conflict error.\n
\n
\n
\n The events table receives a new Put item containing the full event\n payload, plus a derived eventTs (an ISO timestamp decoded from the ULID)\n for convenience.\n
\n

\n The error handling checks cancellation reasons across both transaction slots — a\n DuplicateItem on the events table (index 1) is just as meaningful as a\n ConditionalCheckFailed on the aggregate (index 0), and both produce an\n actionable error rather than a raw SDK exception:\n

await db.send(\n  new TransactWriteItemsCommand({\n    TransactItems: [\n      { Update: toUpdate(aggregate, aggregateTableName) },\n      {\n        Put: {\n          TableName: eventsTableName,\n          Item: marshall(\n            {\n              ...event,\n              eventTs: new Date(decodeTime(event.eventId)).toISOString(),\n            },\n            { removeUndefinedValues: true },\n          ),\n        },\n      },\n    ],\n  }),\n);\n// ...\nif (err instanceof TransactionCanceledException) {\n  if (err.CancellationReasons?.[0]?.Code === \"ConditionalCheckFailed\") {\n    throw new Error(\n      `Failed to persist \"${aggregate.$meta.id}\" due to version conflict!`,\n    );\n  }\n  if (\n    err.CancellationReasons?.[0]?.Code === \"DuplicateItem\" ||\n    err.CancellationReasons?.[1]?.Code === \"DuplicateItem\"\n  ) {\n    throw new Error(\n      `Failed to persist \"${aggregate.$meta.id}\" due to duplicate item!`,\n    );\n  }\n}\n

\n Because the aggregate and the event are written in one transaction, they are\n always in sync. You never end up in a state where an event was recorded but the\n aggregate was not updated, or vice versa.\n

The read side

\n Queries are entirely separate from commands — that is the whole point of the CQR\n split. The read side has two shapes:\n

\n Current state — fetch the latest aggregate projection directly from the\n aggregate table. Because persistDynamoDB keeps the aggregate table current on\n every write, reads are a simple GetItem or Query against a well-known key\n schema. No event replay needed at query time.\n

\n Event stream — use listAggregateEventsDynamoDB to retrieve all events for\n a given aggregate in order. This is useful for rebuilding projections, feeding\n downstream consumers, or debugging. DynamoDB Streams integration is also\n covered: extractEventsFromDynamoDBEvent parses stream records back into typed\n AggregateEvent objects so they can be forwarded to Lambda functions or other\n processors.\n

What makes this simpler than the 2016 version

\n The earlier versions of this pattern wrote the event to the event store first,\n then relied on a separate asynchronous step — typically a DynamoDB Stream\n feeding a Lambda — to update the aggregate projection. This worked, but it\n created three problems that I kept having to work around.\n

\n The first was a window of inconsistency. Between the moment an event was\n written and the moment the Lambda finished updating the aggregate, the two\n stores were out of sync. In practice this window was small, but it was real. If\n the Lambda failed — a cold start timeout, a throttle, a transient DynamoDB error\n — the aggregate could end up permanently behind the event log. You needed\n dead-letter queues, retry logic, and monitoring to catch and recover from these\n failures.\n

\n The second was latency on the read side. Because the aggregate projection\n was updated asynchronously, a caller that wrote an event and immediately read\n back the aggregate might get stale data. You had to either accept eventual\n consistency or build compensating logic to handle it.\n

\n The third was CDK infrastructure overhead. Every aggregate needed a Stream\n enabled on its events table, a Lambda to consume it, an event source mapping,\n IAM roles, a DLQ, and CloudWatch alarms. This was not a huge amount of code, but\n it added up and it was all load-bearing — getting any of it wrong meant silent\n data loss.\n

\n The current approach sidesteps all of this with a single TransactWriteItems\n call. The event and the aggregate projection are written atomically. Either both\n succeed or neither does. There is no async gap, no eventual consistency on the\n write path, and no extra CDK constructs to manage. The aggregate table is always\n in sync with the event store by construction.\n

\n The tradeoff is that you give up the ability to fan out to multiple projections\n in the same write path — but in practice I have found that DynamoDB Streams off\n the events table is still the right mechanism for that, and you can add it when\n you actually need it rather than building it upfront for every aggregate.\n

\n The full source, including a working test suite that runs against DynamoDB\n Local, is at\n github.com/coderbyheart/aws-dynamodb-es-cqrs.\n The package is also published to npm as\n @coderbyheart/aws-dynamodb-es-cqrs\n if you want to use it directly.\n

\n","slug":"es-and-cqrs-on-aws-simplified","hero":"!undefined"}],["european-testing-conference-2018",{"title":"European Testing Conference 2018","subtitle":"Conferences","abstract":"A retrospective on what I learned during the European Testing Conference 2018 in Amsterdam","date":"2018-02-21T09:00+01:00","html":"\n

\n This week I went to the beautiful city of Amsterdam to attend the\n European Testing Conference 2018.\n This conference hasn't been on my radar previously, but what caught my attention\n was the level of detail the organizers (most notably Franzi and Maaret put\n into creating an attendee-focused, inclusive and diverse event.\n

https://twitter.com/lisacrispin/status/965498092429684738

\n I initially had submitted an older talk if mine on testing REST-APIs\n using BDD which was not accepted, but the experience during the submission\n process made me want to go to this conference any way.\n

https://twitter.com/maaretp/status/900672218816032768

\n Other than my usual conferences, the ticket price was\n notable (800 €) but given the fact the this conference offered free tickets to\n underrepresented groups, organized child care, and paid their speakers. This is\n (unfortunately) exceptional! I was happy to use the conference budget my\n employer Nordic Semiconductor grants us to support this!\n

https://twitter.com/EuroTestingConf/status/936305287308472320

https://twitter.com/AdharaIT/status/958464191135977473

What did I learn?

\n The two-day programme was a great mixture of up-front keynotes, talks, and\n workshops as well as interactive sessions. The keynotes were carefully selected\n to not be vendor-sales-pitches but focus on high level ideas about testing,\n communication and team-dynamics.\n

Keynotes

\n Gojko Adzic explained that we are seeing a\n revolution in the field of UI testing.\n

https://twitter.coderbyheart.com/status/965511538059726848

This was very insightful since I grew up with the notion in mind:

\n It looks like it's time to rethink this paradigm. Tools like the one Gojko wrote\n (an open-source tool called Appraise)\n or payed tools like Applitools which i learned about\n from another participant during the networking session are greatly simplifying\n visual testing.\n

\n Lanette Creamer spoke about the importance\n of communication and how to better understand and improve the skills as a\n tester. Although this talk was mainly geared towards testers, I still enjoyed\n her insights into what it means to be a tester and improved my understanding of\n this role.\n

https://twitter.coderbyheart.com/status/965622543557283843

\n Zeger van Hese held a great keynote on\n being a sceptic. He stressed the point that it is important to (constantly)\n question information you have been given in order keep making the best\n decisions.\n

https://twitter.coderbyheart.com/status/965870628048957440

\n He recommended\n a set of context-free questions\n to identify important aspects about a project in an unbiased way.\n

\n The closing keynote by Pamela Gay was\n meticulously executed and fascinating from beginning to end. It provided a great\n insight into the work of the Cosmoquest project,\n which uses crowd-sourced data to solve mission-critical problems in\n space-travel. One might think that it's a long stretch to testing but the\n learning of this talk for me was:\n

https://twitter.coderbyheart.com/status/965984483370569728

\n Ergo, not all problems can be solved using software. A great reminder to stay\n humble.\n

Talks

\n There were four talk slots, each with four talks in parallel. I attended three\n of them, since I spent most of the fourth talk time talking with other\n attendees.\n

https://twitter.coderbyheart.com/status/965913802951790592

\n In this highly interesting talk Matthew Butt\n explained his way to enable testing in software that depends on services, which\n cannot be run locally. Since cloud-based services (like machine-learning) is\n becoming more and more coming, we have parts in our software which can not\n longer be run locally on a developer machine (e.g. for legal reasons). What to\n do if the provider does not provide a test-environment / stub for this service?\n Adapters, all the way. IMO this concept is getting to few attention. We are\n happily following the\n SOLID\n principle, but we are pulling interfaces from dependencies into our\n implementation. If we write adapters for them we can hide implementation detail\n of a service behind an easier (to mock) interface and can simplify testing of\n individual components. Matthew did a good job in illustrating this. You can find\n his slides\n here.\n

https://twitter.coderbyheart.com/status/965590736669413378

\n The talk was a tester's perspective of working with microservices, which\n provided some value for me since Emily was concerned with orchestrating the\n collaboration between different teams working in with a microservice\n architecture. Most important takeaway from her talk: version your microservices\n so other teams or individuals can run integration tests and teams are\n responsible to run the integration tests with their latest code, otherwise there\n will be pain.\n

https://twitter.coderbyheart.com/status/965517620396134400

\n Albeit providing no new insights to me, Lynoure tried to take a new angle on\n explaining how to write tests: the mindset you put yourself in. Start from the\n most minimal example you can think of and then stop and go talk to your\n (business) stakeholders to actually figure out what the component you are about\n to write is actually supposed to do. Don't let yourself get drawn into the\n rabbit hole of writing too much, and too complete software. Because you can\n never know when you are done on your own, and the more code gets written, the\n more resistance to change is becoming ingrained.\n

Workshops

\n There were five workshops which were repeated on both days. This reduced the\n FOMO significantly and I\n attended a workshop on BDD and one on Test Specification.\n

\n In Vernon Richard's workshop on Scripted vs. Exploratory testing we got to\n experience the pain of scripted testing first hand.\n

https://twitter.coderbyheart.com/status/965564137890828291

\n We\n were given\n an outdated test script and tasked with testing a changed UI. This was no fun.\n

\n $\"PAIN\"$ \n

\n After 30 minutes we switched to persona based testing, where we used the persona\n to test a different website. Also we made significantly more progress here, and\n it was way less mind-numbing, it still had a flaw: the persona was lacking a\n clear goal, so it was not possible to evaluate whether the website under test\n passed or failed.\n

\n Obviously the workshop was meant to show us the difference in these testing\n methods through first hand experience and what would be needed to improved in\n order to make them a useful tool.\n

\n This workshop provided a great insight for me into the way testers work, and how\n we as developers can (and should) support them, as well as understanding the\n value especially of persona-based testing. It is way more flexible, does not\n need to be changed if implementation details are changed and provides\n customer-focused, easy to reason about framework for testers. On the other hand,\n it relies on testers understanding the domain and a lot of details about the\n test subject in order to execute tests. Which in the end will be to the benefit\n of the project.\n

\n The second workshop by Seb Rose and\n Gáspár Nagy gave us a very well executed\n tutorial on how to write better BDD scenarios. Working in groups on suboptimal\n scenarios we worked towards writing one great at the end of the workshop. Their\n insights and tips we easy to follow and execute.\n

https://twitter.coderbyheart.com/status/965889984258506752

https://twitter.coderbyheart.com/status/965899224062791680

\n From discussion with attendees one thing became clear though, too few teams are\n using this technique which enables discussion of features between stakeholders\n and developers and at the same time enforcing the implementation to follow these\n talking points. It seems that many teams start the implementation through Jira\n and other issue trackers instead of taking the time to formulate users stories.\n It might be because it is easy to write tickets like \"Export list of products as\n CSV\" in an issue, but hard to explain why a user needs this functionality in the\n first place.\n

Open Space

https://twitter.coderbyheart.com/status/965939046492131328

\n Being an unconf fan I especially enjoyed this two-hour slot in the programme. It\n was hard to choose from from the roughly 25 sessions:\n

https://twitter.coderbyheart.com/status/965954415525064704

\n The first session was by someone working for a big oil company and they were\n looking for a lean way to develop an alternative-energy car. It was fun to toy\n around with that idea and imagine ways to enable this. Given the knowledge I\n have collected working at Nordic and as the son of an automobile industry\n veteran I could add some insights.\n

https://twitter.coderbyheart.com/status/965954967256358914

https://twitter.com/RidingWolf/status/965954663924322304

\n In the session on Continuous Deployment we talked about the do's and don'ts.\n Basically: you want your CI runners to be\n Phoenix Servers.\n Chris Dräger who hosted this session\n found LambdaCD to be his tool of choice. I would\n recommend Travis + Makefiles to solve this.\n

https://twitter.coderbyheart.com/status/965962746415206401

\n How to Kanban better started as a question on how to improve Kanban but this\n session quickly turned into a team clinic, where we tried to find ways for a\n team to improve their internal shortcomings, which were just being revealed by\n using Kanban:\n

https://twitter.coderbyheart.com/status/965964932960354305

Summary

\n The European Testing Conference was a\n fantastic experience for me, even being in the minority as a developer I felt\n very included and welcome. The atmosphere was always very friendly and never\n hostile or too opinionated. Amsterdam as a city did its best, we arrived a few\n days earlier and had awesome weather, great food and beer.\n

\n I would definitely recommend to follow\n @EuroTestingConf and sign up for their\n newsletter. We might see a new installment of this conference in 2019. Maybe in\n Finland, given that there were so many Finns among the attendees already?\n

\n","slug":"european-testing-conference-2018","hero":"!undefined"}],["european-testing-conference-2020",{"title":"European Testing Conference 2020","subtitle":"The pioneering tech event is no more","abstract":"What happens at European Testing Conference must not stay at European Testing Conference.","date":"2020-02-08T12:00+01:00","html":"\n

\n
This is the most diverse conference I have ever been to.
\n

\n While this remark my friend Patricia Aas makes during\n the retrospective is about the attendees of the 2020 edition of the\n European Testing Conference, it\n strongly resonates with me and I will extend it to the wide range of topics that\n were covered in keynotes, talks, workshops, an open-space, lean coffee, the\n hallways track, and evening get-togethers. I would use diversity further as the\n decisive reason for the experiences I had sharing two days with people from\n typically separated professions: testers and developers. Both were represented\n plentiful, with industry veterans, newcomers and all shades in between. Finally,\n attendees were coming from all over the world to meet with people who care about\n quality, customers, mental health and bring the desire to learn, share and\n teach.\n

https://twitter.coderbyheart.com/status/1225330258569764864

\n It is a safe place to acknowledge that we, our behaviour and our skills are far\n from perfect, to connect with others and figure out together how to be better\n humans who work on computers.\n

\n The closing keynote by Ulrika Malmgren\n summarized this perfectly:\n

https://twitter.coderbyheart.com/status/1225807205783527424

\n It is our responsibility to have honest conversations about our work because we\n happen to be influential to the lives of other with every keystroke and we owe\n it to our users to deliver the best possible solution.\n

\n You can find all the content I discovered and highlights I had this year\n in my twitter feed under the hashtag #EuroTestConf,\n but I would like to point out two specifically:\n

Pact

\n Pact: Fast, easy and reliable testing for your APIs and\n microservices during development.\n

\n With the help of Nelis,\n Matteo, and\n Bernardo I got a good impression of its\n usefulness for my area of work. I plan to look more into it for providing\n stronger documentation of my public APIs, which right now are described for\n other developers using Gherkin Scenarios. It would be straightforward to create\n pact contracts out of these scenarios which would provide a significant benefit\n for the frontend developers which consume these APIs. It would also provide a\n explicit, safe and unambiguous way to communicate API requirements and changes,\n which currently is done using Confluence, Slack and email.\n

7 dimensions of quality

\n from:\n Discover to Deliver\n

https://twitter.coderbyheart.com/status/1225389623448342528

\n This is super useful technique to uncover blind spots in a project and can be\n done with straightforward exercises which don't take up too much time. I will\n add this to my toolbox when talking about (new) features.\n

\n The slides from this workshop have been uploaded\n here.\n

The End

\n 2020 was the last year for European Testing Conference, I will miss it deeply\n and I am grateful for the three years I got to attend it, because every year\n helped me to become a better developer but also because it provides an inspiring\n proof that diversity in tech is not a pipe dream, but achievable.\n

The Future

\n On Friday we met with some of the speakers and attendees from\n Domain Driven Design Europe, one of them being\n Lisi Hocke who spoke and attended\n the European Testing Conference many times before. She could share first-hand\n how large the overlap between the three communities is that were present at the\n table: attendees and speakers of European Testing Conference, Domain Driven\n Design Europe, and\n Softwarecrafters/SoCraTes Conferences share\n the same DNA, and hopefull next year, we can bring these three communities\n closer together.\n

https://twitter.coderbyheart.com/status/1225859527255392256

\n
\n I thank my employer Nordic Semiconductor for\n enabling me to attend this event on company time and cost under our competence\n improvement program.\n We are hiring!\n
\n

\n","slug":"european-testing-conference-2020","hero":"!undefined"}],["expect-tobewithin-number-number",{"title":"expect.toBeWithin(number, number)","subtitle":"A matcher for Jest's expect","abstract":"Use .toBeWithin() when you want to check that a number is within a range.","date":"2017-10-29T18:00+02:00","html":"\n

\n I've just authored\n @coderbyheart/jest-expect-tobewithin\n which adds a matcher to\n Jest's expect that lets\n you expect that a number is between two other numbers.\n

\n","slug":"expect-tobewithin-number-number","hero":"!undefined"}],["exploring-better-ways-to-write-tests",{"subtitle":"Talk","title":"Exploring better ways to write tests","abstract":"My approach to testing embedded firmware using real hardware.","date":"2023-06-09T13:30:00.000Z","html":"\n

\n In my talk Exploring better ways to write tests that I gave at this year's\n Nordic Testing Days 2023 in Tallinn, I\n discussed my journey from feeling dissatisfied with testing tools to creating my\n own test runner. My goal of this talk was to inspire others to explore and\n customize their tools rather than settling for the default options available.\n

\n For quite some time I have been working on cloud-based software system for IoT\n devices. Initially, I used Gherkin for writing tests, but I encountered\n limitations in expressing complex scenarios, dependencies, and handling eventual\n consistency in cloud-based services. Let me explain how I began using Gherkin\n and describe its format and keywords (given, when, then).\n

\n Facing challenges with Gherkin for my specific needs, I ran into issues with\n expressing dependencies between features, directly embedding JSON in feature\n files, managing eventual consistency problems, and dealing with\n context-dependent scenarios. I also realized that I needed better documentation\n beyond just tests. To address these issues, I decided to build my own custom\n test runner, a process that took me three years to develop. The key improvement\n was adopting Markdown for better formatting, hierarchical structure, code\n blocks, and comments. I introduced the \"soon\" keyword to handle eventual\n consistency in tests. Additionally, I utilized GitHub actions to summarize test\n results in a more user-friendly format.\n

\n I also talked about the struggles I faced with architecture diagrams and their\n maintenance. Auto-generated diagrams fell short, prompting me to explore the\n concept of using test traces and observability to dynamically generate\n architecture diagrams based on test runs. This approach would allow for more\n focused and informative diagrams linked directly to actual usage.\n

\n In conclusion, I encouraged others to create tools tailored to their own needs.\n I believe that developing personalized solutions can significantly enhance\n efficiency and understanding in both testing and development workflows.\n

https://www.youtube.com/embed/dZX7SbGOGn4

\n The slides are available at\n bit.ly/better-test-tools.\n

\n You can read up about my impression under the hashtag\n #NTD2023.\n

\n","slug":"exploring-better-ways-to-write-tests","hero":"!undefined"}],["fintech-appsolute-bankfurt",{"title":"Fintech — Appsolute Bankfurt","abstract":"I've written an article about the fintech scene in Frankfurt which you can find at hallofrankfurt.de.","date":"2016-01-04T16:40:00.000Z","html":"\n

\n I've written an article about the fintech scene in Frankfurt which you can find\n at\n hallofrankfurt.de.\n

\n","slug":"fintech-appsolute-bankfurt","hero":"!undefined"}],["firefox-4-und-x-509-zertifikate",{"title":"Firefox 4 und X.509-Zertifikate","abstract":"Im neuesten Firefox funktionieren einige Zertifikate nicht mehr, mit denen z.B. Zugänge zu Content-Management-Systemen oder Banking-Webseiten gesichert werden.\n","date":"2011-04-05T00:00:00.000Z","html":"\n

\n Im neuesten Firefox funktionieren einige Zertifikate nicht mehr, mit denen z.B.\n Zugänge zu Content-Management-Systemen oder Banking-Webseiten gesichert werden.\n

\n Diese Zertifkate (mit Dateiendungen wie z.B. .p12) lassen sich auch nicht mehr\n über den Zertifikate-Manager von Firefox importieren.\n

\n Mit zwei kleinen Handgriffen kann man den Firefox aber doch wieder dazu\n überreden, mit den Zertifikaten zu arbeiten.\n

\n Zuerst muss in about:config der Wert\n security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref\n auf true gestellt werden — sonst verweigert der Fuchs jede Verbindung.\n

\n Anschließend wird das Zertifikat mit Hilfe des Kommandozeilen-Tools\n pk12util\n importiert:\n

pk12util -i <zertifikat.p12> -d ~/.mozilla/firefox/<profile>/\nEnter password for PKCS12 file:\npk12util: PKCS12 IMPORT SUCCESSFUL\n

Jetzt noch den Firefox neu starten und schon klappt die Verbindung wieder.

\n","slug":"firefox-4-und-x-509-zertifikate","hero":"!undefined"}],["firmware-test-automation-using-real-embedded-devices",{"subtitle":"Talk","title":"Firmware test automation using real embedded devices","abstract":"My approach to testing embedded firmware using real hardware.","date":"2022-06-06T23:00:00.000Z","html":"\n

\n In this talk I am presenting my approach on testing embedded firmware using real\n hardware which I gave at Nordic Testing Day 2022 in Tallinn.\n

\n Testing firmware in emulators drastically limits what actually gets tested and\n it can quickly become very tedious to mock, fake and set up environments for\n embedded firmware that needs to connect to cloud services.\n

\n I am taking a different route: let the firmware run on real hardware, and test\n its behavior.\n

\n I show how I implemented these tests using Zephyr, AWS, and GitHub Actions.\n However, this solution can be applied in any environment which cannot be run\n inside a test runner.\n

The slides are available at bit.ly/fwtesting.

\n Unfortunately there was no recording of the talk, but it got featured on\n @internetofshit:\n

https://twitter.com/internetofshit/status/1532795048084983808

\n","slug":"firmware-test-automation-using-real-embedded-devices","hero":"!undefined"}],["first-principles",{"title":"First Principles","subtitle":"How to share gut feeling","abstract":"How can we share the gut feeling we use when writing software?","date":"2018-09-01T17:00+02:00","html":"\n

\n A question I brought to SoCraTes 2018\n was one that formed in the recent months when I was onboarding a new developer\n to a greenfield project. The project they going to work on is developed as a\n walking skeleton.\n Although the architecture is complete, there is not enough flesh on it to\n clearly see the patterns I have used when designing it. Right now every\n component looks like a unicorn and it is hard to see the underlying principles\n that went into the design—simply because there is not enough code to provide\n good heuristics.\n

\n I was looking for a way to provide a resource outside of the code which\n documents the gut feelings that lead to this architecture. These gut feelings\n are a result of reading books, articles and building many different software\n projects, so there is not one school of thought, but a amalgamation of\n hundreds of resources and experiences that form the principles that influence my\n decisions.\n

But what are First Principles?

In this session I listed mine and we collected some more:

Push to deploy
S.O.L.I.D.
No global state
No monolith
Version dependencies
Simplicity
Done > Perfect
Show > Tell
Code Stewardship

\n While some of those are fairly easy to explain (like S.O.L.I.D. where extensive\n documentation can easily be found),\n others are horribly ambiguous, like Simplicity.\n

\n In the course of the session we then collected, how principles are shared within\n teams. One recurring characteristic was that they are usually very project\n specific and are best understood if they are explained using real examples from\n the project's source code.\n

\n A good method to share these principles is pairing when concrete situations\n arise.\n

\n Multiple participants shared that they had good experiences using an internal\n Stackoverflow (or a home-grown solution similar to that), where developers would\n bring up principles they discover or certain implementation details they did not\n fully understand so it could be discussed what the underlying principle was, and\n whether it still applies. This forum-style aproach can also serves as a good way\n to document technical dept, and the decisions that lead to keeping it in the\n system. It provides an easy way to regularly revisit these decisions after a\n certain amount of time has passed and decide again whether to keep it or get rid\n of it.\n

\n I was also looking for a way to provide documentation about First Principles\n before code is written, especially to reduce frustration during code-reviews\n when a violation of a principle is discovered and big changes are neccessary in\n order to heal the pull-request.\n

\n Following the idea of continuous improvement (I think this is yet another First\n Principle) I will try to follow this process:\n

\n This will lead over time to a collection of First Principles which can be used\n to train new developers.\n

\n The Training part is important so we can discover bad and harmful principles\n like Simplicity—if you can't train it, it is most likely a bad principle and\n we should drop it. (The number of times a principle has been violated will be a\n good indicator!).\n

First Principles

Privilege
Push to deploy
5 whys
The 20 percent trick to continuously keep learning

Best practices

\n I also collected a set of best practices that are specific instructions rather\n then generic principles:\n

\n","slug":"first-principles","hero":"!undefined"}],["for-usd24-podio-gives-you-the-names-faces-and-contact-details-of-their",{"title":"For $24 Podio gives you the names, faces, and contact details of their premium users","subtitle":"Privacy","abstract":"Podio discloses extensive user information and claims its users have agreed to it.","date":"2019-07-03T10:00+02:00","html":"\n

\n I've been a big fan of Podio for many years and I recently discovered a nice\n feature: once you sign up to Podio and pay for the\n Premium Plan: you become connected through more than 2,600 other premium users\n through becoming part of the same Network in order to use their automation\n product globiflow.\n

This gives you access to extended personal information:

Full name
Title
Email
Phone Number
City
Personal description / About
Photo
State
Country
Skype
Location
Address
Postcode
Website
IM

\n The information is presented in a nicely formatted way, so I was able to extract\n the data for all users within a few minutes in a nice spreadsheet.\n

\n I think this is highly problematic because this provides a gold mine for\n phishing attacks: I could find members who belong to the same organization and\n use Podio as a pretext to send them arbitrary emails (Hey Bratt, I shared this\nPodio View with you!) containing dangerous links.\n

Two months ago I reached out to the Podio support

\n I asked them to remove this feature, however they claim that this is perfectly\n fine.\n

I wrote:

\n
\n When you purchase Podio premium, and activate Globiflow, you are joining the\n Globiflow network, which will make over 2,600 connections available.
See also\n https://help.podio.com/hc/en-us/community/posts/360000702471-Mass-Delete-Connections
This\n is a serious violation of user privacy since the connections show Name,\n E-Mail, Photo and Phone of the job Title is exposed to anyone (who payed\n $24).
Please remove this feature immediately.\n
\n

This is the answer I received:

\n
\n I understand your concern of having so many connections added to your profile.\n But this is not necessarily a violation of user privacy because the profile\n details that a user is adding is an information that would be publicly\n available only to other podio users you are connected to.
Please refer to:\n https://help.podio.com/hc/en-us/articles/201019378-Updating-and-editing-your-profile\n which states that the profile details will be visible to other users as well.\n It is similar to having your contact and profile information added to your\n social or business collaboration platforms like Linkedin.\n
\n

\n No, this is not what I would expect from a paid product like Podio.\n Especially looking at the linked article, it does not state that \"profile\n details will be visible to other users\" but instead uses \"colleagues\".\n

\n
\n Having a completed Podio profile really helps you and your colleagues \"see\"\n who you're working together with.\n
\n

\n Colleagues are by definition not all podio users. With colleagues I (or the\n manager of the podio account I belong to) has control over who sees my data.\n This is not the case with the \"connection\" feature where I do not have ways to\n control who sees my data.\n

\n I can only encourage Premium Podio users to educate themselves about this\n \"feature\" and reach out to the Podio support so this disclosure of extensive\n personal information will be stopped.\n

Update 4. July 2019

\n I received a reply from Podio support to the original request I made two month\n ago:\n

\n
\n I understand your point of view here and thanks a lot for bringing this up.
We are working towards making this more transparent to users so that users can\n decide what information they would want to keep public.\n
\n
\n Will be releasing out information once we have more clarity on the plan and\n approach.\n
\n

Update 8. July 2019

\n Podio responded to\n the Twitter thread:\n

https://twitter.com/Podio/status/1148152555177857026

Update 11. July 2019

\n Podio updated the\n help article\n and added a section which explains that profile information is shared with\n everyone:\n

\n
\n Public Profile Information Profile information can be seen by all of your\n connections in Podio. This means all of your colleagues, external members that\n you collaborate with, and members inside of community workspaces that you’re\n apart of will all have the ability to view your Podio Profile information. You\n can edit and remove any unwanted profile information at anytime by editing\n your profile information.\n
\n
Shared Profile Information:
\n
\n
Profile Picture
\n
Email
\n
Phone
\n
Location
\n
Address
\n
\n

\n They also added a prominent warning presnted to GlobiFlow users when joining\n that workspace:\n

In addition they plan to upldate the \"Edit Profile\" feature:

\n
\n For long term, we would also be updating our in-product \"Edit Profile\" page\n later to call out what all information is public and what is not, so that\n users can take an informed decision while adding their details.\n
\n

\n","slug":"for-usd24-podio-gives-you-the-names-faces-and-contact-details-of-their","hero":"!undefined"}],["future-of-work-in-the-wild",{"title":"#futureofwork in the wild","abstract":"On April 2nd 2015 I'll be giving a lightning talk to show some examples of organizations that have already arrived at the future of work.\n","date":"2015-03-21T15:00:00.000Z","html":"\n

\n #futureofwork is a rather abstract term which stands for changing our\n workplaces from a concept that was conceived in the 19th century to something\n that reflects the needs of the 21st century human–at least for those of us who\n are asked to produce creatively and innovatively.\n

\n There are a lot of theoretical resources detailing what needs to be done to\n create an environment in which knowledge-workers can achieve their best possible\n output.\n

But there are organizations which have already arrived at the future of work.

\n At the next agile round table, which will take place on April 2nd 2015 at\n Die Zentrale FFM Coworking Space, I'll be\n giving a lightning talk to show some examples of these organizations.\n

\n Sign up on\n XING and\n find out that the wait to change the way we work is over.\n

\n","slug":"future-of-work-in-the-wild","hero":"!undefined"}],["give-your-dots-to-dotHIV",{"title":"Give your dots to dotHIV","abstract":"December 1st is World AIDS Day and we have prepared something for your homepage which will support our cause in an unobtrusive and witty way: turn the fullstops of your page into pink dots.","date":"2014-11-28T10:01:00.000Z","html":"\n

\n December 1st is World AIDS Day and we have prepared something for your homepage\n which will support our cause in an unobtrusive and witty way: turn the\nfullstops of your page into pink dots.\n

\n Our friends from SinnerSchrader built a script\n which once integrated into your site will color a random amount of dots inside\n your text elements on the page in pink. If a user clicks on a dot, a little\n popup will show up with a short info text and a link to\n click4life.hiv. You'll find some of those pink dots in\n this text, too.\n

\n Head over to mydotfor.hiv/dothivify to\n download the script. They even built a configurator to adapt the script to your\n needs. Afterwards you need to add it to your websites source code, just before\n the </body> tag. Make sure to test it–as with all software there might be\n bugs.\n

\n As always with our projects at dotHIV the source code\n is available at GitHub.\n

\n Please let me know in the comments or by your\n preferred means of communication once you've got\n the script running.\n

Thank your for supporting dotHIV!

\n","slug":"give-your-dots-to-dotHIV","hero":"!undefined"}],["have-a-local-folder-to-put-your-crap-in-which-wont-get-accidentally-committed",{"title":"Have a local folder to put your crap in which won't get accidentally committed","subtitle":"Devhacks","abstract":"Do you always have temp / scratch files lying around in your Git repo and sometimes accidentally commit them (like I do)? Here is a simple fix!","date":"2019-01-02T11:00+01:00","html":"\n

\n Do you always have temp / scratch files lying around in your Git repo and\n sometimes accidentally commit them (like I do)?\n

\n Add local/ to your global gitignore file and now you have a place where you\n can put your not-so-temp files and they won't bother you ever again when you use\n a git add -A.\n

You can define a global .gitignore in your global git config file:

#  ~/.gitconfig\n[core]\n        excludesfile = ~/.gitignore_global\n

\n And in the excludesfile add a\n line for the local/ folder:\n

#  ~/.gitignore_global\nlocal/\n

\n","slug":"have-a-local-folder-to-put-your-crap-in-which-wont-get-accidentally-committed","hero":"!undefined"}],["heart-of-code-001",{"title":"❤️.of(code) // 001","subtitle":"Week 33 of 2017","abstract":"Week 33 of 2017 in review","date":"2017-08-20T14:00+02:00","html":"\n

\n Celebrating 2,000 followers on @coderbyheart\n I decided to sum up my week on Twitter from now on every weekend.\n

Quote of the week

https://twitter.coderbyheart.com/status/898107322307936257

Software Craft

We decided to drop the \"Middleman\" in \"Softwarecraftsmanship\":

https://twitter.coderbyheart.com/status/896679150379032576

https://twitter.com/marcoemrich/status/897199629275725824

and take a stand against sexists within our community:

https://twitter.com/dmikeyanderson/status/897124081652293632

JavaScript

Franziska writes on V8's bytecode:

https://twitter.com/fhinkel/status/898184918286643201

A new official Node.js API for headless Chrome appeared:

https://twitter.coderbyheart.com/status/897864286525169664

I made a finger disco:

https://twitter.coderbyheart.com/status/897500349870755842

\n React (and other open-source projects by Facebook) will keep\n the patent clause in\n their license:\n

https://twitter.coderbyheart.com/status/899165362750619651

Tech

\n Contentful changed it's pricing model, which is great, because\n I use it to build this website:\n

https://twitter.coderbyheart.com/status/898062887096397824

Bootstrap next major release is getting closer:

https://twitter.coderbyheart.com/status/896613287038734336

Tricks for the Chrome Developer tools:

https://twitter.com/fox/status/898397296798203905

People

On hiring women for tech roles:

https://twitter.coderbyheart.com/status/896688570462818304

https://twitter.com/MIT/status/898199017439547392

On Code of Conducts:

https://twitter.com/fox/status/898046902884720640

https://twitter.com/langziehohr/status/897832402361495553

Why Code of Conducts are important:

https://twitter.com/fox/status/899129551522979840

I made a list of women in civic tech:

https://twitter.coderbyheart.com/status/897564594654384129

🎧 Listening to

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-001","hero":"!undefined"}],["heart-of-code-002",{"title":"❤️.of(code) // 002","subtitle":"Week 34 of 2017","abstract":"Week 34 of 2017 in review","date":"2017-08-27T14:00+02:00","html":"\n

\n Celebrating 2,000 followers on @coderbyheart\n I decided to sum up my week on Twitter from now on every weekend.\n

Tech 🚀

You can go to jail if you just follow the orders your managers gives you:

https://twitter.com/tedneward/status/901135785969074177

Facebook is fucking disgusting:

https://twitter.com/dhh/status/900893798821134336

\n Benjamin (a super awesome coffe-to-code organism) has created a GitHub repo\n where you can ask him questions:\n

https://twitter.com/benjamin/status/900473217118240768

JavaScript 🛠

\n Dudes behaving like assholes will make contributors turn away, that's why\n there is now a Node.js fork:\n

https://twitter.com/maybekatz/status/899746713572786177

https://twitter.com/ohhoe/status/899748838302302212

https://twitter.com/maybekatz/status/900680829512294404

It matters which behaviour you accept withing you community, because:

https://twitter.com/maybekatz/status/901288355773599744

I've learned to appreciate async/await for this reason:

https://twitter.coderbyheart.com/status/900252517723930624

Web 🌍

Learn how CSS is implemented in CSS (and why Rust is great for that):

https://twitter.coderbyheart.com/status/900267620515106816

Diversity 🌈

Don't be shy, your will be senior in no time:

https://twitter.com/sehurlburt/status/901538910764793856

Because:

https://twitter.com/RidingWolf/status/900994562012917761

Railsgirls released a report on the impact of their initiative:

https://twitter.com/fox/status/901319347573891074

Conferences 💡

\n The European Testing Conference 2018\n has announced\n their keynote speakers\n and is taking place on February 19-20 February 2018 in Amsterdam. Tickets\n start at €899.\n
\n The codefreeze is free and is taking place on\n Jan 15th-18th 2018 in Kiilopää, Finland. I wrote\n here\n about why it is so awesome.\n

\n I'm sponsoring a diversity ticket here, so please apply also to RuhrJS (October\n 14th+15th 2017):\n

https://twitter.com/RuhrJS/status/900285456549638144

Listening to 🎧

Armin van Buuren live at Tomorrowland 2017
Tomorrowland Belgium 2017 | Paul van Dyk
\n QOTSA's new album\n Villains\n

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-002","hero":"!undefined"}],["heart-of-code-003",{"title":"❤️.of(code) // 003","subtitle":"Week 35 of 2017","abstract":"Week 35 of 2017 in review","date":"2017-09-04T14:00+02:00","html":"\n

\n Celebrating 2,000 followers on @coderbyheart\n I decided to sum up my week on Twitter from now on every weekend.\n

Tech 🚀

\n I've been using Firefox Focus\n now for two weeks and I really like it when reading articles from RSS feeds. It\n blocks a lot of ads and does not pollute my history with one-shot visits.\n

Some asshole dude can't deal with a woman, again.

https://twitter.com/jessfraz/status/902262783672291328

\n The next thing regarding Facebook and licenses came up. This time:\n GraphQL.\n

https://twitter.coderbyheart.com/status/902804396504961025

This might explain why I like cooking AND Linux:

https://twitter.com/douglax/status/901155475424550912

JavaScript 🛠

V8 is now on Twitter:

https://twitter.com/v8js/status/902560466291093504

I've learned a new term: NPM lego.

https://twitter.coderbyheart.com/status/902791900104667136

I am still struggling with TypeScript:

https://twitter.coderbyheart.com/status/903619298215768064

Also, I haven't completely ditched Promises, yet.

https://twitter.coderbyheart.com/status/902646931226275840

\n With Chirr I can finally effortless create a Twitter\n thread. Like this one about my visit to Trondheims JavaScript UserGroup\n BartJS:\n

https://twitter.coderbyheart.com/status/903548864384438272

Web 🌍

\n Because Web is an ever changing target, our performance optimizations\n strategies are also in constant need of revisiting them:\n

https://twitter.com/fox/status/903190652401451008

Diversity 🌈

\n A longer article about Project Include\n highlights some of their methods:\n

https://twitter.com/projectinclude/status/903288925485228032

Culture✌️

Very well said:

https://twitter.com/amokleben/status/903218809183535104

\n
\"We don't have enough experts\" You 👏 have 👏 to 👏 start 👏 training 👏 some!
\n

Nordic understands that, and investe in roughly 40 paid summer interns:

https://twitter.com/NordicTweets/status/903216628048986112

Also culture, but different:

https://twitter.com/kcimc/status/902229612666658816

Conferences 💡

A reminder:

https://twitter.com/uveavanto/status/902852536557871106

Franzi has another:

https://twitter.com/Singsalad/status/902626487471362048

Listening to 🎧

\n Joachim Pastor - Promesse (the\n long version!)\n
\n THE HAUNTED - Preachers Of Death\n and the rest of\n their new album\n
\n Every Country's Sun,\n Mogwai's new album\n

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-003","hero":"!undefined"}],["heart-of-code-004",{"title":"❤️.of(code) // 004","subtitle":"Week 36 of 2017","abstract":"Week 36 of 2017 in review","date":"2017-09-10T22:00+02:00","html":"\n

\n Celebrating 2,000 followers on @coderbyheart\n I decided to sum up my week on Twitter from now on every weekend.\n

Tech 🚀

git merge and git rebased lovely explained with cats:

https://twitter.com/girlie_mac/status/906691511496011778

There is a new place to find Software Craft Communities around the world:

https://twitter.com/rradczewski/status/906522197602299906

Don't pretend, you haven't:

https://twitter.com/ifCoffeeEquals0/status/902911447293980672

I needed to install Java this week:

https://twitter.coderbyheart.com/status/906083160089395203

Yes, please do and own your data!

https://twitter.com/lila_luca/status/905757976518066180

\n Germany uses software to count votes, that makes Windows XP look like a\n marvelous piece of software:\n

https://twitter.coderbyheart.com/status/905753958400106496

\n If you don't like ~~Firma~~ Fira Code,\n then checkout these alternative fonts for writing c0d3:\n

https://twitter.coderbyheart.com/status/905310598531043328

Some good thoughts on code coverage:

https://twitter.com/matthewpskelton/status/904654850968965120

JavaScript 🛠

\n Finally, you can just pass through arbitrary attributes to DOM elements in React\n 16:\n

https://twitter.com/reactjs/status/906239745247899648

React license is still in the top 10 this week:

https://twitter.com/JI/status/905487232479330305

Diversity 🌈

\n Don't take it personal, but accept that you (as a white CIS male) are part of\n the problem:\n

https://twitter.com/fox/status/906375321045405696

https://twitter.com/fox/status/906397794189135872

https://twitter.com/fox/status/906398077342420992

https://twitter.com/fox/status/906398704529297408

Because:

https://twitter.com/danielpunkass/status/906733889569378305

One action could be, to support your local RailsGirls chapter:

https://twitter.com/RailsGirls_FFM/status/906175625303601152

Samsung took a dump on diversity:

https://twitter.com/codePrincess/status/905115541794324483

And this is a proper response:

https://twitter.com/bomelino/status/905704419286798336

Culture✌️

\n A (german) read on how DB Systel is transforming the way its 3,500+ employees\n work:\n

https://twitter.com/olewin/status/905008276873650185

True:

https://twitter.com/swissmiss/status/905086353846579201

Conferences 💡

Check out the ETC 2018 shedule:

https://twitter.com/EuroTestingConf/status/905332239449210881

Nordic.js is setting standards in conferencing:

https://twitter.coderbyheart.com/status/906158707976876037

And RuhrJS as well:

https://twitter.com/Maggysche/status/905049102152593408

Jobs / Hiring 💪🏻

https://twitter.com/RidingWolf/status/905489566454489088

https://twitter.com/ckatzenbach/status/904662835862614017

https://twitter.com/NordicTweets/status/906112204042375168

Listening to 🎧

Scooter Forever
\n Holy Books by Death\n From Above 1979\n

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-004","hero":"!undefined"}],["heart-of-code-005",{"title":"❤️.of(code) // 005","subtitle":"Week 38 of 2017","abstract":"Week 38 of 2017 in review","date":"2017-09-24T12:00-07:00","html":"\n

\n ❤️.of(code) number 5 arrives a little late, I had to travel to Portland for an\n nRFCloud.com team meeting.\n

https://twitter.com/NordicTweets/status/908590681538666497

Tech 🚀

Commit Lint will help you write better commit messages:

https://twitter.coderbyheart.com/status/907984489959317504

On using git rebase (which I do a lot):

https://twitter.coderbyheart.com/status/909059267369558016

JavaScript 🛠

Modules (using Michael Jackson Script) are now in Node:

https://twitter.com/MylesBorins/status/907629749559812096

I lean towards TypeScript:

https://twitter.coderbyheart.com/status/907862682459656192

The Facebook license keeps annoying people:

https://twitter.coderbyheart.com/status/908572086288785408

React lets you beam HTML to other sections of the DOM using portals:

https://twitter.coderbyheart.com/status/908602537028341760

\n We will see real type support in JavaScript at some time thanks to Franziska's\n work:\n

https://twitter.com/fhinkel/status/909390206956113921

Diversity 🌈

Kudos to this leading the lawsuite:

https://twitter.com/fox/status/908399808699928576

Nikon thinks there are no women photographers:

https://twitter.com/KristenMcTighe/status/908239912775929861

Culture ✌️

https://twitter.coderbyheart.com/status/907167041060265985

Conferences 💡

https://twitter.com/RuhrJS/status/907573885998166018

Get 25% off ETC2018 tickets:

https://twitter.com/EuroTestingConf/status/908042424957751296

Jobs / Hiring 💪🏻

https://twitter.com/ctrlaltjustine/status/908322638505889792

Listening to 🎧

https://twitter.coderbyheart.com/status/908348254890455040

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-005","hero":"!undefined"}],["heart-of-code-006",{"title":"❤️.of(code) // 006","subtitle":"Week 39 of 2017","abstract":"Week 39 of 2017 in review","date":"2017-09-24T13:00-07:00","html":"\n

\n ❤️.of(code) number 6 concludes an intense week in Portland, with a lot of Craft\n Beer, Burgers. Check out my flickr later for more pictures from that trip.\n

https://twitter.coderbyheart.com/status/909839329886838786

Tech 🚀

Gitte talks about the Imposter Syndrome:

https://twitter.com/NativeWired/status/912019819796602886

Great quote, highlighting some defects in our industry:

https://twitter.com/tottinge/status/911644365327618048

Adequate:

https://twitter.com/midan888/status/910886864512540672

I have ordered a new book:

https://twitter.coderbyheart.com/status/911245991310917633

Press t on GitHub to launch the auto-complete file search:

https://twitter.com/koba04/status/910467885973114886

JavaScript 🛠

I did not expect this!

https://twitter.coderbyheart.com/status/911486542811664384

Basics, but important to get right:

https://twitter.coderbyheart.com/status/911059404195168256

You can now start adding checksum verification to your JS scripts:

https://twitter.coderbyheart.com/status/910547887800684545

Diversity 🌈

\n Sad to see that these dudes are getting a big stage to broadcast their stupid\n claims:\n

https://twitter.com/ag_dubs/status/911696125626904576

I know it's true, so here is what I do:

https://twitter.coderbyheart.com/status/911969460646404096

Culture ✌️

We have softdrinks is a sorry excuse and totally misses the point:

https://twitter.com/savvysarahjane/status/911357833664356352

Conferences 💡

Jobs / Hiring 💪🏻

https://twitter.com/eva_trostlos/status/910790565285056512

Listening to 🎧

\n This was a week full of team interaction so there was no occasion for going into\n the zone.\n

\n But the\n Foo Fighters Car Pool Karaoke Episode\n just came out.\n

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-006","hero":"!undefined"}],["heart-of-code-007",{"title":"❤️.of(code) // 007","subtitle":"Week 39 of 2017","abstract":"Week 39 of 2017 in review","date":"2017-10-03T01:00+01:00","html":"\n

❤️.of(code) number 7 now has the correct week number. Last week was 39.

\n A day late, because I spent the weekend with a few colleagues from\n Nordic at the\n Kårvatn Fjellgård hiking. You can find\n more pictures here.\n

Tech 🚀

Did you know ...

https://twitter.coderbyheart.com/status/913297977795649537

Grid layout is heaven-sent, here is an awesome tutorial:

https://twitter.com/SaraSoueidan/status/913092170923614210

Only a few more years, and Twitter will be a Blog.

https://twitter.coderbyheart.com/status/912802813662711809

or a forum:

https://twitter.com/austin_walker/status/912793201592999936

Diversity 🌈

A very powerful statement:

https://twitter.coderbyheart.com/status/912562291081715713

https://twitter.com/sehurlburt/status/911416253738213376

Culture ✌️

\n Uncle Bob Martin crapped more shit on Twitter and his Blog. His personal\n opinions are disgusting and not tolerable.\n

https://twitter.com/RonJeffries/status/912683108461314048

\n The question is, do I reject a book about software he has authored because of\n this reason? Can knowledge be tainted?\n

https://twitter.com/Singsalad/status/913082583533199361

https://twitter.com/Singsalad/status/913082848076234752

https://twitter.com/Singsalad/status/913083077462827011

And that goes without saying:

https://twitter.com/Gaohmee/status/911729603609206784

Conferences 💡

I booked my tickets for ETC2018:

https://twitter.coderbyheart.com/status/912592461578620928

https://twitter.coderbyheart.com/status/913766517652824064

https://twitter.com/SoCraTesAT/status/913680229469753344

https://twitter.coderbyheart.com/status/913683735106785280

Listening to 🎧

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-007","hero":"!undefined"}],["heart-of-code-008",{"title":"❤️.of(code) // 008","subtitle":"Week 40 of 2017","abstract":"Week 40 of 2017 in review","date":"2017-10-08T21:00+01:00","html":"\n

\n With ❤️.of(code) number 8 I'm finally back at the regular schedule: recapping my\n week in Twitter, every Sunday.\n

Tech 🚀

A report on the state of automated testing came out:

https://twitter.coderbyheart.com/status/917070835751489536

Five hours of setup, for two hours of LAN party:

https://twitter.com/Foone/status/912517731571736576

Mozilla is the poster child of open-source:

https://twitter.coderbyheart.com/status/915472808020504576

\n AWS has some quirky behaviour when it comes to lambdas and environment\n variables, so use Parameter Store. I do and it works great.\n Not only for that.\n

https://twitter.coderbyheart.com/status/914807927231406080

JavaScript 🛠

npm now has 2FA and read-only tokens:

https://twitter.com/npmjs/status/915615028497264640

\n JavaScript (in contrast to Python) has no hard to explain concepts (like list\n comprehensions). It's a great beginners language:\n

https://twitter.com/NeoIghodaro/status/916908182122921984

Node.js is everywhere:

https://twitter.com/fhinkel/status/915603328607727621

https://twitter.com/fhinkel/status/915973586267004928

Diversity 🌈

\n It's sad that this is still not a thing:\n equal pay.\n

https://twitter.com/norway/status/916680335772938241

Verena tells her experience with RailsGirls (Thread):

https://twitter.com/viddity/status/914746997948780544

Studies show that men won't believe evidence when it comes to gender bias:

https://twitter.coderbyheart.com/status/915095082864451585

Culture ✌️

\n You should follow Substack, not only for their\n opinion:\n

https://twitter.com/WoodyZuill/status/916731091779801088

Do this and the whole company will benefit (emphasis on measurable!):

https://twitter.com/johncutlefish/status/916957862835843072

Don't trust a consultancy that sells you the Spotify model. It's does not exist!

https://twitter.com/dwitherick/status/916253643858378752

Thread with great resources on changing organizations:

https://twitter.com/adibolb/status/916206973862936578

Conferences 💡

A BarCamp in my former hometown:

https://twitter.com/bc_rm/status/916562519329857537

\n I signed up for codefreeze 2018!\n Here is\n why you should, too.\n

https://twitter.com/RidingWolf/status/916649224950992896

Jobs / Hiring 💪🏻

\n Make yourself familiar with this, because soon I'll have more concrete details\n to share:\n

https://twitter.com/NordicTweets/status/915142730732449792

Listening to 🎧

\n The Intercepted podcast is back, and\n provides a deep insight into what's going on in US politics\n
\n Heaven Upside Down is\n Marylin Manson's new album\n
Boris Brejcha FCKNG Serious Europe Bus Tour Prague

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-008","hero":"!undefined"}],["heart-of-code-009",{"title":"❤️.of(code) // 009","subtitle":"Week 41 of 2017","abstract":"Week 41 of 2017 in review","date":"2017-10-15T23:00+01:00","html":"\n

\n It's now autumn here in Trondheim, bringing beautiful colors to, as you can see\n in the picture above.\n

Jobs / Hiring 💪🏻

\n Let's start with this one first: we are hiring for two roles to join the team I\n am working in (and on nRFCloud.com. The first role is\n an experienced backend developer to join the half of the team that works from\n the Portland office (check out\n the pictures from my recent trip there.\n

https://twitter.coderbyheart.com/status/917843307413360645

\n We are also hiring a senior-ish frontend developer for Trondheim, more details\n coming soon!\n

\n I have never worked in a more diverse team than here at Nordic Semiconductor, so\n please apply!\n

If you won't move to Trondheim, maybe this one is for you:

https://twitter.com/codeforde/status/917411716421619718

And if you are looking for a remote JavaScript job:

https://twitter.com/PatrickHeneise/status/917306828505088000

Tech 🚀

Bash is the best functional programming language:

https://twitter.com/TIMGroup_Dev/status/918448495874461696

JavaScript 🛠

Node.js is a first class citizen in V8:

https://twitter.coderbyheart.com/status/919500900158377984

Let husky automate stuff for you:

https://twitter.com/dtanzer/status/918383037414506496

More security features for npm:

https://twitter.com/npmjs/status/915615028497264640

Diversity 🌈

Very simplified, but powerful:

If someone doesn't understand privilege, show them this . pic.twitter.com/tMM6MMXawL
— binghii (@TheRealNyha) October 9, 2017

When hiring, read this:

https://twitter.com/drunkcod/status/918476413619056644

Culture ✌️

You know the difference between working manager and managing managers? I do.

https://twitter.com/jurgenappelo/status/917933170133295106

You can't just copy&paste culture:

https://twitter.coderbyheart.com/status/917106443337248769

Conferences 💡

It's great to see that there are tech conference organized by women:

https://twitter.coderbyheart.com/status/919578801432137728

\n A little reminder, why you should come to\n codefreeze:\n

https://twitter.coderbyheart.com/status/917284877531340801

Listening to 🎧

https://twitter.coderbyheart.com/status/918772928925392896

\n and Long Ambient by\n Moby.\n

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-009","hero":"!undefined"}],["heart-of-code-010",{"title":"❤️.of(code) // 010","subtitle":"Week 42 of 2017","abstract":"Week 42 of 2017 in review","date":"2017-10-22T18:00+01:00","html":"\n

\n I talked about autumn last week, and this week the temperatures dropped below\n 0°C in the nights — but the rain stopped and we are having a series of\n beautiful and sunny days this week.\n

https://twitter.coderbyheart.com/status/921009917728886784

Jobs / Hiring 💪🏻

\n This week I'm happy to share the seconde position we are hiring for the\n nRFCloud.com team. We are looking for an experience\n frontend developer to join us here in Trondheim (Nordic is offering a\n relocation package!). For an impression of what Trondheim has to offer, check\n out my flicker, I'll write up a post\n about my experience moving here so far in the next week.\n

https://twitter.coderbyheart.com/status/919970952489861122

More information on nRFCloud after this click:

https://twitter.com/NordicTweets/status/920923969435336705

Tech 🚀

\n There is a new project by betterplace: demokratie.io,\n funding projects that imrove democracy.\n

https://twitter.com/betterplacelab/status/921378984490950656

Bootstrap v4 Beta 2 has been (release):

https://twitter.coderbyheart.com/status/921271013886832640

\n I've\n just updated my blog to Beta 1 last week,\n so time to look at it again ...\n

\n And I wonder if Bootstrap v5 will strip out\n its own grid implementation in flexbox\n to use the CSS Grid which is now available in all evergreen browsers:\n

https://twitter.com/wesbos/status/920385124159672320

https://twitter.coderbyheart.com/status/921255746335137792

Check out what is possible with CSS Grid in this example:

https://twitter.com/dudleystorey/status/920343180582752262

Samsung wants to appeal more to developers:

https://twitter.coderbyheart.com/status/921057190798032897

\n When knee-deep in HTML, check out this list and especially the tools in each\n section, which will help you to ensure you are covered:\n

https://twitter.com/TrendingGithub/status/920755736854126600

\n MDN will get even better (I use it all the time when pointing students to\n specs):\n

https://twitter.com/ChromiumDev/status/920704120390111232

Great guide by Raimo Radczewski about wht makes a great README:

https://twitter.com/rradczewski/status/919981621813633024

JavaScript 🛠

At least once a day I think: JavaScript has to die.

https://twitter.coderbyheart.com/status/921262773706936322

\n This could be interesting if you need to leverage multiple cores in one Node\n process:\n

https://twitter.com/littlefirecode/status/920737689850269696

\n Robin Wieruch has released an update to his Road To Learn React book, which is a\n great introduction to React. You can read it for free!\n

https://twitter.com/rwieruch/status/920336212069515264

Diversity 🌈

This whole thread by Sallyann Freudenberg is a must read for event organizers:

https://twitter.com/SalFreudenberg/status/921421125434986496

This thread by Sarah Mei discusses the misconception that passionate\ndevelopers is something to look for:

https://twitter.com/sarahmei/status/921366047122268165

Culture ✌️

\n This weeks big culture topic was\n #meetoo.\n

https://twitter.coderbyheart.com/status/919818697090437120

https://twitter.coderbyheart.com/status/919818998811852801

https://twitter.coderbyheart.com/status/919819462089560064

https://twitter.coderbyheart.com/status/919819809621270533

Conferences 💡

No time to go to a conference?

https://twitter.com/AlterConf/status/920415377166946304

Listening to 🎧

\n The 138 special (A State of Trance 835)\n by Armin van Buuren\n (more about 138)\n
\n A lot of great anekdotes in the\n Porcelain Audiobook\n by Moby\n

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-010","hero":"!undefined"}],["heart-of-code-011",{"title":"❤️.of(code) // 011","subtitle":"Week 43 of 2017","abstract":"Week 43 of 2017 in review","date":"2017-10-29T14:00+01:00","html":"\n

\n It's amazing how short the autumn here in Trondheim is, today we had the first\n snowfall of the season:\n

https://twitter.coderbyheart.com/status/924606668050190337

Jobs / Hiring 💪🏻

Silvia shared a great resource for women looking into a career in tech:

https://twitter.com/SilviaHundegger/status/923519487751741441

You can also hire her (as a contractor) for your next venture:

https://twitter.coderbyheart.com/status/922437956752814081

Tech 🚀

Some remarks on Software Architecture from a fellow Software Crafter:

https://twitter.com/Ookami86/status/922908515236220928

I also need to emphasize this:

https://twitter.coderbyheart.com/status/924589685564944384

There is a nice new drag&drop library around (with an awesome demo page):

https://twitter.coderbyheart.com/status/923794863950303232

\n I started following Honest Status Page for\n tweets like this:\n

https://twitter.com/honest_update/status/913443696833646592

JavaScript 🛠

\n Reason is still very high on my to check out\n bucket list for its promise to improve the way we are writing JavaScript:\n

https://twitter.com/reasonml/status/924043510977740800

\n The next Node.js LTS release is coming (check out\n this post for an overview of the\n important changes from v6). I personally like\n util.promisify\n and\n Object.values.\n

https://twitter.com/nodejs/status/923987712343986176

\n Node.js 8 enables http2 by default,\n btw.\n

https://twitter.com/tomayac/status/922882277276835842

It's time to update, anyway:

https://twitter.com/nodejs/status/922955663864664065

My observation on using Redirect in React apps:

https://twitter.coderbyheart.com/status/923964650542239744

https://twitter.coderbyheart.com/status/924175477551587328

https://twitter.coderbyheart.com/status/924175558505848832

Diversity 🌈

Two articles that show how Men will be favored, no matter what:

https://twitter.com/jchyip/status/923151607633731584

https://twitter.com/math_rachel/status/922609748607823872

Diversity is about potential:

https://twitter.com/ClydeHyena/status/922391353215946752

Culture ✌️

A good article on David Marquet's book Turn The Ship Around:

https://twitter.com/corp_rebels/status/923430498642341888

Here is why teams should own their code, not a single person:

https://twitter.com/Lynoure/status/922939010976239618

Conferences + Usergroups 💡

Meet me at these Usergroups:

\n Oktober 31st 2017:\n A dive into the Erlang VM by Robert Virding,\n Lambda Trondheim\n
\n November 1st 2017:\n Vespa - the open big data serving engine,\n Trondheim Big Data\n

These are the conferences where you will be able to meet me:

January 2018: codefreeze in Ivalo, Finland
\n Fabruary 2018:\n European Testing Conference 2018,\n Amsterdam, Netherlands\n

Listening to 🎧

A 12 hour State of Trance episode
Opus by Eric Prydz

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-011","hero":"!undefined"}],["heart-of-code-012",{"title":"❤️.of(code) // 012","subtitle":"Week 44 of 2017","abstract":"Week 44 of 2017 in review","date":"2017-11-05T17:00+01:00","html":"\n

\n It has been a wet week here in Trondheim. On Monday we had the first snowfall of\n the season:\n

https://twitter.coderbyheart.com/status/924947035488432128

\n But luckily Saturday gave me only wet feet on the 19km hike from the Skistua\n Busstop up to\n Storheiha:\n

https://twitter.coderbyheart.com/status/926892769771171841

Jobs / Hiring 💪🏻

From my team:

https://twitter.coderbyheart.com/status/919970952489861122

From my network:

https://twitter.com/digiges/status/926444171031916544

https://twitter.coderbyheart.com/status/926177548383506432

Here is some career advice from yours truly:

https://twitter.coderbyheart.com/status/927186763285696512

Tech 🚀

Show this the next time something takes longer than expected:

https://twitter.com/atomrc/status/926141456133378048

On the importance of testing and code analysis:

https://twitter.com/housecor/status/926100700437843968

JavaScript 🛠

\n A quick reminder, that TypeScript ist a\n duck-typing system:\n

\n
\n One of TypeScript’s core principles is that type-checking focuses on the shape\n that values have. This is sometimes called “duck typing” or “structural\n subtyping”. In TypeScript, interfaces fill the role of naming these types, and\n are a powerful way of defining contracts within your code as well as contracts\n with code outside of your project.\n
\n

which leads to this:

https://twitter.coderbyheart.com/status/926465683860393984

Another TypeScript annoyance it hit this week, was how inheritance works:

https://twitter.coderbyheart.com/status/926015230756433920

\n I love Greenkeeper and how it puts some sanity in working with JavaScript\n dependencies:\n

https://twitter.com/greenkeeperio/status/926101104705835013

\n With the LTE release of Node.js 8 I wonder when we will see an AWS Lambda\n environment with it:\n

https://twitter.coderbyheart.com/status/926040615686692864

Diversity 🌈

Great data on why women have a hard time dvancing to more senior roles:

https://twitter.com/fox/status/925586408202366976

Culture ✌️

It's not hard to find an alternative to Hey guys,:

https://twitter.com/mariatta/status/926141459530579968

Conferences + Usergroups 💡

If you are looking for more divers speakers, check out this list:

https://twitter.com/jlengstorf/status/911186730480435200

There is a new unconference in Düsseldorf:

https://twitter.com/iamjoyclark/status/926137973019516928

(JS|CSS)conf Australia has their CfP open:

https://twitter.com/fox/status/926189913917108224

Listening to 🎧

deadmau5 @ BBC Radio 1 Residency (02 Nov 2017)

https://twitter.coderbyheart.com/status/926085734234279936

https://twitter.coderbyheart.com/status/926131590043926528

https://twitter.coderbyheart.com/status/926120118786064389

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-012","hero":"!undefined"}],["heart-of-code-013",{"title":"❤️.of(code) // 013","subtitle":"Week 45 of 2017","abstract":"Week 45 of 2017 in review","date":"2017-11-12T15:00+01:00","html":"\n

\n This week I started to notice how long the shadows are during the day since the\n sun is barely getting above the hills that surround Trondheim. The photo above\n was taken at 2pm and shows how the sun is already close to the horizon.\n

But this week I compensated for the reducing sunlight:

https://twitter.coderbyheart.com/status/927577937217572866

Jobs / Hiring 💪🏻

From my team:

https://twitter.coderbyheart.com/status/919970952489861122

If you wonder, why Trondheim is a great place to live:

https://twitter.coderbyheart.com/status/928623601707823104

From my network:

https://twitter.com/ESiersleben/status/928351023407812609

https://twitter.com/Code_Door/status/927502280701685760

https://twitter.com/ThisIsMissEm/status/925726195941076992

I wrote a post on how to build a professional network:

https://twitter.coderbyheart.com/status/927504106402603008

Tech 🚀

True.

https://twitter.com/dbader_org/status/928445538516852736

Writing modular software is important, but what makes for a good module?

https://twitter.coderbyheart.com/status/929348101609021442

Someone visualized the one sound that influenced my life the most:

https://twitter.coderbyheart.com/status/927597969297289216

JavaScript 🛠

\n Using React means you need to learn a new set of paradigms, find some of them\n here:\n

https://twitter.coderbyheart.com/status/928883943277039618

You know that you own your dependencies, right?!

https://twitter.coderbyheart.com/status/928393488747696128

\n Since I am seeing this (and it violates the\n SOLID\n principles):\n

https://twitter.coderbyheart.com/status/928177969394257920

Diversity 🌈

This is what Nordic Engineers look like:

https://twitter.com/NordicTweets/status/927632650747236353

Culture ✌️

\n nohello.com got it right, (also, check out\n VSRE!).\n

https://twitter.coderbyheart.com/status/928591011672215557

If you don't have time to try things out at work, you might ask to run a Kata:

https://twitter.com/ladiesofcode/status/927980320862896129

Conferences + Usergroups 💡

https://twitter.com/jsconfeu/status/928185361360179201

https://twitter.com/FemtoConf/status/927914799614263300

Listening to 🎧

Above & Beyond #ABGT250 Live at The Gorge Amphitheatre, Washington State
\n Salmiakki Sessions 148\n by Darude\n
The Hurry Slow Podcast

\n
\n Remember to follow me on Twitter! DMs are\n open!\n I'm happy to answer your questions\n ...\n
\n

\n","slug":"heart-of-code-013","hero":"!undefined"}],["how-i-package-typescript-lambdas-for-aws",{"title":"How I package TypeScript lambdas for AWS","subtitle":"Serverless","abstract":"The latest (and greatest?) way I could come up to publish AWS Lambdas written in TypeScript.","date":"2019-04-25T17:00+02:00","html":"\n

\n nRF Connect for Cloud is an IoT product prototyping\n platform built on top of AWS. It heavily uses serverless resources and all of\n our business logic is deployed using AWS Lambda. Per last count there were over\n 100 lambdas which handle API requests, act based on MQTT messages, or run\n maintenance operations.\n

\n While there are great solutions (like CloudFormation, or the even better\n CDK) to manage resources on AWS, when it\n comes to publishing the program code for lambdas, the relevant documentation\n section\n is rather sparse.\n This is understandable, though. AWS Lambda only provides computation resources\n (CPU, RAM) and does not care much how you use those resources in your code. It\n makes actually very few assumptions about what you run and it supports\n any kind of language.\n

\n This leaves a lot of room for many possible ways to solve publishing code to\n run on AWS Lambda. Since I joined the team in 2017 I went over multiple\n iterations on how lambdas are deployed. In this article I want to describe the\n latest way I could come up with and what it provides for our scenario.\n

External dependencies in a layer

\n Our code depends on some rather big production dependencies. It needs to include\n elasticsearch which adds a few\n megabytes to the deployment package. In the past we used to pack lambdas with a\n package.json per lambda to at least not have to include the Elasticsearch\n client in lambdas that do not talk to this database. Nevertheless this resulted\n in around 400MB in zipped deployment packages. It was reasonably fast (one\n npm ci --production per lambda, and a zip), but deploying this amount of\n data can take time on slower connections, which can be annoying during\n development.\n

\n In the current approach I put all external dependencies for all lambdas in one\n Lambda Layer.\n This one ZIP file is a little bigger (25 MB) than the biggest individual lambda\n deployment package before (18MB), but I only need to publish this once.\n

Tree-Shaking on inter-repo dependencies

\n For the individual lambda I use Webpack to compile it into a single module. I\n ignore all external modules\n so the deployment package only contains the code that is actually required from\n the repository. The typical size of the zipped lambda now is around 15KB. This\n results in huge savings in the total deployments size. Including the layer this\n results in less than 30MB. Which is more than 10 times less.\n

Deploy only if changed

\n It still takes time to build these deployment packages. That's why I use\n dependency-tree to track the\n dependencies of each lambda and only rebuild it if one of the dependencies has\n changed. This brings a great improvement for the developer. Previously I used to\n keep deployment packages locally and would manually remove those that needed to\n be rebuild. This is error-prone and regularly led to forgetting a certain lambda\n which was affected by the current edit. Since I now have a hash of all\n dependency, I can tell exactly which lambda needs to be rebuild when a source\n file is changed. Checking the dependencies is reasonably fast (a few seconds) so\n I run it as part of our deployment command (hooked into npx cdk).\n

Cache on S3

\n As an added bonus I publish all deployment packages on S3 (I need to do this for\n CDK anyway). And the deployment script will skip the packaging of a lambda if\n that exact version has already been build. This means a developer can check out\n our repo and does not need to rebuild all lambdas in order to start working.\n

Source code and usage in AWS CDK

\n I have published the source code of the deployment script\n here. The entry method is\n packLayeredLambdas.\n

\n Since AWS CDK is building the Stack configuration through synchronously\n constructing class instances we need to package the lambdas before we run\n new App().\n

`cloudformation.ts`

import * as fs from \"fs\";\nimport * as path from \"path\";\nimport { packBaseLayer } from \"@bifravst/package-layered-lambdas\";\nimport {\n  packLayeredLambdas,\n  WebpackMode,\n} from \"@bifravst/package-layered-lambdas\";\n\n(async () => {\n  // This is where we locally store the packaged lambdas\n  const outDir = path.resolve(__dirname, \"pack\");\n\n  // Create the directory if it does not exist\n  try {\n    fs.statSync(outDir);\n  } catch (_) {\n    fs.mkdirSync(outDir);\n  }\n\n  // Set the name of the S3 bucket to store the lambdas\n  // in reality we have another CDK App which provides this value,\n  // but I have omitted it for the sakee of brevity\n  const bucketName = \"cf-sourcecode\";\n\n  // Location of the webpack config to use (see below)\n  const webpackConfig = path.resolve(__dirname, \"tsconfig-webpack.json\");\n\n  // Location of the tsConfig to use with dependency-tree (see below)\n  const tsConfig = path.resolve(__dirname, \"tsconfig-dependency-tree.json\");\n\n  // Now package your lambdas\n  const layeredLambdas = await packLayeredLambdas<{\n    helloWorld: string;\n  }>({\n    // We group related lambdas per feature, this identifies the group\n    id: \"my-project-lambdas\",\n    webpackConfig,\n    mode: WebpackMode.production,\n    srcDir: __dirname,\n    outDir,\n    Bucket: bucketName,\n    lambdas: {\n      helloWorld: path.resolve(__dirname, \"hello-world.ts\"),\n    },\n    tsConfig,\n  });\n\n  // And create the base layer\n  const baseLayer = await packBaseLayer({\n    srcDir: __dirname,\n    outDir,\n    Bucket: bucketName,\n  });\n\n  // Now you can construct your CDK app and pass the locations\n  // of the layered lambdas and the base layer location in,\n  // to use them when constructing a Lambda function definition\n  new MyCDKApp(layeredLambdas, baseLayer).run();\n})();\n

`tsconfig-webpack.json`

{\n  \"compilerOptions\": {\n    \"module\": \"commonjs\",\n    \"target\": \"es2017\",\n    \"strict\": true,\n    \"declaration\": false,\n    \"skipLibCheck\": true,\n    \"noUnusedParameters\": true,\n    \"noUnusedLocals\": true\n  },\n  \"include\": [\"**/*.ts\"]\n}\n

`tsconfig-dependency-tree.json`

{\n  \"compilerOptions\": {\n    \"module\": \"commonjs\",\n    \"target\": \"es2017\",\n    \"lib\": [\"es2017\"],\n    \"strict\": true,\n    \"outDir\": \"dist/\",\n    \"declaration\": false,\n    \"skipLibCheck\": true,\n    \"noUnusedParameters\": true,\n    \"noUnusedLocals\": true\n  },\n  \"include\": [\"**/*.ts\"]\n}\n

\n If you would like to see a working example with AWS CDK,\n ping me or leave a comment below. As always,\n I'd love to get your feedback on how you solve this in your project, too!\n

\n","slug":"how-i-package-typescript-lambdas-for-aws","hero":"!undefined"}],["how-to-develop-a-cellular-iot-project",{"subtitle":"Talks","title":"How to develop a cellular IoT project","abstract":"A small lecture I gave on how to approach designing the software architecture for a cellular IoT project.","date":"2024-02-08T14:00:00.000Z","html":"\n

\n This is a small lecture I gave to a team of students on how to approach\n designing the software architecture for a cellular IoT project.\n

\n It uses the Nordic nRF9160 as a\n habit tracker in a 12 sided enclosure and connects to\n AWS IoT.\n

In the talk I speak about:

design considerations
how to separate work between three teams
make sure the project is aligned with the user's goals
how end-to-end tests support integration between teams

https://www.youtube.com/embed/4dxdToouAI8

\n","slug":"how-to-develop-a-cellular-iot-project","hero":"!undefined"}],["how-to-find-a-cto",{"title":"How to find a CTO","abstract":"A fews weeks ago I announced that I am holding free bi-monthly CTO office hours and the first one I did revolved around the question “How to find a CTO?”. In this post I aim to summarize the advice I gave.","date":"2015-01-25T18:00:00.000Z","html":"\n

A fews weeks ago I announced that I am holding free bi-monthly CTO office\nhours and the first one I did revolved around the question “How to find a\nCTO?”. In this post I aim to summarize the advice I gave.

You can't compete with bigcorp's salary and financial benefits …

\n The Rhein-Main-Area is packed with high-profile companies that offer post-grads\n high salaries and even higher salaries to experts. You can't compete with\n salaries that banks are offering. Even if you offer shares–what you should–the\n financial security a large company provides is tempting.\n

\n What you can offer is the opportunity to work in an environment with the freedom\n and leverage to influence all important technical decisions, build a team and\n constantly improve the product. But don't replace speed in decision making with\n haste–a clear vision and a defined set of core values are very important!\n

… offer freedom!

\n Developers (and their brains) don't like a 9-to-5 work environment in an open\n plan office space. If they are hooked to an idea they will work all day solving\n your business problems, even during their time off. In contrast to working with\n physical products, where your output ends when you leave the workplace, the\n brain won't stop thinking about problems that arose during work time. I\n regularly get new ideas about how to improve the software I am working on or\n what could be done better when commuting to and from the coworking space I\n work at on my bike. It is stupid to measure the value of a creative work in\n terms of work hours per week. Drop this relict from the 19th century and give\n your CTO (and the rest of the team) the freedom to work when they want. This\n should also be true for the amount of vacation time. Make it unlimited!\n

\n Especially for a startup it is critical to get out in the wild once in a while.\n This includes time (and money) to attend conferences, usergroups are hackathons.\n Don't put an arbitrary limit on this, too.\n

Remote is just one video call away

\n Don't limit yourself to candidates which are 30 driving minutes away from your\n location. You'll be looking for an experienced CTO who has experience running\n the tech stack you are working with in production? This will limit your pool of\n candidates dramatically. Having a remote team is hard and requires constant\n work, but that is true for local-only teams, too and you won't have the benefit\n of a large candidate pool. You should make sure that the preferred working hours\n of your team members are overlapping at least 4 hours, though.\n

Build a reputation

\n It's important to put a lot effort into the job section of your website.\n This also helps to define your understanding of how working at your startup\n should be and can be used as a reference for continuous improvement. Great\n examples are expensify and ZenMate. Those examples are of established\n startups but they serves as a great example of what to communicate when looking\n for talent that gets offered exciting and once-in-a-lifetime opportunities\n every day.\n

\n If you have an established tech team already, let them write a blog. This will\n help in proving that you are up to your promises and also gives an insight into\n your daily work. Good examples–from around–are Vaamo or flinc.\n

Where to find a CTO?

\n Besides your website–where you must have an up-to-date job listing at all time\n look into these networks:\n

XING, LinkedIn

\n Use your network, get introduced. Go through the contacts of your XING and\n LinkedIn connections and pick the candidates you'd be genuinely interested in\n talking to. The ask your contact to make an introduction. They'll refer you as\n someone worth to talk to. It is important to get the first contact right. Take\n the time to describe why the candidate impresses you.\n

Hacker News

\n Hacker News is the resource for people interested in startups. Every\n month there is a thread called Who is hiring (January 2015 example) and\n Who wants to be hired (January 2015 example) –use those to post your job\n offer and find possible (remote) candidates.\n

Angel.co

\n Startups are an international phenomenon, so a lot of german speaking candidates\n already have a profile on the most important platform for startups looking to\n hire. Don't miss having you job offer on angel.co.\n

StackOverflow

\n Developers (and CTOs) will be on StackOverflow at least once a day. I have very\n positive first hand reports of posting job offers on their careers page.\n

Usergroups

\n We have over 100 usergroups in the Rhein-Main-Area and there you'll meet\n good candidate material as they attract a special kind of person: those who are\n willing to learn and to share–important characteristics of a CTO. Don't waste\n your time going there if you are the not rooted in technology. If you already\n have developers in your startup, encourage them to go there. They'll talk about\n your startup and you will get known to be looking for a CTO–who then has a\n reference in his peers. And recommendations from peers are worth more than\n anything else.\n

\n It is always a smart move to host usergroups that are related to your field of\n work or technology once and a while. That provides free publicity for your\n startup and knowledge for your employees delivered to your doorstep for the\n price of a few beers and pizzas.\n

Go to a startup weekend

\n Startup Weekends are a great way to meet people looking for a startup to\n join. Don't hesitate to go there–even if your startup is already established.\n You'll have a lot of fun and get to know a lot of people. There is a Startup\n Weekend every week in a city on this planet. So look a little further than\n Germany–I heard that Malta is great for startups …\n

What is the one thing only you can offer?

\n That is a hard question. In the end the process of building software is the same\n in every company. What matters is what you do with the software! How will\n working for your startup make this world a better place?\n

I will always ask myself this question.

\n","slug":"how-to-find-a-cto","hero":"!undefined"}],["how-to-write-a-job-post-for-development-positions",{"title":"How to write a job post for development positions [Updated]","abstract":"An important role in your search for developers is your job page. Don't miss the chance to impress a curious developer because every candidate will browse your website to look up your job postings.\n","date":"2015-05-31T14:00:00.000Z","html":"\n

\n I recently blogged about How to find a CTO. An important\n role in your search for your CTO or any other development role is your job page.\n Don't miss the chance to impress a curious developer because every candidate\n will browse your website to look up your job postings.\n

\n I have a shocking idea for you: ditch the bullet-pointed job description. First\n and foremost you are looking for a team member with a broad range of skills to\n join you on a year long journey. It's more important to find a person who is\n smart, curious, genuinely interested in your business and most important a match\n for your team culture than a match to your current tech stack.\n

\n You should start the job posting by explaining what you do as a business and why\n it matters to help you to achieve this goal. You might call this a vision if you\n don't have a product. It's this vision that drives everyone in your company to\n give their best.\n

\n Next you should describe what the position is responsible for. Explain this by\n describing the typical workflows and tasks. This is a good spot to include tools\n and technologies that are used in your tech stack. I recommend that you assign a\n relevant team member to the position to be available for answering questions.\n Display his position, his name and his email.\n

\n You should finish by explaining what you offer in return. Talk about the things\n that you do to make your employees happier, healthier and more productive. Don't\n forget to include links to company rating sites like\n glassdoor or kununu.\n

\n And don't forget to make sure that every job posting has a unique page with a\n sharable permanent url, includes the date of publication and is taken down\n immediately once the position is no longer available. A side note on publication\n dates: a lot of companies do not remove their job postings and the can linger on\n their website for month. If possible display the current month and year as the\n date of publication. This signals that the job offer is still valid and\n up-to-date.\n

Below I've compile a list of good examples for job posts and hiring sites:

\n Mindvalley is pure porn when it comes to\n company job websites\n
\n Supercell is technically impressive, which\n conveys their work\n
\n Buffer has become a great\n example for a company built on culture so it's no wonder they have outstanding\n job postings\n
\n Expensify goes great lengths to give you an\n insight in how awesome their team is\n
\n Blizzard is known\n for their great company culture and they are doing a fantastic job telling you\n about it\n
\n Goodgame Studios\n is another well executed example\n

\n I know those examples are big and take a lot effort to build but you can start\n small:\n

DeinBus looking for a backend developer (I\nwrote this one myself (in german), so its natural to include it here.)
\n Vaamo finds a good balance between standing\n out and keeping the job page lean.\n

And progress from there by fleshing out a little:

Zenmate has a nice one-pager
\n Quäntchen und Glück are a little heavy on the\n text side, but what they are writing is what makes them special\n
\n GitHub finds a good balance between\n simplicity and emotionality\n

\n I hope this helps you in building a great job posting.
But don't forget that this is only a small part of the things you have to do to\n attract great talent.\n

\n","slug":"how-to-write-a-job-post-for-development-positions","hero":"!undefined"}],["hubsche-dummy-bilder-erzeugen",{"title":"Hübsche Dummy-Bilder erzeugen","abstract":"Der Dummy-Image-Generator erzeugt auf Wunsch die passenden Bilder. Wenn man aber auch mal lokal ein paar Dateien braucht, um z.B. einen Uploader oder eine Galerie zu testen, kann man sich mit ein paar Zeilen Python schnell ein paar Testbilder erzeugen:","date":"2011-07-11T00:00:00.000Z","lang":"de","html":"\n

\n Der Dummy-Image-Generator erzeugt auf Wunsch die passenden Bilder. Wenn man\n aber auch mal lokal ein paar Dateien braucht, um z.B. einen Uploader oder eine\n Galerie zu testen, kann man sich mit ein paar Zeilen Python schnell ein paar\nTestbilder erzeugen:\n

from itertools import cycle\nfrom urllib.request import urlretrieve\n\nwords = cycle(\"Lorem ipsum dolor sit amet consectetur adipiscing elit Etiam \nsit amet tortor velit id consectetur ipsum Morbi id nulla diam sit amet\".split(\" \"))\n\ncolors = cycle([\"1b9e77\",\"d95f02\",\"7570b3\",\"e7298a\",\n\"66a61e\",\"e6ab02\",\"a6761d\",\"666666\",\"a6cee3\",\"1f78b4\",\n\"b2df8a\",\"33a02c\",\"fb9a99\",\"e31a1c\",\"fdbf6f\",\"ff7f0\",\n\"cab2d6\",\"6a3d9a\",\"ffff99\",\"b15928\"])\n\nfor i in range(10):\n    word = next(words)\n    url = \"http://dummyimage.com/1280x1024/%s/000000.jpg&text=%s\" \n        % (next(colors), word)\n    print(urlretrieve(url, \"%s.jpg\" % word))\n\n

\n","slug":"hubsche-dummy-bilder-erzeugen","hero":"!undefined"}],["humans-are-liars",{"title":"Humans are Liars","subtitle":"3 Goals for a great Workplace Culture","abstract":"As Scott Adams put it very well: Humans are liars. How do we create an environment where they don't?","date":"2017-12-30T16:35+01:00","html":"\n

\n $\"The$ \n

\n Once again, Scott Adams nailed it in one of his\n recent comics:\n

\n
\n Boss: Our consultant has studied our corporate culture and isolated the\n problem. Dogbert: The problem is humans. You're all selfish, rotten liars.\n Boss: What kind of team-building exercise will fix that? Dogbert: I'd try\n something involving DNA and alien technology.\n
\n

\n It is one of my fundamental learning as an agile consultant and practitioner:\n Humans are Liars. They lie about their feelings, performance, thoughts,\n coworkers, progress, ..., in order to protect themselves. And this is the root\n cause for all organizational problems. Humans are really great in adapting to\n existing organizational deficits and turning them to something which they can\n operate in with the least amount of energy necessary.\n

\n In order to break this pattern and create a workplace that enables humans to\n focus on their positive skills (creativity, problem solving, …) these three\n factors are key in a workplace culture:\n

It should be safe to be vulnerable

\n Fear of Shame is an important driver for telling lies, and if we remove this\n fear from our workplaces, we remove the need for lying. Brené Brown is doing\n fantastic research on this topic and you should start reading and watching her\n material here.\n

It should be transparent

\n Transparency enables to uncover defects, if information and data is available\n without restriction, there is no use in lying about it or covering it up. It\n also disables power structures that are build on information possession and\n selective distribution of information. You can start reading about this topic in\n this article.\n

It should be free of incentives that promote individualized results

\n In creative industries, there are no individual performance goals that will not\n hurt the company. Our work output is too complex to define goals for individual\n contributors. If done nevertheless they are easily gamed (by lying) towards the\n benefit on the individual.\n Here\n is a good article to get you started.\n

\n","slug":"humans-are-liars","hero":"!undefined"}],["i-am-a-coder-help-me-learn-to-collaborate",{"subtitle":"Using communication frameworks to become a better engineering leader","title":"I am coder; help me learn to collaborate!","abstract":"You may prioritize improving your technical skills, but why is improving your communication skills just as important?","date":"2021-11-03T20:00:00.000Z","html":"\n

\n
This blog post was originally published in June 2021 on\nLeadDev:\nUsing communication frameworks to become a better engineering leader.
\n

\n\n

\n Having had the opportunity to earn my living as a software developer since 1997,\n I have lost count of the number of meetups and conferences I’ve attended as a\n participant or speaker, the number of YouTube videos I’ve watched, blog posts\n I’ve read and written – all in pursuit of one goal: improving my skills as a\n developer and to become a god of the world wide web, a ninja, a rock star, a\n full stack developer.\n

\n Many developers see themselves as artists and their works as divine creations\n brought into existence by heroic acts of willpower that are only possible after\n many, many years – by day as a paid software professional, and by night as an\n open source contributor.\n

\n It was in 2012 when I started to interact with the community outside of my\n workplace and then eventually realized that the effort to become a full stack\n developer is futile.\n

Stop becoming a full stack developer – your efforts are futile.

\n Five years later, after having met many amazing, humble people in the\n software craft community that care about\n software quality the same way I do,\n I concluded that the\n aim to become a master on all levels of the stack stems from a preposterous\n self-glorification. Building world class software is a\n complex and sometimes chaotic\n process that requires knowledge on so many different aspects (backend, frontend,\n UX, privacy, accessibility, CI/CD, operations, etc.) that it’s impossible for an\n individual to acquire the amount of knowledge needed to be the expert on all\n of them.\n

\n Being a full stack developer supposedly means that you possess the skills to\n develop an application end to end. This is of course a very simplified view,\n since being a full stack developer means you need to be proficient in a\n multitude of areas: your skill is not a single value but varies across the\n professions as shown in this graph.\n

\n Ask yourself this: what is your overall level? Your highest skill in one of\n these areas (so a t-shaped skill set lets you call yourself a full stack\n developer), your lowest skill (you need to master all in order to call yourself\n one), or an average?\n

\n You can see that the label of ‘full stack developer’\n is problematic already.\n

https://twitter.coderbyheart.com/status/1185891780128133120

\n If we consider more deeply what is needed to develop software, we also need to\n take into account the various requirements of the respective domain the\n application is intended for.\n

\n Your skill is always relative to the sector you are working in. If you mostly\n work on ecommerce projects, you will most likely have deep knowledge in\n performance, payment systems, and user journeys. If you work on internal banking\n systems, your fields of expertise will have an entirely different focus.\n

Technical skills have a limited lifetime

\n All of the above also needs to be viewed through an important fourth dimension:\n time!\n

\n Your skill is a function of the time you spend improving it, and since you\n cannot simultaneously improve all skills at the same time, your absolute full\n stack developer skill will fluctuate over the years of your career.\n

\n Software is an incredibly fast-changing field, and the skills associated with a\n full stack developer usually become outdated within a few years – a fraction of\n your total working life!\n

\n
\n This all means you will never truly be a ‘principal full stack developer’.\n Sorry.\n
\n

\n This realization brought me to the conclusion of focusing my learning journey on\n the area where my talent, my interests, and my ability to sell these skills\n overlap: being a great architect and\n developer for cloud native solutions, while trying to keep following the\n frontend trends.\n

\n I didn’t see it in 2017, and it seems like I was still framing my function in\n isolation. To you it might be obvious: building software is a team effort and\n typical project sizes make it impossible to be the sole decision-maker for all\n technical decisions in a project.\n

\n It took me a while to realize this. I am most likely not the only developer\n going through this process. It's impossible to achieve greatness solely on your\n own.\n

Writing software is a team effort – you will always lack important skills to\nrealize the best work you have ever done.

You will always depend on others to work with you, and the more experienced you\nare, the more others depend on you enabling them to achieve their best.

\n If I would categorize the problems I encountered in my career into people\n problems and software problems, it’s only the people problems that are the real\n challenge.\n

\n I'd love to have more software problems, because dealing with software problems\n is sometimes hard, but there is always a solution: fix it, hack it, or scrap it\n and take another approach.\n

\n But people problems are the ones that give me sleepless nights and stress me\n out. These problems are different: we can’t make the person on the other side do\n what we want – we can only try to get on the same level with them to resolve\n issues, but we can’t, ultimately, change them.\n

\n Somehow, as engineers, we expect people to have the same quality: to fix a\n problem, I just have to explain, really slowly, what’s wrong with them for the\n problem to go away.\n

\n However, in the past I’ve invested very little time in educating myself on\n collaboration and communication. And I am certainly not alone.\n

\n We developers happily pay (with our money and our time) for getting up to speed\n on tech topics. We don't do this for communication and collaboration skills. And\n this is not because our employers don't offer this, as they rarely offer\n structured tech training, either.\n

I want us to change this. That’s why I am writing this article.

Where to start?

\n Our industry is flooded with communities, blog posts, meetups, and conferences\n that revolve around technical skills.\n

\n Over time, I have developed a great sense for finding interesting content\n through Twitter, Slack, and YouTube because I know what to look for and my\n trained pattern recognition skill can easily identify relevant tech content. But\n when it comes to collaboration, communication, and leadership, I don’t have that\n sixth sense, yet. Let’s look at the actions I’ve taken in the past couple of\n years to start developing it.\n

Communication frameworks

\n I mentioned earlier that people problems are different to software problems,\n which means we cannot apply the same principles. I can’t fix another person,\n however,\n I am responsible for how their actions affect me.\n I decide to feel angry, hurt, annoyed, ashamed. How I feel about something is\n solely my responsibility.\n

\n There are communication frameworks we can adopt or extend on like we do for\n software. Because, as with software frameworks, communication frameworks should\n prevent us from making the same mistakes over and over again and provide best\n practices that will let us achieve our goals faster: less conflict when\n communicating with others.\n

Nonviolent communication

\n Nonviolent communication\n helps to identify my emotions and separate them from the message, it also gives\n you the tools to help the other party help you, by providing clear information\n about how you feel (without blaming them), and providing them ways to help you.\n It gives you a process to dissect communication and try to find the true\n message, which might be wrapped in emotions and hard to understand initially.\n But this is a one-sided method, where I do the analysis and do not work with the\n other person on the way they communicate.\n

\n Lara Hogan has a talk on how to use this method for feedback on LeadDev.com:\n Navigating engineering team friction,\n where she talks about the\n feedback equation. Additionally,\n Bob Marshall has a great summary about\n using NVC in the workplace.\n

Four-sides model

\n The four-sides model is a\n valuable complement to non-violent communication, since it also models a message\n as a composite of various aspects and it helps to identify and separate the\n different aspects that were amalgamated by the sender of a message. I learned\n about this model back when I was studying communication as part of my first\n professional education many years ago. It's helpful to identify the aspects\n within the model in written communication in order to better understand the\n true meaning of a message.\n

The five love languages

\n Since most people work for some kind of affirmation, the\n five love languages\n give a good model about the different ways humans are receptive of gratification\n and it is important, as a collaborator, to understand what drives them and how\n you can give them the feeling that you value their work. The important learning\n here is that means of affirmation can be completely different to your own, so\n you need to make a conscious effort to translate affirmation and gratitude in a\n way the recipient understands.\n

The core protocols

\n A few years ago I took the time to read\n The Core Protocols, but they are\n very regimented approaches to human interaction. This works for some, but in my\n experience, requires a lot of discipline. Many that experience using it, develop\n an uncanny valley feeling of being overly controlled. In my experience as an\n organizational coach, these systems do not work well with heterogeneous teams\n where you gradually change something; it's hard to explain to an ‘outsider’ why\n this makes sense and it can actually feel inhuman. It is, however, a fascinating\n source material to look into because it very explicitly highlights communication\n issues and how to deal with them.\n

Structured RFC process

\n Phil Calçado published an article proposing a\n structured RFC process\n about communication which puts a spotlight on the aspect of discussion and\n decision-making. His analysis and proposal are very valuable because\n decision-making is one major source for conflict and often a time where power\n dynamics become painfully visible.\n

Ladder of leadership

\n L. David Marquet’s\n ‘Ladder of Leadership’ is a\n really powerful concept that describes ‘angles of freedom’ in a collaborative\n relationship. What's great about it is that it provides a model for\n communication that involves everybody in making implicit rules around\n decision-making explicit, and provides a road towards enabling team members to\n make autonomous decisions.\n

Let's explore this topic together

\n I am just beginning to explore this space and I already have enough material for\n many years to come. I also invite you to run a session at an open-space you\n attend,\n like I did at the JSCraftCamp 2019,\n this is a great way to spread awareness about this topic and also collect input\n from others on the resources they use to improve their collaboration skills. One\n outcome of this session was a list of book recommendations:\n Crucial Conversations,\n Adversaries into Allies,\n and\n The Coaching Habit.\n

\n I hope I inspired you to invest more time in your real power skills: the way you\n communicate and handle conflict influences your personal and your team’s\n wellbeing tremendously. This is key to creating workplaces where people feel\n valued, heard, and understood, and where they feel safe to voice concerns,\n criticism, and can propose radical ideas.\n

Because, as Kelsey Hightower put it:

https://twitter.coderbyheart.com/status/1393194153681440780

\n","slug":"i-am-a-coder-help-me-learn-to-collaborate","hero":"!undefined"}],["i-cannot-edit-that",{"title":"I cannot edit that","abstract":"When dealing with structured data there are no tools for collaboration\n","date":"2013-08-15T00:00:00.000Z","html":"\n

When dealing with structured data there are no tools for collaboration

\n
\n In my community we meet quite often: there are usergroup meetings, networking\n events, BarCamps, StartUp Weekends — we even use the need to eat as an excuse\n to make plans on how to change the world. There is an enormous amount of\n knowledge in these communities, but we fall short in tapping it.\n
\n

Blog posts are the gravestones of ideas

\n What I am doing right now is the wrong approach — but as I am going to show you\n later I have no other means right now. Let’s say I’d like to map out the start\n up hot spots in my area. I could write up a blog post with 'The 10 hottest\nplaces for start ups in the area'. This blog post would be valid for a few\n weeks, maybe half a year. But it will rot, its data will get outdated sooner\n or later. I’d have to constantly visit and update it. But as it is with people\n engaged in communities it is with specific knowledge: it will shift to another\n person who rises as a new expert. And they will write up another blog post.\n

But what if they could collaborate on mine?

\n They can. Send me an email. Tweet me a link to a new location. I can create an\n account for them on my blogging platform — if it offers that feature.\n

\n The task of collaboration on piece of text isn’t as simple as it sounds. If you\n are in the business of asking someone for help you better make it as easy as it\n gets to collaborate with you.\n

And there the trouble starts.

We need atomic collaboration

\n Picture this:
You can go to my imagined posting about the 10 hot spots and just click on 'Add\na hotspot', provide the details of I location I missed and click send. I’d get\n a notification email with a preview of your addition and can accept it with one\n click. I can do that even without knowing who you are, as the data you provide\n speaks for itself.\n

\n This is what I call atomic collaboration. Atomic in the means of actions\n required to collaborate. They should be small. Really small.\n

We need structured data

\n You have to trust me on this: there is basically no usable way to track the\n changes to piece of text. If I want atomic collaboration I need structured data.\n I can split a text into it’s parts — headlines, paragraphs, lists,\n etc. — editing gets a lot more manageable.\n

We need open data

\n There is one last thing: collaboration on data also requires you to let go in\n terms of ownership of the content. There is no better invitation to collaborate\n on content then to make it public domain. The open source movement has shown the\n way: everyone can collaborate and if there are differences they are either\n settled or a fork is made — there never is the one solution.\n

Atomic collaboration on open structured data = ?

\n I think we all could use a github for data. A platform that is neutral in\n terms of the content it manages but makes clear decisions on how the\n collaboration is done.\n

I’ll keep on looking!

\n I did a followup a few weeks later where I explained a little,\n what I think when talking about the Github for data.\n

\n","slug":"i-cannot-edit-that","hero":"!undefined"}],["i-want-to-tear-down-the-developer-firewall",{"title":"I want to tear down the developer firewall","abstract":"I create developer firewalls for a living. And it is so wrong.\n","date":"2015-09-13T21:48:00.000Z","html":"\n

\n Until recently I understood that one of my roles as a CTO was to create a\n developer firewall that shields the developers in my team from the managers.\n Those firewalls are need to create the space for developers to actually get\n things done and give them task they can fully understand and thus focus in their\n implementation. Otherwise management would just stand in the door every other\n hour with a new idea to discuss. I create these firewalls through planning\n meetings whose purpose it is to order upcoming feature request by priority. This\n is my first firewall. Here I have the opportunity to talk down feature\n requests and eventually make them go away. If they make it through those\n meetings it is because they are either actually useful and implementable given\n the current resources or it is decided that they are important enough to be\n shoved in the already overfull schedule. If tasks make it to the roadmap I only\n have a second chance to intervene: I can try to shave off some extra\n functionality to make the first version of a feature as small as possible. Once\n they are after my second firewall the development team has to implement them if\n they like it or not.\n

\n When I saw Marty Cagans' fantastic talk titled\n \"Great Engineering, Failed Product\"\n from this years CraftConf it became clear to me\n that this is one of the things that create so much friction and make my job\n sometimes very dreadful: I'm fighting an uphill battle and because we are in the\n end fighting for the same goal there can only be losers.\n

\n But why do I fight ideas that come from the top or the management? Fighting is a\n hard word, but in the end it is exactly like that: in this pseudo-agile process\n as picture above I don't have the power to deny tasks. I simply cannot say no\n because how it is organized. There is a visionary boss who knows what's best.\n But vision unfortunately does not entail wisdom and so many of the broad ideas\n simply cannot be put in production just like that. It takes days of planning,\n talking, conceptualizing, building, testing, bugfixing for each new feature. And\n new features required changes to existing features and so forth. The more\n features you have the more noise you create in your project but also in the\n mind of the developer.\n

\n Developers are the foundation of every tech project. Yet, they bear no power.\n They don't say: stop, lets make this mess right by removing technical debt! They\n don't say: no, let's first make that feature actually complete before we jump to\n the next one. Why? And this is the crucial part: hierarchy. They don't get to\n speak up because they don't own the project. The CEO does. By now it should be\n clear that Marty Cagan is right: you can't expect great products from a team of\n developers who are not fully commited to the task they are doing because they\n were just handed down to them. In this classical scenario not all feature\n reuquest are created equal, some get a free pass to production no questions\n asked.\n

\n
\n And interesting side note: the usual argument for why the boss gets to be the\n boss is that he holds the entrepreneurial risks. But only in the rarest cases\n is he really affected by bad decisions. The first ones that will take the\n risks are the employees. If the the numbers are bad for the business and costs\n need to be cut, the quickest fix is to lay off people. So the result of bad\n decisions is handed down to the employees, where the wins by good decisions is\n often cashed in by the CEO.\n
\n

\n Cagan's picture of these rare but successful teams that built great products is\n not new, but he makes it clear to understand in his talk: no one should be\n entitled to force features. They should emerge from the team because only if and\n idea attracts enough followers (designers, developers, concepters) to realize\n it, it can make it to production and that guarantees that the persons working on\n it are actually committed to do great work. He also points out that in order for\n an idea or a feature request to be understandable they should have\n OKRs attached. This answers the why but\n leaves the how open, which can't be figured out before anyway.\n

\n This kind of organizational structure is radically different, but if we are\n honest, what are we making different than the \"old economy\" whose products we\n are trying to replace? We've attached an agile appendix to a hundred year old\n skeleton.\n

\n Imagine a place where the person that owns a majority of the company comes to\n your desk and instead of saying: \"Paint the shed in the backyard green by the\n end of the week.\" he asks you: \"I need your help for making our backyard\n prettier.\" and he would expect you to decline, if you were busy. Would'nt this\n be great? No firewalls in sight.\n

\n","slug":"i-want-to-tear-down-the-developer-firewall","hero":"!undefined"}],["i-wore-a-t-shirt-demanding-inclusivity-at-a-tech-conference-and-this-is-what-happened",{"title":"I wore a T-Shirt demanding Inclusivity at a Tech Conference and this is what happened","subtitle":"SoCraTes 2019","abstract":"A subtle way to hack your community.","date":"2019-10-13T08:00+02:00","html":"\n

SoCraTes 2019

\n I have\n previously written\n that the\n SoCraTes conference in Soltau, Germany is my\n absolute favorite (besides CodeFreeze and\n CodeBreeze which I help to organize\n obviously), and I was especially amazed about the progress in terms of diversity\n that took place last year. I was\n confident that this year would be even better because at SoCraTes we manage to\n bring a critical mass of mindful humans together that actively push for\n inclusivity and safety at tech conferences. This mindset permeates permeates\n every thing that happens at the conference which enables newcomers to quickly\n open up and contribute with their entire self.\n

Nevertheless I felt the urge to make a statement.

\n I had visited two open-space conferences this year who are part of the\n ever growing community of Software Crafters\n around the world. And at these events diversity was lacking, which was due to\n their geographical situation. However, living in Norway, I totally get that it\n is sometimes impossible to achieve diversity amongst event attendee if the\n structure of the industry itself is absolutely dominated by men.\n

The issue then arises is when attendees use English as the common language and\naddress the entire room as Guys.

\n I am absolutely aware that for many it's not a conscious decision, and they did\n not intend to address everyone as men, but are using guys in a\n gender-neutral form.\n

\n However many are painfully aware of the literal translation because they are\n non-native speakers and did not grow up with Hey guys! being used as an idiom\n and not as a way to selectively address the male members of a group.\n

After all Guys is not gender neutral:

https://twitter.com/etiene_d/status/994509163693838337

\n Not convinced? Please read this\n extensive post about the topic.\n

Calling everyone a Guy 🤵 is one of these microaggressions that keep reminding some members of our community that they are not recognized. 🤦‍♀️

\n Now, changing behaviour is hard. And especially at events I find it impolite\n to interrupt someone (especially in public) if they use Guys. They most likely\n are not aware how it makes others feel and there is a high chance that it puts\n them in a spotlight which in most times will make them turn into\n aggressive-defensive mode rather than considering their behaviour.\n

\n This holds true for online communities as well. It is much more helpful to reach\n out to a person in a private chat and ask them to consider their wording then\n pointing it out in the public thread. There they even have the chance to edit\n their postings.\n

This obviously is not possible at events.

This t-shirt is like a friendly virus

So I made this t-shirt:

https://twitter.coderbyheart.com/status/1164957001438433280

\n You can download the layout files\n here, so you can\n print your own version yourself (I printed this shirt at Spreadshirt for\n €33,98).\n

Wearing a t-shirt like this at an event has some interesting aspects to it:

\n I wore it the entire day, so I could reach many attendees with this message,\n without sounding like a broken record.\n
\n It is specific in it's message, but does it in a way that addresses everyone\n at the event, which means it will nudge people to think about their behaviour\n but in a way that does not single out individuals\n
\n The t-shirt got recognized and mentioned during the open-space, so others were\n building, and extending on it.\n

\n I did not witness the use of Guys to address a group, but I would address this\n to the lovely group of people that come to SoCraTes every year. Or maybe the\n t-shirt worked, who knows?\n

Privilege emphasizes the message

\n It is important to also recognize that it was I who wore the t-shirt and what\n this means for the message.\n

\n First, I felt safe to be able to wear a T-Shirt at my favorite conference\n which clearly demanded something specifically from its attendees. Newcomers\n and members of underrepresented groups often do not feel safe enough to express\n messages like this. As a community it is the job of the overrepresented to\n recognize issues and advocate for the change.\n

\n Second, being recognized by Softwarecraftmen as one of their own makes the\n recipient of the message being more likely to consider it. Change works best\n peer-to-peer, if the recipient of a message can identify with the messenger they\n are more likely to consider it.\n

\n We can change our industry only if we as those who have benefited for years from\n its homogeneity put effort into it—and we have the luxury of being\n listened to by those that need to change.\n

\n","slug":"i-wore-a-t-shirt-demanding-inclusivity-at-a-tech-conference-and-this-is-what-happened","hero":"!undefined"}],["improving-the-startup-weekend-experience",{"title":"Improving the Startup Weekend Experience","abstract":"In my opinion the default shedule for the weekend is not educating the teams enough to focus on what matters in those 54 hours: *validate their assumptions* about the business idea and *prepare a presentation*. For this year I've created a new shedule which includes more concrete deliverables and divides the weekend into distinct slots.\n","date":"2015-05-31T17:50:00.000Z","html":"\n

\n I've been organizing and attending more then a dozen events in the format of a\n Startup Weekend in the past three years. In my opinion the\n default shedule for\n the weekend as proposed by the up.com, the Startup Weekend Organization, is not\n educating the teams enough to focus on what matters in those 54 hours: validate\ntheir assumptions about the business idea and prepare a presentation.\n Therefore I've created a new shedule which includes more concrete deliverables\n and divides the weekend into distinct slots which put the focus on them. The\n goal is to prepare and equip every team with the material and knowledge they\n need to talk to investors and new team members–because this is what they will be\n doing after the weekend.\n

The new schedule at a glance

\n The Friday schedule is kept unchanged. The difference is that once the teams\n have formed their task is to deliver their mission statement and an elevator\npitch.\n
\n The task for Saturday morning is to define three assumptions about the\n business, e.g. why this idea will succeed, who are the customers, what is the\n market. The team then uses the time after lunch until dinner to evaluate the\nassumptions by going into the city to conduct interviews and finding their\n first real customers.\n
\n Sunday is dedicated to building a compelling pitch. This can be in the\n form of a presentation or a prototype. It is important to focus on every\n aspect of the idea: business, realization, team, uniqueness, and wit!\n
\n The schedule also includes more clearly defined slots for the presence of the\n coaches.\n

Deliverables

Teams are tasked to deliver:

a written mission statement (max. 10 words)
an elevator pitch (max. 1000 characters)
written assumptions about their business and evaluation plan
a written evaluation of those assumptions
a business plan presentation (max. 3 slides)
a pitch slidedeck

Schedule

\n | Time | Activity | Task | Coaches |\n | -----------: | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------- |\n | Friday |\n | 1800 | Registration | - | - |\n | 1830 | Registration | - | - |\n | 1900 | Dinner | - | - |\n | 1930 | Welcome & Pitches Start | Optionally line up to give your pitch | Present for introduction |\n | 2000 | Pitches | \" | Present |\n | 2030 | Voting | Attendees vote for the top pitches | Present |\n | 2100 | Form Teams | Find your team for the weekend | Coaches briefing |\n | 2130 | Form Teams | \" | \" |\n | 2200 | Mission Statement | Begin to work on your idea. | Assist team building, mission statement |\n | 2230 | Elevator Pitch | \" | Present |\n | 2300 | Deliver | Written mission statement (max. 10 words) and elevator pitch (max. 1000 characters). | Coaches leave |\n | 2300 | Build | Work on your idea until the venue closes. | - |\n | Saturday |\n | 0830 | Breakfast |\n | 0900 | Assumptions | Define three assumptions about your business and plan how to evaluate them. | - |\n | 0930 | Assumptions | \" | - |\n | 1000 | Assumptions | \" | - |\n | 1030 | Assumptions | \" | - |\n | 1100 | Assumptions | \" | Present to give feedback. |\n | 1130 | Assumptions | \" | Present |\n | 1200 | Deliver | Written assumptions and evaluation plan. | Present |\n | | Feedback | Get feedback from the coaches. | Present |\n | 1230 | Lunch |\n | 1300 | Evaluate | Leave the location and go to the city to evaluate your idea by talkting to possible clients. Try to find your first customers! | Presence optional |\n | 1330 | Evaluate | \" | \" |\n | 1400 | Evaluate | \" | \" |\n | 1430 | Evaluate | \" | \" |\n | 1500 | Evaluate | \" | \" |\n | 1530 | Evaluate | \" | \" |\n | 1600 | Evaluate | \" | \" |\n | 1630 | Evaluate | \" | \" |\n | 1700 | Evaluate | \" | \" |\n | 1730 | Evaluate | \" | \" |\n | 1800 | Evaluate | \" | \" |\n | 1830 | Dinner | Return to the venue to replenish your energy | \" |\n | 1900 | Evaluate | Evaluate what you have learned together with the coaches. Write down what you have learned. | Coaches help interpreting the learnings. |\n | 1930 | Evaluate | \" | Present |\n | 2000 | Deliver | Written evaluation of your assumptions. | - |\n | | Business Plan | Formulate your business plan. | Coaches help to get you started. |\n | 2030 | Business Plan | \" | Present |\n | 2100 | Business Plan | \" | Present |\n | 2130 | Business Plan | \" | Present |\n | 2200 | Deliver | Deliver your business plan presentation. Three slides max. | Coaches leave |\n | | Build | Work on your idea until the venue closes. | - |\n | Sunday |\n | 0830 | Breakfast |\n | 0900 | Pitch slidedeck | Work on your pitch presentation and slidedeck. The slidedeck must include: a summary of your saturday learnings, the business plan slides, team presentation with names and contact information. | - |\n | 0930 | Pitch slidedeck | \" | - |\n | 1000 | Pitch slidedeck | \" | - |\n | 1030 | Pitch slidedeck | \" | - |\n | 1100 | Pitch slidedeck | \" | - |\n | 1130 | Pitch slidedeck | \" | - |\n | 1200 | Pitch slidedeck | \" | - |\n | 1230 | Lunch | - | - |\n | 1300 | Pitch slidedeck | \" | Present to give feedback |\n | 1330 | Pitch slidedeck | \" | Present |\n | 1400 | Pitch slidedeck | \" | Present |\n | 1430 | Pitch slidedeck | \" | Present |\n | 1500 | Pitch slidedeck | \" | Present |\n | 1500 | Deliver | Pitch slidedeck. Failure to deliver will result in pitching without a deck. | - |\n | | Pitch practice | Practice your pitch | Present to give feedback |\n | 1530 | Pitch practice | \" | Present |\n | 1600 | Pitch practice | \" | Present |\n | 1630 | Pitch practice | \" | Present |\n | 1700 | Pitches! | Time to shine on stage | - |\n | 1730 | \" | \" | Present |\n | 1800 | Dinner | - | Present |\n | 1830 | Judging | - | Present to answer judges questions |\n | 1900 | \" | - | Present |\n | 1930 | Awards | - | Present |\n | 2030 | Wrap-Up | - | Present |\n | 2100 | Go Home! | - | - |\n

\n","slug":"improving-the-startup-weekend-experience","hero":"!undefined"}],["intents-auf-android-testen",{"title":"Intents auf Android testen","abstract":"Mit der adb shell ist es einfach möglich das Handling von Intents zu testen ` sehr praktisch, wenn man z.B. in der App normalerweise einen QR-Code-Scanner verwendet, um eine URL zu erhalten.\n","date":"2012-01-26T00:00:00.000Z","html":"\n

\n Mit der adb shell ist es einfach möglich das Handling von Intents zu testen `\n sehr praktisch, wenn man z.B. in der App normalerweise einen QR-Code-Scanner\n verwendet, um eine URL zu erhalten.\n

Das Kommando

adb shell am start -a android.intent.action.VIEW -d 'http://www.google.de'

öffnet z.B. den Browser.

\n","slug":"intents-auf-android-testen","hero":"!undefined"}],["intro-to-the-frankfurt-tech-scene",{"title":"Intro to the Frankfurt Tech scene","abstract":"This post tries to provide an entry point for newcomers to Frankfurt","date":"2016-08-01T08:00:00.000Z","html":"\n

\n This post tries to provide an entry point for newcomers to the tech scene in\n Frankfurt.\n

\n To get to know your locals, join the\n {fradev} Slack channel.\n {fradev} itself is\n currently the biggest generic group on Meetup where developers and of course\n non-developers meet.\n

\n If you are looking for a more specific topic and want to meet people that code\n in your language of your choice, check out the\n list of technology user groups or\n @ugsrock on Twitter. With more than 100 there is\n no shortage of events to go to. We have days where you had four events on on\n evening to attend. Gone are the days of the early 2010s when there was just on\n event in two weeks.\n

\n An important entry point to the startup scene is the\n Founders Table\n which meets every month. In the city of banks you can't avoid FinTech either,\n the\n FinTech Meetup\n is hands-down the biggest regular meetup in Frankfurt.\n

\n The mother of all tech events in Frankfurt is the\n Webmontag, now in its 10th year, a great opportunity to\n connect with people that are somehow doing things with the internet, and if you\n have a project or are looking for support they always provide spotlight slots on\n their stage. A must-go once every month!\n

\n A neighbor to the Webmontag is the Hashtag\n #RheinMainRocks a lot\n of Tweeps from the area use it to mark up local events and news related to the\n net community (Internetgemeinde) we affiliate ourselves with.\n

\n If you are a remote coder like me and in need of an awesome place to work from,\n come visit me for a coffee at\n Die Zentrale Coworking located in Bornheim\n Mitte which is the Friedrichshain of Frankfurt. Zentrale offers coworking plans\n from €90/mo with great coffee and awesome coworkers.\n

\n To learn more about Frankfurt in general, check out\n hallofrankfurt.de, written by and for Hipsters.\n

\n That should give you a good head start … but if there is anything important that\n I've missed, please drop me a comment,\n tweet me or\n mail me!\n

\n P.S.: Arguably Frankfurt is just the center of the rural area we call\n Rhein-Main-Gebiet so it's fair to mention that there are more and more events\n happening outside of Frankfurt, namely in Darmstadt given its strong tech scene\n connected to the local university. But given its central location with the\n biggest train station in Germany Frankfurt remains the gold standard for cities\n to run an event in.\n

\n","slug":"intro-to-the-frankfurt-tech-scene","hero":"!undefined"}],["introducing-teamstatus.space",{"title":"Introducing teamstatus.space","subtitle":"side-projects","abstract":"Use teamstatus.space to collect project status updates asynchronously and distributed to speed up your sync meetings","date":"2023-09-06T00:30:00.000+02:00","html":"\n

\n
\n collect project status updates asynchronously and distributed to speed up your\n sync meetings\n
\n

\n I am happy to announce a side-project that I’ve been working on for a while, and\n which I have been using daily since its inception.\n

\n Use teamstatus.space to track what you are working on, as it happens. It may be\n small updates, or big releases.\n

Status updates are associated with projects, which belong to organizations.

\n You can invite coworkers to the projects you are working on. They then can also\n add their own status to the project.\n

\n Team members can see status, and add reactions. They are an important tool to\n share praise 🌟, but also prepare the next sync meeting. Status can be marked as\n significant 🚀, so they will be highlighted in the next sync. Or a status can be\n marked as a question 🙋 so they can be discussed during the sync.\n

\n And when it's time for a sync meeting with your collaborators, you create a new\n sync which collects all the status updates from the projects your meeting is\n about, from all the collaborators and a time frame you can specify.\n

\n This way you do not have to remember all the big and small things that happened\n since your last sync with this team; or the other group of stakeholders you only\n meet every other week.\n

\n And since you can share what happened in advance, you can spend your time during\n the meeting to discuss the highlights and the open question which\n ensures that everyone's time is used most efficiently.\n

\n This project is in an early stage and I am interested to hear your feedback,\n especially whether this is a tool you would use yourself. As a thank you for\n your input you’ll be able to keep using the tool without charge with all paid\n features, if and when this turns into a paid service.\n

\n I’ve created a self-guided onboarding flow which will guide you through the\n features, so just head over to https://teamstatus.space to sign up. I’m happy\n to receive your feedback on a channel that you prefer, but I want to dog-food\n it, so please use the $teamstatus#feedback project for your feedback.\n

\n","slug":"introducing-teamstatus.space","hero":"!undefined"}],["introduction-to-tdd-in-javascript",{"title":"Introduction to TDD in JavaScript","subtitle":"CodeDoor Challenges for 2018","abstract":"Introducing Beginners to Test-Driven-Development in JavaScript","date":"2018-01-01T18:00+01:00","html":"\n

\n Since I am remote and a little disconnected from the day to day mentoring I have\n decided to try something new in 2018 for my mentoring at\n CodeDoor.\n

\n I've created a coding challenge at\n github.com/coderbyheart/codedoor-challenges\n (and I plan to add more) which contains real-world problems in a real-world\n JavaScript project set-up how I am using it every day at work.\n

\n The goal is for beginners to get a little more familiar with GitHub and receive\n an introduction to\n Test Driven Development (TDD)\n — a way to write software which gives you immidiate feedback about the\n quality of the code you are writing.\n

\n Later on I plan to introduce challenges that cover the\n S.O.L.I.D. architecture principle.\n

\n These challenges are not for total beginners, you should have implemented a\n handful of solutions in JavaScript already.\n

\n Please let me know if you want to start working on the first challenge, and join\n the gitter channel, so I can\n support you. Alternatively you can\n DM me on Twitter.\n

\n","slug":"introduction-to-tdd-in-javascript","hero":"!undefined"}],["it-does-not-run-on-my-machine",{"title":"It does not run on my machine","subtitle":"Integration testing a cloud-native application","abstract":"In this talk I will take you through the challenge of testing a cloud-native application. I will cover the challenges when developing solutions on top of serverless components which you cannot run on your own machine and how I designed a BDD driven approach to run the integration tests.","date":"2019-06-30T00:00+02:00","html":"\n

\n In this talk I will take you through the challenge of testing a cloud-native\n application. I will cover the challenges when developing solutions on top of\n serverless components which you cannot run on your own machine and how I\n designed a BDD driven approach to run the integration tests.\n

\n You can find the slides\n here.\n

https://www.youtube.com/embed/yt7oJ-To4kI

\n Here is an\n example project where you try out this approach in your own AWS account.\n

\n","slug":"it-does-not-run-on-my-machine","hero":"!undefined"}],["j-on-the-beach-2018",{"title":"J On The Beach 2018","subtitle":"A tech conference in Malaga","abstract":"End of May I had the opportunity to fly to Malaga in Spain and speak at J on the Beach.","date":"2018-06-15T19:00+02:00","html":"\n

\n End of May I had the opportunity to fly to Malaga in Spain and speak at\n J on the Beach.\n

\n This was one of the most exciting conference experiences for me. The conference\n took place in a historic bath house, which had been turned into a event\n location. It was perfectly equipped with air-conditioned rooms featuring\n sound-systems, beamers and cinema-chairs, a great, green outdir area and-as the\n name implies-is directly located at the beach in Malaga. I could not resist to\n use the opportunity to take a swim in the (still cold) sea!\n

\n The attendees and also speaker linup was very diverse: out of 56 speakers, 20\n were women (36%). It was fantastic to see that the organizers effort to attract\n speakers from underrepresented groups paid off.\n

\n Although this conference started as a Java conference, this was hardly\n noticable. I enjoyed many great talks and also my own talk (the one about IoT\n and JavaScript) was very well received, I had a full room and received great\n feedback.\n

\n I can highly recommend this conference and will definetly come back, not only\n because there is a direct flight from Trondheim to Malaga, but because I'd like\n to spend more time in this beautiful city.\n

\n You can check out my pictures from this trip\n on flickr.\n

\n","slug":"j-on-the-beach-2018","hero":"!undefined"}],["javascript-dependency-management-with-greenkeeper-on-aws-codebuild",{"title":"JavaScript Dependency Management with Greenkeeper on AWS CodeBuild","subtitle":"Continuous Integration of JavaScript projects","abstract":"You can now run Greenkeeper with lockfile support on AWS CodeBuild.","date":"2018-05-21T14:00+02:00","html":"\n

\n I recently had the opportunity to look into some fundamental Continuous\n Integration and Deployment techniques we use to build\n nrfcloud.com. We rely heavily on AWS, so it was natural\n to look into using AWS CodeBuild as a\n task runner for our private repositories.\n

\n I previously had a fantastic experience working with\n Travis CI, but it adds a hefty fixed price to an\n infrastructure. On AWS CodeBuild costs occur only during the runtime of jobs\n (which are run in Docker containers). This, and a potential better integration\n with other AWS services, gave me the initial reason to look into using it as the\n main task runner for our TypeScript projects.\n

\n If you work with JavaScript the number one reason for changes in your software\n are dependencies. The number of dependencies that changes on a daily basis\n is staggering. The only sane way to deal with this quirk of the JavaScript\n eco-system is to fully embrace it. Roll with the tide and make sure your\n software runs with the latest version of its dependencies.\n

\n One precondition is to have tests. The benefits of tested software,\n especially in a fast-moving environment, are manifold and I have been practicing\n TDD for many years. Tests will ensure that a piece of software still works if\n you change a dependency.\n

\n Another invaluable helper is Greenkeeper: it will\n send you a pull-request if a dependency is updated, which will in turn trigger a\n CI build. If everything works fine, you are left with merging a PR. It's a\n 1-click solution to updating dependencies and it makes working with dependencies\n fun again.\n

\n Since npm 5 there is also a new and improved lockfile:\n package-lock.json, which is\n a huge improvement over the old shrinkwrap. It ensures that when running\n npm ci only the exact dependencies described in the lockfile will be\n installed. This enables reproducible builds\n builds of our package and we can be certain that we have the exact same executed\n code in production that we ran when testing.\n

\n Greenkeeper has an addon called\n greenkeeper-lockfile\n which takes care of updating the lockfile just for the dependency after a\n successful test run.\n

\n A changed dependency also calls for a new release of the host package, and this\n in turn will trigger updates and releases to packages that depend on the host\n package. Managing this manually would simply be insane, or just plain\n monotonous. But thankfully to\n semantic-release the\n process of release new versions can also be automated! (I have explained the\n whole the process in\n these slides\n in 2016).\n

\n All of the tools above require Node.js v8 andw when I started to run the first\n of our packages on AWS CodeBuild the official Node.js Docker image did only\n support Node.js v4 and v6. This\n has been fixed on May 2nd\n and CodeBuild now has an official Node.js v8.11 image.\n

\n I already had begun to add CodeBuild support to\n env-ci, which Greenkeeper uses to detect if\n it is running in a CI environment and in which. Since the official images uses\n an outdated Git version (1.9) it required\n some back and forth until we figured\n it out.\n

\n The next task was to get greenkeeper-lockfile to work in AWS CodeBuild runs\n which I have implemented\n in this PR.\n Also here I needed to deal with a quite old Git version and figuring out\n CodeBuilds way of cloning the repo. It also does not provide all the necessary\n details about the build in the environments so I needed to persist that during\n the build, since greenkeeper-lockfile will apply changes to the repository --\n it is updating the lockfile and commit this back to the PR.\n

\n Using a buildspec.yml like this we finally can have automated library releases\n and dependency management on AWS CodeBuild!\n

version: 0.2\nphases:\n  install:\n    commands:\n      - echo \"updating git ...\"; apt-get update; apt-get install -y python-software-properties software-properties-common; add-apt-repository ppa:git-core/ppa; apt-get update; apt-get install -y git\n      - npm install -g npm@\n      - npm install -g nRFCloud/greenkeeper-lockfile\n      - npx greenkeeper-lockfile-update\n      - npm ci --no-audit\n  build:\n    commands:\n      - npm test\n  post_build:\n    commands:\n      - npx greenkeeper-lockfile-upload\n      - npx semantic-release\n

Notes:

\n we update git to the latest stable version, since semantic-release\n now depends on >=2.0.0\n
we run npm install -g npm@ to ensure we are running the latest stable npm
\n we use our\n patched version of greenkeeper-lockfile\n
\n we disable audit on npm ci\n to not slow down the install\n

And here is the result on a real PR:

\n","slug":"javascript-dependency-management-with-greenkeeper-on-aws-codebuild","hero":"!undefined"}],["jaxp-dom-whitespace-aus-xml-entfernen",{"title":"JAXP DOM: Whitespace aus XML entfernen","abstract":"In Java 1.6 gibt es einen Bug im Dom-XML-Parser, der Whitespaces trotz aktiviertem Hinweis nicht entfernt.\n","date":"2010-06-16T00:00:00.000Z","html":"\n

\n In Java 1.6 gibt es einen Bug im Dom-XML-Parser, der Whitespaces trotz\n aktiviertem Hinweis nicht entfernt.\n

DocumentBuilderFactory domBuilderFactory = DocumentBuilderFactory.newInstance();\ndomBuilderFactory.setIgnoringElementContentWhitespace(true);\n

Abhilfe schafft da diese Methode:

/**\n * Entfernt whitespace aus dem Document\n *\n * @see http://forums.java.net/jive/thread.jspa?messageID=345459\n * @param e\n */\nprivate static void removeWhitespaceNodes(Element e) {\n    NodeList children = e.getChildNodes();\n    for (int i = children.getLength() - 1; i &gt;= 0; i--) {\n        Node child = children.item(i);\n        if (child instanceof Text && ((Text) child).getData().trim().length() == 0) {\n            e.removeChild(child);\n        } else if (child instanceof Element) {\n            removeWhitespaceNodes((Element) child);\n        }\n    }\n}\n

\n","slug":"jaxp-dom-whitespace-aus-xml-entfernen","hero":"!undefined"}],["joining-ctmafri",{"title":"I've joined CreaTech Motives Afrika's Advisory Board","subtitle":"Volunteering","abstract":"I support the leadership of CreaTech Motives Afrika as a technical advisor as part of their advisory board.","date":"2023-01-01T18:00+01:00","html":"\n

\n
\n Update: End of September 2023 I have decided to step down from the advisory\n board.\n
\n

\n I've joined the Advisory Board of\n CreaTech Motives Afrika as a technical advisor.\n

\n CreaTech is a Ghana-based initiative that creates educational programs that aim\n to teach young children programming skills and inspire them to become the next\n generation of problem solvers and tech entrepreneurs in Ghana.\n

\n I support the leadership of CreaTech Motives Afrika as a technical advisor as\n part of their advisory board.\n

\n One of their projects is algo peers which is supported\n by the micro:bit foundation and my employer\n Nordic Semiconductor\n and I got the chance to speak to the team a while ago (please excuse my bad\n audio in the recording):\n

https://www.youtube.com/embed/8YHZi0BEgcc

\n","slug":"joining-ctmafri","hero":"!undefined"}],["jotb2018-interview",{"title":"JOTB2018 Interview","subtitle":"JavaScript and IoT","abstract":"I was interviewed after my talk about Prototyping products for the Internet of Things using JavaScript","date":"2018-09-09T16:30+02:00","html":"\n

\n After my talk Prototyping products for the Internet of Things using JavaScript\n (Slides)\n I was interviewed by Alexandra M. Sims, part of\n the questions were asked by the audience. I really loved how they added this Q&A\n segment to every talk and that attendees could post questions and get them\n answered even if they could not make it to a session.\n

You can watch the full video on YouTube:

https://www.youtube.com/embed/6rBHje_ciGM

I have selected some interesting questions on #JavaScript:

https://twitter.coderbyheart.com/status/1038791853431312384

https://twitter.coderbyheart.com/status/1038791857818533888

https://twitter.coderbyheart.com/status/1038791862239289345

\n","slug":"jotb2018-interview","hero":"!undefined"}],["joy-inc",{"title":"Joy, Inc.","subtitle":"Book review","abstract":"Book review of Joy, Inc. by Richard Sheridan\n","date":"2016-01-01T17:00:00.000Z","html":"\n

\n I can't remember where I stumbled upon the recommendation for\n Joy, Inc.–How We Built a Workplace People Love by\n Richard Sheridan but having read it at the\n beginning of this very new year couldn't have come at a better time.\n

\n In this very well told book Richard describes how coming from a dreadful time of\n IT projects that were executed as death marches he built\n Menlo Innovations based on the believe that\n aiming for joy would be the highest value of his enterprise. He defines joy\n as working on meaningful projects in an environment where fear is absent and\n everyday actions have the purpose of delivering a product that customers love.\n

\n This notion in itself is not surprising or new but what makes this book an\n exemption from the many Make-Your-Employess- Happy-To-Build-Great-Products-Books\n which describe organizations that are great places to work at he describes\n what methodologies Menlo Innovations uses in great and applicable detail. In\n addition he doesn't fall short in explaining how his ideas are able to enable a\n sustainable and growing business with happy clients while creating a working\n environment that is free from overtime, has full vacation flexibility and leaves\n room for employees to engage in social community and educational work.\n

\n Joy, Inc. leaves no excuse to go on the pursuit of joy at the workplace on\n your own.\n

\n","slug":"joy-inc","hero":"!undefined"}],["jscraftcamp-2019",{"title":"JSCraftCamp 2019","subtitle":"Conference Retrospective","abstract":"How I experienced JSCraftCamp and my key take-a-aways.","date":"2019-07-22T18:00+02:00","html":"\n

\n After two years of absence I was able to attend the 2019 edition of\n JSCraftCamp thanks to the very generous conference\n policy my employer Nordic Semiconductor has.\n (This meant flying from Trondheim to Munich but I compensated this flights CO₂\n emissions with Atmosfair.)\n

\n In this post I want to write about how I experienced JSCraftCamp and my key\n take-a-aways.\n

About JSCraftCamp

\n JSCraftCamp is a BarCamp style event focusing on all things JavaScript and takes\n place every year in Munich in the\n beautiful offices\n of Virtual Identity AG next to the Isar.\n This location is exceptionally well suited for an Open Space, since it offers\n many indoor and outdoor spaces to gather around a whiteboard, beamer or table\n — and the way the building is layed out creates a lot of possibilities to\n interact or relax.\n

https://twitter.coderbyheart.com/status/1152127446721933313

\n JSCraftCamp belongs to a bigger family of\n Software Craft conferences around the globe and\n is entirely organized by the community. The event is free for attendees and all\n costs (e.g. for Coffee, Food, Location) are covered directly by sponsors. If you\n want to sponsor this event in the future, check out\n this dedicated page — sponsoring\n starts at 100 €.\n

\n It was great so see that Sponsors also came from the community and took part in\n the open space, this created a much better atmosphere compared to other\n conferences where sponsors engage with a much stronger focus on hiring and\n selling services.\n

\n With over 100 participants signed up for both days, most of them showed up on\n Friday. The Saturday saw more no-shows. I guess this is understandable given\n that the weather on Saturday was really good.\n

Food

\n A word on food, because this is always one of the big headaches when organizing\n a conference: it's time to default to plant-based food.\n

\n It was sad to see that the BBQ during the party on Friday focused mostly on\n serving supermarket meat, while vegetarians and especially vegans had a hard\n time finding a decent option.\n

https://twitter.coderbyheart.com/status/1152265721059139584

\n I recommend conference organizers to look into options that can be prepared in\n advance and can serve everyone: chilies, lentil soups, or pastas can all be\n prepared in big portions, in advance and without needing to use meat or dairy\n ingredients.\n

https://twitter.com/Frerichs_S/status/1152525241840799747

\n I really loved the lunch: Burritos were served with meat, but also in sufficient\n quantities as vegetarian and vegan option, and everybody could be served at once\n ...\n

\n Coffee supply by Peerigion was amazing, they even had\n milk alternatives!\n

https://twitter.com/peerigon/status/1152129002032812034

Marketplace

https://twitter.coderbyheart.com/status/1152135865201770497

\n This was my first marketplace which was facilitated by\n Cecilia Maria Zannini and she did an\n incredible job of opening up the space and creating an inclusive and welcoming\n atmosphere. You could really tell that she cared deeply about making these two\n days special.\n

https://twitter.coderbyheart.com/status/1152129402890854400

Both days had a good variety of sessions:

https://twitter.com/ajitsonlion/status/1152143860237307905

https://twitter.com/NarigoDF/status/1152504992286289920

My key take-aways

\n I tried to find a good balance between sharing and helping others while also\n getting input on some of things I am struggling with.\n

fp-ts

\n This was a pull session on fp-ts where we\n tried for an hour to fix a seemingly trivial function code example I had, where\n I wanted to turn a non-functional exception throwing code into an implementation\n which does not rely on exceptions for flow control.\n

\n After we did not manage to solve it in the session, I pushed\n the most simple example on GitHub.\n

\n After going back and forth and getting more feedback from attendees, I finally\n managed to solve it on the next day:\n

https://twitter.coderbyheart.com/status/1152591342079565825

This is why I love Open Spaces so much!

Ask me anything: GraphQL

https://twitter.coderbyheart.com/status/1152545454137253888

\n The questions I got made once again clear that GraphQL seems to be a technology\n that offers great benefits but those benefits are not immediately obvious to\n everyone. In this session I mostly talked about concerns of backend engineers\n and what they need to know in order to be open towards the adoption of a GraphQL\n API.\n

Brown Bag: Hexagonal Architecture

\n During lunch I hosted a session on hexagonal architecture, by giving a\n walk-through the code base of a recent project of mine but I ended up running\n out of time because it took longer than expected to come to the core starting\n from the outermost view of our system. I started with the\n C4 model's context diagram which is great for explaining\n the entire system but I should have prepared this session a little better to\n actually receive more feedback — which was the point for me to host this\n session: get other peoples opinion about the system I designed.\n

https://twitter.coderbyheart.com/status/1152546213830516736

https://twitter.com/_sasidhar/status/1152888906041503744

Learn to collaborate

https://twitter.coderbyheart.com/status/1152190229601820672

\n This was a great session around the topic I am working on for\n my next talk: how can I become better at\n collaborating?\n

\n We collected skills and actions that make us better collaborators, and the main\n takeaway for me of this session was that it seems that we can grow our set of\n strategies to deal with communication or collaboration issues, but it is hard to\n change your own empathy — some of the \"skills\" mentioned on the flipchart\n are harder to change than others but it's possible to improve here in similar\n ways like with programming. I just don't work on improving them as structured\n right now.\n

Package registries

https://twitter.com/seriousManual/status/1152232064206475264

\n In this session we mostly talked about how we can deal with the no longer\n unlikely event that npm will shut down. We looked at\n some alternatives and especially for browsers there is already good support of\n fetching dependencies without bundling them from CDNs.\n

\n The pain point will be moving away from a centralized service which will create\n more problems in terms of reliability (if fetching dependencies from many\n external sources) or costs (managing your own registry).\n

Things to look into are:

entropic
\n using nix:\n https://github.com/adnelson/nixfromnpm\n
\n and for browsers to user script type=module\n and resolve dependencies from URLs.\n

https://twitter.coderbyheart.com/status/1152451215978110979

There is even more to discover even now that the JSCraftCamp is over:

\n the hashtag\n #jscc19\n tracks what happened during the event\n
\n there is the\n #jscraftcamp_org channel\n on the Software Crafters Slack to keep in\n touch and follow up\n
\n you can find the session notes for all sessions in\n this repository.\n

Thanks

https://twitter.coderbyheart.com/status/1152628944795054081

\n","slug":"jscraftcamp-2019","hero":"!undefined"}],["juniors-in-remote-teams",{"title":"Juniors in remote teams?","subtitle":"Some ideas how to make it work","abstract":"Having juniors in a remote team is a challenge, but you still can make it work.","date":"2017-07-24T14:30+02:00","html":"\n

\n Patrick Heinese\n yesterday asked on Twitter:\n

\n
\n I find the remote-first approach very unfriendly for juniors. How do you\n mentor and teach in such an environment? Any experiences?\n
\n

\n I agree, since working remote requires a high level of self-direction and\n communication skills, which are not developed in a junior yet. I still think you\n can make it work.\n

\n Regardless of experience I always start to onboard remote employees by having\n them on site. Or, in case of a junior, bring them to the colleagues the will be\n working with the most time. This should be at least 1-2 weeks. Their mentor\n should be available most of the time, of course, to explain them how you work\n and set up the juniors hardware, webcam, etc.\n

\n After the local phase, it's critical that the juniors behavior regarding work is\n evaluated. Are they working regularly, with a good pace. Is their workplace\n (coworking, home) good for them? This phase should have at least a few hours per\n day sync communication via video. Or just audio, but simulate being in the same\n room. Screensharing will happen often, so use TeamViewer in order to have full\n access to their computer.\n

\n Communications can now gradually become less sync, but you need to be prepared\n to do a lot sync, if they are learning new topics.\n

\n It's also critical to check how they like this style of work, of the feel lonely\n move them to a coworking space and train them to ask a lot of questions. This is\n especially hard, if you put questions into writing, because you feel even more\n intimidated to show that you don't know something.\n

\n For the mentor it's important to be available for jumping in video chats\n quickly. This means you have to reserve time and can't quickly switch between\n your work and their problem because it's harder to keep track of what they are\n doing.\n

\n Have a whiteboard behind your desk on the wall, and thick markers, so you can\n quickly explain things by drawing them. This works pretty with FullHD webcams\n these days.\n

\n","slug":"juniors-in-remote-teams","hero":"!undefined"}],["just-edit-it",{"title":"Just edit it!","abstract":"We need tools not protocols for editing content on the web.\nIn my first article I barely scratched the surface of what is missing to encourage collaboration on public available data. In this article I’d like to share my view of what is missing.\n","date":"2013-08-23T00:00:00.000Z","html":"\n

We need tools not protocols for editing content on the web.

\n In my first article I barely scratched the surface of\n what is missing to encourage collaboration on public available data. In this\n article I’d like to share my view of what is missing.\n

\n I have a publicized a list of technology user groups from my area at\n usergroups.rheinmainrocks.de. The list\n is driven by a collection of XML files describing each group. The XML files are\n hosted in a GIT repository at GitHub.\n They can be edited by everybody.\n

Everybody can edit public on GitHub already. Everybody?

\n Well, at least if he is accustomed to the git pull request workflow, the file\n format in place, can speak english (as this is GitHubs only interface language),\n has an account on github.com.\n

\n If I want every member of my audience to enhance my collection of data about\n usergroups—GitHub pull requests on XML files would not be the choice. I picked\n it because it is easy to manage. From a contributors point of view another\n approach would be much more feasable: fill in some kind of form and be done with\n it.\n

Look Ma! No login!

\n Yes, I am talking about anonymous submissions. I can decide on the submitted\n data if it fits into my context. Author information is nice to have but not\n required.\n

I really don’t care who is submitting information—the information is what\nmatters.

\n To encourage contributions to data the process must be as easy as ordering\n something from amazon: straight forward and self explanatory. But the tools we\n have at the moment are fare from that. In my industry we call the content\n management systems. And the emphasis is on management and system. Those are\n beasts in terms of functionality and versatility which is achieved by throwing\n massive collections of buttons and input elements at the users without any\n explanation. For every CMS you need not only the vendors handbook, but an\n instruction on how to use the system for the specific site it was adapted for.\n

Admin areas must vanish!

\n Admin areas—the thing behind the username and password fields—are designed for\n users to edit content. If the content for every website can easily be classified\n into a few—text, lists, links, images—why must there be a custom way to edit\n these in every CMS?\n

It is these admin areas which function as a blocker for contributions.

\n If we could establish an easy to use and standardized way to orchestrate the\n editing, review and approval of content on the web we could focus on publishing\n content instead of setting up systems for its management.\n

Protocols are for machines

\n There is a\n protocol—AtomPup—which\n enables the collaboration on arbitrary data in a system neutral way. This is\n achieved by defining a set of actions—known as the CRUD operations—and\n strategies to handle conflicts. It is a robust and universally approach but it\n lacks an important aspect: it does not care about the data to be edited. For the\n scope of the protocol this is the right approach. There is no need to care about\n the data—AtomPub is just a messenger. The implementation of the content editing\n is left to the user and he is forced to acquire the suitable tools.\n

Adding constraints adds to our goal

\n Just add some constraints and we could push this further into a general way for\n editing arbitrary data where we can make assumptions about the data itself!\n

\n If we could describe the contents of web pages in just a few content types we\n would could provide a service which enables the edition of the data\n instantly—and like GitHub does—in the browser.\n

I think we can!

\n","slug":"just-edit-it","hero":"!undefined"}],["keep-code-left",{"title":"Keep code left","subtitle":"Best practice","abstract":"Make code more readable.","date":"2026-01-02T00:10:00+01:00","html":"\n

This long wrapping in a if / else clause makes the code hard to read.

Bad

if (condition) {\n  doWork();\n} else {\n  throw Error(\"Condition not met!\");\n}\n

Good

if (!condition) {\n  throw Error(\"Condition not met!\");\n}\ndoWork();\n

Stop nesting promises

Another example:

Bad

getData((a) => {\n  getMoreData(a, (b) => {\n    getMoreData(b, (c) => {\n      getMoreData(c, (d) => {\n        getMoreData(d, (e) => {\n          console.log(e);\n        });\n      });\n    });\n  });\n});\n

Better

getData()\n  .then((a) => getMoreData(a))\n  .then((b) => getMoreData(b))\n  .then((c) => getMoreData(c))\n  .then((d) => getMoreData(d))\n  .then((e) => console.log(e));\n

Even better

const a = await getData();\nconst b = await getMoreData(a);\nconst c = await getMoreData(b);\nconst d = await getMoreData(c);\nconst e = await getMoreData(d);\nconsole.log(e);\n

\n","slug":"keep-code-left","hero":"!undefined"}],["keep-prs-free-of-formatting-changes",{"title":"PRs should never contain formatting changes","subtitle":"Best practice","abstract":"It's important to have an automated way of formatting source code to eliminate discussions around style and remove noise from diffs.","date":"2025-12-28T12:38+01:00","html":"\n

\n It's important to have an automated way of formatting source code to eliminate\n discussions around style and remove noise from diffs.\n

All code style guides must be enforceable by tools

\n The best way to handle it is to fix all fixable errors using\n lint-staged and\n Prettier. That way developers won't even notice. Good\n IDEs are able to apply prettier style guides automatically even during editing.\n

\n","slug":"keep-prs-free-of-formatting-changes","hero":"!undefined"}],["lean-mindset",{"title":"Lean Mindset","abstract":"Lean Mindset by Mary and Tom Poppendieck is a concise handbook for building then next generation of software company; which must be product company.\n","date":"2017-04-13T12:00+02:00","html":"\n

\n Lean Mindset by Mary and Tom Poppendieck is only 160 pages long, but it\n packs a punch: companies that follow the agile way of building software driven\n by customer needs will eventually deliver a good result. But good does not mean\n exciting nor innovative. Just good does not set you apart from any other\n software company out there and makes you replaceable as a service provider.\n

\n In their book Mary and Tom take the reader on a quest that eventually leads to\n finding the answer for the most powerful question: how can organizations create\n breakthrough innovations in a predictable (or at least sustainable) way?\n

\n Chapter by chapter they lay out their understanding of the fundamentals that are\n needed to build software that truly serves the customer, and they don't all\n short on highlighting what's needed to achieve that: engaged employees with a\n deep understanding of the underlying business rules, a clear purpose and vision\n for the product they are building. Every section is supported by a real-world\n case study so you don't have to take their word for granted, but can see the\n respective theories in action in real life.\n

\n This book easily made it to the top of my reading recommendation for managers,\n founders, and developers as well. Keep a copy of the book handy, so you can\n check once in a while their questions to ponder provided after every chapter.\n

\n","slug":"lean-mindset","hero":"!undefined"}],["leap-second-stromverbrauch-bei-hetzner-steigt-um-ein-megawatt",{"title":"Leap second: Stromverbrauch bei Hetzner steigt um ein Megawatt","abstract":"So schreibt es Hetzner gerade in einer E-Mail an seine Kunden.\n","date":"2012-07-03T00:00:00.000Z","html":"\n

So schreibt es Hetzner gerade in einer E-Mail an seine Kunden.

\n
\n in der Nacht vom 30.06.2012 auf den 01.07.2012 registrierten unsere internen\n Überwachungssysteme einen Anstieg des IT-Stromverbrauchs um etwa ein\nMegawatt.\n
\n
\n Grund für den enormen Anstieg ist die zusätzliche geschaltene\n Extrasekunde, die auf Linux-Rechnern zu dauerhafter CPU-Auslastung führen\n kann.\n
\n
Laut heise.de sind diverse Linux-Distributionen davon betroffen.
\n
\n Um die CPU-Auslastung wieder auf ein normales Maß zu reduzieren ist in\nvielen Fällen ein Neustart des gesamten Systems notwendig. Im ersten Schritt\n sollten Sie dazu einen Soft-Reboot über die Kommandozeile versuchen. Sofern\n diese Maßnahme nicht greift, steht Ihnen noch die Möglichkeit eines\n Hardware-Resets über die Administrationsoberfläche Robot zur Verfügung. Wählen\n Sie dazu in der Administrationsoberfläche den Menüpunkt 'Server' sowie den\n Reiter 'Reset' des jeweiligen Servers.\n
\n

\n Auf meinem Server war die Java VM betroffen, in der eine Jenkins-Instanz lief.\n Selbst nach dem Töten aller Java-Prozesse und anschließendem Start von Jenkins\n verbrauchte dieser weiterhin 80-90% der CPU-Zeit. Erst ein Neustart des Servers\n brachte alles wieder in Normalzustand.\n

\n","slug":"leap-second-stromverbrauch-bei-hetzner-steigt-um-ein-megawatt","hero":"!undefined"}],["learn-about-asynchronous-communication-why-phone-is-bad-and-chat-is-good",{"title":"Learn about asynchronous communication: why phone is bad and chat is good","abstract":"This post tries to explain the rationale behind one of my recent tweets: Phone is bad, Chat is good.","date":"2015-06-28T11:30:00.000Z","html":"\n

\n This post tries to explain the rationale behind one of\n my recent tweets:\n

\n
\n Everyone will work better if all understand the difference between sync and\n async communication: Phone is bad, Chat is good. >\n #futureofwork\n
\n

\n You can maximize your work output if you can use your work time in a way the\n suits your habits best. The more your work requires your undivided attention,\n which is true especially for creative and innovative work, the more your mind\n will submerge into something called flow, a state of mind that shuts out all\n exterior disturbances and focuses on the one task at hand. I call this the core\n working time, that part of the day which is dedicated to the work that you are\n best doing at.\n

flow needs an environment of self-determination and independence to happen

\n There are two important things to consider:
Flow can't be switched on just like that, you need the environment and the\n personal condition to activate it. It's a very individual condition that is\n entirely up to you and can't be determined by putting you in a cubicle from 9 to\n 5 with motivational posters around. You are in charge of picking the time of a\n day and the location that provide the best conditions for you to be able to do\n your best work possible.
It takes time for your brain to enter a higher state of concentration that\n enables you to see all the factors of a problem and understand patterns that\n emerge-only then will you be able to find a good solution to a given problem.\n It's a matter of hours and not minutes until you can focus all your senses on a\n problem.\n

\n If you work at an organization where innovation and creativity is key to your\n organization's success you want everyone to reach their flow at least once a\n day. But as I pointed out before, it can't be planned nor can it be mandated.\n flow needs an environment of self-determination and independence to happen.\n

Phone calls are poison in these environment

\n Every time you pick up your phone to call a colleague you have a very high\n probability of disturbing their flow and yanking them out of their core working\n time. Why is that? You will force their mind to step out of its current\n engagement and refocus on the question you need to have answered. Is your\n problem that important? I'd argued that it is not for most of the time. The same\n is true for walking up to someone's desk without invitation.\n

\n I'm an advocate of asynchronous communication, like chat, because it puts\n establishes a buffer in the communication that enables every participant to\n communication in their own time. They can decide when to read chat messages\n because they can turn of notification and find the time that fits them to answer\n questions there.\n

\n There is nothing wrong with using phone-calls or video-chats for planned\nmeetings. It's essential for the wellbeing of an organization to hear your\n colleagues voices and synchronous communication should be your choice for all\n your recurring meetings like the daily, jour fixes or other sync-up style\n meetings.\n

\n So it's not the technology that is bad but the implications they bear: phone\n calls are expected to be answered immediately, that puts some pressure on the\n receiver. They are not bad per-se because the bandwidth depending on the topic\n can be higher compared to chat or email.\n

Make an escalation plan for communication

\n Phone calls might be an easy to use tool for the individual but bear a very\n unbalanced cost for the team. It shouldn't be your first choice of communication\n with your team.\n

\n Communication in a team needs to be well defined and agreed on organization\n wide. I propose that chat should be the default way of communication internally.\n You can replace email with a chat system that allows for private, topic based,\n and general messaging. Your project management tool is the place to assign work\n items. Email should be an interface only to clients and external contacts.\n

\n That leaves phone-calls for emergency situations. And you should handle them\n like this. If you pick up the phone to call someone it should be an emergency.\n You also should know which kind of problem qualifies for an emergency and which\n are better added to the bug tracker.\n

\n If you are on the receiving end of a phone-call and it's not an emergency you\n should know about the effect of immediately taking care of the issue. If you are\n in a state of focus just ask the caller to let you call them back so you can\n finish your current thought or bring your current work item to a state that\n enables you to easily pick it up later. Give them a time frame and essentially\n schedule a call with them.\n

Synchronous communication is expensive

\n … is the gist of this post. Separating myself voluntarily from my team by\n working out of a coworking space at least\n 3 days a week and reducing unplanned phone calls to a minimum is important for\n my personal happiness at work. I even try to cluster meetings around two days a\n week so I have the other three days for work that feels more productive to\n me-like coding.\n

\n I hope you have enough reasons to make your organization default to asynchronous\n communication if you have the power to do so.\n

\n","slug":"learn-about-asynchronous-communication-why-phone-is-bad-and-chat-is-good","hero":"!undefined"}],["leaving-distributeaid",{"title":"I've left DistributeAid","subtitle":"Volunteering","abstract":"After three years volunteering for DistributeAid I felt it no longer was a good way to spend my time","date":"2023-01-01T17:00+01:00","html":"\n

\n After three years contributing code and organizational wisdom to\n DistributeAid I am saying good bye to this\n amazing project. I had the opportunity to work with amazingly skilled and\n passionate people on making aid available who have to flee their countries and\n are held in cages at the European borders.\n

\n My reason to leave is that I am not able to work on projects that I find\n interesting, but this is not DistributeAid's fault. There are meaningful things\n to work on, however I owe it to myself to make good use of my time.\n

\n I've kicked of some important changes within the organization and maybe a few\n years from now there is a new opportunity to return.\n

\n","slug":"leaving-distributeaid","hero":"!undefined"}],["leaving-dothiv",{"title":"Leaving dotHIV and looking for a new team","abstract":"From April 1st 2015 I'm available to join a new team where I can craft software, my leadership skills to the organization and my wit to the daily stand-up.","date":"2015-03-03T17:00:00.000Z","html":"\n

\n Over 1,500 working hours will have been logged to my time-tracking tool when I\n push the last commit to our repository end of\n March 2015. Those 1,500 hours were in part the most fulfilling time I spent\n working I ever–or are you able to claim to be writing code for something that\n literally will save people's lives? So it comes with a little sadness that we\n won't be able to work on dotHIV how we used to …\n

\n This means: from April 1st 2015 I'm available to join a new team where I can\n craft software, my leadership skills to the organization and my wit to the daily\n stand-up.\n

\n I used to work as a freelancer, but having been part of an amazing team provides\n something that is missing if you are a keyboard for hire: relationships and\n colleagues–which is equally important to me as being able to work remotely from\n a coworking space.\n

\n I'm looking to join a team as a lead-developer or CTO because I know that I can\n contribute more than S.O.L.I.D. code and software that is deployable\n everyday–even on fridays. I believe that there are better ways to work than\n building waterfall projects in open plan offices and I can help you transform\n not only the way you build software but how you talk to your clients.\n

\n I did join dotHIV last year because I wanted to build a project that has a\n purpose and serves a real need–not some made up first-world problem. This is\n still true and this is what I will ask you when we talk: Why does working at\nyour company matter?\n

\n And while we are at it … these are some of the questions we'll talk about. They\n should give you feeling about what I am looking for in an employer:\n

Do you have defined your core values and mission statement?
Do you default to transparency?
Are the employees responsible for business critical decisions?
Do you do regular team events (OpenSpaces, Hackathons, Code Retreats)?
\n Do your employees have personal development goals and do you review them on a\n regular basis?\n
Do you have a mentorship / sponsor program?
Do you do estimates for waterfall projects?
Can I choose my own hardware?
Do you have unlimited vacation days?
How large is the conference budget for employees?
Do you default to remote work?
Do you support contributions to open source software?
Can you deploy on a daily basis?

\n Learn more about me at these sites and if you think I could be a match for your\n team, talk to me.\n

\n","slug":"leaving-dothiv","hero":"!undefined"}],["leaving-twitter",{"title":"I am leaving Twitter for Mastodon","subtitle":"#LeavingTwitter","abstract":"Elon Musk is now in full control of a powerful network, that I am part of; but that is not the biggest issue.","date":"2022-10-28T23:00+02:00","html":"\n

\n Elon Musk is now in full control of a powerful network, that I am part of and in\n the past he has made it clear that he wants to turn it into a un-moderated,\n free-for-to-strongest opinion machine that supports his narrow world views. I\n have no confidence in him and the leadership he is going to install to change\n #Twitter for the better, to improve the efforts to reduce hate speech against\n minorities and to work against troll armies being able to use the platform's\n reach for their sinister purposes.\n

\n Musk taking over\n is going to be a mess,\n and yes, I could wait it out, until he gets bored and leaves the platform's\n smoldering ruins, but I also need to address the bigger issue here. A single,\n privately run business is in control over my main communication channel with\n friends, industry peers, customers of my employer, etc. It tries to monetize\n every interaction on the platform and by doing so incentivizes content and\n interactions I do not care about and are actually harmful to what I want to do:\n have honest connections and conversations.\n

That's why I am leaving Twitter and will stop posting content there.

\n You can follow me on Mastodon (a\n distributed social network),\n where I joined the chaos.social instance: I\n am @coderbyheart@chaos.social there.\n

\n I have published my Twitter archive on https://twitter.coderbyheart.com/, so\n it's not lost and can be accessed anonymously.\n

\n Leaving Twitter will suck, I am noticing it already while going through my\n private Twitter list I call \"tribe\" which has 225 members and which I use as\n timeline in TweetDeck; very few in there are on a Mastodon instance. I don't\n depend on Twitter for my income, so the impact for me should be quite\n manageable. It hurts to know that I am leaving some amazing connections behind\n because I do not plan to keep using Twitter in reading mode. So many of these\n daily inspirations will be lost for me.\n

\n It will not be easy for a while but in my experience we can always get used to a\n new way to connect to people. And it might even open up entirely new\n connections.\n

\n","slug":"leaving-twitter","hero":"!undefined"}],["local-schedule-create-a-shareable-schedule-with-times-in-your-local-timezone",{"title":"Local Schedule: Create a shareable schedule with times in your local timezone","subtitle":"Project","abstract":"Great for remote conferences!","date":"2020-05-10T15:00+02:00","html":"\n

\n Local Schedule is a small tool I\n published this week which helps with running and attending virtual and #remote\n conferences: You can create a shareable schedule with times in your local\n timezone. It also shows the time to the next session and a colored warning if\n it's less than 5 minutes.\n

\n The tool is open-source,\n free and requires no registration.\n

\n","slug":"local-schedule-create-a-shareable-schedule-with-times-in-your-local-timezone","hero":"!undefined"}],["logrotate-config-fur-vhosts-automatisch-erstellen",{"title":"Logrotate-Config für VHosts automatisch erstellen","abstract":"Mit diesem Script erzeuge ich für alle Virtuellen-Hosts eines Apache2-Webservers eine Konfiguration für Logrotate.\n","date":"2011-12-11T00:00:00.000Z","html":"\n

\n Mit diesem Script erzeuge ich für alle Virtuellen-Hosts eines Apache2-Webservers\n eine Konfiguration für Logrotate.\n

\n Hierzu lese ich die VHost-Konfigurationen in /data/sites ein und parse daraus\n die Pfade zu den Logfiles.\n

\n Anschließend erzeuge ich mit Hilfe eines Templates die eigentliche\n Konfigurations-Datei im logrotate.d-Ordner.\n

logrotate-config.sh

#!/bin/bash\nCONFDIR=/data/sites/\nTEMPLATE=/data/sites/logrotate.conf.template\nOUTFILE=/etc/logrotate.d/`hostname`-apache\necho \"# DO NOT EDIT!\" > $OUTFILE\necho \"# automatically generated by $0 on `date`\" >> $OUTFILE\necho \"\" >> $OUTFILE\nfor i in `cat $CONFDIR/*.conf | grep -i -E \"(Transfer|Error|Custom)Log\" | awk '{ print $2; }' | sort | uniq`\ndo\n        echo -n \"$i \" >> $OUTFILE\ndone;\necho $OUTFILE\ncat $TEMPLATE >> $OUTFILE\ncat $OUTFILE\n

/data/sites/logrotate.conf.template

{\n  missingok\n  notifempty\n  sharedscripts\n  postrotate\n  /etc/init.d/apache2 reload > /dev/null 2>&#038;1 || true\n  endscript\n  rotate 9999999\n}\n

\n","slug":"logrotate-config-fur-vhosts-automatisch-erstellen","hero":"!undefined"}],["macbook-funktionstasten-unter-linux",{"title":"MacBook Funktionstasten unter Linux","abstract":"Diese sind, zumindest unter Arch Linux, standardmäßig nur mittels FN+F zum auslösen zu bewegen.","date":"2011-04-13T00:00:00.000Z","lang":"de","html":"\n

\n Diese sind, zumindest unter Arch Linux, standardmäßig nur mittels\n FN+F<1..12> zum auslösen zu bewegen.\n

Dieser Eintrag in der /etc/modprobe.d/modprobe.conf behebt das Problem:

options hid_apple fnmode=2

\n","slug":"macbook-funktionstasten-unter-linux","hero":"!undefined"}],["master-is-the-wrong-name-for-your-branch",{"title":"master is the wrong name for the main branch","subtitle":"Best practice","abstract":"I prefer saga branch over master because I think that this name (which means a long continuous recollection of histories) better reflects how development happens.","date":"2025-12-28T12:38+01:00","html":"\n

\n I prefer saga branch over master because I think that this name (which means\n a long continuous recollection of histories) better reflects how development\n happens. A master conveys this idea of control over something, while it's\n actually the branches where development happens and which control what ends up\n in the main branch. A good name would also be main, or trunk.\n

How to change the default git branch

\n Note:\n The master terminology in Git is historically tied to the master/slave metaphor and not the master copy one,\n see\n https://github.com/github/renaming\n

\n","slug":"master-is-the-wrong-name-for-your-branch","hero":"!undefined"}],["meine-subversionconfig",{"title":"Meine .subversion/config","date":"2010-10-14T00:00:00.000Z","lang":"de","html":"\n

[helpers]\ndiff-cmd = colordiff\ndiff-args = --ignore-all-space --ignore-blank-lines\n[miscellany]\nenable-auto-props = yes\n[auto-props]\n* = svn:keywords=Id Rev\n[auth]\n# Verhindert die Verwendung von Keychain / Keyring\npassword-stores =\n

\n","slug":"meine-subversionconfig","hero":"!undefined"}],["mergify",{"subtitle":"Tools","title":"Interview with Mergify","abstract":"I was interviewed by Mergify about my use of their service.","date":"2022-05-04T19:00:00.000Z","html":"\n

I was interviewed by Mergify about my use of their service.

\n
\n Opinions expressed are solely my own and do not express the views or opinions\n of my employer.\n
\n

Please could you explain a bit more about what Nordic Semiconductor does?

\n Of course! As our name says, we are a semiconductor company, and a fabless one,\n which means we earn our money by designing chips and selling them. To give you\n an idea of the scale of our operation, we have sold about a billion Bluetooth\n chips, selling around 1 million every day right now, and we are the world market\n leader for Bluetooth connectivity. Products using our chips range from wireless\n keyboards and mouses to tracking devices that you can put on your key chains. In\n 2018, we launched our long-range chip, which is a chip that connects directly to\n cell phone networks using a new standard for IoT connectivity called\n LTE-M or\n NB-IOT. We designed those chips\n to use very little power to build a battery-operating device so small that you\n can put it on a cat’s collar or a fitness tracker without needing to use a cell\n phone as the gateway.\n

\n We currently have 1,200 employees worldwide, mostly in the northern hemisphere\n and in Europe, but we are also in Singapore, China, and the US. Because things\n that need tracking and real-time data are everywhere!\n

What projects are you working on at Nordic Semiconductor?

\n I’ve been working as a software engineer with a group responsible for figuring\n out how the chips connect to the Internet and to cloud providers and teaching\n our customers how chips work. Many of our customers are great at designing\n hardware and physical products, but they often have very little experience in\n cloud technologies. So we provide them with a comprehensive SDK [software\n development kit] that shows not only how to build applications on the device\n itself but explains how the device connects to AWS IoT and other IoT offerings,\n how the data gets in there, and how the data gets out of there so that they can\n focus on the product design.\n

\n And that’s what your\n open-source projects on GitHub\nare all about, right?\n

\n Yes, exactly. One closed-source software component is the driver for our modem\n and contains our secret knowledge about how to deal with all these connectivity\n protocols on the transport layer and how to implement encryption using the CPU.\n But everything above that is open-sourced! Our SDK is an embedded one based on\n Zephyr, a\n real-time open-source operating system [OS] part of the\n Linux Foundation. Nordic Semiconductor provides\n direct upstream features to Zephyr, but we maintain some of our application\n samples and the stuff we do specifically for our hardware in a fork, as those\n things are often not relevant to the entire ecosystem. We also open-sourced\n samples for mobile apps to explain how to implement Bluetooth and use the\n Bluetooth stack on your phone in the right way. In addition, we have a big\n open-source desktop application\n built using Electron.\n

What’s your typical GitHub workflow on those projects?

\n It depends on the projects, so let’s talk about my preferred workflow, which is\n based on trunk-based development.\n Basically, the idea is that you don’t use feature branches—you put everything in\n the main branch because otherwise, you would quickly end up with the problem\n that you have too many parallel variances of your software. And when you start\n merging a feature branch into your main branch, it will encounter merge\n conflicts, and solving those conflicts calls for a lot of painful collaboration.\n So ideally, I commit everything in small iterations to the main branch with very\n short-lived feature branches—short-lived, meaning a few hours or a day.\n

\n However, we have some projects where I need reviewers. For example, there is\n this documentation repository where tech writers are involved. In this case,\n there are two workflows. If it is a purely technical change, like changing a\n comment line argument in a document that was missing for the users, there is no\n need for a tech writer to review it. But if I update or extend a document, there\n will be a pull request [PR], and we have a rule that says at least three tech\n writers need to approve it.\n

Which projects do you use Mergify with?

\n I use Mergify on a TypeScript project that I\n started in 2019, intending to provide our customers with an open-source\n reference implementation of end-to-end examples for an IoT product. That starts\n with the firmware, but a lot of the code is the cloud component, showing our\n customers that they need to get location data from the device to the cloud if\n they want to build a cat tracker. For example, that they will need to visualize\n it on a web application, what technologies should be used there, what AWS\n services should be used there, or which database should be used there. I’ve made\n this example open source, and I’ve done the same thing for Azure.\n

How did you first hear about Mergify?

\n Probably through Twitter. I have been doing dependency automation for quite a\n long time. And previously, I was using Greenkeeper,\n but it was discontinued two years ago, so I had to find an alternative.\n

How is Mergify helping you on this particular project?

\n It saves me a lot of time with dependency updates, which means I can focus more\n on the features. Dependencies change so often in the JavaScript ecosystem! So I\n asked myself whether we should be pinning the dependencies and release every\n half-year or quarter, or whether it was better to go with the flow.\n

\n I believe that projects are more manageable if you continuously maintain and\n follow a path of stable release with your dependencies. And that’s where Mergify\n has become extremely valuable to us!\n

So you use Mergify to update your dependencies?

\n Yes. So the main task Mergify does is if there is a dependency update created by\n Renovate bot or the\n GitHub security bot,\n and all the tests pass on GitHub actions, it merges the PR. On my project,\n Mergify has merged hundreds and hundreds of PRs.\n And with every PR taking a median of 2 minutes to be merged and more than a\n hundred dependency update PRs happening every week, it saves me about 5 hours a\n month! It also preserves the continuity of my coding sessions and removes some\n irritating aspects of the work that would drive me mad. The only thing I have to\n take care of is to make sure I have a well-tested codebase. This is a\n precondition if you’re going to use Mergify—like, you need to make sure that you\n have covered your dependencies in tests. Otherwise, you won’t know if they are\n working.\n

Do you differentiate between minor and major dependency updates?

\n Absolutely. Major updates aren’t merged automatically. However, as they also\n typically break the tests, I’m not bothered by that. But what often happens in\n JavaScript is package maintainers bump up the minimum-required\n Node.js version and declare it a breaking change, even\n if there is no implementation change. So from a user perspective, that is a\n change that wouldn’t break my system, but if I had been running tests without\n the necessary Node.js version, they would have failed. So arguably, you could\n even have merges for major version changes enabled automatically because, again,\n if you have good test coverage, what can go wrong?\n

What would be your N°1 tip for someone new to Mergify?

\n The last time I checked Mergify documentation was maybe a year ago or earlier,\n and I found it difficult to understand the possible combinations between the\n available properties. It documents the properties pretty well, but it lacks\n explanations for how to use Mergify on different types of projects. But I would\n like to say that it’s worth investing some time in understanding how Mergify\n works!\n

\n This interview was originally published\n on the Mergify blog.\n

\n","slug":"mergify","hero":"!undefined"}],["meta-is-killing-source-code-writing",{"title":"Meta is killing source code writing, if you like it or not","subtitle":"Facebook changed the way we build frontends, Meta changes the way we build software","abstract":"Meta is investing billions into an LLM that writes software the Facebook way, and it has reassigned thousands of engineers to produce the training data for it. This paves the way to change how all of us build software, whether we like it or not.","date":"2026-07-12T23:00:00+02:00","html":"\n

\n We are at an inflection point that will have a huge impact on how we write\n software: Meta is investing billions of dollars into building an LLM that is\n capable of writing software. They are doing this to write software at\nFacebook—but as with React, what happens at Facebook does not stay at Facebook.\n

Engineers as training data

\n In March 2026, Meta involuntarily transferred roughly 6,500 engineers and\n product managers into a new unit called Applied AI (internally: Agent Data\n Optimization) whose job is to manufacture training data for Meta's models: hard\n coding problems, the tests that check them, and grades on AI-written code.\n According to\n The Pragmatic Engineer,\n 30–50% of engineers on core product teams were reassigned—people who were\n building Instagram, ads, and infrastructure the week before.\n

\n Meta considers hand-written, novel coding problems from senior engineers so\n valuable that it pulled thousands of them off product work to produce them. In\n leaked audio,\n Zuckerberg reportedly argued\n that Meta's own engineers are simply smarter than outside contractors—his case\n for conscription over hiring.\n

\n These engineers are expected to deliver two such tasks per week—with a\n median software engineer compensation of $444,000\n these are some of the most expensive—and arguably best—engineers in the\n industry.\n

Aggressive pricing, by design

\n The second piece landed this week. On July 9, Meta released\n Muse Spark 1.1,\n an agentic coding model, together with its first serious paid developer API:\n

\n
\n Since this is not an open source model, this is I think the first time that\n we're doing a real serious API. And the pricing is going to be very aggressive\n and attractive. —\n Mark Zuckerberg, Bloomberg interview, 2026-07-09\n
\n

\n Developers can use the model for free up to a token threshold, and the API is\n priced at roughly 25% of what OpenAI and Anthropic charge for their top models.\n This is a deliberate land grab—and, I believe, an admission that there is no\n money in selling access to LLMs in the long run. The race to the bottom of\n frontier model pricing has already started—Meta's own launch at 25% of\n competitor pricing is that race, and cheap models from other labs are pushing\n in the same direction. Zuckerberg himself calls the margins of the other labs\n \"very extreme\"; his stated strategy is to get the technology in front of as many\n people as possible. That is not the strategy of someone who plans to live off\n token revenue. Meta's actual business is advertising, and its actual interest in\n this model is writing Meta's own software cheaper and faster.\n

\n The paid API is just temporary—training models and running inference is\n expensive today, but we have seen that for example Chinese companies are able to\n produce coding models that can compete with the latest Western models, having\n only much more limited access to skills and hardware—training and inference\n costs will eventually be low enough that Meta can afford to open source their\n frontier coding model.\n

\n And running them will be feasible for anyone, not just a few frontier AI\n companies with access to thousands of Nvidia GPUs.\n

\n Zuckerberg can afford to play this game for as long as he wants. He is the\n shareholder with super-voting rights, which means he decides—by himself—where\n Meta invests its money. He is on this track now, and he believes the future of\n Meta is, in part, to reduce the amount of software written by humans at Meta.\n Meta's internal targets say as much: the Creation organization\n aims for 65% of engineers to produce more than 75% of their committed code with AI\n in the first half of 2026.\n

\n Which puts the model in exactly the same position React was in: a tool built to\n solve Facebook's problem, where giving it away costs Meta little and buys them\n an ecosystem, mindshare, and a labor market pre-trained on their way of working.\n

We have seen this movie: React

\n If you think \"this is a Facebook-internal problem\", let me remind you of\n React.\n

\n React was\n open-sourced at JSConf US in May 2013\n as a better way to build front-end applications. It solved a problem for\nFacebook—and there are arguably very few companies in the world that have\n Facebook-level problems with their frontend applications. Yet today React is the\n predominant technology for building web applications; it has topped the\n Stack Overflow developer survey\n as the most-used web framework for years, in recent years by large margins.\n

\n To be fair: Meta has an enormous engineering organization. Of its roughly\n 78,000 employees at the end of 2025,\n about a third work in engineering—in the order of 25,000 engineers. React is\n technically a great achievement. It is an innovation. It solves real problems.\n

\n But there were, and are, many good alternatives. React won in large part because\n enough tech leaders were drinking the Facebook Kool-Aid: what Facebook does\nmust be good, therefore it is good enough for us. Add the job-market\n flywheel—everybody who wants to work at a FAANG company learns React, so\n everybody hires for React—and you get the de facto standard we all live with\n today. An ecosystem that exists purely because Facebook willed it into\n existence.\n

Facebook changed the way we build frontends, Meta changes the way we build software

Now run the same playbook with an LLM instead of a UI library.

\n Meta makes the model cheap—25% of the competition—free to start with, and\n eventually, I believe, open source. That is the React move: outsource the cost\n of onboarding. Engineers learn the tool before they apply at Meta, and arrive\n with the skill Meta needs already available. Meanwhile Facebook is still the\n biggest website on the planet, and what Meta does technically is still seen by\n many as the epitome of scalable web application development.\n

\n So when Meta at some point says: we no longer employ people who write source\ncode by hand—we employ software engineers, but they direct, review, and grade\ncode instead of writing it (and remember, at Facebook that code is written in\n Hack, their own PHP dialect\n introduced in 2014,\n which tells you how comfortable they are with defining their own way of doing\n things)—then a significant number of companies around the world will copy that\n model. Not because it is the best way to build software. React was not the\n best way either. It will be a controversial way, and better alternatives will\n continue to exist, including simply writing source code by hand.\n

\n But the Facebook way of developing software without writing source code will be\n impossible to ignore for us as software crafters.\n

\n Given the trajectory Meta is on—the billions in investment, 6,500 engineers\n producing training data, a coding model priced to undercut everyone and,\n eventually, given away—this will lead to a significant shift in how we build\n software.\n

\n React did not become the standard because it was the best option. It became the\n standard because Facebook made it free, made it huge, and made it a hiring\n requirement. The same machine is now being pointed at source code writing\n itself.\n

If you like it or not.

\n","slug":"meta-is-killing-source-code-writing","hero":"!undefined"}],["method-calls-favour-argument-bags-over-individual-arguments",{"title":"Method calls: favour argument bags over individual arguments","subtitle":"Best practice","abstract":"Bad: myMethod(arg1, arg2, arg3); Good: myMethod({ arg1, arg2, arg3 });","date":"2025-12-28T12:38+01:00","html":"\n

Bad

myMethod(arg1, arg2, arg3);\n

Good

myMethod({ arg1, arg2, arg3 });\n

Reasons

\n this removes the\n Connascence of Position (CoP)\n because the order of arguments becomes irrelevant\n
arguments to methods can easier be created programmatically

Watch out for

removing support for currying

\n","slug":"method-calls-favour-argument-bags-over-individual-arguments","hero":"!undefined"}],["motivation",{"title":"On Motivation of Software Engineers","abstract":"Tobias Zander has written a blog post about Motivation of software engineers. These are my motivations.\n","date":"2016-01-19T11:00:00.000Z","html":"\n

\n $\"Happiness\"$ \n

Tobias Zander has written a blog post about\nMotivation of software engineers.\nThis is what motivates me:

Freedom

\n Being once again in the situation of looking for my next job this question is a\n very important one to answer. I can earn money by taking on a lot of roles—the\n possibilities are endless. For me it is therefore important to know or at\n least believe to know what my day to day work should look like. In the past,\n I've already written about\n what I am looking for in an employer and gave advice on\n How to find a CTO; both posts emphasize on the\n circumstances that create great working environments. And for me a great\n working environment is a great motivator. If you read them, you'll see that I\n strive to work in an environment where I am trusted and have the tools I need.\n But personal freedom in deciding where and when I work is the most important\n factor of motivation for me.\n

\n Because of this it is great to work as a Software Engineer—or as I would see\n myself as a Software and Organization Engineer. When technology is all around\n you it enables you to work on a project anytime and everywhere but still having\n ways to bridge long distances in an instant. It is an enormous win to have\n people from different socialisations in your team. And we can because … the\ninternet.\n

Purpose

\n Having worked as a freelancer this didn't matter then. The short-term motivator\n is getting paid good money for learning a new domain and software stack and\n apply my problem-solving, pattern-matching and software-building skills. But the\n new-toy-feeling wears off in just a few months. Therefore the second great\n motivator for me is that the time I spend in front of a keyboard is helping to\n create something that is useful. And useful in a way that is honest and does\n not harm the planet. Yes, I have the liberty to ask this question and having\n spent years building consumer marketing solutions I know how huge the market is\n which creates demand for the consumption of stupid products by selling fake\n innovations.\n

Challenge

\n Software is about Mind and Machines and the feeling to build something by\n combining smart minds and interesting technology is a never ending source of\n joy—and pain, too. Working in a field where every decision you make is just a\n good guess and you have to constantly adapt forces you to work on your skills\n and learn something new everyday. And everyday you have the chance to improve\n the system you are working on bit by bit. This cycle provides a constant stream\n of frustration and triumph—and that is what makes it great. There are only a few\n professions where you can see the result of your own work on a daily basis\n without being repetitive.\n

\n","slug":"motivation","hero":"!undefined"}],["moving-to-trondheim-hire-expat-mid-norway",{"title":"Moving to Trondheim? Hire expat Mid-Norway!","subtitle":"Relocation to Norway","abstract":"About my experience relocating to Trondheim, Norway.","date":"2018-08-19T14:00+02:00","html":"\n

\n It has been a year since I started to work for\n Nordic Semiconductor in Trondheim, and\n expat Mid-Norway has been part of my journey\n here right from the beginning. When Nordic Semiconductor flew me to Trondheim\n for the in-person interview, I met with Ellen for the first time. I remember\n vividly how she answered all the questions I had regarding immigrating to Norway\n and gave me the confidence that there would be someone which would take care of\n all the important and annoying tasks. This was an important factor why I finally\n decided to take the job offer. And it turned out to be absolutely true. Ellen\n and her team were meticulously planning the immigration, the move, helped with\n finding a very nice flat according to our wishes and made sure that moving to\n Norway was a smooth experience so that we could settle as fast as possible. At\n no time did I encounter surprises. It was the first immigration for us and I\n would do it again with Ellen and her team—even if I had to pay for it on my own,\n the money is very well spent. Because now in her 10th year, Ellen knows that\n logistics are just one part of what is needed to make a move to a foreign\n country a success.\n

\n What I especially enjoy is the continued support expat Mid-Norway offers after\n the move: information meetings on healthcare, taxes and pension on the one hand\n and the Norwegian language course and conversation group offer very valuable\n support to integrate better into the Norwegian society. There are also more\n information occasions every week, like hiking trips, board game nights, fishing\n excursions, knitting, which provide a great opportunity to get to know many of\n the other expats in Trondheim - you are part of a network from day one, which is\n very important since you are leaving your old network behind. With this support\n you are not feeling “alone” in Trondheim and you can also more easily get to\n know people outside of your workplace.\n

\n I am now also on the other side of this experience: since I am hiring for Nordic\n Semiconductor it gives me great confidence to have expat Mid-Norway as part of\n our offering. I know that we are not only offering a job in a world class team\n of engineers, but our support for relocating new employees and their families to\n Trondheim has the same standard: world class and with the fanatical commitment\n to make a relocation a lasting success.\n

\n","slug":"moving-to-trondheim-hire-expat-mid-norway","hero":"!undefined"}],["mvps-in-production",{"title":"MVPs in Production","subtitle":"Reflections on being a CTO for 5 years","abstract":"In this post series I'll reflect on the technical principles that I've employed in the last 5 years working as a CTO to achieve something that would have been seen as futile and insane a decade ago, but is the norm today: running software in production that is neither complete nor well-designed and needs to evolve every day.","date":"2017-06-10T13:45+02:00","html":"\n

\n From 2013 to 2017 I've worked as a CTO in four startups:\n DeinBus, dotHIV,\n Fintura, and\n Resourceful Humans. In all I was not a\n technical co-founder but joined the team at a time when the existing technology\n showed cracks that put the business at risk. The notorious shortage of tech\n talent made these startups turn to freelancers, agencies to build their first\n public beta or despite lacking a professional technical background the founders\n started to build the solution on their own. Which is actually the smartest thing\n you can do, because in the pre-seed phase of a startup cash is usually a very\n scarce resources and freelancers and agencies are charging rates which are not\n affordable on a sustainable rate, but will lead to cutting (cost) corners that\n create technical debt that is not transparent to the startup, which leads to\n even more risks.\n

\n Once I joined these teams my job in all cases was to stabilize the technology\n and make it more robust and reliable, and increase the headcount of the tech\n team to improve velocity, which is the speed at which you can release new\n features to your (sometimes paying) users. In a start-up environment, where\n there are only known and unknown unknowns achiving these goals is especially\n challenging. In this blog series I'll explain the principles that I've employed\n which enable notoriously understaffed tech teams to tackle these challenges at a\n sustainable pace.\n

\n This is a recollection of how I made it work, and of course, so many things\n could have been done better, if the circumstances had been different. The\n opinions expressed in these posts are solely my personal views and not those of\n my former employers.\n

\n I'll try to put this into an easy to read guide for future CTOs,\n follow me on Twitter to know first, when\n I'll finish a new section.\n

\n Before you start reading here is some context: all these startups were product\n startups building web-based (an mobile) applications, which were development\n in-house as well as using service providers and freelancers. We hosted them on\n bare-metal, virtual serves or on AWS. The team size was never more then 15\n people, always in a distributed setting, where working remotely was the norm.\n

The first post is already finished:

Setting up a product management process

Coming up next:

\n Building an architecture that supports feature creep, Building features in\n verticals\n

I'll also want cover these topics in later installements of this series:

Going serverless
Push to deploy and Code Stewardship
Running experiments in production, without staging
The case for JavaScript
Test-driven development
Designing RESTful APIs that evolve easily
Using Bots and open-source to fight Conway's law

\n But here is the catch: I want 10 additional readers to sign up for my\n influencer group for this series before I start the third section, and you'll\n get to pick which one I'll continue with!\n

Fill out this form if you are interested to read more!

\n","slug":"mvps-in-production","hero":"!undefined"}],["ndc-oslo-2018",{"title":"NDC { Oslo } 2018","subtitle":"Visting one of the biggest tech events in Scandinavia","abstract":"This week I flew to one of the biggest developer conference in Scandinavia: NDC { Oslo }.","date":"2018-06-15T19:00+02:00","html":"\n

\n This week I flew to one of the biggest developer conference in Scandinavia:\n NDC { Oslo } lasts a full week and is convieniently\n location next to Oslo Central Station in a huge arena which is divided into 9\n session rooms during the conference.\n

\n The ticket prices are hefty, but I was accepted as a speaker with my talk about\n Prototyping for the Internet of Things using JavaScript which not only granted\n me a free conference pass, but also my travel costs from Trondheim where covered\n as well as the stay in the official conference hotel, the Radisson Blu which is\n next to the venue.\n

\n Since speakers where not required to self-fund their travel costs (hint:\n #paytospeak) there was a very international line-up and a noticable amount of\n women speakers (out of 183 speakers, 30 were women) which resultet in a quite\n diverse panel, at least for a scandinavian location.\n

\n During the conference there was access to food and drinks all-day, and free\n flowing beer during the evening. The variety and quality of the food was\n amazing, even given the quite expensive admission fees.\n

\n Although NDC is leaning heavily towards the Microsoft eco-system, the variety of\n talks was impressive. With 9 parallel tracks on three days, one needed to select\n between more than a hundred talks, many of them held by well-known keynote\n speakers. I found a good mixture of inspiring talks and this that went into more\n detail. The 60-minute format provided enough room for explaining a topic in\n depth without needing to sacrifice on important background information.\n

\n I was also impressed by the exhibition in the main hall. Many, mostly local\n companies where happy to chat and offer give-aways and raffles for the attendees\n in search for the next hire. You could easily get in touch with many interesting\n companies from all over Norway and learn about why it is so exciting to work for\n them. Many brought their most exciting projects with them, or at least the ones\n they were allowed to talk about.\n

\n You can find my pictures of the event\n on flickr.\n

\n","slug":"ndc-oslo-2018","hero":"!undefined"}],["niedrigen-speicherplatz-mit-bash-uberprufen-und-per-mail-warnen",{"title":"Niedrigen Speicherplatz mit Bash überprüfen und per Mail warnen","abstract":"Dieses kleine Bash-Script, versendet als Cronjob eingetragen, E-Mails an den root-User, wenn der Plattenplatz auf allen gemounteten /dev/hd*-Platten weniger als 1 GB beträgt.","date":"2010-05-12T00:00:00.000Z","lang":"de","html":"\n

\n Dieses kleine Bash-Script, versendet als Cronjob eingetragen, E-Mails an den\n root-User, wenn der Plattenplatz auf allen gemounteten /dev/hd*-Platten\n weniger als 1 GB beträgt.\n

for i in `df | grep \"/dev/hd\" | grep -e \"[a-z]$\" | awk '{ print $4; }'`; do if [[ $i -gt 999999 ]]; then df -h | mail root -s \"Low diskspace warning for `hostname -f`\"; break; fi; done\n

\n","slug":"niedrigen-speicherplatz-mit-bash-uberprufen-und-per-mail-warnen","hero":"!undefined"}],["npm7-and-aws-sdk-v3",{"subtitle":"Cloud Native","title":"Handling NPM v7's unnecessary inclusion of peer dependencies with AWS SDK v3","abstract":"When using NPM v7 to package lambdas using AWS SKD v3 it leads to unnecessary large deployment pacakges.","date":"2021-03-07T16:00:00.000Z","html":"\n

\n In my previous post I looked into the new AWS SDK v3, which\n turned out to provide good improvements over version 2 that justify an upgrade.\n

\n The upgrade is relatively straight forward: the same type of change needs to be\n applied to all clients and this can be done safely and quickly. Only a few\n changes required more than simply replacing some API calls.\n

\n This week I decided to migrate a bigger codebase to NPM version 7, which is now\n general available.\n However this surfaced an issue in AWS SDK v3 that leads to lambdas becoming\n unnecessary large, when the AWS SDK v3 clients are installed with NPM v7.\n

\n On a high level,\n the way I package lambdas runs\n npm ci --only=prod, which with NPM v6 results in a node_modules folder for\n this project I am working on of around 120 MB of dependencies. With NPM v7 on\n the other hand I suddenly was seeing folder sizes of around 380 MB, which after\n zipping was too large for AWS lambda:\n deployment packages after unzipping can only be 250 MB.\n

\n When trying to deploy the solution this leads to CloudFormation errors like this\n one:\n

\n
\n 7/88 | 5:33:19 PM | CREATE_FAILED | AWS::Lambda::LayerVersion |\n cat-tracker-Linux-fbfce639-layer (cattrackerLinuxfbfce639layerDD08A9A6)\n Unzipped size must be smaller than 262144000 bytes (Service:\n AWSLambdaInternal; Status Code: 400; Error Code:\n InvalidParameterValueException; Request ID:\n 839fc0c0-bc5e-4e4a-9cbb-df8fa8b2d3ba)\n
\n

\n The issue has been reported in multiple variants\n (#1536: Trim production dependencies,\n #2051: middleware-retry includes react-native)\n on the AWS SDK v3 GitHub project, but a fix has not been released, yet.\n

\n After going a bit back and forth over different solutions, I managed to get the\n lambda layer down to an acceptable size: 28.2 MB zipped / 196 MB unzipped size\n for the main application lambda layer, which includes these dependencies:\n

{\n  \"dependencies\": {\n    \"@aws-sdk/client-apigatewayv2\": \"3.8.0\",\n    \"@aws-sdk/client-cloudformation\": \"3.8.0\",\n    \"@aws-sdk/client-cloudwatch-logs\": \"3.8.0\",\n    \"@aws-sdk/client-codepipeline\": \"3.8.0\",\n    \"@aws-sdk/client-dynamodb\": \"3.8.0\",\n    \"@aws-sdk/client-iot\": \"3.8.0\",\n    \"@aws-sdk/client-s3\": \"3.8.0\",\n    \"@aws-sdk/client-sqs\": \"3.8.0\",\n    \"@aws-sdk/client-ssm\": \"3.8.0\",\n    \"@aws-sdk/client-sts\": \"3.8.0\",\n    \"@aws-sdk/client-timestream-query\": \"3.8.0\",\n    \"@aws-sdk/client-timestream-write\": \"3.8.0\",\n    \"@nordicsemiconductor/cell-geolocation-helpers\": \"3.0.1\",\n    \"@nordicsemiconductor/cloudformation-helpers\": \"6.0.9\",\n    \"@nordicsemiconductor/e2e-bdd-test-runner\": \"12.1.8\",\n    \"@nordicsemiconductor/random-words\": \"5.0.0\",\n    \"@nordicsemiconductor/timestream-helpers\": \"3.1.1\",\n    \"@sinclair/typebox\": \"0.12.9\",\n    \"ajv\": \"7.1.1\",\n    \"fp-ts\": \"2.9.5\",\n    \"uuid\": \"8.3.2\"\n  }\n}\n

The install command used here is

npm i --ignore-scripts --only=prod --no-audit --legacy-peer-deps\n

\n --ignore-scripts, --only=prod, and --no-audit are expected for bundling\n production dependencies.\n

The two important parameters to npm are:

\n i instead of ci:\n otherwise NPM v7 will, when used with the projects package-lock.json which\n contains many other development dependencies, install all dependencies, not\n just the production dependencies\n
\n --legacy-peer-deps: not many packages have yet migrated to NPM v7's new\n behaviour to\n automatically resolve and install peerDependencies.\n

\n For smaller projects without AWS SDK v3 dependencies you can keep using\n npm ci,\n as the example in my lambda packager shows,\n which speeds up the installation process significantly.\n

\n","slug":"npm7-and-aws-sdk-v3","hero":"!undefined"}],["ntd2022",{"subtitle":"Conference","title":"Nordic Testing Days 2022","abstract":"I had the opportunity to attend the Nordic Testing Days in Tallinn for three days and I had a blast.","date":"2022-06-06T23:00:00.000Z","html":"\n

\n I had the opportunity to attend the Nordic Testing Days in Tallinn\n as a speaker for three\n days and I had a blast. It's a beautiful old town with a very interesting\n history, which we learned about on a guided tour. The\n #ntd2022\n itself was a very well organized conference at a beautiful location (a former\n coal power plant). I spoke about firmware end-to-end testing using real hardware\n and got to meet many awesome people, who all care about better software.\n

You can find a real-time collection with a lot of pictures on Twitter:

I will definitely go again!

\n Update 2022-06-11: I have uploaded the photos\n here.\n

\n","slug":"ntd2022","hero":"!undefined"}],["office-design-by-an-office-hater",{"title":"Office design by an office hater","subtitle":"A walk through my dream office","abstract":"I hate offices. But how many interior designers have I heard of, that are coders, too? Let me take you through my dream office!","date":"2017-04-27T10:00+02:00","html":"\n

\n I hate offices. I feel uncomfortable in most of them because they are too loud,\n too crammed, smell, are too hot or cold. Being a knowledge worker I first and\n foremost need office space that helps me think; but most companies create office\n space for representative reasons, to impress clients, and show off their\n success, and and not with a focus on the productivity of those tasked with\n creating this success.\n

\n Just last week I was visiting a tech company here in Frankfurt and was shocked\n to discover what the consultants they paid for designing their new interior came\n up with: an open floor plan of randomly distributed work station left and right\n of a walkway and some meeting spots sprinkled within. For me this is madness:\n not only is there constant sound because of the big open-floor plan, but I also\n get distracted by visual noise: movement. And since the office lacked warm\n colors, the few unpretentious plants only added to this depressing instance of a\n creative production line.\n

\n And then I thought, that I’m making it too easy for myself to just complain. How\n many interior designers have I heard of, that are coders, too? None. So how can\n I expect them to come up with an office I would work in? Right, I can't.\n

\n I think it’s time that we as software craftspeople, who constantly thrive to\n improve our skills and tools, start looking at the place where we are practicing\n our craft and take influence in how they are built. We have everything we need\n for that: I’ve been using 3D tools since I’m a teenager, I’ve built maps for\n shooters like Doom and Duke Nukem, I’ve been a first-person shooter player for\n ever. This makes us very well skilled to also think in the physical space of the\n office world. Not to mention the whole VR thing. The tools we use are more or\n less used in interior design and architecture, and this enables us to speak the\n language of architects and interior designer easily.\n

\n Since I recently came around an\n awesome, browser-based tool for this\n task, I set out to create my ideal office. I tried to be very realistic and use\n a simple, rectangular floor as the base. I’ve created an office for roughly 30\n people, because this is known to be optimal team size for humans. Above that\n size, teams should split up anyway (and move to another floor).\n

\n Because I think that open space floor plans are awful I tried to create as much\n enclosed space as possible, but at the same time enabling everyone to quickly\n see if a person is busy, available or not even present. Unfortunately glass\n reflects sound very good that’s why the walls in the offices are made of\n sound muffling wood panels.\n Carpet floors everywhere help with reducing noise further.\n

Let me take you through my dream office

\n The base building block is the 3 people office (my favorite!). I think this is\n the ideal size for day to day work. Every office has tables that are adjustable\n in height electrically and a big (55\") flat screen, for pair programming,\n displaying team metrics and doing video calls with those who work remotely.\n

\n Note that a wall shields the tables from the entrance, this reduces visual\n noise. Teams can also use this wall to hang information about their work, or “Do\n not disturb” signs.\n

\n Some tasks require bigger groups to work together. Therefore two 6 people office\n rooms exist. They have the same features as the 3 people office.\n

\n For one-on-one meetings or just for some quiet alone-time, there are dedicated\n places and a nice library.\n

\n For the daily stand-up everyone can gather in the big open space (the townhall)\n in the middle of the office, which also brings everyone together during lunch\n time, and can quickly be transformed into a space for meetups. The screens here\n are touch sensitive so you can use it while standing in front of them. Iiyama\n has those or\n go for the Jamboard if you can afford it.\n

\n No dedicated meeting room? Yes, meetings should be reduced to an absolute\n minimum and can be held in one of the offices or in the stand-up area. This\n makes them public and everyone easily has the chance to join in. The same is\n true for client meetings, which in my experience rarely take place at the office\n if you are an agency, anyway. So, no dedicated meeting rooms necessary.\n

\n The unisex bathroom has a separate shower for those that come to the office by\n bike.\n

\n The kitchen is very well equipped with a large stove, because cooking is a great\n social activity, and you can't beat healthy, self-cooked lunch.\n

\n You can walk through the plan yourself and even modify\n it with the awesome Archilogic editor.\n

\n What do you think about this design? Please leave your feedback in the\n comments.\n

\n And start spreading the word that we as developers are interested in taking part\n in office space design and let me know, how your ideal workplace looks like!\n

Reactions

Here are some reactions (from other developers):

https://twitter.com/ryyppy/status/857537165944913920

https://twitter.com/fhopf/status/857548445510361088

https://twitter.com/spinscale/status/857568366357360642

https://twitter.com/SilviaHundegger/status/857575027511898112

Links

\n Martin Berry pointed me towards\n this post\n about about an office space where everyone has their own room. The company\n did drop\n the concept as they kept growing, though.\n

Updates

2.2

\n Updated the bathrooms and converted the stalls into separate rooms. Also added a\n wall between so there is more barrier between the bathrooms and the kitchen.\n

2.1

\n Updated the kitchen, thanks to Tobias for\n pointing this out!\n

\n
\n I think office kitchens desperately need a real stove-top or alternatively a\n sandwich-maker, raclette or fondue set. Preparing the shared meal together is\n really good for the community. Likewise things like sandwiches or raclette\n where everybody can bring something and then share. Another cool thing is to\n have a big salad bowl and make a huge mixed salad together where everybody can\n contribute.\n
\n

\n","slug":"office-design-by-an-office-hater","hero":"!undefined"}],["office-hours-discontinued",{"title":"Office hours discontinued–feel free to ask your question anyway","abstract":"I started mentoring and I will not offer any more office hours on a fixed schedule.","date":"2015-03-22T14:00:00.000Z","html":"\n

\n In January 2015 I offered CTO office hours every other\n Thursday. This came out of a new years resolution to do more things that I\n really enjoy–and I enjoy meeting people and work with them and their ideas.\n

\n That decision had a fascinating side-effect. When one of my former co-eds asked\n me to be her mentor the answer was a no-brainer: of course, I can and want to do\n that! I don't know how that call would have turned out if I didn't have thought\n about the office hours in January.\n

\n As a fallout from my search for a new job I also offered to\n be a mentor for the founder of a local startup. We are new meeting every two\n weeks for two hours.\n

\n What I enjoy about being a mentor over giving office hours is that continuously\n supporting a person enables me to see the effects of my mentoring first hand\n which also teaches me a lot in return. That's the kind of win-win situation I am\n always looking for and I've experienced in the last three years so often: give\n unconditionally and with pleasure and you'll get even more in return.\n

Nevertheless, I'm not totally bailing out on the office hours.
Just write me an email and I'll try to help you.

\n","slug":"office-hours-discontinued","hero":"!undefined"}],["office-hours",{"title":"Office hours","abstract":"I'll offer free bimonthly office hours starting January 2015.\n","date":"2015-01-02T15:00:00.000Z","html":"\n

\n In the last two years I’ve dived into the Rhein-Main startup scene working for\n startups and foremost trying to build a solid foundation that enables startups\n to grow. An important part of this foundation is a network of people you can\n trust and who can give you unbiased advice without a hidden agenda. Those are\n hard to find even if I think giving advice can be a lot a fun-which I had at\n last year's Startup Weekend Rhein-Main.\n

\n Even if I believe that Rhein-Main neither can nor should follow Berlin's lead\n in terms of Startups I do want to see disruptive, innovative and creative\n tech-startups in the area, because those will shape the Rhein-Main area and be\n built by people I want to work with in the future …\n

\n That's why I'll offer free bimonthly office hours either on Google Hangout or at\n the Coworking Space Die Zentrale in Frankfurt Bornheim Mitte starting\n January 2015. Talk to me about technology, building software, managing teams or\n your organization, whether you have a vague idea or a specific problem. And if I\n can't help you I'll probably know someone who does.\n

\n Email me at m@coderbyheart.com with a short intro and a link to your\n LinkedIn or XING profile and pick a free slot and I'll get back to you to\n confirm our meeting.\n

\n Thursday, Jan 22nd 2015: taken\n (How to write a CTO job posting)\n
Thursday, Feb 5th 2015, taken (App-Feedback for talkREAL)
\n Thursday, Mar 5th 2015, 1pm-2pm:\n (Backup your business: Advice for non-technical co-founders)\n
Thursday, Mar 19th 2015, 1pm-2pm: (BASISREBELL)

There are no strings attached.

\n Update March 22nd 2015: I've discontinued the office hours. Learn why,\n here.\n

\n","slug":"office-hours","hero":"!undefined"}],["one-month-into-my-new-job-as-the-cto-at-fintura",{"title":"One month into my new job as the CTO at Fintura","abstract":"I joined a #fintech startup which aims to change the way SME finance their investments and it also changed the way I look at managers","date":"2015-05-30T19:00:00.000Z","html":"\n

Update: five months after this post I quit my job at Fintura.\nRead why …

\n In March I announced that I was looking for a new team. This\n announcement resulted in an unexpected high amount of offers. I took the time to\n evaluate them thoroughly by rating them based on a point system and first and\n foremost finding out if I would have the chance to do what I was looking for:\n to build a team. After a little more then four weeks I signed the contract\n with Gernot Overbeck and\n Thomas Becher who are the\n founders of Fintura. I feel that both of them–given their\n experience in the industry–can provide a unique opportunity for the success of\n this fintech startup.\n

They basically handed me the keys to their business infrastructure and I took over even before my official first day.

\n It immediately changed to type of work I had to do. I have barely touched my IDE\n in the last weeks but could focus on defining the foundation of Fintura's IT.\n Starting with the definition of the structure of the IT team, their salary and\n their carreer path. It's obviously not as easy as it sounds. Ideas like the lean\n aproach, remote team members, transparency and software craft are something that\n cannot be easily explained with execuitve summaries or formulas but needs to be\n experienced–which is hard in the always moving startup rollercoster. But I feel\n the need to build the place I'd like to work at because it will not just\n magically appear. With a solid multi-million euro series A round due in the next\n months Fintura is looking into a bright future and our IT team–I call them\n fintechies–will get the funds it needs to build a compelling product without\n being turned into a meat grinder.\n

It's a green field without grass.

\n Joining a startup in this early stage offers other great opportunities. Not much\n is defined, yet: Put everything in the Cloud or go for\n Software Hosted in Germany,\n to Docker or not to,\n our codingstandards, unify the\n tech stack in favour of robustness or keep running everything in silos. Every\n decision needs to be prepared and made. To be the one that has the power to\n overrule every decision is tempting but involving as many colleagues as possible\n is the only way to find the best decision. And that's only the small part: much\n more excitement comes from beeing able to shape the way we operate at Fintura.\n The work of the fintechies has to be integrated with everyone in the\n organization and being tasked with finding a modus operandi that will enable\n us to deliver a product that the customer wants is by far the contribution that\n I am proud of the most when looking back at the last weeks.\n

I'm a politician, now.

\n If you know me then you also know that I hate politics. I pride myself in being\n brutally honest–which has worked for me very well in the past. But being part of\n the management at Fintura gives me access to information that I cannot share\n with all colleagues immediately. And having to keep knowledge to myself–even if\n it is in the best interest–is something that doesn't come naturally for me. But\n I already saw in the past that these situations are dealt with as fast as\n possible, without haste and very determined.\n

Let's go!

\n The last month has been intense. I have a new team now and it feels like the cog\n wheels that have been spinning freely are now gripping into each other and the\n machine that powers Fintura is getting its grips. I'm really looking forward to\n build the team that builds Fintura and I feel that I will have a blast, doing\n it!\n

\n If you like to be part of this team, have a look at\n our job postings. We are\n @TeamFintura on Twitter and we will start\n open-sourcing code that is not part of our core IP on\n GitHub.\n

\n","slug":"one-month-into-my-new-job-as-the-cto-at-fintura","hero":"!undefined"}],["passworter-fur-ssh-keys-in-der-konsole-merken",{"title":"Passwörter für SSH-Keys in der Konsole merken","abstract":"Um sich die wiederkehrende Passwort-Abfragen für SSH-Keys auf der Konsole zu sparen, führt man folgende Kommandos aus:","date":"2010-05-15T00:00:00.000Z","lang":"de","html":"\n

\n Um sich die wiederkehrende Passwort-Abfragen für SSH-Keys auf der Konsole zu\n sparen, führt man folgende Kommandos aus:\n

eval \"$(/usr/bin/ssh-agent -s)\"\nssh-add -L\n

\n Das startet den SSh-Key-Agent und damit ist das Passwort des Keys für die\n aktuelle Sitzung gespeichert und wird nicht mehr abgefragt.\n

\n","slug":"passworter-fur-ssh-keys-in-der-konsole-merken","hero":"!undefined"}],["pecl-crack-unter-ubuntu-installieren",{"title":"PECL crack unter Ubuntu installieren","abstract":"Auch die PECL Erweiterung crack muss erst überredet werden, sich auf Ubuntu zur Verfügung zu stellen, da beim Installieren folgender Fehler auftritt:\n","date":"2010-05-29T00:00:00.000Z","html":"\n

\n Auch die PECL Erweiterung crack muss erst überredet werden, sich auf Ubuntu\n zur Verfügung zu stellen, da beim Installieren folgender Fehler auftritt:\n

/tmp/pear/temp/crack/libcrack/src/config.h:1:26: error: ../../config.h: No such file or directory\nmake: *** [crack.lo] Error 1\nERROR: `make' failed\n

Die Lösung ist die manuelle Installation.

apt-get install cracklib2-dev cracklib-runtime\ncd /opt\nsvn co http://svn.php.net/repository/pecl/crack/trunk pecl-crack-svn\ncd pecl-crack-svn\n

Die Datei libcrack/src/cracklib.h editieren:

-# include \"../../config.h\"\n+# include \"../config.h\"\n

Die Datei package.xml editieren:

-          <file role=\"src\" name=\"config.h\" />\n

Und dann manuell installieren:

pecl install --force package.xml\necho \"extension=crack.so\" > /etc/php/conf.d/crack.ini\n/etc/init.d/apache2 restart\n

\n","slug":"pecl-crack-unter-ubuntu-installieren","hero":"!undefined"}],["pecl-oauth-0-99-9-unter-gentoo-installieren",{"title":"PECL OAuth 0.99.9 unter Gentoo installieren","abstract":"Da einige der Maschinen, mit denen ich arbeite noch (aktuelle) Gentoo-System sind, gibt es immer wieder Probleme, die Gentoo-spezifisch sind, und damit oft auch nervig.\n","date":"2010-05-28T00:00:00.000Z","html":"\n

\n Da einige der Maschinen, mit denen ich arbeite noch (aktuelle) Gentoo-System\n sind, gibt es immer wieder Probleme, die Gentoo-spezifisch sind, und damit oft\n auch nervig.\n

Aktuelles Beispiel ist die fehlschlagende Installation von PECL OAuth:

pecl install oauth-beta\n`\n\nlibtool: Version mismatch error.  This is libtool 2.2.6b, but the\nlibtool: definition of this LT_INIT comes from an older release.\nlibtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b\nlibtool: and run autoconf again.\nmake: \\*** [oauth.lo] Error 63\nERROR: \\`make` failed\n

Abhilfe schafft das nur das manuelle Installieren:

wget http://pecl.php.net/get/oauth-0.99.9.tgz\ntar xvzf oauth-0.99.9.tgz\ncd oauth-0.99.9\nphpize && aclocal && autoheader && autocon\n./configure\nmake\nmake install\necho 'extension=oauth.so' /etc/php/cli-php5/ext/oauth.ini\nln -s /etc/php/cli-php5/ext/oauth.ini /etc/php/cli-php5/ext-active/oauth.ini\necho 'extension=oauth.so' /etc/php/apache2-php5/ext/oauth.ini\nln -s /etc/php/apache2-php5/ext/oauth.ini /etc/php/apache2-php5/ext-active/oauth.ini\n

\n","slug":"pecl-oauth-0-99-9-unter-gentoo-installieren","hero":"!undefined"}],["phpugffm-als-animiertes-gif",{"title":"PHPUGFFM als animiertes GIF","date":"2013-01-18T00:00:00.000Z","lang":"de","html":"\n

\n $\"PHPUGFFM$ \n

\n","slug":"phpugffm-als-animiertes-gif","hero":"!undefined"}],["prototyping-iot-products-with-the-iot-tiles-toolkit-cards",{"title":"Prototyping IoT products with the IoT Tiles Toolkit cards","subtitle":"Design Thinking","abstract":"When building connected products, it will never be only the hardware which makes for a successful product. The IoT Tiles Toolkit cards are a fantastic support tool for generating ideas and even possible solutions.","date":"2018-08-28T09:00+02:00","html":"\n

\n When building connected products, it will never be only the hardware which makes\n for a successful product. Customers today—regardless whether they are a business\n or a consumer—are looking for connected experiences. Our products need to\n integrate in complex scenarios and a physical component may play a key role in\n such a scenario but seldomly can be looked at in isolation.\n

\n The biggest challenge therefore is designing a compelling offering which\n anticipates how customer will use a product and not only fulfill the basic\n functionality, but extend its value beyond that. Only then will users accept a\n device not only as a tool they maybe have to use, but as something that makes\n the task at hand significantly easier.\n

\n Given that we are faced with this challenge and it is incredibly hard to\n approach the design process with and open mind and not to get lost in details a\n group of researchers at the Norwegian university NTNU here in Trondheim have\n developed the IoT Tiles Toolkit and part of that is a set of playing cards which\n are a fantastic support tool for generating ideas and even possible solutions.\n

\n These cards are used in a workshop format and can be used with novices and\n experts likewise. They provide talking points to get creative and brainstorm on\n concrete solutions while a steady influx of randomness helps to keep an open\n mind.\n

\n
\n The journey starts with a set of problem SCENARIOS and PERSONAS given to\n participants to choose from. Participants are in turn asked to choose and\n combine THINGS, DATA CHANNELS, HUMAN ACTIONS and FEEDBACKS relevant for the\n chosen scenario. Participants then elaborate an initial concept and sketch it\n out on a storyboard. Then participants are asked to challenge their own ideas\n inspired by MISSIONS cards. A refined ideas in now visualised on the IDEA\n GENERATOR BOARD. Participants are then asked to collaboratively reflect and\n improve their concepts using CRITERIA cards and to prepare an elevator pitch\n to present their concept to the the audience.\n
\n

\n You can learn more about the IoT Tiles Toolkit on\n tilestoolkit.io. The cards layouts are available for\n download free of charge and generously licensed under a Creative Commons\n license.\n

\n","slug":"prototyping-iot-products-with-the-iot-tiles-toolkit-cards","hero":"!undefined"}],["prototyping-products-for-the-internet-of-things-using-javascript",{"title":"Prototyping products for the Internet of Things using JavaScript","subtitle":"Talk","abstract":"This is a recording of my 2018 talk on prototyping products for the Internet of Things using JavaScript","date":"2018-11-17T18:00+01:00","html":"\n

\n My 2018 conference talk focused on how to prototype for the Internet of Things\n using the language we all love: JavaScript.\n

\n In this talk I explain why the Internet of Things, or in short IoT, is a very\n exciting field how we as engineers can start to explore this space with its very\n own restrictions and challenges. Because today we can no longer focus only on\n technical solutions but need to be able to develop connected experiences for\n our clients—they are not able to innovate on their own any more and depend\n on the expertise of consultancies and contractors.\n

\n A part that did not make it into the 45 minutes I had at code.talks was a look\n at the protocol that will power the next generation of connected devices: MQTT a\n lightweight pub/sub protocol which has some significant improvements over HTTP.\n You will find the slides in the talk and it is am important part to explore when\n starting to look into this topic.\n

Here is the recording:

https://www.youtube.com/embed/HpNv8Ahb2MU

\n And here are\n the Slides.\n I brought a demo application to the conferences which I have\n published on GitHub and it runs\n on an Espruino Wifi.\n

Happy connecting!

\n","slug":"prototyping-products-for-the-internet-of-things-using-javascript","hero":"!undefined"}],["push-to-deploy-as-the-means-to-deal-with-uncertainty",{"subtitle":"Talk","title":"Software Quality made this talk happen: push-to-deploy as the means to deal with uncertainty","abstract":"This talk is an encouragement for developers to trust their skills and tools, but also invest in mastering them.\n","date":"2024-05-16T13:30:00.000Z","html":"\n

https://www.youtube.com/embed/2KeBxWAdndo

\n I was first paid to write software in 1997, now 27 years ago, and if there is\n one skill that had the biggest impact on my career then it’s the ability to\n deliver working software that doesn’t break. This allows me to take vacation,\n invest back into my communities and initiatives that I want to support,\n self-development, and to have time for self-, and family care.\n

\n In this talk I want to reinforce your love for software quality by sharing how I\n helps me in my day to day work where I balance my efforts between too many\n projects but still manage to be both and innovative software engineer, and\n deliver solutions that do not break when it matters most through setting up all\n projects and teams that I work with around one main principle: push-to-deploy.\n

\n In order to achieve this, confidence is needed, which can only manifest if we\n know that our changes will not break the system. And in an environment that\n becomes more and more uncertain and volatile every day, there is only one\n solution that has stood the test of time: writing tests first. And its beauty,\n especially with outside-in-test-driven-development, is that it helps to keep the\n focus on delivering value to the end-user. Over the last years I have added\n Behavior-driven development to my quality toolbox because it decouples the\n implementation of the tests from the implementation of the application. Testing\n through the public API of a system ensures that there are no unexpected changes\n for the user.\n

\n As I will share, I have a strict focus on user stories when building our\n products, because it is the only way that ensures that all stakeholders can\n participate and contribute to a product. Because in the end a successful\n software is always built in collaboration with people who contribute source-code\n and those who contribute in other ways.\n

\n Enabling the collaboration of all stakeholders is a very important part of my\n job, and I have been able to achieve this through using a walking skeleton\n approach: delivering working minimal products from the first day. This way\n developers like me can make sure to be involved in the discussion with product\n people and customers early on in a projects' life-cycle. And in my experience\n only the real product (and not even a click dummy) will truly create shared\n understanding with all stakeholders. Because time is always short and we know\n that every prototype ends up in production we have to make sure that even our\n prototypes are of high quality; which is where using quality in software\n development to achieve continuous delivery (CD) with confidence - really shine.\n

\n The slides are available\n here.\n

Video transcript

Thanks for joining me in this talk.

I can be here because software quality is the story of my professional career.

\n And given this is the 10th edition of New Crafts, I thought it would be time to\n remind you why we do what we do as crafters.\n

\n My story goes back till 2012 when I became a crafter, but now I have colleagues\n who could be my kids if I had them.\n

\n Like they're in their early twenties and they, they study, or they become\n juniors and they are the next generation of software engineers.\n

And we as crafters need to think again like, why are we doing this?

And we need to explain this.

And this is, this is what I would like to share with you.

\n This is a talk that is very personal, so not everything that is in there might\n apply to you, so keep that in mind.\n

But I hope you can take away a few things in there.

So, a little bit about me.

I am an R&D research and design engineer from, Nordic.

I work on cloud stuff, at the semiconductor company.

\n So my company makes money selling chips that connects your smartphone to your\n headphones, the pencil on this fruity tablet that you have or tracks the medical\n the pharmaceutical products that you need, and, and allow that to happen.\n

I work in Norway.

I'm not the only one from Norway.

I hear we have two more speakers from Norway, so I'm pretty proud of that.

\n You can find all my links on\n coderbyheart.com/socials.\n

\n The slides, I've shared them on my Mastodon profile in case you want to follow\n the links or whatever, but you can reach me there.\n

So first let's recap a bit.

What is push to deploy?

Push to deploy means:

\n when I do a change on the thing that I'm working on and I committed to my\n versioning system, probably Git in most of the cases, and then I push it,\n meaning I push it to the, to the server, make it available to, to everybody in\n the team.\n

\n So I push it from my local computer to the source code repository that we use as\n a company.\n

\n But then from there, it should trigger the chain, your pipeline, your flow, that\n puts it in front of the real customer.\n

\n And it's not the test system or it's not your colleagues, it's actually whatever\n makes you money.\n

\n So it can be, if you are software as a service, it could be your website that it\n shows up there, or, if you're shipping, software to other of your collaborators,\n your customers, then it arrives there and they can use it.\n

So this is really important fact that we, we want to optimize for this.

\n And this is, when I, when I talk about push-to-deploy, this is what I mean.\n Deploy is not just is it running somewhere, but is it used by the end user?\n

And there is a fantastic book, I hope all of you have read it.

\n If not, this is a reminder to read Accelerate because, the first half of this\n book explains why push-to-deploy is so amazing.\n

And then the second part is it actually shows the proof how they figured it out.

The scientific background, the methodology they used, is explained.

\n So A, if you want to convince somebody, you can prove that the numbers in there\n are correct, and B, you can apply this methodology in your company as well to\n test and figure out and learn more on how to get code faster into production.\n

Push-to-deploy is kind of a mantra for me.

There are so many principles out there that we learn as crafters.

We get some of the very outdated ones.

\n S.O.L.I.D., we get, maybe, I dunno, TDD, is kind of a principle, that we learn\n or inside-out-testing, outside-in-testing, Domain Driven Design, like all of\n these are many concepts that are very good.\n

\n But for me, I feel that over my experience over the last years, it's really\n that, focusing on this thing, getting the code out there as fast as possible,\n applies in any domain that I've worked on.\n

\n I now work in IoT, but I've worked in FinTech, I've worked in the gaming\n industry, I've worked in in advertising, in marketing.\n

So kind of everywhere this would and will still apply.

\n So it's a universal thing, principle, and it's really easy to remember what to\n do, how to get there is the hard part, however.\n

So why do I want it?

What does it give me?

It's not because I get surprises from it, it's to deal with surprises.

\n And I think we understand now since like maybe the last five years, this is more\n or less common, is that we live in a volatile world.\n

Everybody went through the pandemic.

That was probably the call for the globe that nothing can be predicted anymore.

Until before that we had some financial crisis.

We had 9/11, we had some of these Black Swan events that nobody could predict.

\n And even if you can predict them, then you don't know what effect they will\n have.\n

And that makes them really dangerous.

\n But the overall learning is that it's completely futile to do any planning, any\n long-term planning that goes beyond maybe this week we don't know what's gonna\n happen next week.\n

You have surprises everywhere.

Like you get surprises if you build a product for your customer.

Your customer last week said, I want this button on the left side.

\n And then they get the new Chief Marketing Officer and they say, no, I want it on\n the right side.\n

Here's money. Make it happen. I don't care.

\n So, and you can tell, but last week you told us left side, and now you're\n telling right side, and yes, fine, I'm the customer, I'm paying. Surprise\n change.\n

\n And you can, and we heard here, sometimes you need to push back and say, no,\n that's not right.\n

But sometimes it's just like that.

They want it, it makes sense. They change their business.

So we need to follow their decisions or they will pick another vendor.

Surprise success is, is great to have, but can come at a surprise.

You build something which is kind of ahhh ... it's gonna be a cool prototype.

Let's see how that works.

\n And then like two weeks later you learn oh, this is the main showcase at the\n trade show that is happening in Barcelona.\n

That happened to me, more than once.

\n When nobody tells you oh ... your stuff is gonna be used in that way, but it's\n just this because it works.\n

We all got that surprise delays.

I can go on endlessly.

I can't avoid surprises.

\n But I need my team and my solutions that I work on be ready to deal with these\n surprises.\n

\n And that's were pushed-to-deploy really enables me to do this. Because, anytime\n I have this cycle,\n

\n I make a change, I put it in front of the customer, I put it in front of my\n team, I put it in front of my stakeholders.\n

And by the way, over the lifetime of your product, your customer will change.

\n If you start a new project, in the first day, you are your customer because you\n want to see that it runs in, in the cloud and that kind of the bootstrapping\n works and that you have all the pipelines in place, then you are the customer.\n

\n Then next week you're showing the product to your product manager and to your\n team.\n

Then they are your customers. And then this changes over time.

But the idea is the same.

\n The people that give you money, that give you power that you need to agree on\n what you're doing, that basically grant you the freedom to keep working on this\n project.\n

\n These are your customers and you, every time you put it in front of them, you\n get feedback.\n

I list some features that I get from these fast feedback cycles.

\n Really if you've been following Thierry a bit he's here on this conference as\n well.\n

\n He has really, really elaborate and very good ran about why, feature branches\n are evil.\n

\n And if we do push-to-deploy, meaning we all commit to production code and there\n is, at any given moment in time, we can release our software to the wild.\n

There are no feature branches.

\n That also means there are no longstanding conflicts where you have a long living\n branch and then you, you kind of don't put it in production, but you put it off\n and then you come back and then you need to merge everything together to get it\n to work.\n

Don't do this. It will save you a lot of work.

And, it will also not block others if they depend on your work.

Just finish your work.

\"Just\" an evil, very evil word.

Just finish your work.

Get it in production then everybody else can depend on what you've done.

\n Of course, that just finish your work means we need to kind of slice our work\n smaller and smaller iterations so we can basically drop whatever you're working\n on.\n

\n When I work not on any project, basically on any project, if somebody comes to\n me and says, Markus, I need this.\n

\n I am prepared for this because, again, I can't predict if they say, is this\n important?\n

\n Of course we assume, let's assume just they have a good point why they want me\n to do this.\n

Then I'm able to drop what I'm working on maybe within one, two hours.

\n I don't need it immediate, but I can finish what I'm working on, finish, write\n my test, put it in, push it, release it, maybe put it behind a feature flag, but\n it's out there.\n

I can drop it, I can get my mind off it.

I don't need to remind my colleagues, \"Hey, I'm still working on this.\"

\"Please wait. Or please rebase your branch against it.\"

What, whatever. I push it out, it's done.

I can shift my focus.

And with a lot of surprises,

shifting focus happens constantly.

\n There's unfortunately, a big learning in my career is: you cannot avoid these\n surprises.\n

I tried it many years ago. It didn't work out.

\n Reiterating it a bit, unfortunately, the surprises also come from many things\n that you don't like.\n

There are positive surprises, but very often there are unfortunate surprises.

So we want to be, and we need to be in this constant loop where shit's fucked.

\n Meaning like you have technical depth that you need to change in order to get\n this new feature, or there's a new feature that you don't want to do, but you\n have to do it.\n

And then yes, we need to change it.

And sometimes this means we need to completely change our architecture.

\n Alberto said this so good\n in his previous talk.\n

If you haven't been here, please watch it.

We can only make decisions based on the knowledge we have now.

\n But we cannot limit the future capabilities of our systems based on the past\n knowledge.\n

\n We learn new stuff, we learn that there is new value to be created and we need\n to go where we can create this value.\n

And that sometimes unfortunately means we need to change everything.

So we need to fuck shit up, so we can find it out.

So we can find it out. This loop.

The faster this loop is, the more we learn, the less painful it becomes.

The pain will never go away.

It will always be painful.

There will always be this phase, \"Oh my God, not again.\"

\"It's fucked again.\" But we can get out of it.

\n So we get this good end of feelings of okay, customer's happy, we changed\n something.\n

My colleague is happy. It is on a trade show.

Oh, there's good, PR about it.

My marketing colleagues are happy. Hmm.

That gives me then the motivation.

The next time when somebody comes to me with, \"Hey Markus, can we change this?\"

I'm like: \"I hate you for it, but yes, of course we can.\"

\n What we need in order to be able to push-to-deploy however, that is where the\n craft comes in.\n

The plain process of I push code and it goes online.

Well, that's that there's no magic.

\n Like you pack whatever your artifact is of your source code and put it on a\n server, and then user does a request and hopefully it works.\n

And of course we want to eliminate this \"hopefully\".

We want to be certain that it works.

And the only way to get to this point is to write tests.

There, there is no way to do this manually.

You cannot do manual testing.

\n If you have a high velocity, if you release, change your production multiple\n times a day, there is no chance in the world that you get good manual tests.\n

Well, you can pay for it, but it, it doesn't make sense.

It economically doesn't make sense.

So you need automated tests.

\n This will give you the certainty that, okay, the change that I'm now making,\n that's usually where you have a high confidence because this is the, the small\n part in your code where you just work on, you have all the things in mind.\n

\"Okay? It's touching this database here, this is working.\"

\n Where you probably can get away with little tests, to make sure it works because\n you also just tested it.\n

\n The problem is all the other stuff out there in your system that you completely\n oblivious to that it even exists.\n

Maybe it's not like you've never touched it, you've never seen it.

\n If there are no tests there, but you kind of change something here, then this\n will break the system.\n

\n So we need good tests over the entire system to make sure that even small\n changes, we don't accidentally break something.\n

We also write, of course tests, for ourselves.

\n Even I have to drop something, I would, very often then if I'm not finished with\n the the feature I'm working on, write a failing test or a skipped test that\n says, okay, I want like this thing to work like this, put it in a test, commit\n it, it will be there, it will be marked as skipped.\n

\n But the next time I pick it up, I can go back to this test because this test,\n and I design outside-in and this test will tell me: \"Hey, this is kind of the\n thing\", \"that the user wants to do.\"\n

\n And then, okay, alright, I remember, okay, now I know what to kind of implement\n under the hood to get it to work.\n

\n And of course, like this is the fight we constantly have as crafters, who\n believe in testing is the people who are not there, yet.\n

Who kind of know it's good, but it's too much effort.

This is our job to make it easy for them to follow us.

\n We can't just say: \"Oh, let's go there.\", \"This mountain is not so high as it\n looks like it's kind of, it's fine.\" \"You will be fine.\" No, we have to go\n ahead. We need to lead with good example. We sometimes even need to make the\n path there.\n

Because getting started is really, really hard.

\n The thing at the side here, yes, of course, don't have too many tests.\n Especially when we start with TDD, we start making, building a lot of tests.\n

\n And then at some point we have many tests that cover the same feature or are no\n longer really useful.\n

Remember to delete your tests.

\n Because this will remove cognitive load from everybody who's coming in later and\n trying to understand what is essentially happening here or have like a giant\n file that tests all the variants here.\n

Maybe it's not super useful for them to understand it.

And this is where we come to the vacation part.

I'm now not working, on code.

I'm here on stage and on this conference.

If I have well-tested code, I can even be productive while I'm doing nothing.

So, here's an example from my inbox.

This is like Thursday, Friday, Saturday, Sunday.

\n So while I'm not working, I'm still producing value respectively, not I, but the\n code base that I created is covered in a lot of tests that I can deal with the\n messy state that the JavaScript ecosystem is in, where we get dependency updates\n every hour.\n

\n And if you want your code base to not be outdated, you basically need to deal\n with this in an automated way.\n

\n And having a well tested code base means if a new dependency changes, a test\n will be run, it will be checked that it works.\n

\n And if it works, we bump the dependency and release an new version to\n production. we get automated security updates.\n

\n We get new, not new features because we don't use the new features, but maybe we\n get performance improvements.\n

\n And the best thing is, if I get back from vacation, I did three weeks vacation\n now, I come back to a code base with basically no new PRs.\n

\n Nobody needs to take care of maybe stuff that piles up while I'm away on some of\n my projects where not more people are working on it.\n

\n Again this mindset push-to-deploy, means a bot, AI, hello, a bot can create a\n commit.\n

It gets automatically verified. Is it good?

And if yes, then fine.

\n I talked about this principle where, I can save the work that I'm working on and\n I save the intended user feature.\n

\n That was a hint on, what I think is for me, really the best way to approach\n this, push-to-deploy and the fast feedback cycle is using outside-in TDD.\n

Very, very simply explained.

\n If we talk about writing tests we have a calculator and we have a function that\n adds two numbers, or we have a calculator, it's the product, I want a\n calculator.\n

\n So I can implement my calculator and the test for it by really starting to\n implement all the features.\n

Like I have an add function and I write a test for it.

I have a subtract function, I have a root function.

And then so I build all these small things that a calculator should be doing.

\"Oh, let's pull in modulo. What else do I have?\"

\n I need to deal with rendering maybe exponential numbers, how to display floats,\n whatever.\n

\n Like I can spend a lot of time on testing all the components and then I pull\n these together into bigger components.\n

But since everything is covered under here, this goes very fast then.

\n But I can spend a lot of time in the depth of some obscure feature that I might\n be needing to test it.\n

\n Where outside-in TDD is really taking from the beginning the perspective of the\n user.\n

\n It's not deconstructing the calculator into its small components, but it's\n saying:\n

\"Hey, as a user, I want to add two numbers.

Then you have the calculator and say, given two numbers, I expect the sum.

You have a user story already and you get clarity from your stakeholders.

Okay, this is what we want.

None of your stakeholders said they want to do modulo.

Nobody says they want fractions.

Maybe you will never need it.

\n So when, when you use outside-in TDD you really focus on the features and you\n only do that.\n

\n And this is really, really helpful to, to make sure that you only implement the\n necessary stuff.\n

\n However, that means there is, there will be some maybe shortcuts or not like\n super optimizations for any kind of use case that will lead you later to do more\n refactoring.\n

But then at least we know that the refactoring is needed.

\n Like in the beginning, I have a calculator which has the add implemented, just\n in the main function.\n

\n And if I have 20 different operations I probably want to refactor this in into\n smaller modules, so it's easier to compose, but maybe I never need this.\n

\n The ultimate hint for you and what to really look into, I think is, Behavior\n Driven Design, which really takes this to an extreme that it decouples the\n testing, the language the tests are written in, from the actual implementation.\n

\n And BDD takes a step that it moves your basically description of what the thing\n does.\n

\n There is a user who has a calculator and then they input two numbers and they\n get a sum out of it.\n

They put this in like written plain English text.

\n And now when you have a plain English text, you need something that runs this\n against your system.\n

\n But the cool part is that regardless of what you do here, you can change\n everything in your implementation.\n

\n You can change the language, you can change from Python to JavaScript. You can\n change from Java to whatever this file here with your test.\n

That will not change.

\n And there's a really beauty in it that it preserves your intended behavior of\n your system in a state that is not affected by any refactoring.\n

\n And I've seen this so often that when you start refactoring and removing stuff,\n you start uncommenting tests and maybe delete them, maybe move them around.\n

You forget to turn them on or add them back.

And that can happen. Where if you have a BDD feature, it will not.

\n So that is really an important, way to capture the behavior of a system in a way\n that's also understood by all stakeholders.\n

\n I know that's a myth that with BDD, I can go to my product manager, and say:\n \"Hey, let's write a BDD scenario together.\"\n

That's not true.

\n I don't think many people have managed this, but at least like they can, if I\n give it to them and say: \"Hey, this is what my system does,\" \"it takes two\n numbers and gives out a sum\" they can understand it.\n

They don't get scared by some syntax, by curly braces.

And they are willing to read this.

\n And also new people who come in a team, they can start browsing through that\n without needing to dig through your source code system to figure out what's\n actually happening in which unit test is relevant.\n

I can talk forever about BDD.

\n It's also amazing because it groups together features or or implementation into\n things that a user would do.\n

\n A good example is that, you very often see, you have a, a storage class, a\n repository implementation that can store stuff.\n

\n And often it's really stuff because it's generic, it's not a book storage\n because you don't need that.\n

Technically, a database can store anything.

So your database repository adapter will also store anything.

\n And that's not helpful. Like the user is not using a repository, the user is\n using your website.\n

And then they have a list where they can add features.

\n So, and if you have a feature that connects this part of your source code to\n this feature, you know exactly when and where it's used.\n

\n That was just a glimpse of where like this explodes in complexity of how to\n test, why to test, what to use, what technology to use, which approaches to use.\n

And, the unfortunate truth is that, it is extremely hard to get started.

\n The effort it takes, like when there are no examples in your source code base,\n is insane.\n

And it's super frustrating.

And then over time, the more examples you have, it gets easier.

\n I'd say that at some point, like if you have too many examples, it might even go\n up, because then your test suit gets too long, the runtime gets too long,\n whatever.\n

But that's unfortunately the truth.

\n And that's what I said before, like, we need to be good at giving examples and\n be a good example.\n

So how do we get there? How do we become good?

\n I know I want to test and I was in, in many times in a situation where I came\n back from a conference, heard about this testing is cool, and then at work\n nobody writes tests.\n

And this has worked for me in my career very well.

\n The 20% rule, which basically means if I have a new project or I have an\n existing project, but I want to learn something new where this could work.\n

\n So for instance, I want to try out event sourcing. I know I have kind of, we\n have never done this before to, to make events the main source of truth for our\n system.\n

We just use MySQL and do updates.

That's fine, but I really want to try it.

So I would then risk it.

That's the truth.

\n Like 20% means of the deliverable, like using event sourcing is maybe 20% of the\n features.\n

\n And if I figure out at some point \"okay, it won't work\" \"it is the wrong\n decision\" I still can go back and rip it out and use the old approach.\n

\n You can do this for everything you have 20% of your time you can always carve it\n out because you have, after some point of time, you have enough knowledge on how\n to build a system, and very often you repeat stuff.\n

\n So try to introduce some experiment even in your own code, you might learn with\n it.\n

And if it fails, well, you take a weekend and implement it the old way.

And this can even work as a team.

\n You need a commitment to that, but there is room for it. the next thing is and\n this is a thing that worked well for me, but the gist in here is that we become\n good by learning not everything.\n

We need to find the things that work for you.

And that's, that's okay. You can't know anything.

\n It's just too much. But learn some of the techniques that serve you well, and go\n deep on them because the truth is there is not one thing how to implement\n anything.\n

There is always another way to do it.

And so the same with testing.

I said outside-in is great.

\n There are enough people and example that say no inside-out is the only way to\n go.\n

And we both are right. We get good systems.

It's just for some of you, it the one way works the other way maybe doesn't.

I talked about end-to-end testing.

\n Push-to-deploy also depends on one of these ideas here. Reproducible builds. You\n need to learn how to package software in a way that you can kind of repeat it,\n repetitive, deploy it.\n

If you learn this by the way, you go into scalability.

I put RegEx on here because for me, RegEx allows easy refactoring.

I can using RegEx, do a lot of refactoring.

I personally, I don't use refactoring tools in IDEs.

I too often change IDEs.

I was forced to use Vim when I was in my early companies.

So I came from a path where I didn't have IDEs in the beginning.

\n So I know how to clone hundreds of repositories and do changes across many\n repositories at the same time using RegEx because I also am not afraid of code\n duplication.\n

Another thing here, code duplication is not a bad thing.

It allows you to quickly iterate.

\n I don't need to make code reusable so I can apply it with all the like,\n perfectly designed APIs in multiple projects.\n

There's no value in it.

\n It only becomes a problem if you have bigger code bases that reuse the same\n piece of code that has the same bugs, but then well, you still can use RegEx to\n find it and fix it.\n

This is where craft really comes in.

\n One of the ideas is that we have is that, we try to understand the tools that\n exist, keep an open mind, that's really important.\n

\n What is out there? Have a look at it, do these experiments, but really find the\n tools that work well for you because only then also can you explain it to your\n team?\n

Why are you doing this? Why are we doing code duplication here and why not here?

\n How can I deal with tests when I can't run the system, on my computer and to end\n testing?\n

\n Awesome. So this is, we need to have a discussion with our younger colleagues on\n really not on a level \"This is how I do it.\", \"So you have to do it!\" but I need\n to enable them to understand why we're doing this also because they might find a\n better way and then can tell me, Hey, there's a new way to do it.\n

\n One thing I would really like to reinforce is that, testing as in test driven\n development, is a universal skill.\n

Meaning if you invest in this, this will be useful for your entire career.

Like it works in, in all languages.

It works in embedded, it works in high level languages.

There's no programming language that can work without tests.

\n So all of them can work without tests, but there is no language that is perfect\n because tests are not for the language.\n

Tests are for your assumption.

Tests encode your business knowledge and the requirements that you have.

\n Yes, you might write some tests that your data is stored correctly in the\n database or the integration against an API works, but mainly tests serve as a\n documentation.\n

That's why I put this blue reminder here.

Don't test your language features.

\n If you have a feature that calls some functions and you have, for example,\n TypeScript, like I see this very often in, in lambda functions like a Lambda\n function pulls in some collaborators and then passes in an event to another\n collaborator.\n

\n I don't write tests for lambda functions, which they are very kind of your, the\n C and MVC and model view controller.\n

I don't write tests for the controller.

\n If I have TypeScript, which then ensures that I can call my collaborators with\n the right parameters and everything typed, the input is validated.\n

So there's no point in like doing language tests.

We can only do this fast iteration if we start owning our own infrastructure.

\n I've never seen it work well with a DevOps or an ops team, which you hand over\n stuff over the big wall and say: \"Hey, please run this for me.\"\n

\n And then you just ship them new features and they are responsible for running\n it.\n

They're responsible for performance, for migration, for whatever you need.

Unfortunately, I think that's the truth.

You need to learn more about how to run the things that you're building.

\n And the way to do it is, of course, going in the cloud, going serverless, or\n learning about, deploying infrastructure, using Kubernetes or whatever works for\n you.\n

For me, serverless worked very well.

\n But one of the like big, big important decisive, books for me to learn and start\n learning more about it was, REST in practice.\n

That's the top one. It is really a fantastic book.

\n The main idea is like, how can we build systems that work when everybody failed\n to build these systems?\n

\n The only system we know that really works well for billions of people for the\n last 35 years is the internet.\n

\n And the internet is built on very simple principles. HTTP requests, status codes\n and systems are broken all of the time.\n

\n So if you keep that in mind, if that's your mode of, how you design your system,\n everything fails all the time.\n

\n How to deal with that. This book tells you how to use that, as a way to design\n your architecture, and it leads you natively towards a microservice\n architecture.\n

And you can use this and apply this many different contexts.

\n And if you then go a bit more into the serverless route, then definitely start\n reading. the new book that just came out a few months ago, serverless\n Development in AWS fantastic introduction.\n

I'm such a big fan of serverless also because I work a lot in IoT.

\n In IoT we have this a problem that is made for serverless where we have millions\n of devices which connect to your server.\n

You can't predict it.

It needs to scale.

You can't have one machine that deals with these requests.

\n There's a long talk, by me about why this is such a great match. many systems\n have properties where serverless is really a good application.\n

You should invest a bit of time into it.

\n Now we are close to the end of my time, so I want to finish with what I said in\n the beginning.\n

\n You need the support system outside of work because very often you're alone in a\n company, and you're the only one who's pushing this forward.\n

\n My journey basically as a crafter was really, really, really supported by the\n outside support, not within my company,\n

but it's really, there's a big community out there that can help you.

\n And by the way, no, there are no certificates, like softwarecrafter\n certification is a scam.\n

But you can go to my website and get a certificate.

I give them out for free if you want it, but it's a scam.

So the solution, of course is you are already here.

So you did the first step.

You went to, to a conference, to connect with others.

And this is the, I think the only way that really worked.

\n And if you start digging a bit into the software crafters community, then you\n will find there's many resources.\n

Advocate internally, if you're at the point and you need to grow the others,

\n I said that before, you need to be an advocate, a good example, but the\n inspiration for that, and many have the same problem, that you want to push a\n topic and you don't know how is, to go to external communities.\n

\n We have a nice website, software craft communities worldwide,\n softwarecrafters.org, where we list communities\n all around the world.\n

NewCraft is part of this network.

\n There are other conferences, like I really love the Friends of Good Software\n conference, was from a testcraftCamp.nl\n

\n Now it's, it's more on, software quality, really great communitie, it is\n virtual, you can participate here virtually.\n

This is really cool. Organize your own, I organize a few conferences.

\n I organized Codefreeze in Northern Finland, come there, 80 people, a lot of\n snow, Aurora, Sauna, and maybe a bit software craft talks.\n

\n One thing that really has helped me, and this no longer exists, but I just put\n it up here as an example\n

I also created my own peer groups.

\n I think, some people call these mastermind circles where you just reach out to\n people from other organizations.\n

And for me, this was a time where I was a CTO in startups in Frankfurt.

That's why #TechLeadsFFM, that's the region.

\n And I reached out to other CTOs, from startups, and, we started creating this\n circle, where meeting as a group, like 15 people.\n

And then we would have one-on-ones.

And everybody was really thankful that this existed.

It takes really little effort.

\n So reaching out to a few people, finding a coworking space where you can hang\n out with a few beers and do this once every two months.\n

\n But the important part is that you kind of connect with others and start sharing\n your things and the problems that you have, because everybody has these\n problems.\n

And of course, what I'm doing now is also part of getting better at my craft.

\n Because when I stand in front of people, this trains your skill to voice what's\n important for you.\n

And I really invite all of you.

\n I don't want to be on this stage, don't want to see more people like me, white\n English speaking dudes from Norway, or from Europe.\n

I want to see more diversity on conferences.

And unfortunately, it's a giant problem.

So please take the courage and apply.

And the first thing you need

to do is just write an abstract.

You don't need a presentation.

You just need four sentences and three takeaways, and that's it.

Submit it to a conference like NewCrafts.

And if they take you, then you have to make the presentation.

I made a video about this, like how simple it is.

And if you want to write an abstract, I will help you.

We need to get more.

\n I've been doing this too long, so there need to be more people who are doing\n this.\n

Not so long as I am.

\n But it's a way, of course, I get to go to the speaker's room, I get to meet\n amazing other speakers.\n

I can just chat to them and learn about stuff.

And get the insight that will, again, help me improve my skills.

It's, it's really invaluable.

So I will be closing with

What's the point of this?

I talked about push-to-deploy, we are learning, we need this skill.

And I'd like to reiterate why do we want to be good at what we are doing?

\n And basically, Alberto said it before in the talk, we can't just put shit in\n front of our customers.\n

Everything we do needs to be very good.

If it's a good idea, shitty executed.

\n If it's the most amazing screen design, but the response time is 15 seconds\n before the page loads, nobody's gotta see this amazing idea.\n

They will be gone.

The craft itself it's not an end to itself.

\n We support business ideas with our craft and through us, we are the conduits\n that take the business idea.\n

\n And, I might not agree with all of them, but I don't have the data to say to\n them: \"Hey, this idea is really shitty.\"\n

\n I need to treat any idea that's coming to me fairly, give it my best to put it\n in front of the user and let the user decide if this idea is shitty, because\n they are paying my salary, not I.\n

\n So that really is why we need to be good at what we are doing to give any idea\n that is out there, a good chance to survive and maybe to be the surprise success\n we have been preparing for.\n

Thank you very much.

\n","slug":"push-to-deploy-as-the-means-to-deal-with-uncertainty","hero":"!undefined"}],["readable-error-messages",{"title":"Readable Error Messages","subtitle":"Best practice","abstract":"Use RFC 7807 \"Problem Detail\" to document API errors.","date":"2026-01-04T18:36:00+01:00","html":"\n

\n
\n Error messages are the only piece of documentation you can be sure people will\n read when it is relevant. Write them accordingly.
— Beth Andres-Beck\n
\n

\n Use RFC 7807 \"Problem Detail\" to document\n API errors.\n

\n","slug":"readable-error-messages","hero":"!undefined"}],["readme-for-apc-students",{"title":"README for APC students","abstract":"I am mentoring students and I gave them a README for my weekly office hour.","subtitle":"Mentoring","date":"2020-12-11T18:00:00.000Z","html":"\n

\n I am mentoring students\n and I gave them a README for my weekly office hour.\n

\n I ask them for 4 things every week, because I think these are very important\n for them:\n

note progress
get clarity on goals
identify where you struggle
say thank you

\n I am doing this so they develop habits that will benefit them later in their\n work life:\n

\n note progress: it's important to capture the things you did. This is data\n which is very useful to keep stakeholders up to date. But it also provides a\n great source for review and appraisal meetings with managers. If they are not\n frequent you will most likely have forgotten what you did a few months ago. A\n log of things you did will help you identify important milestones you\n reached.\n
\n get clarity on goals: working on software projects is highly complex and\n it's easy to loose sight of the bigger picture. Many small problems pile up\n and can easily obscure the initial goal that was set at the beginning of a\n project. Stating (and reinforcing) the goals you work towards is important to\n keep everyone aligned to work towards the same outcome. Clarity on thy Why?\n is neccessary to be able to quickly make daily decisions without depending on\n long feedback cycles.\n
\n identify where you struggle: I've put this in to normalize the fact that\n hitting blockers is normal, it is part of doing something new that hasn't\n been done before but also part of learning something new. Very few concepts\n will just reveal themselves on the first look, it takes time and practice to\n understand them. Sharing what you struggle with also provides the opportunity\n for team members to offer help and support; after all they might have had the\n same issue in the past and know how to handle it. It is also important to\n enable the entire team to identify blockers that limit progress and evaluate\n wether to invest into resolving them immediately.\n
\n say thank you: Actionable feedback is the most important input for a team\n to improve and grow. I especially highlight that it's about providing\n feedback on what a person did, this offers them concrete feedback on their\n behaviour and what is perceived as valuable by their team members. This can\n also help them uncover skills they didn't know they posessed or didn't think\n of being valuable.\n

https://twitter.com/marcobahn/status/1337353217592745995

Below is the full README.

README: Office Hours

\n In order to maximize the time for questions please post the questions you have\n in the Teams chat before the office hour. I will answer them following the\n FIFO principle.\n

Status updates

Individual

Each student should provide an individual small status update every\nThursday in Teams:

Describe one interesting thing you learned in the past week.
Upload one screenshot of your week's work progress.
Describe one thing you struggle with.
\n Write a virtual\n Kudo card\n to a team member (you can do this privately if you like).
Here is a template:\n

For:   <Name of your team member>\nFrom:  <Your Name>\n\n       Thank you for <description of what they did>\n       because it <description of how it helped you>\n

Team

\n Each team should provide a written status update every Thursday in\n Teams:\n

\n Describe the goals you were working towards this week and the progress you\n made towards them.\n
Describe the blockers you encounter.
Describe what you plan to work on next week.

\n","slug":"readme-for-apc-students","hero":"!undefined"}],["rebase-and-ideally-squash-instead-of-merge-pull-requests",{"title":"Rebase and ideally Squash instead of Merge Pull Requests","subtitle":"Best practice","abstract":"A pull request should only address one change at a time.","date":"2026-01-02T00:10:00+01:00","html":"\n

\n You should rebase a branch against the main branch before \"merging\" it, so that\n there is no merge commit.\n

\n While some\n consider rebasing to be an act of destroying the true history of a software project,\n I think this is doing actually the opposite.\n

\n What matters in terms of history is that we preserve the time when a set of\n changes became effective for the rest of the team. As long as a change is in an\n isolated branch on which only one developer works on, it cannot produce bugs for\n others (developers or users) thus it did not have the chance yet to make\nhistory so to speak.\n

\n By rebasing a PR against the main branch just before merging it will tell the\n real story: the changes will appear in this branch in the order they became\n active and this accurately reflects the time when others were made aware of\n these changes and also the time from when to entire codebase needed to deal with\n the changes introduced by them.\n

Squash merging

\n Once a PR is done and has been approved, I like to squash all commits into one\n commit with a good and concise explanation. That one commit should ideally look\n like the PR itself: a PR on GitHub has a title and a decription, which explains\n the motivation for the change and lists what needs to be done (simple future).\n Turning this into a commit means telling the story of what the commit now does\n (in present tense).\n

\n I consider squashing a PR into one commit to main an even better way to\n contribute changes to the main branch. I often have man small commits in a PR,\n which add tests, implement features, refactor. Having all these in the main\n branch does not really help other developers to quickly get the high-level\n summary of a change.\n

Cleaning up your commits for a PR

\n This does not mean that all PRs should only have one commit (although\n they rarely should have many)\n it makes reviewing a PR easier if all the commits in a PR are condensed down to\n a set of distinct commit messages, even if they get squashed when being merged\n anyway. See this as an opportunity to describe to the reviewer what you did\n when implementing the change. It also enables a reviewer to view changes in a\n bigger PR with a context specific to a commit.\n

Re-tell the story of your PR

\n Creating a clean set of distinct commits in a PR requires that atomic commits\n were made in the first place. It's a good habit while developing to commit\nearly and commit often: create many small commits, which you then later can\n combine into bigger ones. A great helper to achieve this is using\n git add -p, which will go\n through all current unstaged changes and let you decide which changed segment in\n a file to stage. git add -p allows you to create multiple commits from a\n situation where you have applied different changes while developing (a new\n feature here, but also a bug fix, and maybe some formatting, or changes to the\n CI configuration).\n

\n
\n Tip: when incorporating PR feedback into these commits,\n git-absorb can\n help with that.\n
\n

What if you have unrelated changes in the same commit

\n You might encounter a situation where you accidentally combined unrelated\n changes in one commit. There is a way to split up these commits, but there is no\n reverse version of squash, it has to be done manually. See the Splitting a\ncommit section in the\n official Git documentation.\n Here again, when in rebase, git add -p is your friend.\n

Resources

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
https://dev.to/maxwell_dev/the-git-rebase-introduction-i-wish-id-had
https://gist.github.com/mattlewissf/9958704

\n","slug":"rebase-and-ideally-squash-instead-of-merge-pull-requests","hero":"!undefined"}],["relationen-in-linked-data",{"title":"Relationen in Linked Data","abstract":"Eine Einführung in JSON-LD","date":"2012-01-17T00:00:00.000Z","lang":"de","html":"\n

An englisch translation of this article can be found\nhere.

\n Das Thema Linked Data geistert ja nun schon eine\n Weile durch die Branche, noch hat sich besonders im JSON-Umfeld noch kein\n wirklicher Standard etabliert. JSON-LD versucht dieser\n Standard zu werden und hat auch schon\n sehr ausführlich dessen Syntax\n beschrieben.\n

\n In JSON-LD werden JSON-Daten mit Informationen zum Kontext angereichert, so dass\n der Verwender der Daten erkennen kann, wie diese zu interpretieren sind. Ein\n einfaches Beispiel eines JSON-Datensatzes mit Linked Data-Zusatzinformationen\n sieht so aus:\n

{\n  \"@context\": \"http://purl.org/jsonld/Person\",\n  \"@subject\": \"http://dbpedia.org/resource/John_Lennon\",\n  \"name\": \"John Lennon\",\n  \"birthday\": \"1940-10-09\",\n  \"member\": \"http://dbpedia.org/resource/The_Beatles\"\n}\n

\n Diese Beispiel beschreibt einer Person, deren Name „John Lennon“ ist. Der\n Unterschied zu normalem JSON und JSON-LD ist der, dass dieses Objekt sich\n eindeutig selbst beschreibt und so ohne Mehrdeutigkeit in jeder Anwendung\n verwendet werden kann, die mit @context ein eindeutiger „Namesraum“ angegeben\n wird, der die Bedeutung der Daten beschreibt. Mit @subject ist es dann möglich\n den konkreten Datensatz eindeutig zu identifizieren.\n

\n Die Informationsanreicherung für untergeordnete Elemente, die z.B. als Liste\n vorliegen ist mit JSON-LD\n ebenfalls möglich.\n

\n Soweit, so gut — aber eben für meinen Anwendungsfall nicht ausreichend: Ich\n möchte nicht bei jeder Nachricht alle zugehörigen Objekte mitliefern, sondern\n den Client selber entscheiden lassen, was er benötigt.\n

Verweise definieren

\n Die Spezifiktion geht davon aus, dass eine JSON-Nachricht immer die zu einem\n Objekt gehörenden Kind-Elemente enthält. Sie sieht aber nicht die Möglichkeit\n vor, Verweise zu weiteren Datensätzen zu definieren. Mark Nottingham zeigt\n in seinem Blog-Eintrag\n „Linking in JSON“, dass\n dieses Problem auch in anderen Linked-Data-Ansätzen nicht zufriedenstellend\n gelöst wird, auch wenn es mit\n JSON Reference und\n HAL\n mindestens zwei Ansätze gibt, fehlt beiden jedoch die Möglichkeit den Kontext\n der verknüpften Daten zu definieren, denn Anhand des Kontexts einer Relation\n kann der Verwendern erkennen und entscheiden, ob es für ihn Sinn macht, eine\n Relation weiter zu verfolgen.\n

\n In meiner Anwendung habe ich mich entschieden in der Syntax von JSON-LD zu\n bleiben und ein weiteres Element ein zu führen: @relations. Dieses Element ist\n eine Liste von Relation die zum jeweiligen Objekt gehören. Jede Relation\n beschreibt dabei mit relatedcontext, welchen Kontext das andere Objekt hat und\n unter welcher URL (href) dieses Objekt abgerufen werden kann; mit role wird\n die Art der Beziehung beschrieben. Optional gibt das Attribut list an, ob es\n sich um eine Liste von Objekten handelt.\n

Beispiel: John, mal wieder

\n Im Beispiel verwenden wir wieder John und definieren eine Relation zu seiner\n Frau Yoko Ono, sowie zu den Singles, die er geschrieben hat.\n

{\n  \"@context\": \"http://purl.org/jsonld/Person\",\n  \"@subject\": \"http://dbpedia.org/resource/John_Lennon\",\n  \"@relations\": [\n    {\n      \"@context\": \"http://coderbyheart.de/jsonld/Relation\",\n      \"relatedcontext\": \"http://purl.org/jsonld/Person\",\n      \"role\": \"http://gmpg.org/xfn/11#spouse\",\n      \"href\": \"http://dbpedia.org/page/Yoko_Ono\"\n    },\n    {\n      \"@context\": \"http://coderbyheart.de/jsonld/Relation\",\n      \"relatedcontext\": \"http://dbpedia.org/ontology/Single\",\n      \"role\": \"http://dbpedia.org/ontology/writer\",\n      \"href\": \"http://dbpedia.org/resource/John_Lennon/singles/\",\n      \"list\": True\n    }\n  ],\n  \"name\": \"John Lennon\",\n  \"birthday\": \"1940-10-09\",\n  \"member\": \"http://dbpedia.org/resource/The_Beatles\"\n}\n

\n Dem Verwender kann so mitgeteilt werden, dass wenn er dem (fiktiven) Link\n http://dbpedia.org/resource/John_Lennon/singles/ folgt, er eine Liste von\n Singles erhält, die John geschrieben hat. Es bleibt aber Sache des Verwenders zu\n entscheiden, ob er in seiner Anwendung überhaupt ein Personen-Objekt definiert\n hat, dass Verweise auf Singles enthält.\n

Fazit

\n Der gezeigte Lösungsansatz ermöglicht es, die Menge der übertragenen Daten in\n einer JSON-Nachricht gering zu halten, gleichzeitig bleibt aber die Möglichkeit\n bestehen, zugehörige Objekte erkennen und nachladen zu können.\n

\n","slug":"relationen-in-linked-data","hero":"!undefined"}],["relations-in-linked-data",{"title":"Relations in Linked Data","abstract":"An introduction to JSON-LD","date":"2012-01-17T00:00:00.000Z","html":"\n

This is the translation of this german blog entry.

\n Even if Linked Data has been around for a while a solid standard for a\n JSON driven environment is yet to surface. JSON-LD has set its course to\n becoming this standard and goes great length in explaining their take on\n linked data in JSON.\n

\n In JSON-LD JSON data is enriched with information about its context enabling the\n client to explicitly know how to interpret this data. A simple example of\n JSON-Data with embedded linking information looks like this.:\n

{\n  \"@context\": \"http://purl.org/jsonld/Person\",\n  \"@subject\": \"http://dbpedia.org/resource/John_Lennon\",\n  \"name\": \"John Lennon\",\n  \"birthday\": \"1940-10-09\",\n  \"member\": \"http://dbpedia.org/resource/The_Beatles\"\n}\n

\n This example describes a person named „John Lennon“. By adding a namespace via\n the @context attribute the data becomes self-describing. The @subject\n enables the client to identify an this specific entry.\n

\n It is also possible to describe subsidiary entries of this object which\n could be given e.g. in a list.\n

This is good but not sufficient for my use case.

Defining relations

\n By following this design I have to include all related objects in the JSON\n messages. But I want to let the client decide which subsidiary objects he needs.\n What I really need is the possibility to define relations. In his blog entry\n „Linking in JSON“ Mark Nottingham shows that this need is not addressed\n properly or at all. JSON Reference and HAL do provide solutions but\n they are both lacking a way to define the context of the related objects. Only\n by knowing the context of a relation the client can decide which relation to\n follow and which to discard.\n

\n In my applictaion I’ve decided to stick with the JSON-LD syntax and add\n another property: @relations. This property is a list of relations for the\n object. Every relations describes the context of the related object in\n relatedcontext and states under which URL (href) this object can be fetched.\n The role attribute defines the kind of relation. Optionally the attribute\n list states, if the relation is actually a list of objects.\n

Example: Again, John.

\n In this example we use John again and define a relation to his wife Yoko Ono and\n to the singles he has written.\n

{\n  \"@context\": \"http://purl.org/jsonld/Person\",\n  \"@subject\": \"http://dbpedia.org/resource/John_Lennon\",\n  \"@relations\": [\n    {\n      \"@context\": \"http://coderbyheart.de/jsonld/Relation\",\n      \"relatedcontext\": \"http://purl.org/jsonld/Person\",\n      \"role\": \"http://gmpg.org/xfn/11#spouse\",\n      \"href\": \"http://dbpedia.org/page/Yoko_Ono\"\n    },\n    {\n      \"@context\": \"http://coderbyheart.de/jsonld/Relation\",\n      \"relatedcontext\": \"http://dbpedia.org/ontology/Single\",\n      \"role\": \"http://dbpedia.org/ontology/writer\",\n      \"href\": \"http://dbpedia.org/resource/John_Lennon/singles/\",\n      \"list\": True\n    }\n  ],\n  \"name\": \"John Lennon\",\n  \"birthday\": \"1940-10-09\",\n  \"member\": \"http://dbpedia.org/resource/The_Beatles\"\n}\n

\n In this way the client can be told that if he follows the (fictive) link\n http://dbpedia.org/resource/John_Lennon/singles/ he’ll receive a list of\n Singles written by John. It’s up to the client to decide a person object\n exists in his application with a relation to singles.\n

Conclusion

\n The solution presented above enables us to transfer just the minimum amount of\n required data but still gives the client the possibility to discover and fetch\n related objects.\n

\n","slug":"relations-in-linked-data","hero":"!undefined"}],["rest-in-practice-reading-guide",{"subtitle":"Book review","title":"REST in Practice - a reading guide","abstract":"While the book was published in 2010 and some of its contents have not aged well, it still provides a lot of things to learn. In this post I will give my recommendations on which sections are a must read, and which ones can be skipped in case you are-like me-not very fond of Java and XML.","date":"2022-07-16T16:00:00.000Z","html":"\n

\n It has been a while, probably more than 10 years, since I first read\n REST in Practice and it greatly influenced the\n way I design web application backends. It gave me a universal toolkit (HTTP) to\n build decoupled microservice architectures, and I am convinced that I even today\n many of the learnings I got from reading the book for the first time.\n

\n For this reason I also highly recommend this book\n (amongst others)\n as a must read in my talks and to whomever asks for a book recommendation on\n software architecture.\n

\n Since this year I am in the lucky situation to grow my team that and having\n recently hired a Junior engineer, REST in Practice is one of the first books I\n ordered.\n

\n This is a good opportunity to give it a second read, and review it from the\n point of view of a team that develops software using serverless technologies, in\n TypeScript on Node.js and provide a reading guide for them that helps to\n navigate some of the outdated sections. I will also highlight especially\n important chapters.\n

Still highly relevant

\n Overall, the sentiment of the book still holds very true today. We need to build\n resilient, decoupled systems that can handle unpredictable load patterns. The\n book does a very good job of showing how all of this can be achieved with a\n ubiquitous communication protocol: HTTP. This principle is truly language- and\n platform-neutral which makes it so universally applicable.\n

Reading guide

This is my recommended reading guide for the book:

\n Chapter 12 - Building the Case for the Web (p. 407):
this is the tl;dr of the book, and it gives a good summary of why the\n techniques explained in the book work so well.\n
Chapter 1 - The Web As a Platform for Building Distributed Systems:
read fully
Chapter 2 - Introducing Restbucks: How to GET a Coffee, Web Style:
read fully
Chapter 3 - Basic Web Integration:
skip URI tunneling and POX (p. 37-55)
\n Chapter 4 - CRUD Web Services:
read fully, important chapter on how to properly employ HTTP for building\n APIs\n
\n Chapter 5 - Hypermedia Services:
read full! This is also an important chapter on how to make services\n discoverable. While the use of XML is quite clunky for a Node.js developer,\n it does not get too much in the way of the content that explains the main\n idea. After this chapter we could have a look at\n JSON-LD.\n
\n Chapter 6 - Scaling Out:
ready fully, important chapter on the usefulness of caching and how to use\n cached response to reduce latency and infrastructure costs.\n
\n Chapter 7 - The Atom Syndication Format:
good explanation of how to decouple microservices and allow consuming\n services to observe changes. Skip the Java implementation part (p.207-234).\n Missing in this chapter is a push notification capability. The communication\n relies on consumers to poll for changes, and this is very inefficient.\n Microservices should publish events in a way that allows consumers to react\n to these changes when they happen, but only IF they happen. This is possible\n in HTTP with websockets and should be discussed after reading this chapter.\n
\n Chapter 8 - Atom Publishing Protocol:
read, but skip the implementation guide (p. 269-283). It's a lot of XML\n that's thrown at the reader but the underlying idea is still worth exploring:\n we want a language-independent way to describe which actions a service\n provides. The authors pick AtomPub as a general purpose syntax. After this\n chapter we could have a look at\n Hydra or\n Apache Thrift.\n
\n Chapter 9 - Web Security:
read, but skip the OpenID and OAuth part (p. 295-339) because they are often\n not relevant in machine-to-machine scenarios. The first and the last pages of\n the chapter however are a good refresher on HTTP security essentials.\n
\n Chapter 10 - Semantics:
Optional. Be aware that the solutions proposed are quite outdated, but we\n face the main question today nevertheless: How can we build a ubiquitous\n languages into our systems that transcends the boundaries of our business. I\n haven't seen this to be really relevant in my day to day job.\n
\n Chapter 11 - The Web and and WS-*:
Skip. This is a discussion around specific technologies which is only\n relevant to people who use them; which we are not.\n

\n","slug":"rest-in-practice-reading-guide","hero":"!undefined"}],["rheinmainrocks-sticker",{"title":"#RheinMainRocks sticker","abstract":"You can now stick #RheinMainRocks where you like!\n","date":"2015-05-22T23:00:00.000Z","html":"\n

\n Here they are: the totally inofficial\n #RheinMainRocks\n sticker.\n

\n Back in March I started the project over on\n community.rheinmainrocks.de\n and after a\n design contest,\n a longish startnext campaign\n for which I even had to record\n a video.\n

\n They'll start showing up in the RheinMain area in the coming days. Our awesome\n backers will receive them on the\n Google I/O extended\n in May and the\n WMFRA in June\n accompanied by a little gift I was able to add to the package because …\n #RheinMainRocks!\n

The sticker

\n There is a\n flickr album\n which shows them in all their glory.\n

\n The backers will receive a complimentary sheet with a different color version\n and smaller versions.\n

For instance, the smaller version can be used to cover your camera:

Happy sticking!

\n","slug":"rheinmainrocks-sticker","hero":"!undefined"}],["rotate-screen-in-linux",{"title":"Rotate screen in Linux","abstract":"Sometimes it can be useful to rotate a screen, e.g. to have one display in portrait. This command will rotate your screen:\n","date":"2016-04-19T00:00:00.000Z","html":"\n

\n Sometimes it can be useful to rotate a screen, e.g. to have one display in\n portrait. This command will rotate your screen:\n

# find the name of your actual output (in this example DVI-I-3) with this command\nxrandr --listmonitors\n# Apply rotation\nxrandr --output DVI-I-3 --rotate left\n

\n","slug":"rotate-screen-in-linux","hero":"!undefined"}],["schneller-syntax-check-fur-modifizierte-php-dateien",{"title":"Schneller Syntax-Check für modifizierte PHP-Dateien","abstract":"Ja, manchmal muss man halt via SSH auf Maschinen rumhacken, auf denen es kein vernünftiges Error-Reporting gibt. Und wenn dann die Seite weiß bleibt, hilft dieses Kommando, um heraus zur finden, welche der Dateien man zerschossen hat:","date":"2011-01-20T00:00:00.000Z","lang":"de","html":"\n

\n Ja, manchmal muss man halt via SSH auf Maschinen rumhacken, auf denen es kein\n vernünftiges Error-Reporting gibt. Und wenn dann die Seite weiß bleibt, hilft\n dieses Kommando, um heraus zur finden, welche der Dateien man zerschossen hat:\n

svn status | grep \"\\.php$\" | grep \"^M\" | awk '{ print $2; }' | xargs -i php -l {}

\n Das svn status am Anfang verrät schon, zumindest über eine SVN working copy zu\n verfügen ist dabei äußerst hilfreich.\n

Die Alternative dazu, ohne SVN ist

find ./ -type f -name \"*.php\" | xargs -i php -l {}

was aber natürlich sehr viel langsamer ist.

\n","slug":"schneller-syntax-check-fur-modifizierte-php-dateien","hero":"!undefined"}],["separate-workflows-through-events",{"title":"Separate workflows through events","subtitle":"Best practice","abstract":"Build scalable systems by separating concerns.","date":"2026-01-02T21:05:00+01:00","html":"\n

Build scalable systems by separating concerns.

Bad

class UserManager {\n  async createUser(email) {\n    const id = await this.userRepo.insert(email);\n    await this.upgradeAccount(id, \"trial\");\n    await this.sendConfirmationEmail(email);\n    await this.notifySlack(`Woot! ${email} has registered`);\n  }\n}\n

\n The UserManager does too many things and needs to know all these dependencies.\n There is no clear limit to what could be added there in the future, that needs\n to be done when a user is created. This can increase the runtime of this one\n method further and further and couples systems that not need to be coupled.\n

Good

\n Instead have all methods that change the state of the system only do exactly on\n operation and use Events to have other components get notified. This enables to\n run these secondary operations in a separate process and even in an environment\n which is better suited for them.\n

class UserManager {\n  async createUser(email) {\n    const id = await this.userRepo.insert(email);\n    this.eventBus.publish(\"UserCreatedEvent\", { id, email });\n  }\n}\n\nclass TransactionalMailer {\n  construct(eventBus) {\n    eventBus.on(\"UserCreated\", (name, { email }) =>\n      this.sendConfirmationEmail(email),\n    );\n  }\n}\n

This is enabled by implementing the system using Event Sourcing.

\n","slug":"separate-workflows-through-events","hero":"!undefined"}],["serverless-architecture-for-iot-on-aws-talk-ntnu",{"subtitle":"Talk","title":"Serverless Architecture for IoT on AWS","abstract":"An NTNU guest lecture on serverless and IoT and why they are a great match.","date":"2022-02-23T20:00:00.000Z","html":"\n

\n If you have 1,5 hours to spend, you can watch a recording of the guest lecture I\n gave today at NTNU in the course IDG2001 - cloud technologies about serverless\n for IoT, and have a look at the code I work with at the end, where I give a\n walkthrough of a concrete example.\n

https://www.youtube.com/embed/E7t6BXGIZHk

\n","slug":"serverless-architecture-for-iot-on-aws-talk-ntnu","hero":"!undefined"}],["serverless-development-on-aws-review",{"title":"Serverless Development on AWS","subtitle":"Book Review","abstract":"Great book for devs & managers: serverless intro & potential!","date":"2024-05-10T18:45:00+02:00","html":"\n

\n I can fully recommend the book for developers who are starting to work more with\n serverless but as well for technical managers who want a better understanding of\n the potential of the serverless paradigm and the mindset shift needed to tap its\n full potential. It’s a must read for every developer that works with AWS because\n more and more powerful services on AWS are built from the ground up as\n serverless offering. Making the most of them will be a skill that takes time to\n master, and this book will provide you with many well explained shortcuts.\n

\n For a more seasoned serverless engineer the book is still valuable, especially\n since you want it in your bookshelf to give to colleagues. Especially chapter 2\n (“Enterprise Readiness for Serverless”) is a great resource that discusses the\n value of serverless as an innovation and value creation enabler which is\n supported by a great interview with\n David Anderson.\n

\n This chapter also discusses the serverless mindset, which is a distinctly\n different approach to architecting solutions compared to instance-based\n architectures. Adopting this mindset is both hard to achieve and complicated, so\n this chapter does a great job of highlighting the different aspects that\n serverless solution designers need to conquer.\n

\n The highlight of the book is certainly the third one (“Software Architecture for\n building serverless microservices”) which does a very good job of explaining how\n to design efficient serverless architectures and the important role events are\n playing. If you are familiar with event-based systems this might not surprise\n you: after all, serverless works well if all services are loosely coupled and\n all efficient architectures are designed with this in mind. This is a good\n reminder to check out my reading guide of\n REST in Practice,\n which still applies to these kinds of architectures.\n

\n The implementation of these architectural concepts is then described in chapter\n five (“Serverless implementation patterns”) and I really liked that they\n invested a good portion of it to describe strategies on how to deal with\n third-party services … because the reality is that not everything runs smoothly\n within AWS. In my day to day job, nearly every feature deals with some kind of\n third party API. Dealing with those APIs failing gracefully is an important\n aspect of any implementation. The chapter provides good examples of how to\n actually solve this.\n

\n In this and the following chapter seven (“Implementing serverless applications”)\n we find good tips on structuring and deploying applications and how to use the\n serverless platform as an event flow engine so the code you write can focus on\n implementing the business domain logic.\n

\n
\n It’s an important learning that utilizing flow control features like EventBus\n and StepFunctions will yield better observability and unlock resilience\n features like automated retries that otherwise would need to be implemented in\n software.\n
\n

\n Of course, chapter 7 (“Testing serverless applications”) was a must read for me,\n given that\n I have spoken extensively about my approach\n on conferences. The chapter explains very well the compromises that have to be\n made when testing a serverless architecture. The promoted approach is: unit-test\n your business logic implementation, and add end-to-end tests for the\n business-critical paths. This way you ensure that the implementation is correct\n and the solution once deployed does what it is supposed to do. This aligns very\n well with my experience, so it was nice to read in the chapter’s interview with\n Sarah Hamilton how an expert\n approaches this topic.\n

\n Don’t skip chapter 8 (“Operating serverless”) because it provides a good\n introduction to monitoring serverless solutions and shows that it’s quite easy\n to get started with building monitoring for your solutions.\n

\n Overall I really liked the interviews that conclude every chapter, because they\n add more flesh to the sometimes very technical concepts discussed in the\n chapters and help to support what was discussed in the preceding chapters.\n

\n You can buy “Serverless Development on AWS”\n on Amazon.\n

\n","slug":"serverless-development-on-aws-review","hero":"!undefined"}],["serverless-on-aws",{"title":"Building serverless applications on AWS","subtitle":"Learning Resources","abstract":"This is the material I share with colleagues who want to learn the idiomatic way of building serverless applications on AWS","date":"2025-03-23T10:00:00+01:00","html":"\n

\n I've been building serverless applications on AWS for over ten years. I was\n immediately hooked when\n AWS Lambda was launched in 2014\n and have been using it as the main way to build web services using JavaScript,\n and later TypeScript ever since.\n

\n For developers who come from classic, instance-based architectures, working with\n serverless is a huge paradigm shift. It's not natural, nor obvious. In this blog\n post I am sharing the current set of material I give to colleagues who want to\n learn the idiomatic way of building serverless.\n

The basics

\n There are some fundamentals when building scalable web services, which apply\n both in instance-based and serverless architectures.\n

\n REST in practice is a\n must read.\n

\n The Twelve-Factor App provides important design aspects\n for web services in general, but this applies very well to serverless\n applications.\n

\n In my talk\n Serverless Architecture for IoT on AWS I\n explains the benefits of serverless in general in why it is especially suitable\n for IoT applications. I provide an introduction to serverless in general, and\n how it is implemented at the different cloud vendors (looking at AWS and Azure,\n where I have implemented the same application using the respective cloud's\n idiomatic way), and why it is especially relevant for IoT deployments.\n

Learning AWS serverless

Of course, always check the official AWS resources on AWS Lambda:

\n For training my colleagues I have used the\n AWS Dev Hour: Building Modern Applications\n training, with the added challenge of writing tests for it. My colleague Lena\n Kråkevik Haraldseid has a talk about her learnings from this exercise:\n Testing serverless applications.\n

\n The recently released book\n Serverless Development on AWS\n offers a great way to learn more about the potential of the serverless paradigm\n and the mindset shift needed to tap its full potential. It’s a must read for\n every developer that works with AWS because more and more powerful services on\n AWS are built from the ground up as serverless offering.\n

Testing

\n One of the challenges when building serverless applications is testing. You are\n building on the shoulder of giants, and are using services that no longer run on\n your (CI) machine. In my talk\n It does not run on my machine: Integration testing a cloud-native application\n I take you through the challenge of testing a cloud-native application. I cover\n the challenges when developing solutions on top of serverless components which\n you cannot run on your own machine and how I designed a BDD driven approach to\n run the integration tests.\n

\n Here is AWS' best practice on testing Lambda:\n How to test serverless functions and applications.\n

Reference projects I have built

\n It's always best to look at actual code, so these are the open-source projects\n that are available which I have worked on:\n

\n","slug":"serverless-on-aws","hero":"!undefined"}],["setting-up-a-product-management-process",{"title":"Setting up a product management process","subtitle":"MVPs in Production","abstract":"In this post I will explain the way I design the process that supports one key operation in every startup: improving the technology which delivers value to customers—or should, if you are working towards signing your first customer.","date":"2017-06-22T17:00+02:00","html":"\n

This post is part of the MVPs in Production series. Be sure to make\nyourself familiar with the context I've set\nin the introduction.

\n In this post I will explain the way I design the process that supports one key\n operation in every startup: improving the technology which delivers value to\n customers—or should, if you are working towards signing your first customer.\n

\n The driving principles are two opposing needs: maximizing uninterrupted time and\n agility. Developers would love to work uninterrupted for days and weeks, and\n business stakeholders need to get as many things done as possible, ideally right\n now and at the same time. In a startup nothing can be planned so we are charged\n with the impossible situation of building new features as fast as possible,\n which takes preparation and excellence to get it right, and at the same time\n leaving enough wiggle room to quickly change focus or incorporate last-minute\n changes.\n

\n You could as well call this an insane situation, trying to achieve both. Being\n presented with this as a reality I could not change, I tried to find a balance.\n When you are joining a startup your are submitting yourself to a lot of external\n stimulus with extreme leverage and you are usually schlepping your company from\n week to week. No amount of experience, and world class team members, and\n disruptive ideas can change this.\n

Decouple the Sprint from the Release

\n Being a product team that builds web based products means that your product\n could potentially fail all the time. And you can’t wait to fix bugs until you’ve\n reached the next release day. Bugs have to be fixed immediately, if they are\n significant that is, of course. A bug that affects potentially all users like a\n logical error or one that corrupts data must be fixed immediately. A browser bug\n that makes a button unclickable for 10% of your users should be fixed within one\n business day¹. In any case, you will be fixing bugs every other day,\n and a bugfix means: releasing a new version.\n

\n Everybody that changes code, should be able to release a new version, and\n observe how the feature or fix they’ve just released behaves when it’s used by\n real users. And this is especially true for feature releases. In the last five\n years I have never seen the case where a new feature was thoroughly reviewed by\n the story owner because for the fact that it’s really hard to get hold of domain\n experts when you need them … But you can turn this to your advantage, liberate\n yourself from the “review” step by the story owner and let your customers have a\n go at a new feature. Their behaviour will tell you if a feature works or needs\n more work. There are techniques to limit the blast radius if something goes\n wrong, which I’ll talk about in another chapter.\n

\n Since the developers own the operation of their features and they are the only\n ones that can judge if a feature is ready to deploy or a bug is fixed, it would\n be counter-productive to release only at the end of every sprint. This only\n creates more opportunity for incompatible changes and merge hell. Also since\n they have just build the feature it’s easy to recollect where to look if\n something does not work as expected.\n

\n Bug fixing and feature development exist at the same time, and I found this to\n create a good balance on a day to day basis. I would work on one big feature in\n a branch, and once I’ve reached a certain milestone in a feature (or savepoint,\n where I would rebase and force push my feature branch) I could take my mind off\n for some hours, fix bugs, do housekeeping tasks and release a new version of\n master to production. All this also ensures that changes are released when they\n are ready, at the best time, and not when they are scheduled. In my experience\n having a release date will create a goal that demands to be met, and shortcuts\n will be taken “Just commit this one last fix before the sprint review… Oops!”).\n Let’s be honest to what we’ve learned: only one thing is certain when building\n software, especially one that has never been built before: all attempts to pick\n a done-date are futile and these dates are dead Schrödinger’s cats: as long as\n you don’t open the box they are still dead, but they don’t smell.\n

\n ¹ And the obscure IE bug which affects less than 3% of your\n users, can be safely ignored, until you really have nothing better to do, or\n these users switch to a different browser. It’s important to understand how\n excluding a certain amount of users translate into lost revenue and making an\n educated decision whether fixing that bug has a return on invest.\n

Stories, not Issues

\n For managing the things to be done I repeatedly had success using the\n Kanban-inspired Trello. I personally don’t believe in using issue trackers like\n GitHub issues, Jira, Redmine, etc to drive the implementation of a story. A card\n in trello provides content in a format that is accessible and understandable by\n anyone in the team but provides additional features like Checklist, linking\n Commits etc. that help to keep track of the implementation work for that\n feature.\n

\n Features that should be implemented are added to the Backlog board and contain a\n description that explains the user goals for this feature, and provides\n additional background information like wireframes and links to other concept\n work. Since Trello is not able to handle collaboration on a card’s description,\n I prefer to use Google Docs for writing concept documents. It’s live editing\n feature is superior to anything else I’ve used and combined with the commenting\n / note feature it’s the best tool to write concept documents and even sketch\n pseudo code.\n

\n Stories are organized in Topics: I have no clear rule for what makes a good\n topic, just that a natural clustering for Stories will automatically emerge. I\n typically have a Topic per product, for the website, for marketing. Because some\n Topics can create an endless stream of new stories, these could easily create\n the impression that they are more important. But it’s necessary to visualize\n that each topic has it’s purpose and having stories that are never making it\n into the Sprint is easier understood, if they are constantly on top of their\n Topic list.\n

\n Since we are using an approach inspired by Kanban, the most important Stories\n must be at the top of each Topic list. Typically I have a dedicated Owner per\n Topic who is in charge of prioritizing the stories within their Topic by\n sourcing information from customers and other stakeholders. This role can be\n filled by any team member, that understands the Topic matter and has the\n resources to do it. This not only distributes the workload of this task between\n more team members but actually gives every Topic an individual advocate. This is\n not optimal, though. I have worked in startups where we didn’t have a dedicated\n Product Manager—which I believe to be one of the biggest mistakes any startup\n can do—but owning a Topic means you have to constantly reevaluate existing\n Stories and review new Stories, which takes time and requires commitment, which\n can be hard to find in startups where everyone is already doing more then they\n should. So, get a dedicated Product Manager!\n

\n The Backlog board is very busy and tends to accumulate stale stories. Usually\n the outflow of Stories from the Backlog to the Sprint is far smaller than the\n inflow of new Stories to the Backlog. Stale stories are those that are\n constantly prioritized lower than newer and more important ones. Over time\n grooming the Backlog takes more and more time because you have to revisit more\n stories and check if they are still valid, if preconditions have changed or new\n preconditions have emerged.\n

\n Try to not use it as a scratch board for personal ideas. Stories that make it to\n the board should at least have a clear purpose and more important a clear value\n proposition attached: if we do X how will that affect our revenue²?\n As a Topic Owner look out for one-liners, nice-to-haves and use labels to mark\n these and follow up with the story owners to fill in the blanks. If they can’t,\n do not hesitate to remove these stories, because they are either unimportant or\n if not, will resurface at a later point in time. The biggest rule here is:\n listen to your users! A story is off to a bad start if it’s born out of a “I\n think we need X!” … your feature will be so much better if you work with a\n “Customer A said the would pay B for feature C”. If a story is missing a real\n customer (A), a letter of intent (B), or a clear user story (C), invest time in\n getting them!\n

\n I encourage Topic Owners to have a separate Backlog board of their personal\n planning. This way they can collect ideas and organize them in a way that allows\n more freedom and is more germane to their preferred work style. They would then\n move Stories they want to be implemented next into the Backlog board.\n

\n ² John Cutler has a\n great set of questions\n to consider.\n

The Sprint Planning

\n Work on the Backlog is ongoing and happens every day. Having some kind of\n structure on the other hand is important, especially since coordinating\n calendars in startups is so complicated that the only way to fight this flea\n circus is to find a regular slot for planning meetings and stick to them no\n matter what. It’s essential for everyone involved in building the product to\n sync up once a while—in my experience, no tool is able to completely eliminate\n synchronous meetings.\n

\n The Sprint Planning is one of two meetings that I establish during a two week\n Sprint Cycle. It usually happens on a Monday, after the Weekly. In this meeting\n the team decides which of the stories with the highest priority from each Topic\n will be taken to the Sprint. If the Backlog Board is well maintained, this\n meeting can be done swiftly: in preparation we would take the the stories with\n the highest priority from each topic to the Sprint Planning column and arrange\n them again in order of priority. At this point we would also discuss—given the\n expected capacity of the next two weeks—which of those stories we feel confident\n in building.\n

\n And two weeks is just the horizon I feel comfortable predicting. Four weeks is\n ages and given that most stories are really hard to estimate because most of the\n features you are building are so experimental and unique that it is nearly\n impossible to draw conclusions on story size from previous ones. One week on the\n other hand is too short to really get stuff done because for any given week\n there may be just one or two days where you can manage to focus on one task for\n half a day.\n

\n A two week cycle also provides a great opportunity for the Backlog Grooming\n every other week, which is the second meeting of the Sprint Cycle, during which\n the Topic Owners and me would go through the story candidates for the next\n sprint and look for conflicts and missing information that would block them from\n going into the next sprint.\n

\n This meeting also provides a good opportunity to introduce new, important\n stories which need to be put on the fast lane, essentially trumping all other\n stories that are up next. This happens quite often and therefore it’s always\n good to have everybody aware about what features are in the pipeline and will be\n delayed if they are put on hold for another sprint. Solving these kinds of\n conflicts can’t be done through a tool (e.g. voting in Trello) but can only be\n coordinated in a synchronous meeting. Doing this dance every week, in the Spring\n Planning and in the Backlog Grooming, will keep everyone’s understanding of the\n progress of the product development fresh and reduce discussions to a minimum.\n

\n If you have every tried finding a lunch date for five people, try rescheduling\n that date: impossible. That’s why you stick to the meeting schedule, no matter\n what. You start the meeting on point and everyone receives the meeting notes\n afterwards³. Preparation is key and if the backlog board is managed\n well, the result of the sprint planning won’t be a surprise.\n

\n ³\n Pre-written meetings notes can help you so much with that.\n

The Sprint

\n After the Sprint Planning the stories that made it into the Sprint are moved to\n the Sprint Board’s To Do list⁴. The owner of the Sprint Board is the\n development team and only they move cards around there. It also serves as a\n history record of the features that have been implemented. A story moves from\n the To Do list to the Doing list once developers start implementing it. When\n they deploy it to production, the card moves to Live. Live means “It’s public\n but still needs some work”, this happens for so features which start as\n experiments and are getting polished while (some) of your real users use it and\n provide feedback. Here again is where Trello really shines as a tool for product\n management: the discussion feature and the check lists are great for keeping\n track of the progress of each story.\n

\n The Sprint board is also used to track bugs, which don’t follow the typical\n lifecycle of a story. Each of them is represented by a dedicated card in Trello\n but giving them a distinct label (I chose a red “Bug” one) makes them easy to\n find or filter out. Bugs don’t require the same exhaustive description like\n Stories do, because they are usually self-explanatory: A bug is when a feature\n does not behave as defined—which also means: it’s not a bug if it’s not defined.\n Bug cards trump every other card in the To Do list and move quickly from there\n to Done. They should not hang around in the To Do column for more than a day.\n

\n Once a story or bug is done—the definition of that highly depends on your\n individual requirements, but must be defined in a living document\n nevertheless—it’s moved to the Done list for the current month. Using this gives\n you nice history of the things that happened and the monthly grouping makes it\n easy to recollect and find features to revisit them later, when you are\n reviewing how accurate the assumptions about the expected outcome were that you\n made when describing the Story. This is also the time to document the final\n implementation of the story by updating the description and providing a detailed\n explanation of how the end result behaves and looks like (the use of screen\n recordings here greatly helps to easily understand what changed).\n

\n ⁴ Butler for Trello can help\n with that.\n

What’s a release?

… when you deploy to production every day?
… when your product is composed of microservices?
… when you had a feature for weeks for a selected group of users?

\n It’s the point in time when you decide to activate a feature for all your users.\n As mentioned earlier, the software release cycle is decoupled from the product\n management process. There is no need to orchestrate them but will just create\n more unnecessary coupling between collaborators who can perfectly work in their\n own pace.\n

\n The release of a feature is announced on the Story card and this is observable\n by anyone interested (who did subscribe to the card) and you would also post a\n message on the related Slack channels.\n

It’s a team effort

\n This way of managing a product allows everyone to get involved in the product\n development and the progress becomes observable and transparent without taking\n up too much time. It’s flexible and fosters a strong degree of self-organization\n within the whole team. Having one source of truth for everyone is a key factor\n in keeping everyone in the loop.\n

\n This was part one of the MVPs in Production post\n series. A big thank you goes out to\n Sebastian Nell,\n Ralf D. Müller and Sven Kloppenburg for taking\n the time to review this post and for providing great feedback and\n thoughts!\n

\n Want to read more? In order to unlock the next chapter, I want 10\n additional readers to sign up for my influencer group for this series before I\n start the second post, and you'll get to pick which one I'll continue with!\n Fill out this form and make your choice!\n

\n","slug":"setting-up-a-product-management-process","hero":"!undefined"}],["six-months-into-my-job-as-the-cto-at-fintura-I-quit",{"title":"Six months into my job as the CTO at Fintura I quit","abstract":"Half a year full of lessons.\n","date":"2016-01-19T16:00:00.000Z","html":"\n

\n Mid-October I handed in my resignation which put and end to one of the most\n miserable work experiences I had in my entire career. If you read through the\n post that\n I've written after the first month working there\n you will find me struggling with explaining my idea and values. One of the\n decisive factors was that I could not find support for my vision\n of what makes a great place to work.\n

\n But in every bad experience there are still things to learn. In no particular\n order, these were:\n

culture: I only want to work with a CEO that I have genuine sympathy for
\n values: I need to put more effort into making sure that our goals align (go\n read The Big Five for Life) and happiness (or\n joy is a core value)\n
freedom: I work remotely from day one

\n Still today I'm struggling with the experiences I made last year. I lost a fair\n share of trust in people but gained a lot of confidence that the way I lead is\n very well received. I cannot but look forward to the next twelve months.\n

\n","slug":"six-months-into-my-job-as-the-cto-at-fintura-I-quit","hero":"!undefined"}],["social-media-account-takeover-guidelines",{"subtitle":"Social Media account Takeovers","title":"Guidelines to ensure a safe experience","abstract":"This document provides a code of conduct for these account Takeovers in order to enable the employee, the social media team, and the followers to have meaningful and positive interactions.","date":"2022-07-19T10:00:00.000Z","html":"\n

\n A women student from my team did an Instagram takeover last week and shared an\n insight into her working day as a student in my team. Of course, there were\n dudes who had to send her inappropriate comments. While she had done Instagram\n takeovers previously on other accounts, they all were positive, but, no\n surprise, these accounts are focusing on inspiring girls and women about a\n career in tech, so the audience on those accounts is much different than on a\n tech companies social media account. It's my fault that I didn't foresee this\n and that she was exposed to inappropriate comments that made her feel\n uncomfortable. To not repeat the same mistake twice, I wrote down my\n recommendations for running Social Media account Takeovers in a way that ensures\n a safe experience for the employee below.\n

Individuals as company advocates

\n Social Media account Takeovers are a gray area because here the individual\n employee becomes part of a corporate communication strategy and the company on\n the one hand is much more resilient to negative experiences compared to the\n individual. Therefore it is the responsibility of the company to ensure that the\n employee is protected against negative experiences as much as possible.\n

\n This document provides a code of conduct for these account Takeovers in order to\n enable the employee, the social media team, and the followers to have meaningful\n and positive interactions during and after a Takeover.\n

What are Account Takeovers?

\n So called “Account Takeovers” are a way for companies to give a more personal\n look into the day to day work at the organization. An employee is responsible\n for posting updates on the social media account for a day. This is an effective\n tool for companies to engage with a diverse audience and provide content that is\n more natural to the audience and not the usual streamlined marketing content.\n

\n For employees this provides the opportunity to provide an in-depth insight into\n their daily work which often can be very obscure and therefore attract people to\n apply for open jobs or engage with the specific product the employee is working\n with in order to provide more detailed feedback.\n

\n In both cases the point is to put an individual employee in the center of the\n attention during the takeover. This however opens them up to receive unwanted\n attention in the form of inappropriate or harassing questions and personal\n messages, especially when it’s people from under-indexed groups that are being\n put in the spotlight.\n

\n The employee might not be experienced in ways to protect themselves against\n these comments or—because they are representing the company—may be inclined to\n interact with harassers to keep “good appearances” because “the customer is\n always right”.\n

For the social media team

\n Assume that the employee doing the takeover has no or very limited experience\n handling social media interactions on an account with a large number of\n followers. Therefore you must ensure that they are protected against\n unwanted, inappropriate or harassing comments or questions.\n
\n Share a Code of Conduct before the Takeover:
“In order to have a wonderful experience together, please keep your\n questions, comments and interactions professional. Do not comment or ask\n about personal appearances, relationship status or similar private details.\n This is not a dating site.”\n
\n Moderate all interactions: do not let the employee receive messages\n unfiltered by giving them direct access to the social media account. Have an\n experienced social media manager screen all questions and forward only\n appropriate ones via the company's chat app. For example on Instagram, the\n employee then can use their Instagram app to provide the story via a private\n message to the company account.\n
\n If a users posts an inappropriate question, reprimand them immediately with a\n clear message:
“Hei, your comment is inappropriate and hurtful and adds to making tech a\n place that is exclusive and hostile. We will not answer these kinds of\n questions. Stop it.”\n
\n If they repeat their inappropriate actions, block them without further\n comment.\n
\n Make sure the employee does not share their private Instagram account\n details. Do not ask the employee to do so.\n

For the person doing the Takeover

\n It is fantastic that you have decided to lend your face and personality to your\n organization. It is a gift and its value cannot be measured monetarily. Here are\n few rules to help you make this an amazing experience:\n

\n You do not need to answer questions that you are not comfortable with. If\n some questions make you comfortable please let the social media team know so\n they can filter out these types of questions.\n
\n Do not share your personal social media account unless you personally want\n to. Your employer’s social media team will not ask you to do so. If you do\n nevertheless, feel free to ignore and block unwanted users without\n explanation. This is your personal space. You do not owe these users\n anything.\n
\n Please be aware that all content you provide will end up on the internet\n beyond the control of your organization. Share only what you are comfortable\n with being accessible to a wide audience forever.\n

For the audience

\n As a participant you too need to be involved in making takeovers a fun\n experience for everyone. Ask questions about the business, or the workday of the\n employee. Just see this as an opportunity to get to know an interesting company\n and a future colleague a bit better. Simply do not try to get in their pants.\n Social Media accounts of companies are not a dating platform, and any unwanted\n attention without consent is inappropriate here digitally, as it is at the\n workplace.\n

\n","slug":"social-media-account-takeover-guidelines","hero":"!undefined"}],["socrates-2018",{"title":"SoCraTes 2018","subtitle":"Magic, Diversified","abstract":"After a year of absence, I went back to Soltau for SoCraTes 2018 and discovered that the best conference ever got even better—thanks to fantastic diversity efforts.","date":"2018-09-01T15:00+02:00","html":"\n

When I left SoCraTes 2018 this year I was as energized as the years before:

https://twitter.coderbyheart.com/status/1033960643307687936

\n I have blogged about my experiences before,\n I called it Magic. It's magic because it is a place where I get to meet\n friends I have known for years, and we all arrive with the strong urge to learn\n from each other to be a better human in tech, in an open-space setting where\n everybody can be a teacher, and a student—at the same time.\n

\n This is so entirely different compare to regular conferences, because nobody is\n put on a stage. There is no stage, no list of speakers. We are all equals and\n those with many years of experience working in our industry know not to use\n experience as an excuse to not listen.\n

\n But this is not really news and upon reflecting I think I witnessed a very\n important change for the first time. This year I noticed that session related to\n diversity were proposed by members of underprivileged groups and it happened\n with a level of naturalness which made it evident that SoCraTes has become a\n safe-space for everyone. Big Kudos to the organizers who have been pushing to be\n more inclusive for many years now.\n

\n I cannot stress enough how important this is for me, to be invited to join a\n session where women shared their experience with sexual harassment. It provides\n a view to what I need to look out for, in my own behavior and this of my\n coworkers which I would not otherwise.\n

https://twitter.coderbyheart.com/status/1033960647158050818

\n I invite you to join our community and make it even more diverse:\n https://www.softwarecrafters.org/\n

\n","slug":"socrates-2018","hero":"!undefined"}],["socrates-2022-be-prepared-to-be-challenged",{"title":"SoCraTes 2022","subtitle":"Be prepared to be challenged","abstract":"The unconference, re-invented for inclusiveness.","date":"2022-09-01T23:00+02:00","html":"\n

\n 1,096 days had passed since the previous SoCraTes in 2019. Because of the\n COVID-19 pandemic, there was not SoCraTes in Soltau in 2020 and 2021. Therefore\n this year was especially exciting for me to return Soltau to isolate for a long\n weekend to meet with fellow Software Crafters at\n the 10th\n International Software Craft and Testing Conference\n to share about our experience working in teams that build software.\n

\n Having been a sponsor in previous years, I did have the pleasure this year to\n extend my budget allocation which allowed a total of eight colleagues from\n Nordic Semiconductor\n to attend a SoCraTes, six of them for the first time!\n

\n From top left to bottom right: Lena Kråkevik Haraldseid,\n Jørgen Kvalvaag,\n Maximilian Deubel,\n Vassilis Papanikolaou,\n Mauro López Jiménez,\n Marko Schulz,\n Balaji Srinivasan, and\n me.\n

The unconference, re-invented for inclusiveness

\n The previous years had shown that since the \"introduction\" of the lottery system\n a large portion of the attendees were first-timers and attendees who haven't\n been part of the community as long as people like me.\n I have written previously, why I\n think this is a necessary and fantastic feat of this unconference. SoCraTes has\n shown year after year to be an inclusive and welcoming space to for sharing and\n learning, and it is by word of mouth and through the many interactions on\n Twitter and via Software Craft user groups that keeps the circle of software\n crafters growing in Europe and beyond.\n

\n This year, around 138 of the 197 attendees checked the diversity box when\n applying for the ticket, and while this number includes people who are traveling\n to SoCraTes from outside of Germany, it felt even more diverse compared to the\n previous years.\n

\n This can in part be attributed to another big change this year brought: the\n Foundations Day offers short\n and intense introduction workshops one day before the open-space. In two tracks\n on Thursday before the open-space, world-class coaches held one or two hour long\n sessions which gave around 60 attendees a introduction to topics, every\n professional software developer should have heard about, like TDD, Refactoring,\n Hexagonal Architecture, Exploratory testing, and much, much more.\n

\n It is yet another step towards making the biggest gathering of Software Crafters\n even more welcoming for newcomers. And for my colleagues who were both junior\n software engineers and first time attendees of an open-space this helped them\n greatly in the following days because it provided an introduction to the\n techniques, terminology and lingo that often is used during the open-space\n without considering whether it is understood by all participants.\n

\n This created a clearly needed and safe learning space for them so they could\n make much more out of the following two open-space days and the Sunday\n workshops.\n

\n Of course, Conference Buddy was present again\n this year, and 5 participants were volunteering as buddies for this conference.\n

Conclusion

\n Conferences like SoCraTes are for me a place where I can challenge my\n assumptions, skills and beliefs exactly because it is such a safe space where\n everybody pays attention and listens. It's rare in a professional setting that\n there is the opportunity to have this form of exchange that only happens without\n organizational power structures. It's the environment I need to keep growing.\n

\n My colleagues, too, were absolutely happy with the unconference, and all want to\n come back. In the closing session we drew a spider chart that sums it up nicely:\n

https://twitter.coderbyheart.com/status/1563554925615120386

https://twitter.coderbyheart.com/status/1565292728845565963

Photos

\n You can see all photos I've taken\n over here.\n

Session log

\n I've managed to attend a good amount of sessions, and\n live-tweeted my experience\n (for your inconvenience displayed in reverse order) using the hashtag\n #SoCraTes2022.\n

\n Nevertheless, for completeness I've collected the tweets below for you in the\n correct order:\n

Friday: Open-Space Day 1

\n https://twitter.coderbyheart.com/status/1563065904971128832\n https://twitter.coderbyheart.com/status/1563100104474918913\n https://twitter.coderbyheart.com/status/1563079699391463426\n https://twitter.coderbyheart.com/status/1563093870728351746\n https://twitter.coderbyheart.com/status/1563138705195278336\n https://twitter.coderbyheart.com/status/1563161713481961475\n https://twitter.coderbyheart.com/status/1563181885395648518\n https://twitter.coderbyheart.com/status/1563229277101105153\n

Saturday: Open-Space Day 2

Workshop Day

\n https://twitter.coderbyheart.com/status/1563802156142137344\n https://twitter.coderbyheart.com/status/1563802399222947841\n https://twitter.coderbyheart.com/status/1563818007549321217\n

\n","slug":"socrates-2022-be-prepared-to-be-challenged","hero":"!undefined"}],["softwerkskammer-rheinmain",{"title":"Softwerkskammer RheinMain","date":"2012-02-28T00:00:00.000Z","lang":"de","html":"\n

\n Die Softwerkskammer ist eine UserGroup, die sich mit dem Thema Software Craft\n befasst — zu deutsch also dem Handwerk der Software-Entwicklung. Es geht dabei\n um den Austausch zwischen Software-Professionals, die ihren Arbeitsalltag damit\n verbringen, komplexe Software-Systeme zu entwerfen, zu entwickeln und zu warten.\n Dabei steht vor allem der Erfahrungsaustausch über Prozesse und Methoden im\n Vordergrund, die unabhängig von speziellen Programmiersprachen zum Einsatz\n kommen.\n

\n Die Softwerkskammer RheinMain trifft sich seit Januar 2012 einmal im Monat,\n das Februar-Treffen in den Räumen von Namics war für mich das erste — und\n von meinen Eindrücken möchte ich an dieser Stelle berichten.\n

\n $\"2.$ \n: \n 2. Treffen der Softwerkskammer RheinMain bei Namics. Foto von Jürg Stuker.\n

\n Die anwesenden 20 Mann bilden einen tollen Querschnitt aus der\n Software-Branche, von technischen Projektleitern, über Rails-Web-Entwickler und\n ein nennenswerte Anzahl von Java- und .NET-Entwicklern bis hin zu den\n obligatorischen iOS-Freelancern. Nach der Vorstellungsrunde standen die\n lightning talks auf dem Programm. Hier ging es unter anderem um\n 10-Finger-Schreiben, Diagramm-Editoren und Tipps zu VidCasts, die von allen\n Anwesenden schnell zu einer großen Liste erweitert\n wurden. Der zweite Programmpunkt war die\n Besprechung einer Codezeile, die einige mitgebracht hatten und die jeden in\n einer Art persönlich repräsentieren sollte. Hierbei ergaben sich dann auch sehr\n interessante Diskussionen um Sprach-Konzepte, zu denen jeder Anwesende so seine\n eigenen Erfahrungen und Abneigungen mitbringt. Ich selbst habe eine Zeile\n vorgestellt, die ich in\n meinem\n Studiums-Blog beschrieben habe — mir ging es\n darum, zu zeigen, wie aus einfachsten (Linux-)Kommandos mithilfe von\n Verkettung\n sehr schnell und flexible komplizierte Aufgaben lösen\n kann. Den Abschluss bildeten dann die\n Auswahl des Buches für den Buchclub, hierbei wird innerhalb der nächsten\n Monate Working\n Effectively Legacy Code von Michael\n Feathers gelesen und\n besprochen. Ein knappes Protokoll des\n Meetings findet sich\n im Wiki\n der Softwerkskammer RheinMain.\n

\n Zu guter Letzt wurde sich des, ebenfalls von freundlicherweise von Namics zur Verfügung gestellten, Kasten Biers angenommen.\n

\n Mir hat das Treffen sehr gut gefallen, da hier in kurzer Zeit viele Themen\n kompetent angeschnitten werden, aber nicht zu sehr in die Tiefe gegangen wird,\n schließlich kann nicht jeder mit allem etwas anfangen. So hat man aber eine\n tolle Liste mit Themen, in die man sich nach eigenem Geschmack etwas aussuchen\n kann und hat aber auch direkt den passenden Ansprechpartner für weitere Details\n in der Gruppe. Den Besuch bei einem Treffen einer der vielen Softwerkskammern\nin Deutschland kann ich wirklich jedem, der mit Softwareprojekten zu tun\n hat, ans Herz legen.\n

\n","slug":"softwerkskammer-rheinmain","hero":"!undefined"}],["speckyboy-com-responsive-design-is-not-about-screen-sizes-any-more",{"title":"speckyboy.com: Responsive Design is Not About Screen Sizes Any More","abstract":"Sehr guter Artikel darüber, das die Entwicklung einer guten mobilen Website nicht nur mit CSS-Media-Queries erreicht werden kann.","date":"2013-09-11T00:00:00.000Z","lang":"de","html":"\n

\n Sehr guter Artikel darüber, das die Entwicklung einer guten mobilen Website\n nicht nur mit CSS-Media-Queries erreicht werden kann.\n

\n
\n Code the site for the lowest resolution and possibilities. Make true use of\n Progressive Enhancement from the start. Build extra functionality, enhanced\n visuals and interaction when it can be used.\n
\n

speckyboy.com: Responsive Design is Not About Screen Sizes Any More

\n","slug":"speckyboy-com-responsive-design-is-not-about-screen-sizes-any-more","hero":"!undefined"}],["speed-up-your-meetings-with-pre-written-meeting-minutes",{"title":"Speed up your meetings with pre-written meeting minutes","abstract":"How to make your meetings fun again, productive and produce a well-made protocol afterwards.","date":"2015-03-09T09:00:00.000Z","html":"\n

\n When I joined dotHIV we had weekly jour fixe\n meetings via Google Hangout that easily took one hour with a team of five. Today\n we barely ever break the 30 minute mark and no one has to keep tabs to create\n the meeting minutes afterwards. Our meetings are fun again, productive for us\n and produce a well-made protocol afterwards.\n

The problem with our old meetings

\n We use our jour fixe meetings to get everyone up to speed on what's happening\n in all departments. At dotHIV that would be the work of the charitable\n organization, finances, marketing, sales, and development.
Once everyone was settled in we took turns in telling what we did in the last\n week and provide an outlook for the coming week. With a five person team\n everyone would take up to 15 minutes recollecting everything that happened and\n answer questions from the others as they came up–which would regularly spiral\n off into discussions. We tried to use timeboxes but this didn't work out very\n well because there were so many exciting things going on during the week.\n Everyone is forced to listen to things that might not be relevant to him, which\n they had prior knowledge about or they were just not capable of processing right\n now because they were preoccupied.\n

\n And then there was the one poor soul that had to make sense of everything and\n put it into writing because we wanted to have meeting minutes for ourselves and\n as a weekly report delivered to our extended team and the investors. I think you\n now that writing meeting minutes for topics that you are not an expert for is\n cumbersome and produces a result that no one is really happy with.\n

Introducing: pre-written meeting minutes

\n The first thing I wanted to change was the time spent on the telling part. So\n I asked everyone to contribute a compact written summary to a Google Doc. I\n provided a template with sections for every person. This report hat to be done\n two hours prior to our meeting so there would be enough time to read through the\n report. Questions are added to the top of the document or as notes and we go\n through each one of them during the jour fixe.\n

This is the intro text in our template:

\n
\n We create the meeting minutes for our weekly Jour Fixe beforehand. Everyone\n reports what they deems noteworthy from their \"department\" until two hours\n before the meeting in a Google Doc. Keep it brief, this should be one or two\n sentences. If there is something to explain in detail, write it down in a\n separate document. During the Jour Fixe we only talk about a topic, if someone\n has a question about it! No reciting of topics most participants already know\n anyway. This is also the place to ask specific team members about their\n commitment to a task. Commitments will then be added as task items in Trello.\n
\n

\n What's great about this approach: the meeting minutes are done when the meeting\n starts and during the meeting we can focus on the things that matter. We discuss\n the open questions concerning the report and then we have a lot more time to\n socialize, crack jokes and talk about the small things–which we couldn't before\n because we didn't have the time.\n

\n","slug":"speed-up-your-meetings-with-pre-written-meeting-minutes","hero":"!undefined"}],["start-with-react",{"title":"Start with React","subtitle":"Markus, how do I ...","abstract":"Some resources to get you started with React.","date":"2017-10-22T20:00+02:00","html":"\n

Depending on your preferred learning style, check out these starter guides.

\n this\n React Video Tutorial by LearnCode.academy\n
\n also\n David Tanzer has a nice paid course\n
\n an interactive way to learn React can be found at\n react.express\n
\n if you like to read, check out Robin Wieruch's free\n Road to Learn React\n

\n","slug":"start-with-react","hero":"!undefined"}],["startup-weekend-productivity-tipps",{"title":"Productivity Tips for a Startup Weekend","abstract":"So, you are attending a startup weekend? You will be crammed in a room with strangers to collaborate on an idea-maybe even yours? I have some advice for you to improve your output during this 54 hours.","date":"2014-10-26T00:00:00.000Z","html":"\n

\n So, you are attending a startup weekend? You will be crammed in a room with\n strangers to collaborate on an idea-maybe even yours? I have some advice for you\n to improve your output during this 54 hours.\n

\n Use Google Drive to work on concept documents,\n texts, spreadsheets for your business plan and the presentation. Everyone can\n work on every document at the same time and all collaborators will see updates\n in real time. Don't even try to work with files during the weekend.\n

\n If you need to share files, use\n Bittorrent Sync. It doesn't rely on\n central internet servers like Dropbox and can transmit files on the local (W)LAN\n with insane speed. No registration required-you'll be sharing files in minutes.\n

\n Use Trello to manage your tasks.\n It's super easy to get started and you'll have an easy way to prioritize what\n should be done next and track what is going on.\n

\n Use Slack for team communication. This provides a clear\n separation of communication for your project, it runs on any device and nobody\n has share his phone number. Yes, don't even think about using WhatsApp. I mean\n it!\n

\n If you are building an MVP, use GitHub to share and\n collaborate on your code, it even provides free hosting for\n your landingpage. You should\n create an organization\n for your project.\n

\n Bring headphones or earplugs. It will get loud sometimes, and you will need to\n concentrate. You should bring some music, too. Or just tune in to\n ETN.\n

\n And last but not least: enjoy yourself and take the startup weekend as an exotic\n escape from your day job. You can be a totally different person here, you know?\n

\n","slug":"startup-weekend-productivity-tipps","hero":"!undefined"}],["startup-weekend-rheinmain-2012",{"title":"Startup Weekend RheinMain 2012","date":"2012-06-05T00:00:00.000Z","html":" $\"Startup$ \n

\n Am Wochenende rund um den 1. Juni 2012 fand im FIZ in Frankfurt das erste\n Startup Weekend hier im RheinMain-Gebiet statt. Ich hatte mich schon\n frühzeitig, und mit Studentenrabatt, angemeldet um mit meinem Projekt\n re:text dort teil zu nehmen. Ziel eines Startup Weekends ist es, für neue\n Ideen Mitstreiter zu finden und bereits am Wochenende diese Idee zu einem\n tragfähigen Konzept auszubauen. Hierzu stellt man in einem 60-Sekunden-Pitch die\n Idee vor allen Teilnehmern vor, in der anschließenden Abstimmungsphase werden\n von jedem Teilnehmer drei Punkte an seine Lieblingsidee vergeben. Die Ideen mit\n den meisten Punkten dürfen dann am Wochenende bearbeitet werden. An dieser\n Veranstaltung waren etwa 120 Teilnehmer anwesend, die sich zu 15 Teams\n zusammenfinden sollten – am Sonntag sind davon zehn Teams übrig geblieben.\n Über das Wochenende stehen den Teams erfahren Mentoren zur Seite, die diese bei\n der Ausarbeitung der Konzepte unterstützen. Bis zum Sonntag Nachmittag ist dann\n Zeit, sich auf die Abschlusspräsentation vorzubereiten, bei der die Idee –\n oder das, was sich aus ihr entwickelt hat – einer Jury aus vier Experten\n zu präsentieren. Anschließend werden von der Jury noch einige Fragen gestellt,\n vor allem zu den Themen Finanzierung, Machbarkeit, Anfangsschwierigkeiten und so\n weiter. Die besten Teams erhalten neben tosendem Applaus auch handfeste Preise\n für die erste Zeit des Startups: Bürofläche, Firmenwagen und natürlich auch\n Beratungspakete.\n

\n Der eigentliche Gewinn an diesem Wochenende ist aber, die Gelegenheit zu haben\n tolle Menschen kennen zu lernen, die alle ein gemeinsames Ziel verfolgen: mit\n der eigenen Idee ein Unternehmen zu gründen oder sich einem jungen, innovativen\n Team anzuschließen – in beiden Fällen sprühen die Teilnehmer nur so vor\n Energie und Tatendrang, was das Wochenende für mich zu einem bisher einmaligen\n Erlebnis gemacht hat.\n

\n An dieser Stelle muss man auch dem tollen Orga-Team ein riesiges Lob\n aussprechen, die an ihre eigenen Grenzen gegangen sind, um es uns Teilnehmern an\n nichts fehlen zu lassen. Fantastisch war auch die Versorgung über das\n Wochenende, oder kennst Du ein Event, bei dem es eine Kaffee, fritz kola,\n Schwarze Dose 28, MyMüsli, Burger, Bagels, BBQ, Pizza und Buffet Flatrate gibt?!\n Ich nicht.\n

Mehr Fotos finde sich hier.

\n","slug":"startup-weekend-rheinmain-2012","hero":"!undefined"}],["stay-connected",{"title":"Stay connected","subtitle":"Working From Home","abstract":"It's now even more important to keep in touch in these times of crisis and uncertainties.","date":"2020-03-26T13:00+01:00","html":"\n

\n It’s week three from most likely many, many weeks to come in which we will work\n in a setting that many of us are not used to: from their hjemmekontor. It means\n we see our lovely colleagues only occasionally and as small flat rectangles on\n our screens … this makes it very hard to connect on the human level, which is\n now even more important in these times of crisis and uncertainties. While we are\n privileged to be able to move our daily work seamlessly into a remote setup,\n many of us worry about their families and relatives in other countries. It’s\n important to not only check in daily about any blockers, but also be on the\n lookout for the personal wellbeing of our colleagues. While a video call might\n be the closest thing at hand, you might also try to experiment with other ways\n to stay connected during the day.\n

\n SoCoCo for example emulates the physical office, and\n while everybody hangs out there all day, you can also visualize your current\n situation: free to chat with everyone or focused on a specific project by\n putting your avatar in the respective room.\n

\n Discord also is a very convenient way to have a voice\n channel open all day, if something comes up, you can just talk and reach\n everybody who is listening …\n

\n If you want to turn up the fun factor a bit, try\n Mozilla Hubs, a VR chat that runs in your browser -\n no signup or download necessary. It works great without VR goggles and the\n spatial audio feature allows us to interact virtually even with bigger groups.\n

\n If you’d like to try out some of these tools,\n I am having an open remote coffee hour every workday from 15-16:00 Oslo time\n where we try out these offers.\n

\n","slug":"stay-connected","hero":"!undefined"}],["success-through-humanness",{"title":"Success through humanness: The autobiography by dm founder Götz W. Werner","subtitle":"Book review","abstract":"Book review of Womit ich nie gerechnet habe by Götz W. Werner. I recommend this book to everyone who is facing problems like high turnover rates, inefficiency due to bureaucracy and incompetence or is, like me, interested in alternative operating-systems for organizations.\n","date":"2016-06-18T08:00:00.000Z","html":"\n

\n Womit ich nie gerechnet habe is the (German) autobiography by the founder\n of dm, today the largest pharmacy retailer in Europe. Within 35 years, Werner\n build an organization of 30,000 employees and 2,000 stores in 2008 based on\n anthroposophical principles developed by Rudolf Steiner: putting the human\n first, within the organization but also in relation to the customer.\n

\n The book is unique because it offers a fascinating insight into a journey of a\n founder who learned that you can run a profitable, agile and antifragile\n business while ignoring industries best practices and putting the individual\n first.\n

\n In this book Werner describes his way from a young pharmacist when he started\n seeing opportunities where others wouldn't to the CEO of a successful pharmacy\n retailer and describes multiple occasions where the organization needed to be\n completely restructured. The reasons were never due to a crisis but due to\n Werner's strive to build a company that serves its employees, customers and\n the society. By questioning the status quo and pushing for his idealistic views,\n often answered with strong hesitation by colleagues and friends, he enabled dm\n to be truly agile: change was achieved by engaging everyone in the organization,\n which often took years. But because everyone owned the change it never failed\n to stick. His effort to improve the human factor in the organization proved to\n be a win-win for everyone: the company never made losses, it holds the highest\n rating in independent consumer satisfaction rankings, is a highly favored\n employer and the market leader in Europe.\n

\n Werner's legacy is proof that it is possible to build a successful business in a\n highly competitive market without sacrificing purpose and generosity. A business\n that includes the human needs and messiness into the business model will be at\n least as successful as classical meat-grinders. Examples like the Schlecker\n bankruptcy showed that this approach pays off.\n

\n I recommend this book to everyone who is facing problems like high turnover\n rates, inefficiency due to bureaucracy and incompetence or is, like me,\n interested in alternative operating-systems for organizations.\n

\n","slug":"success-through-humanness","hero":"!undefined"}],["symfony2-with-assetic-automatically-update-assets_version-on-deploy",{"title":"Symfony2 with Assetic: Automatically update assets_version on deploy","abstract":"If you're using assetic to manage your assets in your Symfony2 project you have probably already wondered if there is a way to update the assets_version parameter automatically with every deploy.","date":"2013-10-03T00:00:00.000Z","lang":"de","html":"\n

\n If you're using assetic to manage your assets in your Symfony2 project you\n have probably already wondered if there is a way to update the assets_version\n parameter automatically with every deploy.\n

\n On my boxes I use this little command to update the assets_version to the\n latest unix timestamp:\n

\n
V=`date +%s`; sed -i -r -e \"s/(\\W+)assets_version:(\\W+)[^\\n]+/\\1assets_version:\\2$V/\" app/config/parameters.yml
\n

\n It searches the parameters.yml and updates the assets_version line with the\n current unix timestamp (e.g. 1380833873). It also honors the current\n indentation used in the file which may vary in YAML.\n

\n This statement could be added to your composer.json‘s post-install-cmd\n or post-update-cmd section or any other deploy script you are using.\n

After that just make sure to update your assets via

\n
app/console assetic:dump
\n

\n","slug":"symfony2-with-assetic-automatically-update-assets_version-on-deploy","hero":"!undefined"}],["templates-fur-jenkins-in-php-projekten",{"title":"Templates für Jenkins in PHP Projekten","abstract":"Ähnlich wie die Ant Build Commons von qafoo, liefert Sebastian Bergmann unter jenkins-php.org Vorlagen für Integration von PHP-Projekten in Jenkins.\n","date":"2012-09-15T00:00:00.000Z","html":"\n

\n Ähnlich wie die Ant Build Commons von qafoo, liefert Sebastian\nBergmann unter jenkins-php.org Vorlagen für Integration von\n PHP-Projekten in Jenkins.\n

\n
\n The goal of this project is to provide a standard template for Jenkins jobs\n for PHP projects.\n
\n

\n Im Projekt stehen verschiedene Templates zur automatischen Ausführung in Jenkins\n zur Verfügung, mit denen sich PHP-Projekte dann automatisiert Prüfen, Testen und\n Analysieren lassen.\n

Die build.xml, in der alle Build-Targets beschrieben sind, findet sich auch auf\nGitHub.

\n","slug":"templates-fur-jenkins-in-php-projekten","hero":"!undefined"}],["testcraftcamp2021",{"subtitle":"Conferences","title":"TestCraftCamp 2021 Virtual Edition","abstract":"Virtual conferences do not get any better than this one.\n","date":"2021-03-14T18:00:00.000Z","html":"\n

\n One year into the pandemic I spent yet another day in front of a computer screen\n to virtually connect with fellow computering humans who care about software\n quality at the TestCraftCamp.\n

\n After all, the tester community aligns very closely with the software crafters\n community, so I feel very much at home in both of them:\n

https://twitter.com/S_2K/status/1368924555486564360

\n Before I dive into the sessions I have attended and what I've learned, I'd like\n to share the set-up that was used for this conference, because this is a now\n proven combination of tools and it works really well.\n

\n The two main tools in use are a real-time whiteboard (in this case\n miro, but I have seen Mural to\n work equally well). One whiteboard is used for all content of the\n conference, from the introduction, to the marketplace, the schedule and the\n feedback. This means everyone can easily navigate around the virtual venue.\n

\n Each slot in the marketplace links to a section on the whiteboard for taking\n notes during the session.\n

\n Miro supports many different styles of taking notes, like Post-its, plain text,\n or even mind maps.\n

\n Zoom was used for face-to-face communication, and all the\n break out rooms were clearly labeled (with name and color) so it was easy to\n find the right room to switch to. It also supports remote controlling a\n presenters computer, which we used extensively during ensemble testing session,\n where the entire group tests a program.\n

\n The tools in use have clearly evolved over the last year, but so did the\n attendees. Interacting with everyone using them felt much more natural\n compared to a year ago and this led to a very noticeable level of interactivity\n and tangible levels of energy.\n

\n It felt great to be around people who embrace these digital tools and try to\n make the best out of it.\n

Remote conferences make for different sessions

\n Especially Irja's session on ensemble testing was designed with all participants\n being remote in mind and it would not have happened like this at a physical\n conference ... there we typically try to stay away from screens, or have only\n one person sit in front of a screen while everybody else watches. This leads to\n a different experience compared to having everybody being remote.\n

https://twitter.com/irjastraus/status/1370791393946374150

\n The omni-presence of a digital whiteboard also leads to much better note-taking,\n because everyone is logged in, and on the board, there is much less hesitation\n to add notes, or correct and improves the notes of others. The result is not\n necessary usable standalone; having a recording would improve the experience for\n those who were not present during the session. This is one of the main\n advantages of a remote conference, recordings are basically free, however I see\n the issue that not everyone wants themselves (or their children who happen to\n walk in the room) to be recorded.\n

Sessions I attended

\n I've tried to summarize some of the learnings from the sessions I've attended\n on Twitter,\n and if you are interested to learn more about what happened at the conference,\n check out the hashtag\n #TCC2021.\n Writing up good session summaries on Twitter while in parallel attending a great\n session is not that easy ... so I'll try to give a summary here as well.\n

Quality for AI systems

\n This session was a very interesting discussion around the challenges that AI\n brings with a focus on testing and ensuring it's quality. We collected many\n interesting aspects and I'd consider this my preferred style of session: you get\n way too much input to handle, but it gives you a direction towards further\n research ... which brings more confusion, obviously. This is a topic we will\n most likely revisit at future events.\n

\n It also revolved around testing strategies for black box systems, and those that\n make highly complex, expert decision, and how the development and proliferation\n of these systems could lead to the availability of (new) experts being\n influenced by their existence, which could lead to some professions not getting\n developed further.\n

Spicing up your relationship with your projects

\n This was a wild and fun session. A tester was wondering what they could be doing\n differently when testing their software, because they felt a little bit stuck.\n We spent 45 minutes brainstorming a huge list of ideas and techniques that would\n add additional elements to their test strategy or even the way the product is\n co-designed with customers and users. Again, this session also lived off the\n good use of the available tools and the fact that everyone felt included and\n safe to contribute to their ideas mostly because of the amazing session host.\n

\n The outcome then resulted also in the last session I've attended in which we\n ensemble-tested the app, which was pure joy to see a group of testers poking\n wildly at a production app and finding at least 50 problems, and running into\n network errors, bad recommendations, performance and usability issues.\n

End-to-End BDD tools

\n I joined the session which was initially proposed by\n Pascal Dufour where he wanted to have a\n look at NoCodeBDD. I wanted to talk about\n end-to-end testing tools that others are using so for me this was a great match.\n Besides NoCodeBDD, which we only managed to get to run on one machine, and the\n widely known end-to-end testing frameworks that drive web browsers (Selenium,\n Cypress, and Playwright), there weren't much other tools, that take the\n low-code approach I use. Most teams work with\n high-level BDD scenarios written in domain-specific language and implement step\n definitions.\n

\n Nevertheless this discussion was great to get feedback on the advantages of this\n approach and hear about concerns against too much low-level language in feature\n files.\n

Ensemble Testing

\n I've mentioned this earlier, Irja facilitated a great session where we tried to\n figure out what a software does (which we didn't really), and find bugs (which\n we did). For me it was great to see how enabling a group of people to poke at\n the same piece of software makes testing much more fun but is at the same time\n very effective. Taking turns in being the driver, the navigator and observer\n also gives everyone enough time to complete notes. The output of testing like\n this is much more complete as if individual tests would have given it a look\n individually.\n

Summary

\n I guess for me one of the main takeaways was about the power of timeboxed group\n collaboration. This worked so well in this event, not only because the\n technology is now working reliably, but also because the event created a safe\n and welcoming space, where every opinion is heard and everyone is invited to\n contribute and ask any kind of question. This is an event format that more teams\n and companies can also use for internal events ... who knows what you might\n discover?!\n

\n","slug":"testcraftcamp2021","hero":"!undefined"}],["the-full-stack-developer-trap",{"title":"The full stack developer trap","subtitle":"The fallacy of doing everything","abstract":"I realized that there is a full-stack developer trap: your work is evaluated based on your best skill, which unfulfillable expectations.\n","date":"2017-04-21T11:00+02:00","html":"\n

\n
\n This is a replication of\n this tweet thread.\n
\n

\n I would consider myself to be a full stack developer, but my strength is\n building backend systems for complex processes. My career started as a frontend\n developer and I have been building frontends throughout my various types of\n employment of the last 19+ years. I'd say I know frontend technologies VERY\n well. And this knowledge gets me very far even compared to frontend developers.\n

\n Because I know how everything works together, and I also have been educated in\n design theory, usability, it's easy for me to use frontend frameworks to build\n production quality frontend components.\n

\n But going beyond that, we are looking at UX and in the end hard UI design\n problems: going from Bootstrap to the next level, is something I can't do.\n

\n And this is where it gets tricky: If I'm confronted with a backend task, I can\n always go further and provide excellent solutions, because backend code for\n processing data, talking to to other services, scaling infrastructure, failure\n tolerance is my passion. Frontend code for mitigating browsers bugs, UI effects,\n positioning elements, animation: a sometimes interesting but mostly just\nnecessary thing.\n

\n But for a non-technical founder, though, they do not make this difference\n between backend and frontend work. My work is evaluated based on my best\n skill, which creates unfulfillable expectations. And they will implicitly expect\n my frontend work results to be equally sophisticated as my backend work.\n

\n I maneuver myself into this trap by using frameworks like Bootstrap. They enable\n me to have great looking standard components, without designing. But for\n everything custom, it gets hard, and there needs to be designers, UI/UX\n experts.\n

\n I know this from the start, but at this point it's actually too late. It's now\n really hard to explain that to your founders and team, that they road you had\n taken them on is not getting just a little bumpy, but ends now, at a cliff.\n

Here is what you can do

Make your skill distribution and preference explicit when working in the full\nstack role.

\n As a full stack developer your are sought after in early stage startups, small\n teams because you can deliver everything technically they need in one person.\n

\n Make clear for which of the many roles you hold, you expect to be replaced and\n how quickly and what you want to keep doing forever.\n

\n This will help your team to commit to finding a replacement for you from the\n start of a project. And you will spend more time working with what you can\n and love to do.\n

\n I know this sounds contradictory to the term full stack developer, but I've\n never met one that truly excels in and loves both disciplines.\n

\n I think there is a better term for that: next time I'll introduce myself as a\n backend developer and full stack literate.\n

\n","slug":"the-full-stack-developer-trap","hero":"!undefined"}],["the-great-web-framework-shootout-bottle-vs-silex",{"title":"The Great Web Framework Shootout: Bottle vs. Silex","abstract":"Frameworks zu vergleichen ist immer eine schlechte Idee, zu viele Faktoren spielen bei der Wahl eines Frameworks eine Rolle, als dass man sich rein auf quantitative Aussagen wie Anfragen pro Sekunde, Zeilen Quellcode oder die geschlossenen Bugs pro Monat verlassen darf.","date":"2012-02-20T00:00:00.000Z","lang":"de","html":"\n

\n Frameworks zu vergleichen ist immer eine schlechte Idee, zu viele Faktoren\n spielen bei der Wahl eines Frameworks eine Rolle, als dass man sich rein auf\n quantitative Aussagen wie Anfragen pro Sekunde, Zeilen Quellcode oder die\n geschlossenen Bugs pro Monat verlassen darf.\n

\n Trotzdem ist sind diese Vergleiche immer wieder faszinierend. Gestern bin ich\n über The Great Web Framework Shootout gestolpert. Bei diesem Test werden\n mit Frameworks drei einfache „Hello World!“-Seiten umgesetzt: einmal als\n statische Antwort, einmal mithilfe einer Template-Engine und einmal mit Daten\n aus einer kleinen SQLite-Datenbank. Gemessen wird die jeweilige Antwortzeit der\n Frameworks bei diesen drei Seiten.\n

\n Was mich bei den dort gezeigten Zahlen extrem stutzig gemacht hat, war das\n miserable Abschneiden der PHP-Frameworks und besonders von Symfony2, obwohl der\n Tester darauf geachtet hat, APC zu aktivieren. Um diese Zahlen zu\n verifizieren habe ich einen eigenen Test mit Silex (dem kleinen Bruder von\n Symfony2) aufgesetzt. Den Quellcode dazu findet sich in diesem\nPull-Request. Da ich inzwischen auch ein großer Fan von Python bin und sich\n zudem noch die Philosophie von Bottle und Silex sehr ähneln, habe ich\n dieses Framework zum Vergleich genommen. Beide Frameworks sind als Virtual Host\n konfiguriert, und werden mit Apache Bench ab -n 10000 -c 10 aufgerufen. Die\n Ergebnisse sprechen für sich. Mit Templating-Engine und Datenbank-Zugriff\n liefert Bottle 16.632 Anfragen pro Sekunde aus, Silex lediglich 378.\n

$\"The$ \n

Micro bedeutet also nicht immer hohe Geschwindigkeit.

\n","slug":"the-great-web-framework-shootout-bottle-vs-silex","hero":"!undefined"}],["the-hard-things-about-hard-things",{"title":"The Hard Things About Hard Things","subtitle":"Book review","abstract":"Book review of The Hard Things About Hard Things by Ben Horowitz","date":"2016-06-12T16:00:00.000Z","html":"\n

\n The Hard Things About Hard Things by Ben Horowitz is a book for CEOs.\n Horowitz explains in a very easy to read and an entertaining style his learnings\n as a CEO. For me it was especially helpful to better understand the role of a\n CEO and exciting the get a look into to the decision strategies of a battle-\n proven startup founder.\n

\n Especially useful for non-CEOs like me and and from a leadership perspective are\n his remarks on the importance of the CEO being the person in an organization\n that is actually in the position to make tough decisions and that finding\n decisions in a commitee does not yield the best decision in the interest of the\n company. In combination with his chapter on the Peacetime/Wartime CEO this\n helps to understand the role of a CEO: companies cant function properly without\n them and they are in a constant state of struggle, often dilemma. The hard\nthing is that there is no simple answer to this and they deservere respect and\n forgiveness for their sometimes hard to understand decisions. But only the\n unique position of a CEO who has all knowledge about a business enables thme to\n weigh that information and find the best decision-or just the least bad one.\n

\n Where Horowitz stands out for me is the fact that he goes great length into\n explaining the importance of not letting politics destroy the connection and\n trust employees have in their company. He values the individual learning and\n development over everything else because in the end it will be the strength of\n the team that carries a startup through tough times.\n

\n The book is a short read and I highly recommend it to (future) entrepreneurs and\n team leads.\n

\n","slug":"the-hard-things-about-hard-things","hero":"!undefined"}],["the-magic-of-socrates-conference",{"title":"The magic of Socrates Conference","abstract":"Get rich by visiting this conference: rich in ideas, options and connections\n","date":"2015-08-29T20:00:00.000Z","html":"\n

\n It's the fifth installement of the yearly conference centered around the idea\n that\n software developement is a craft\n and if you consider yourself to be a software developer you would be doing\n yourself and your peers a favour if you constantly improve yourself.\n

\n The Socrates Conference creates through\n contribution of every participant an environment where you can let yourself\n wander around in over a hundred sessions with topics ranging from technical\n topics like domain driven design, software testing or functional programming to\n team building, hiring, meditation and board games. Every single item on the\n session board is proposed and hosted by the participants — there is no\n sponsored track, no product show or hackathon. You'll get absorbed in a flood of\n new ideas, fascinating concepts and compelling questions and you leave with you\n head buzzing and the warm feeling that we as an industry are not solely made of\n people that hunt the next big thing and compromise their personal freedom, their\n health and their empathy.\n

\n #socrates15 attendees\n also want to get rich: rich in ideas, options and connections — this is\n for me an important part in becomming a better software developer. Please join\n us next year!\n

\n","slug":"the-magic-of-socrates-conference","hero":"!undefined"}],["the-seven-day-weekend",{"title":"The Seven-Day Weekend","subtitle":"Book review","abstract":"Ricardo Semler debunks an illusion: the idea that you can plan for the future.\n","date":"2016-11-06T10:00+02:00","html":"\n

\n In The Seven Day Weekend, Ricardo Semler explains in plain english his\n very pragmatic approach to building a company that survives radical market\n transformations while keeping its employees fully invested in constant\n improvements, change and new ventures. His philosophy is radical: if a problem\n or conflict arises, do nothing. Given enough trust, information and time, the\n employees will find a solution to any problem that might not always be better\n then one thought up by top-level managers but always will find a broad\n acceptance within the workforce and thus getting accepted and integrated as\n quickly as possible.\n

\n What is also clear, though, it's hard to run a company after Semcos example:\n removing artificial growth goals, not being able to control everything, and\n trusting your employees and their instincts is nothing today's managers are\n prepared for. Schools, universities and companies are systems that still teach\n the opposite of what Ricardo Semler so easily debunks as an illusion: the idea\n that you can plan for the future.\n

\n This book is fascinating and provides in many anecdotes an insight into a truly\n new way of managing organizations, and that is what makes it so powerful. Semco\n is proof that there are robust and successful alternatives to\n command-and-control-structures.\n

\n","slug":"the-seven-day-weekend","hero":"!undefined"}],["there-is-no-working-time-flexibility-during-vacation",{"title":"There is no working time flexibility during vacation","abstract":"If not for yourself, you owe it to your peers to be a good example by not executing your working time flexibility during your vacation.","date":"2015-12-03T08:48:00.000Z","html":"\n

\n If you take your work seriously you also need to do this for your vacation.\n Vacations are an important factor for your overall ability to generate value.\n Their purpose is to recharge your batteries–for knowledge workers this means\n taking your mind off work so that your brain can process the things you have\n learned about the challenges at hand, build the connections, and identify the\n patterns that emerge. After returning from your vacation you have taken several\n virtual steps back and can assess your work from a new perspective. This will\n enable you to find better solutions for the projects you are working on and\n enable you to do your best eventually.\n

It is therefore that you lose your working time flexibility during vacation.

\n I am an absolute advocate of personal freedom as part of your position which\n includes the ability to chose when and where you work. This means that I don't\n care when a coworkers is working–as long as they are not doing overtime. And\n this is the crucial point. I am obliged to ensure that my coworkers' working\n hours during the week don't exceed the agreed-upon limit. By doing checkings in\n during vacation, completing little tasks, being ready to take calls, coworkers\n on vacation are sending a signal to everyone in the company that it is O.K. to\n be available 24/7. It is not.\n

\n There is the argument, that an experienced coworker who is very well\n self-organized is mature enough to know about the balance between work and\n not-work and that they are very well equipped to handle smaller tasks during\n vacation without the blink of an eye. I'd doubt that. But what is even more\n important is that there are usually far more coworkers that are not yet able to\n manage themselves to their best. They will see this behaviour not as an\n expression of great self-management skills but take it for what it looks on the\noutside: that it is O.K. to work all the time.\n

\n If not for yourself, you owe it to your peers to be a good example by not\n executing your working time flexibility during your vacation.\n

Happy holidays!

\n","slug":"there-is-no-working-time-flexibility-during-vacation","hero":"!undefined"}],["timezone-in-ubuntu-setzen",{"title":"Timezone in Ubuntu setzen","abstract":"Zum Einstellen der Zeitzone in Ubuntu führt man dieses Kommando aus und folgt den Anweisungen.","date":"2010-05-14T00:00:00.000Z","lang":"de","html":"\n

\n Zum Einstellen der Zeitzone in Ubuntu führt man dieses Kommando aus und folgt\n den Anweisungen.\n

dpkg-reconfigure tzdata\n

\n","slug":"timezone-in-ubuntu-setzen","hero":"!undefined"}],["tincr-edit-and-save-files-from-chrome-developer-tools-live-reload-for-chrome",{"title":"Tincr - Edit and save files from Chrome Developer tools. Live reload for Chrome.","abstract":"Tincr ist eine sehr nützliche Extension für Chrome, die Änderungen an lokalen Dateien überwacht und die Änderungen im Browser anwenden. Änderungen an CSS-Dateien können dabei sogar ohne Neu-Laden der Seiten angewendet werden.\n","date":"2013-09-08T00:00:00.000Z","html":"\n

\n Tincr ist eine sehr nützliche Extension für Chrome, die Änderungen an\n lokalen Dateien überwacht und die Änderungen im Browser anwenden. Änderungen an\n CSS-Dateien können dabei sogar ohne Neu-Laden der Seiten angewendet werden.\n

\n","slug":"tincr-edit-and-save-files-from-chrome-developer-tools-live-reload-for-chrome","hero":"!undefined"}],["topconf-linz-2016",{"title":"TopConf Linz 2016","abstract":"Impressions from my first tech conference as a speaker.\n","date":"2016-02-03T18:00:00.000Z","html":"\n

\n I'm just returning from TopConf Linz 2016 which\n was my first tech conference that I visited as a speaker. I do have\n quite some speaking experience but with\n shorter talks, usually around 15 minutes, and in front of an audience that does\n not pay to attend the event. With a ticket price of €220 this conference is no\n where near your usual €1,500+ that some of the bigger conferences call up but\n still, not a free event. I did visit some similar priced conferences in the\n past, like the mindblowing SoCraTes or the\n APIDays so I do also have made some experiences how\n awesome conference could be. TopConf unfortunately does not fully live up to its\n name.\n

\n They did manage to create a really interesting and to some extent diverse\n program with one workshop day and eight talk tracks during two days. The\n speakers that I saw were experienced, very well prepared and very enjoyable.\n What I especially liked: never marketing a specific product or solution. The\n location was technically top notch regarding audio and presentation equipment.\n Unfortunately the WiFi was non-existent. I wasn't even able to connect to it the\n whole day, so I had to buy a roaming data pass to be able to tweet-which I enjoy\n a lot. For me this is even more important in order to connect with other\n attendees after the event is over. Having no working WiFi resulted in a very low\n volume of tweets for the events hashtag\n #TopConfAT and basically no use of\n the mobile conference app which had dedicated functionality for interacting with\n other attendees during the conference. But given this is the first time for the\n TopConf to take place at this location it is something they are not to blame\n for.\n

\n Where I can't be that forgiving is the catering. I have never experienced\n something similar. What began with the absence of breakfast (the conference\n opened at 9am) and coffee only being available after the first talks were over\n ended in the evening with dinner in the form of hamburgers and cheeseburgers\n from McDonalds. This is probably the most braindead catering option to be found,\n yet they failed to take care of the attendees for whom meat is not a proper\n meal. This is simply rude and non-inclusive.\n

\n In the end I still enjoyed attending TopConf because I got to practice my\n speaking (and also got to make some stupid mistakes myself doing so) and had the\n chance to meet great and interesting people. The TopConf staff always was very\n friendly and caring. The problems I've pointed out are easy to fix so I'll\n probably apply to speak again next year …\n

\n","slug":"topconf-linz-2016","hero":"!undefined"}],["topconf-linz-2017",{"title":"TopConf Linz 2017 Notes","abstract":"These are the notes I took for my company Slack during TopConf Linz 2017.","date":"2017-03-06T23:00+02:00","html":"\n

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

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

Day 1

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

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

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

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

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

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

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

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

Day 2

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

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

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

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

\n","slug":"topconf-linz-2017","hero":"!undefined"}],["towards-class-less-javascript",{"title":"Towards class-less JavaScript","subtitle":"Ongoing Exploration","abstract":"I am getting more and more convinced that classes in JavaScript or TypeScript are an anti-pattern. At least in the way I use them.","date":"2019-03-18T12:00+01:00","html":"\n

\n I am getting more and more convinced that classes in JavaScript or TypeScript\n are an anti-pattern. At least in the way I use them.\n

I guess this will be a familiar example to you:

class PetStoreManager {\n  constructor(petRepository: PetRepository, account: CheckingAccount) {\n    this.petRepository = petRepository;\n    this.account = account;\n  }\n\n  buyPet(name, price) {\n    const pet = this.petRepository.findByName(name);\n    if (!pet) throw new Error(`Pet ${name} not found!`);\n    this.petRepository.remove(pet);\n    this.account.addFunds(price);\n    return pet;\n  }\n}\n

\n PetStoreManager is a class, which when instantiated receives dependencies, and\n upon calling the butPet method, will interact with these collaborators\n according to the business logic (When a pet is bought, add the paid price to\nthe funds.)\n

petRepository is an instance of another class:

interface PetRepository {\n  create(name: string): void\n  findByName(name: string): Pet | undefined\n  remove(pet: Pet): void\n}\n\nclass FileSystemPetRepository extends PetRepository {\n  constructor(storageDir) {\n    this.storageDir = storageDir\n  }\n  create(name) {\n    writeFile(\n      path.resolve(storageDir, `${name}.json`),\n      JSON.stringify({\n        name\n      })\n    )\n  }\n  findByName(name) {\n    return JSON.parse(readFile(path.resolve(storageDir, `${name}.json`)))\n  }\n  remove(pet) {\n    unlink(readFile(path.resolve(storageDir, `${pet.name}.json`)))\n  }\n}\n

\n We use these classes to achieve the S, L and D of the\n S.O.L.I.D.\n principles:\n

\n Single responsibility principle:\n we separate the concerns of handling the transaction and storing pets in two\n separate classes, which makes it easier to understand what they do and also it\n simplifies testing this code.\n
\n Liskov substitution principle:\n the PetStoreManager class does not care how the pets are stored, one can\n swap out the instance of the FileSystemPetRepository with a\n MySQLPerRepository without needing to modify the managers implementation.\n The PetStoreManager is getting passed an instance of the repository, it does\n not use new ... to create an instance. This is important so we can test the\n implementation and can effectively configure our software depending on the\n environment.\n
\n Dependency inversion principle:\n The PetStoreManager depends on a repository interface, not on the concrete\n implementation.\n

\n My observation however has been that by following this pattern we eventually end\n up violation the Single responsibility principle because classes give us and\n arbitrary boundary which is hard to pierce because there is no easy and\nobvious way to slice a class. We end up adding more and more methods to\n classes who roughly interact with the same dependencies. I have seen multiple\n instances where class methods were added which introduced new dependencies, and\n they were added to the constructor:\n

class FileSystemPetRepository extends PetRepository {\n-  constructor(storageDir) {\n+  constructor(storageDir, storageQuota) {\n    this.storageDir = storageDir\n+   this.storageQuota = storageQuota\n  }\n  create(name) {\n+   this.storageQuota.hasQuota(storageDir)\n    writeFile(\n      path.resolve(storageDir, `${name}.json`),\n      JSON.stringify({\n        name\n      })\n    )\n  }\n}\n

\n Now create needs to check if there is enough quota in the storage before\n adding a new entry. But findByName and remove can be kept unchanged, since\n for them the quote information is not relevant or respectively implicit.\n

\n We keep growing the class further and further and this bugs me for multiple\n reasons:\n

\n for every dependency we are also adding an import statement, a constructor\n argument, and a class property. This adds additional noise in the beginning of\n the file.\n
it gets harder to reason which method needs which dependency
class files become longer and longer, easily stretching above 500 lines

What if we had no classes in the first place?

\n The most obvious reasons for using classes is as collaboration holders,\n meaning they provide the dependencies which the business logic needs to\n interact. There are basically no classes in my code that have state in the\n classically sense: storing computation results to be reused later. Because this\n is hard to test I avoid having state in my classes and methods will only have\n local state and return results. They are already functional.\n

Classes were not meant to be used for that, that's why using Classes for the\npurpose of dependency management is an anti-pattern.

\n Now, where do we go from here? How does a better version of that code looks\n like, that addresses the concerns listed above:\n

only provide the dependencies for a method that are needed
shorter files

\n My current practice is to convert interfaces to TypeScript types for each\n method:\n

// petRepository.ts\nexport type create = (name: string) => void;\nexport type findByName = (name: string) => Pet | undefined;\nexport type remove = (pet: Pet) => void;\n

\n The concrete implementation for e.g. the file-system backed pet repository looks\n like this:\n

// petRepository/fileSystem/remove.ts\nexport const remove: petRepository.remove = (pet: Pet) => {\n  unlink(readFile(path.resolve(storageDir, `${pet.name}.json`)));\n};\n

\n and convert all class methods to functions which receive the implementations\n of these types.\n

// petstoreManager/buyPet.ts\nexport const buyPet: (\n  findPetByName: petRepository.findByName,\n  removePet: petRepository.remove,\n  addFunds: checkingAccount.addFunds\n  name: string,\n  price: number\n) => {\n    const pet = findPetByName(name);\n    if (!pet) throw new Error(`Pet ${name} not found!`);\n    removePet(pet);\n    addFunds(price);\n    return pet\n  }\n

\n In cases were an implementation has a dependency but the consumer does not know\n about this dependency I return the implementation with the bound dependency.\n

\n Here is the example of the file-system backed pet repository method create\n which needs to ask for the quota.\n

// storageQuota.ts\nexport type hasQuota = (location: string) => boolean\n// petRepository/fileSystem/remove.ts\nexport const create = (hasQuota: storageQuota.hasQuota) => (name: string) => {\n  writeFile(...)\n}\n

\n When I need a petStore.create method somewhere in the code it is constructed\n like this:\n

import * as petStore from \"petStore\";\nimport { create } from \"petRepository/fileSystem/create\";\nimport { hasQuota } from \"storageQuota/fileSystem/hasQuota\";\nconst createPet: petStore.create = create(hasQuota);\n\n// The code that creats a new pet does not know\n// about the quota dependency\ncreatePet(\"Kitty\");\n

\n This approach solves the issues I listed, but feels a little clunky. Especially\n passing dependencies to methods is, at least for me, a thing I would need to get\n used to.\n

\n I'd love to hear your feedback and thoughts on this topic, this is an ongoing\n exploration of mine, so keep checking back here or on\n my Twitter for updates.\n

\n","slug":"towards-class-less-javascript","hero":"!undefined"}],["turn-your-ship-around",{"title":"Turn Your Ship Around!","subtitle":"Book review","abstract":"The workbook to implement intent-based leadership in your organization\nis as concrete as it gets for books that promise changing your organization\nfor the better.\n","date":"2016-12-27T10:00+02:00","html":"\n

\n Turn Your Ship Around! by L. David Marquet is\n as concrete as it gets for books that promise changing your organization for the\n better.\n

\n Based on the famous book about his tour on the nuclear submarine USS Santa Fee,\n where Marquet faced the challenge of his career of becoming the commanding\n officer on the worst performing ship in the entire US Navy but managed to turn\n it into the best performing within two years, the workbook lays out concrete\n exercises to implement what Marquet developed: intent-based leadership.\n

Intent-based leadership

\n The method is essentially a helper to codify behavioral change throughout an\n entire organization. By making decisions observable by others it enables the\n transfer of decision making power to \"lower\" levels; which is what you\n want in any complex and complicated environment today. By pushing authority to\ninformation, as Marquet calls it, decisions are made where they need to be\n made: where and when the action happens, and not many layers distant from it.\n

\n The idea is simple: to have leaders on every level, even at levels where\n individuals are not used to lead. Obviously this skill is not inherently\n existent everywhere in the organization so Marquet lays out the ideas and\n concepts to equip them with mechanisms of Control (put them in control of\n their actions and results), Competence (give the the technical knowledge to\n make the right decisions), and Clarity (give the the understanding of the\n organization's purpose).\n

\n You will get more than two dozen exercises that can be executed in a few minutes\n and yield material for your team right away. The book is so applicable, that no\n trainer is need, and there are companies that just by following the book, have\n saved hundreds of million $.\n

\n It not only tackles the common decision fatigue in organizations where it's more\n important to not make an error then to make a bold move but makes you discover\n invisible red-tape, which alone are potentially limiting your ability to\n innovate and create compelling products.\n

\n The most important aspect of intent-based leadership in my opinion is that it\n establishes deliberate learning towards a common goal which enables\n organizations to grow and become truly agile.\n

\n","slug":"turn-your-ship-around","hero":"!undefined"}],["typesafe-stack-outputs-cdk",{"title":"Type-safe stack outputs in AWS CDK","subtitle":"AWS CDK","abstract":"In order to ensure that the outputs of your CloudFormation Stacks are typed properly, you can use this technique.\n","date":"2022-08-11T01:00+02:00","html":"\n

\n In order to ensure that the outputs of your CloudFormation Stacks are typed\n properly, you can use\n this technique.\n

\n","slug":"typesafe-stack-outputs-cdk","hero":"!undefined"}],["unboss-a-compendium-for-future-organizations",{"title":"Unboss: A compendium for future organizations","subtitle":"Book review","abstract":"Book review of Unboss by Lars Kolind and Jacob Bøtter\n","date":"2016-06-10T08:00:00.000Z","html":"\n

\n Unboss is a remarkable book. Lars Kolind, Jacob Bøtter and over\n 60 contributors created a blueprint for future organizations. Instead of\n offering bite-sized action-plans like many other books dealing with\n organizational development Unboss explains underlying principles and reasons\n why organizations need to change and establishes a solid foundation explaining\n how to build the next generation of organizations and work for the next\n generation of workers: those that truly care for meaningful relations,\n purposeful work and global sustainability.\n

\n They don't try to offer a simple change-plan because an unbossed orgnization\n is so radically different from the orgnizational model that was established over\n a hundred years ago that any attempt to offer a smooth transition is futile.\n

\n This could be the reason why Unboss has not seen much interest since its\n publiation in 2012, and hard-copies are not easy to aquire. It's a whopping 310\n pages and due to it's questionable use of typographic ornaments to highlight\n certain key phrases it is not an easy read. But believe me, it is worth it.\n

\n Its great value lies in finding words for a gut feeling: there is something\n fundamentally wrong with established industries. Most organizations are running\n full steam into disasters because they stick to their traditional management\n models. Recent events like the VW scandal are just the tip of the iceberg. We\n now see it loosing some chunks. Soon, more and more chunks will break off until\n suddenly the whole iceberg flips around. Those that are on top now will vanish\n without knowing what hit them.\n

\n In chapters like Unboss communications the book proposes a new way to\n integrate employees, customers and partners into the dialoge with the customer.\n Information must flow freely and decisions must be made where they are the most\n effective not where an artificial hierarchy has appointed the appropriate\n point of contact. Enabling everybody to hold honest conversations, internally\n and externally, requires know-how and information to be available to anybody.\n Most organizations still work with need-to-know models that protect and enable\n power over others through conceiling and controlling the flow of information.\n Unbossing the communication means that this power must vanish but this calls\n for answers to the fears of mid-level managers losing their power; they need new\n and better ways to get what they truly strive for: the appreciation of their\n coworkers.\n

\n This is the hard part when changing organizations. It can't be answered in a\n book. The What is up to you!\n

\n","slug":"unboss-a-compendium-for-future-organizations","hero":"!undefined"}],["unicode-cheat-sheet",{"title":"Unicode Cheat Sheet","date":"2010-11-16T00:00:00.000Z","html":"\n

\n | | |\n | ----- | -------------------------------------------------------------------------------------------------------- |\n | ♥ | BLACK HEART SUIT](http://decodeunicode.org/de/u+2665) |\n | · | U+00B7 MIDDLE DOT](http://decodeunicode.org/u+00B7) aka middot |\n | © | COPYRIGHT SIGN](http://decodeunicode.org/de/u+00a9) |\n | ✔ | U+2714 HEAVY CHECK MARK](http://www.decodeunicode.org/de/u+2714) |\n | ✘ | HEAVY BALLOT X](http://www.decodeunicode.org/de/u+2718) |\n | ← | LEFTWARDS ARROW](http://www.decodeunicode.org/de/u+2190) |\n | ↑ | UPWARDS ARROW](http://www.decodeunicode.org/de/u+2191) |\n | → | RIGHTWARDS ARROW](http://www.decodeunicode.org/de/u+2192) |\n | ➜ | HEAVY ROUND-TIPPED RIGHTWARDS ARROW](http://decodeunicode.org/de/u+279C) |\n | ➔ | HEAVY WIDE-HEADED RIGHTWARDS ARROW](http://decodeunicode.org/de/u+2794) |\n | ↓ | DOWNWARDS ARROW](http://www.decodeunicode.org/de/u+2193) |\n | ' | Typografische Anführungszeichen links DOUBLE LOW-9 QUOTATION MARK |\n | ' | Typografische Anführungszeichen rechts LEFT DOUBLE QUOTATION MARK |\n | « | LEFT-POINTING DOUBLE ANGLE QUOTATION MARK](http://decodeunicode.org/de/u+00ab) |\n | » | RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK](http://decodeunicode.org/de/u+00ab) |\n | ⁰ | SUPERSCRIPT ZERO](http://decodeunicode.org/de/u+2070) |\n | ¹ | SUPERSCRIPT ONE](http://decodeunicode.org/de/u+00b9) |\n | ² | SUPERSCRIPT TWO](http://decodeunicode.org/de/u+00b2) |\n | ³ | SUPERSCRIPT THREE](http://decodeunicode.org/de/u+00b3) |\n | ⁴ | SUPERSCRIPT FOUR](http://decodeunicode.org/de/u+2074) |\n | ⁵ | SUPERSCRIPT FIVE](http://decodeunicode.org/de/u+2075) |\n | ⁶ | SUPERSCRIPT SIX](http://decodeunicode.org/de/u+2076) |\n | ⁷ | SUPERSCRIPT SEVEN](http://decodeunicode.org/de/u+2077) |\n | ⁸ | SUPERSCRIPT EIGHT](http://decodeunicode.org/de/u+2078) |\n | ⁹ | SUPERSCRIPT NINE](http://decodeunicode.org/de/u+2079) |\n | ⚠ | Warning |\n | ⌀ | Average |\n | ○◔◑◕● | Harvey Balls |\n

\n","slug":"unicode-cheat-sheet","hero":"!undefined"}],["use-internetofshit-as-a-reminder-to-build-safe-and-usable-IoT-products",{"subtitle":"Tech Talk","title":"How i use @internetofshit as a reminder to build safe and usable IoT products","abstract":"an ad-hoc tech talk about an inspirational Twitter account","date":"2023-09-19T13:30:00.000Z","html":"\n

\n Today I did an ad-hoc tech talk for my team where I talk about what the Twitter\n account [at]internetofshit can teach us cloud engineers about what to consider\n when it comes to designing solutions for the internet of things:\n

https://www.youtube.com/embed/FlTWph4At6o

\n","slug":"use-internetofshit-as-a-reminder-to-build-safe-and-usable-IoT-products","hero":"!undefined"}],["usergroups-rheinmain",{"title":"Usergroups RheinMain","abstract":"Unter usergroups.rheinmainrocks.de habe ich ein Projekt gestartet, dessen Ziel es ist, einen umfangreichen Überblick über das Angebot der Technologie-Usergroups im Rhein-Main-Gebiet zu geben. Der konkrete Mehrwert besteht darin, dass die Daten zu den Usergroups von jedem selber gepflegt werden können. Es wird lediglich ein GitHub-Account benötigt.","date":"2013-01-29T00:00:00.000Z","lang":"de","html":"\n

\n Unter usergroups.rheinmainrocks.de habe ich ein Projekt gestartet, dessen\n Ziel es ist, einen umfangreichen Überblick über das Angebot der\n Technologie-Usergroups im Rhein-Main-Gebiet zu geben. Der konkrete Mehrwert\n besteht darin, dass die Daten zu den Usergroups von jedem selber gepflegt werden\n können. Es wird lediglich ein GitHub-Account benötigt.\n

\n Auf dem Webmontag #47 am 8. April 2013 werde ich einen Ignite-Vortrag zum\n Thema Usergroups halten. Darin werde ich versuchen, ein möglichst komplettes\n Bild der im Rhein-Main-Gebiet aktiven Usergroups zu zeigen. Zur Vorbereitung für\n den Vortrag muss ich natürlich Informationen zu den Usergroups sammeln. Ein\n Einstiegspunkt bietet die ausführliche Auflistung auf\n RheinMainRocks.de/usergroups. Praktischerweise hat die Linux-Usergroup\n Frankfurt gerade ein Großtreffen aller Usergroups im Rhein-Main-Gebiet\n angestoßen, Details dazu finden sich hier.\n

\n Um aus diesen ganzen Bestrebungen etwas nachhaltiges zu schaffen habe ich nun\n das UGRM-Projekt gestartet. Kern des Projekts bildet ein GitHub-Repository mit\nXML-Daten, das zum einen frei verfügbar ist, aber auch die Pflege der Daten\n durch jedermann ermöglicht und dabei den Aufwand zur Einpflege von neuen\n Einträgen und Änderungen auf ein Minimum reduziert. Mit Hilfe von Pull Requests\n können Daten zum Projekt beigesteuert werden, die sich in der Regel mit nur\n einem Mausklick in die Stammdaten übernehmen lassen. Dafür sorgt vor allem, dass\n die Beschreibung der Usergroups mithilfe von XML erfolgt und so eine feste\n Struktur vorgegeben ist. Dies erleichter erheblich das Anlegen und Überprüfen\n der Daten – ein XML-Schema gibt den Rahmen vor.\n

\n Die Visualisierung der Daten erfolgt unter usergroups.rheinmainrocks.de –\n der zugehörige Quellcode ist ebenfalls frei auf GitHub verfügbar. Auch hier\n sind Pull Requests gerne willkommen.\n

\n Nun sind alles Technologie-Usergroups aus dem RheinMain-Gebiet aufgerufen, ihren\n Einträge anzulegen oder zu erweitern, Logos zur Verfügung zu stellen und ein\n Foto der Gruppe auf dem nächsten Treffen zu machen. Neben den reinen statischen\n Informationen zur Usergroup können auch die nächsten Termin hinterlegt werden.\n Der Eintrag der PyUGRM zeigt die volle Ausprägung der anzeigbaren Daten.\n

\n","slug":"usergroups-rheinmain","hero":"!undefined"}],["value-types",{"title":"Value Types","subtitle":"TypeScript","abstract":"Value Types are are used to enable runtime validation of parameters. This provides a simple and expressive way to ensure their validity and convey their semantic meaning in code at the same time while making this transparent for the caller.","date":"2018-06-27T10:00+02:00","html":"\n

\n This technique is a variant of\n Value Objects which I have\n been using for many years, in different languages. The gist is that you create a\n boxed value, which encapsulate business rules for a value, which cannot be\n attribute to a primitive value, like a string.\n

\n Let's assume I have a class which allows sending of emails to a user:\n sendEmail(email, subject, text). All three parameters are strings:\n

class Mailer {\n  /**\n   * @param string email\n   * @param string subject\n   * @param string text\n   */\n  public async sendEmail(email, subject, text) {\n    // ...\n  }\n}\n

\n It's now very easy when programming against this method to construct a correct\n invocation, with nevertheless invalid arguments:\n

// email argument is not an email\nm.sendEmail(\"John Doe\", \"Hello\", \"Text ...\");\n

\n It is also easy to flip the order of the arguments, because they are all typed\n as string:\n

// email argument is not first\nm.sendEmail(\"Hello\", \"Text ...\", \"john@example.com\");\n

\n If we instead turn email into a value object, we can mitigate these kinds of\n errors:\n

class EmailValue {\n  constructor(email) {\n    if (!isValidEmail(email)) throw new TypeError(\"Not an email: \" + email);\n    this.email = email;\n  }\n}\n

Now the first example is no longer possible:

// throws TypeError\nm.sendEmail(new EmailValue(\"John Doe\"), \"Hello\", \"Text ...\");\n

\n The second example has become less likely to happen, because it's easier to spot\n in an IDE that the first argument is an object, not a string, and it is easier\n in our implementation to detect wrong arguments. Value Objects also enable us to\n have domain contracts about certain values shapes in one central location and\n not beeing replicated in all places, where we need to validate e.g. that an\n argument looks like an email address.\n

class Mailer {\n  public async sendEmail(email, subject, text) {\n    // Validate by shape, not by content using a regular expression\n    if (!(email instanceof EmailValue))\n      throw new TypeError('email must be EmailValue!');\n    // ...\n  }\n}\n

Safer, but harder to understand

\n Having built the fourth iteration of this technique in my projects, I recently\n noticed one disadvantage: it increases the complexity of the calling code. Let's\n compare the two examples.\n

Without value objects:

const { Mailer } = require(\"@acme/mailer\");\n\nconst m = new Mailer(\"localhost:25\");\nm.sendEmail(\"john@example.com\", \"Hello\", \"Text ...\");\n

With value objects:

const { Mailer, SmtpHostValue } = require(\"@acme/mailer\");\n// let's share global domain value objects!\nconst { EmailValue } = require(\"@acme/values\");\n\nconst m = new Mailer(new SmtpHostValue(\"localhost\", 25));\nm.sendEmail(new EmailValue(\"john@example.com\"), \"Hello\", \"Text ...\");\n

\n We now require the caller to construct the arguments first using the correct\n value objects, before calling the actual method. This is well within the idea of\n failing fast but the problem here is that we move the knowledge about\n parameters details to the outside world. The caller needs to know exactly which\n Value Object class to import, and in case we need to refactor our implementation\n we have increased our the code surface which might be affected by that.\n

\n We also increased the screen real-estate our code needs in order to get executed\n which puts a toll on readability and comprehensibility. Especially for\n developers who are not familiar with this concept constructs like this one seem\n counter-intuitive:\n

m.sendEmail(\n  // \"new\" in an argument?\n  new EmailValue(\"john@example.com\"),\n);\n

Last but not least: using instances of value objects becomes cumbersome.

Imaging the sendEmail method returns the email it has sent:

class Mailer {\n  public async sendEmail(email, subject, text) {\n    // Validate by shape, not by content using a regular expression\n    if (!(email instanceof EmailValue))\n      throw new TypeError(\n        `email must be EmailValue! \"${JSON.stringify(email)}\" given.`\n      );\n    // ...\n    await this.transport.send(...);\n    return {\n      email, subject, text\n    }\n  }\n}\n

For the caller letter.email is now an object:

const letter = await m.sendEmail(\n  new EmailValue(\"john@example.com\"),\n  \"Hello\",\n  \"Text ...\",\n);\ntypeof letter.email; // object(EmailValue)\n

\n In order to access the value they would need to either know that an EmailValue\n has a email property:\n

letter.email.email; // 'john@example.com'\n

\n This is weird and leads to generalizing the primitive value through having\n them implement a .toString() method:\n

class EmailValue {\n  // ...\n  toString() {\n    return this.email;\n  }\n}\n

so consumers of the value can stringify it:

`${letter.email}`; // 'john@example.com'\n

\n Unless the value object is no longer a string but e.g. a float, or composite\n value which can no longer be usefully represented as a string:\n

class SmtpHostValue {\n  constructor(hostname, port) {\n    this.hostname = hostname;\n    this.port = port;\n  }\n}\n

Although one could intuitively tend to implement it like this:

`${new SmtpHostValue(\"localhost\", 25)}`; // 'localhost:25'\n

\n the problem here is that the string representation can not be used to construct\n the value object:\n

new EmailValue(`${new EmailValue(\"john@example.com\")}`); // this works\nnew SmtpHostValue(`${new SmtpHostValue(\"localhost\", 25)}`); // this doesn't\n

\n To be fair: in many cases you will simply be passing through value object\n instances. But my experience showed that it gets especially tedious when\n marshalling data to and from representation, e.g. when sending them via JSON or\n receiving JSON input.\n

Value Types: call me, like you mean it

\n I was looking for an alternative way and what I wanted to achieve was to keep\n the promises of Value Objects, but to reduce the overhead for the caller.\n

\n One design decision was to remove the need for the caller to know about Value\n Objects, they should be able to call methods with primitive values ... we are\n after all writing TypeScript code and I don't want to add additional bloat to\n it. Also I wanted to address the boxed value problem: you should be able to\n directly use the value instead of needing to reach into the box.\n

class Mailer {\n  public async sendEmail(\n    email: string,\n    subject: string,\n    text: string\n  ): Promise<Letter> {\n      // ...\n  }\n}\n\ntype Letter = {\n    email: string;\n    subject: string;\n    text: string;\n}\n

\n I removed the boxing of values, but kept the semantics and shareable validation\n of values through the introduction of Value Types which are built on top of\n io-ts which combines run-time validation and\n TypeScript types.\n

This is how sendEmail is implemented:

class Mailer {\n  public async sendEmail(\n    email: string,\n    subject: string,\n    text: string\n  ): Promise<Letter> {\n    email = validate(EmailValue)(email);\n    await this.transport.send(...);\n    return {\n      email, subject, text\n    }\n  }\n}\n

Let's look at the details:

email = validate(EmailValue)(email);\n

\n validate is a method which is able to validate an argument against a given\n Value Type. EmailValue is such a Value Type. validate will throw a TypeError\n if an invalid argument is passed. For our method this means, we ensure that\n email actually contain a string with a syntactically correct email address\n according to our domain specs. We have also explicitly expressed the developers\n intention: email is a valid email address. In case the caller passes an\n invalid email address they will receive the TypeError.\n

\n It's important to note that email stays of type String, and also in the\n returned letter, the caller can now access its properties naturally:\n

const letter = await m.sendEmail(\"john@example.com\", \"Hello\", \"Text ...\");\ntypeof letter.email; // 'john@example.com'\n

Code

This is the implementation of validate:

import * as t from 'io-ts';\nimport { PathReporter } from 'io-ts/lib/PathReporter';\n\n/**\n * This function takes one of the value types to validate a parameter.\n *\n * Example:\n * const u = validate(URLValue)('https://example.com')\n * // typeof u === 'string'\n *\n * @link https://github.com/gcanti/io-ts\n * A: static (runtime) type\n * O: output of encode\n * I: output of decode\n * @throws TypeError\n */\nexport const validate = <A, O, I>(\n  type: t.Type<A, O, I> | t.ArrayType<t.Type<A, O, I>, A, O, I>,\n) => (value: I): A => {\n  const result = type.decode(value);\n  if (result.isLeft()) {\n    throw new TypeError(PathReporter.report(result).join(''));\n  }\n  return result.value as A;\n};\n

And the email value type is implemented like this:

import * as t from 'io-ts';\n\nconst emailRegex = /.+\\@.+\\..+/;\n\nexport const EmailValue = new t.Type<string, string, string>(\n  'Email',\n  (s): s is string => typeof s === 'string',\n  (m, c) => (m && emailRegex.test(m) ? t.success(m) : t.failure(m, c)),\n  a => a,\n);\n

Summary

\n Value Types are are used to enable runtime validation of parameters. This\n provides a simple and expressive way to ensure their validity and convey their\n semantic meaning in code at the same time while making this transparent for the\n caller.\n

\n","slug":"value-types","hero":"!undefined"}],["webmontag-offenbach-turns-10",{"title":"WEMO♥F turns 10","abstract":"On the next Monday, February 23rd 2015, I'll be at a run-down place that used to be a super market and hosting the 10th Webmontag Offenbach.\n","date":"2015-02-17T18:00:00.000Z","html":"\n

\n On the next Monday, February 23rd 2015, I'll be at a run-down place that used to\n be a super market and hosting the 10th Webmontag Offenbach.\n

\n While compiling the impressively long line-up for the newsletter which I send\n out before the event to the people who have registered on\n Webmontag Offenbach's website I realized that it is time to\n celebrate a little.\n

\n It all started over two years back when I bitched once again about the\n Webmontag Frankfurt beeing on the other side of Frankfurt\n and I wanted to have a similar event in Offenbach. Up until today we are still\n the only community-driven, non-profit tech-event in Offenbach!\n

\n Getting it started was easy: I set a date and spread the word about it. Just a\n few days afterwards I was approached by Lutz Jahnke,\n who owns the location WEMO♥F has been guest at now ever since: the\n afip!. This location has been the backbone of the\n event and without it the Webmontag Offenbach couldn't be. It's location in the\n city center makes it easy to reach by public transport and beeing a former\n supermarket it perfectly conveys Offenbach's charme: beeing pragmatic to the\n absolute bare minimum.\n

\n After the first Webmontag it became harder to attract speakers–this has improved\n a lot and we never were short on talks in the end anyway. It's not easy to find\n the balance between effort and result for events but I feel that the way I run\n the WEMO♥F works out. I focus on delivering a great evening for the people at\nthe location. Everything else is secondary. I default to \"No.\" when it comes\n to changes and extras and if they happen, somone else has to take\n responsibility, not me. That removes a lot of burden from my mind. And every bit\n more you have to take care of for an event will cost you a lot energy, and\n always more than you've expected. That's also why there can only be one answer\n to the question: \"What's next?\" Let's do 10 more WEMO♥Fs like we did the last 10\n and see …\n

\n I'd like to thank everyone who made the Webmontag Offenbach possible, it became\n a part of the community work I still enjoy doing.\n

Now head over and sign up for #10: wemoof.de

\n","slug":"webmontag-offenbach-turns-10","hero":"!undefined"}],["what-not-to-be-sorry-about",{"title":"Don't say \"sorry\" for things you can't control","subtitle":"Personal Handbook","abstract":"At work I don't like when people say sorry about something they can't control. I prefer they either just acknowledge it, or tell me what they are going to do about it.","date":"2025-12-28T12:38+01:00","html":"\n

\n At work I don't like when people say sorry about something they can't control. I\n prefer they either just acknowledge it, or tell me what they are going to do\n about it.\n

\n","slug":"what-not-to-be-sorry-about","hero":"!undefined"}],["why-i-love-barcamps",{"title":"Why I love BarCamps","subtitle":"Interview","abstract":"I was interviewed during the DeveloperCamp 2017 about BarCamps.","date":"2017-07-11T11:00+02:00","html":"\n

\n At the DeveloperCamp 2017 I was interviewed about\n why I ❤️ BarCamps. I also explained why I organize BarCamps like\n BarCamp RheinMain,\n LeanCamp Frankfurt,\n AUGENHÖHECamp … myself.\n

\n You can find full interview\n here.\n

\n","slug":"why-i-love-barcamps","hero":"!undefined"}],["why-i-threw-up-in-my-mouth-when-reading-accelerate-xlr8-by-john-kotter",{"title":"Why I threw up in my mouth when reading Accelerate (XLR8) by John Kotter","subtitle":"Book review","abstract":"Asking your employees to think different for a better\ngoal and simultaneously forcing them to follow the old, \nleft-side methods, which the right-side is trying to get \nrid of, is nothing but insanity.\n","date":"2016-12-31T10:00+02:00","html":"\n

\n In Accelerate, which the publisher HBR dubbed XLR8 to make the word\n look, you know, more accelerated, John Kotter summarizes his body of work since\n 1974 and ideas from previous publications dating back to 1996’s Leading Change\n about organizational change. He concludes that organizations need to develop a\n Dual Operating System in order to sustainably adapt to chaotic markets which\n he has observed in the 1% of the top-performing companies under his discretion.\n

The Dual Operating System

\n In his observation, when organizations transition from the start-up phase to a\n bigger organization, they develop—for a short period of time—the ideal state:\n the strong, informal network of the early days, where everybody is involved in\n every activity and thus knows what is going on combined with necessary\n processes and hierarchies to deliver a more predictable output. The emerging\n hierarchy will soon take over and the network succumbs because of employees\n natural tendency to prefer stability over variety. This state of a juvenile\n organization is able to deliver innovative products as well as doing so\n efficiently and that is what organizations should aim for: running a network\n organization without hierarchies, performance management and organizational\n boundaries (the right side which is governed by leadership principles) alongside\n your traditional, hierarchy (the left side which is governed by management\n principles).\n

\n What follows is a rather good explanation of how to start the network by\n introducing and enabling a team of change agents and how to get them working\n towards a common vision that moves the organization forward. In his terms, The\n Big Opportunity describes in concrete and understandable language, and in a few\n paragraphs, what the organizations aims to achieve in order to make an impact in\n the market and sustainably move the needle:\n

\n
\n [In contrast to a vision] a well-crafted statement of a Big Opportunity sounds\n less like finger pointed inward at the managerial and employee children [e.g.\n
\n
\n
\n 'you are not the most innovative'] and more like a finger pointed outward at\n a rainbow [e.g. 'we can achieve X by doing Y'].\n
\n
\n

\n The Big Opportunity is the center of the networks activity and used to rally the\n Volunteer Army which will work outside of their usual hierarchies to develop\n new, innovative solutions that are fed back to the left side where they are put\n into operation. These changes translate into 'wins' which are publicized\n throughout the whole organization and will increase the acceptance and the\n reputation of the network which will lead to more volunteers and an ever\n increasing rate of improvements and bigger wins for the whole organization. Thus\n the title: Accelerate.\n

Innovation for free

\n The Volunteer Army is not only voluntarily deciding to work as part of the\n network, but does so on their spare time, and this is how Kotter sells the\n dual operating system to CEOs: because working in the network, for The Big\n Opportunity and freed from the constraints of the left side, employees will do\n this on top of their regular work they still need to do for the left side.\n So companies will get the benefits of establishing the right side for free. He\n strengthens this multiple times throughout the book and explains that if\n motivated by The Big Opportunity, employees will work 150% 'in a\n well-functioning dual system'.\n

\n
\n Think of the parent who has no spare time but somehow makes time, without\n shirking other commitments, when his or her child needs tutoring to do well in\n school. Or the man who is 'exhausted' at the end of a workday yet is building\n a twenty-five-foot boat in his backyard with energy that comes from … where?\n
\n

\n I threw up in my mouth, when reading this. These claims are outlandish for many\n reasons. First, the parent example is not sustainable long term, and they are\n putting extra effort in for their family not a company. The second example\n works only because what is getting worn out during work in today's businesses\n are cognitive resources. Coming home from a computerized workplace working on\n spreadsheets does not affect your ability to creatively wield a hammer and a\n saw.\n

\n This also favors employees that can afford to work overtime, usually single,\n young workers. But employees that work part-time or have important liabilities\n outside of the companies will have a hard time finding extra time to work in the\n network. This is important to understand, because if your network is mostly\n consisting of a uniform selection of the organization's members, the creativity\n and innovativity of its ideas will suffer. A focus on diversity is a must to\n effectively deal with worldwide and chaotic markets.\n

This is insanity.

\n But what is even worse is his idea that the network part is entirely dependent\n on the benevolence of the left side, because it has no budget on its own, and\n network members still need to fulfill their left-side duties and are subject to\n left-side performance management processes.\n

\n
\n Q: How do I keep enthusiastic volunteers from shirking their regular jobs?
A: A well-run hierarchy does not allow this. The whole system of bosses,\n measurements, performance appraisals, and accountability catches and corrects\n shirking.\n
\n

\n Asking your employees to think different for a better goal and simultaneously\n forcing them to follow the old, left-side methods, which the right-side is\n trying to get rid of, is nothing but insanity.\n

Just barely touching the details

\n Throughout the book he gives many vague and one named example of an\n implementation of this system which don’t go into much detail. Although the book\n closes with a Q&A section, the answers there are only repeating what has been\n written in the few chapters before and can be downright insulting to the reader:\n

\n
\n Q: What is the single biggest challenge creating a dual system?
A: Getting started, and in the right way. And the right way is what I have\n outlined in the previous two chapters.\n
\n

\n I doubt that the Dual Operating System is sustainable. Kotter never gives the\n impression that at some point the left-side should lose its dominance over the\n right side. But this is an inevitable development because otherwise the network\n will stay in the chokehold of the hierarchy, and this is what he so clearly\n describes earlier in the book:\n

\n
\n Since the hierarchy side of the organizations tends to control resources […]\n it begins to quietly, yet systematically kill off the network side of an\n organization.\n
\n

\n I can only recommend this book for Kotter’s explanations on how to start and\n structure an initiative that kick-starts a network organization. But the\n execution he describes is dangerous in its shortsightedness and contradiction.\n

\n","slug":"why-i-threw-up-in-my-mouth-when-reading-accelerate-xlr8-by-john-kotter","hero":"!undefined"}],["wordpress-quellcode-als-store-dekoration",{"title":"WordPress-Quellcode als Store-Dekoration","date":"2011-12-28T00:00:00.000Z","lang":"de","html":"\n

\n Der Sankthorst-Concept-Store in der Zeilgalerie in Frankfurt verwendet als\n Dekoration an seinen Schaufenstern und Aufzügen Auszüge aus dem Quellcode von\n WordPress. Zu sehen ist das auch auf den Grafiken der Internetseite.\n

\n Es läuft einem schon kalt den Rücken herunter, wenn man dieses negativ-Beispiel\n für PHP-Quellcode, in riesigen Lettern tapeziert sieht.\n

Fotos von der Dekoration finden sich hier.

\n","slug":"wordpress-quellcode-als-store-dekoration","hero":"!undefined"}],["working-in-distributed-teams-the-three-most-important-challenges",{"title":"The three most important challenges","subtitle":"Working in distributed teams","abstract":"This post series is a summary of my talk about the challenges working in remote teams and how I dealt with them.","date":"2016-02-02T11:40:00.000Z","html":"\n

\n This post series is a summary of my talk about the challenge working in\n distributed teams\n I held at this year's TopConf in Linz.\n

\n It's a 40 minute talk so I decided to split it into three separate posts, each\n on focusing on one challenge:\n

\n","slug":"working-in-distributed-teams-the-three-most-important-challenges","hero":"!undefined"}],["working-remote-celebrate-successes",{"title":"Celebrate successes","subtitle":"Working in distributed teams","abstract":"This is not so easy as it sounds: because we are pushing out updates to our products every day, a natural date to celebrate does no longer manifest itself. As a manager we have to take care of this, too.","date":"2016-02-02T11:43:00.000Z","html":"\n

This post series is a summary of my talk about the challenge working in\ndistributed teams.\nFind the other parts here.

\n In an environment where we are continuously pushing out changes it is hard to\n find clear milestones or even changes that are “big”. If you work in an\n organization that is a web based business you work towards processes that allow\n for multiple updates per day you will have a dozend bugfixes, new features and\n adaptions per week.\n

\n This is good! Being able to release and adapt quickly is one of the key factors\n of the successfull organization. But you lose these “ahhh we just worked months\n to release this thing, lets lean back and celebrate” moments.\n

\n But this is important. Celebrating and praise is something everyone will\n remember and also creates the understanding that everyone contributes towards a\n common goal.\n

\n Because it will be hard to exactly pin the moment when everyone has achieved\n something outstanding at the same time you as a manager need to keep track of\n the progress and arbitrary decide when it is time to party!\n

\n On the picture you see me during the ICANN 50 conference in London in 2015,\n where we celebrated with our partners and especially as a team the launch of the\n .hiv TLD. I will never forget this day in my entire career and even if I wore a\n silly hat this strengthened our bonds as a team.\n

\n I told you before that it is very important to bring people together once every\n now and then … obviously this is a good occasion to celebrate, too. But\n sometimes it can take a while if this is possible, so my last protip is …\n

Protip #5: Send everyone a cake!

I mean who doesn’t like cake?

\n … the idea is that even if your team is distributed you can organize for them to\n have a special gift so you can celebrate your victory via video chat on that\n day. In general you learn what everyone in your team loves and send them a\n present once in a while. The idea is to take some of your time and invest it in\n the happiness of your coworkers. For me this is my primary job. And yes, we can\n achieve this with a lot of process work, but these small things are really fun,\n too! So, that’s all I have today …\n

Closing notes

\n I hope I gave you some ideas how to bring more joy to your remote team\n experience! It's basically all about creating trustful and deep relationships\n with your coworkers and this is something that can be achieved even in a\n distributed team.\n

\n","slug":"working-remote-celebrate-successes","hero":"!undefined"}],["working-remote-fix-the-missing-watercooler",{"title":"Fix the missing watercooler","subtitle":"Working in distributed teams","abstract":"The most important challenge when working in distributed teams is the missing watercooler. Here is how to fix it.","date":"2016-02-02T11:41:00.000Z","html":"\n

This post series is a summary of my talk about the challenge working in\ndistributed teams.\nFind the other parts here.

\n The watercooler is a symbol for a central place in an office building where\n everyone walks by multiple times per day and which enables informal, accidental\n meetings.\n

\n How important this place is can be seen in this picture: this is the atrium in\n the Pixar Headquarter. Steve Jobs himself altered the initial concept of the\n architect and placed facilities like the restrooms, cafeterias, meeting rooms\n next to each other in a central location to ensure employees need to leave their\n seclusion and bump into each other once in while. For Jobs only this would\n enable great ideas to form, information to spread and problems to be solved\n quickly. It also facilitates building relationships with colleagues and a sense\n of belonging. This obviously is lacking if you have no physical office but it is\n vital for every creative team to have an insight into what is happening in the\n whole organization.\n

Working out loud

\n The way to fix this is probably not new to you but I can’t stress it enough:\n Start working out loud. You need to provide your coworkers with a constant\n stream of information about:\n

what you are working on
what your impediments are

\n With this information available everyone can start making the connections to\n their own projects and contribute to solutions for your problems. This can’t\n happen if you are away from your coworkers and only share a finished result of\n your work once every other week. Obviously there is the need for a tool for that\n and by all means do not use email!\n

\n I am having great results by using a team chat like Slack\n for the asynchronous sharing of what’s happening. Even if you don’t know Slack,\n you will be familiar with the concept of chat rooms: a tool like Slack enables\n you to have as many rooms as you like. This is different to Skype for instance\n where you only have a contact list and ad-hoc group chats. In Slack (or IRC if\n you like) a history of messages is kept and even if people join a room at a\n later point, they can re-read everything that has happened regarding the topic.\n Everyone is able to start following a certain topic and can contribute to it.\n

There are usual three kinds of rooms:

\n Long-lasting general topic like #tech, #marketing and #hiring - I’d\n say they usually emerge around every role you have in your organisation; you\n could say these are communities of practice … but are also used to\n communicate news from these groups to the whole company in a less technical\n way.\n
\n Project-specific topics like #website-relaunch or #our-mobile-app in\n which you exchange about the progress of the project, these usually have a\n diverse mix of people from all disciplines.\n
\n Short-lived topics like #launch-of-big-feature, #special-event which\n deal usually have a high volume of exchange only for a few days and then can\n be discarded.\n

\n This granularity helps to better control the amount of information they will\n need to consume because following everything is impossible. You need to care\n about this! Of course we as developers have channels where every commit from our\n repositories is posted, but I don’t get notified about every message in such a\n channel, I selectively read them a few times a day. Slack enables you to specify\n notification settings per channel and even have different settings depending on\n the device so you can have more notifications if you are on your desktop or only\n a few important ones if you are traveling. Make sure that the tool you are using\n has this type of granularity when it comes to notifications and educate all your\n users about them.\n

More bandwidth: video chat

\n So much for the asynchronous part of working out loud but you will also need\n something that has a lot more bandwidth than text: video chat.\n

\n Everything that develops into a discussion with more than a few messages should\n be taken to video. I always enjoy using\n Google Hangouts but if you don’t want to use\n Google services (like we did at my last company) you should check out\n Goto Meeting which is free for\n even more than three people and worked for my team very good. Both services\n offer a screen sharing option which is a real important feature for\n collaboration … and a universal one; yes there is software that enables\n real-time collaboration directly in your apps but screen sharing is universal.\n If you need to remotely fix things on coworkers computer,\n TeamViewer is great. All these tools work\n cross-platform which you need to keep in mind, too (and I am neither on Mac nor\n on Windows).\n

\n Video chat not only has more bandwith than text but it also enables nonverbal\n communication which is really important to fully understand each other. We often\n used it to hang out together with microphones muted and listening to music but\n everyone could just speak up to the room if they had a question. And sometimes\n people just need to vent, yes this may sound stupid but there is for instance\n something called rubber duck debugging which is a real thing!\n

… also for check-ins

\n Besides the ad-hoc meetings for increased bandwidth and the occasional team\n hangout during the day I use videochat for all recurring meetings like daily\n stand-ups. I call them check-ins.\n

\n Yes I know that there are tools that can collect daily stand-up information\n asynchronously (iDoneThis,\n Umantis Daily Highlights,\n a Slack bot) but I’m\n convinced that you should use every chance you have to actually see and hear\n each other.\n

\n The daily standup is where everyone states what they are working on and\n what their impediements are. This takes just a minute per person and should\n be done after 15 minutes. Impediments need to be resolved immediately so we\n have reserved an additional 15 minutes after the daily for 1-on-1s to\n resolve any pending issues. Everyone in the team knows to keep this slot\n free for ad-hoc meetings. After that you can spread out again. Because the\n daily stand-ups deal with detailed technical topics we only did them within\n people of the same profession like developers, marketing, business people.\n
\n Once a week we then had a product meeting which brought together a wider\n range of people, usually the product owner and if needed other specialists.\n This meeting took between one and two hours on every Monday and was used to\n plan the upcoming week and readjust the backlog.\n
\n And finally there were our weekly lunches: Once a week on every Tuesday at\n 1pm everyone would gather together for a lunch. This is a great meeting\n because of its informal nature and you have a perfect ice-breaker for free:\n “what are you having for lunch over there?” That’s always fun! During the\n weekly lunch we’d go through every department and provide a brief update of\n what has happened. Bringing everyone together again creates the opportunity\n for cross-chatter and random connections.\n

\n By the way: this is a large flatscreen where we connected to our remotees …\n what’s especially nice is that this large screen gives them a real physical\n presence because it provide a life-size image and a loud sound. And yes, getting\n the technology right is always a pain. You need good internet connections,\n good webcams (go for HD!) and\n good headsets … don’t go cheap on those.\n

\n But occasionally every technology will fail. Usually the internet connection of\n one person or the chat or video service entirely … which brings me to my first\n protip:\n

Protip #1: Have a fallback ready

\n In our case we usually had problems with the internet connection of one of our\n colleagues and some times goto meeting was down. So we made sure that everyone\n knew how to switch over to a telephone conference provider. The information was\n available in the wiki and as soon as problems arised we quickly switched to the\n fallback without much waiting in order to continue quickly without to many\n failed attempts. Obviously this requires you to a) find a fallback and b) test\n it once in a while. For video conferencing we used Talky as\n an alternative. And alternative for a not working internet connection is using a\n different medium, which is phones. MyTelco provides\n free dial in conference rooms, and usually everyone has flatrates on their\n phones these days.\n

So many tools, I know … That’s why, my second protip is:

Protip #2: Define a communication escalation process!

\n What this means is that you establish a common understanding in your team, which\n communication tool is used for what. At my last workplace we had these rules:\n

\n Slack is the main communication medium used to push information and to clarify\n questions, it is agreed upon that everyone is free to read messages in Slack\n whenever it suits them. It is asynchronous and everyone must be okay with the\n fact that there may be hours between your question and a response.\n
\n The authorative tool for managing tasks was not Slack but a task tracker (I'd\n recommend Trello). This is where you create an agreement about who is doing\n what and when. If you have an emergency you may call someone on his cellphone\n … and if you can’t answer a cell phone call you are supposed to call back as\n soon as possible.\n
\n We also defined for the IT what classifies as an emergency. Basically only if\n our product was not usable by all our customers, for instance if the server is\n down.\n
\n There was also a special email address you could use to report bugs that\n directly affect individual customers. We guaranteed that emails sent there\n would be dealt with within two hours during regular business hours.\n

But protip #3 is the most important one:

Protip #3: Everybody should work remotely, at least some days a week.

\n And here is why: if you never experience working remote you won’t understand how\n it feels to be cut off the water cooler and to not be included in the “offline”\n chatter or how important great equipment is. And this is especially true for the\n CEOs in every company. Go and scout a coworking space, work from home or even\n more crazy: visit your remotees …\n

Coming up: quality together-time

\n The second most important challenge is to ensure that the few occasions you will\n spend face-to-face with your colleagues is quality time.\n Read about it in Part 2 of\n this series.\n

\n","slug":"working-remote-fix-the-missing-watercooler","hero":"!undefined"}],["working-remote-quality-together-time",{"title":"Quality together-time","subtitle":"Working in distributed teams","abstract":"The second most important challenge is ensure that the few occasions you will spend face-to-face with your colleagues is quality time. Here is how to achieve this.","date":"2016-02-02T11:42:00.000Z","html":"\n

This post series is a summary of my talk about the challenge working in\ndistributed teams.\nFind the other parts here.

\n The few times you spend together with your employees face to face should be\n quality time!\n

\n If you have\n fixed the missing watercooler\n you are still not learning much about the personal quirks everyone has, but this\n is important for a good understanding of each others motivations and fears.\n That’s why you simply must bring everyone together regularly, at least every\n other month. Yes, this requires a lot of effort and it costs money! And to focus\n on getting everyone to know each other better, this occasion should not be spent\n with business-as-usual activities.\n

\n Focus on activities that require interaction and profit off physical presence\n which is doing retrospectives, doing 1-on-1s or even lunch and dinner.\n

\n For us it worked best to have all-hands on Tuesday and Wednesday. The remotees\n would travel on Monday and Thursday which left the weekend untouched for them\n and also prices for flights are lower if you don’t travel on fridays or the\n weekends.\n

\n And this is the important part: you need to make sure that they feel the effort\n of traveling is worth it.\n

Protip #4: Plan every hour - make their stay worthwile!

\n When bringing people together for an all-hands meeting it is important to not\n only take care of their activities during the day but the complete trip has to\n be planned and prepared in advance. You need to be their host! This may sound\n superfluous but I for me this is an import part of making room for the\n connection building part that is the purpose of these events.\n

Take care of their individual travel preferences.
\n Let them arrive on the afternoon before so they are relaxed when the all-hands\n starts.\n
\n Pick them up on arrival because they are usually not accustomed to the local\n modes of transportation. Also take care of their departure!\n
\n Organize for their accomodation: staying with colleagues is awesome, but make\n this opt-in only, not everyone likes having people at their homes or staying\n over at other peoples places. Pay for hotels and don’t force them to share\n rooms.\n
Plan the days but also the evening activities.

\n An important side note: especially remote work is attractive for people that are\n introverts. Therefore it is important for every group activity you plan to keep\n this in mind. You should always find a polite way to offer everyone a way to\n opt-out of an activity or provide an alternative that allows them to recharge.\n

Coming up: celebrate successes

\n Having everyone in one place is the perfect occasion to celebrate successes!\n This is not so easy as it sounds: because we are pushing out updates to our\n products every day, a natural date to celebrate does no longer manifest itself.\n As a manager we have to take care of this, too.\n Read about it in Part 3 of\n this series.\n

\n","slug":"working-remote-quality-together-time","hero":"!undefined"}],["your-agile-practice-is-a-dementor",{"title":"Your agile practice is a Dementor","subtitle":"interaction-free space is required","abstract":"Can we have space for people whose energy is drained by all the interaction that is promoted in all agile methods?","date":"2017-12-30T18:58+01:00","html":"\n

Here is something for you #agile practitioners to do in 2018:

Can we have space for people whose energy is drained by all the interaction\nthat is promoted in all agile methods?

\n In case you haven't noticed: everything focuses on human interaction and all\n material focuses on how to \"design\" human interaction so that it yields results.\n

\n What I don't see in books, articles, vides is a strong reminder that many will\n have their energy drained by constant interaction.\n

\n Of course, there is an implicit space between activities which some people\n will actively use to retract and recharge.\n

\n But not everybody can muster the courage to actively do so, if the environment\n we as agile coaches and trainers are presenting the ideal does not mention\n \"alone-time\"; they will see their need to have solitude as something\n unfavorable.\n

It is not!

Please mention this in your training material, books and videos.

\n","slug":"your-agile-practice-is-a-dementor","hero":"!undefined"}],["your-code-of-conduct-applies-everywhere",{"title":"On Code of Conducts","subtitle":"Conferences","abstract":"Your event’s Code of Conduct extends beyond the event and it’s digital spaces","date":"2023-05-16T15:00:00.000+01:00","html":"\n

\n We had an interesting discussion at SoCraCan about\n whether we should allow people to attend the event, if they had behaved in a way\n that violates the event’s Code of Conduct outside of the event. What if that\n person “behaves” during the event? Wouldn’t it be unfair towards them to exclude\n them? Maybe they have changed?\n

\n To me there is only one clear action that an organiser can take: do not allow a\n person to join your event if they have shown behaviour that would harm the\n safety of any participant. Otherwise, allow people to enter your space that\n otherwise would create harm to others. Event though this would be technically\n outside of your event’s space, it nevertheless does not create a safe space\n for all participants according to your Code of Conduct.\n

\n There simply is no separation between “outside” and “inside” behaviour when it\n comes to harassment and toxicity. You, as an organiser, owe it to your\n participants to do everything possible to prevent harm from being created.\n Trusting the harasser on that is not a smart move.\n

\n","slug":"your-code-of-conduct-applies-everywhere","hero":"!undefined"}],["your-team-needs-a-vision-and-common-values-to-succeed",{"title":"Your team needs a vision and common values to succeed","abstract":"Having a vision and a set of values will empower your team and remove a lot of potential for misunderstandings from your day to day interaction within your team. This helps them to focus on their work instead of arguing about it and build momentum because it removes uncertainties about what should be done.\n","date":"2015-09-06T21:54:00.000Z","html":"\n

\n During this year's Socrates Conference¹ I\n attended a session that questioned the importantance of\n techology² for the\n overall success of projects—and I agree. Technology is just a tool, that\n can be replaced easily and has usually mo major influence in the project\n success. If your tech stack is built with robustness and modern software\n development principles in mind\n (S.O.L.I.D.³,\n Domain Driven Design⁴, Tell don't\n ask⁵, Hypermedia System\n Architecture⁶) you'll end up with software whose\n implementation can in part or in total easily be replaced by any other\n technology. It is therefore the people in your project that are vital for the\n long-term success. They cannot be replaced because changing only one team member\n will change the entire\n team⁷.\n But keeping your team intact and everyone committed to doing exceptional work\n requires the establishment of two things:\n

\n a vision that is well understood and provides clear guidelines for\n measuring the success in achieving it\n
\n a shared set of values with clear examples of how these values affect the\n daily work.\n

\n Only if these two things are given, a team can act truly agile, meaning that\n each team member can assess if their actions are contributing towards the vision\n and ensure that the way they solve their current task will be acceptable in the\n project's scope.\n

\n The process of defining a good vision and especially of finding common values is\n hard but in my opionen should be undertaken immidiately when you start your\n project—or startup—and re-evaluated everytime the the team changes.\n

What is a good vision?

\n Embracing agile principles means that you want your team members to be able to\n push forward and decide on their own which part of the project needs their\n contribution. They should think like an entrepreneur and this needs their\n understanding of the overall goal. This is where a vision works as a guide\n because it can answer this simple question:\n

\n
If I do this, will it take us closer to reaching our vision?
\n

\n A good vision inherently provides an answer to this question because it\n describes what goal should be reached, by which action and how to know when the\n goal is achieved. It is important to stress that the vision needs to be clear\n and well understood amongst your team members. Otherwise it will create\n confusion and in the worst case confliction actions will be taken.\n

Just compare these two real-world examples from two companies I know:

\n
\n We develop digital solutions, which suit people’s needs and thus help make\n their lives easier.⁸\n
\n

\n
\n Developers use our service to easily build, deploy, and manage their\n containerized services as well as collaborate on and share their architecture\n templates.⁹\n
\n

\n Where the first example is just a hollow promise to deliver everything the\n customer asks for the second example provides a much more detailed explanation\n of what the core business is and tells about the deciding factors when measuring\n their success.\n

What are values?

\n Having a vision is important not only because it provides guidance for your team\n members every day but also provides identity which helps to attract new talent\n and give new hires a clear scope for their work. It is equally important to\n provide and answers this question:\n

\n
Is it ok to do it this way?
\n

\n Where the vision provides guidance for the What do we do? values provide\n guidance for the How do we do it? which has even more potential for conflict.\n In an environment where failure is part of the process it is critical for all\n parties to understand why something is a failure. If your team has misalinged\n values it might be seen as failure by one person to rush out a software release\n without proper testing (better safe than sorry) where the other person might\n think of this as taking an acceptable risk (speed over safety). Both can be\n totally acceptably behaviours on their own but are conflicting in the same\n context.\n

What are good values?

\n If you don't provide values as well, you create room for frustration. Like a\n good vision good values not only are easily understandable but also provide\n clear guidance for acceptable behaviour. They are much more individual to the\n team and should be established by the whole team. There are some exceptional\n good examples to get you started, like The 10 Buffer\n Values¹⁰, Zappos Core\n Values¹¹.\n

tl;dr

\n Having a vision and a set of values will empower your team and remove a lot of\n potential for misunderstandings from your day to day interaction within your\n team. This helps them to focus on their work instead of arguing about it and\n build momentum because it removes uncertainties about what should be done. This\n invest is something you should consider making.\n

\n","slug":"your-team-needs-a-vision-and-common-values-to-succeed","hero":"!undefined"}],["zugriffe-nach-host-sortiert-aus-apaches-access-log-auslesen",{"title":"Zugriffe nach Host sortiert aus Apache`s Access Log auslesen","abstract":"Dieses kleine Bash-Kommando listet die Zugriffe in einer bestimmten Zeit (20/Oct/2008:21 = am 20. Oktober 2008 zwischen 21:00:00 und 21:56:59) und sortiert diese nach Häufigkeit.\n","date":"2010-05-10T00:00:00.000Z","html":"\n

\n Dieses kleine Bash-Kommando listet die Zugriffe in einer bestimmten Zeit\n (20/Oct/2008:21 = am 20. Oktober 2008 zwischen 21:00:00 und 21:56:59) und\n sortiert diese nach Häufigkeit.\n

cat access_log | grep \"20/Oct/2008:21\" | awk '{ print $1; }' | sort | uniq -c | sort | tail\n

Beispiel:

  2 66.249.71.205\n  2 83.7.105.44\n  2 88.80.205.184\n  3 38.113.234.180\n  3 93.158.151.25\n  4 72.14.199.10\n  6 72.30.142.245\n 24 67.195.37.90\n 48 85.180.64.152\n 57 80.109.85.214\n

\n","slug":"zugriffe-nach-host-sortiert-aus-apaches-access-log-auslesen","hero":"!undefined"}],["øredev-2022",{"title":"Øredev 2022","subtitle":"Conferences","abstract":"A look back at this years Øredev in Malmö; one of the best for-profit tech conferences I have attended so far","date":"2022-11-14T00:00:00.000Z","html":"\n

\n Having had the change to attend Øredev in 2019 as a\n speaker I was hooked; this conference is one of the few commercial conferences\n that I have truly enjoyed attending. First, there is a fantastic team of\n organizers who have created this conference to strengthen the tech scene in\n Malmö; the main goal therefore is to connect the local tech scene with an\n international audience and not like on many other for-profit conference to boost\n a brand or product ecosystem. It's about people.\n

\n This is also clearly visible in the way sponsors (at Øredev called partners)\n interact with attendees: most bring developers to their booth, because direct\n solicitation to hiring is not allowed by the organizers. That meant that I had\n the opportunity to talk directly with developers, and founders from companies\n like INGKA, 55degrees,\n and other small and large companies and learn about the way they work, the tools\n they use and how they collaborate. For me this is an important aspect of going\n to a conference... meeting new people in my industry and building new\n connections.\n

\n Another cool detail I want to mention: the attendee badges were intentionally\n designed in a way that made it hard to read names from a distance, so sponsors\n could not just snap a quick picture but had to ask for getting close to the\n badge in order to see the name. The QR code on the back that gives access to the\n attendee details is also not easy to scan. The organizers encouraged sponsors to\n have real conversations and not hunt for contacts. Which in my experience worked\n very well.\n

\n But of course, the main reason I go to conference is to get insights into topics\n that are or will be relevant to my work. So let's recap the talks I've seen. By\n the way, this was the first time that I've attended a conference\n without using Twitter. During the conference\n I've used Mastodon to share about the sessions I went to.\n There were very few attendees and speakers who used this social network, so the\n ability to connect to others was definitely impacted, but I think it is only a\n matter of time until Twitter is no longer the main social media platform in use\n at conferences (actually there were\n quite some posts on LinkedIn tagged with #oredev).\n

Opening Keynote: Always time for tea (Allan Kelly)

\n Allan Kelly gave the opening keynote. He talked\n about how we can optimize time spent on projects, and how bad humans are a\n estimating time. But they are good at working against deadlines. The more closer\n to a deadline we are the better we are in finishing on time. Deadlines work best\n when they are in short, repeating intervals ... like the Sprints of Scrum.\n

\n Working against short deadlines also gives you the opportunity to release a\n working product and start creating revenue quickly. Now, looking at how we\n structure the work to be done Allan points out that Backlogs are bad, because\n they do not scale. They just keep growing. What is needed is a clear vision so\n what needs to be done next can be identified when the current work item is done.\n Having (and knowing) the higher purpose is in the end more profitable than\n focusing on profits alone ... because plans never work, they are rarely good,\n and when a plain fails, it's demoralizing.\n

\n But don't forgo planning, it's effective for small iterations, but don't overdo\n it.\n

\n Allan closes with a call to have small, lightweight planning processes, because\n they are both more humane and effective.\n

\n I mostly got my project planning philosophy confirmed during\n this talk.\n

🐘 Toot

Four years of team self-selection at Redgate Software (Chris Smith)

\n Chris Smith's\n talked about how Redgate enables employees to regularly change teams\n despite its commonly assumed that changing teams is hurtful for productivity.\n However for Redgate is not. It actually helps to distribute knowledge and\n culture, and helps people to change teams to support their personal development.\n

\n Main takeaway: Regular re-teaming can help to spread knowledge in the\n organization and make onboarding of new employees much smoothers.\n

🐘 Toot

Aligning Architecture with Responsibility Indices (Michael Feathers)

\n In\n his talk\n Michael Feathers talked about\n Responsibility Indicies.\n

\n He elaborated how we can create understanding for a software system that allows\n us to reason about which components are responsible for which business task.\n

\n He mentions\n Object Design: Roles, Responsibilities, and Collaborations\n by Rebecca Wirfs-Brock where she introduces the concept of responsibility driven\n design.\n

\n My main takeaway from the talk was that we tend to look at systems from the\n perspective of responsibilities and until now it seems that we didn't pay enough\n attention to that. And many techniques (like architecture diagrams, use cases,\n DDD) focuses on creating an inventory of what is there now, but don't contain\n the knowledge/vision about what should be.\n

🐘 Toot

How to control insanely complex stuff in a simple way (Gojko Adzic)

\n Gojko Adzic\n talks\n about feedback systems, which are really everywhere, and a lot of software works\n because they use feedback systems.\n

\n This talk is inspired by Goijko's reading of the the book Feedback Systems:\n An Introduction for Scientists and Engineers Åström, Karl Johan and Murray, Richard M. (2008).\n

\n Feedback systems can be used in production to detect defects, even if we do not\n understand the cause of the problem, but we can look at the behavior of the\n system to see if it behaves correctly, or not.\n

\n By focusing on business metrics to inform on the health of our system we\n decouple the error detection from the implementation and make it more robust and\n more easier to understand.\n

\n If we apply that to TDD, where the difficultly to write tests for a system is\n the sensor, then we are well advised to understand that we need to change the\n design of system. The feedback systems however helps us here to only discover\n bad design, not good design.\n

When designing feedback systems there are a few caveats to watch out for.

\n My main takeaway was that we do use feedback systems quite often, and they\n can help us to improve complex systems, but understanding the theory behind it\n will prevent us from making stupid mistakes.\n

🐘 Toot

Deep down the rabbit hole of state management and server cache (Natalia Tepluhina)

\n Natalia Tepluhina's talk was very hands-on.\n She introduced the state-management library\n TanStack Query that is available for all\n popular frontend frameworks and aims to simplify typical workflows when\n interacting with RESTful APIs, similar to the Apollo library for GraphQL APIs.\n

\n It was very helpful to get a quick intro to this library and talk to Natalia\n about it a bit after her talk.\n

🐘 Toot

Opening keynote Day 2: Jenny Radcliffe

\n The opening keynote is from\n Jenny Radcliffe and she talks\n about social hacking. I was familiar with her story already from\n this great Darknet Diaries episode\n about her.\n

🐘 Toot

Reawakening Agile with OKRs (Alan Kelly)

\n In another #oredev session by Allan Kelly, this time hearing from him about\n #OKRs\n

\n First, Allan points out that Agile in most organizations is too much bureaucracy\n and too little moving the teams towards learning and improving.\n

\n OKRs can help here, because they help to formulate the necessary tasks to move\n towards the organizations goal.\n

\n But they can be easily misused, so watch out for them being used as command &\n control in disguise.\n

\n However they have the potential to enable teams to work autonomously but still\n provide information to other teams about their deliverables. But it shouldn't\n cascade (one teams objective depends on another teams key result); it needs to\n be combined in collaboration not in dependencies.\n

\n If you add #OKRs, don't add them on top of other inputs for what a team works\n on, but EVERYTHING must be expressed in OKRs, otherwise they will be effective.\n

\n And this can be done every sprint, and can replace your backlog. Imagine how\n great this could be if you create alignment within the organization this\n consistently.\n

\n He wrote a book about it:\n Succeeding with OKRs in Agile (2021),\n and is for sure worth checking out.\n

Btw,

\n My main takeaway here was that\n OKRs can only work\n well, if\n

everything we do is expressed as OKRs
they are created togethers as a team, not on an individual level

\n Additionally I'd like to mention that this is\n how Morningstar (the tomato company) works:\n there teams create contracts every year between each other.\n

\n For me this sounds that ideally teams are re-teamed every time OKRs are defined.\n I asked Alan about it during lunch and he didn't have experience with that, yet.\n

🐘 Toot

Event API Products: Maximizing the Value of Your Event-Driven Architecture (Hari Rangarajan)

\n This talk was the only disappointing one. It was a product demo disguised as a\n talk. To be fair, the\n talk description\n at the bottom mentioned that it \"includes a demonstration of building and\n consuming an event API product using Solace PubSub+ and AsyncAPI\" but there was\n little value for me from the introduction to event APIs, given that I already\n have experience building them.\n

🐘 Toot

Keep it simple! How to apply KISS principle in modern frontend (Nir Kaufman)

\n This\n session\n by Nir Kaufman was really fun.\n

\n Nir started with an quick history of frontend technologies. Then showed\n Backbone.js as a simple example for a UI framework and showed how to use it with\n React. That was 12 years ago. Now we have much more JavaScript libraries in our\n frontend code. He proposed how to we can make it easier again.\n

don't support all potential use cases, just the ones you need to support today
not backwards compatibility

\n Keeps on to introduce\n WebComponents,\n which are today widely supported and provide a framework for reactive apps,\n but has 0 dependencies, because it runs natively in browsers.\n

\n Nir proposes a lean stack using small, functional utilities that solve one thing\n only and can be composed: A layered stack using Preact\n for UI, TypeScript for Logic & state\n mangement, and some functional UI libraries like [https://date-fns.org/],\n lodash, and Axios.\n

\n It was good to hear from an experienced frontend developer, that the way I\n prefer to build frontend apps is sound, although I personally don't see the\n value of Axios over fetch.\n

\n I found Nir at the party later and asked him why he in the end did not propose\n WebComponents for his K.I.S.S. stack: in his experience it is still not ready\n for production because it is challenging to integrate it with existing\n libraries.\n

🐘 Toot

Architecture for Flow with Wardley Mapping, DDD, and Team Topologies (Susanne Kaiser)

\n Susanne Kaiser's\n talk\n was intense and packed. She spoke about how to optimize architecture for flow,\n using Wardley Mapping, Domain-Driven Design and Team Topologies.\n

\n First, we cannot improve the performance of a whole system by only improving the\n individual parts. Therefore we need to understand how the individual components\n work together to solve the user's needs, and which components need more\n attention then others (because their are mature or commodities).\n

\n But, there is no software without people, so we also need to look at how to set\n up the teams in a way that optimizes flow. This is where the work done in Team\n Topologies comes into play. Combining that with the Wardley Map we can identify\n areas in our project that changes often and therefore requires a high amount of\n collaboration in order to achieve fast flow (of change). Now brining in DDD\n which helps to subdivide the project into distinct domains allows to identify\n value in each subdomains.\n

\n Combining these three techniques allows to get a good overview of the current\n state. The goal is to have an architecture that is optimized for flow which\n moves as much components to the right side of the map as sensible so teams can\n focus on building the essential, and unique components that provide a\n competitive advantage.\n

\n It's critical to identify which components can be moved to the commodity\n segment, because if they are not there you might be spending too much money and\n you are lagging behind the market.\n

Once this is done, there will be more resources to improve the core domain.

\n Susanne is working on a whole book about that which is supposed to come out next\n year:\n Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow.\n

\n My main takeaway was that combining these methodologies will yield\n interesting insights into your current organization and help to map out where it\n needs to go. A feedback loop is built-in which allows for course corrections\n along the way. I definitely want to learn more about Wardley Maps and Team\n Topologies (I am quite familiar with DDD).\n

🐘 Toot

Micro-frontends anti-patterns (Luca Mezzalira)

\n Luca Mazzalira distilled the common mistakes he\n has seen in his 7 years of experience working on Micro-frontends.\n

\n They should be independently deployable without coordination with other\n teams.\n
They should also be made for a certain business domain.
They all should use the same UI framework.
They should not implemented hacks for legacy components/microfrontends.
\n He mentions Elm and\n Cycle.JS as examples for good reactive UI\n implementations.\n
Microfrontends should not have bidirectional data flow.
\n Microfrontends don't share global state, they use events to communicate. This\n ensures loose coupling. They avoid calling the same APIs from multiple\n micro-frontends. This could be solved by merging two frontends or wrapping\n them in one parent container that provides the data to both.\n

\n When migrating to micro-frontends, sites can start with partial implementations,\n e.g. only for certain sub-pathes (/catalog). This can be handled on the edge\n (Reverse proxy).\n

\n Blog post with an outlook:\n The Future of Micro-Frontends.\n

\n I personally was mostly curious what an experienced AWS engineer has to say\n about micro-frontends, but I am currently not involved in a project where this\n is needed.\n

🐘 Toot

How to get it right by being wrong all the time (Johan Öbrink)

\n This talk\n by Johan Öbrink can be quickly\n summarized: talk to your users, from day 1, but hearing an inside story from\n one of Scandinavia's biggest banks on how they developed a mobile payment\n solution was nevertheless interesting.\n

🐘 Toot

Playing with serverless and state - Let's create a serverless chatbot! (Karl Løland)

\n In this talk I got a first impression of Azure's Durable Functions, which allow\n to simplify persisting state between invocations. It was helpful to understand\n how to use them. Unfortunately the talk was in parts very slow because a lot of\n boilerplate code was written during the talk in order to get the main points\n across. I wished the coding would have been a recording so the speaker could\n have focused on the details and skipped the uninteresting parts.\n

🐘 Toot

Through the Looking Glass, or the Tech Revolution that Is (Emily Gorcenski)

\n The\n closing keynote of the second day\n by Emily Gorcenski was both inspiring and\n interesting, but I will not attempt to summarize it, watch the recording, it's\n going to be good good!\n

🐘 Toot

The Ethical Engineer (Cennydd Bowles)

\n The keynote of day 3 was held by Cennydd Bowles on\n Ethics, and why we as engineers should care about it and what we can do to\n follow good ethics principles.\n

\n The main takeaway for me was that there are many opportunities to take a\n step back and consider the implications of the systems we (help) develop.\n

🐘 Toot

Why one model can’t fit all - creating fulfilling engineering organizations (Heidi Helfand & Chris Smith & Susanne Kaiser)

\n This\n panel\n was way too short because it was so interesting.\n

\n Heidi Helfand,\n Susanne Kaiser, and\n Chris Smith talked about how to\n get started with improving and changing? Allow teams to experiment and find out\n what is limiting then and what would work for them to improve, but still make\n sure that they don't lose the alignment with the whole organization.\n

\n I got to ask a question on how to motivate people who do not have the need to\n change and we kept the discussion going a bit even after the panel was over,\n because it was way too short. The main takeaway here is to create motivators\n by using team topologies and Wardley mapping to restructure teams in a way that\n separates the people who do not want change from the ones that want and need to\n adapt rapidly and through that creating both the stability reliable products\n need from infrastructure, but also have people who want to work in more dynamic\n settings be able to innovate. That way the innovators can quickly figure out the\n path to the next successful iteration and can through that have good cause to\n ask the \"traditionalists\" for help, which will then hopefully motivate them to\n support the new efforts.\n

🐘 Toot

Why should you care about WebAssembly? (Adrian Cole)

\n I went to\n this talk\n to get a quick update on the state of WebAssembly. While I do not have immediate\n use for it it was interesting to see an example of an\n architecture build with it that allows plugins to be authored using code, which\n allows much more flexibility compared to configuration and much more security\n over using native plug-ins.\n

🐘 Toot

Data Lake with AWS CDK (Krzysztof Slowinski)

\n Krzysztof Slowinski walked us through an\n AWS CDK based implementation of a data lake.\n

\n He is using S3 and data converted to the Parquet\n format to make it more performant for querying.\n

\n The final CDK application involved many services, grouped in 8 stacks. Here CDK\n really shines because it allows to define the solution in a higher level\n language which allows us to easily re-use definitions.\n

\n For me there was not too much to take away, but it was great to chat to\n Krzysztof a bit afterwards about his testing strategies for architectures like\n this.\n

🐘 Toot

Securing Journalists in 2022: Runa Sandvik

\n The closing keynote\n was an interesting experience report from\n Runa Sandvik who works at the New York Times to\n secure journalists.\n

\n She lead with an overview of the current state of technology which provides a\n lot of tools that allow anonymous and secure communication possible relatively\n easy. But it still requires work and making a mistake when using these tools\n could have grave consequences for journalists. The tools have to become even\n easier to use. It's also often unavoidable that journalists use personal tools.\n

Here's how you can help

Google Summer of Code is still around!
Crypto Parties? Let's bring them back
The Tor Project, Freedom of the Press, Signal are hiring
You can also secure at-risk people at a Big Tech company
Try out the tools yourself, such as Lockdown Mode in iOS 16

\n The main takeaway for me was that even journalists, whose life depends on\n secure communication will not do everything to be safe. If the usability of a\n tool is too bad, it will not be used. As engineers, we often prefer very\n technical, precise solutions, but we cannot ignore the fact that we can\n overburden users with too technical solutions.\n

🐘 Toot

Videos

\n Subscribe to\n Øredev's YouTube channel\n where the talk recordings will be published soon.\n

Photos

\n All my photos from Øredev 2022 can be found in\n this album.\n

Acknowledgements

\n My employer Nordic Semiconductor covered the\n costs to attend the conference. Are you interested in a job that let's you\n explore some of the most innovative connected technologies in the world? Check\n out\n Nordic Semiconductor's career page!\n

\n","slug":"øredev-2022","hero":"!undefined"}]]

First Principles

What is enough?

The gap between enough and adequate is your playing field!

I make €101,750 in non-monetary compensation a year

Agile as a starter for organizational transformation?

Agile is a seed, and seeds need a soil

How to release a new version of a package

Patch release 🐞 (fix) 2.3.4 -> 2.3.5

Feature release 🚀 (feat) 2.3.4 -> 2.4.0

Breaking Release 🚨 (BREAKING CHANGE:) 2.3.4 -> 3.0.0

Typical changes

Updated dependencies

Refactoring

How releases are published

Happy releasing!

Command is the new method

Constructing a client

Calling an operation

A complete example:

Updating imports

IoT: Payload is now Uint8Array

Not in v3: StepFunctions

S3

createPresignedPost

SignatureDoesNotMatch error when uploading a file

Custom signed HTTP requests

Removed types

Where will JavaScript be in 5 years?

And will JavaScript still be there in 5 years?

Does JavaScript scale both in the technical sense and within teams?

Is JavaScript a good language for programming beginners?

Not everything is perfect with JavaScript

The Book to understand the toolset Gherkin provides

BDD is reverse decoupled TDD

BDD is for everyone, and any time

When I read The BDD Books: FormulationThen I become a better Software Crafter

Day 1

Opening keynote

Lightning talks

Architecture Workshop with Oliver Zeigermann

Fishbowl

Day 2

OpenSpace

Talk by Elisabeth Whiteley about side-projects

Day 3

Talk by Hege Dreiem about API Design

Talk by Aleksander Olavsrud about Machine Learning

Talk about GraphQL by Pål Thomassen

Talk by Andrew Harmel-Law about Architecture

Closing

Update

Structure of a Proposal

Speaker Profile

Abstract

Notes

5 key learnings

Keywords

Where to find CfPs

Submitting

#paytospeak

Code of Conducts

Now, go and become a speaker!

good architecture makes software easy to change

what matters is the domain

Good example

Bad example

Tip

Absolute Silence

Perfect winter vacation: snow and sauna

The codefreeze unconference

The tests were lying

Debugging code you didn't write

Scaffolding vs. design

What I should have done

Bad

Good

What ES+CQRS gives you

The anatomy of an event

Reducing events to state

Commands: the write side

Patch release 🐞 (`fix`) `2.3.4 -> 2.3.5`

Feature release 🚀 (`feat`) `2.3.4 -> 2.4.0`

Breaking Release 🚨 (`BREAKING CHANGE:`) `2.3.4 -> 3.0.0`

IoT: Payload is now `Uint8Array`

When I read The BDD Books: Formulation
Then I become a better Software Crafter

Web 2.0

Web 1.0