Batsify
batsify@ruby.social
<p>I am a french who love coding the hard way (no AI), worked for a lot of startups until saturation, hope for a come back of social values instead of monetization of the poorest. Toots in 🇬🇧, please be indulgent.</p><p>Are you French? Take a look at my profile on Chapril: <span class="h-card" translate="no"><a href="https://pouet.chapril.org/@batsify" class="u-url mention">@<span>batsify</span></a></span></p>
Posts
-
Post #2481215
Interesting article on API documentation best practices. The author focuses on web APIs, but I think this article applies to classic APIs (those in our packages or that we generate ourselves for other teams). In short, it&#39;s always advisable to provide two types of documentation: the specifications (the &quot;what&quot;) and the API documentation (the &quot;how&quot;). https://inkwright.inc/blog/your-api-reference-is-not-your-api-documentation #SoftwareDocumentation #a...
-
Post #1943557
I loved this article. It&#39;s something that resonates with me personally and in my professional life. &lt;&lt; Neither decision involves asking the person using the software. The adding is driven by business metrics. The removing is driven by engineering metrics. The user is in neither equation. &gt;&gt; I recommend reading: https://vivianvoss.net/blog/the-feature-creep
-
Post #1943556
We should copy and paste this message onto all open-source projects to avoid any misunderstandings or false hopes: --- You clearly confuse “open” with “we’ll accept anything”. GNOME is open – you can talk to anyone, work on any module and fix any bug. GNOME is also principled – if your code isn’t good, or your feature isn’t desired by some maintainer, it won’t be accepted. If you know that something won’t be accepted, and yet you work on it, good luck. [1/2] #opensource