• Read more about Choosing the Best Language for the Project: Deciding between PHP and Ruby on Rails

PHP

The positives:

The potential downsides:

Ruby

The positives:

The potential downsides:

The ugly side of both:

Both either provide or use templating language/tools. This is a trap, don’t do it. Let server side handle server side, and front end frameworks handle the rest.

And the last word…

PHP may be a language that’s easier to use and pickup on the server side than Ruby, but historically it has a hard time competing with Ruby when it comes to its frameworks’ capabilities.

• Read more about On Code Cleanliness and Readability

Programs must be written for people to read, and only incidentally for machines to execute. - Abelson / Sussman

I like my code so clean you could eat off of it (if you could eat off of code). When working on a codebase I'm ruthless about deleting unused code, unnecessary comments, debugging statements, etc. Yes, it may be painstakingly detailed, but this is all a benefit to my future self, my coworkers and anyone who reviews my code in the future.

When doing a code review of a pull request, I make notes of all the places where code could be cleaner; I also expect the same to be done for me. If I'm pairing, I make sure we do code reviews of every line of a commit before making the commit. I run a tight ship, and I appreciate when my coworkers do the same.

It's just common sense; a clean codebase, free of cruft, is easier to read and understand. A codebase that is easy to read and understand is easier to debug, extend, and modify. Ultimately, a clean codebase makes for happy developers.

What is "clean" code?

Code that is "clean" is code that is written to be read and understood with relative ease. You could say this is code written with the reader in mind. Every person and every organization has their own definition for what exactly clean code is, so I won't be giving explicit examples. What is important is to find some common ground on a project and all stick to it.

Every developer has heard the old saying that goes something like "Always code as if the person maintaining it is a maniac serial killer and knows where you live". With respect to that, clean code is code that keeps you safe.

Rules for organization

Everyone in an organization has their own rules for how code should be organized. It doesn't matter all that much what these rules are, so long as everyone in the organization can agree on some set of rules and everyone follows them.

If you do not have some rules I suggest listening to the ruby rogues podcast episode in which Sandi Metz discussed some rules for keeping code clean.

They are:

• Your class can be no longer than 100 lines of code.
• Your methods can be no longer than five lines of code.
• You can pass no more than four parameters and you can’t just make it one big hash.
• Your controller (in a Rails app, when a call comes into your controller) can only instantiate one object to do whatever it is that needs to be done.

Note that these rules are not really rules but more like guidelines. They are there to guide you when you don't know where to begin with writing clean code; they are there if you have no rules; they are there as a conversation starter within your organization.

To quote Charles Max Wood from the Ruby Rogues episode regarding the rules:

So, one thing that really strikes me with these rules is that for the most part, if you really try, you should be able to follow them. [If you say] “Oh well, I’m sure I can find an instance that breaks this rule.” The whole point is when you break the rule, you should be able to explain exactly why you need to break the rule. In that way, then you can justify what you’re doing. But otherwise, you’re not forced to think about what you’re coding and that’s really what the issue is.

Style Guide

A style guide goes hand in hand with code rules, such as those defined above. A style guide, however, covers a much greater set of situations. I think the guidelines defined in a style guide are just as important. If everyone codes using their own style (say 4 space or hard tabs instead of 2 space tabs) on a project, it makes the cognitive overhead that much greater from file to file. If I have a standard style that I know the code will conform to, it makes it that much easier to scan the code and figure out what is going on.

Ruby style guide

At Intridea, we have a Ruby style guide that we follow to make sure that the code we write all follows the same convention. (you can find it at Ruby Style Guide). This is a non-confrontational way to let your developers know there is a standard for the way their code should look when they are writing it, you are reviewing it, or you are both writing it via pairing.

Rspec style guide

It is not only important to keep your ruby and rails code adhering to a consistent style, but also it is important that everyone write their specs in a consistent way. I suggest using a resource like betterspecs.org as a starting point for a conversation about how you want tests to be written.

If you want to differ from what is proposed on that page, it is open source on github here. So you can fork it for your organization and make any changes you would like.

Humbleness and code reviews

The best way to fight against spaghetti code, or a big ball of mud, is to have someone review your code, whether through pair programming or an explicit code review (a git pull request being most common these days).

It's important to remember, don't take comments personally, criticisms of code are not criticisms of the person. Critiques of code logic or style should be looked at as a moment in which you can grow as a developer. You may not agree with the examination of your code, but it will at least spark a conversation in which case all parties can see each others viewpoints and come to a consensus of what the end result should be.

On more than one occasion I have come across a piece of code that I thought could have been a bit cleaner, or refactored differently, and thought "oh man, I get to correct someone!" Only to then check the author through git blame, and realize it was written by me. My point is that no one is perfect and change isn't going to happen overnight; it takes time and deliberate effort. You should look at comments regarding code organization or style not as an attack, but as an effort to make the end result better for everyone.

Keep the conversation going! We'd love to hear from you.

• Read more about Development for Designers

Development for the Designer

Designers and developers have a symbiotic relationship. While they may have complementing skill-sets, there are plenty of advantages to reaching across the aisle, so to speak. This two-part series discusses how designers and developers can benefit from becoming more familiar with each others skills and I'll offer some advice on how to get familiar with the "other side."

