Welcome to the personal website of Matt Halliday

A List Apart recently linked to an article by Joshua Seiden titled, “Designers shouldn’t code” is the wrong answer to the right question. Joshua’s article is actually a response to Wayne Greenwood’s article, Unicorn, Shmunicorn—Be a Pegasus.

Both authors discuss important topics like different methods of approaching problems, which details to focus on & job security, so I urge you to read them. But to be completely honest (and hopefully not belittling), I think we’re over thinking this.

Designers should know just enough code so that they understand the technical constraints of a project and are able to reduce any potential issues during the execution phase.

What is meant by “code”

Joshua does a great job covering this in his article mentioned above:

Second, “code” is such a broad term as to be essentially meaningless. What do we mean when we say this? Do we mean back-end programmers writing APIs in C#? Do we mean full-stack developers writing web applications in Rails? Do we mean front-end developers working in HTML+CSS+Javascript?

In this case we’re definitely talking about front-end code, as Joshua goes on to say. I can’t think of any valid reason a designer should have to worry things about frameworks, database adapters, frameworks, etc.

Be a t-shaped designer

What does it mean to be a t-shaped person? Basically, it’s someone who excels in one area, while still being generally knowledgeable in other related areas.

Some things you should know as a t-shaped designer:

• Basic HTML & CSS (Box model, floats, positioning, page flow)
• Interaction (What happens when this is clicked? How will this adapt to a phone or tablet?)
• Performance (How will 4 web fonts affect page load time? Will this require any 3rd party scripts?)
• Accessibility (Is there enough contrast? Is this typeface legible at this size?)

Having a general understanding in the areas listed above doesn’t mean you need to become an expert in them. I can also guarantee you that you won’t have to design in the browser, understand Sass mixins or know the difference between a rebase or merge in Git. Heck, most of the time you probably won’t even have to write code.

(But if you do end up writing code, it doesn’t need to be great either. It should hold the same value as a sketch on a whiteboard or piece of paper does.)

Going forward

Developers don’t want designers to start writing production-ready code, the same way designers don’t want developers to create interfaces. There will always be a need for a dedicated designer and no one is trying to diminish your role on the team.

Things move quickly in the web industry and that means constantly learning new things and stepping up our game. Don’t look at these extra responsibilities as burdens, instead see them as a new challenge.

Ruby on Rails is a great framework with lots to offer, but to those unfamiliar with either Ruby or Rails, it can be a bit intimidating to get a development environment set up.

Note: I’ll only be covering installation for Mac OS X (specifically Lion) because that’s what I’m using. Windows users should have a look at RailsInstaller and Linux users probably don’t need help anyways.

Custom FTW

There are lots of ways to set up a Rails environment, but I’m only going to cover my preferred configuration, which is using rbenv and ruby-build.

A few reasons why we’re not going to bother with the default Mac OS X version of Ruby:

• it’s already out of date
• it doesn’t support multiple versions
• it can easily break after OS upgrades

We’re also not going to bother with RVM, but I won’t go into the reasons why. If you’re curious, just read the rbenv/rvm comparison on the rbenv Github page. (Nothing against RVM, I just prefer rbenv/ruby-build)

rbenv: Simple Ruby version management

That title doesn’t lie - installing rbenv is pretty simple, but you will need to have Git on your system. If you don’t have it yet, you can download and install the Mac package from the official website.

First things first, open up Terminal.app and type the following commands (without the dollar sign - that’s used to represent your shell prompt):

$ cd
$ git clone git://github.com/sstephenson/rbenv.git .rbenv

If you’re unfamiliar with shell commands, all we did was change into our home directory (/Users/yourusername) and cloned a Git repository into a new directory called .rbenv (in OS X any files/folders that begin with a period are hidden by default).

Now in Terminal, type the following:

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ exec $SHELL

The commands above should have added a few lines of code to your bash profile (a hidden file located in your home directory). These commands pretty much tell your shell what to do when you type an rbenv command. The last command will restart your shell and let you start using the rbenv command. (If the last command doesn’t work, try relaunching Terminal and that should do it.)

Next, enter the following command into Terminal and you should see a help screen with the version of rbenv and all the possible commands.

$ rbenv

If you don’t get an error that means you’ve done everything correctly - congrats! Now we have rbenv set up, but we still need to install a few more things.

Enter ruby-build

If you thought installing rbenv was easy, then you’ll love ruby-build, which by the way, are both of which are made by the super awesome Sam Stephenson of 37signals.

