Positioning, by Al Ries and Jack Trout, has long been on my to read list, and I wish I had read it sooner.

The core message of how to position a product is becoming more relevant as the marketplace continues to crowd.

In our overcommunicated society, the name of the game today is positioning. And only the better players are going to survive.

The book draws on a wide range of examples of different products, where a product could be a type of beer, the Catholic Church or your own career.

The key message is that your products position is determined by how it fits into the consumer’s mind. All the things that matter to you, to your company, are irrelevant if you can’t create a distinct position to separate you from everything else.

Experience has shown that a positioning exercise is a search for the obvious. Those are the easiest concepts to communicate because they make the most sense to the recipient of a message.

The authors are quite scathing about “me too” products that attempt to beat out a competitor by going head-to-head. Many examples are provided within the book.

The suicidal bent of companies that go head-on against established competition is hard to understand.

To repeat, the first rule of positioning is: To win the battle for the mind, you can’t compete head-on against a company that has a strong, established position. You can go around, under or over, but never head to head.

The leader owns the high ground. The No. 1 position in the prospect’s mind. The top rung of the product ladder.

The book covers a range of detail levels, and dips into more detail on key areas such as product naming:

As a guide, the five most common initial letters are S, C, P, A, and T. The five least common are X, Z, Y, Q, and K. One out of eight English words starts with an S. One out of 3000 starts with an X.

The authors are often quite blunt as to how they see things. This is a refreshing change from most business books:

Creative people often resist positioning thinking because they believe it restricts their creativity. And you know what? It does. Positioning thinking does restrict creativity.

I gained a lot of insight into how products have succeeded, or not, by reading this book. The examples are clear and will easily map to situations you are experiencing.

I recommend Positioning for anyone involved in creating something new. This is a book that I will re-read.

After over 12 years of using Vi(m), and a brief fling with TextMate, I started using Emacs as my primary editor.

Emacs

The switch has been very positive. The learning curve has been relatively steep, as my expectations from a text editor are quite high.

Emacs strength (and weakness) is that it is incredibly extensible. Where I’m finding Emacs a win over Vim is that I don’t have to leave Emacs to get things done. With Vim, I tend to use more of a mix of terminal windows and the editor.

I began by using the starter kit to get going with Emacs configuration. This made it quicker to get moving, but added a lot of things I ended up not needing. After getting more comfortable with elisp, I started from scratch and rebuilt my emacs.d folder.

To jump in quickly, I also purchased the tutorial video from Peepcode. This certainly helped as emacs is a mental shift coming from Vim.

The big benefit I have found with Emacs is the extension packages. These can be installed from the ELPA repository, and include a range of different modes.

Some of my favourite modes include:

• paredit - essential for any lisp, it ensures your brackets match.
• deft - simplified note taking. (I it sync via Dropbox)
• magit - comprehensive Git workflow within Emacs
• markdown-mode - my current default for writing notes, although I’m leaning towards org-mode now.
• org-mode - highly capable note taking mode, with export options to everything. You can use it to write a book, create slides, or manage your todo list.

On the Mac, I’ve been using Aquamacs for most of my text editing, and used macports to install the command line client.

I have yet to try Emacs on Windows, as I haven’t been using Windows much at all. There is a release available here.

After cleaning up my .emacs.d configuration, I’ve now started using Emacs on Linux servers I use regularly. For temporary servers, I’ll fallback to Vim as Emacs is often not installed.

If you want to improve your emacs skills follow @emacs_knight.

Vim

To get started with Vim, it is worth reading The Vim Learning Curve is a Myth.

Over the years, the popular mythology around vim has become that it’s insanely difficult to learn; a task to be attempted by only those with the thickest of neck-beards. I’ve heard dozens of times from folks who are convinced it will take them months to reach proficiency.

These beliefs are false.

My feeling is that Vim is unrivalled for the simple task of text editing. Even after a day or two of learning, you will be faster.

Where things get a bit more complicated is when you start to realise that text editing isn’t the whole story for a text editor.

Platform support is superb. The first thing I do to a Windows machine is install Vim. It is rare for an application with a Unix heritage to be so comfortable on Windows.

