I received an email from Holvi, who provide me with my business bank account. It was a notification that my account number will change. Now, that by itself would be merely annoying, since I soon have to edit this number in various places. However, the nature of that account number change and the reason they gave goes a little deeper, so let me share the background and my thoughts about it.

My business is based in Germany, and Holvi is a fintech company based in Finland (so a fintech in a double sense …). Therefore, my account number was an IBAN starting with FI, the country code for Finland, instead of DE, the country code for Germany. I never had any problems with this. On the contrary, I quite liked having the Finnish IBAN because I felt it was a statement for Europe and the Digital Single Market.

I’m a firm believer in the idea of the European Union, and I’m sure that to foster European innovation, we have to take a European perspective instead of a national one if we want to play a role in a world of superpowers like the US and China. The regulation does not yet make this easy, but I feel we’re getting there.

The Single Euro Payments Area (SEPA) makes it mandatory for banks and companies to offer cross-border financial transactions within SEPA countries under the same terms as domestic transactions. Moreover, Article 9(2) of the regulation bans so-called IBAN discrimination explicitly, which means companies must not require customers to have a bank account in their home country or any other specific place.

As Holvi explains in the FAQ about the change: “Even though the FI-IBAN should work anywhere within the EU, many of our German customers have experienced IBAN discrimination due to the FI prefix.” In other words, this change is giving up and caving in. Now, I don’t want to blame Holvi; this pragmatic decision probably makes sense for them and the affected customers. It would have been nice if this was an opt-in change, though, as I was not affected.

But anyway it’s a negative sign for fintech startups all over Europe because it shows that it’s challenging to offer a product in other countries as there are still companies who practice IBAN discrimination which is, I repeat, an illegal practice. It means that it’s startups and innovators who have to adapt to an “old economy”.

Still, I hope that this is a problem that will be solved over time and Europe will grow closer together (not only) in the financial market. Until then, I will weep a little over my beloved FI IBAN and change it to the DE IBAN.

I’ve talked and written a lot about the importance of good API design. Now, in my latest guest post for Stoplight, I have explored how to design APIs following the CRUD paradigm - created, read, update, delete. While this approach is not necessarily the right one for every API, it works for a lot of them, and those APIs can benefit from consistency throughout the API ecosystem by following best practices. Go ahead and find “CRUD API Design Recommendations From the Field” on the Stoplight blog , where I’m explaining the implementation of recommended URL structures and choosing the correct HTTP verbs.

Disclosure: This work was paid for by Stoplight.

On the past weekend, I attended the Founder Summit 2019 in Wiesbaden. Entrepreneur University, led by the 26-year old Söder twin brothers from the Frankfurt Rhein-Main region, organized this event for the fourth time and it was my first time going.

I enjoy going to meetups, conferences and networking events, but mostly I attend smaller and more tech-focused events. This one was a generic entrepreneurship event with over 5000 attendees, and it had an additional focus on personal development. Therefore, apart from people from the startup ecosystem like founders and investors, they also had a lot of motivational speakers from the coaching scene, who, in turn, drew a more diverse crowd. Those coaches and what they teach are not necessarily everybody’s cup of tea, but there’s no denying that they know how to entertain huge crowds. And talking about entertainment, well, that was probably my first conference where professional dancers, magicians, and musicians alternated with entrepreneurs on stage and every entrance was accompanied by professionally produced videos, music, and light shows.

Also, they put in a considerable effort to get big names to attend. For example, they had two of the four investors from Die Höhle der Löwen, which is Germany’s equivalent of the Shark Tank TV show. Both had interesting insights to share, I especially enjoyed Frank Thelen’s outlook into the future of technology and honest judgment of things like the blockchain, explaining its potential but not succumbing to the hype that surrounds it. Another great talk was by Iskender Direk of Microsoft on Artificial Intelligence (AI). Even though he omitted critical aspects like privacy, his (simplified) description of a day in the year 2029 with new technologies was vivid and well-presented.

To conclude, I had a great time in Wiesbaden, even though I was suffering from a minor cold over the two days, and I would probably attend this event again. Until then I’ll continue going to smaller events which might have less big names and entertainment but are, no less, products of their founder’s love.

On Saturday I attended the first SpeaKonf in Darmstadt, an unconference specifically for conference speakers and those who want to become one. I’ve given a few talks already, such as “To SDK or not do SDK?” at APItheDocs or “Specification-driven APIs vs. Technical Writers” at tcworld, but I’m always eager to learn and improve.

