<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Guillermo Rodríguez</title><link>https://guille.github.io/posts/</link><description>Recent content in Posts on Guillermo Rodríguez</description><generator>Hugo</generator><language>en-uk</language><lastBuildDate>Fri, 01 May 2026 11:26:32 +0200</lastBuildDate><atom:link href="https://guille.github.io/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Agentic engineering in reverse</title><link>https://guille.github.io/posts/dmn/</link><pubDate>Fri, 01 May 2026 11:26:32 +0200</pubDate><guid>https://guille.github.io/posts/dmn/</guid><description>&lt;p&gt;One of the many projects I had started over the last few months was a daemonized shell. I wanted to understand how terminals work more in depth, and how tmux does what it does. In order to do that, I started building a very simple PTY daemon. My idea was something like: I want to be able to daemonize a shell, and then have some sort of listening process that controls it and can send bytes to it. That felt like the bare minimum to get something working that I would actually bring myself to finish, even if it wouldn&amp;rsquo;t have the polish I&amp;rsquo;d want in order to open-source it or do any sort of demo.&lt;/p&gt;</description></item><item><title>Working with large Git repositories</title><link>https://guille.github.io/posts/git-large-repos/</link><pubDate>Wed, 08 Apr 2026 20:39:32 +0200</pubDate><guid>https://guille.github.io/posts/git-large-repos/</guid><description>&lt;p&gt;I have recently joined a startup with a staggering number of repositories for the size of the team. The repos are all quite small, though. Behind me are the days working with the Rails monolith that made git operations feel slow. I like things to be snappy, so I&amp;rsquo;m just writing my notes so I don&amp;rsquo;t forget them for next time I need them. These notes are mostly for myself, but if you find them useful —or incorrect— feel free to let me know.&lt;/p&gt;</description></item><item><title>The Copilot key does what?</title><link>https://guille.github.io/posts/copilot-key/</link><pubDate>Thu, 26 Mar 2026 16:59:32 +0100</pubDate><guid>https://guille.github.io/posts/copilot-key/</guid><description>&lt;p&gt;I changed jobs a couple of weeks ago and got a nice Thinkpad, with Fedora installed. On the right-hand side of the keyboard, where one would expect keys like Super_R, Menu, Ctrl_R, right between Alt Gr and the fingerprint reader there was&amp;hellip; something else. I didn&amp;rsquo;t think much of it at first, I even assumed it was the Menu key, but I accidentally pressed it in combination with &amp;ldquo;2&amp;rdquo; and it triggered one of my shortcuts.&lt;/p&gt;</description></item><item><title>Building a terminal workflow</title><link>https://guille.github.io/posts/tools-i-use-all-the-time/</link><pubDate>Tue, 24 Mar 2026 22:40:45 +0100</pubDate><guid>https://guille.github.io/posts/tools-i-use-all-the-time/</guid><description>&lt;p&gt;I spend more time than I probably should building a workflow that feels right for me. Part of it is because I believe it makes me more productive, but I won&amp;rsquo;t hide that it&amp;rsquo;s also partly because I enjoy the process itself. Since I spent a lot of time in the terminal, that&amp;rsquo;s where most of my &lt;a href="https://guille.github.io/posts/tinkering/"&gt;tinkering&lt;/a&gt;
 ends up happening.&lt;/p&gt;
&lt;p&gt;Inspired by &lt;a href="https://evanhahn.com/scripts-i-wrote-that-i-use-all-the-time/" class="external-link" target="_blank" rel="noopener"&gt;this blog post&lt;/a&gt;
 by Evan Hahn that recently&lt;sup id="fnref:1"&gt;&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref"&gt;1&lt;/a&gt;&lt;/sup&gt; made the rounds, I wanted to share some tools and scripts that I use in my day-to-day workflow.&lt;/p&gt;</description></item><item><title>Thoughts on Change Data Capture and aggregations</title><link>https://guille.github.io/posts/cdc-aggregations/</link><pubDate>Sun, 09 Nov 2025 18:47:32 +0200</pubDate><guid>https://guille.github.io/posts/cdc-aggregations/</guid><description>&lt;p&gt;Let&amp;rsquo;s dive right in by considering a few scenarios:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Banking app&lt;/strong&gt;. In order to show the user their current balance, you add up all their bank movements since they opened the account.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;CMS&lt;/strong&gt;. In order to display a word count at the top of an article, you parse the entire contents and sum up each word.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Project management&lt;/strong&gt;. In order to display the completion percentage of a project, you iterate through all the tasks, checking their status and finally calculating the ratio.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Accounting software&lt;/strong&gt;. In order to show a business how much they owe a certain customer, you add up all invoices and payments for that customer.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;E-commerce&lt;/strong&gt;. In order to calculate product ratings, you sum up all the purchaser&amp;rsquo;s ratings and divide by number of purchasers.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;They&amp;rsquo;re all obvious. And they work. But do they scale? The answer is: &amp;ldquo;yes, until they don&amp;rsquo;t.&amp;rdquo;&lt;/p&gt;</description></item><item><title>Getting Sublime LSP working in Ruby</title><link>https://guille.github.io/posts/sublime-lsp-ruby/</link><pubDate>Fri, 22 Aug 2025 17:00:32 +0200</pubDate><guid>https://guille.github.io/posts/sublime-lsp-ruby/</guid><description>&lt;p&gt;A Language Server Protocol (from here on, LSP) is a very useful developer companion. In a nutshell, it allows text editors to get some of the features of a fully-fledged IDE: smarter autocomplete, formatting, refactoring tools, documentation, etc.&lt;/p&gt;
