Author Archive

There are three things that are crucial when starting a company: selling, selling and selling. OK, actually, there are four things. Cash flow is king, too. As I write this the Dow is down nearly 3000 points over a 4-week period, the commercial paper and interbank loan market have completely dried up, and it’s getting harder and harder to borrow money. The bottom line is businesses need to do everything they can to make the money they do have go further.

When we started out, the one thing we focused on was our “time to expiry” — the amount of time that we had until we would be insolvent without winning any more business. It’s simple: add the money coming into the company (sales), and subtract the money going out (salaries, office space, etc.) and plot that over time. At some point in the future, the graph will drop below zero. If you reach that point, without any more sales, it means you’re out of cash.

Focus religiously on this event horizon. There are two ways to push back the zero date. Sell more stuff, and reduce your costs. This article is about our experience with the latter. I could start talking about the former, but you’d have to pay me.

Obelix!

When we finally grew large enough to be able to afford our own office, we spent a while looking for a decent, cheap, expandable phone system. We didn’t, and still don’t, trust VoIP as a 99.9% reliable service, so we were set on some sort of switch connected to a few ISDN lines.

I couldn’t believe the quotes we were getting from suppliers. Many, many thousands of pounds for a simple switch that connects phones to ISDN lines. You want to add another 16 phones? That’ll be another £3000! You want to store the call data in a database? £2000, please. Oh, and the phones cost a fortune, too.

Then I heard about Asterisk. Asterisk is a Linux-based open source software stack that can drive any number of ISDN cards that are available. OK, the cards are about £500, but we had a spare PC lying around and Linux is pretty cheap! Some hacking around later (OK, OK, about two days‘ of hacking!) and we had a working setup using VoIP internally, which is then bridged to ISDN lines when calls go into or out of the office.

The phones we use are £70 a throw, so in total we managed to save about £3500 right off the bat. Then there’s the saving in cabling: we only need one network in our office. Adding phones just costs us the price of a new phone, not £3000 for an add-on to a proprietary system. Finally, we have a system that we actually understand, so we never need to call an engineer to change a dial plan or add some phones; we just SSH into the asterisk box and fire up vi. We have voicemail as email attachments, conference calling, “intelligent” call forwarding, group pickup, call logging, etc. It’s all there — Asterisk is just great.

Office space

OK, you want to sign a 2-year office lease to get the best possible space, but you know you won’t be able to either fill the office or afford the rent for the first 12 months. The solution? Sub-let.

Stick an ad up on Craigslist (or Gumtree if you’re in London, like us) for the desk space, charge by the month and wait about 4 weeks. By then your office will be full and you will be getting extra money in to cover the rent.

Just make sure you check with the landlord of the property that you are legally allowed to sub-let or even better have it written into the contract. We actually had a better response for desks than we initially imagined, meaning we got to pick and choose our desk neighbors. The selection criteria boiled down to two things: do we get on, and can we potentially work together on projects? It’s very useful to have a top-notch bunch of Flash developers downstairs that we could use to complement our current skill set.

Decamp

Basecamp is very successful and rightly so, it’s an extremely good project management tool. However, you can get a very, very similar application at a £0/month price plan. Project Pier is fork of another project that was open source but has since gone the paid-for route. The project isn’t very actively developed, but it’s more than good enough to satisfy a large proportion of what you get with Basecamp.

Manage your own email

If you have someone in the company who understands what postfix, snmpd, smtp, httpd and sshd are, and you’re already paying for server hardware infrastructure, don’t bother paying someone else to do your email hosting. Run it internally. Get your Linux geek to do all that server management stuff. Consider whether you really need push email. Surely getting your email every 15 minutes is good enough, right? If so, dump the Blackberry/ActiveSync phone with the pricey license fees, and go IMAP. It’s open and it’s free.

Who said spam?

Like I just mentioned, we run our own SMTP server. Slowly, predictably, our email addresses started attracting spam. There are a load of companies out there that will filter your email for a pretty penny, but don’t call them. Just download ASSP, spend a day playing with it and away you go. We’ve gone from more than 200 spam messages per mailbox per day to about one per day, with no false positives.

Free banking

OK, I admit it, right now I hate my bank. Their service is far from ideal, but they don’t charge us a penny for running the account, paying checks in, or calling them. Anything that can reduce the pressure on your cash-flow is a good thing, and free banking, warts and all, is a good choice for a start-up. It pays to shop around and see which banks offer free business banking. Also watch out for teaser offers: some banks offer free banking for a year, but you have to pay for things (like giving them money! Crazy, huh?) after that. You plan to stay in business for more than one year, right?

