# Password databases: Migrating from KeePassX to Pass

I spent some spare hours on the week-end playing with Pass, importing my KeePassX database into password-store and synchronising it to a GitLab private repository.

It's a little tricky to get it set up, with a few moving parts, so I'm still experimenting. Here's what I've figured out so far.

Passwords. We all have a lot of them to remember — most of us have too many. How do you keep track of them all?

Originally I used to just remember passwords for everything, like most people. I soon found this doesn't scale past about 7 passwords and PINs. Rather than use the same passwords everywhere, I started to keep a secret list of passwords, but it was a pain to keep that list with me, and what if it was discovered?

After been keeping my passwords in a GPG-encrypted text file for a few years, I then started using a KeePassX database, and that's been pretty successful. I sync the database to my phone so that I can have my passwords with me whenever needed, but it is a little bit clunky to use.

At the recomendation from someone at work, I checked out pass, “the standard Unix password manager”. It offers all the features I've been using from KeePassX for a few years now, only with much better syncronisation based upon git+ssh.

Pass is also integrated into browsers, editors, and even a few operating systems, so it's potentially a lot less clunky and risky to use than how I was using KeePassX with passwords entered via the system clipboard.

This post reviews my password management approaches to date and gives an overview of Pass.

# Learning DVCS Workflow - 1

Tonight I learned a basic git trick that was not immediately obvious to me, but should have been, I guess.

I've been switching my Spacemacs back to the master branch to try trouble-shoot a performance issue I'm having on the Macintosh where it just hangs occasionally. My master is tracking to Spacemacs master which is still at 0.200.13. I haven't touched it in over a year, and there are some things that I wanted from my develop branch.

I want to merge in the latest version of those few files, but not everything on the branch, so a merge is not the right operation.

# 4-bit Rules of Computing, Part 4

Here is the fifth part of my blog series expanding on my 4-bit rules of computing.

In this post: rules 7, 8, and 9; which discuss testing and debugging. They are all related in a way: having to do with making good-quality craft work. Because, as much as computer people like to believe that we're "engineers" or that this is "computer science", we're not really. We're crafts people, in a profession that's still very young and finding its roots and methods in order to be consistently successful.

I'm definitely not trying to pretend I'm an "engineer". For real rigour, there is much more required than a few simple rules. But these are some realistic and humble rules in the area of testing that I aim to stick to.

# Learning DVCS Workflow - 0

If you take look at the revision history for some of my projects on GitHub, you'll see that I have a fairly messy track-record!

A few times I have successfully used Magit's ability to interactively stage/unstage Hunks or parts of Hunks, to make my commits a bit more clean and sensible, but not always.

The real problem is: I haven't been using Branches. It's because I haven't studied how to use them effectively, and in the past they've been scary.

But for the future, and especially for my dotfiles, I'd like to be able to read through the commits and make sense of them after. Also I'd like to be sure when I'm committing that I don't make any unplanned master changes and break things.

I also tend to work by myself on these projects, but I'll often go on a tangent, or start a blog post and then put off finishing it while another, different idea is developed and maybe even published first. Ideally I should be able to track these things separately.

So I need to learn: how to do revision control workflow with branches, properly.

# 4-bit Rules of Computing, Part 3

Here is the forth part of my blog series expanding on my 4-bit rules of computing.

Previously in Milosophical Me: Mike was reflecting on Comments, both in source code and in social media, and had come to the conclusion that they are to be avoided, that they can be more harmful than helpful, and that source codes (and people) should be allowed to speak for them selves.

There is an exception to Rule 5 (Rule 0 allows for this): doc-comments. In this post I explore what they are, how they differ from regular comments, and how to use them to assist your fellow hackers.

# Exploring Minecraft code in Jupyter

Some breif notes from a lazy Sunday morning spent exploring the minecraft coding environment that I set up using Raspberry Jam earlier. I'm taking my notes in Jupyter while I explore the Minecraft API and poke around with one of the sample programs. Since my blogging engine Nikola also supports Jupyter Notebooks as one of it's import formats, I found that I could do Litterate Programming for Minecraft quite nicely!