We’re going to be installing ruby-build as a plugin for rbenv, so you’ll need to run the following commands into your Terminal:

$ mkdir -p ~/.rbenv/plugins
$ cd ~/.rbenv/plugins
$ git clone git://github.com/sstephenson/ruby-build.git

The above commands created a subdirectory called plugins in /Users/yourusername/.rbenv, changed into that newly created directory and cloned the Git repo containing ruby-build. You can check ~/.rbenv/plugins to check and see if there’s a ruby-build directory there. If there is, it’s successfully installed.

Now that we have both rbenv and ruby-build set up and properly working, all we have to do is install the latest stable version of Ruby and set it as the default version.

In order for this step to work, you’ll need to have Xcode installed on your system. You can grab it for free from the Mac App Store if you need to. Once it’s installed, run the following commands. (The first command may take a while because it needs to download and compile the Ruby source code.)

$ rbenv install 1.9.3-p194
$ rbenv rehash
$ rbenv global 1.9.3-p194

We’re almost done - just a few more steps and you can start using Rails.

Multiple versions of Ruby

It’s worth noting that the above commands will also allow you to install any other versions of Ruby (old or new), simply by changing the build number.

For example, if you needed to support an older Rails app that requires Ruby 1.8, you would type:

$ rbenv install 1.8.7-p358
$ rbenv rehash
$ cd ~/legacy-rails-app/
$ rbenv local 1.8.7-p358

Then you could have the latest Ruby version set as your system default, but override it on a per project basis using the rbenv local command.

RubyGems and Rails

Since we’ll be installing Rails from the RubyGems library, we want to make sure that we have the latest version. RubyGems should already be installed by default, so all we’ll have to do is make sure it’s up to date.

$ gem update --system

Once that’s finished updating, we’ll need to install the Rails gem.

$ gem install rails

Rails and RubyGems are now installed and up-to-date.

Finishing up

Our shiny new Ruby on Rails development environment should now be set up, properly configured and ready to start using.

By choosing the rbenv/ruby-build configuration, we’ve made it pretty easy for ourselves to stay up-to-date with the latest version of Ruby. We also now have the ability to support legacy Rails apps that may require older versions of Ruby (like 1.8).

If you’re wondering what to do next, you may want to read my previous article on Getting started with Ruby on Rails.

Also, if you’ve run into any into problems during the installation process, I’ll try my best to answer any questions you may have on Twitter.

Over the past few months I’ve been teaching myself Ruby on Rails. I’m very happy with the progress I’ve made and thought it would be helpful if I shared a bit of my learning process with others.

My background

I’m a front-end designer, so most of my time is spent writing HTML, CSS and JavaScript. As much as I love doing that, I also wanted to explore the other side of things.

I can write some PHP and understand even more, but it’s never really felt natural to me. It always seems that what I’m trying to express in my head makes more sense than the code I write. This left me looking for a different programming language, one that more closely matched how I solved problems in my head.

(Note: I’m not trying to bash PHP here, just stating that it’s not for me. Use whatever tools make you happy.)

So, why Ruby on Rails?

There are many things to love about both Ruby and Rails, but the one thing that stood out to me was the Ruby language itself - it’s absolutely beautiful.

Ruby doesn’t heavily rely on things like curly braces and semicolons, instead line breaks and indentation are used. As a result you end up with groups of code that look like statements written in plain English. Ruby is quite often compared to poetry because of this.

And since formatting is so important, Ruby code will look virtually the same, even if it’s written by different people. This makes it much easier to read if you’re working with a team of developers or contributing to open source projects.

Language and syntax aside, there are many other reasons why Ruby on Rails seemed like a good fit for me. Here are just a few:

• Tons of awesome stuff is built with Rails (Basecamp, Github, Shopify and many others)
• Testing your code is strongly encouraged because it makes your life easier in the long run
• Coding principles like convention over configuration and Don’t Repeat Yourself
• There’s a huge open-source community of friendly, helpful people

Jump in

I honestly don’t think it matters where you start. A lot of people will tell you how to learn, when really, only you will know best. The important thing is that you just get started and stick with it.

I use a lot of different resources, both free and paid, but I had my “A-ha!” moment when I did the Rails for Zombies course.

Rails for Zombies

A free online course put out by Code School where you write code directly in the browser. This lets you learn Rails without having to set up a development environment on your machine.

Basically, you watch a video walkthrough and then write code in your browser to reach the next level. Also, be sure to check out Rails For Zombies 2 and also Rails Testing For Zombies.