VirtualBox

We write web applications, which means we spend a lot of time testing web applications. Testing across browsers and O/S versions used to be very painful, but with the advent of virtualisation software it means you can test across systems without getting out of your seat. We used to use VMWare, which did its job, but the open source VirtualBox is just as good, and has a much better price point: free!

Server said what?

We run a number of servers for our clients, and it’s important to be able to keep tabs on them. Their bandwidth usage, memory usage, what they’re having for dinner, that sort of thing. Cacti is an SNMP-based tool that just plain rocks. It runs as a web application, monitoring other servers in the background. It records all their data points, and allows you to view all sorts of metrics through the web front end. SNMP clients are free under Linux, but you can pay big bucks for commercial management tools. Cacti does the job for general web serving just fine.

Of course, every now and then things do go wrong. When they do it’s important that you know about it before your client does. Nagios does the job of server monitoring really well. (Just remember to use different infrastructure for your Nagios server, otherwise you’ll have a hard time being alerted of your network going down if Nagios is on the very same network!)

Colleague said what?

Don’t waste money on something like Campfire; just compile an IRC daemon and run that. Old Skool! You can’t easily post and share images and documents like you can on Campfire, but you can get a long way with ASCII art…OK, so maybe this one is a bit of a stretch.

He’s no longer the Richest Man in the World

Seriously, don’t bother with Microsoft Office, the beta releases of OpenOffice 3 are top notch. It handles the new Office Open XML standard perfectly well, and can export to PDF in a single click. The OSX version is really, really good too. In fact, it’s helping me write this!

For all you cloud-lovers, there’s a number of collaborative solutions like Google Docs, Zoho Writer and a cool Flash-based application, Acrobat Buzzword.

Squash those bugs

Bugzilla always seemed like overkill for projects with less than 10000 issues. We ran the company for about four years with Mantis, which did the job admirably. It’s free, simple to use, easy to set-up and does the job just fine.

Being totally honest, though, a while ago we splashed out on JIRA. Although it goes against the grain of this article, I believe that you need to spend your hard-earned cash when it really is necessary (more on this a bit later). Our clients can communicate with JIRA via email, the permissioning is much more powerful and the application itself is far more extensible. I think JIRA is worth every penny; it’s brilliant.

Patch that code

In terms of managing your code, Subversion and Git both solve similar problems in different ways, but they are both free and just as good as any paid-for product.

Spend spend spend!

While it’s a good idea to cut costs where you can, there are a few things we think you should spend that little bit extra on. Things that make the work environment more enjoyable for employees, increase productivity and reduce overall business risk are what I feel it’s worth spending some extra money on, like:

• Chairs
• Physical office security
• Off site backup
• Coffee (oh, and get a stainless steel cafetiere. Glass ones have a mean lifetime of around 10 weeks!)
• Monitors
• The odd night out on the town; a great way to team-build. Recommended venues: Ice Skating by the Tower of London or Urban Golf
• A Wii. A great way to de-stress and an excellent excuse for a 10 minute break. Recommended vices: Wii Tennis, Mario Kart and Super Smash Bros.

What’s worked for you?

In this article I’ve beeen through a few of the ways that we’ve reduced our business costs, primarily by using free software, but if you have any tips (either ways you’ve reduced your business costs or things that it’s worth splashing the cash on), please share them in the comments.

If you liked this article, check out Ben’s other Vitamin article: Easy Automated Web Application Testing with Hudson and Selenium

Let’s face it, developing web applications is, in some ways, getting more and more complex as time goes on. Sure, there are frameworks like Django, Rails or Seam to help you get sites built in record time with minimal resources, but at the same time applications are becoming more complex and more demanding. Being able to support Ajax-heavy applications through multiple browsers across multiple operating systems is now a primary requirement, as is being able to scale to thousands (or, if you’re lucky, millions) of users.

The frameworks help primarily with the initial effort of building the functionality of your site, but they are less useful addressing the longer-term problems associated with application development. The “old school” maxim that you spend 90% of your time supporting (as opposed to writing) your application is still fairly accurate. This article looks at one way of cracking the problem of regression testing (retesting previously working parts of an application following a new build) a modern web application, using two superb open source projects: Hudson and Selenium.

What will you get out of this article? Our set-up achieves the following:

