Automatic Teller UI, Can we fix this please?

While sitting in a restaurant last night I was watching the waitress use the touch screen POS system.  I'm always interested in the user interface of systems like this, and though it certainly seemed functional enough, I have to say that the button look and layout was just plain ugly.  I could only think "would it really have been that hard to pretty this thing up a bit."

Earlier in the day I had stopped at my local Chase ATM to grab some cash.  The woman in front of me finished up her transaction and rushed off.  When I approached the screen I was met with the "Do you want another transaction?" screen.  While I was pressing the "No" response, I thought "Thank God I'm not somebody who would extract cash from this person's account".

Which brings me to one of my biggest User Interface pet peeves.  Why does this screen exist?  What programming genius decided that every person who ever uses an ATM should be asked if they would like to perform another transaction?  I have got to believe that literally 99% of all users walk up to an ATM and perform a single transaction.   Whoever designed this decided that it was better for 99 people to have to press NO, taking the chance that they walk away and have money stolen from their account, for the convenience of the 1 person who does multiple transactions.

Some bank web-sites even mention this in their ATM security section.  And I quote:

"Make sure you have finalized the transaction and removed your card before leaving the ATM. Some ATMs ask if you want "another transaction". You must reply "No" to close out your card's transactions. If you do not close your card's transactions and remove your card, the next ATM user can use your card."

The simple answer here is to do away with this screen. Let the 1 out of 100 users who actually wants to do a deposit and get some cash re-swipe his card and reenter his PIN.

Occasionally you still run into ATMs that have the "suck your card inside mechanism."  A number of times I've watched people walk away counting their money leaving their card inside the machine.  I never understood why those machines don't kick out the card and then dispense your money. No one is ever going to leave without their money.  It would've been so simple to just change the order of cash dispersion and card ejection and problem solved.

As a programmer these kinds of things make me nuts.  I'm hoping that the ATM industry did lots of research and there's something I'm missing here. There is some mysterious reason why they chose to program these machines in this fashion.  My guess is it was someone not thinking about it, or someone who did, but thought that fighting to get the change made late in production was too much of a hassle.  No matter what the reason it's not helping out the poor person who doesn't have an honest person behind them when they forget to press No.

Using Webstorm or PHPStorm and Mocha for unit testing in Node.js

I have been working on a node.js project and decided I wanted to get some unit testing going .  I did some research and there are a lot of test frameworks out there for node.  You can use Jasmine, node-unit, Expresso, Mocha or a myriad of other frameworks.  Apparently this is a problem people have decided to solve over and over and over.  After a bit of research I settled on Mocha.  It’s written by the same guy who writes the awesome Express library and is well supported. 

You can write your unit tests in a variety of formats whether you like BDD or TDD and you can write them in either javascript or coffeescript.  Mocha is pretty deep and supports all sorts of input and output formats. There is actually a great tutorial on peepcode called Full Stack Node JS that goes into a lot of stuff on getting started with node and has a lengthy section on testing with Mocha. Spend the $12 right now it’s worth it. 

After you get done watching that you should be able to write some basic unit tests in javascript or coffeescript and run them from the command line using npm test.  I say “should” because like all things “node”, documentation is pretty sparse.  Be prepared to do some googling. 

So now that I was able to write unit tests and run them from the command line I should've been happy as a clam right?  Wrong.  Typically when I’m writing code I like to write a test method and then run it in a debugger.  I did some searching around and couldn't fine a way to do this with Webstorm, my choice of javascript editor.  I like Webstorm because you can debug your javascript from within the IDE and single step through the code. If you need to do PHP stuff you probably want to buy PHPStorm as it has all of the functionality of Webstorm plus the ability to work with PHP.  I bought Webstorm first but 6 months after the fact the people at JetBrains were nice enough to give me a discount when I upgraded to PHPStorm.

When you run the Mocha test framework it runs a node.js program that takes a list of test files on the command line.  I realized that if I could figure out a way to pass the files without having to use the command line I could probably debug my js files that are loaded by Mocha.  My plan was to run the mocha.js file from Webstorm in debug mode and that would then load up my test js files. After spending a few hours digging into the Mocha code, it looked like the plumbing was there for what I needed but it was still going to take some time to figure out exactly what to do.

