Aashutosh's Devlog

TIL: Postgres Distinct On Clause

2025-05-30T00:00:00+00:00

I stumbled upon a really handy feature in Postgres today: DISTINCT ON</code>.</p>

I needed to find the latest entry from a history table for each record in a main table. The history table tracks changes over time (like status updates or edits), so naturally, there are multiple entries per record.</p>

My first instinct was to go with the usual ROW_NUMBER() OVER (PARTITION BY ...)</code> approach. It works fine. You partition by the record ID, order by timestamp descending, and filter to the first row. However, I found a more concise way to do the same thing: using DISTINCT ON</code> clauses.</p>

With DISTINCT ON</code>, you can tell Postgres to return only the first row of each group based on how you sort the data. For example, if you want the latest entry for each record_id</code>, you can write:</p>

SELECT DISTINCT ON (record_id) *
FROM history
ORDER BY record_id, updated_at DESC;
</code></pre>
This gives you one row per record_id</code>, and because we are ordering by updated_at DESC</code>, it returns the most recent one.</p>
Here’s the official Postgres docs on DISTINCT</a> if you want to dive deeper.</p>



TIL: Using CASE directly in ORDER BY for custom sorting
2024-01-13T00:00:00+00:00
I’ve been using CASE</code> statements in SELECT</code> clauses for a while now, usually to compute some value that I would then use in ORDER BY</code>.
But that often meant wrapping things in a CTE just to clean up the result later.</p>
Today I realized that you can just use the CASE</code> directly in the ORDER BY</code> clause.
No need for a CTE or alias.</p>
-- Sorting by priority in a task manager
SELECT title, priority
FROM tasks
ORDER BY
  CASE priority
    WHEN 'Urgent' THEN 1
    WHEN 'High' THEN 2
    WHEN 'Medium' THEN 3
    WHEN 'Low' THEN 4
  END;
</code></pre>


Handling command line arguments in Zig
2023-06-17T00:00:00+00:00
In Zig, handling command line arguments is not as straight forward as with other programming languages.
Since there are no hidden memory allocations, we need to explicitly allocate memory for storing the command line arguments.
This is different from something like in C, where the argv</code> parameter that holds the command line arguments is allocated and populated by the language runtime.</p>
We can read in the arguments from the command line using the argsAlloc</code> function from the std.process</code> namespace in the standard library.</p>
fn argsAlloc(allocator: Allocator) ![][:0]u8
</code></pre>
We see that argsAlloc</code> requires an allocator.
So we first need to create an allocator and pass it to argsAlloc</code> for it to be able to read in the cli arguments.</p>
var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);
defer arena.deinit();

const allocator = arena.allocator();
</code></pre>
Here we instantiate an arena allocator that manages the memory provided by the page_allocator</code> which allocates memory in pages.
Zig has a number of different allocator for different use cases.
We use the arena allocator since it provides a simple and efficient way to allocate and deallocate memory.
Benjamin Feng's talk "What's a Memory Allocator Anyway?</a>" provides a really good explanation on the matter.</p>
The defer</code> statement ensures that the allocator is deinitialized when the current scope exits.</p>
With the allocator in place, we can now read in arguments from the command line into a variable as:</p>
const args = try std.process.argsAlloc(allocator);
defer std.process.argsFree(allocator, args);
</code></pre>
Putting it all together</h2>
const std = @import("std");

pub fn main() !void {
    var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);
    defer arena.deinit();

    const allocator = arena.allocator();

    const args = try std.process.argsAlloc(allocator);
    defer std.process.argsFree(allocator, args);

    if (args.len < 2) {
        std.debug.print("Hello, stranger!\n", .{});
    } else {
        std.debug.print("Hello, {s}!\n", .{args[1]});
    }
}
</code></pre>
</p>


