Rob Zolkos

Here are the steps to make a Mountain Lion USB boot disk (USB).

You will require a 8Gb USB Disk. These are cheap nowadays :)

Step 1. Go to the Mac App Store and download a copy of Mountain Lion. If you have already downloaded it, you can redownload it without being charged again.

Step 2. Download a copy of Lion DiskMaker from liondiskmaker.com

Step 3. Run Lion DiskMaker. It will ask you what version of OS X you wish to install. Select Mountain Lion (10.8). It will automatically detect the Mountain Lion install app that was downloaded from the App Store in step 1. Click ‘Use this copy’. If it doesn’t find the copy downloaded in step 1, it will ask you for the location of the file.

Step 4. It will then ask you to either burn a DVD or Create a boot disk. Choose ‘Create a boot disk’.

Step 5. It will then ask what kind of disk to use. Select ‘An 8Gb USB thumb drive’.

Step 6. It will present a list of plugged in USB drives. Make sure you select the correct one and press ‘Choose this disk’. A warning letting you know you are about to erase the selected thumb drive.

A progress bar will then appear and Lion DiskMaker will proceed to transfer the required installation files to the USB Thumb Drive. After about 10 minutes, a dialog box will appear proclaiming the process was successful. Select ‘Quit’ to finish the process. Don’t forget to Eject your thumb drive as it will be mounted.

I used to install all my Rails applications on a VPS that I would configure myself. Install the OS, all required development libraries, Ruby etc. My database of choice would be MySQL. Its what I’ve used for years and I know it well. However, I’ve grown fond of the ease of development and deployment for a platform such as Heroku. Migrating existing apps from a VPS to Heroku can be quite a challenge, especially since Heroku uses Postgres by default and has a read-only file system. Here I’ll go through the steps to migrate a MySQL database from a VPS to a Postgres DB on Heroku.

Prerequisites

You will require a MySQL and Postgres server setup on your local machine, and access to a remote server that can temporarily host a file (eg dropbox or Amazon S3 etc)

Substitute ‘databasename’ with the name of your actual database where appropriate.

The Steps

1. SSH into your remote server currently hosting your database.

2. Dump the MySQL database

   mysqldump -u username -p databasename > database.sql

3. Copy the database dump to your local machine

4. Create a Postgres database on your local machine

   psql -c 'create database databasename'

5. Install the taps gem

   Taps is a rubygem that creates a temporary server that is able to migrate databases from one format to another. It is excellent and easy to use.

   gem install taps

6. Start the Taps server

   taps server mysql://username@localhost/databasename tempusername temppassword

   ‘username’ is your username on the local mysql server.

   ‘databasename’ is the name of the database on your local mysql server you wish to migrate.

   ‘tempusername’ and ‘temppassword’ is the username and password for the taps server. Put in anything you like for these as its only temporary.

   This will start a taps server running on port 5000. If the command succeeds it will connect to the database and wait for a connection.

7. Open a new terminal window

8. Pull the data into the Postgres database

   Using taps, we will now pull in the data from the taps server into the postgres database.

   taps pull postgres://username@localhost/databasename http://tempusername:temppassword@localhost:5000

   ‘username’ is your username on the local postgres server.

   ‘databasename’ is the name of the database on your local postgres server (created in step 4).

   ‘tempusername’ and ‘temppassword’ is the username and password for the taps server. These are the ones you set in step 6.

   Your database should now be copied over from your local MySQL server to your local Postgres server. Now lets get it onto Heroku.

9. Create a Postgres dump file

   pg_dump -Fc --no-acl --no-owner -h localhost -U username databasename > db.dump

   This will create a postgres database dump file.

10. Upload this file to Dropbox or Amazon S3 or anywhere else with a publicly accessible url. Make a note of the url.

11. Install the Postgres Backup add-on for your Heroku app.

    heroku addons:add pgbackups

    Installing this add-on is free and will allow you to make backups and restore postgres backups and dumps.