• It checks our Subversion repository every hour to see if anyone has committed any changes.
• If they have, it updates the project from Subversion and builds it.
• It then creates a clean version of our application database, loads in reference data and deploys the application on our app server.
• A job is triggered that runs through a series of tests in a remotely-controlled web browser on the fresh application.
• Anything that deviates from the accepted norm is logged and screenshots of the web browser are taken.
• Screenshots of the browser are also taken for key pages of the site for later checking by a human.
• If any of the tests fail, the developers responsible for the changes are notified by email of the problems.
• Our issue tracker is updated with any issues that were fixed in the build.

Here’s what the architecture of the setup looks like:

The best thing about our set up is that it doesn’t rely on a single shell script. Really! For those applications that do need some form of scripting, Hudson offers relevant hooks in the build process to trigger these easily.

If You Build It, They Will Come

The first piece of the puzzle is Hudson. Hudson is a build server designed for Java applications, but it will work quite happily (albeit with slightly reduced functionality) with any language you choose to throw at it. Hudson is responsible for checking if your application needs building, building it, triggering any testing that you have defined and, finally, reporting on the state of the build.

The first step is to download Hudson and install it. To create a new project you need to provide some details:

1. The source code repository that you are using. SVN or CVS support are provided out of the box.
2. Under “build triggers” choose Poll SCM and in the schedule enter something like “5 * * * *“. This is a CRON-like notation that basically means “every five minutes past the hour”: Hudson will check your repository every hour. If it has changed, a build will be triggered.
3. Select a build step. If you are running a Java project using either Ant or Maven, you’re in luck, because it’s as simple as adding the details of the appropriate script and target here. If not, choose Execute Shell; you can enter shell commands here to carry out your build and deployment tasks.
4. Add an Email Notification post-build action to enable Hudson to notify the developers who were responsible for breaking the build! If you’re running a Java app, you can also include all your JUnit test results in the application reports.

The most important aspect of the build step is to get the source code updated and deployed on your test web server. If you aren’t writing a Java application, you can still achieve this relatively easily using the Execute Shell build process. At its simplest, it can just copy the files from the Hudson server to the development server web root.

If the build fails, you will receive an email stating what went wrong, with a link to the Hudson page giving further details. If Hudson can figure out who committed the offending code, it will even email them too. If the tests failed, you can get good insight into where in your code the failure occurred, helping you to diagnose exactly what went wrong.

Browser Testing Is Boring. Get Someone Else To Do It For You…

The second piece of the puzzle is Selenium. Selenium is a bunch of JavaScript craziness (well, they call it a “Web application testing system”) that is a real lifesaver. Basically, you give it a bunch of web tests, each consisting of a series of actions to perform on the site, and it replays the commands in a browser window automatically.

We’re going to use Selenium Remote Control, which allows you to set a machine aside as the browser testing box, and control it remotely from your Hudson build. As if by magic, the browser will start up and run through your recorded tests. Hudson will alert you if anything out of the ordinary appears.

Download Selenium Remote Control, and install it. Once you have Selenium Remote Control up and running, you will want to install the Selenium IDE, a plug-in for Firefox. The IDE allows you to go onto your site, hit the record button, and then browse around as if you were using the site normally. It records any user actions you make, like clicking on a button, or entering data into a form field. You can then save these base tests to a file ready for regression testing.

You can drive Selenium Remote Control with a number of different clients: Java, .NET, Perl, PHP, Python, Ruby and JavaScript are all supported. Export your Selenium IDE tests into the chosen language, and then hook it up with Hudson as part of the build process. Driving the Selenium server using the language of your choice means that you have a large amount of control over your testing. You can take the base tests you created using the IDE and then augment them with conditional logic, loops, whatever you like . As an example, the following method tests one part of our application (in Java):

    public void testSendMessage() throws Exception {
        try {
            selenium.windowMaximize();
            selenium.open("/mtb.profilepage.action");
            selenium.type("text1", "testuser1@mailinator.com");
            selenium.type("name", "123456");
            selenium.click("btnLogin");
            // Add the second user as a contact
            selenium.open("test.user.contact.add.action?&profileId=2");
            selenium.open("test.user.contact.approve.action?targetProfileId=1&profileId=2");
            selenium.open("/mtb.profilepage.action");
            selenium.click("navigation.inbox");
            for (int second = 0;; second++) {
                if (second >= 60) fail("timeout");
                try { if (selenium.isElementPresent("xpath=id('inboxToolbar')/li[1]/a")) break; } catch (Exception e) {}
                Thread.sleep(1000);
            }
            assertTrue(selenium.isTextPresent("Ben Rometsch"));
            selenium.select("recipientSelect", "label=Ben2 Rometsch2");
            selenium.type("subject", "This is the subject");
            selenium.type("message_body", "This is the body");
            selenium.click("link=Send");
            selenium.click("link=Sent");
            assertTrue(selenium.isTextPresent("This is the subject"));
            selenium.click("link=Sent");
            assertTrue(selenium.isTextPresent("Ben2 Rometsch2"));
            selenium.click("xpath=id('header')/ul/li[2]/a"); // Log out
        } catch (Exception e) {
            super.takeScreenshot("error-" + this.getName());
        }

        saveDraftThenSend();
        checkMessageReceivedOK();
        deleteDraftMessage();
        deleteSentMessage();
    }
    