The unconference was a one-day event organized by the Java User Group Darmstadt and supported by cosee, who opened their offices for approximately 40 participants. After a typical BarCamp-style planning session, we filled three tracks with 15 session proposals. Here’s a quick summary of the sessions in which I participated.

The first was about using images in slides. Pictures, especially photos, can support a talk’s message on an emotional level, but they must fit and not feel forced. To be safe in terms of legal compliance, always mention your sources, ideally as a small footnote on the slides itself, and store some proof (i.e., screenshot) of the licensing agreement, in case the source disappears or changes.

The second session was the organizer’s offer to have yourself recorded and analyzed, which I gratefully accepted, though being the only brave person to do so in a group with only three people. But the feedback from the other two was helpful.

After a catered pizza lunch there was a session called “Tag Teach”. It was led by Mirjam, who was a dog trainer before she became a software developer. She explained how conditioning methods, especially positive reinforcement, applied for teaching animals could also be helpful for humans to improve their behavior, for example, their posture or way of speaking in front of an audience. We did a few practical exercises, too.

The fourth session was about self-recording your talks, either for practice or if you want to keep presentations from meetups who don’t record them, so you have reference material when submitting to CFPs.

Finally, the last session was about live coding. We talked about the advantages and risks of live coding during a presentation compared to recorded screencasts and collected some advice for optimizing an on-stage coding session, for example using automation, IDE shortcuts or storing various states of your project so you can quickly access them if necessary.

The day ended with a retrospective. There was a lot of positive feedback, but many including me thought that the diversity of attendees should be improved. Java developers and conference veterans were overrepresented whereas there was a lack of novices and people with a non-technical background and perspective.

But altogether, the trip was worth it, also because of the “hallway track” in which I got to know Ralf who runs docs-as-co.de, a website that advertises a docs-as-code workflow based on AsciiDoc. Talking to him inspired me to dive even deeper into optimizing and automating API documentation.

After explaining the difference between APIs and microservices in an article for the Stoplight API Corner, I wrote a follow-up piece talking about API design for microservices. Even though microservices APIs seem small, it’s important to design them well to build a microservices architecture that performs well. Apart from performance considerations, such as designing non-chatty interfaces, you also need to maintain loose coupling and pay attention when modeling your domain. To learn more, you can read the full post “Designing APIs for Microservices” in Stoplight’s API Corner, which they just migrated off Medium and onto their website. The new blog also has author pages, so you can find an overview of everything I’ve written for Stoplight here.

Disclosure: This work was paid for by Stoplight.

I’ve observed that sometimes people use the words “API” and “microservice” and mean the same thing, or they use the terms in other confusing ways. As the famous adage goes, “there’s only two hard problems in computer science, cache invalidation and naming things”, and it seems to be correct when it comes to terminology in the API ecosystem.

I’m exploring these terms, along with containers, in an article APIs and Microservices that now got the more click-baity editorial headline “Stop Calling your APIs Microservices” and has been published in the Stoplight API Corner on Medium. Go and check it out!

Disclosure: This work was paid for by Stoplight.

Thank you for your interest in my talk Specification-driven API with OpenAPI! I have now uploaded the slides to SlideShare.

Tonight I will be at the bits, bytes & bier #3 meetup in the FinTecSystems office in Linden near Gießen and give a talk called Specification-driven API Design with OpenAPI. It will be similar to last week’s talk, but since it’s a meetup targeted at developer, there will be an emphasis on the OpenAPI specification and less about documentation and the role of technical writers.

Thanks to everyone who was at my talk Specification-driven API vs. Technical Writers. If you want to refresh your memory or if you haven’t been at the talk but still interested in the topic you can now get my deck on SlideShare.

I’m at this year’s tekom conference and fair, also known as tcworld18, and I’m about to give a talk titled Specification-driven API vs. Technical Writers. If you found my website because of it, welcome! The slides will be published by tekom after the conference but I will also share them on this site soon.

I’m on a train right now on my way to London. I’ll be attending the API the Docs London 2018 conference and the first DevPortal Awards Gala, where I have the honor to announce the jury winner for the best overall developer portal on behalf of the jury members. This is also a memorable trip because it’s my first time going to London by Eurostar and also probably the last time that this journey doesn’t involve crossing the borders of the EU.