One month with the Colemak keyboard layout
2023-02-07T00:00:00+00:00
At the start of June, I switched to the Colemak</a> keyboard layout.
Colemak is an alternative to the traditional Qwerty layout designed to make typing more efficient and comfortable by placing the most frequently used letters on the home row.
The reason behind the switch was not to improve speed, but to get a more comfortable typing experience.</p>
The reason I switched to Colemak, as opposed to other layouts such as Dvorak, was its similarity to Qwerty - only 2 keys move between hands and also the position of common shortcut keys (z, x, c, v) is preserved which makes transitioning a lot easier.</p>
Due to the similarity between Qwerty and Colemak, memorizing the key placements wasn't much of a difficult task.
The real difficulty was in slowing down and not letting muscle memory take over.
Going from typing at around 90 wpm to having to think about the placement of each key was hard, way more than I had imagined.
It took me about a week to get used to and within two weeks I was typing at around 20 wpm.</p>
A month in and I am nearly at 40 wpm.
I have not noticed any significant improvement in typing comfort, most probably because I have only been typing small chunks of text for a short period of time.
However, it does feel satisfying to type words that can be typed using only the home row keys, which is quite a few words.
Contrary to what most people say, the transition has slowly started to affect my muscle memory when typing on my phone as well.</p>
Pain points</h2>
Vim.
I use vim for all my writing and text editing.
Also, most of the programs I use have Vim bindings.
Vim, however, is designed with Qwerty in mind.</p>
Initially I just remapped the bindings to make use of the placement rather than the actual keys (eg. navigation remapped from jkl;</code> to neio</code>) but it started getting confusing and hindering my progress with Colemak.
So I reverted to using them with the default Colemak layout.
Using Vim, and programs that make use of the Vim bindings, with the Colemak layout did not feel as good as it did with Qwerty.</p>
What next?</h2>
Goodbye Qwerty.
One month with Colemak and I am convinced that it is a much better layout than Qwerty.
Typing is something that I will be doing a lot throughout my life since both my work and hobbies involve computers.
Not just writing code, but things like taking notes, chatting, and emails which I do quite a lot.
Taking this into consideration, I think it only makes sense to invest in a typing layout that is designed</em> to be comfortable.</p>
All these reasoning aside, learning Colemak has been really fun and I have found something new that I want to get good at.
So here's to a long ride with Colemak!</p>


Bootstrapping dev environment setup with Airflow
2022-12-04T00:00:00+00:00
This is just an experiment.
There are tools out there, like Ansible, that handle tasks like these much better.</div>
I recently came across an interesting video on Youtube titled Don't Use Apache Airflow</a>.
This video talks about Airflow's identity crisis—how it's promoted as an ETL tool when in fact, it has no ETL specific functionalities.</p>
When starting out, I too got the impression that Airflow was an ETL tool.
It was a while until I realized that it had no ETL specific functionalities and that it was just a highly sophisticated job scheduler.
So this little experiment is an attempt to shed light on the fact that Airflow is just a job scheduler and hence can be used for any</em> kind of scheduled work.</p>
The Workflow</h2>
The goal here is to bootstrap my dev environment setup.
A major portion of it includes installing necessary packages and setting them up the way I configured them.
So, breaking it down, the tasks that need to be accomplished are:</p>

Install git.</li>
Install necessary packages.</li>
Clone my dotfiles repository.</li>
Stow the dotfiles.</li>
</ol>
I separate installing git from installing other packages as, while not in this case, I use git to clone programs to build them from source.</p>
Once git is installed, installing other packages and cloning the dotfiles repository can happen in parallel as there is no dependency between the two tasks.
Finally, once the necessary packages are installed and the dotfiles are cloned, the dotfiles are symlinked to the required locations using GNU Stow.</p>
The Code</h2>
Airflow represents workflows as directed acyclic graphs (DAGs).
The acyclic property prevents us from running into circular dependencies between tasks.</p>
Let's define a DAG to represent the workflow.</p>
dag = DAG(
    dag_id="dev_env_setup_dag",
    start_date=airflow.utils.dates.days_ago(0),
    schedule_interval=None,
)
</code></pre>
Since the workflow is run once during initial setup, the schedule_interval</code> for the dag is set to None</code>.</p>
Now defining the tasks specified above as tasks associated with the DAG we just created.</p>
install_git = BashOperator(
    task_id="install_git",
    bash_command="echo $PASSWORD | sudo -S dnf install git",
    dag=dag,
)

