Life Codecs Ruminations. Reflections. Refractions. Code.

September 18, 2013

Cherry MX Mechanical Key Switches

Filed under: software dev — Tags: — Kamal Advani @ 19:10

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.

Team Enthusiasm and Productivity

Filed under: general,software dev — Tags: — Kamal Advani @ 17:10

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.

July 14, 2013

Linux Xorg Recovery Tip

Filed under: software dev — Tags: , — Kamal Advani @ 19:36

When you screw up your X drivers, the following is a good way to force “safe” drivers, assuming you have a bootloader that allows you to edit your kernel boot params like grub.

  1. Boot into grub.
  2. Edit the boot entry removing extraneous video related entries like splashscreens, and use the following instead: nomodeset vga=791 forcevesa. Generally, depending on your graphics card, vga=791 forcevesa should do.

The tip was based on looking at the SystemRescueCD distro.

Additionally, so I get a more decent virtual console resolution for day to day use, under Debian I do:

  1. Edit /etc/default/grub
  2. Find, enable if commented, and set:
    # The resolution used on graphical terminal
    # note that you can use only modes which your graphic card supports via VBE
    # you can see them in real GRUB with the command `vbeinfo'
  3. Run update-grub2

December 9, 2012

Oracle JDK on Debian

Filed under: how to,software dev — Tags: , — Kamal Advani @ 21:56

Just came across JavaPackage in Debian. This allows you to cleanly replace OpenJDK with a complying alternative systemwide, the Debian Way. I was only interested in the Oracle JDK, and that worked a treat, not sure about other JDKs. In essence:

  1. Install the JavaPackage package using apt[itude]
  2. Download the .tar.gz JDK package from Oracle
  3. Run make-jpkg, installed as part of JavaPackage, against it (not as root); this produces a Debian package of the tarball
  4. Install the Debian package using dpkg
  5. Finally, use update-java-alternatives to update various Java-related symlinks systemwide. You can choose to only update a subset (e.g. just use the Oracle JDK for the browser plugins, but nothing else), or go the whole hog — all JDK binaries will then be from the Oracle JDK.

The wiki link has examples and details.

PS. I really miss saying “Sun JDK”.

Android with Ivy and Ant

Filed under: how to,software dev — Tags: , — Kamal Advani @ 20:57

Created this template project because I wanted proper dependency management when developing for Android. I chose Ivy because it was the least intrusive, and Android officially supports Ant, which Ivy cleanly integrates with, rather than Maven.

Honestly, making Eclipse and Maven play with each other seems to be a really unnecessary time-sink for most things, it’s stupid. mvn eclipse:eclipse, in my opinion, is a much better approach than m2eclipse or similar “heavy” integrating plugins. Unfortunately, I could not find a similar thing for ADT. Anyway, Ivy is quite cool as a pure dependency manager once you (mostly) get your head around “configurations”.

Anyway, hopefully it is useful to others besides me.

July 22, 2012

Javascript Core Concepts

Filed under: how to,software dev — Tags: — Kamal Advani @ 19:12

Alex Russell’s Google I/O 2011 Learning to Love Javascript video is probably the best Javascript core concepts videos I have seen to date. While I still find the boilerplate required to model what other languages have built-in annoying, the elegance and hackery of building sophisticated things from a small, composable featureset is very neat.

I also love that syntactic sugar is acknowledged to be of use to avoid this boilerplate and unnecessary overload of existing keywords. 60000 incompatible ways to do modules has always been one of my pet peeves for something so fundamental. Javascript in this sense has a case of The Lisp Curse. I do understand that essentially the JS people wish to avoid changing syntax for compatibility, however I think at some point this reticence gets a bit much. Given the alternative browser languages coming up, CoffeeScript being the most mainstream, followed by the Dart initiative, I’d say we have hit that point. Admittedly, Dart is somewhat different, apart from syntactic constraints, it is also attempting to make semantic changes for performance optimisation purposes. CoffeeScript is much more about solving the problem at hand.

“De-Sugaring” as discussed, is the way to go to keep the language core small while allowing more syntactic support. Something like CoffeeScript essentially does this — people should still learn the Javascript core, IMO, before learning CoffeeScript to appreciate the elegance of both languages.

