Sure, to learn photography you need to understand exposure and depth of field, but that’s only part of what it takes to be a real photographer, to be a good photographer. What camera and lenses should you buy? What brand of film? I even pay attention to borderline ridiculous details like what kind of camera bag the pros use. Learning first-rate cooking skills won’t do you much good if you don’t have a good set of pans. Any chef will tell you that having quality, sharp knives make a world of difference in the experience of cooking, even though it may not change the flavor. And, as I love to watch Gordon Ramsay scold, keeping a clean kitchen is an essential (and too often overlooked) step in producing quality food.

The point is that there is more to learn than just the fundamentals. It makes sense to learn from the trial-and-error experience of people who are already working with these tools everyday. I may decide I disagree with their preferences, but knowledgeably making a different choice is much better than stumbling around on my own. Plus in the process, I know I will discover some of the intricacies and pitfalls that come with working in the field.

In that spirit, here are the tools that help me as a web developer.

MacBook Pro (15″ Intel)

I have always been an Apple user so that is where I am the most comfortable. It has been a great choice for web development because I can develop on OS X’s Unix and deploy on Linux. I like having a laptop because everything travels with me. If I need to fly to a meeting in California or teach a course in Texas, I have all my web development files with me. I can work on the plane. I can answer client emails from the hotel. I can upload bug fixes as soon as I find out about them. I prefer the 15″ because the 17″ is harder to lug around and I don’t need the extra width (screen height is more important for programming than width).

Apple Cinema Display

In order to have more screen real estate, I attach an additional monitor to my laptop. When I’m developing, I usually keep my code and any server connections (FTP, SSH) in front of me and use my external monitor for my web browser(s). Fix code over here, view the changes over there.

Spaces

Recently, I’ve also started using OS X’s Spaces to good effect. Spaces let’s you create several virtual screens that you can quickly switch between. It works well for me when I’m multi-tasking. I can put email and personal web browsing in one space and then put work for three different clients in three separate spaces. If I have a brainstorm of if a phone call comes in from a client, it only takes a second to switch spaces and start taking notes or making changes.

External Hard Drive / Time Machine & Time Capsule

Backup, backup, backup. If cleanliness is essential to a career in the kitchen, then backing up your computer is essential to a career in programming. It may not make your code any better but it will make the experience better. An external hard drive is a tiny investment for a huge data insurance policy. Of course you have to remember to use it! At a minimum, backup once a month and/or before any trip. For key files, I recommend keeping two versions. You can safely throw out the oldest version when you make a new backup because you know there is another full backup. Be sure not to forget about non-obvious files like MySQL databases.

You can also get software to run backups for you. I’ve tried different programs and techniques with mixed results. The best so far is Apple’s Time Machine when pair with their Time Capsule. Every hour, my computer boots up the Time Capsule hard drive and records any file changes. I don’t have to remember to make the backup. I always know I’m covered. One of the added benefits of Time Machine is that you can also see the old versions of the files, even deleted files, in case you made a revision or deletion you didn’t mean to make.

TextMate

Don’t attempt coding without a good text editor, especially one that has code coloring. While I know that a lot of developers prefer a full Integrated Development Environment (IDE) over a simple text editor, I do not. I prefer the simplicity of a tool that does one job really well. I don’t want to have to learn the ins-and-outs of the IDE. I don’t want to spend time wrestling with its peculiarities and bugs. If I were working with a compiled language like C++ or Java maybe I would find an IDE more useful, but for web programming it’s easy enough to host my own development environment (whose peculiarities I already know).

For many years, BBEdit was my favorite editor, but about three years ago I switched to TextMate and I’ve never looked back. TextMate lets me open up a whole project at once with a file drawer and tabs that make it easy to move around. It will fold up (collapse) sections of code to get them out of my way when I’m not using them. It lets me bookmark code to make it easy to locate later. It has great search and replace features (searching using regular expressions is a feature I insist on). It has customizable code coloring/formatting, a long list of language specific helpers (bundles), and many useful hot keys and shortcuts. The only feature I miss from BBEdit, is the ability to run diff on two folders. You can manage it in TextMate but not as easily. I still have BBEdit around for those rare times when I need it.

Transmit

The best FTP software I’ve used. Simple and reliable.

ExpanDrive

I have recently started using ExpanDrive and I can’t say enough good things about it. It is SFTP software that mounts a remote server as if it were a local drive. You can drag/drop and open files using the Finder, just like they were on your Mac. The only reason that this software won’t replace Transmit for all my FTP needs is that it is for SFTP only right now. (Half of the servers I use use FTP and half use SFTP.)

One note, if you want to use ExpanDrive to open files as a project in TextMate, TextMate will slow to a crawl while it refreshes the list of files in the project every time you switch to it from another program. There is a plugin called Remate that removes the wait and gives you a manual “Refresh Project Files” link instead.

