Articles on the craft of software development.
A curated and opinionated list of resources for Chief Technology Officers, with the emphasis on startups - kuchin/awesome-cto
Experiments with microservices and Vaadin applications.
It is always a good thing to benefit from the point of view of others, things are never either black or white and to find your way in this grey area that you’ll have to define is certainly not easy. I really enjoyed reading this article from @dwmkerr because it highlight many good points, the article’s title was carefully chosen to generate some “hype”, it certainly delivered.
<rant> I absolutely despise OpenApi(well, swagger. I’ll call it swagger since it was that for most of my career). It’s supposed to make the process of creating and documenting an API easier. But does it really?… Here’s what I think about it. Writing the swagger schema is so damn tedious From my experience when someone mentions swagger, you’ll get dragged into design first - code later mindset rather quickly. While it sounds good on paper the practical implications of writing a swagger schema just make me want to curl in a ball in the corner of the office. The swagger schema is so explicit and such a pain to write. We’ve got what I’d call a rather simplistic API by corporate standards at my work. I invite you to “design” it first. The swagger definition for it is 19808 lines long. I’m not kidding. Just think about it. 20 fucking thousand lines of JSON. Good luck designing that. Now, some of you will say “but wait a moment, why not generate the swagger schema from code”. While that does sound like a great idea on paper I really fail to see the point of it. If I document my code properly I can already generate documentation that is not going to be as tedious or as explicit. If the code is undocumented, swagger does not provide any sort of a benefit there.