Rails Tutorial

A tutorial (recently updated for Rails 3.2) that will walk you through the creation of a simple Twitter-like app.

You’ll learn about Rails MVC, testing with RSpec, user authentication, the Asset pipeline and even deploying to Heroku. You can currently read it for free online, or buy the PDF & screencasts.

Railscasts

A great site with new screencasts each week (one free, one pro and one revised). All sorts of topics are covered such as customizing/optimizing Rails, working with Gems and refactoring your code.

Also, if you buy a subscription then you get access to all the pro and revised screencasts.

Agile Web Development with Rails

This is probably the best Rails book out there. It covers tons of useful stuff like testing, AJAX, authentication, sending mail and deploying apps. It’s also written by very talented people, including David Heinemeier Hansson, the guy who created Rails.

RailsGuides

This will be your best friend when you’re first getting started and can’t remember how to do something. I can’t tell you how many times I refer to this when I’m working with Rails.

The path of least resistance

If you take anything away from this article, make sure it’s this section. These may seem obvious to some of you, but a list like this would’ve made my life a lot easier when I was starting out.

Embrace the command line

It can seem daunting at first, but it’s very powerful and faster than browsing your filesystem. I put this off and did things the hard way for a while. It’s totally possible, but can be tedious.

Love thy editor

I prefer something like Textmate (or Sublime Text 2) because it lets me see the entire directory structure which can be helpful when you’re starting out. A lot of developers swear by Vim because they’re in the command line anyways and it’s one less app to switch between. Either way, make sure you love it because you’ll be spending 90% of your time using it.

Have MVC experience

You’ll be way ahead of the game if you’ve worked with other MVC frameworks in the past. If you write procedural code, start with learning the basics of MVC. Simply knowing where all the code lives can be helpful when things go wrong and you need to debug.

Know some Ruby!

Rails isn’t a language, it’s a framework built with Ruby. That means you’re going to be writing Ruby, so learn it sooner rather than later. It will also give you a better understanding of how Rails works.

Next steps

One thing I didn’t cover here was setting up a Ruby on Rails environment of your own. This looks and sounds harder than it actually is, but it can be intimidating to tackle on your own. I should be publishing an article on that in the next few weeks, so stay tuned and start hacking.

I’ve wanted to get this site back up and running for a few years now. It’s taken this long because I honestly wasn’t sure what the purpose of a new website would be, or if I even needed one at all.

A little history lesson

The previous version of this website first appeared around the beginning of 2007, right after I graduated from college. The whole purpose of the website was to showcase my graphic design work, try to land a few freelancing gigs and blog about graphic and web design.

The website achieved all of those things, but it was quite obvious that the blog was an afterthought. I probably wrote about a dozen articles or so, none of which were spectacular or really said anything unique. The problem, was that I had originally decided to start blogging because a lot of other web designers were at the time. What I didn’t realize then was that I wasn’t contributing anything useful to the web and was just creating noise where it wasn’t needed.

I ended up taking the site down in early 2009 when I was hired by Barking Dog Studios as a front-end designer. The blog had been neglected for quite a while and the rest of the site wouldn’t be needed anymore, so I replaced it with a “coming soon” page (which was actually still online up until a few weeks ago).

Starting over

When I first started redesigning, I was too caught up with what the rest of the web was doing. I was adding features I didn’t need, trying to go after a certain “look” and using shiny new technologies just because they were available. I went through a number of designs and even got to the coding stage a few times before completely scrapping them.

It took me a while to realize that all of that stuff didn’t matter to me. I wanted my website to be a place where I could write about the things I love and share things that interest me with like-minded people.

Once I knew what the purpose of the website would be, it wasn’t so hard coming up with an appropriate design for it. It’s far from perfect but I’m quite happy with the result so far.

So, what now?

First things first – no promises. I’m not going to tell you that I’ll write a certain number of entries per month or anything like that. I’ll write when I have something to say. It could be an idea, a review, a suggestion or even a frustration (hopefully not too often). I imagine that most of it will be web or technology-related, but don’t hold me to it.

Also, this website is very much a work in progress. I wanted to launch it as soon as possible so that I could start writing, but that also meant I had to leave some things behind (for now at least). This included a fluid grid layout and also support for media queries so that the site will be more usable. Hopefully those features will be added back in the near future.

Also, this site will never have comments, but if you ever have questions or thoughts you can reach me on Twitter @matthalliday.

Thanks for reading.