Programming

As a preview in JDK 23 and about to be final in the upcoming JDK 24, Java has added a capability to its Stream API to create new collectors using a new interface called Gatherer. Java has had a Collector API for a while now, but the Gatherer interface addresses some limitations, including the issue that there was no way to tell a Collector that processing was complete. If there were still some data the Collector was processing, this data was lost. You will see an example of this later. ...

When I started writing blogs, since my code was stored in GitHub, I would use GitHub Gists of my code snippets to use in my blogs. I was also predominantly using JetBrains IDEs, which have a built-in Gist-taking feature, which I love. This was very convenient, staying within my IDE. Because I was also using Medium to publish my blogs, this turned out to be very convenient because Medium could take the URL of the Gist and nicely embed the image in the published blog. However, because the URL is actually to some Javascript, and not to an image file like a PNG or JPG, I could not use the Gist URL in my blog posts on my own website quite so easily. This is in part because of the publishing tool I’m using ( Quartz), but also because I want the Gist to show “inline” like an embedded image. ...

With all the wonderful graphical interfaces available, it’s easy to forget that a terminal is still a powerful tool. And depending on your job or what you’re doing, it can be the only interface available. Or you may just be longer in the tooth like me and have been using terminal emulators or actual real-life terminals for decades, and feel comfortable and at home working within a terminal. I will use the term “terminal” from here on out, even though for almost everyone we’re really using terminal emulators. But even if you’re used to using terminals, you may not have heard of some of the newer tools available, which can seriously make you much more productive. So whether you’re relatively new to terminals or a seasoned pro, here are tools for the terminal that have made me much more productive. Some of these are replacements for tools you may be familiar with, and others are new(ish) and make one wonder how we got along without them. ...

In this blog I continue my journey with Rust and Git, focusing on creating the last two object types in Git — the tree and the commit. As you may recall from previous post in this series, a tree object represents a single level of a directory tree, with the file’s name, permissions and object hash. A commit object is what most people are familiar with, and it contains references (via object hashes) to a tree for files in the commit, a reference to the parent commit if any (e.g. the very first commit in a repo has no parent), the name of the author and committer (which are allowed to be different) and finally the commit message. If you sign your commit, this ends up as text in the comment. ...

In this latest blog on Git internals with Rust, I will focus on the ls-tree command in Git. You can find the earlier posts here: Part 1 — git init Part 2 — git hash-object Part 3 — refactoring Part 4 — git cat-file The ls-tree command is similar to doing an ls in a terminal emulator. It lists the contents of tree objects in Git. The Git object model looks like this (copied from Part 2) ...

I have been using — and loving — JetBrains Integrated Development Environments (IDEs) and other tools (I like TeamCity a lot!) since effectively version 1 of IntelliJ IDEA since it was released in the early 2000s. Compared to the other IDEs I tried at the time like NetBeans, JBuilder and Eclipse, IntelliJ was just better all around. But the really great thing that I liked about it in addition to its overall look & feel was its keyboard integration. That’s right, keyboard integration. ...

In this post we’ll cover the Git cat-file command. Previous posts in this series are Part 1 — git init Part 2 — git hash-object Part 3 — refactoring The Git cat-file command let’s you dump the contents of a Git object. You cannot view Git object files directly since they are compressed as well as having headers, as we saw in the second post on hash-object. The cat-file command is essentially the inverse of the hash-object command. ...

In this post we continue our journey with Rust and Git. If you haven’t read the previous posts, you can find them here Part 1 — git init Part 2 — git hash-object At the end of Part 2 I said the next blog would be on cat-file. Sorry for the bait and switch, but I wanted to do this refactoring, so I snuck this in. We’ll definitely get to cat-file next time. While this post is mostly standalone, there are aspects of the prior posts that will probably help to understand this post better. ...

This post continues from where I left off in the first post that covered creating a new empty repository. You can read it here. To briefly summarize the goal of this series of posts, I am on a journey to learn Rust and for me the best way is doing “real” stuff. In this case I’m looking at the internals of Git, by implementing some of the many commands available. After the first post I am able to create a new repository. Let’s start to look at what Git stores and how it does so. As we saw in the first post, after git init we have a directory .git/objects. Content is stored in files under that base objects directory by using a SHA-1 hash of the contents being stored. Git provides a command git hash-object which allows generating the hash based on content, and optionally writing that file to .git/objects. However, that doesn’t mean that git hash-object is just a fancy wrapper around sha1sum or similar tools. ...

Have you ever wondered how Git does what it does? What happens when you do a commit? You can read about some of this in the Git Book free online, like in Chapter 10 on Git Internals. But it doesn’t give you all the details, as I discovered. And I wanted another interesting “project” to help me on my continuing journey learning Rust. So why not poke around under the Git hood? ...