phpMyAdmin

The standard for working with MySQL databases in a simple user-friendly web interface. I love the fact that it exposes most of the SQL requests it makes so that beginners can learn from it and pros can tweak and edit it. I still use MySQL from the command line too, but for a quick answer, for working out complex queries, or for importing and exporting records, phpMyAdmin gets me there faster.

WordPress

This blog uses it. It’s easy to install for clients (or friends) who need a simple, free blog or content management system. I also find it instructive to watch the development of WordPress, both from the code and business perspective. The WP team is doing a lot of things right.

QuickBooks

I use QuickBooks for all my business accounting. I use it to record deposits, write checks, and keep track of projects. I can run a report and know which projects brought in the most revenue and which were the most profitable (not the same thing). Four times a year I send the file off to my accountant who figures out how much I own in taxes. Because it is designed for users with an accounting background, I’m not sure how easy it would be for a beginner to pick up on their own. I had an accountant teach me.

Dictionary & Thesaurus

It may sound strange, but the dictionary and thesaurus have been frequently useful to me. Not just for writing client proposals, but for when I am actually programming. Suppose you are working on a site where you need a database for “types” or “classes”. But “type” and “class” are reserved words in most programming languages. Just open up the thesaurus and find a synonym–maybe “brands”, “groups”, “vintages”, or “flavors”. They can also be a great help when trying to think of new domain names, project names, or company names.

Hosts: Pair, Slicehost and Rackspace

I have been a long time client of Pair. I love them for their stability, domain management tools, and email management. They are a great place to host an HTML or PHP site, but Ruby on Rails hosting is not one of their strengths.

For Rails hosting (or any hosting really), I can’t say enough good things about Slicehost. They are inexpensive, it is fast and easy to sign up or modify your account, and their online documentation is good.

The only downside to Slicehost is that you have to be server savvy. When you sign up it’s literally like taking a brand new Linux server out of the box with only the base software installed. You have to do the rest. Beginners will do better to go with shared hosting environment where much of it is pre-configured for you. But experts will love the freedom.

Rackspace is the Mercedes Benz of web hosts. I can’t afford them but some of my clients can. If a client wants reliability and top-notch customer service, and will spend the money to get it, then I refer them to Rackspace.

And even though I use them less frequently, I can also report good experiences with MediaTemple and LiquidWeb.

Other Tools

And rounding out the list would be some more obvious choices: Firefox, Safari, Internet Explorer, Photoshop, Illustrator, iCal, Mail, Keynote and iTunes.

I’d love to hear what tools help you. I still have plenty to learn from others!

The before_thumbnail_saved callback in attachment_fu is useful for tasks like giving thumbnail versions the same attributes that parent images have. So if an image belongs to an artist, the callback can give the thumbnail the same artist_id as the parent. The callback originally yielded two values to a block—record and thumbnail—like this:

But now it yields only one value: thumbnail. To get the same functionality as before, you will need to add a line of code to first find the parent record.

If you haven’t tried attachment_fu yet, here are some links you may find helpful:

• Install RMagick on Mac OS X Leopard from source
• Mike Clark’s attachment_fu Tutorial

Rails 2.1 removed the original scaffold generator and replaced it with a new RESTful scaffold generator.

Bummer.

I’m not talking about the dynamic scaffolding that comes from putting “scaffold :model” in a controller. That “dynamic scaffolding” was removed in Rails 2.0 and few of us miss it. I’m talking about when you type “ruby script/generate scaffold Model” from the command line and get generated model, controller and view files as a result.

While I understand that Rails is “opinionated software” and that they want to encourage everyone to get on the REST bandwagon, I think completely removing the old scaffold generator was a mistake for one simple reason:

It unnecessarily raises a barrier to entry for beginners.

When beginners first start on Rails there is a lot to digest. Installation issues, Ruby language, MVC architecture, ActiveRecord, Rails syntax, routes, migrations and deployment—just to name a few. In my opinion, asking someone eager to learn Rails—someone who may have a background in PHP but who still doesn’t understand code blocks or the basic Rails .find syntax—to also use REST from the start is only going to frustrate them and slow the growth of Rails adoption. They need to walk before they can run. We have added best practices for advanced users at the expense of the newbies.

The Lesson of Microsoft Excel and Lotus 1-2-3

I remember when Microsoft Excel won the spreadsheet market away from Lotus 1-2-3. They did it in part by making an easy transition path so that Lotus 1-2-3 users could make the switch painlessly. (Lotus was also slow to adopt Windows, and Microsoft pushed out frequent releases with new features. Two other important lessons.) It was more work on Microsoft’s part to make Excel “Lotus-friendly” and meant supporting and living with code inside Excel that must have seemed extraneous and deviated from “best practices”. But that extra code wasn’t actually extra, it served an important function: to bring users into the product. Without those users, you could argue that the rest of the Excel code—the “essential parts”—would not matter.

