To improve is to change; to be perfect is to change often.

Every once in a while I wonder if my programming tools, languages and platforms need to be changed. Maybe, just maybe, the software mix I use every day needs to be shaken up.

And then my mind starts spinning in circles.

As we all do, I find myself using the same languages and tools over and over again. The same programmer’s editor. The same color scheme and fonts. The same language for scripting. The same platform for web services. The same database. The same server applications.

I use them because they work. Actually, I really use them because I know them so well. They are proven, robust, easy for me to use, easy for me to deploy and easy for me to support. I have gone though the learning curves, fought with the quirks, dealt with the problems and emerged a master of these tools.

Spin.

But I sometimes do wonder: Is it time for a change? Maybe I do need to learn and master a new editor, new scheme, new language, new web platform, new database, new server, new everything.

The only way that we can live, is if we grow. The only way that we can grow is if we change. The only way that we can change is if we learn.

But the question then is which new things to learn and tackle? My programmer’s editor is still modern, fast and reliable. My scripting language is still popular and works great. The web platform I use is robust and has just been updated to a whole new version. And I switched to the database I use these days only three years ago.

Spin.

So maybe I don’t need to change. The languages and tools I use these days are still at or near the top of their game. A glance at the competitive space for each area shows a few promising new technologies, a few stable similarly aged technologies and a bunch of older ones, but none stand out as “the next big thing” yet.

Spin.

But I don’t want to miss or be late for “next big thing” wave. And I fortunately do have the time to learn new stuff. But what to learn? What to change?

And what to change to?

Change Simply for the Sake of Change Is an Abdication of Leadership.

Is change for the sake of changing good or no good? John Luke Jr believes it is not good, a sign of bad leadership. Freek Vermeulen, Phanish Puranam, and Ranjay Gulati in the Harvard Business Review’s Change for Change’s Sake disagree, they view it as a good thing, a sign of good leadership. Both great sources of advice, and yet completely contradictory. Not helping!

Spin.

Maybe, thinking more on it, I need a real arguable reason to change? A stand-out “this is amazing and much better than what I use” reason to change?

Looking back, it was arguable need that caused me to switch from stagnating Perl to growing Ruby years ago. From Apache to Nginx to get more workers and throughput on the same hardware. From ASP.Net to Ruby on Rails for platform independence and development speed. From MySQL to PostgreSQL for better write performance and large data management.

Spin.

But what if I change and land up with the “wrong” platform? Marco Arment wrote about his trusty PHP when looking to make his own change:

The fear of making the “wrong” choice actually makes the familiar, mastered PHP more attractive.

Spin.

Or, maybe it’s not tools, just a timing issue? Is it time for the next change? Even though there seems to be no reason to do so just yet. Do I need to shake things up a bit right now?

I honestly don’t know.

In this specific case, maybe T. Bert Lance is right (even though I do not believe this maxim):

If it ain’t broke, don’t fix it.

Spin.

And so the thinking, spinning and search continues.

Until I find the “right” new things for me, I’ll stick with what I have. But I’ll keep looking, keep checking things out.

My next project will be a trusty Rails project on a trusty Linux platform using my trusty Nginx setup against trusty PostgreSQL. And my next script will still be in trusty Ruby. And I’ll still program it all using trusty TextMate 2 with my familiar CombinedCasts theme.

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

I read a lot of programmer’s editor reviews and see a lot of arguments about which is best. Yet, essentially, they all do the same thing, help you program the way you want to. So here is my review of your favorite programmer’s editor for the Mac.

Choose your Editor: TextMate 2 | Sublime Text 2 | BBEdit | Chocolat | Vim | Emacs

My EDITOR Review

EDITOR is by far the best programmer’s editor ever.

Here’s why.

EDITOR contains all the basic features you would expect from a good programmer’s editor, such as syntax highlighting, code folding, block selection, brace matching, and support for almost every programming language out there. It also supports multiple file encodings, different line ending conventions and, of course, has multi-level undo.

You can save and use your own code snippets within EDITOR. And you can create and run your own macros in EDITOR to increase your efficiency. And one of the best features is that there is an extensive library of bundles on the internet to extend EDITOR’s feature set to do anything imaginable.

EDITOR is blazingly fast to load and use. Much faster than any IDE. Plain text and regex search and replace are but a keystroke away and very quick. And navigating between files in a project or within a file is simple.

The UI is streamlined and does not get in your way. Which makes EDITOR a beautifully simple product. Of course, you can customize the font, spacing and theme to your desire.

Like all such tools though, there is a learning curve. There are only a few keystrokes a beginner needs to learn to get going. But once you have mastered EDITOR extensive keyboard shortcuts, you can do anything in it without reaching for the mouse.

Look, I am most productive in EDITOR. All the commands and features I need are available at a keystroke. And I have the muscle-memory to ensure that I can program at peak efficiency when I use EDITOR.

So I highly recommend you use EDITOR as your primary programmer’s editor. I cannot imagine programming without it.

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

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.

But.

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.

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.

If you update to the latest Octopress and you still use the rdiscount markdown processor, you now get footnotes like this ¹. I was previously using a CSS workaround because I prefer the speed of rdiscount for my growing site² 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 file³.

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:

1
2
3
4
5
6
7
8
9

.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.

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.

and

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.

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.

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.

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.

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.

• Download and save the script as macicon.rb.
• Download the MacIcon Application.

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.