ash white

I recently moved across town, and after meticulously setting up my desk in my new office I was disheartened to see that my Apple LED Cinema Display would no longer turn on. After a bit of experimentation I noticed that the USB ports, internal speakers, and magsafe charger all worked fine, but for some reason the display itself remained off.

After much unhelpful googling, I finally came across this post from a guy named Dan Myers, and it totally saved my bacon. 

This trick was to delete the file described in his post ($ sudo rm /Library/Preferences/SystemConfiguration/com.apple.PowerManagement.plist), but I additionally had to reset my PRAM a couple times while the display was unplugged (reboot while holding down CMD+Option+P+R). 

Thank $deity I didn't end up wasting any money on trying to service it!

John Gruber just summed up my exact thoughts about today's announcement by Microsoft previewing the UI changes being made in Windows 8. The last paragraph is particularly good:

Apple’s radical notion is that touchscreen personal computers should make severely different tradeoffs than traditional computers — and that you can’t design one system that does it all. Windows 8 is trying to have it all, and I don’t think that can be done. You can’t make something conceptually lightweight if it’s carrying 25 years of Windows baggage.

As anyone who has been writing code for a while can attest, keeping track of reusable code snippets is a must in terms of speeding up development. After all, who wants to waste time writing the same code over and over when you can simply copy and paste?

There is a plethora of software-based solutions to this problem, notably Code Collector Pro and Snippets (both for the Mac). I have used both of these in the past, and while they are great apps they either don't work quite the way I want or are a bit too unreliable in terms of syncing.

So what's the best solution for maintaining code snippets and reliably syncing them across multiple computers? For me it's through the filesystem, with a lot of help from Dropbox. I simply create a folder for each language, each of which containing snippets for that language (one file per snippet, with the appropriate file extension for the language).

This presents several advantages over dedicated snippet management apps:

Syncing is instant and 100% reliable

When you save a file it is instantly pushed to any other computers that are linked to your Dropbox account. You can even share folders or files with other people using Dropbox's sharing feature.

You get to manage the code in your own editor

Being locked into a snippet management app's text editor sucks. Though many of them will let you open snippets in an external app, that's still an extra and unnecessary step.

Snippets are indexed by the filesystem

This allows you to use Spotlight, LaunchBar, Quicksilver, or something similar to quickly search your snippets without having to launch another app. Practical filenames and embedded comments make finding the right snippet super easy, replacing the need for a tagging system.

Versioning and Backup

Dropbox provides awesome file versioning, making it easy to revert back to a previous version if needed. Dropbox keeps your files safe in the event of a disk failure.

Your mileage may vary of course, but in my opinion this method works wonderfully, especially for a free solution.

I had to laugh a little at the irony of your recent tweet about mainstream design blogging. The article does hit the nail on the head, though. There's way too much noise on the Internet these days. And you're not helping it at all. But you could be.

Having been subscribed to your RSS feed for about a year, I'd be surprised if I've found more than two or three actually useful chunks of information hidden in the mass of unoriginal, regurgitated link bait. The same goes for your Twitter feed, which is nothing more than a half-assed attempt to copy Gruber's Linked List format (which he freely admits was not his idea). Seriously, it's almost as spammy as Guy Kawasaki's feed.

If you were to take down all of the posts whose subject start with a number greater then three or include words like "showcase" or "roundup," there wouldn't be a whole lot left except for a handful of "articles" based on product placement and name dropping.

I would simply unsubscribe and unfollow, but I like to have reminders around me of how not to act.

Here's the thing you need to realize: you aren't providing us any useful service or information. That is, nothing that we aren't already getting from far better publications. We already know about all the latest nifty jQuery plugins because we read about them on Ajaxian and DailyJS first. We already got the latest tech news from TUAW and Daring Fireball, who are kind enough to provide real, honest perspectives. We already know what the latest design trends are because we read about them from the people who are actually creating them. We get spammed with disingenuous tips for optimizing our workflows and businesses all day long, most of which boil down to common fucking sense. We don't need someone to aggregate our news for us, so what are you really adding to the mix?

But think about what you could be adding. What if you stopped with the unreadably long roundup posts and started writing original, thought-provoking, non-attention-begging content? What if you broke away from the easy formula and went out and talked to real people with real opinions, or better yet, came up with some of your own? What if you stopped using Twitter to spam my feed with 20+ useless links per day and started using it to generate substantive conversations among your followers?

You could (and should) be doing something better than picking the low-hanging fruit.

I just spent a good hour trying to diagnose a problem related to the view lifecycle in the iPhone OS, so I thought I'd share the solution here.

My problem was in trying to grab some data from the network immediately after loading a view from a UITabBar. The goal was to have it switch to the new view, issue the system network activity indicator, and update a UITableView when the data was done processing. Something like this:

- (void) viewDidLoad {
	[super viewDidLoad];
	
	[self updateData];
}

However, no matter whether I put the code in viewDidLoad or viewDidAppear, the entire interface would appear to freeze before switching to the new view and would not respond again until the data loaded. I didn't even notice the delay in the simulator using WiFi, but when I deployed to my iPhone and tested it over 3G the process took upwards of five seconds (which I find unacceptable from a UX standpoint).

I eventually figured out a solution, which was to use a tiny delay before starting the network activity. This is a simple task:

- (void) viewDidLoad {
	[super viewDidLoad];
	
	[self performSelector:@selector(updateData:) withObject:nil afterDelay:.1];
}

The afterDelay parameter defines how long the app will wait (in seconds) before issuing the method on the specified object. Note that you are forced to pass one parameter to the target method. If your target method doesn't need to take any arguments, simply pass nil as I did above. You will also need to update your method signature to take that parameter, even if you do nothing with it.

Something that has always irked me is having to take the value of a textarea and convert the text into HTML paragraphs (especially when using a WYSIWYG is not an option). Here's a quick PHP snippet to take care of that, whether the user uses one or two line breaks for new paragraphs.

$body = preg_replace("/\r/", "\n", $body);
$body = preg_replace("/(\n+)/", "</p><p>", $body);
$body = "<p>$body</p>";

The first line will convert all carriage returns into newline characters (to accommodate for the way different operating systems handle line breaks). The second line will replace one or more occurrences of a newline into an ending and open paragraph tag. From there, all you need to do it wrap the entire block in a paragraph tag, which is taken care of by the third line.

To be honest this feels way too easy, so if I am doing something wrong here please feel free to let me know.

I've finally gotten around to picking up a copy of The Mythical Man Month, a collection of essays on software engineering written by Frederick Brooks which was originally published in 1975.

While the majority of the book has stood the test of time remarkably well, Chapter 3, entitled "The Surgical Team," especially intrigued me. The essay draws an elaborate analogy between a team of software engineers and - you guessed it - a surgical team. Brooks proposes that splitting large groups of coworkers into multiple smaller chunks based on the following positions:

• The Chief Surgeon is the lead developer of a group, responsible for all coding, testing, and documentation of a system or sub-system.
• The Copilot is the surgeon's assistant, whose job is to act as a sounding board for ideas and to know the code like the back of his hand to provide support when needed.
• The Administrator manages the team in addition to keeping an eye on the group's finances and resources.
• The Editor is responsible for managing and editing the documentation generated by the surgeon.
• Two Secretaries provide support for the administrator and the editor to assist with correspondence and non-critical project files.
• The Program Clerk manages the records of the project, namely documentation and source code.
• The Toolsmith assists the surgeon by crafting specialized tools as needed.
• The Tester maintains test cases for evaluating the work produced by the surgeon.
• The Language Lawyer is a very specialized consultant-type who is responsible for using his deep understanding of the technologies being used in order to maximize the efficiency of the operation.

Ten people to work on one system or a part of a system? Isn't that a bit of overkill?

While the roles of the Surgeon, Copilot, Administrator, Editor, Secretary, and Tester are still alive and kicking, the Program Clerk, Language Lawyer, and Toolsmith have largely been replaced by the software that has been developed in the 35 years since the original writing.

The role of the Program Clerk is now filled by sophisticated version control systems like Subversion and Git.

The need for Language Lawyer has been mostly replaced by highly-optimized compilers, lightning fast interpreters, and next-generation hardware.

The Toolsmith can probably be largely replaced by free libraries available from services like GitHub and SourceForge (and in the special cases that require this role the surgeon could most likely fill it).