12. Restore the Postgres dump to your Heroku database

    heroku pgbackups:restore DATABASE 'http://url.to/db.dump'

    After a few seconds your database will be restored. Note that this is a destructive action (on the existing Postgres database on Heroku), so Heroku will ask you for confirmation before proceeding. Just follow the prompts it gives you.

There are probably faster and easier ways to do all these steps. However, I’ve found that if you have a lot of important data that needs to be migrated over perfectly, keeping all IDs and indexes intact, it pays to follow a methodical approach such as this.

The tools of a software developer are as just important as the tools of a carpenter. They need to let the craftsman get on with the job and get out of the way. Here is a list of tools that assist in getting my work done.

• iTerm 2 - I spend the vast majority of my day inside a terminal screen. To that end, it needs to be fast, have multiple windows and tabs, and be highly configurable. iTerm2 fits those requirements perfectly. Coupled with the Solarized theme, it looks and works beautifully.

• Vim - my trusty text editor of choice. I started my Rails development career with TextMate after watching that blasted how to make a blog video, and in the past used Visual Studio for ASP.NET/C# and Visual Basic development and the Delphi IDE back in my Delphi days. But now I use Vim. I’ve trained myself to use the h,j,k and l keys for movement and I’ve stolen many a vimrc configuration from others. I suspect that XCode will soon join Vim once I begin my journey into Objective-C/iOS development.

• Google Chrome - my browser. Its fast. Has a speedy development cycle. And great developer and standards support. Of course I keep a copy of the latest Safari, Firefox installed on my Mac as well. For testing Internet Explorer, I have Windows set up in VirtualBox (see below)

• Photoshop - Yes I could try and use something simple (and less expensive). But like I said in my intro, I just need something that works. And works well. I have to deal with images. The quicker I can deal with them and get back to my terminal the happier I am.

• VirtualBox - Having the ability to run virtual machines is a god send. Especially in todays world of multiple browsers in multiple operating systems. I run VirtualBox to allow me to test site rendering inside Internet Explorer.

• Pivotal Tracker - Organise your projects. I haven’t found anything simpler or more effective for managing the progress of projects.

• Github - Source code repository. All my code goes in here.

• Freeagent Central - Great site to manage invoicing, tracking business finances.

• Linode - Web hosting. Yes there are plenty of others. I’ve been with Linode for years. They are fantastic.

• Ubuntu - Server operating system of choice. I also have Ubuntu running on a seperate desktop machine in the office. It is stable, well supported with a huge community.

• Apple OSX - My primary work computer is an Apple MacBook Air (mid-2011) model. Running the best operating system in the world.

• LimeChat - IRC Client. Simple. Effective. And has the Solarized theme.

• Adium - I have lots of contact on a variety of chat platforms. This one combines them all into one app.

• Skype - I use Skype for work contact. Its bullet proof.

• Twitter - You can learn a great deal by following the people in your field. I’ve made many contacts through twitter. It can be a time suck, so you need to be careful. I use the official Twitter app on the Mac. Occasionally I’ll have Tweetdeck running in Chrome.

A topic for another day is time management. I use two apps for this:

• Notional Velocity
• Things

I’ll cover more about those in the future.

I hope thats shed some light on my main apps. I don’t think there is anything shocking in the list above. If there is anything you think I should try or would benefit in knowing more about, let me know in the comments.

I was refactoring some old rails code in a project today, and there were a lot of instances of the following:

f = self.where("country = ?", country).order("amount asc").all
g = self.where("country = ?", 'worldwide').order("amount asc").all

The issue is that everytime I queryed the db, I needed the records sorted a by ascending amount, so I had .order(“amount asc”) scattered through my code.

Of course, if I ever needed to sort a different way, I had to redo multiple lines. Not very DRY.

But Rails has default_scopes. This means you can define things like sort order or any other condition that will always be executed during a select, new or create action.

default_scope :order => "amount asc"

f = self.where("country = ?", country).all
g = self.where("country = ?", 'worldwide').all

A lot simpler.

