On walkabout in life and technology

My Next Product

My next product is going to be the best product I ever made. Of this I am certain.

It is going to have an absolutely beautiful design inside and out. The internal architecture is going to be sublime, the code and classes readable and maintainable. The functionality in the first version will hit all the high marks and the UI is going to stand out.

My next product is going to solve a problem that lots of other people face every day. Tens, hundreds, thousands, maybe even millions of people. And it is going to solve that problem in a new, unique and intuitive way. Users of my next product are going to wonder how they got bye without it.

Of course my next product will use the latest and greatest technologies. If that means that some users need to upgrade their platforms to use it, so be it. It is through the use of these technologies that the hottest features of this product will emerge.

My next product is going to test my skills to the limit. Nothing in my 23 years experience as a designer and developer of software will match the challenges of this product. And yet all that experience will help me overcome each hurdle as I craft it, all that experience will enable me to craft it.

My next product is going to be of the highest quality. I will get the core working, proven correct and fast. I will sweat all the details most would miss. It will be tested to death, and then tested some more.


I just have no idea what it this next product will be.

But that is not the point.

Whatever my next product is, be it for myself or for a client, will be the best product I ever made.

As was the one before it.

As will be the one after that.

Never stop learning. Never stop growing. Never stop improving.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

A Coda 2 Use Case

I upgraded to Panic’s Coda 2 when it came out, and never used it. Unless it was to trigger a software update.

That was until last week.

Last week I was working on an odd project to create a set of web pages that would be hosted on a payment processor’s site, but must look and feel like they are running on the actual site. This was for some non-profits to enable them to accept credit-card donations and electronic payment of member fees. Think of it as a customized set of Paypal pages that run on Paypal’s servers, yet are customized to the look and feel of the parent. Without Paypal, of course.

Since our payment processor’s servers could only handle plain-old HTML and CSS files, this looked like a job for my trusty hammer tool, BBEdit. Which is what I started with. BBEdit’s handling of HTML and CSS is excellent. So, my plan was to mock up the pages as plain old HTML and use BBEdit’s live preview window to check that it looked right. I would then copy the final pages to a new BBEdit project where I could then insert the payment processor’s funky markup to make it work. And then iterate. As you do.

But that led to a problem, one of navigation. I needed one BBEdit project window open for the mockup HTML (bottom left), another project window open for the processor’s templates (top left) and one preview window open for each page being mocked up. This is because BBEdit’s preview window is tied to the editor frame that is current when opening it, and it does not switch when you change to another editor frame containing a different file.

I tiled the preview windows to help, but got confused as to which preview window to look at when I made a change to a HTML file. I tried just using one preview window, but that meant I had to close and open a preview each time I switched pages. This process was slowing me down.

I think I wore out my ⌘-~ (switch window) key jumping around. The problem was that my muscle memory kept on making me hit ⌘-⇥ (switch app) when moving between mockup-pages and the templates even though they were in the same application. My brain was seeing these as two separate products.

So, in personal OCD frustration, I decided to use another product for some of the work.

And remembered I had Coda 2 which contains integrated previews. So I opened the mockups folder as a site in Coda 2 and used its split panes feature to add a preview window for each mockup, and then created a tab for each mockup page. And it worked brilliantly.

I could focus on a single mockup page in Coda 2, see its changes live in the split-pane preview window, and jump tabs to work on different mockup pages with their own previews. Which suited my mindset. And then use ⌘-⇥ to jump back to BBEdit to modify the templates, which suited my muscle-memory. And which kept me sane.

I then found out you could even add the CSS file as an additional pane in Coda 2, which made testing and customizing these mockup pages exceptionally easy and pleasurable.

The result is that I got to create and test these mockups quickly and easily in Coda 2, run and post the marked-up templates from BBEdit, iterate as necessary, and got the job done on time without further frustration. I don’t know of any other product that has live integrated pane previews for static HTML sites like Coda 2 does. Thank you, Panic, for this use case.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Octopress Now Has Footnotes