&lt;p&gt;Despite everyone&amp;rsquo;s obsession with Visual Studio Code, I have stayed true to Sublime Text, which works perfectly fine for me. But what&amp;rsquo;s the LSP support like? Well, it turns out, it is not as good as Visual Studio Code&amp;rsquo;s but it is not bad at all.&lt;/p&gt;</description></item><item><title>Link roundup (IV)</title><link>https://guille.github.io/posts/link-roundup-4/</link><pubDate>Thu, 21 Aug 2025 18:47:32 +0200</pubDate><guid>https://guille.github.io/posts/link-roundup-4/</guid><description>&lt;p&gt;&lt;strong&gt;1)&lt;/strong&gt; &lt;em&gt;&lt;a href="https://www.scattered-thoughts.net/writing/reflections-on-a-decade-of-coding/" class="external-link" target="_blank" rel="noopener"&gt;Reflections on a decade of coding&lt;/a&gt;
&lt;/em&gt; was a great read—especially the &lt;em&gt;&lt;a href="https://www.scattered-thoughts.net/writing/coding/" class="external-link" target="_blank" rel="noopener"&gt;Coding&lt;/a&gt;
&lt;/em&gt; section. On a similar vein, &lt;a href="https://grugbrain.dev/" class="external-link" target="_blank" rel="noopener"&gt;reading grug&lt;/a&gt;
 is always a good idea.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;2)&lt;/strong&gt; I like reading about security vulnerabilities. For the most part. I came out of &lt;a href="https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/" class="external-link" target="_blank" rel="noopener"&gt;this write-up&lt;/a&gt;
 terrified and swearing off CUPS forever. In case you think I&amp;rsquo;m exaggerating, here is a &lt;a href="https://x.com/evilsocket/status/1879846515180511705" class="external-link" target="_blank" rel="noopener"&gt;follow-up&lt;/a&gt;
.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;3)&lt;/strong&gt; Writing a calculator app is easy, until you think about it. And the more you think about it, the harder it gets. &lt;a href="https://chadnauseam.com/coding/random/calculator-app" class="external-link" target="_blank" rel="noopener"&gt;Here&amp;rsquo;s an amazing writeup on the stock Android calculator&lt;/a&gt;
.&lt;/p&gt;</description></item><item><title>Is there value in tinkering?</title><link>https://guille.github.io/posts/tinkering/</link><pubDate>Wed, 20 Aug 2025 21:47:32 +0200</pubDate><guid>https://guille.github.io/posts/tinkering/</guid><description>&lt;p&gt;Every so often I like to &lt;del&gt;waste&lt;/del&gt; spend some time tinkering with my computer&amp;rsquo;s configuration. Part of it is, of course, to make it look nice. There&amp;rsquo;s something satisfying about getting the right colour scheme, a cool-looking prompt, and a custom bar that shows exactly the information you want where you want it.&lt;/p&gt;
&lt;p&gt;&lt;img src="https://guille.github.io/images/desktop.webp" alt="A screenshot of my desktop" loading="lazy" decoding="async"&gt;
&lt;/p&gt;
&lt;p&gt;But I&amp;rsquo;d argue there&amp;rsquo;s also some valuable lessons to be learned from them. I&amp;rsquo;ve said &lt;a href="https://guille.github.io/about"&gt;before&lt;/a&gt;
 that fundamentals are very important, and that includes knowing your operating system and your shell. Those are the sort of skills that this sort of tinkering forces you to learn.&lt;/p&gt;</description></item><item><title>What every junior developer should work on</title><link>https://guille.github.io/posts/tips-juniors/</link><pubDate>Wed, 26 Feb 2025 16:40:45 +0100</pubDate><guid>https://guille.github.io/posts/tips-juniors/</guid><description>&lt;p&gt;These sort of lists seem to be very popular —and some are actually quite good!—, so I figured I would add my own two cents. Without further ado:&lt;/p&gt;