Historically, I hadn’t been a fan of the graphical version of MacVim. This is something that is much better in recent releases. Load times are much improved.

Integration into external tools is where I feel Vim is lacking a bit. With the number of developers migrating from TextMate to Vim, this gap is being rapidly addressed. However, Vim isn’t as extensible as some other editors.

I really noticed this when trying out Clojure programming. If you are dealing with a REPL based environment, Vim has a way to go.

Closing Thoughts

If you aren’t using either of them, it’s not too late to start. You can’t make a bad choice.

If you are already using either Emacs or Vim, enjoy!

Both are great editors that allow you to be incredibly productive at working with text. Try learning a new feature each week. You use your text editor so often that a small improvement is a major payoff.

Mongo has a database size limit in 32 bit mode, so I want to purge out items that are less than a certain date in the past. I decided that it would be easy to write a simple shell script to run the query.

The tricky part was calculating dates in shell. This is what I ended up with:

#!/bin/sh

MONTHS_AGO=3
DATE_AGO_EPOCH=$((`date +%s` - $MONTHS_AGO * 31 * 24 * 3600))
OSTYPE=`uname`
FORMAT='+%Y-%m-%d'

if [ "Linux" = $OSTYPE ] ; then
  DATE_AGO_ISO=`date -d "1970-01-01 00:00 UTC + $DATE_AGO_EPOCH seconds" $FORMAT`
else
  DATE_AGO_ISO=`date -r $DATE_AGO_EPOCH $FORMAT`
fi

DB_CMD="db.items.find( { publish_date : { $lt : \"$DATE_AGO_ISO\" } } ).count()"
# DB_CMD="db.items.remove( { publish_date : { $lt : \"$DATE_AGO_ISO\" } } )"

echo $DB_CMD | mongo pz

This now provides a simple way of purging out old items that can be called from cron.

I am very excited about the potential unleashed by Storm.

Previously at BackType, Nathan Marz has now built Storm into Twitter and then open sourced the platform.

Storm opens up a lot of possibilities, by bringing real-time distributed processing together in an elegant way. And it is built in Clojure!

Some useful links:

• Rationale
• Slides - detailed presentation on Storm by Nathan
• Starter project - a few basic demo use cases
• Mailing List
• Taking the Emmys by Storm - an hour long video of how to use Storm to aggregate data from Twitter in realtime to spot trends.

While playing around I wanted to try from Clojure (most examples are in Java). There is a great DSL for Clojure that makes using Storm super easy. I forked the storm-starter project to add examples based on a Gist from Nathan.

While porting a simple example of generating a Hadoop file for Mahout, I came across a number of edge cases of the Clojure Java interop.

Nested Classes

Java allows for classes to be nested. However, Clojure doesn’t provide an obvious way of referencing them.

For example, Hadoop’s SequenceFile includes SequenceFile.Writer and SequenceFile.Reader.

To access these in Clojure, the period is replaced by a dollar sign.

For example:

(ns example
  (:import [org.apache.hadoop.io SequenceFile$Writer]))

...
  writer (SequenceFile$Writer. fs conf path
                               (class Text)
                               (class VectorWritable))
...

This thread on the mailing list has some more details.

Generics

From the Java code, generics add annotations about the type. However, at the JVM level, generics are nowhere to be seen. It turns out that generics are a compiler level feature only.

What this means for Clojure is that you can safely ignore them, provided that you honour the types that are included in the generic.

Thus the following Java:

List<NamedVector> apples = new ArrayList<NamedVector>();

Can be written in Clojure:

(def apples (ArrayList.))

The responsibility is then on the programmer to ensure the types put into the collection.

This thread on the mailing list has some background.

Primitive Arrays

I started out looking at how to construct a double[] to pass to DenseVector.

Turns out that there are a number of things to be wary of when constructing primitive arrays. Bradford Cross has written this up with examples in a blog post.

The considerations I took away were:

1. double-array function to migrate a Clojure data structure
2. make-array with Double/TYPE to pre-allocate the array
3. Type hints should be considered
4. Odd things are likely to be happening with type coercion, so check run time performance.