<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blog on Vojtěch Káně</title><link>https://vkane.cz/posts/</link><description>Recent content in Blog on Vojtěch Káně</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 03 Jul 2025 11:29:49 +0200</lastBuildDate><atom:link href="https://vkane.cz/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Give back useful documentation</title><link>https://vkane.cz/posts/give-back-good-docs/</link><pubDate>Thu, 03 Jul 2025 11:29:49 +0200</pubDate><guid>https://vkane.cz/posts/give-back-good-docs/</guid><description>&lt;p&gt;Just dumping a quick mental meltdown here: Please, pretty please, can we go back to good old &lt;strong&gt;boring&lt;/strong&gt; developers documentation style? I mean those terse articles presenting real new information? Those long walls of text that &lt;strong&gt;nobody ever wants to read&lt;/strong&gt;, but ends up reading because &lt;strong&gt;they contain what one is looking for&lt;/strong&gt;?&lt;/p&gt;
&lt;p&gt;It doesn&amp;rsquo;t have to be so bad. There are well-written documentations that are a pleasure to read, but the core point is that they have to actually convey some facts. It might have just been a bad month for me, but I was confronted with too much screwed-up docs and I think it hadn&amp;rsquo;t been so bad in the past. I am afraid it is an inevitable consequence of replacing real humans with &lt;a href="https://en.wikipedia.org/wiki/Large_language_mode"&gt;LLMs&lt;/a&gt; or simple machine generated garbage. Both of the recent instances were from Google, but I meet it just everywhere. The docs tell the obvious (“To assemble a car, you gotta get a wrench from your box. Beware there are two latches, if you only press one, the box won&amp;rsquo;t open preventing you from obtaining the wrench”) and pretend the rest is intuitive (which it often sort of is) ignoring the parts where one can honestly need to tweak some details (“Then put all parts where they fit. And if you get lost, ask our chat bot”).&lt;/p&gt;</description><content type="html"><![CDATA[<p>Just dumping a quick mental meltdown here: Please, pretty please, can we go back to good old <strong>boring</strong> developers documentation style? I mean those terse articles presenting real new information? Those long walls of text that <strong>nobody ever wants to read</strong>, but ends up reading because <strong>they contain what one is looking for</strong>?</p>
<p>It doesn&rsquo;t have to be so bad. There are well-written documentations that are a pleasure to read, but the core point is that they have to actually convey some facts. It might have just been a bad month for me, but I was confronted with too much screwed-up docs and I think it hadn&rsquo;t been so bad in the past. I am afraid it is an inevitable consequence of replacing real humans with <a href="https://en.wikipedia.org/wiki/Large_language_mode">LLMs</a> or simple machine generated garbage. Both of the recent instances were from Google, but I meet it just everywhere. The docs tell the obvious (“To assemble a car, you gotta get a wrench from your box. Beware there are two latches, if you only press one, the box won&rsquo;t open preventing you from obtaining the wrench”) and pretend the rest is intuitive (which it often sort of is) ignoring the parts where one can honestly need to tweak some details (“Then put all parts where they fit. And if you get lost, ask our chat bot”).</p>
<p>The first one was the YouTube API. I remember (though it can be just dreamed up) seeing Google&rsquo;s API reference in reasonably good shape in the past, but this time, it was all just</p>
<blockquote>
<p>This JSON attribute named <code>x</code> contains x</p>
</blockquote>
<p>with little additional description of the semantics. And if you then mess up different <code>id</code> attributes because you think it&rsquo;s a video that you are handling but it&rsquo;s a playlist item instead (I admit it was my mistake), the API greets you with a pretty useful 403. And yes, thanks for asking, the semantics of the error codes <a href="https://developers.google.com/youtube/v3/docs/videos/update#errors">are documented</a>, except 403 isn&rsquo;t and 404 is guaranteed anyway. ❤</p>
<p>And then I was forced to interact with their serverless functions we&rsquo;ve been using for quite a fer years. They unobtrusively presented that Go&rsquo;s 1.21 runtime is about to be deprecated and later removed so it might be a time for upgrade. For far so good, it is a reasonable decision with a rather generous time schedule. I do a few clicks at the web interface and ha! I can&rsquo;t select a never runtime, 1.21 is the only available one. Can it be related to them deprecating the whole v1 cloud functions stack hoping to push us to v2? That must be documented somewhere, right? We can easily find either a deprecation notice or generally some info on the future of v1 functions or at least find the list of supported execution environments of v1, <strong>right</strong>? Nope. They beautifully retrospectively renamed <em>Google Cloud Function</em> to <em>Cloud Run Functions v1</em> (probably dropping the original <em>Cloud Run</em> product (or just rebranding it is v2? 🤷)) and merged its documentation with v2. They are supposed to be very much compatible, so why bother? Links explicitly marked as documenting v1 point to some shared docs crossroad where you can again pick you are interested in v1 to get to a <a href="https://cloud.google.com/functions/1stgendocs/concepts/overview">short page</a> again pointing you to some v2 resources, pointing you to how to deploy v1 code and how v1 compares to v2 (of course they just claim it is sort of compatible with no technical details).</p>
<p>I thought “Game&rsquo;s not over. We&rsquo;re actually using Firebase, so we can try their docs?”. I was so naive. They are the other extreme I was writing about in the preface: they contain just a lot of examples, but no real information. It&rsquo;s always good to show the audience how to accomplish the most frequent tasks and give them some confidence if the sole theory is too dense. <strong>But you can&rsquo;t skip the theory!</strong> Defining your config format by a collection of snippets is just bullshit even if it is clear how they actually compose together.</p>
<hr>
<p>Alright, I&rsquo;ve probably calmed down by now. Enough ranting, back to useful work. Take this post with a grain of salt as wasting multiple hours on that YouTube HTTP 403 really turned me mad, but I really feel like the best current documentation is usually in the <code>man</code> pages these days. I wish they covered everything out there. Of course it isn&rsquo;t about source format, it&rsquo;s about the style. Boring and terse but always with a preface with motivation and high-level, detailed list of whatever is to be listed, additional sections with security considerations etc and finally a bit of examples both the simple and more convoluted ones. If you feel it the same or on contrary very much disagree (and everything in between), make sure to <a href="https://vkane.cz/contact/">share your thoughts</a>!</p>
<p>If you&rsquo;re reading this and are responsible for a public facing documentation, hear me: it is nice to provide an AI assistant, but keep in mind it can&rsquo;t understand your product if you don&rsquo;t have it written down. LLMs shine at summarizing text and extracting pieces of information on request (“What&rsquo;s the name of the function that does this and that?”) and it can really save one&rsquo;s time. It can probably also generate all those usage examples, so please stop concentrating on what can be automated. Provide us with genuine list of facts and an architectonic overview with forward-references. We can then synthesize what we want with our little brains or use some digital ones if we want to. <strong>Thanks</strong>!</p>
]]></content></item><item><title>I am not dead!</title><link>https://vkane.cz/posts/not-dead/</link><pubDate>Sun, 30 Mar 2025 19:58:44 +0200</pubDate><guid>https://vkane.cz/posts/not-dead/</guid><description>&lt;p&gt;I&amp;rsquo;ve always dreamed about blogging, you know, sitting down revisiting my recent thoughts and presenting them in an organized way to the public. The problem is, I&amp;rsquo;ve always dreamed about so many things that finding time for any particular one was difficult if not impossible. It usually happens by chance that I get back to an old dream and push it a bit. It&amp;rsquo;s most often when I am sick and can&amp;rsquo;t take the regular duties. And guess what? I feel ill today. But that&amp;rsquo;s not the point here.&lt;/p&gt;</description><content type="html"><![CDATA[<p>I&rsquo;ve always dreamed about blogging, you know, sitting down revisiting my recent thoughts and presenting them in an organized way to the public. The problem is, I&rsquo;ve always dreamed about so many things that finding time for any particular one was difficult if not impossible. It usually happens by chance that I get back to an old dream and push it a bit. It&rsquo;s most often when I am sick and can&rsquo;t take the regular duties. And guess what? I feel ill today. But that&rsquo;s not the point here.</p>
<p>I&rsquo;ve found my friends writing recently and it&rsquo;s such a shame that there is near to nothing on my blog. I&rsquo;ve just finished minor infrastructure changes to simplify the publishing process for me and I have some ideas for articles. This time, it must happen! I WANT TO WRITE SOMETHING. Keep your fingers crossed for me :)</p>
]]></content></item><item><title>Donating challenge for 2022</title><link>https://vkane.cz/posts/2022-donating-challenge/</link><pubDate>Mon, 24 Jan 2022 12:55:57 +0100</pubDate><guid>https://vkane.cz/posts/2022-donating-challenge/</guid><description>&lt;p&gt;&lt;a href="https://www.gnu.org"&gt;gnu.org&lt;/a&gt; states:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Free software is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech”, not as in “free beer”.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Yes, sure, free software is a matter of liberty, but that doesn&amp;rsquo;t mean it doesn&amp;rsquo;t cost anything to create it. Right. Some actual money for the servers and most importantly, for the developers. There is tons of free software out there (and in the broader sense, free content, like Wikipedia) and most of it is a passion project of a well-employed nerd with just a few users, so everything is all right.&lt;/p&gt;</description><content type="html"><![CDATA[<p><a href="https://www.gnu.org">gnu.org</a> states:</p>
<blockquote>
<p>Free software is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech”, not as in “free beer”.</p>
</blockquote>
<p>Yes, sure, free software is a matter of liberty, but that doesn&rsquo;t mean it doesn&rsquo;t cost anything to create it. Right. Some actual money for the servers and most importantly, for the developers. There is tons of free software out there (and in the broader sense, free content, like Wikipedia) and most of it is a passion project of a well-employed nerd with just a few users, so everything is all right.</p>
<p>So what&rsquo;s the problem then? <strong>Dependability</strong>. This model works great if you copy a free picture and use it in your design. If you copy a 25 lines long shell script into your cron. If you grasp the general idea from someone else&rsquo;s code and use it elsewhere. If you build your work against a tiny library you could, in theory, write yourself, but it would be too annoying (make sure it is in fact tiny, log4j I am staring at you). But things quickly become hairy, if the target is complex and you need to depend on it for 10 years or so. On such a scale the question is not whether a vulnerability will be found, but rather who will fix it. The community? Communities are <strong>very</strong> powerful. If you&rsquo;ve ever contributed to nixpkgs, asked in an Arch forum, or otherwise engaged in an active community, you know what I am talking about. They can be very lively, write wikis, answer questions, get their hands dirty and contribute code, but they can never do that alone. Small communities are too small and the large ones need someone to lead them (and the project of course). And these leaders need a ton of enthusiasm (might degrade over time) and/or some money to be able to invest enough time into the project.</p>
<p>Now to the point. Reading articles like this one and nodding in agreement (my free-time occupation for the last 6 years) doesn&rsquo;t really help. Surely, large companies are at fault, they should pay for the pillars of their success and their money would matter the most, but does that justify regular users paying nothing? <strong>No</strong>. At least when you can afford it. As a student, I am not exactly bathing in golden coins, but giving the price of a lunch or two a month won&rsquo;t affect my life in any way. It won&rsquo;t change the life of the recipient either, but it may send a good message and if I manage to build a habit of regularly contributing and find a good job, I can easily raise the bar. All of the contributions can be found on <a href="/donating-challenge/">a dedicated page</a>.</p>
<p>If this way of reasoning sound familiar to you, please join me on a journey to more sustainable open content and be so kind and <a href="/contact/">write me about it</a>. I may list you on this site possibly compete with your donated amounts :).</p>
]]></content></item><item><title>Improving detailed prints by changing perimeters count</title><link>https://vkane.cz/posts/3d-printing-and-perimeters/</link><pubDate>Tue, 13 Jul 2021 22:49:50 +0200</pubDate><guid>https://vkane.cz/posts/3d-printing-and-perimeters/</guid><description>&lt;p&gt;I have been printing lots of different badges and other finely detailed objects with no requirements on mechanical properties. They seem to be super easy at first as they are all flat with no overhangs and with only simple bridging. That&amp;rsquo;s all great, but there is a tough part: every minor failure is visible and unfixable. Sculptures can be post-processed with a sharp knife and sandpaper, but badges only get uglier and uglier. It is therefore crucial to slice the models in a way the printer cannot make it wrong.&lt;/p&gt;</description><content type="html"><![CDATA[<p>I have been printing lots of different badges and other finely detailed objects with no requirements on mechanical properties. They seem to be super easy at first as they are all flat with no overhangs and with only simple bridging. That&rsquo;s all great, but there is a tough part: every minor failure is visible and unfixable. Sculptures can be post-processed with a sharp knife and sandpaper, but badges only get uglier and uglier. It is therefore crucial to slice the models in a way the printer cannot make it wrong.</p>
<p>I recently discovered a useful option — <strong>the perimeters count</strong>. It is not a magic wand, but just as you start losing hope, it comes to save your day. For certain shapes, it makes the print much more straightforward and therefore much less likely to fail and also much nicer to look at.</p>
<div style="display: flex; flex-wrap: wrap; justify-content: center;">
<figure class="left"><img src="/posts/3d-printing-and-perimeters/3_perimeters.png"
    alt="Badge sliced with 3 perimeters"><figcaption>
      <p>Badge sliced with 3 perimeters</p>
    </figcaption>
