Lukas Rosenstock

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.

The Entrepreneur University 2019 Founder Summit

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.

Speakonf 2019

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.

You can read my API security in OpenAPI article in the Stoplight API Corner on Medium.

Disclosure: This work was paid for by Stoplight.

This is a test post created with the Wrimini app for Android (alpha version).

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.

You can find my tutorial in the Stoplight API Corner on Medium.

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.

Machine-readable API specification formats like OpenAPI are not just for creating documentation but can be a driver for the whole API lifecycle. If you generate them from code you’re leaving half of what OpenAPI can do on the table, so it’s better to develop a specification-first API workflow.

I wrote about this topic as a guest post for Stoplight who offer cloud-based tools around OpenAPI and API design. You can read it in the Stoplight API Corner on Medium.

Disclosure: This work was paid for by Stoplight.

I’m back home in Germany after my two-week workation in Gran Canaria. These two weeks were a great experience but also way too short; as I had a lot of work to do I couldn’t explore as much of the city or the island as I wanted to. So, sooner or later, I have to go there again!

I saw the documentary Banking on Bitcoin last night. The main reason I watched it was that they hosted a screening at this very nice co-working/co-living place called The Roof here in Las Palmas. Regarding the movie itself, it’s obviously outdated since it’s from 2016 and a lot has happened in the cryptocurrency space since then.

What I liked about it: it does a good job demonstrating the beginnings of Bitcoin from the cypherpunk movement, the first startups in the space and their regulation issues as well as the search for the identity of Satoshi Nakamoto. From that perspective, I can highly recommend it.

What I didn’t like about it: the movie contains practically no criticism. Issues like scalability are glossed over, and others like the inefficient use of energy are not mentioned at all. You end up thinking that Bitcoin is without a doubt this great technology that just has to go through growing pains.

I arrived in Las Palmas de Gran Canaria today! For the next two weeks I will be working from the lovely ReStation co-working space and enjoy my free time exploring the city and the beach.

I’ve written and published an article, in which I describe how to create API test cases in Postman and then run them both within Postman as well as its command line companion Newman and finally export the collection from Postman and import it to BlazeMeter for cloud-based functional API testing.

If you’re curious you can read the article on the BlazeMeter blog or the syndicated copy on DZone.

Disclosure: This work was paid for by BlazeMeter.

As promised, I wrote an article about my experience at API the Docs Paris 2018. It’s published on the CloudObjects blog. Looking forward to your feedback!