<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Samizdat blog by Egor Kovetskiy</title>
    <link>https://samizdat.dev/</link>
    <description>Recent content on Samizdat blog by Egor Kovetskiy</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <managingEditor>egor@samizdat.dev (Egor Kovetskiy)</managingEditor>
    <webMaster>egor@samizdat.dev (Egor Kovetskiy)</webMaster>
    <lastBuildDate>Mon, 27 Apr 2026 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://samizdat.dev/index.xml" rel="self" type="application/rss+xml" />
    
    
    
    <item>
      <title>Phantom Patch</title>
      <link>https://samizdat.dev/phantom-patch/</link>
      <pubDate>Mon, 27 Apr 2026 00:00:00 +0000</pubDate>
      <author>egor@samizdat.dev (Egor Kovetskiy)</author>
      <guid>https://samizdat.dev/phantom-patch/</guid>
      <description>&lt;p&gt;GitHub (and many others) exposes mail-style patches at &lt;code&gt;.patch&lt;/code&gt; URLs.
If you download one of those patches and feed it to GNU &lt;code&gt;patch&lt;/code&gt;, diff-shaped text inside the commit
message can be applied as if it were part of the real patch.&lt;/p&gt;
&lt;p&gt;It matters (to me) because &lt;code&gt;wget&lt;/code&gt;/&lt;code&gt;curl&lt;/code&gt; plus &lt;code&gt;patch&lt;/code&gt; is not some exotic lab setup. It is a
very old, very ordinary way to move a patch from one machine to another.&lt;/p&gt;</description>
    </item>
    
    
    
    <item>
      <title>Prometheus: scrap all Docker Swarm tasks</title>
      <link>https://samizdat.dev/prometheus-scrap-all-docker-swarm-tasks/</link>
      <pubDate>Mon, 28 Jun 2021 00:00:00 +0000</pubDate>
      <author>egor@samizdat.dev (Egor Kovetskiy)</author>
      <guid>https://samizdat.dev/prometheus-scrap-all-docker-swarm-tasks/</guid>
      <description>&lt;p&gt;We have a server with Docker Swarm initialized. A few services are running on it. We need to scrap
metrics to prometheus and we want it to use direct connection to the services without going through
a load balancer.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve spent a bunch of time figuring out how to do it, so here is a tutorial just for my future self.&lt;/p&gt;
&lt;p&gt;There are several ways to scrap metrics with service discovery:&lt;/p&gt;</description>
    </item>
    
    
    
    <item>
      <title>Getting lucky with posting on Hacker News</title>
      <link>https://samizdat.dev/getting-lucky-with-posting-on-hacker-news/</link>
      <pubDate>Mon, 23 Nov 2020 00:00:00 +0000</pubDate>
      <author>egor@samizdat.dev (Egor Kovetskiy)</author>
      <guid>https://samizdat.dev/getting-lucky-with-posting-on-hacker-news/</guid>
      <description>&lt;p&gt;You know the feeling of watching your post quickly drowning in the Newest section of Hacker News, right?
It seems like pure, chaotic luck. Or is it?&lt;/p&gt;
&lt;p&gt;I tried to crack the code of successful submissions.&lt;/p&gt;
&lt;p&gt;I built a tool that parses Hacker News every two minutes and logs the state into the
database. The program has been working for &lt;strong&gt;14 days&lt;/strong&gt; so far.&lt;/p&gt;
&lt;p&gt;For the latest two weeks, there were &lt;strong&gt;13846&lt;/strong&gt; stories, and only &lt;strong&gt;1403&lt;/strong&gt; of them reached the first
page of Hacker News.&lt;/p&gt;</description>
    </item>
    
    
    
    <item>
      <title>How I self-host my blog with Docker &amp; Ansible</title>
      <link>https://samizdat.dev/how-i-self-host-my-blog-with-docker-ansible/</link>
      <pubDate>Thu, 05 Nov 2020 00:00:00 +0000</pubDate>
      <author>egor@samizdat.dev (Egor Kovetskiy)</author>
      <guid>https://samizdat.dev/how-i-self-host-my-blog-with-docker-ansible/</guid>
      <description>&lt;p&gt;I have always wanted to build a blog, but for a long time, I have been postponing it.&lt;/p&gt;
