Stefan Ukena's Blog

I have previously written about the awesome but less known git bisect command and the rather obscure git interpret-trailer command. Today I thought I’d share another obscure git command that I stumbled upon during my research: git notes.

Adding notes to git commits without changing the commit

git-notes - Add or inspect object notes

DESCRIPTION
Adds, removes, or reads notes attached to objects, without touching the objects themselves.

That is the beginning of the man-page. So, git notes can be used to add some information to a commit, without changing the commit itself. The documentation gives example: You could add a note to a commit that indicates who tested the commit:

Since I spontaneously decided to teach myself frontend development, I thought I would start by making myself familiar with common tools used in frontend development. Up until now I have been tangentially aware of what it takes to create a frontend, but I have never taken the time to read up on any specific topic. I will divide the tools into four categories: development tools, build tools, deployment tools, and, of course, other tools.

Warning: This is somewhat of a rant.

Off to a great start

This week I have been toying around with the idea of doing something that would involve some processing on the frontend that goes beyond submitting a form to the backend.

After some googling, I decided to try out my idea and set up a vue.js project. The easiest way to get started seemed to be to use my preferred IDE and set up a starter vue.js project with all the default settings. Ok, done. Find a little beginner tutorial and make some changes to the example component, and that also works immediately.

While waiting for the new edition of Thoughtwork’s Techonology Radar¹ – which should arrive any day now – I thought I’d go over the current, volume 24. What can bootstrappers and solo founders take away from the Technology Radar, which is really aimed at enterprises and larger organisations?

Out of the 104 techniques, tools, platforms, frameworks and languages, I have picked three that I found most relevant for bootstrappers and solo-founders.

Many tools automatically look for a special file called .env, which contains KEY=VALUE pairs, one per line. I am here referring to a file with the same syntax, but with arbitrary names. I use different names to distinguish between configurations for different development stages.

Using environment variables for configuration is pretty much accepted as good practice today for web applications. But it’s always a hassle to deal with them during development, if you are not using a specialised service for them. My current approach is to create separate *.env-file for the development and testing stage: development.env and testing.env. These files use regular bash-syntax for variable declaration:

Once you start a side-project, there comes the time when you ask yourself where to host it. You probably started with a simple project page on your website. But inevitably, the more effort you put into the project, the more you feel the urge to host it on its own domain or sub-domain, am I right?

my-cool-project.com or my-cool-project.ukena.de?

Both have their pros and cons. A sub-domain is usually easier to set up and often comes for free with your existing domain. A sub-domain also has the benefit of making your own relationship to your project more explicit: my-cool-new-project.ukena.de is immediately recognizable as one of my projects, while my-cool-new-project.com is not. Is that a pro or a con?

• What if you listened to advice and tactics of successful founders and then ignore it on purpose?
• What if you focused on the things you enjoy instead of the things that seem most important?
• What if you slowed down when you feel the need to reach your goal?
• What if you took a break when you feel the urge to keep going?
• What if you asked for help instead of doing everything yourself?
• What if you shipped something that is not finished?

Of course, leaving your comfort zone is important. But some things you might have simply heard repeated so many times that you believe they must be true, and thus you should do this as well. What would happen if you don’t?

tl;dr: Scroll to the end of the page, and you will find two one-liners that help you record and roll back Django migrations.

Even though Django has nice built-in support for creating and maintaining database migrations, I find it surprising that one feature seems to be missing: There is no easy way to automatically roll back the migrations during a failed deployment.

I have the following workflow in mind for a typical automated, failed deployment.:

I have been fascinated by the idea of building a business in public for quite some time, years, actually. Building in public is about sharing your progress, your successes and failures, while you are building your business. I haven’t put any research into this topic, and (until recently) I haven’t followed anyone who is actually doing it. But for some reason, I really like the concept.

Why build in public?

The two obvious benefits of building in public from a business perspective can be:

I recently started to time myself when writing my daily blog post. My original intention was to see if the time required to write will decrease over time. I assume it will, but I don’t have any data yet. But now I realized that timing myself while writing has a direct benefit: It helps to stay focused, and it helps me to finish the blog-post. For example, one day I couldn’t really think of a topic. By now I have learned that it’s best just to create a new file and start writing, despite the lack of inspiration. But after a while all the words a had written felt pretty meaningless and shallow. I started to wonder if that is really something I want to publish on my blog. Mr. Perfectionism was starting to get in the way.