If you update to the latest Octopress and you still use the rdiscount markdown processor, you now get footnotes like this 1. I was previously using a CSS workaround because I prefer the speed of rdiscount for my growing site2 and still wanted footnotes.

To create a footnote, use the standard MultiMarkdown [^1] anchor to create the footnote reference link, and add [^1]: The footnote content. to the bottom of the file3.

I also prefer my footnotes a tad smaller, lighter and closer together, so I added the following CSS to my sass/custom/_styles.css file:

.footnotes {
  font-size: 13px;
  line-height: 16px;
  color: #666;

  p {
    margin-bottom: 6px;

If you prefer popover style footnotes (which I do not), try the Footnotes Popover by Matt Gemmell.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

  1. This is a footnote.

  2. If you had changed Markdown processors, you would have gotten footnotes sooner, but at the cost of significantly slower site generation speed. rdiscount is fast C code, the others are slower interpreted code.

  3. Bold and italics work here too.

Avoiding the Blogger Trap

I totally agree with Marco in Avoiding the blogger trap:

People aren’t so one-sided. Everyone has a life that goes much deeper than the topics on their blogs.


This site represents me, and I’m random and eccentric and interested in a wide variety of subjects.

This site is me, with a hodge podge of posts ranging from opinion pieces, news, geeky ideas, advice, links, jokes, setups and productivity. I write what I find interesting. I experiment. Sometimes I have a point. Sometimes I just want to provoke thought. And allegedly I even occasionally produce a good and useful post.

I don’t make any money from this. I don’t get any new business from this (as yet, still hoping).

I do care about my readers. I like to engage with you, and get very excited every time I get an email from Disqus to say a new comment has been posted. Or a Twitter or App.Net mention. Or a Facebook page like. And the best is when another blogger links to my work.

I like to write. And I intend to continue writing. Maybe I’ll even get better at it.

But most importantly, thank you for reading Hiltmon.com and coming along on the journey. I hope you continue to enjoy it.

“Good Journey.”

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Reading the Archives

Most people when they click on a link to a new blog, read the linked article and move on elsewhere. Google Analytics records this as a bounce - a visitor comes in, reads a single page and leaves.

One of my habits when I come across a new blog is to read the archives. Almost every blogging platform has archives and almost every blogger makes these available.

But why read the archives?

  • My primary reason is to scan the archive headlines to see what topics this blog covers. If the series of topics I see interest me, I’ll add that blog to my RSS feeds.
  • I also want to see how frequently the blog gets updated. If the archives end a year ago, then I can tell that the blog has been abandoned, and will not subscribe.
  • If the post I was linked to did interest me, chances are that this writer has more posts that may interest me. Reading the archives often points me to another set of posts by the same writer, which I invariably Instapaper for tonight’s recreational reading.
  • Even if the post I read was not as interesting as expected, I still scan the archives the first time around, just in case they have other topics that do interest me. I may have followed a link to an article I did not enjoy, but the link usually came from someone I do trust.

I used to just bounce around the internet, reading one piece here, one piece there, but I found that all this bouncing around meant I read a lot of posts that did not interest me. By reading the archives, I found a bunch of sites that I subscribe to, regularly visit and find that my limited reading time is filled with stuff that interests me. It is so much more enjoyable.

I’m not saying you should do this too, but chances are that your analytics has me logged as an arrival by link, followed by a click on the archives. Not a bounce.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Hedge Fund Systems

I have started a new series of articles on Hedge Fund Systems on my company, Noverse LLC blog. I did not post them here (yet) because I am not sure my readers will be interested – and I am using them to promote my skills and services. Let me know in comments you think I should post them here too.

But just in case you are interested in Hedge Fund systems (or my professional skills), the first post is called The Opportunity where I describe the opportunity I got starting in 2004 to design, develop and grow a brand new end-to-end Hedge Fund system for a completely fresh new business. It was the opportunity of a lifetime, and I took it.

In short, I did successfully architect, plan, design and build a feature-complete, integrated platform that ran the business for this Hedge Fund that traded everything and grew to over 900mm under management.

Head on over to The Opportunity to read more. It’s a pretty unbelievable, but true, story.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Fix the Mac Function Keys With Palua

By default, the function keys on Apple keyboards are mapped to the Apple functions on them, like brightness, volume and Mission Control. To access them as F1 - F12 requires you to hit the fn key as well. You could always reverse this in Preferences / Keyboard by checking Use all F1, F2, etc. keys as standard function keys.

But this change is system-wide. What if you want the default Apple behavior most of the time, but Function key behavior in certain applications, for example, in virtual machines?

Palua is a simple menu-bar applet that allows the user to easily switch between Apple and Function key behavior using a keyboard shortcut. Tap the shortcut and the mode changes.

But I don’t use it that way.

Palua’s true power comes when you enable Smart Mode in its Preferences. Here, you can set which keyboard mode to use for which application, and Palua makes the switch for you automatically. Brilliant!

In my case, I have Function mode enabled for VMWare Fusion so hosted VM’s see the F? keys, and for Apple’s Mail.app so that I can use the Function keys directly for Mail Act-On behaviors. At the moment, I use Apple mode for the rest.

Palua is a lovely little utility that does one thing well, and then does it smartly: It automatically switches my keyboard mode based on the currently active app. I have it running all the time and managed by MacBartender.

Available on the App Store for 99c (US) as of writing.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Instantly Grab a High-res Icon for Any Mac App

In Instantly grab a high-res icon for any iOS app, the awesome Brett Terpstra (@ttscoff) offered a script and an app to get the icon from iTunes for any iOS app.

I wanted the same for Mac apps. Turns out, it’s a one word change to Brett’s scripts. Just follow his instructions using the below files, but replace the script name with macicon.rb and the application name with MacIcon.

Usual disclaimer: It works for me, should work for you, and no bunnies were harmed.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Email Before the Open Web

Today, April 30, 2013 is the 20th anniversary of CERN making the WWW free, see Twenty Years of a free, open web. I thought I’d share a story about how it was like before then.

The year was 1988 or 1989, and my Computer Science Professor wanted to send his first email. But first we had to connect our University to the fledgling Internet. Since I ran the UNIX lab, I was tasked to set this up.

I should point out that I was at the University of Cape Town in South Africa at the time, about as far from the physical internet as was possible back then.

This was before ISP’s. We ran our own wires, hubs and routers. And the Computer Science department had it’s own LAN. We also had a bank of modems available for graduate students to dial in from other parts of the campus. We were not even wired to the next building. That was our entire network.

Since we were not interconnected, we had no access to the fledgling DNS network that was growing in the United States. And web servers and web browsers had yet to leave the lab and be opened up. And SMTP, which the planetary email network still depends on, would only work in a fully-connected environment.

The first step was then to find a way to connect to this Internet thingie from the far end of the world.

One of my Professor’s colleagues had written in a letter that his University, The University of Cambridge in the UK, had already been connected, and offered to enable us to route through them. All we needed to do was find a way to connect to them first.

We could have just used one of our modems to call out to Cambridge via the phone network. But international phone calls to host slow modem connections were prohibitively expensive, and the international lines out of Africa were notoriously noisy and unreliable. We needed another way.

Then we found out that the Rhodes University in Grahamstown in the Eastern Cape had been given a huge grant to pay for their connection to Cambridge. So my Professor got on the phone to his counterpart there and they agreed that UCT could route through Rhodes and piggyback on their UK connection.

So I set up a modem, scripts and routes to use UUCP (UNIX to UNIX copy) to connect our primary UNIX computer to the Rhodes one. It would dial up Rhodes every hour and use UUCP to transfer any files and messages between the two computers. I tested it by sending messages and files to my counterpart there. It was then up to the Rhodes computer to process any email messages for us.

And it worked. My Professor sat at my desk, typed in his email and hit send. Then we both stared at the screen. Because nothing happened. I checked the UUCP folders, and the message was there in the queue. Sometime in the next hour, our modem awoke, called Rhodes and UUCP sent the message out. Rhodes forwarded it on sometime later to Cambridge and I have no idea how it went from there onwards.

The next morning we came in to see if there was a reply. But there was none. The UUCP queues and folders were empty. Maybe the message did not get through.

But the day after there was a message. It had come back through this ad-hoc network of computers, dial up connections, hand-coded scripts and home grown routing tables from the other end of the world.

Donald Knuth himself had replied to my Professor’s first emailed question.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Hiltmonism - the Process Is Not the Product

Or how many people get so stuck in the processes of how to do the job, they simply forget to actually do the job. Many a product has failed to materialize because the process to make that product has gotten mired, stuck, distracted or waylaid. It becomes about the people and the politics and the process and no longer about the product.

I use this Hiltmonism to help me to focus on the goal, the reason we are creating the product, and the need to be ruthless in getting it done. We are doing what we do to make a product, to ship it, to delight our customers, and to make money. Not because we love following a process for the purpose of process following.

There are so many examples of when the process takes over, and the product never gets done:

  • Too many head chefs: Projects that are run by committee or need to have “buy-in” from a multitude of people and departments get waylaid by the process to achieve consensus. The number of opinions and egos grows exponentially as the number of owners grow.
  • Too many deliverables: Projects get slowed down in project management reports, process documentation, regular presentations and meetings instead freeing the Project Manager to lead the team and get things done.
  • Bureaucracy: The growth of a bureaucracy as an organization matures is natural, but it leads to discussions on seniority and turf wars instead of laser focus on product.
  • Used to Do X: The continued slavish performance of manual processes that distract and take up time just because “we always did X this way”. Look for processes that may not even be necessary any more as the business changed or another process covers it.
  • Waiting For: Incessant “waiting for” others before one can do their task, and accepting this as an excuse for non-performance and an acceptable business practice. This leads to human deadlock, and the inability to move forward on a product.
  • Minutiae: Getting lost in the minutia of a product, or “seeing a leaf and missing the trees and the forest”. This often manifests in management trying to solve all the problems instead of leaving that up to individual designers or engineers.
  • Doing all the steps: Following strict adherence to a development methodology and process without actually creating the product, because the methodology takes over people’s time. Methodologies are good, but are not the all.
  • Blame: Processes also assign blame, invariably to those who cannot choose the assignment, and folks don’t like to be blamed. So they do all sorts of crazy things to ensure they cannot be blamed or held accountable, spending time and effort covering their asses instead of making the product. And so the product does not get made.
  • Fear: And good old fear of the unknown, so the product never even gets started. You can tell if this is happening when the team tries to solve all the problems that may never occur, just to be 100% sure that the product will work before even launching the project.

How to keep the impact of the process down and maintain focus on the product?

  • Start with a light process. Do only the minimal amount of process to track the product development project and report on it, and focus more on the work of creation and building.
  • Cross bridges if and when you get to them. Good product planning is worthwhile, too much over-planning means that you never stop planning and get started doing.
  • Spike the known issues early and deal with the unknowns when they come up. If there are a few issues that are unresolved at the start, spike them, solve just them. Once they are sufficiently solved to move on, do so, and the rest of the product should be easier.
  • Maintain clear and proper team communication, keeping folks in the loop and not hiding anything. Keep meetings short, make information available to all but do not overload or bore them with details.
  • Delegate decision making responsibility. People who feel they have the responsibility to decide and to do something usually get down and do it. And if they depend on some one else’s work, give them the authority and responsibility to chase their dependencies up as well. That gets rid of the ‘waiting for’ mentality.
  • Step back every once in a while and remember what you are trying to make and why. Look to see if the product is on track from a high level, then get back to the details.
  • Fix instead of Blame. If an issue arises, and it will, all those who need to should get involved and resolve it. If an individual screws up, help them rectify and move on.
  • Iterate a product, don’t try build it all at once. Aim for a minimum viable product, then take the time to flesh it out.
  • Get parts of the product in front of users as it grows. Nothing motivates a team more than joyful acceptance of work done and excited anticipation of deliverables to come.

Many a product has failed to materialize because the process took over. Look for the signs, and remember, the process is not the product. The process is not what you do nor why you do it, the product is.

See also the other Hiltmonisms in the ongoing series.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.