During Hacktoberfest Poznań Meetup (October 2018) I gave a talk about how people can support Free Software, apart from just programming.

Some two weeks ago, I've participated in the Ludum Dare compo and created a 2D platforming game. Almost any 2D game that uses tile-based maps will face the issue of how to render them properly. This may seem trivial – just use texture X on tile X and texture Y on tile Y – but unless you're aiming for a very minimalistic style, you'll probably want edges and corners to look a bit differently than a "solid" tile.

Previous weekend (August 11-12) I participated in Ludum Dare – an online event where the goal is to make a video game, solo, (mostly) from scratch, in 48 hours. This was the 42nd Ludum Dare, and this time the theme was "Running out of space". Over the two days of the weekend, I've written code, made pixel-art, generated sounds and designed levels; the end result of all of this was Super Overachiever 42000 Deluxe. In this blog post, I want to reflect on the compo – what I did well, what went wrong, and what lessons are there to learn.

Some time ago at work I was transferred to a project dealing with building mobile apps in Unity (the game engine). Since the rest of the team was using Microsoft Windows, along with a couple of Windows-only tools (such as Visual Studio and ReSharper), not to mention the fact that Unity Editor for Linux is still marked as "experimental" – I had to make the switch, too. Re-learning how to use Windows after spending almost a decade using Linux exclusively was a bit hard; even after getting used to all the quirks of the platform, there was one thing that I was missing sorely: the terminal. I played a bit with Git Bash, but found it a bit clunky to use, and most importantly – missing a lot of less-popular Unix tools. Dissatisfied, I set out to come up with something that'd be as close to my usual Linux-only workflow as possible.

During Poznań Free Software Event XIII (April 2018), I gave a talk about package lifecycle in Fedora.

So you've encountered some cool software on the interwebz – or better yet, you've written it yourself! You pop open the terminal and launch your package manager to install the program... and zoinks, it's not available in the repository. As you download the program and try to figure out how to compile the source, you think to yourself: wouldn't it be nice to have this in the repository and not have to worry about potential breakages (e.g. when dependent libraries change) and handling updates?

Ahh, Arduino. Microcontroller programming made easy accessible. There's just so much stuff you can build with it! Sensors, home automation, robots... After all, why pay five bucks for an existing product, when you can spend twice as much on parts and sacrifice multiple hours of your life to come up with your own, flawed solution?

In my previous blog post, I described how to build a basic RPM package. This article picks up where we left off, by showing how to create multiple packages using one spec file – which allows us to split a program into multiple packages – and how to handle potential conflicts.

One of the aspects of Unices that I personally very much enjoy is the concept of the system manual – with just a single command in the terminal, you can get a nice description of most available programs (applies also to C functions and a lot of other stuff). It should be no wonder that I tend to get slightly annoyed when I install a new package and find out that the authors didn't bother to write a man page (and neither did the packager). As such, when writing software myself, I ensure to include a man page to save other people from similar annoyances.

So, you're writing a shell script and you've come to realize that it needs to be able to perform several different functions. You could separate each of those into a separate script... but they're closely tied together; they complement each other. It only makes sense to make them available via the same command, just activated using different options.

One of the core concepts to Linux Distributions is that of the package manager: instead of forcing the user to compile everything from source – or even worse, downloading untrusted binaries from shady third party websites – the distro provides the user with a wide assortment of pre-compiled software that can be easily installed. Package management comes with heaps of various benefits, such as dependency resolution: the package manager automatically installs any libraries or programs that might be required for the user's desired program to work correctly.