If we want developers to transition from other technologies to Rails, it is important to keep the barriers to entry low and to make the upgrade path simple. Every developer who gets curious about Rails and says “Hey, I picked this up fast” will grow the audience and probably evangelize to others. That’s exactly how Rails got it’s amazing, viral beginning. But every developer who gets curious about Rails and says “I just tried it but I couldn’t make sense of it” is a developer whose participation, enthusiasm and evangelism we lose. For that reason I think the decision to remove the old-style scaffolding takes Rails in the wrong direction.

The Utility of the Original Scaffold Generator

The original scaffold generator made Rails easier for beginners by introducing the basics of CRUD (Create, Read, Update, Delete) and by giving them an opportunity to see how the Rails request/response cycle works, how routes work, how parameters are passed, and how instance variables and object instances do or don’t persist. It was a friendly introduction to the framework and to world of object-oriented programming for the uninitiated. It offered a smooth transition for anyone used to PHP, Perl, Python or Java. The beauty of the original scaffold generator code was not so much that it was useful, but that it was instructive.

The Solution: CRUD Scaffold Generator Plug-in

Fortunately, one of the wonderful features of Rails is it’s extensibility through plug-ins. So the original scaffolding doesn’t have to die just yet. I put the original scaffold generator into a plug-in, updated it (for example view templates now end in “.html.erb”) and cleaned up the views and styles a bit. I’ve called it CRUD Scaffold (”crud_scaffold”) so that it won’t interfere with the built-in “scaffold” generator’s RESTful scaffolding and to make clear that it generates the basic CRUD for a model. (99% of the credit goes to the original coders.)

You can download the plug-in by going to the github page for CRUD Scaffold Generator and then clicking the download button. Unpack the file and put the entire crud_scaffold_generator folder into the /plugins folder of any Rails application. Run it from the command line while inside the root of your Rails application:

Where Modelname is the name of the model for which you want to create a model, controller and views. It works just like the old scaffold command use to work.

There is one big change in my version that is worth noting. The old scaffold used to dynamically read the fields from your database table, this one does not. I never found those dynamic fields useful and found they were confusing to beginners. Instead, my version reads the fields from the database table when you generate the scaffold. So it is a good idea to first create/migrate your database table, then generate the scaffold. If you add fields to your table later, you’ll have to either re-generate the scaffold or add the new fields to the views by hand.

My hope is that the CRUD Scaffold generator will keep it easy for beginners to get started with Rails. I know I’ll be using it in all of my Rails courses.

It’s a good question. Experienced computer programmers have learned these steps—either through intuition or experience—but beginning programmers are often mystified. Once you learn the language syntax, how exactly do you use it to approach a programming problem? Especially if you want to try to use good programming techniques and to solve the problem in a smart and efficient way.

The answer to the question “Are there steps to writing code?” is “Yes”. After the jump, I’ll give three ways to develop the logic necessary to write good code.

Outline

When I have a complex bit of code to write, I start by writing comments to outline what I want the code to do. For example, imagine I’m adding an item to a shopping cart:

Once you have an outline to work from, then you can go back and write code below each comment. It allows you to get your thoughts organized—to say “Okay, what are we trying to do here?” Breaking a large problem down into smaller parts will make it less overwhelming and let you tackle once piece at a time. Outlining is also a good way to make sure that you don’t skip a step once your head is wrapped up in the code details. And, as a bonus, you’re code will already have some comments in place so you and other developers will understand the thought process.

Design Patterns

Design patterns describe the high-level concepts or abstractions that are frequently used in software. (Wikipedia: Design Patterns) There’s no sense in reinventing the wheel each time. Design patterns will not tell you how to write your code, but rather they provide a conceptual structure that can help to guide you and inform your coding choices. Design patterns is not a beginner subject (many of them will go right over your head), but even beginners can start to make use of them. My advice is to digest what you can, don’t worry about the rest and revisit them again each year. Wikipedia has some good information, but the best book to learn about design patterns is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

Refactoring

First make it work, then make it work better without breaking it. In the simplest sense, that is what refactoring is. However, like design patterns, it is possible to describe those code improvements in high-level, abstract terms. (Wikipedia: Refactoring) You can look for “refactoring patterns” or places where a common refactoring technique can be employed to make your code clearer, faster, reusable, and overall more maintainable. The best resource to learn more about refactoring is the book Refactoring: Improving the Design of Existing Code by Martin Fowler. Refactoring techniques make use of design patterns so it’s worth exploring both. Also, since the goal of refactoring is to improve code without changing the results, code testing (such as unit testing and functional testing) becomes an important skill to develop to get reliable results from refactoring.