</figure>

<figure class="right"><img src="/posts/3d-printing-and-perimeters/1_perimeter.png"
    alt="Badge sliced with 1 perimeter"><figcaption>
      <p>Badge sliced with 1 perimeter</p>
    </figcaption>
</figure>

</div>
<p>Hope it helped someone</p>
]]></content></item><item><title>What? A blog?</title><link>https://vkane.cz/posts/intro/</link><pubDate>Tue, 25 May 2021 14:17:27 +0200</pubDate><guid>https://vkane.cz/posts/intro/</guid><description>&lt;p&gt;&lt;strong&gt;Yes&lt;/strong&gt;! This is not a personal diary to be filled with fears and desires from the bottom of my heart, this is (or will be) a collection of technical notes, opinions, and dead ends I have discovered during my computer science adventures.&lt;/p&gt;
&lt;p&gt;The internet is already full of high-quality content, so why make another? Because the world is a complex place with so many variables and pitfalls, so while my posts might not be the most accurate or the most detailed, they might match the situation of the readers and therefore be helpful. I have read many articles showing the obvious, but without them, I would have never realized.&lt;/p&gt;</description><content type="html"><![CDATA[<p><strong>Yes</strong>! This is not a personal diary to be filled with fears and desires from the bottom of my heart, this is (or will be) a collection of technical notes, opinions, and dead ends I have discovered during my computer science adventures.</p>
<p>The internet is already full of high-quality content, so why make another? Because the world is a complex place with so many variables and pitfalls, so while my posts might not be the most accurate or the most detailed, they might match the situation of the readers and therefore be helpful. I have read many articles showing the obvious, but without them, I would have never realized.</p>
]]></content></item></channel></rss>