Life Codecs @

Ruminations. Reflections. Refractions. Code.

Mar 14, 2017 - Software dev

Docker Container as a Shell

Most of my work is done either on a Macbook Pro, or my Linux desktop. As much as macOS is a Unix, with supporting tools like MacPorts, Linux is still richer as far as commandline utilities go.

Prior to native Docker support on macOS/OSX, you would resort to running Linux in a virtual machine, and having a share directory.

With Docker, we basically emulate the same, but obviously, native Docker on the Mac, or Windows 10 for that matter, is far more lightweight than a VM. Note that this is not a very container’ey use of Docker where everything you need is ready to deploy right from the image.

The approach I’m taking for this use case is basically to treat a Docker container as a lightweight VM, with adhoc tooling installed — essentially a rolling-release style VM, occasionally taking snapshots, and pushing up to the docker registry so it’s shareable across machines.

The overall approach is:

  • Pull down an existing container, I went with ubuntu
  • Tag it as your own and push to your docker registry. Follow instructions here on this step.
  • Pull down your tagged image
  • Create a script that will mount your home directory as a volume. Thereby providing you with a live workspace to execute your container utilities against. I have nearly all my work in my home directory, so this mount makes sense, but it’s simply a regular mount.
  • Create a user in the container, so you don’t constantly log in as root.
  • Commit and push the container’s changes as needed.

Your data is still in your host’s home, while the utilities are installed in the container.

Running docker commands is a pain if you do the above workflow often. Here I’m providing the scripts and utilities I wrote. Replace with your custom values as needed.

My Docker utility run script. Note that it’s already using my tagged ubuntu image. So the tagging and pushing step is a prerequisite.



docker run -dt \
  --name ${CONTAINER_NAME} \
  -h ${HOSTNAME} \
  -e ${TZ} \
  --volume ${HOST_HOME}:${CONTAINER_HOME} \

I also added a bunch of utility aliases for common container tasks in ~/.bashrc:

#### Local Shell Container ####

alias d=docker
alias ubuntu-deploy-container='~/projects/checkouts/desktop-scripts/'
alias ubuntu-commit='d commit ubuntu kva1966/ubuntu:latest'
alias ubuntu-push='d push kva1966/ubuntu:latest'
alias ubuntu-stop='d stop ubuntu'
alias ubuntu-start='d start ubuntu'
alias ubuntu-run='ubuntu-stop; d rm ubuntu; ~/projects/checkouts/desktop-scripts/'
alias ubuntu-delete-container='ubuntu-stop; d rm ubuntu'

