Getting moving with Heroku on Windows

I've been trying to get going with a new Rails app over the past couple of weeks or so, and I'd decided that I wanted to doing a few things differently from my other Rails app. One of them was to use Heroku, because I've read so many raves about it, and about how it 'just works'.

Those 'ravers' must work on *nix machines though, as there are a few hoops to jump through to get Heroku successfully talking to Windows XP.

For starters, I will assume you have the following already installed and running on your Windows box:

1. Heroku itself
2. Git and Putty

From the above Git/Putty post, it's not strictly necessary to be connected to Github, to work with Heroku, as Heroku hosts your repository for you as well as your application. However, the concepts for connecting to Heroku through SSH are similar.

Step 1: Store your SSH key
You can generate a new one, or you can use the same one you have generated for Git, but Heroku requires some fairly specific things for this to work. The following assumes you are using PuttyGen to generate your SSH key:

• Your public key must be stored in a '.ssh' directory in your Windows 'home' directory (ie. something like 'C:/Documents and Settings/Username/.ssh/id_rsa.pub'
• Note: you can't create the '.ssh' directory using Windows Explorer (explorer won't let you create any directory that begins with a '.'). You must use Git Bash for that.
  
• You must cut and paste the 'Public key for pasting into OpenSSH authorized_keys file' into your id_rsa.pub file (replacing the content of the file that you created using 'Save public key'). Otherwise, you will get persistent messages when you try to interact with Heroku, to the effect that you have 'Contents Invalid public key'
  

Step 2: Get Windows to recognise Heroku as a host
As you may have read for Github in the post referenced above, for each server that you wish to connect your Windows box to, using SSH, you need to have a host key defined in your Windows Registry. This is true for Heroku. If you don't have the appropriate host key, you will see a message something like the following:
"The server's host key is not cached in the registry. You have no guarantee that the server is the computer you think it is."

To establish Heroku's host key in your Windows Registry:

1. Open putty
2. Type 'heroku.com' in the hostname box and click 'Open'
3. When you see the prompt, 'The server's host key is not cached in the registry...', click 'Yes'
4. You do not need to log on, and can close putty at this point
   

After you have followed these two steps, you should have a working connection between your Windows box and Heroku. You do need to remember though, to be running 'pageant' whenever you attempt to connect to Heroku (the same is true of Github).

When you open pageant, click 'Add Key', and select the private key of the key you have stored in your home '.ssh' directory.

After that, you should find that it does 'just work'!

Why should mainframe development be so archaic

It seems that mainframe ("Dinosaur") development practices are so far removed from "more modern" language and technology development that they are practically different careers.

Or at least, I used to think so...

A couple of years ago, my employer ran a "Developers' Conference", as a place where the company's developers could gather to listen to keynotes by our technology leaders, on topics ranging from specific overviews of particular areas of our technology to general visions of the future of technology in our company and industry. It didn't take long to figure out that the conference was aimed squarely at the Java community within my company, but the invitation was open to all, and here I was, with a handful of other mainframe COBOL developers who were motivated enough to attend.

The conference was a real eye-opener, and not just for introducing me to terms like 'wiki', 'mash-up' and 'Flikr' (I'd been seriously sheltered in my career to that point). It made me realise I'd been in a career rut, and led me to become dissatisfied with the toolset I'd become comfortable with over the past 15 years of mainframe development.

It started with one of the keynotes that attracted my eye. Titled, 'The Future of Development at (my employer)', the content didn't really focus much on the future, but more on the problems with the way that we currently do development (and this was talking about the Java side of things, not the mainframe side of things - though just as relevant to mainframe). One almost throw-away line from the keynote went something like "By the way, if you haven't read 'The Pragmatic Programmer', you should!". That stuck with me, and not long after, I found myself thinking about what to read next, and came back to this book. I found a copy in a local bookstore and started reading. Wow!

Many of the concepts in 'The Pragmatic Programmer' are not aimed at development on mainframes with limited command-line capabilities, and in static languages like COBOL. However, a surprising amount of the ideas in the book relate directly to ANY kind of development - not just the 'popular' or 'modern' languages. Many of them don't even relate directly to development - more to improving yourself as a developer - the book is afterall, subtitled 'From Journeyman to Master'.

A surprising thing started to happen as I read through this book. I started to think about each of the concepts presented, and in many cases, my mindset shifted from "this doesn't apply to me", to "well, why not?". Just because, for example, there is no framework for automated Unit Testing on the mainframe, why should that mean that I as a developer cannot use at least some of the techniques of Test Driven Design? For that matter, why couldn't I as a developer start to develop a mainframe framework for automated Unit Testing?

The bottom line is that just because the 'mainstream' developer community doesn't seem to think much of mainframe / COBOL development, and though we don't have a particularly sophisticated toolset readily available for implementing many of the modern (or "Agile") development techniques, this doesn't mean that we can't all at least aspire to work in better ways.

Within the constraints of our toolset, we can still work smart. We have the same brain capacity as the non-mainframe community. We can apply 'modern lessons', 'modern techniques', 'modern design patterns' to our everyday work. Admittedly you can only take this so far - some Object Oriented design patterns just can't stretch to a static language like COBOL or Assembler. But, plenty of concepts DO work. 'Don't Repeat Yourself...', 'Don't leave broken windows...', 'Automate what you can...' - these things are universal and just as relevant to mainframe development as to web development or PC development.

We also can't afford to neglect our own intellectual property, just because the systems we maintain are 15 years old and the technologies we use to maintain them haven't shifted in that time. Keeping up with the latest ideas and reading technology magazines and blogs is valuable, regardless of what technology we work in.

Possibly the hardest part of the problem though, is breaking out of our 'Dinosaur' mindset in the first place.