&lt;p&gt;Well, I guess I thought it was difficult to build a blog.
Turns out, even if you self-host it, it&amp;rsquo;s not that hard.&lt;/p&gt;
&lt;p&gt;I decided to finally create it one day, and I had a few criteria:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;No fancy admin panels. I want to write markdown and deliver it as is.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Without sacrificing the privacy of visitors, I should be able to collect traffic statistics, i.e.
Google Analytics. No external JavaScripts.&lt;/p&gt;</description>
    </item>
    
    
    
    <item>
      <title>Notes on Nailing Your First Launch by Adam Wathan</title>
      <link>https://samizdat.dev/notes-on-nailing-your-first-launch-by-adam-wathan/</link>
      <pubDate>Fri, 30 Oct 2020 00:00:00 +0000</pubDate>
      <author>egor@samizdat.dev (Egor Kovetskiy)</author>
      <guid>https://samizdat.dev/notes-on-nailing-your-first-launch-by-adam-wathan/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve just watched the talk «Nailing Your First Launch» (MicroConf Starter 2018) by Adam Wathan and I
took notes that I&amp;rsquo;d like to share and re-visit them in the future. Some of them are just text from his screens, some thoughts are mine.&lt;/p&gt;
&lt;p&gt;But don&amp;rsquo;t let me steal the video from you by providing a digested summary.
In my humble opinion, the main idea of watching talks or reading something is to change your mind
model of seeing this topic.
Don&amp;rsquo;t hesitate and start watching the video before proceeding to notes.
The notes are here just to come back from time to time and re-call some especially useful highlights.&lt;/p&gt;</description>
    </item>
    
    
    
    <item>
      <title>Keep your GitHub forks up to date</title>
      <link>https://samizdat.dev/keep-your-github-forks-up-to-date/</link>
      <pubDate>Tue, 29 Sep 2020 00:00:00 +0000</pubDate>
      <author>egor@samizdat.dev (Egor Kovetskiy)</author>
      <guid>https://samizdat.dev/keep-your-github-forks-up-to-date/</guid>
      <description>&lt;p&gt;Sometimes I do fork repositories and do some tweaks here and there for my personal needs which ain&amp;rsquo;t
really going to be merged into the upstream repository.&lt;/p&gt;
&lt;p&gt;One thing that used to concern me is that I needed to manually rebase my changes onto the upstream
to have new goods but keep my changes on top of them.&lt;/p&gt;
&lt;p&gt;Fortunately, GitHub Actions supports the &lt;code&gt;schedule&lt;/code&gt; trigger for workflows and this is what we are
going to use.&lt;/p&gt;</description>
    </item>
    
    
    
    <item>
      <title>Use Markdown for Confluence</title>
      <link>https://samizdat.dev/use-markdown-for-confluence/</link>
      <pubDate>Mon, 27 Jul 2020 00:00:00 +0000</pubDate>
      <author>egor@samizdat.dev (Egor Kovetskiy)</author>
      <guid>https://samizdat.dev/use-markdown-for-confluence/</guid>
      <description>&lt;p&gt;TL;DR
&lt;a href=&#34;https://github.com/kovetskiy/mark&#34;&gt;Mark — a tool for syncing your Markdown with Confluence&lt;/a&gt;&lt;/p&gt;
&lt;h1 id=&#34;devils-playground&#34;&gt;Devil&amp;rsquo;s Playground&lt;/h1&gt;
&lt;p&gt;Oh man, I was so frustrated when I was trying to edit docs in Confluence, and it
broke all my text, trying to adjust any tags led to breaking the text even more.
I felt the same when Slack introduced their Wysiwyg editor that solved problems that never existed,
but at least they added an option to disable it.&lt;/p&gt;</description>
    </item>
    
    
    
    <item>
      <title>Help message for shell scripts</title>
      <link>https://samizdat.dev/help-message-for-shell-scripts/</link>
      <pubDate>Tue, 07 Jul 2020 00:00:00 +0000</pubDate>
      <author>egor@samizdat.dev (Egor Kovetskiy)</author>
      <guid>https://samizdat.dev/help-message-for-shell-scripts/</guid>
      <description>&lt;p&gt;Have you ever thought how good it would be to have a help message for your shell script
that you wrote a month ago and already forgot what it is supposed to do?&lt;/p&gt;
&lt;p&gt;Yeah, there is always a way to show a message using cat (meow) or a bunch of echo
calls.&lt;/p&gt;
&lt;p&gt;But there is a neat trick.&lt;/p&gt;
&lt;p&gt;Add your message with all the required information on top of your file, just right
after the shebang.&lt;/p&gt;</description>
    </item>
    
    
    
    
  </channel>
</rss>