In my own work, I use all three. I try to recognize the design patterns I’ll need before I start. Next I outline before I code. Then I just try to make it work, writing very sloppy code I would never want anyone to see. Finally, I try to make it work better by looking for refactoring opportunities. (And often it isn’t so much looking for fancy refactoring patterns, but just for bone-headed choices and shortcuts that I made while getting it to work.) As I gain more experience, problems that once required me to employ all three techniques now get solved with pretty decent code from the start; and I can use those same techniques to solve harder problems. It is a bit like when you first learned to add and subtract using your fingers but then learned how to do those calculations in your head.

If you are an experienced programmer with additional advice for beginners on the steps to write good code, feel free to offer it in the comments.

The first function simply locates an element on a page. For example, if you pass it an element_id like “sidebar” it will locate the element with that id, such as <div id=”sidebar”>. The second two functions use findElement to locate the element and then either tell it to display on the page or not. So a hidden element can be revealed or a visible element can be hidden.

Though simple, these functions allow us to perform a nice slight-of-hand. We can hide a large block of text but leave the title or a short summary visible. Clicking on the title will reveal the full text in a larger div. Clicking it again will re-hide it. The effect is made even better by adding arrow icons: right-facing (or left-facing) for the “collapsed” or hidden state, downward-facing for the “expanded” or visible state.

Here is an example:

First Section

First Section

Longer text goes here.

Click the title again to collapse the view.

Second Section

Second Section

Text for the second section.

Here’s how you can do it yourself. Put the above JavaScript on a page. Next, create two div elements. In the first, put the collapsed or summary view. In the second, put the expanded view with the full text and give the div a style attribute of “display: none;” to hide it when the page first loads. Now you need to two links. In the first div put a link that shows the second div and hides itself. In the second div, put a link that shows the first div (remember: when this link is visible, the first div won’t be anymore) and hides itself.

Because one div hides at the same time as the next one displays, and because all the other page elements shift up or down, the effect is that the original div has simply “opened up” to reveal its contents. You could also reverse the effect—start with an expanded div that can be folded out of the way—by simply moving “display: none;” to the other div. You can add more expandable divs to the page and, provided you give them unique ids, they will all work.

It is a simple way to put a lot of information at the user’s fingertips without overloading the page all at once. It also could save you additional page loads or MySQL calls that would result from putting the same data on a different page.

The textCounter script runs once after each key stroke is complete (”key up”) and takes two arguments. The first is the field being monitored, the second is the target field that will be updated with the “characters remaining” value.

Note that we don’t add 1 and subtract 1 for each keystroke. Instead we use the current field length because it is possible to paste text into the field or to select and remove more than one character with a single delete keystroke.

Each time a box is clicked the script runs. If a check mark is being added then the script tests to see if the running total (current_count) is larger than the defined maximum (max_count). If so, then it undoes the checkmark and displays an alert, but if not, then it allows the check and adds one to the current tally. When a box is unchecked, the tally simply decreases by one.

Save the Developers! is hoping to make the lives of web developers easier, while also improving the experience for web users. Their current campaign is Say No To IE 6! which is an attempt to rid the world of Internet Explorer 6.

How? By getting developers to put a bit of JavaScript on their website. Developers can either link to their external JavaScript file or download the script and host it themselves. (I added it to this site.)

If the JavaScript detects the the user’s browser is IE 6, then a small window appears suggesting that they upgrade. Clicking takes the user to their website which contains links to the latest versions of IE 7, Firefox, Safari and Opera.

They acknowledge that it may take awhile, maybe even a few years, but their goal is to reduce IE 6 usage as much as possible to help usher it into permanent retirement. I think that’s a goal all web developers share.

It is simple, effective and—best of all—won’t bother most users because they won’t see it. Their website will let you preview the effect, even if you don’t have IE 6. If you don’t like the look, just modify the JavaScript to fit your site design. If you don’t want users leaving your site, you can adapt the JavaScript so that the window links to an upgrade page on your own site.

Remember: Every time you upgrade a browser, a developer gets his wings.

A List Apart, Issue #257, has two articles on Ruby on Rails. Both articles are targeted toward Rails beginners and curious designers who may have heard the buzz but few details.

The information may be old news for many developers, but both articles are up-to-date, well-written introductions that are still worth bookmarking. Save them for the next time a beginner asks you for an explanation. Forward them to co-workers who don’t understand what you’ve been raving about. Print them out and leave them laying around so your most earnest PHP/.NET/Java friends can sneak a peak at them when no one is looking. Maybe they can even help explain to your parents/friends/significant-other what you do for a living.

• Creating More Using Less Effort with Ruby on Rails by Michael Slater
• Getting Started with Ruby on Rails by Dan Benjamin