I don’t know why but for some reason I decided to poke around a bit on TJ Holowaychuk’s blog (the author of Mocha).  I clicked on “About” which took me to the footer of his blog. By coincidence the last blog entry on the page from March 24^th said:

“A new JS API was added, which mocha(1) now utilizes. This higher-level JS API will make it easier for those who want to script the testing process with Mocha. I have yet to document this API but it looks like this:”

There it was right in front of me.  20 lines of code that would help me do exactly what I needed to put together my own “runner” file for doing my unit tests in a project.  Holy stroke of luck! I found the “I have yet to document this API” statement to be quite humorous since you rarely find heavily documented node.js libraries.  Here’s what I’m doing to make my test files Mocha compatible as well as debuggable from within Webstorm.

First add Mocha to your node project by doing the usual "npm install mocha" and make a directory called test.  This is where all your tests will live.  You can make subdirectories for your tests if you’ve got lots of them but make sure everything lives in test.  In test you create a base file called testRunner.js.  This file has the code you need to load your other tests and it is the file you will run in debug mode from within Webstorm.  

Your project should look something like this:

The code for testRunner is as follows

var testFiles=["test/_helper.js","test/tests.js","test/tests.coffee"];


var Mocha = require('mocha');


var mocha = new Mocha;


mocha.reporter('spec').ui('bdd');


for (var i =0;i<testFiles.length;i++){


 mocha.addFile(testFiles[i]);


}

var runner = mocha.run(function(){

                console.log('finished');

});

The array at the top is where you put the names of the files that contain all your tests.  As you can see above I’m going to run 3 test files named _helper.js,tests.js, and tests.coffee.  The _helper.js is stub file and all it contains is the follow line of code:

require('coffee-script');

If you’re not going to write any of your test scripts in coffeescript then you don’t need to include this file.  If you are, then make sure it’s the first file in your list of tests.

The next lines of code load Mocha, create an instance of it, specify that you want to use the behavior driven development style of tests, add the test files, and then run them. When you run this from Webstorm the output from your tests wlll show up in the Webstorm console window and you can single step through the code for debugging. 

I hope this helps some of the other people out there who were trying to figure out how to work with Mocha and Webstorm.

Programming with the IPad.. not so much

Lately I’ve been doing a lot of coding for Wordpress and node.js. So with my dead laptop I wanted to see if I could get any work done on a recent trip with my IPad.

With my laptop I’ve got everything I need for this kind of development. I have Wordpress running under IIS on my laptop and use Chrome with its built in debugger to debug html, css and javascript on the client side. For node.js I again use Chrome for client side debugging and Webstorm for code editing and server side debugging. I can quickly make code changes and see the results both client and server side. This is just not possible on the IPad.

First let’s look at the client side. On the IPad you don’t have the advantage of a nice client side debugger for web pages. You can turn on the Safari debug window in the IPad settings section but all this will show you is when you’ve got a Javascript error. It’s almost useless. I did find a tip for viewing the source of web pages. Basically it saves a short amount of Javascript into a book mark, which you then select when you’re on a web page. It runs the following code:

 var sourceWindow=window.open('about:blank');

 var newDoc=sourceWindow.document; 

 newDoc.open(); 

 newDoc.write('<html><head><title>Source of' +

              document.location.href +

              '</title></head><body></body></html>');

 newDoc.close();

 var pre=newDoc.body.appendChild(newDoc.createElement("pre"));

 pre.appendChild(newDoc.createTextNode(document.documentElement.innerHTML));

The code opens a new blank window. Writes an empty html page with the title “Source of” and the url of the current page. It finishes by appending the html source of the current page into a text element of the new page. Voila! You’ve got source.

Now for the server side. I have yet to find an “app” that lets me run node.js or the Wordpress php software on the IPad. So basically I was stuck using the IPad as a terminal to a server. I needed two things to make this happen. First I needed a server on which to run Wordpress and node.js. Second I needed to be connected to said server anytime I want to do work. The latter was a bit of a pain on this trip as even though the plane said it had wifi, it didn’t, and my AT&T coverage in Georgia pretty much sucked as well as the DSL from Southern Bell. But putting aside the whole connection issue lets look at what it took to actually get up and running from a server standpoint.

