Month: March 2017

My lightbulb moment with modular design

Cameron Lock, of Yammer fame, describes the complexities involved that led her and the team to a simpler, more modular approach to the mobile application design.  The most important bit after grouping everything into modules, practically, I think, is this:

We stopped defining margins between modules. Instead, all the spacing in the app would come from padding within the modules — specifically, top padding. Bottom padding would have worked, too; just not both. The key is to choose one of the two and stick with it.

awless – a Mighty CLI for AWS

awless is a command line interface to the Amazon AWS.  While Amazon AWS already has its own set of tools for command line interface, awless makes things even simpler, with the following features:

  • run frequent actions by using simple commands
  • easily explore your infrastructure and cloud resources inter relations via CLI
  • ensure smart defaults & security best practices
  • manage resources through robust runnable & scriptable templates (see awless templates)
  • explore, analyse and query your infrastructure offline
  • explore, analyse and query your infrastructure through time

SELinux Concepts – but for humans

SELinux has been an annoyance for me since the early days of Fedora and Red Hat bringing it into the distribution and enabling by default (see this blog post, for example, from 2004 about Fedora 3).

Over the years, I’ve tried to learn it, make it useful, and find benefits in using it, but somehow those were never enough and I keep falling back on the disabling it.  But on the other hand, my understanding of how SELinux works slowly is growing.  The video in this blog post helped a lot.

And now I’m glad to add another useful resource to the “SELinux for mere mortals” collection.  The blog mostly focuses on the terminology in the SELinux domain, and what means what.  It’s so simple and straight-forward, that it even uses examples of HTML and CSS – something I’ve never seen before.   If you are making your way through the “how the heck do I make sense of SELinux” land, check it out.  I’m sure it’ll help.

How To Use Git to Manage your User Configuration Files

There is probably a gadzillion different ways that you can manage and synchronize you configuration files (aka dotfiles) between different Linux/UNIX boxes – anything from custom symlink scripts, all the way to configuration management tools like Puppet and Ansible.  Here are a few options to look at if you are not doing it already.

Personally, I’m using Ansible and I’m quite happy with it, as it allows me to have multiple playbooks (base configuration, desktop configuration, development setup, etc), and do more things than just manage my configuration files (install packages and tools that I often need, setup correct permissions, and more).

Recently, I came across this tutorial from Digital Ocean on how to manage your configuration files with git.  Again, there are a few options discussed in there, as even with git, there’s more than one way to do it (TMTOWTDI).

The one that I’ve heard about a long time ago, but completely forgot, and which I think is quite elegant is the approach of separating the working directory from the git repository:

Now, we do things a bit differently. We will start by specifying a different working directory using the core.worktree git configuration option:

git config core.worktree "../../"

What this does is establish the working directory relative to the path of the .git directory. The first ../refers to the ~/configs directory, and the second one points us one step beyond that to our home directory.

Basically, we’ve told git “keep the repository here, but the files you are managing are two levels above the repo”.

I guess, if you stick purely to git, you can offload some of the additional processing, such as permission changes and package installation, into one of the git hooks.  Something like post-checkout or post-merge.