When to hard-code

Hard-coding is generally considered an anti-pattern and abhorred by experienced developers. Input and configuration data should be externalized from the code, or at the very least parametrized to a language constant.

While working at Wellmo, I’ve come to reconsider this pattern. In fact, I now often advocate hard-coding special cases when first encountering them. I have written and tested production code reading

// TODO: Hard-coded logic
if ("myGroupId".equals(group.getGroupId())) {
    // do stuff
}

and I’m fine with it.

The rationale comes from lean principles. You shouldn’t build something that you don’t know is needed. Especially in a startup, uncertainty is the often norm. New, very specific features are often required without full knowledge how it will fit into the grand scheme of things.

The above example code is from a case where a certain group of users needed to see a group that is hidden from others. I knew that showing / hiding groups is something we need in the future, but I wasn’t exactly sure what the conditions would be.

Instead of creating some generic mechanism for configuring group visibility, I hard-coded that case. Several months down the road, we now have more insight into what the proper logic is, and we are currently implementing that. It’s radically different from what I would have implemented at the time. Premature configurability would have been a waste of time.

Another example is a case where an item needed to be branded differently for certain customers. Instead of designing a way to configure the branding, we simply wrote an if-condition that selected between the two options. Half a year later the alternative branding was removed, and we simply removed the few lines of code. No generic logic was ever needed.

My suggestion is to hard-code cases when:

  • there is uncertainty on how the generic logic would work
  • only a single, short portion of code is affected
  • the proper, generic logic can later be introduced without affecting other code

It is imperative that hard-coded logic is replaced when more similar special cases arise. This requires good communication and understanding between management and the developers. Otherwise it may be difficult to explain why a third similar case is slower to implement than the first two.

Posted in Coding | Tagged | Leave a comment

Backup KeePass2 database on Linux

There are several instructions on how to use the KeePass2 trigger mechanism to create a backup of your password database when saving the database.  However, all of the instructions I found were for Windows.  It took a bit of figuring out what is the proper configuration on Linux, so here are the necessary steps:

  1. Select ToolsTriggers…
  2. Click Add…
  3. Type the name Backup database on save and make sure Enabled and Initially on are checked
  4. Under the Events tab click Add…, select Saving database file and click OK (ignore the conditions)
  5. Under the Actions tab click Add…, select Execure command line / URL and type in the following:
    File/URLcp
    Arguments"{DB_PATH}" "{DB_PATH}.{DT_SIMPLE}"
    Wait for exit:  checked
  6. Click OK a few times

This will create a backup of the database file every time you save it (before the save).  The backup will be in the same directory as the original, with the current timestamp appended to the name.  If you prefer to backup to a different directory, use "/path/to/backups/{DB_BASENAME}.{DT_SIMPLE}" as the second argument instead.

Posted in KeePass, Security | Tagged | Leave a comment

Hybrid app testing using dynamic DNS

Hybrid apps simplify implementing cross-platform mobile applications in many ways.  You only need to write the HTML once, and it should work on all platforms.  However, you still need to test those platforms.

At Wellmo, we do most of our development on local environments using a browser, and test the functionality on phones afterwards.  This poses a problem:  We have a bunch of test devices, but each time you’d want to test on one, you need to install a new native client pointing to the appropriate environment (often your own local environment).  What’s worse is that iOS applications can be developed / deployed only on a Mac and Windows Phone applications only on Windows.

We solved this issue by using dynamic DNS addresses for each device, which allows any developer to point any device at any environment with a single command.

Continue reading

Posted in Hybrid apps, Testing | Tagged , , | Leave a comment

Using Spark with MongoDB

I recently started investigating Apache Spark as a framework for data mining. Spark builds upon Apache Hadoop, and allows a multitude of operations more than map-reduce. It also supports streaming data with iterative algorithms.

Since Spark builds upon Hadoop and HDFS, it is compatible with any HDFS data source. Our server uses MongoDB, so we naturally turned to the mongo-hadoop connector, which allows reading and writing directly from a Mongo database.

However, it was far from obvious (at least for a beginner with Spark) how to use and configure mongo-hadoop together with Spark. After a lot of experimentation, frustration, and a few emails to the Spark user mailing list, I got it working in both Java and Scala. I wrote this tutorial to save others the exasperation.

Read below for details. The impatient can just grab the example application code.

Continue reading

Posted in Coding, MongoDB, Spark | Tagged , | 17 Comments

CoffeeScript woes

I recently wrote a piece comparing CoffeeScript, TypeScript and Dart.  For the UI component of Wellmo, we decided upon using CoffeeScript.  While this has been a great leap from JavaScript, we’ve had our share of setbacks.  Here’s a few issues that are good to know about when using CoffeeScript.

Continue reading

Posted in Coding, CoffeeScript | Tagged | 6 Comments

Modifying the pace of audiobooks

I’ve recently started listening to audiobooks.  They’re a convenient way to enjoy books on your way to work or while driving.  After listening to Mika Waltari’s The Egyptian, I took on The Hunger Games, read by Carolyn McCormick.

Like many who have reviewed the audiobook, I had an immediate disliking of the narration.  It was not so much her voice, but her pacing.  She does not give time for the words sink in.  It was a constant, mild irritation  the book could be so much better if the reader took just a little more pauses.  Rather than giving up on the book, I started coding.

I wrote a Ruby script, Audiobook Pacer, that can change the pace of reading of an audiobook.  (I first tried writing a LADSPA plugin, but it seems they cannot modify the length of the audio.)  The script works by adjusting the length of pauses the reader takes between sentences and paragraphs.  All pauses longer than a specified time are lengthened or shortened by a set percentage.  Breaks between words shouldn’t be modified, as this may break the flow of the sentence.

In the case of The Hunger Games, I increased by 25% the length of all pauses longer than 0.6 seconds.  The change is subtle, but it makes all the difference between constant irritation and enjoyment.

Update:  After listening to the Games for a few hours, I started getting irritated by the narration once more.  It turned out I had converted only half of the files.  After modifying the pace of the rest of the files enjoyment prevailed.

Posted in Coding, Ruby | Tagged , , | Leave a comment

Testing visual appearance with Cucumber + Watir

One of the great things about Cucumber and Watir is that it allows you to write functional tests that are decoupled of the UI.  By using page objects, the definition of how the UI works is decoupled from the tests themselves.  If the UI changes, you only need to update the corresponding page object, and all of your tests still run.

Such tests provide an excellent safety harness in which changes can be made with the confidence of not breaking other features.  The only problem is that the tests verify the functionality, but not the visuals of the pages.  We were missing the safety harness for CSS changes.

For this purpose I implemented a set of tests that verify the visual appearance of certain core pages.  This prevents someone from accidentally making a CSS change that affects other pages as well.

Since these tests are very brittle by definition, I do not recommend having a lot of them.  You need to identify a few core pages from your application that rarely change their visual appearance, but which still cover the most important parts of your CSS.

For the impatient, the example code is on GitHub.
Continue reading

Posted in CSS, Cucumber, Testing, Watir-Webdriver, Web | Tagged , , | Leave a comment