&lt;h2 id="1-dont-use-your-colleagues-as-a-replacement-for-effort"&gt;1. Don&amp;rsquo;t use your colleagues as a replacement for effort&lt;/h2&gt;
&lt;p&gt;Learning when to ask your colleagues versus trying something out yourself is a skill you will have to learn. I think most of us, depending on the environment, our upbringing, and our natural inclinations, have a predisposition towards asking too much or not enough.&lt;/p&gt;</description></item><item><title>Link roundup (III)</title><link>https://guille.github.io/posts/link-roundup-3/</link><pubDate>Thu, 12 Sep 2024 14:47:32 +0200</pubDate><guid>https://guille.github.io/posts/link-roundup-3/</guid><description>&lt;p&gt;&lt;strong&gt;1)&lt;/strong&gt; In 1983, Ken Thompson, one of the pioneers and giants of computer science, received the Turing award. His acceptance speech, &amp;ldquo;Reflections on Trusting Trust&amp;rdquo;, presents a fascinating attack vector. You can read about it &lt;a href="https://dl.acm.org/doi/pdf/10.1145/358198.358210" class="external-link" target="_blank" rel="noopener"&gt;here&lt;/a&gt;
.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;2)&lt;/strong&gt; Russ Cox, over at swtch, has a great explainer going into further detail on how this would work, implementing it, and how the Go compiler avoids it: &lt;em&gt;&lt;a href="https://research.swtch.com/nih" class="external-link" target="_blank" rel="noopener"&gt;Running the “Reflections on Trusting Trust” Compiler&lt;/a&gt;
&lt;/em&gt;&lt;/p&gt;</description></item><item><title>My experience @ StaffPlus London</title><link>https://guille.github.io/posts/staffplus-london/</link><pubDate>Thu, 13 Jun 2024 12:47:32 +0200</pubDate><guid>https://guille.github.io/posts/staffplus-london/</guid><description>&lt;p&gt;Last 11-12 June I had the amazing opportunity to attend the StaffPlus conference in London. As a mid-level developer, the prospect is a bit daunting. You know you will learn a lot and meet interesting people, but you are not exactly the target audience of the talks, so how valuable can it really be?&lt;/p&gt;
&lt;p&gt;It turns out, a lot.&lt;/p&gt;
&lt;p&gt;Listening to staff+ engineers was helpful in two main ways. Or in two main timelines. In the first group are things that may not be directly applicable now, at this point of my career. However, it was still valuable information to understand the constraints senior Individual Contributors work with, how they work around them, and what to expect when I get to that level.&lt;/p&gt;</description></item><item><title>Link roundup (II)</title><link>https://guille.github.io/posts/link-roundup-2/</link><pubDate>Sun, 26 May 2024 12:47:32 +0100</pubDate><guid>https://guille.github.io/posts/link-roundup-2/</guid><description>&lt;p&gt;&lt;strong&gt;1)&lt;/strong&gt; A few hours after I wrapped up the last roundup I learned about CVE-2024-3094. It&amp;rsquo;s a fascinating —and terrifying— situation: a vulnerability was intentionally introduced by one of the core maintainers of &lt;code&gt;xz&lt;/code&gt; over a couple of years. It was randomly discovered by pure luck, and one wonders what other issues are out there like this. And also, who was behind it. Read more at &lt;em&gt;&lt;a href="https://boehs.org/node/everything-i-know-about-the-xz-backdoor" class="external-link" target="_blank" rel="noopener"&gt;Everything I Know About the Xz Backdoor&lt;/a&gt;
&lt;/em&gt;.&lt;/p&gt;</description></item><item><title>Link roundup (I)</title><link>https://guille.github.io/posts/link-roundup-1/</link><pubDate>Fri, 29 Mar 2024 12:47:32 +0100</pubDate><guid>https://guille.github.io/posts/link-roundup-1/</guid><description>&lt;p&gt;&lt;strong&gt;1)&lt;/strong&gt; One of the best ways to learn how to use your tools is by looking through how other people use theirs. This is why Adrian Göransson&amp;rsquo;s &lt;em&gt;&lt;a href="https://adrg.se/blog/dotfiles-digest-git" class="external-link" target="_blank" rel="noopener"&gt;Dotfiles digest: git&lt;/a&gt;
&lt;/em&gt; is the first link in this post.&lt;/p&gt;
&lt;p&gt;For the uninitiated, dotfiles is the term commonly used to refer to those configuration files we all have lying around our computer (.zshrc, .bashrc, .gitconfig, etc.).&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;2)&lt;/strong&gt; Through Adrian&amp;rsquo;s post I also found an informative talk by Scott Chacon: &lt;em&gt;&lt;a href="https://www.youtube.com/watch?v=aolI_Rz0ZqY" class="external-link" target="_blank" rel="noopener"&gt;So You Think You Know Git (46 min)&lt;/a&gt;
&lt;/em&gt; and &lt;a href="https://jvns.ca/blog/2024/02/16/popular-git-config-options/" class="external-link" target="_blank" rel="noopener"&gt;Julia Evans&amp;rsquo; survey of popular git options&lt;/a&gt;
.&lt;/p&gt;</description></item></channel></rss>