In this first post I'm going to talk about the world of the programmer, and how as a designer, you can start to get comfortable in that world.

The Disconnect

By nature, designers are a visual group of people. They think spatially and are affected by aesthetics to a greater degree than the average person, including most programmers. In many ways this mindset can make learning about computer science somewhat difficult. You don’t really think about pretty colors and shapes when thinking about computer science.

Snuggling up to the command line

To many designers, the command line seems to be a frigid, phlegmatic tool; dispassionate, mechanical and without personality. Despite the seeming lifelessness of the tool, we can't argue against the sheer power of the command line. Working from the command line doesn’t have to hurt, and in many ways can be much more productive than using a GUI. Since many designers use a Mac, we will focus on BASH commands (used by Unix, Apple’s underlying operating system).

Learn how your system is actually constructed

Browse your file structure and learn where directories are located on your machine. Doing this will give you a greater sense of how your system works, as well as what sorts of files might be hidden. Moving files and directories within by the command line can be much faster than using Finder to do so; this is especially true if you know the exact locations of where your files/directories exist. Here is a short list of helpful commands to get you started:

• Change directory: cd
• List files in a directory: ls
• Create a directory: mkdir new_folder
• Enter a directory: cd new_folder
• Copy a file or directory: cp /original/file/path new_folder
• Move a file or directory: mv /original/file/path new_folder

For more advanced commands, and in-depth documentation, I like using this site.

If you have an old computer kicking around that you don't care too much about, it would be a great tinkering box for learning the command line. I’ve been a fan of using the FreeNAS operating system, because you can pretty much install that sucker on any machine. It only needs 256Mb to run, and it is all command line unless you connect to it through your browser.

Programmed to love

As a designer, you have the ability to hold images and ideas in your mind. You know how you want your designs to look and how to work, but your brain starts getting cloudy when developers descend into nerd diatribe, sputtering about things like rake tasks, migrations, loops, classes and so forth. A change in communication might yield a change in perception when describing and discussing the inner workings of your design. Really when you get down to it, programming isn’t far off from one of those Create-Your-Own Adventure books.

Write in pseudo-code

Pseudo-code is just a way of thinking about and documenting the logical aspects of how code works, in laymen’s terms. Let’s say that I want a hover state for a navigation item, but I want an active state for the item when the user is on the page. You could use this pseudo-code to describe that interaction:

If the user rolls over the navigation link, Then make the navigation link turn red.
If the navigation link equals the current page, Then make the navigation link turn blue, Unless the user rolls over the navigation link, Then make the navigation link turn red.

Eventually, this mentality will allow you to start coding on your own and can help you understand the code written by the developers that you work with. If you want to start building tests like you hear all of those Ruby programmers talking about, look into Cucumber. You are able to write out tests much like you would write pseudo-code.

Drop your WYSIWYG and pick up an IDE

At some point you will have to face it; in order to do real development you have to write out code. There are programs that help with code completion and syntax coloring, in fact all of the good ones do. I would recommend picking up TextMate or RubyMine. TextMate takes up much less RAM, but doesn’t have all of the extensive assistance that RubyMine does.

Tutorials and Community

Aside from a few disgruntled developers, the majority of the programming/development community are some of the best people that you can come across. Asking questions in forums is a great way to get going, just make sure you know the topic doesn’t already exist. Most programmers are so excited about the work that they're doing, that they don't hesitate to make time to help new programmers. If you want to learn Ruby (and you do), check out these great resources to help you get started:

• http://www.rubykoans.com

If all of this is still too advanced and you want to learn more about basic programming using a GUI interface, check out Scratch! While it may be marketed as software for kids, many entry-level college courses also use it to teach programming fundamentals.

You'll be a better designer for it

Although learning just for the sake of learning is valuable enough, there's something in it for you directly as a designer. Crossing the bridge that spans the divide between quirky, artsy designer and pragmatic, intellectual programmer is a big step. But you'll find that you have more in common than you may have guessed. As an artist, you think abstractly. You bring color, texture, and form to reality. A programmer also thinks with great abstraction. How else could they take your artistic vision and breathe life into it with a bunch of alien commands that abstract back to 0's and 1's? Programmers are all at once both incredibly logical and conceptual thinkers. Learning to program can be an intimidating process, but you'll be able to approach your design patterns and process with greater clarity and confidence, equipped with a more thorough understanding of the entire process. Daring to step out of your comfort zone will give you perspective.

"Perspective is necessary. Otherwise there are only two dimensions. Otherwise you live with your face squashed against a wall, everything a huge foreground, of details, close-ups, hairs, the weave of the bed-sheet, the molecules of the face." ~ Margaret Atwood (The Handmaid's Tale)

• Read more about Team Intridea featured in eWeek

Team Intridea has gained a national reputation for its team members' expertise and knowledge, especially when it comes to Ruby on Rails. Adam and Chris were recently interviewed for an eWeek.com article about Ruby on Rails 2.0 - check it out to see what they had to say:

Ruby on Rails 2.0 Users Give Thumbs Up