You will also be able to replay your tests with the language IDE you use. If you make use of a debugger, you can also step through your tests to isolate any problems that might occur.

Selenium has a number of ways of testing that the application is working as intended:

• Any HTTP errors (like 404 or 500) will be classified as a failure.
• Assertions against text can be made. So, for example, if you are expecting a certain string to be present, you can make a simple assertion stating that it should be.
• Assertions against the DOM structure of your page can also be made using XPath (a killer Firefox addon that can really help with this is XPath Checker)

Do you support IE for Mac?

Regression testing application functionality is one of the main benefits of Selenium and Hudson, but with some tweaking you can also make cross-browser testing far less painful than it normally is. You will still need to have a real live human being checking things over, but the process becomes much quicker.

Selenium Remote Control has a method available to save a screenshot of the current browser to the file system of the local machine. We can build on this functionality to have screenshots of the site generated for key pages across multiple browsers, all running from the same host client machine.

The final test we run simply saves key screenshots of the site across four different Selenium browser sessions (Firefox, Internet Explorer, Safari and Opera). The screenshots are stored onto a shared drive on our development server. The Hudson build number is passed into the Selenium session, and we make use of this to organize all the screenshots. This way we can wait for a Hudson build to complete successfully, then sanity-check the screenshots taken in multiple browsers to ensure that nothing has been broken.

Talking to JIRA

We use JIRA to do all our bug tracking. It’s really superb. If you’re working on an open source project, it’s also free. Hudson has a plug-in architecture that means it can be easily extended. One of the available plug-ins connects the two applications.

Once the connection between a Hudson project and a JIRA project is made, the typical bug tracking process becomes:

1. A user finds a bug and raises an issue in JIRA.
2. A developer fixes the bug and commits the code changes to SVN. Crucially, they include the unique JIRA bug ID (which might be something like “PIPELINE-157″) as part of the SVN commit message. So the commit message might read: “Fixed PIPELINE-157. Re-factored the email daemon to better handle multi-part messages”.
3. Hudson recognizes that the new changes have been committed, and performs a build. It also notices the JIRA bug ID in the SVN message and includes a link to the JIRA issue as part of the build change-set.
4. If the build completes successfully, and there are no failed tests, Hudson posts a comment to the JIRA issue concerned, with a link back to the Hudson build within which it is fixed.
5. The user that raised the issue receives an email of the message added by Hudson and checks that the new build has fixed the problem. They then close the bug.

Note how much of this process is automated.

When performing Staging or Production builds, the JIRA integration can help generate a list of fixed issues since the last build. 

Below is a change-list from Hudson. The links to things like MTB-211 point back to the JIRA issue.

And here is the comment from the JIRA issue itself.

No Silver Bullet

Writing good Selenium tests is tricky. The core assertion you can make are that either text is present, or that it is not. Although that can get you a very long way, it is no silver bullet – your application can break in many ways!

Earlier versions of Selenium also had serious problems with the timing associated with browser-based testing, and required the tester to place a lot of “wait” commands within their tests to ensure that page elements had loaded completely before any assertions could be made. A lot of progress has been made in this area, but the problem rears its ugly head when testing applications that make lots of dynamic page calls. Writing tests that are not horribly brittle when working on an Ajax-heavy site can be testing (pun intended!). Sometimes, unfortunately, there is no replacement for a human pair of eyes.

All that being said, our time-sheet and invoicing application, Pipeline, has benefited greatly from the set-up described above. Getting the environment and associated tests set up took about five days’ worth of work, but the feeling you get when you trap your first bug, automatically, is really great. More importantly, you can make changes to your code safe in the knowledge that the computers whirring away in the background will be checking your work as you go.