Additionally, some of the surviving roles probably are not necessary 100% of the time, in that team members can easily take on multiple roles. For instance, free tools like Dropbox and Google Voice mean that two secretaries (or even one) might not be necessary for smaller firms that don't need to spend a lot of time on correspondence. I don't think I've ever heard of or seen an ad for a position that consisted solely of testing other peoples' code. How much revising of documentation is there really to be done (that can't be sent to a wiki and delegated to junior developers)?

While I certainly agree that a pragmatic distribution of roles and a sensible partitioning of tasks are essential to a successful software development company, I tend to think that it's equally (if not more) important to consider how peoples' personalities affect the mix rather than what it is they do. I would much prefer working alongside a developer who produces 10% more bugs — but who is consistently enthusiastic, personable, and stimulating — than an emotionless savant or a pretentious guru. Spending a few extra minutes in code review is worth it when the offender contributes positively to the overall motivation of the team. Deodorant helps a lot, too.

I'll be interested to see how upcoming advancements in software and hardware continue to affect all of the surgical team roles. Here's to hoping that some rockstar developer doesn't write a piece of software that makes me as obsolete as OS/360.

I have spent the last few days redesigning my personal blog from scratch with a totally new look and feel. The motivation for this came from multiple sources, including the desire to practice my design skills by creating something new (which was not fully satiated by designing my new mini-site recently).

I also decided it was time to start eating my own dog food, so I have migrated everything from Wordpress (which powered the previous iterations of my site) to Spool, the content management system we developed at Boxkite. 

And who knows, maybe the redesign will help me get off my ass and write more.

Let me know what you think of my new digs!

If you are building an iPhone web app, chances are you have gotten a bit tired of relying on your device for testing changes. It can definitely be tedious to upload your changes, pick up your device, and refresh Mobile Safari each time you make a change to your code. Here's a way to use your Mac to eliminate the device and the remote server from the development process.

Step 1 - Download the iPhone SDK

For this to work, you will need to download the iPhone SDK from the Apple website. This is a free download, but you will need to create an account and log in to gain access to the software downloads.

Step 2 - Make a Sandwich

The iPhone SDK is big. More than 2 gigs. Make a sandwich while you wait for it to download. Go on, you look hungry.

Step 3 - Install the SDK

This will also take a little while (see Step 2). If necessary, make another sandwich.

Step 4 - Load up the iPhone Simulator

After the install finishes, you can find a fully-functional iPhone simulator located in

/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app

Since this app is a bit hidden, I suggest creating a shortcut to it in your Dock or desktop, or by using Spotlight to launch it when needed.

Step 5 - Turn on Web Sharing

In order to access your web apps from your local machine without having to upload them to a remote server, you will need to enable Apple's Web Sharing in System Preferences -> Sharing. This turns on the built-in Apache web server that ship with every Mac.

Step 6 - Load up Your App

Now that you have a working iPhone simulator and a web server on your computer, you are free to access your apps from the simulator. First make sure that your iPhone is on the same WiFi network as your computer, then simply launch Mobile Safari and navigate to http://localhost/~your_mac_user_name. This address corresponds to the folder /Users/your_mac_user_name/Sites on your hard drive, so this is where your apps will need to live. There are ways to change that, but I'll leave that for another how-to.

So you built a website. The design is beautiful, the content is filled in, and it has been submitted to all of the major search engines. Maybe you have even purchased a bit of ad space on Google or another PPC network. So why is no one visiting your site? Turns out that there's a lot more that goes into bringing visitors to your site (and keeping them there) than what many people initially realize.

The concept of findability, an umbrella term that encompasses the techniques and methods one can use for driving traffic to a site and making the content easy to navigate, is often overlooked in the design and development process. However it is important to remember that in addition to attracting visitors in the first place one must also give visitors a reason to stick around and eventually come back. This all directly affects a project's bottom line in that the more findable one's content is, the more like it is that conversions will be made and that the project will succeed.

Content

Whether you are selling a product, collecting donations, or supporting a cause, fresh and relevant content is key when trying to attract new visitors. Not only will this please the search engine gods each time they reindex, but it will encourage visitors to keep coming back and to spread the word about the site.

Ideally page content should be keyword rich in order to maximize SEO. Be careful though, as most search engines will look for patterns in keyword placement in an attempt to detect keyword spamming, a black hat SEO technique that could quickly get you blacklisted.

Information Architecture and Usability

Having good content probably won't help too much if visitors are unable to find it on your site. This is where information architecture comes in. IA is the practice of organizing functionality and content into an intuitive structure that allows users to easily find desired content. This could refer to the ease of navigation of a site, the presentation of its content, and also the way that relationships between entities are represented.

If your IA is solid, most users probably won't even notice it. The goal is to create a seamless browsing experience that instills users with a sense of confidence that they are finding what they are looking for.

Measuring the usability of a site can be difficult, but there are many tools available today that can help with analyzing visitor behavior and usage patterns. Services like CrazyEgg and Google Website Optimizer allow site owners to monitor findability problems and to identify what content is the most important.

Design

The way that graphical elements and text content are laid out and organized on a page is an important concern when designing a site and goes far beyond just having a "pretty" design. A talented graphic designer will be able to direct visitors' eyes to various elements along a strategic path in order to effectively communicate a message or a highlight a call to action.

Drawing attention to search boxes, RSS feeds, newsletter subscriptions, etc is a critical way to help users find what they are looking for and to discover new content down the road. This will help gain returning visits and will encourage visitors to spread the word.

Markup and Accessibility

It might not seem obvious, but the quality of HTML markup can be important for findability as well. Helping define the importance of the content of a page through the use of standards-compliant, semantic markup makes it much easier for search engines to accurately parse and rank content. By defining the semantic information hierarchy of a page, one can minimize search engine guess-work.

Building pages to be usable by those with disabilities is an important part of the development process on its own, but also helps with findability by easing search engine indexing. This also give you the option for strategic use of keywords in places like image alt tags, which are also crawled.