clone_dotfiles_repo = BashOperator(
    task_id="clone_dotfiles_repo",
    bash_command="git clone https://codeberg.org/chaoticenginerd/infra.git $HOME/infra",
    dag=dag,
)

# Specify the packages to install
packages = [
    "neovim",
    "starship",
    "stow",
    "tmux",
    "trash-cli",
]

install_packages = BashOperator(
    task_id="install_packages",
    bash_command=f"echo $PASSWORD | sudo -S dnf install {' '.join(packages)}",
    dag=dag,
)

# Specifying the dotfiles to stow
stow_dirs = [
    "bin",
    "nvim",
    "starship",
    "tmux",
]
stow_dotfiles = BashOperator(
    task_id="stow_dotfiles",
    bash_command=f"cd $HOME/infra/dotfiles/ && stow -t ~ {' '.join(stow_dirs)}",
    dag=dag,
)
</code></pre>
With all the tasks specified and associated with our DAG, we now specify the order in which these tasks are supposed to run.</p>
tasks = [install_git, [clone_dotfiles_repo, install_packages], stow_dotfiles]
airflow.models.baseoperator.chain(*tasks)
</code></pre>
The clone_dotfiles_repo</code> and install_packages</code> are grouped together to specify that they are to be run in parallel.</p>
The complete code for the DAG can be found over on Github</a>.</p>
The Result</h2>
This is what the bootstrap DAG looks like.
</p>
A successful run of the DAG will now install the necessary packages, clone my dotfiles repository, and stow my dotfiles to configure my development environment and programs the way I like them.</p>
Once again, I would like to mention that this is not very efficient.
There are tools out there, like Ansible, which do a much better job for tasks like these.
This was just an experiment to try and use Airflow for tasks other than those related to data pipelines.</p>


Embracing the 'bloat'
2022-06-27T00:00:00+00:00
After riding the minimalism train for a while, I have decided to drop off and settle in the land of a full featured desktop environment - KDE Plasma.</p>
Getting on the "anti-bloat" train, I replaced all my apps with minimal alternatives.
While these apps were fun to use, very customizable, and light on system resources, they came at a cost - my time.
I was spending too much time, more than I had wanted and imagined, to configure them to fit my needs, to create my custom workflow and a coherent system.
All I found myself doing was editing config files out which I wasn't learning much and my Linux system became a distraction.</p>
Being obsessed with "anti-bloat" and "minimalism", what I had forgotten was there were already apps and desktops out there, all free software, that fit my needs and worked out of the box.
I had forgotten that there were lots of other stuff to learn and do than just edit config files.</p>
Few weeks back, I messed up my Debian system while experimenting with the nix package manager and decided to do a clean install.
This time I decided to give KDE Plasma a try and reluctantly pressed 'y' on the install prompt that asked me if I wanted to install nearly a thousand packages.</p>
I always had a bias towards KDE considering how I disliked it without giving it much of a try.
If it hadn't been for the recent changes in the Gnome desktop, I probably would have installed Gnome instead.
But to my surprise, I am really liking the Plasma desktop.</p>
The desktop has a ton of features and is extremely flexible and customizable.
Coming from a patched up minimal system, the full featured desktop feels really cozy and I am loving it.
KDE also has a rich set of applications which are packed with features that fit my needs almost perfectly and also help maintain a coherent desktop.
Almost everything works out of the box and configuring is no difficult than toggling a few options.
The theming seems to be much better than how it was on GTK based desktops.
I am also really impressed with the resource utilization considering how feature rich the desktop is.</p>
The amount of time I spend configuring my system has drastically decreased.
I now have more time on my hands which I have been spending on learning new stuff that are actually worthwhile and important to me than just obsessing over resource usage and package counts.</p>

Aashutosh's Devlog

TIL: Postgres Distinct On Clause

TIL: Using CASE directly in ORDER BY for custom sorting

Handling command line arguments in Zig

One month with the Colemak keyboard layout

Bootstrapping dev environment setup with Airflow

The Code</h2> Airflow represents workflows as directed acyclic graphs (DAGs). The acyclic property prevents us from running into circular dependencies between tasks.</p> Let's define a DAG to represent the workflow.</p>

Embracing the 'bloat'