Our internal Rails application needed a feature to scan in barcodes for consignment notes for our dispatch team. I looked around at barcode scanners and they averaged $150 to buy, and wireless ones were in the order of $500. And even then, there was still more data that needed to be captured than just the barcode (we needed to record the job number etc). I mulled it over for a few minutes and then wondered if an iPhone could be used. Sure enough, I found a great little app called BarcodeReader - WiFi. This $3.99US app scans in a barcode and can be configured to send that barcode to any website.

Over the next hour, I added an action to our web app that captured the barcode, and presented the user with a textbox to enter in the job number. Using an input box of type “tel” meant that it popped up a large numeric keypad to enter in the job numbers. Works perfectly and is very quick.

If you need barcode ability in your rails app and are able to use an iPhone or iPod touch, I highly recommend this approach. It is very cost effective and works well. I’ll post a link to a sample github project if required (leave a note in the comments if you would like to see this).

Yesterday I had a few minutes spare to test out Ruby 1.9.3which has just hit ‘preview’ status. I was very interested to see what the startup time would be on Rails 3.1 as some effort has gone into not only speeding up Rails but Ruby. As I get more and more fanatical about testing my apps quickly, especially after watching Gary Bernhardts Destroy All Software screencasts, I’m finding that I’m continually looking for ways to speed things up. It seems that 1.9.3 will assist!

I ran a little non-scientific experiment. All I did was create a new Rails 3.1rc5 app and added the rspec-rails gem. I installed Ruby 1.9.3.preview with the instuctions here. And then created a small rspec spec file that did nothing.

require 'spec_helper'
 
describe User do
end

But together with the time command I was able to see the following interesting stats.

time rspec spec/

With Ruby 1.9.2-p290 the load time was 6.632s. The same app on Ruby 1.9.3.preview loaded in 2.629s (a 60% improvement)