There are a lot of hosting options out there these days but I wanted something I could get up and running quickly, inexpensively, and that let me at a command line interface.  The last requirement was so I could install and run any software I wanted for development. The thing that fit the bill was Amazon’s EC2 instance. Amazon has a variety of levels of cloud server that you can spin up for varying prices. The cool thing is that to get people started they allow you to run a micro instance for free for up to a year. This allows you to fire up your own linux server at their expense. You can’t get crazy with it and you surely don’t want to use it for any real production but for my purposes of doing light weight development it would do the trick.

Setting up an ec2 instance is relatively painless. There are a few things you’ll need to know including you need to edit your security settings to open up some ports. They’re all closed off at first and you’re going to need to open them up for node, http, and ssh. If you don't do this it can be pretty frustrating at first trying to figure out why you can't shell in to your instance.

You’re going to need something that allows you to ssh into your ec2 instance and the thing i use is putty for windows. You’ll need to set up putty to use your private key from amazon. Once you’ve done this you can bring up a shell on your ec2 linux instance and install pretty much anything you want. I installed both Wordpress and node.js on mine, opened up the ports I needed and was ready to roll. I also installed mongodb as I needed a database for my node.js development.

There are two apps you’re going to want for working with the code on yourIPad in conjunction with your ec2 instance. These are Textastic a sweet little context sensitive code editor and Prompt by Panic. Prompt is an ssh client for the IPad that works really well. In fact I installed node.js and mongodb from my IPad using Prompt. The important thing to know is that both Textastic and Prompt will need to have key pairs to work with the ec2 instance and you will need Putty to generate those for you. Here’s additional info on hooking up ec2 with Prompt.

Once you've done all this you're ready to make code changes on your ec2 instance from your IPad.

I got a call from Best Buy while I was out of town that my laptop was back from Asus and I literally stopped to pick it up on the way home from the airport. What I found is that while you can do work using the IPad I wouldn’t really consider it an alternative to a laptop for full on development.  I found myself frustrated not being able to do basic editing and debugging tasks without jumping through hoops. It’ll definitely get you out of a pinch if you want to log on a server and do some basic maintenance of code but that’s about it.

Maybe I’m missing something and I’d love to hear from others with suggestions for better methods of development or tools.

As an aside another tool I use alot and works fine from the IPad is jsfiddle.net. This site allows you to edit code snippets of html,css, and javascript online and see the results immediately. You can save the code, iterate on it and share it with others. I highly recommend it.

In conclusion I'd say I actually did a fair amount of work. I’m just not sure I was really productive,  since the majority of the work I did was just setting up my IPad to prove the concept that I could do work with it.

Facebook making it interesting

I saw this letter Paul Graham put together for the Y-Combinator folks yesterday and I thought it was interesting.  When I was down at Tech Stars in April everyone was absolutely giddy about Facebook's purchase of Instagram. It didn't matter whether it was an organizer, participant, or investor they were all simply besides themselves with $$$ in their eyes over that acquisition.  I remember thinking "oh geez valuations of start-ups are going to be over the top now."

It's still too early to see what effect the Facebook IPO will really have but the one line I agree with 100 percent is this:

 "I often tell startups after raising money that they should act as if it's the last they're ever going to get. "

It reminds me of a conversation I had one time at NAMM with an unnamed band member from what you'd call a One Hit Wonder Band of the 80's.  He told me that when they had their first (and only) hit that they blew all the money from it as they figured they'd just write another hit.  After all, they had it figured out now and it was easy.  Needless to say that didn't happen.

Unfortunately I've heard this same kind of bravado now from a number of young entrepreneurs.  I often say "hey I could be wrong here, but..." and then try to impress on them how hard it can be to raise money.  The problem is when the first round is easy it's often hard to convince them that the second might be harder.

I really hope they are able to keep their visions going if they need more capital. Even if they can't I guess they can always go back to working a day job just like the one hit wonder bands ended up touring Brazil for years to come.