More generally, I had an aha-moment when closures were restated as behaviour that hold on to some state — an inversion of how most of us OO-language users think. This fits very well with my renewed understanding of closures as “closing over” a bunch of state — closed over vars do not go out of scope while the closure is alive. That local vars went out of scope once the function/method completed in many languages, in retrospect, has been the main thing that stopped me from fully “getting” closures when I first looked at it. Then again, it is a subtlety that I had failed to fully appreciate even in Java which does have limited closure support via returning class instances from functions that can reference local vars, so long as they are marked final. By implication, the objects referenced by those vars do not go out of scope whilst the class instance returned holding on to them is alive.

Second satori: As stated above, “the elegance and hackery of building sophisticated things from a small, composable featureset is very neat”, but the syntax is annoying — a language with macro facilities (various LISPs), provides both this composable core, and a unified, extensible syntax. Pretty amazing. In case of LISP, non-syntax really. If only I could get used to the gazillion parentheses of LISP.

Somewhat less elegant than macros (but I love the idea nevertheless) is Groovy‘s parser/compiler hooks which essentially allow you to transform your own syntax/constructs into plain ol’ Groovy at various compilation phases of the program. This is how Groovy allows arbitrary DSLs that do not fit its grammar, a famous example being the Spock Testing Framework.

July 8, 2012

Defaulting to Dvorak on Linux

Filed under: how to,software dev — Tags: , , — Kamal Advani @ 18:15

This is (mostly) a Debian (or derivatives) specific guide to get the Dvorak keyboard layout across the system. Unfortunately, the power of a Unix is also sometimes its curse, in this case, at least as far as I know, there’s no central place to say “use Dvorak”, and have the system honour it. But broadly speaking, there are 3 input areas:

  1. Virtual Console
  2. Display Manager
  3. X session / Desktop Environment (DE)

A ‘modern’ DE like KDE or Gnome, will easily allow you to configure Dvorak through some GUI. I am documenting the case where it is DE-agnostic, and focuses on the X session starting in Dvorak to begin with. So unless there’s a DE override, this should work across all DEs.

Virtual Console

To use Dvorak on the virtual console, on the console issue loadkeys dvorak. This requires the various console keymaps installed. Under Debian, ensure the package console-data is installed; if you issue the command and get a file dvorak not found error or some such, you know you are missing the aforementioned package.

I have not been able to persist a Dvorak-by-default-console setting unfortunately. Will Google some more. There must be a nicer Debian Way, besides just issuing loadkeys directly in some init script. At a per user session, putting it in ~/.profile (or your shell’s equivalent) should work.

Display Manager

Important: This will start your display manager (e.g. GDM, LightDM, XDM) in Dvorak mode! For a shared computer you may not want this!

Edit /etc/default/keyboard, and set/replace XKBLAYOUT=”dvorak”, here’s mine:

# !/bin/sh
# If you change any of the following variables and HAL and X are
# configured to use this file, then the changes will become visible to
# X only if HAL is restarted.  In Debian you need to run
# /etc/init.d/hal restart

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBLAYOUT="dvorak" # was "us", replaced with "dvorak"

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap.  Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz

Note the comment on HAL, I missed it and simply restarted my machine to get it to reload, very lame.

X Session/Desktop Environment

To simply enable a per user X session to start with Dvorak, I set setxkbmap dvorak in ~/.xsessionrc before spawning the window manager. Here’s the full contents of ~/.xsessionrc file (for my own reference):

# see:!msg/chrome/t3vPnF_CTBE/UBba0Dp5w3AJ
nvidia-settings -a InitialPixmapPlacement=0

# enable dvorak by default
setxkbmap dvorak

# rotate portrait monitor output, use 'xrandr -q' to find out output names.
xrandr --output DVI-I-1 --rotate left

# compositing manager
xcompmgr -c &

# accented chars support
xmodmap -e "keysym Alt_R = Multi_key"

# Using xfce4-paneli (and thus all panel plugins) with openbox
# openbox is a lighter wm compared to xfwm
exec dbus-launch openbox-session

Note that you may have to configure your display manager to launch an appropriate X client script, I use Xsession with LightDM.

A slight digression: Many larger DEs do various magic to start-up, I really dislike this lack of transparency — I can see the value of it for absolute beginners of course, but you grow out of it pretty quickly once you come back to the Unix Way. To that effect, I modified LightDM — the display manager I use — to use Xsession. Here are my relevant changes to /etc/lightdm/lightdm.conf:


This will find a ~/.xsessionrc, and execute that post starting the X server. Note that my script is documented above, it’s nice having a central script to hook in everything you need to start your X session with, including the window manager itself.

Switching to Dvorak

Filed under: how to,software dev — Tags: , — Kamal Advani @ 17:19

In the past 4 months or so, I have switched to the Dvorak Simplified Keyboard layout. This post documents the specifics of the journey.


*Added at Will’s request.

  • I never really learnt to touchtype properly. Thought this would be an interesting skill to have.
  • I was a little bored, and feeling a little crazy.
  • I wanted to be a l33t dvorakista. Work in progress.


  • To learn, I don’t think you can get any better than Dan Wood’s ABCD. It has been a joy to use!
    It is lowtech, so you will need to gauge your own accuracy; for me this worked out better. What you type out is also fairly entertaining!
  • ABCD does not list finger positions visually, so google a guide accordingly.
  • ABCD — it rocks. This is the only guide I used during the learning phase.
  • For general Dvorak information, check out Marcus Brooks’ Dvorak Page, very useful.


  • To practice short daily-use words, I use 10FastFingers.
  • For much longer words, fits the bill rather well.

Migration Strategy and Execution

  • Practice at home for about 2-3 weeks for 30 mins to an hour. It will take you at least that much time to complete an ABCD lesson at first!
  • After 3 weeks, use Dvorak exclusively at home, at the cost of feeling like a retard when chatting with friends. And crying each time I had to code.
  • After a month or so, switch to Dvorak at work. I am a programmer, so this was risky, I had to be confident enough to use it. Code completion was indispensable. Having a dev/team/architect lead who also uses Dvorak is likely even more indispensable. (Is “indispensable” subject to gradation? Also google “indispensIble” vs. “indispensAble”, what a mess.)
  • Around 2 to 2.5 months later, finally feel comfortable typing with Dvorak, though by no means fast. Around this time, reached 40-45wpm. Enough to stick to Dvorak!
  • Due to disuse, Qwerty muscle-memory began to fade!
  • 3.5 months or so later, likely covering my previous qwerty speeds. Able to chat without being considered a keyboard noob.
  • Qwerty muscle-memory gone.

Tips and Personal Ideosynchrasies

  • I found using sophisticated typing tutors, especially those with beeps very annoying. Visual cues are fine and useful, but beeps are frustrating and counterproductive IMO.
  • It will be painful at first, have no doubt about it.
  • It helped that I never learnt to formally touchtype, so this was a skill learnt from scratch.
  • Actually memorising the layout was extremely intuitive to me, all my attempts to learn qwerty touchtyping had failed in the past — it just made no sense. Dvorak actually has, for the most part, a logical system to the keyboard.
  • Shortcuts are one case where I have had to visually mind-map qwerty keys to Dvorak, so I do not have to move to the home keys just to execute a shortcut! It honestly is not that much effort though.
  • Passwords are another pain-point, you need to really let go and have your muscles do their thing, instead of relying on visual feedback too much — which you obviously don’t have when entering passwords.
  • Shell-foo: special characters and shell commands, some not being English words per se takes practice. I am still not as fast as I wish on the shell, unless I am in the zone.

Greasemonkey Scripts

Filed under: software dev — Tags: , , — Kamal Advani @ 16:40

I am very late to the greasemonkey party, and likely this has all been done, however:

Converting from Mercurial to Git

Filed under: software dev — Tags: , , , — Kamal Advani @ 16:31

This is basically augmenting (and repeating) this guide.

# get the hg-fast-export util
git clone git://

# create your git target repo, and cd into it.
git init git_migration_target_repo
cd git_migration_target_repo

# export the hg repo into (current git repo)
/path/to/ -r /path/to/old/mercurial_repo

# don't forget to do this! or git status will show you a bunch of deletes
git checkout HEAD


  • Under Debian, you can issue aptitude update && aptitude hg-fast-export, rather than cloning the repo, unless you want the latest and greatest I suppose.
  • My main use case was converting my bitbucket repo to git, I did the following:
    • bitbucket: renamed the mercurial repo (say call it “foo”) to foo-hg
    • bitbucket: created a git foo repo
    • local: git clone the empty foo bitbucket repo
    • local: perform the migration above into the cloned repo
    • local: push the cloned repo to bitbucket
    • bitbucket: trash foo-hg!
Older Posts »

Powered by WordPress