Thanks to various improvements (but I suspect primarily “the patch”, things are looking brighter for Rails bootup times. And that is a great thing!

Use of a particular operating system on any platform is largely a matter of personal choice. Sometimes, that choice is made by a business or corporation on behalf of their employees, and other times, individuals can make the choice themselves. I’m often seen tweeting or facebooking the virtues of Apples operating systems and products, often citing increased sales statistics or my own experiences in my message that Apples products give me a better experience than any of the alternatives. However, I often see mention that Android must be better because it has a higher market share. Or Windows is king because it has a higher market share. Higher market share does not always mean better product. A number of variables play part in determining market share. There are many cases where a product with lower market share, is simply the better product.

I will use the analogy of the car market. Australias #1 selling car, the Holden Commodore, sold 45,956 cars in 2010 (in Australia). Ferrari, on the other hand, sold 6,573 cars last year (worldwide). That’s an almost 7 times increase between one model of car from one manufacturer compared to every single car sold from another. A classic example of a better product (in terms of experience, luxury, and in most cases performance) having a lower market share than a competing product.

It is not business rocket science for a vendor to saturate a market with cheap product and grow market share. Selling cheap android handsets is a clear example of this. Numerous reviews have showcased the horrible experience a cheap android product provides. Yet, people continue to quote Androids stunning market share growth as a clear example of a superior product. Not so.

A similar case can be made for the ongoing debate of whether Microsoft Windows operating system is better than Apples OS X. A windows PC can be bought for a mere $199. The same is not true of Apple hardware. It stands to reason that Windows market share will be higher. This does not mean that it is a better product. If you’ve ever had a blue screen of death, had to re-install due to a slow down, or the computer crashing or catching a virus (even though you already had an anti-virus installed), then you will know what I mean.

So, next time you hear “High Market Share means better”, have a think about all the factors that have contributed to the market share number. Product quality and overall joy of use may not rank high in contributing factors, and it may in-fact be a terrible product to use.

I must admit, I probably didn’t test my code as thoroughly as I ought to have. Let me re-phrase that. I did test it. I just didn’t write complete test cases to ensure regressions weren’t introduced when new bits were added. As a result, maintenance always took longer than it should have, and bugs were introduced when changes were made. Even though I had read and studied the importance of testing very early in my software development career, it was only after continued frustration with things breaking that I got off my butt and actually started using testing practices like TDD, BDD and even writing tests for code that had already been written. I made it a goal to have the code as covered as possible.

Initially it took way longer to write code. Way, way, way longer. I did get frustrated. I questioned if this was really the way to go. But in the end, I got quicker at writing tests. I more often than not wrote the tests first. And things were good. If things broke, I wrote a test, fixed the bug, tested the entire app to ensure I didn’t break anything else. And things were good. I’m now very much an advocate for testing and consider it probably the most important skill in my software development bag.

I recommend reading the post by Ryan Bigg. It covers some other points in relation to testing, especially the economic and financial implications both personally and to an organisation when testing is not a priority.

I’ll follow this post up with some tips on how to add tests to a Rails project that has none. I think this is a very under documented process and one that will help many people that have existing projects that they understand very well, and adding tests will give them the confidence and knowledge to use tests when they start a new project.

A few weeks ago, I finalised some new code for a new section of an existing website. I always code websites using web standards and always test on the latest versions of Chrome (v10), Safari(v5), Opera(v11), Firefox(v3.6) and Internet Explorer(v8). In the case of the latter two, I test both the current version and the upcoming version. So the site is also run through its paces on Firefox 4 and Internet Explorer 9. As for mobile, I test on iPhone and iPad too. As you can see, it’s a pretty comprehensive test. However we began getting customer feedback that they couldn’t log in to the new section of the site.

I looked through the logs and couldn’t even see that they’d made an attempt to login. Very weird. I went back to the tests and everything worked. Then some users were able to log in. But the majority couldn’t. We started to get some screenshots and feedback and discovered that it was a browser issue. Internet Explorer 7 to be exact. The jQuery login popup we had implemented didn’t render correctly on the old Microsoft browser. Hence it didn’t work, and no entry was made in the logs, as the customer wasn’t even able to submit the form.

I had a look at the analytics data for this group of users and found that 89% of them were using Internet Explorer 7. A browser not in my test suite but used by the vast majority of our users (of this part of the site). The fix was easy once we knew the problem. And all customers can now log in.

Suffice to say that Internet Explorer 7 is now part of our test suite. We don’t test that things “look” the same. We just test that the site “works”. Internet Explorer 7 has 5.7% of the worldwide market share, and Internet Explorer 6 has 3.8%.

But the main lesson learned, is that when developing for a closed group (like an intranet or a internet site that is locked to certain users), make sure you know the browser statistics data. Not only will it ensure that what you’re developing works, but it also provides the opportunity to give them a better experience through harnessing the power of that particular browser.

Facebook is like fashion. It never ends.

I was watching..or re-watching….The Social Network the other night and my ears pricked up as I listened to some dialogue between a young Mark Zuckerberg and his equally young financier, Eduardo. They were celebrating the fact that The Facebook was about to “go live” and Eduardo asked if the site is “finished”. Mark shot back, “It’s never going to be finished. Facebook is like fashion. It never ends.”

Not quite sure if Zuckerberg ever actually said that, but it’s an interesting and bold point, not just for Facebook, but all web sites or web applications. I’ve always been a big believer that a website is a continual improvement process. Sure you can launch and leave it. But the site then becomes stale. It’s design becomes stale, its content becomes stale. And visitors stop coming back.

How many sites have you been to lately where the “news” section was last filled in 3 years ago. Where the site looks odd when you look at it in on your smart-phone? These are the sites that suffer from “launch and leave”. Like a neglected yard, the weeds start accumulating and people just see your site as a wasteland.

Often times, we as designers/developers, need to share the blame for this with our clients. We build sites to a budget that doesn’t take into account ongoing maintenance, post-launch reviews, or even educating the client on how best to keep the content on the site fresh. And I think it is up to us in the design/development community to lead the way in, at a bare minimum, communicating this message to our clients. Keeping them educated on the pitfalls of stale content, on the importance of re-visiting the site for design updates on an agreed interval, or reviewing that the site is keeping up with the goals it was originally designed to meet. Surely these points are something we should be looking forward to doing, not shying away from.

A young Mark Zuckerberg was right, and had he left Facebook as it was when it originally launched, it wouldn’t have over 500million regular users that it enjoys today. Websites are like fashion. Never finished. Never done.