What’s your skateboard?

mvp

Minimal Viable Product is a cornerstone of Agile software development but very often (wilfully) misunderstood or misinterpreted. In a lengthy, but very readable, blog post, Henrik Kniberg of Swedish consultants Crisp gives the clearest example I have read yet of what MVP means in practice and why he thinks we should also add three more steps before MVP – Earliest Testable, Earliest Usable and Earliest Lovable Product versions.

 

More:

 

Brackets keyboard shortcuts now available in Dash

Dash, the documentation browser and code snippet manager for OSX, now includes a cheatsheet for Brackets editor, version 1.3

 
Dash is an excellent offline documentation browser and code snippet manager for OSX and iOS (though there are also “officially sanctioned” 3rd-party versions for Windows and other platforms).

Yesterday I submitted a pull request to the cheatsheets repo on GitHub that adds a cheatsheet for Brackets 1.3 keyboard shortcuts to Dash. Earlier today my change was accepted by Kapeli (a.k.a. Bogdan Popescu) and the cheatsheet is now available for download from within Dash.

To install it, first open the Dash Preferences then:

Select Downloads
Step 1
Choose Cheat Sheets
Step 2
Locate Brackets and click Download
Step 3
The Brackets cheatsheet as it appears in Dash
The Brackets cheatsheet as it appears in Dash


This version of the cheatsheet covers keyboard shortcuts for Brackets for Mac, version 1.3.



More:

The work #5

We are all many things. We all do many things. We will do many more things throughout our lives. Yet, when we are gone, most will primarily remember only one of them. They will pick from the lot and remember you as that. What they pick will, in their mind at least, be all that you are. Therefore, it is our job to ask ourselves with all the things we allow ourselves to do, with each and every one, “Is this something I want to be remembered for?”

— Patrick Rhone, “What Will You Be Remembered For?”



More:

Use concept naming to simplify and clarify your Javascript conditions

Concept naming comes naturally to most people but is still rarely seen in Javascript despite the benefits. In this post I’ll illustrate how a simple technique can make your Javascript code significantly more readable.

 
The benefits of writing simple, clear and human-readable Javascript code are well known if not always well practiced.  The other day, while skimming the source of some of the rules bundled with ESLint, I was pleasantly surprised to see many of them made use of “concept naming” for conditions. This is a practice common in many other programming languages but not something I see being used in Javascript very often, despite the benefits.

Let me illustrate the technique with a simple code snippet:


if (charsToMatch[line.charAt(cursorPos.ch)]) {
    // do something
} else {
    // do something else
}

The condition on line 1 is trivial but even something this simple can make us stop and pause as we try to work out what the test is doing, and why. If you’re new to the code or just haven’t worked on it for a while a lot of valuable time can be wasted trying to get an overview of the application flow. Each time we hit a condition we have to pause and ask “what are we trying to achieve here?”.

We could, of course, add a comment immediately before the condition but comments can quickly become out-of-date, incomplete or just plain wrong. For that reason there has been a general trend over the last few years to minimize or reduce the number of comments in source code, or even to abandon them altogether.

When it comes to conditions, there is a simple and reliable way of making your code more understandable – give a name to the concept that is expressed in the condition. In our simple example the intent of the condition might be to determine if the character at the cursor position is one that we don’t want to allow a user to enter. This is determined by checking if it appears in an array – charsToMatch.
We can rewrite our snippet to illustrate this concept:

var charAtCursorIsNotAllowedInInput 
       = charsToMatch[line.charAt(cursorPos.ch)];

if (charAtCursorIsNotAllowedInInput) { 
    // do something 
} else { 
    // do something else 
}

If I were to glance at the snippet above for the first time, I still wouldn’t necessarily know the specifics of the conditional test but I would immediately be able to glean the intent of the condition. It now more closely reflects how we think – in concepts rather than conditional statements – and is much more readable.

Of course, as conditions increase in complexity the benefits will become more apparent:

var charAtCursorIsNotAllowedInInput 
       = (charsToMatch[line.charAt(cursorPos.ch)])
         || (cursorPos.ch >= 0 
         && charsToMatch[line.charAt(cursorPos.ch - 1)]);

if (charAtCursorIsNotAllowedInInput) { 
    // do something 
} else { 
    // do something else 
}

In this snippet the test is more complex but the concept is unchanged and what is trying to be achieved is instantly understandable.

Am I suggesting you should always name your conditions? No. There is, of course, a slight overhead in the “noise” introduced by the extra variable (which I consider a small price worth paying) but, just as you wouldn’t find it necessary to comment every condition, you wouldn’t necessarily want to assign a name to every one either. As always, common sense and consideration for those that will come after you goes a long way.

I hope you can see from these simple examples that, like the judicious use of clearly named variables, applying concept naming to your conditions can make your Javascript code significantly more readable and easier to maintain.

Sensible global shortcut key definitions for iTerm2

Despite being a Mac-only product, the terminal replacement iTerm2 defaults to using very un-Mac-like shortcut keys. Fortunately, this is easily remedied.

 
Earlier today I updated my configs repo on GitHub to add the settings I use for the OSX terminal replacement iTerm2. When I installed iTerm2 I left many of the settings unchanged from their presets but one section I immediately updated was the global shortcut keys. These are initially set to reflect the illogical, outdated and downright bizarre shortcuts used in the editors of yesteryear – Vi and Emacs – and I wanted them to behave more like the standard OSX shortcuts. Thankfully, iTerm2 makes this very easy to do.

The shortcuts can be configured in the Keys section of the preferences (accessed via the iTermPreferences menu item). Below are my updated settings:

iTerm2 global shortcut keys redefined to be more OSX-like
iTerm2 global shortcut keys redefined to be more OSX-like

Only 7 key combinations were changed:

  • ⇧⌘↑ became Scroll One Page Up
  • ⇧⌘↓ became Scroll One Page Down
  • ⌃⌘↓ became Scroll To End
  • ⌥← became Send ^[ b i.e. Move Cursor Left One Word
  • ⌘← became Send Hex Codes: 0x01 i.e. Move Cursor To Start Of Line
  • ⌥→ became Send ^[ f i.e. Move Cursor Right One Word
  • ⌘→ became Send Hex Codes: 0x05 i.e. Move Cursor To End Of Line

Shortcuts are redefined by double-clicking on the entry then selecting the new action to be applied. In most cases you simply want to chose a predefined action such as Scroll to End:

iTermAction

though for Move Cursor To Start Of Line and Move Cursor To End Of Line you should chose Send Hex Code as the action and enter the appropriate code (0x01 for start of line and ox05 for end of line):

iTermHexCode

 

Similarly, for Move Cursor Left One Word and Move Cursor Right One Word you should chose the Send Escape Sequence action and enter the appropriate code (b for left one word and f for right one word):

iTerm_EscapeCode

 

After closing the preferences dialog your new shortcuts will be available for use.


More:

  • iTerm2
  • configs – some of my config files, including the one I use for iTerm2