ubuntu-login-user() {
  if [ -z $username ]; then
  d exec -it -u $username ubuntu bash -c "cd $homedir; exec ${SHELL} --login"

alias ubuntu-login='ubuntu-login-user xdyme'
alias ubuntu-login-root='ubuntu-login-user'

#### END Local Shell Container ####

Some very basic .bashrc and .profile can be found when you login to the xdyme user on my container. Mainly git completion, and a nicer looking default shell.

Jan 27, 2016 - general philosophy

Who Do You Work For?

Corporations often talk about values. Expected behaviour and human traits that the corporation deems necessary to achieve its goals as a whole. It is expected that all levels of the organisation will display these traits. Of course, anything involving people is bound to have its own challenges. It is very difficult to instill values in people; more so adults.

The idea behind value statements is legitimate, and having this framework of character is certainly a step in the right direction. When the toplevel folks consistently display these values, employees down the chain either fall in place, or leave. I am, for the moment, ignoring matters of hiring the right people, a non-trivial problem worthy of its own post (many, many posts).

In effect, it is people that bring values and traits to life. Without enough people making these values pervasive, they mean nothing. Words on a corporate brochure.

Very few places I can think of — in fact, just one, my extended family, the BKC — have values so tangible, that, it would seem even if not one human were left in the place, those values would remain alive, palpable. One gravitates to the promoted values nearly by osmosis. Such places are the exception rather than the norm, of course. Given this, I have come to the epiphany, that for most other corporations, I cannot possibly work for the company. I work for people at the company. Together, we progress the organisation. The latter is nearly a side effect. But it is very much akin to having money as a side effect of providing value, not a particularly big idea by now one would hope.

Management experts like to use terms like “restructuring”, as if an organisation is a malleable construction of easily replaceable lego blocks. In 2016, that many places do not recognise just how organic, just how alive, and how cellular in nature corporations are, is a cause for sadness. Until the importance of people takes precedence, and not just as lip service, everything tends towards disorder, or at best, mediocrity.

One must consider that to start a company, to drive it to provide value and derive profit — the beginning — takes a huge amount of energy. Most company founders are smart and driven. To me, a state of mediocrity (or perhaps, complacency) is when only this initial impetus moves the company in, essentially, auto-pilot mode. When no more of the same drive and energy is applied to achieve continuous innovation.

I recall a Yow! event I attended recently, the speaker — I believe from Netflix — mentioned that execs from other companies often mentioned how they could not hire good people. To which the speaker responded that many of Netflix’s engineers were hired from these execs’ companies. The phrase “damning evidence” comes to mind.

Sep 28, 2015 - Uncategorized

The Second Law of Thermodynamics

Often simplified and paraphrased (mostly by software folks, like yours truly, and pop sci crowds) to “everything tends towards entropy”, the law is surprisingly applicable to wide range of scenarios. Which, I suppose, should not be surprising given the universe and humans forming the ecosystem are simply bags of vibrating, heat-producing molecules. The last statement was not meant to be cynical, nor do I subscribe to the view that consciousness is a purely emergent physical phenomenon, but I am abstracting for the sake of this post. But, I digress.

In software we see the law in the phenomenon known as Software Rot or Bit Rot, or some variation thereof. But, “as above, so below”, the same law applies to groups of people, to companies, to relationships. When a group stops making an effort to be better, then it does not simply stay in place, it tends towards a rotting state. Complacency is bad not because it stops you from progressing, it’s bad because it regresses you. Sometimes, I wonder if there is such a thing as a state of true rest.

Consider now, that if the ‘natural state’ tends towards entropy, what the effect of catalysts towards that state is?

“Is there a point to this post?”, I hear my readers (I should have at least two…) say. Sort of, just one of those days when you wonder why you are in the industry you are. I rarely drink, but, days like this I sympathise with the wise words of jwz, “This is why I sell beer“. People, including myself, simply do not learn.

Jul 19, 2014 - software dev

Set If Not Null ‘Pattern’ in Java 8

When working with business entities, many of them will involve a mix of complicated logic, and plain CRUD data. Often we will have some update or create method where an incoming DTO or Request object will have a subset of fields to source details to update the target entity. Even when trying to restrict the scope of the DTO to what an operation needs (an idea I am a big fan of), it may still be course-grained enough for that scope, and still have nullable/optional fields. The resultant code will need to do null checks and decide what to source and what to ignore. Simple example:

 1class User {
 2  private String firstName;
 3  private String lastName;
 5  // ... getters ...
 7  // private setters
 8  private void setFirstName(String value) {
 9      firstName = value;  
10  }
12  private void setLastName(String value) {
13      lastName = value;  
14  }
16  public void update(UserDto dto) {
17    if (dto.getFirstName() != null) {
18        setFirstName(dto.getFirstName());
19    }
21    if (dto.getLastName() != null) {
22        setLastName(dto.getLastName());
23    }
24  }
26Digression: generally, I avoid public setters entirely.. business
27objects need specific business methods to manipulate/update them. We
28should stop (yeah... like since 2000 at least) thinking of them as
29anaemic wrappers of fields.
31However... private setters can sometimes be useful for encapsulating
32internal checks.

The issue here is with the null checks. Prior to Java 8, for simple values like Strings, there was no way to factor out the annoying null checks (well, not without more verbose artifacts like wrappers to create, or lose type safety and use reflection, blergh…).

What I really want to say is: setIfNotNotNull(fieldToSet, valueToUseIfNotNull).

Now, since String refs are immutable, we can’t pass them in to update in setIfNotNull(…), the local ref will simply be overwritten with a new value… enter our setters, which have a common format of void setFoo(T val). Making use of Java 8 Method References we can achieve what we want in a typesafe manner:

 1class User {
 2    // ...
 4    public void update(UserDto dto) {
 5        setIfNotNull(this::setFirstName, dto.getFirstName());
 6        setIfNotNull(this::setLastName, dto.getLastName());
 7    }
 9    // note the use of java.util.function.Consumer -- a suitable archetype
10    // for setter methods.
11    private <T> void setIfNotNull(final Consumer<T> setter, final T value) {
12        if (value != null) {
13            setter.accept(value);
14        }
15    }


Of course, you can use lambda expressions where we used method references, but in this case, the existing methods encapsulate the logic we need.

Now, to see how far I can take this… I am reminded of Simplicity, Clarity, Generality… it never ceases to amaze me that the timeless 3 traits, more often than not, support each other.

PS. to get up to date with Java 8, Java 8 for the Really Impatient does a stellar job. However, you will have to be patient in parts (I did anyway :P).

PPS. I am still coming to grips with Optional types, and hence have not mentioned this as an alternative to null checks.

PPPS. Sorry about using the term ‘pattern’, it was an attempt to sugar coat the phrase ‘crappy-as rote work’. (There, Tommy). 😛

Sep 18, 2013 - software dev

Cherry MX Mechanical Key Switches

Came across this article recently explaining the Cherry MX key switches used in mechanical keyboards. Very informative.

On mechanical keyboards, these are some interesting links:

  • Mechanical Keyboards Terms explains the various terminology used in describing properties of a mechanical keyboard. Look through this if you don’t get terms used in the Cherry MX article above.
  • Das Keyboard can be probably be credited as the company that brought the ‘cool-factor’ to mechanical keyboards. Aesthetically beautiful keyboards, too. They even allow selecting your Cherry MX switch, allowing blue, red, or brown. They have a Mac edition too for all you Mac owners.
  • WASD Keyboards sell mechanical keyboards with lots of customisation options!
  • CODE Keyboard is a more recent invention by Jeff Atwood (of Coding Horror and StackOverflow fame) putting together quite a few neat features, his dream mechanical keyboard. I like that it has a Dvorak dipswitch too! Interestingly enough, it uses the clear Cherry MX switches which is non-clicky like the browns, but has a higher actuation force. It went out of stock very quickly!

Now to decide between blue and brown (or clear… hmmm..)… do I want the noise or don’t I want the noise… dilemma, dilemma.

Sep 18, 2013 - general software dev

Team Enthusiasm and Productivity

A friend posted this HBR article on the transience of high-performing teams on his Facebook account. This got me thinking, and commenting… thought a blog post might be a better medium to express my thoughts.

Overall, I agree with the article, but I think it, possibly deliberately, does not consider what can be done in more corporate workplaces, where team members tend to stick around for about 2 to 3 years on average.

Keeping this premise in mind — I think the cause of complacency/comfort is doing the same thing over and over again. In many creative fields, this is recognised as an issue. I would say many more “corporate” fields are also “creative”, but not recognised as such, in particular (as it affects me), writing software. This has made real gains in those fields pretty elusive, and limited to a few select teams where the creative aspect is acknowledged, or obtained through accidental discovery then subsequently forgotten.

To me the answer to battling complacency is simple: there needs to be regular, short breaks, where you go do something different but related for a period. For example, explore some new technology, some new framework you think would amount to eliminating some pain point in your core product. Or write some experimental feature integrated into the core product even if there is no known business requirement for it. Or, write something orthogonal to the core product, a support tool. You get the idea: something that makes the employee happy even if there is no immediate business driver for it.

Digression: Speaking of business/customer drivers, it’s a good time to remember Henry Ford’s quote: “If I had asked people what they wanted, they would have said faster horses.” So customers are not the only people who gain insights into what they need. Neither is just management, nor just developers. That’s the point of a team — a collective hive mind.

Back to the core issue, ideally, these breaks need not be accounted for stringently — their purpose is intangible. To require say a short discussion of what one did is very reasonable, but to require that it produce something that adds to the bottomline directly is not reasonable IMV.

One might consider Google’s 20% time, but from what I gather (and I could be wrong here), that time is accountable and you MUST produce something which then feeds into employee performance reviews, etc. For me, that is a fallacy, and misses the point of this “productive downtime” idea I am proposing.

Complacency in my view is a form of mild boredom, and this implies being in a sort of shallow rut. To get out of ruts, people need to do something differently. Employers though are generally not creative enough, or brave enough to allow such measures, due to at least the following reasons:

  1. Trust: In some places, employee/employer relationships have a trust issue, say because in the past employers were bitten by employees abusing leniency. The reaction is human… but equally human is to get over it and not let one or two experiences taint one’s outlook for life.
  2. Excessive Sense of Accountability to a Board: A form of paralysis which forces management members to only ever make “safe”, mundane choices. Unfortunately, safe and mundane choices lead to safe and mundane results a lot of the time.

    I am not proposing constant risk taking — we need to ship and produce within reasonable timeframes… but there is no doubt that calculated risks and a willingness to be different in a positive way are behind some of the greatest successes.

    I would also argue one of the tasks of management is to be able to shield deserving creative people from the scrutiny of an uninformed board.

  3. Excessive Adherence to Best/Established Practice: At one point in time, slavery was established practice. It was a given. That’s how things were done. Was it right? I am all for properly backed studies, but they do not always apply. I also find there’s a bit of selective best-practice adherence, i.e. some places only use best-practices that will please management, but discard others that may in fact be required for the adopted practice to work! It’s like going on a diet without exercise, or exercising but keeping to your 30 Big Macs per night diet.

  4. Lack of Understanding of Staff Psychology: If employers are managing say, software projects (me biased? What bias?), it is necessary they understand the drivers and motivators of software developers. What makes software people tick exactly. I think here we have a generational gap problem too… many of us got into software because it was different, it has a joy of its own. But it is scientific, precise, and creative all at once; thus a lot of software developers suffer the same psychological issues as say artists and actors. Yet, we work under fairly corporate conditions. So there is a mismatch.

    This point is then inexorably linked to the point on Trust… how can you trust easily what you do not understand…

    Granted there are software developers that come with a sense of entitlement… just as there are managers that come with the same. That is an individual issue, the punishment cannot be applied to the whole species.

In my view, there are plenty of things employers can do to improve team morale (and thus output). It just takes some willingness, some creativity, some courage, and some trust.