A software developer’s job is to write code. That’s the reason people hire them. I disagree. I believe a developer’s job is to solve a problem. In a world of SaaS, code libraries, APIs, and automation tools, the best way to solve the problem might be to figure out one or more existing solutions and focus on their integration, instead of reinventing the wheel.
Once, a potential client contacted me who had a specific need for marketing automation involving external APIs. Details are confidential, of course, but they don’t matter for the point I want to make. The client further mentioned he was already working on it with another developer. However, they were unhappy with the work they did and thinking of reassigning the project.
After the client shared the current state of the project with me, I realized that the developer had started implementing a specialized CRM (customer relationship management) tool from scratch. It would have taken some time to complete this CRM before even getting to the API-related work. Thus, I made a suggestion.
I proposed to scrap the whole thing, design a CRM with the required fields in Airtable, and have the client and his employees manage everything through their frontend. Managing structured data in tables is a solved problem, and Airtable is a magnificent tool. Then, I would implement a crontab-triggered service that pulls the data from Airtable via the API and then initiates the required requests on the other APIs. The API results would go back into Airtable. This way, I could focus my work on the value-add for his business, instead of writing generic frontend and data management code.
The client happily accepted, I built it, and he’s now using the system daily. Building headless (frontend-less) integrations with APIs and leveraging existing user interfaces wherever possible might not be the natural and intuitive choice. However, I am confident it can quite often be better and faster than writing your own. It can also help to keep a project with time and budget constraints.
While trying to clean out my saved content in Pocket, I came across an article by Evgeny Morozov published in the SZ (Süddeutsche Zeitung) in German with the title “Für eine radikale demokratische Transformation” (UPDATE: “The left needs to get radical on big tech – moderate solutions won’t cut it” in The Guardian seems to be the English version - thank you Sebastian Lasse!).
In the article, Morozov writes about the “techlash” as a growing feeling that a few dominant corporations have too much control over the Internet. And, as he says, there are basically three types of opposition to the status quo, which I found an interesting classification.
The first type of criticism is economism. It’s mainly focused around the idea that corporations profit off personal data and free labor from the consumers. These should be compensated, for example, through a “data dividend”.
The second type of criticism is technocracy. It identifies monopolies as the main issue and calls for antitrust regulations to break them down and establish more competition in the market.
Morozov says that both of these schools of thought are too limited because they only look at the economy. He identifies a third group who is trying to go beyond the status quo and rethink the purpose of technology in the world and look at data as more than just an economic resource. Essentially, this group is trying to envision a utopia with different rules and new players, including non-commercial ones, and more democratic control. So far, however, this group lacks unity and visibility.
I follow a few initiatives that are part of this third group, such as the IndieWeb movement or Mastodon/ActivityPub, as an alternative approach to social networks. The platform cooperatives movement and some Blockchain-based projects also belong there. And so do tiny indie makers, such as this blog’s host micro.blog. The field is incredibly diverse, but that makes it very difficult to navigate and understand. And, in my opinion, they can’t speak with one voice. The only thing that unites them is the idea that there’s something better than the status quo, but the details vary. Therefore, if we want to limit the power of the technology giants, it might be easier to implement the more straightforward suggestions from the other two groups first. Next, the initiatives in the third group can compete or cooperate on a more level playing field.
There’s also a fourth approach that I sympathize with, for obvious reasons. USV VC Albert Wenger postulates the “right to an API key”. The idea is that companies must make their data troves available in a machine-readable format. In this way, individuals can be empowered to leverage that data in a way that benefits them instead of being limited to the algorithms offered to them.
Next week it’s API the Docs time again. The API conference is coming back to Amsterdam and is sold out! I’m a regular attendee of their events and even was a speaker last year in Paris. This time I’m not speaking, but I’m looking forward to connecting with the community. I booked my train tickets and accommodation this morning and I have some time on the days before and after the conference if anyone wants to meet!
There’s one active role I’m playing for the community, though. For the second time after London last year I’m on the jury of the Dev Portal Awards. Last week I spent some time reviewing many great submissions. I also had two calls with fellow jury members Bob Watson and Anne Gentle as well as Katalin Fogas of Pronovix who’s organizing the awards. I can say that it wasn’t always easy, but we have some winners now! They will be announced at the awards gala that’s happening next week as part of API the Docs and then published online - so stay tuned for that!
One of those solutions is, quite obviously, planting more trees 🌳! And although we can only solve the climate crisis with public measures implemented on a global scale, individual actions are still important. Donating to reforestation projects is one of those actions. Fellow API practitioner Phil Sturgeon has beat the drum a lot lately for a site called offset.earth. The site collects donations for Eden Reforestation Projects but adds a community and gamification aspect on top of it, which I really like:
Every member grows their own virtual forest, and they get a profile URL which displays the trees as well as the impact of the carbon offsetting. The profile can also be used to display other personal goals. Have a look at my profile page at offset.earth/lukas, for example. If you want to make a one-time donation (any amount and payable in EUR, GBP or USD), you can do that on my page to help my forest grows.
Or, if you want to donate regularly (it’s GBP 4,50 a month), you can sign up through my special referral link. Then, you will get your personal offset.earth-URL with your own forest and I will get some “sparkly trees” in mine.
After some months of silence, I’m returning to my blog. And I want to talk about one of the defining problems of our times: climate change, and how to avoid disastrous global warming.
Now, I’m interested in this topic because I believe the scientists who say that we have to act now. But I’m by no means an expert. And neither was my friend Mischa Hildebrand, a physicist and radio journalist turned software developer. However, like (hopefully) you and me, he’s a person that cares about the impact of one’s life on the planet and the people around you. Therefore he has taken the time to write a great piece about climate change.
He says that as humankind, we have to limit our use of natural resources by moving away from growth and expansion. Technological progress is significant, but it won’t save us. It’s a long read but worth your time. And, like a good scientist, the author focuses on analyzing the problem with depth and structure, citing numbers and moral principles, instead of jumping to quick conclusions and solutions.
I can’t urge you enough to go and read Mischa’s article “Climate Change is Not Our Problem.We Are.” and share it on your blogs and social media channels.
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.
The tech industry has a massive impact on the world and our societies, both positive and negative. Social networks have brought people together but have also been detrimental to privacy. Their broad reach and algorithms have helped with the Arab Spring but also with Donald Trump and Brexit. Smartphones require materials that are often mined by child labor. Data centers draw vast amounts of energy.
A few weeks ago I listed to an episode from The New Stack podcast with Anne Curie of the cloud consulting company Container Solutions. Together with London-based diversity-focussed programming meetup Coed:Code, she organized a conference called Coed:Ethics to talk about the impact of the technology industry and what we as professionals should do.
As she told in the podcast, they wanted to produce some tangible results from the conference, and for that, the UN development goals were an inspiration because they offer a low common denominator that is entirely noncontroversial so that everybody can agree on them.
The result is a whitepaper about the state of data center energy usage in 2018, which is at roughly 2% of the entire global energy usage, and a petition to hosters and cloud providers with a simple goal: run all servers with 100% renewable energy in 2024!
I like this goal, and I’ve already signed the petition, and I recommend you do the same. There’s less than 1000 signatures so far - I think we can do much better! Also, I believe the ecological footprint is an excellent way to start a discussion about the ethics of the tech industry before we move to more controversial topics such as privacy.
A month ago I had written about Manna, the cryptocurrency that is issued as a Universal Basic Income (UBI). It was an article in the Union Square Ventures (USV) blog that caused me to sign up for their service. The list that USV compiled contained a few more intriguing projects but, to get started, I wanted to experiment with only one. A few days ago I came across another interesting article about the intersection of cryptocurrencies and UBI, which listed only two examples, Manna and Swift (which was also in the USV list). So I decided to sign up for Swift as well.
The difference between Manna and Swift is that Manna already uses the blockchain while Swift is a centralized digital currency whose blockchain is under development. As far as its website goes, Swift looks a bit more advanced at the moment, for example, it has a complete shop and an API to build transactions around the system. Another critical difference is that Manna will automatically come to your account once a week whereas Swift comes daily but you need to claim it actively and, if unclaimed, new income payments expire after seven days. That means, if you want to use and collect Swift, you should sign in to their website at least once a week. It could be a crucial feature, though, to drive actual adoption and keep the currency valuable instead of having a large number of non-active accounts (“Karteileichen”) holding the coin.
There’s also a referral program, so if you want to try it, please sign up with my link. I’m curious how this space will develop. If I find the time I will play around with the API and offer some services in their shop.
For APIs to be successful, it’s important that they are functionally correct and that they perform well. Testing is a wide field with a lot of different approaches and terminology surrounding them, and it’s also connected to other aspects of the API lifecycle such as monitoring. I have researched and explained some of the major aspects of API testing and I wrote an article about this. You can read it on the BlazeMeter blog or the syndicated copy on DZone.
Disclosure: This work was paid for by BlazeMeter.
Security is an often overlooked aspect of API design. In another guest post for my client Stoplight I have written about the different elements of API security and how the OpenAPI specification allows you to define authentication and authorization for your API explicitly, but also how a specification-driven workflow helps with security in general.
Disclosure: This work was paid for by Stoplight.
As you may be aware, I’m interested in Universal Basic Income (UBI). I believe that it is a useful policy for developed countries to counteract the adverse effects of increased automation and flexibility that leads to less job security. At the same time, I also believe that cash transfers, especially if issued as basic income (what GiveDirectly does), are an effective mechanism for foreign aid.
A while ago, I came across an exciting project called MannaBase. Founded initially as GrantCoin, MannaBase marries the basic income idea with a cryptocurrency. Their concept is that everyone can sign up and receive an equal share of the currency. As it’s a cryptocurrency, people can trade Manna at online exchanges, and that’s how the new money gains value.
What I also like a lot about them is that the People’s Currency foundation that issues Manna has plans to build direct giving instruments directly into the platform so that income recipients can redirect parts of their share to people in need based on demographics.
The only downside to Manna that I see is that it’s a proof-of-work cryptocurrency, which are known to be inefficient. That is something that they, just like everyone else in the cryptocurrency space, has to solve if they want to reach mainstream adoption, but the first steps (such as proof-of-stake or lightning networks) have already been made.
As of now, the weekly distribution has a value of around a single cent, but a project like this is a long shot aimed at the future. Also, to grow the community, MannaBase has a referral program!
So, if you also find this is an inspiring idea, why not sign up for MannaBase with my referral link and collect 50% more Manna for a year?! I’d appreciate that :)
You have never created a machine-readable API specification with OpenAPI because you didn’t know how to start?! Lucky for you, I’ve written a practical tutorial that does a little hand-holding and takes you step-by-step through your first OpenAPI file. It uses Stoplight’s visual editor, so you don’t have to code it in YAML or JSON manually, but I also show you how it looks like under the hood, so you better understand how OpenAPI works.
Disclosure: This work was paid for by Stoplight.
Facebook, Google, Microsoft and Twitter recently announced the Data Transfer Project (DTP) as a way to improve data portability between different services. Naturally, I was intrigued to understand what precisely the DTP is. So I spend a recent ride on the train riding the whitepaper and will give you a little summary here:
DTP provides a Java-based, Docker-deployable open source application that executes bulk tasks with the following workflow: * Authenticate with providers via OAuth. * Export data from one provider through their API and, if necessary, convert it to a standard data model via adapters. Providers can write their own adapters, or third parties can contribute and share them as part of the open source project. * Temporarily store data in encrypted form. * Import data into another provider using their API after, if necessary, converting the standard data model back into the provider-specific format.
A running instance of DTP is called a host. There are different possible models for hosts. One option (distributed) is that a provider itself runs a DTP that allows import from and export to a list of other providers of their choosing. The second option (centralized) is a third party that hosts the infrastructure to exchange data between different providers. The DTP whitepaper suggests that Data Portability NGOs could run such an instance. Finally, the third option (self-managed) means end users are running their own DTP instance.
The DTP only provides software and doesn’t specify any requirements for providers as to with who they have to interact. Every host decides which adapters it makes available and needs to apply for API access with each provider. Also, the whole design of the DTP is for one-time data transfer and does not support continuous synchronization.
My opinion: The DTP is convincing and can certainly help with data portability. Of course, it depends on providers opening up their APIs, although consumer demand and data portability requirements (as in the GDPR) could drive them. Its scope is limited, but I think its data models could be applied even outside this scope for federation and interoperability (or they could become “just another standard …”).
I came across the Kickstarter crowdfunding campaign for Openbook. They call themselves “The honest, open-source & awesome social network”, and their plan is to build a “Facebook competitor” that is open sourced, free of advertisements, and wants to donate a portion of their revenue to charity - but apparently is not decentralized or federated.
I’m not sure what to think about it. On the one hand, I believe we need more alternatives to Facebook, except then I remember that the problem is not that other options don’t exist, but that network effects work against them. It’s already difficult for social media to grow through some hype, venture capital, and unique features. Being “Facebook, but open” is a tough value proposition to sell. I still wish them luck. Their design mocks look fine, and the team also seems solid; they have a founder of PGP on board as well as some non-technical people that could help make Openbook something that doesn’t just cater to computer geeks.