rossboardman.com » Code

Chrome vs. Firefox vs. Safari vs. IE vs. Opera Speed Tests

rossboardman — Fri, 24 Oct 2008 19:42:10 +0000

Browser Speed Tests: The Compiled, Up-to-Date Results -Back when Firefox 3’s final release candidate dropped, we ran some tests to compare its page-loading, memory use, and technical timing to Internet Explorer 7, Opera, and Safari for Windows. Then Google Chrome arrived, so we pit it against the betas for Firefox 3.1 and Internet Explorer 8, and shared the results. The tests were by and large the same, but many commenters wisely asked to see all the results, betas or no betas. Well, today we’ve patched together all our data, thrown in a fresh test of the Opera 9.6 beta, and we’re sharing all the graphy goodness. Read on to see a full comparison of the major browsers you can load on Windows.
The tests

You can read up on our testing methods in their entirety at the original testing feature. I’ve come to realize, however, that between all three rounds of testing involved, the “8-page load” test may be the most vulnerable to variables—some of the pages included are quite dynamic, so if, say, Gizmodo puts up a large number of videos or huge pictures, it could affect the total loading time. Other than that, though, the page-loading tests are run by a human watching a timer, the JavaScript from Sean Patrick Kane’s web test, the CSS from a downloadable form, and memory use from checking Windows Vista’s Task Manager.

Test 1: Page Loading—Winner: Opera (9.5)!

No surprise that Opera 9.6’s beta performed just as well as the official release, on start-ups both both cold (right after boot-up) and warm (having launched at least once). I’m heartened to see comparable results between the first batch of browsers I tested and their newer betas.

The next speed test, loading eight pages from a bookmark folder, left me scratching my head. Why did the newer betas take so much longer to load a similar set of pages? As stated above, my best guess is the dynamic nature of at least one page in the group, but Opera was tested separately from the other betas, and didn’t gain much in speed.

Test 2: JavaScript & CSS—Winner: Safari! (by a nose)

It’s hard to beat Safari’s performance in both Cascading Style Sheets and the JavaScript code that fronts so many webapps. It has to be noted, however, that most browsers, other than Internet Explorer, don’t out-run one another by a huge stretch in JavaScript; Chrome and Safari, though, pull ahead on CSS.

Test 3: Memory Use—Winner: Firefox!

It’s reassuring that Mozilla puts so much effort into memory usage in Firefox 3 releases—seeing as how most readers of this site are more than open to extension suggestions.

So that’s all the testing data we have on the latest web browsers here at Lifehacker Labs. Got another set of test results you put faith in? Surprised at any of our outcomes? Tell us about it in the comments.

Are Freelance Developers a Recipe for Poor Software?

rossboardman — Sat, 03 May 2008 03:54:36 +0000

I recently read the Fast Company article, They Write the Right Stuff, and instantly began thinking of my situation as a freelance developer and what that ultimately means to my clients.

The article talks about NASA and the quality control that goes into the software that drives the shuttle. It's fascinating and impressive stuff.

“Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors.”

I could only dream of such a rate of errors. Of course, the stuff I build isn't as mission critical as taking a hunk of metal with a bunch of people on board and throwing it into space but the four key things that they attribute to success is just as relevant.

1. Planning

At NASA, about one-third of the process is spent on planning. They develop requirements almost to the level of pseudo-code. It's very precise in detailing what the application must do and under what circumstances.

In my development work, I've always believed in the planning process. I'd say I even have a knack for being able to visualize an application before it has even been built. Like a sculptor chipping away at a piece of rock, I have a sense of what is needed. I just have to bring it out in the code. But is my vision the same as what the client wants or needs? That's what the planning process is for.

I like to develop flowcharts showing major pages of an application, and develop the data model, so I know what information needs to be captured. Better yet, would be developing a more thorough analysis of each page and what functionality is expected. I've done this on projects past but don't do it as often as a freelance developer.

As a freelance developer, it may even seem less necessary to document every minutae of a project when you're the only one working on it. However, having documentation is important as it sets client expectations. It also helps avoid feature creep as you have something to refer to as a baseline and can stipulate that changes to the requirements cost extra.

2. Rivalry

Within the shuttle software group, they have two key teams: the coders, and the verifiers. They're pitted against each other in a way that ultimately produces better code.

"They're in competition for who's going to find the errors," says Keller. "Sometimes they fight like cats and dogs. The developers want to catch all their own errors. The verifiers get mad, 'Hey, give it up! You're taking away from our time to test the software!'"

I'm a self-taught developer. Everything I have learned over the years has come from just building things, reading articles on the internet, and reviewing the code of others. I have no formal learning. While this has worked well for me, for the most part, I always feel that I would've liked more people to bounce ideas off of. It's great to be able to brainstorm with other people to achieve a solution that seems the most straightforward. It would've also been nice to have a solid foundation to build on top of. What algorithms should be used, what patterns can be implemented?

As a freelance developer, there's no rivalry. Just the victory in having the client not notice where things might go wrong, or the disappointment by myself and the client when an error is found. The client is the only person who provides any independent set of eyes on what I produce.

The heart of the title is in this very specific point: with nobody to review and critique the quality of product I'm developing, is the product I'm putting out there any good? Is there a way I can restructure my code to make it faster, easier to maintain, and ultimately better for this client and the next?

This is one area where I'm particularly trying to address by hiring people to do code reviews, both for the JavaScript and CakePHP development that I do. For CakePHP, I'm looking to some of the core CakePHP developers via Debuggables and the Cake Foundation. Who better to look at the code I produce? For JavaScript, I put the call out via Twitter and received the names of a few people I can rely on when needed. (Many thanks to those who responded.)

As a freelancer, it's my responsibility to seek out others who can act as my rivaly and do so in a way that makes me strive to create better code.

3. History

There are two large databases at the shuttle software team: one that records the history of every change ever made to the application and another that logs every single error found in the application.

Any development, large or small, should have two key pieces of software at their disposal:

Version Control: There are a few different tools and it comes down to using what you feel comfortable with. Look into CVS, Subversion, or Git for more information.
Bug Tracking: There are plenty of bug tracking tools such as Trac, Bugzilla, and Fogbugz.

I have to admit to being lax on both of these points. I'm hit or miss when it comes to setting up a new Subversion repository for a new project and bug tracking is often left to collecting client emails into a to-do list. A more formal process would be good to establish on any project that I develop. Which leads into the fourth and final point...

4. Process

Don't just fix the mistakes -- fix whatever permitted the mistake in the first place.

The key to success isn't the lack of mistakes; mistakes are bound to happen. How you deal with clients, how you code, whatever it is that you do in your professional career or even in your personal life is a learning experience. It's important to learn from the mistakes and make sure that a process is put in place to avoid the problem from happening again.

If it hasn't been evident throughout this post, I'm still changing my process and will continue to change my process to become a better developer. If there's one thing I've learned about freelance, it's that it is a journey deep into personal discovery.

Do you re-examine your process on a regular basis? Do you have the ability to see where things are working and where they're not? Take the time to review things and change the process.

Improving Code Readability With CSS Styleguides

rossboardman — Fri, 02 May 2008 14:40:22 +0000

A great article, once again from Smashing Magazine: Once your latest project is finished, you are very likely to forget the structure of the project’s layout, with all its numerous classes, color schemes and type setting. To understand your code years after you’ve written it you need to make use of sensible code structuring. The latter can dramatically reduce complexity, improve code management and consequently simplify maintainability. However, how can you achieve sensible structuring? Well, there are a number of options. For instance, you can make use of comments — after all, there is always some area for useful hints, notes and, well, comments you can use afterwards, after the project has been deployed. Indeed, developers came up with quite creative ways to use comments and text formatting to improve the maintainability of CSS-code. Such creative ways are usually combined into CSS styleguides — pieces of CSS-code which are supposed to provide developers with useful insights into the structure of the code and background information related to it. This article presents 5 coding techniques which can dramatically improve management and simplify maintainability of your code. You can apply them to CSS, but also to any other stylesheet or programming language you are using. You can browse through the references listed under the article — they containt further information about how you can achieve a well-organized and well-structured code. You may also be interested in the articles

1. Divide and conquer your code

First consider the structure of your layout and identify the most important modules in your CSS-code. In most cases it’s useful to choose the order of CSS-selectors according to the order of divisors (div’s) and classes in your layout. Before starting coding, group common elements in separate sections and title each group. For instance, you can select Global Styles (body, paragraphs, lists, etc), Layout, Headings, Text Styles, Navigation, Forms, Comments and Extras. To clearly separate fragments of code, select appropriate flags or striking comments (the more *-symbols you have in your code, the more striking a heading is). In the stylesheet they will serve as a heading for each group. Before applying a preferred flag to your code, make sure you can immediately recognize single blocks when scanning through the code. However, this approach might not be enough for large projects where a single module is too big. If it is the case, you might need to divide your code in multiple files to maintain overview of single groups of code fragments. In such situations master stylesheet is used to import groups. Using master-stylesheet you generate some unnecessary server requests, but the approach produces a clean and elegant code which is easy to reuse, easy to understand and also easy to maintain. And you also need to include only the master-file in your documents.

/*------------------------------------------------------------------
[Master Stylesheet] 

Project:	Smashing Magazine
Version:	1.1
Last change:	05/02/08 [fixed Float bug, vf]
Assigned to:	Vitaly Friedman (vf), Sven Lennartz (sl)
Primary use:	Magazine
-------------------------------------------------------------------*/
@import "reset.css";
@import "layout.css";
@import "colors.css";
@import "typography.css";
@import "flash.css";
/* @import "debugging.css"; */

For large projects or large development team it is also useful to have a brief update log and some additional information about the project — e.g. you can put the information about who is this CSS-file assigned to and what is its primary use (e.g. Smashing Magazine, Smashing Jobs etc.). Additionally, you can include a debugging CSS-code to take care of diagnostic styling in case you run in some problems. Consider using Eric Meyer’s Diagnostic Styling as a debugging stylesheet to test your CSS-code and fix problems.

2. Define a table of contents

To keep an overview of the structure of your code, you might want to consider defining a table of contents in the beginning of your CSS-files. One possibility of integrating a table of contents is to display a tree overview of your layout with IDs and classes used in each branch of the tree. You may want to use some keywords such as header-section or content-group to be able to jump to specific code immediately. You may also select some important elements you are likely to change frequently — after the project is released. These classes and IDs may also appear in your table of contents, so once you’ll need to find them you’ll find them immediately — without scanning your whole code or remembering what class or ID you once used.

/*------------------------------------------------------------------
[Layout] 

* body
 + Header / #header
 + Content / #content
 	- Left column / #leftcolumn
 	- Right column / #rightcolumn
 	- Sidebar / #sidebar
 		- RSS / #rss
 		- Search / #search
 		- Boxes / .box
 		- Sideblog / #sideblog
 + Footer / #footer

Navigation	  #navbar
Advertisements	  .ads
Content header	  h2
——————————————————————-*/

…or like this:

/*------------------------------------------------------------------
[Table of contents] 

1. Body
 2. Header / #header
 	2.1. Navigation / #navbar
 3. Content / #content
 	3.1. Left column / #leftcolumn
 	3.2. Right column / #rightcolumn
 	3.3. Sidebar / #sidebar
 		3.3.1. RSS / #rss
 		3.3.2. Search / #search
 		3.3.3. Boxes / .box
 		3.3.4. Sideblog / #sideblog
 		3.3.5. Advertisements / .ads
 4. Footer / #footer
-------------------------------------------------------------------*/

Another approach is to use simple enumeration without indentation. In the exampe below, once you need to jump to the RSS-section you simply use a search tool to find 8. RSS in your code. That’s easy, quick and effective.

/*------------------------------------------------------------------
[Table of contents] 

1. Body
2. Header / #header
3. Navigation / #navbar
4. Content / #content
5. Left column / #leftcolumn
6. Right column / #rightcolumn
7. Sidebar / #sidebar
8. RSS / #rss
9. Search / #search
10. Boxes / .box
11. Sideblog / #sideblog
12. Advertisements / .ads
13. Footer / #footer
-------------------------------------------------------------------*/

/*------------------------------------------------------------------
[8. RSS / #rss]
*/
#rss { ... }
#rss img { ... }

Defining a table of contents you make it particularly easier for other people to read and understand your code. For large projects you may also print it out and have it in front of you when reading the code. When working in team, this advantage shouldn’t be underestimated. It can save a lot of time — for you and your colleagues.

3. Define your colors and typography

Since we don’t have CSS constants yet, we need to figure out some way to get a quick reference of “variables” we are using. In web development colors and typography can often be considered as “constants” — fixed values that are used throughout the code multiple times. As Rachel Andrew states, “one way to get round the lack of constants in CSS is to create some definitions at the top of your CSS file in comments, to define constants. A common use for this is to create a color glossary. This means that you have a quick reference to the colors used in the site to avoid using alternates by mistake and, if you need to change the colors, you have a quick list to go down and do a search and replace.”

/*------------------------------------------------------------------
# [Color codes] 

# Dark grey (text): #333333
# Dark Blue (headings, links) #000066
# Mid Blue (header) #333399
# Light blue (top navigation) #CCCCFF
# Mid grey: #666666
# */

Alternatively, you can also describe color codes used in your layout. For a given color, you can display sections of your site which are using this color. Or vice versa — for a given design element you can describe the colors which are used there.

/*------------------------------------------------------------------
[Color codes] 

Background:	#ffffff (white)
Content:	#1e1e1e (light black)
Header h1:	#9caa3b (green)
Header h2:	#ee4117 (red)
Footer:		#b5cede (dark black)

a (standard):	#0040b6 (dark blue)
a (visited):	#5999de (light blue)
a (active):	#cc0000 (pink)
-------------------------------------------------------------------*/

The same holds for typography. You can also add some important notes to understand the “system” behind your definitions.

/*------------------------------------------------------------------
[Typography] 

Body copy:		1.2em/1.6em Verdana, Helvetica, Arial, Geneva, sans-serif;
Headers:		2.7em/1.3em Helvetica, Arial, "Lucida Sans Unicode", Verdana, sans-serif;
Input, textarea:	1.1em Helvetica, Verdana, Geneva, Arial, sans-serif;
Sidebar heading:	1.5em Helvetica, Trebuchet MS, Arial, sans-serif;

Notes:	decreasing heading by 0.4em with every subsequent heading level
-------------------------------------------------------------------*/

4. Order CSS properties

When writing the code often it’s useful to apply some special formatting to order CSS properties — to make the code more readable, more structured and therefore more intuitive. There is a variety of grouping schemes developers use in their projects. Some developers tend to put colors and fonts first; other developers prefer to put “more important” assignments such as those related to positioning and floats first. Similarly, elements are also often sorted according to the topology of the site and the structure of the layout. This approach can be applied to CSS selectors as well:

    body,
 h1, h2, h3,
 p, ul, li,
 form {
 	border: 0;
 	margin: 0;
 	padding: 0;
 }

Some developers use a more interesting approach — they group properties in an alphabetical order. Here it’s important to mention that alphabetizing CSS properties may lead to some problems in some browsers. You may need to make sure that no changes are produced as a result of your ordering manipulations.

body {
 background: #fdfdfd;
 color: #333;
 font-size: 1em;
 line-height: 1.4;
 margin: 0;
 padding: 0;
}

Whatever grouping format you are using, make sure you clearly define the format and the objective you want to achieve. Your colleagues will thank you for your efforts. And you’ll thank them for sticking to your format.

5. Indentation is your friend!

For better overview of your code you might consider using one-liners for brief fragments of code. This style might produce messy results if you define more than 3 attributes for a given selector. However, used moderately, you can highlight dependencies between all elements of the same class. This technique will dramatically increase code readability when you have to find some specific element in your stylesheet.

#main-column { display: inline; float: left; width: 30em; }
 	#main-column h1 { font-family: Georgia, "Times New Roman", Times, serif; margin-bottom: 20px; }
 	#main-column p { color: #333; }

You remember exactly what you did and can jump back in there and fix it. But what if you made a lot of changes that day, or you just simply can’t remember? Chris Coyier suggests an interesting solution for highlighting recent changes in your CSS-code. Simply indenting new or changed lines in your CSS you can make recent changes in your code more visible. You can as well use some comments keywords (e.g. @new) — you’ll be able to jump to the occurrences of the keyword and undo changes once you’ve found some problems.

#sidebar ul li a {
     display: block;
     background-color: #ccc;
          border-bottom: 1px solid #999; /* @new */
     margin: 3px 0 3px 0;
          padding: 3px; /* @new */
}

Conclusion

CSS styleguides are helpful if and only if they are used properly. Keep in mind that you should remove every styleguide which doesn’t effectively help you to get a better understanding of the code or achieve a well-structured code. Avoid too many styleguides for too many elements bundled in too many groups. Your goal is to achieve a readable and maintainable code. Stick to it and you’ll save yourself a lot of trouble.

Regarding Backups

rossboardman — Tue, 29 Apr 2008 04:00:00 +0000

Now that I have a baby, I’m taking a lot more pictures and recording a lot more video than I ever have before. And as you can imagine, I’d hate to lose any of it. So I spent some time over the last few months researching backup options for Mac OS X. I’ve read many articles and reviews, talked with a number of colleagues (including some who write backup software and others who run datacenters), and checked out lots of software and gear (software like Time Machine, SuperDuper!, and Carbon Copy Cloner, external hard drives like those made by Seagate, LaCie, Western Digital, and also “smart” hardware like the ones made by Iomega, ReadyNAS, and Drobo).

Past Lives

I take file backups and redundancy seriously. You might think it’s because, in a past life, I was a systems and network engineer for an aerospace company, in charge of the backups for all of our corporate data, everything from payroll and HR to user-created files. Nobody ever forgets those middle-of-the-night visits to the server room, bleary-eyed, standing at the VT220 hard-wired console, using commands like dumpfs and restore, working through stack after stack of tapes from the fire-safe, so the VP of Something can get that file he deleted last week (or was it last month?), for that meeting in whatever town tomorrow morning. But it started further back in time, when I was in my very early teens. I had a Commodore 64, and was using the GEOS operating system) and geoWrite, one of the very first WYSIWYG text editors, to create a paper for school. I’d saved up enough to add a 5¼" floppy drive, and although saving files was much faster than when the cassette tape, it was still slow, and generally I didn’t save very often, except, when I was taking a break or done for the time being. If you have good file-saving practices, you’re probably shaking your head right now, but remember, I was about 10 or 11 years old at the time and I’d never lost a whole day of work before, especially not the day before it was due. So when the printer jammed and GEOS crashed and I lost most of everything I’d typed up, I was actually a bit surprised. Until that time, I’d always thought of computers and their hardware as being completely reliable. Ever since then, I’ve been very careful to keep multiple copies of my work. In the old days, that just meant buying a second floppy disk (my entire allowance). Today, it’s not quite so simple. The choices we have both in software and hardware can be overwhelming.

The Short Answer

I’m now relying primarily on a combination of a Drobo, Subversion, automatic .Mac syncing, and occasional drive-cloning. Keep reading for the details.

The Data

As with most aspects of my life, my goal is to simplify. The fewer tools, applications, and devices I need, the better. In the past, I used to backup everything, but now, although I do backup my entire system, I’m mainly interested in a backup of what I consider to be critical data. This includes:

Code and Writing
Bookmarks, Address Book, Serials, and Passwords
Mail
Photos
Video
Music
Other Stuff

What about the applications themselves? What about preferences? What about system-specific settings? Those are all handled by the system level backup/clone. But you know what? After many years of preserving those files, I’ve found that when it comes to actually restoring my machine or setting up a new one, I rarely took those things along with me, preferring to install only what I needed as I needed it. I’ve really been able to keep a minimalist setup in the process, shedding things here and there as I move from system to system. Still, it’s nice to know they’re there when I need them. I’ve found that a multi-pronged approach works best for me, and I use a few different technologies to make it all work. Reading this, you might think I’m a bit retentive when it comes to data redundancy. And you’re probably correct … but then again, I’ve seen many drives fail in my time, and lots of data get lost. I just don’t want to take that chance with the stuff that matters.

Code and Writing

All of my code lives in a Subversion repository which is offsite and fully backed up, and I always have a relatively local copy ready to go, should something odd happen to the repository. The merits of using a revision control system are many, and well beyond the scope of this article, but if you’re not using something like Subversion, Git, or heck, even CVS, you really should be. Another nice benefit to keeping code and writing in a repository, aside from the revision history, is that you automatically have an easy path to synchronized data on any machine you use.

Bookmarks, Address Book, Serial Numbers, and Passwords

I use .Mac to sync data between my Mac Pro and my Macbook, and .Mac keeps these things backed up in the process. It’s true that .Mac is a bit expensive, and this data is backed up elsewhere (see below), but I’m hoping that one day, Apple will do something really amazing with .Mac and I’ll be glad I’m signed up for it. I use Yojimbo, from Bare Bones, to manage all of my serial numbers and passwords. It’s a great utility, and it can even use .Mac to sync (and therefore backup) your data.

Mail

Get a nice, reliable host like Mailtrust (formerly Webmail.us), and store your mail there in IMAP folders. They keep good backups, and you can go from machine to machine and everything will be right where you left it. Unfortunately, Mailtrust has recently recently raised their prices, so you might want to check out Google Apps for a free (but possibly less robust) solution. The main thing is IMAP folders and a company that backs things up reliably. Intermittently, I will copy the contents of the important IMAP folders to my local system within Mail.app, as further redundancy, but that’s probably overkill.

System Cloning

Although I’m doing this much less than I used to (see The Solution below), I sometimes still like to make a complete clone of my system every once in a while using SuperDuper! and a Seagate FreeAgent Pro external hard drive. Many people use SuperDuper! clones as their primary form of backup, as I did for a long time. I love the idea that at any moment, I have a full clone of my system ready to roll in case of a severe emergency. When it comes to cloning your Mac’s hard drive to a spare disk (external or internal), SuperDuper! is the best. It uses a technique called Smart Update to only update files that have changed, keeping the cloned drive identical to what’s on your Mac’s primary hard drive. What you get is a bootable clone of your hard drive, as up to date as the last time you’ve run a backup. You can take this drive, plug it in to any Mac, and boot up from it. What you’ll get is your very own system, just the way you left it, ready to roll. From there, you can continue working right where you left off. This is really useful if your primary Mac needs a repair or had a total drive failure, and if you have access to a spare machine. You can also use SuperDuper! to clone data onto a replacement Mac from a Mac booted into Target Disk Mode or from a cloned external hard drive. For people who like to preserve everything, this is often easier than setting up a new machine from scratch and can be faster than using Apple’s Migration wizard or a Time Machine restore. What you don’t get is an incremental backup, where changes to files are preserved, or files you’ve deleted are still available. This is where Time Machine comes in.

Time Machine

Apple’s Time Machine is a really nice backup solution that ships as part of Leopard. For people who don’t want to think at all about backups, Time Machine is amazing. It just works, maintaining a copy of your entire system and updating things automatically as you go. It’s even smart enough to pick up where it left off if you have a laptop and disconnect from your backup drive, too. For most people, Time Machine is all you’ll probably need. I threw an old SATA drive into one of the spare bays of my Mac Pro, and let Time Machine update it as it pleases. I don’t really need to have multiple copies of a single file, saving each revision, except for my code and writing, which are in Subversion, but I had the drive and the bay, so I figured why not? I have used it to restore a few files here and there, and it worked as I expected it to. I wouldn’t want to use Time Machine to restore my data to a new computer if I was upgrading or replacing current hardware because I’d be forced to do it a certain way, and because it seems like it might take a while. I’d still prefer a clone with SuperDuper! or a manual copy. And while Apple’s previous backup solutions were sometimes problematic, I’ve heard enough good things and positive restore stories to believe that Time Machine might just work as described. My friend Duncan tried a Time Machine restore and it seemed to work just fine. For my wife and parents, Time Machine is just right, and I can relax knowing that should something happen, they have a good way to get their data back … and I don’t need to babysit the process. I can just plug-in an external drive, let Mac OS X use it for Time Machine when it prompts, and walk away (fingers crossed).

Documents

I have a small collection of documents that I like to keep around. There isn’t much, these days, but there are a few things I wouldn’t want to lose. I rarely add to this collection of files, but I need to keep them around. If I were a designer, architect, or something like that, and I wasn’t using subversion, I bet I’d have a lot more of these.

Photos, Video, and Music

Like any modern parent, I take several hundred pictures of my new baby boy every single day. Each picture takes several megabytes of storage, and none of them, not even the poorly framed, out-of-focus ones, will ever be deleted. If you’re a parent, especially a new parent, you know what I mean. And don’t even talk about the video. What I wanted was a solution that would grow as my library grows, but it had to be simple.

The Solution

Enter the Drobo. After talking about it at length with a few friends, most notably John Gruber and Andy Ihnatko on Episode 19 of The Talk Show, I decided I’d give it a try. On the company website, the Drobo is described as “fully automated data storage that ensures your data is always protected, your capacity is unlimited and requires no special knowledge or expertise.” Sounds too good to be true, right? Well, in fact, it really is just that great. Unlike the RAID systems I’ve looked at (and forget about the dozens of RAID servers I’ve configured and built over the years) which require some degree of configuration and often come with a heavy price tag, the Drobo offers truly redundant storage and is simple to use and easy to setup. And it’s affordable. Just turn add a few drives, between two and four of them, turn it on, plug it in to your computer, and away you go. The Drobo intelligently spreads your data across all of the available drives. If a drive fails (or if you remove it), the Drobo reconfigures itself to keep your data safe. If you add a drive, your storage instantly increases. In fact, this is how you upgrade your storage capacity. It’s unlike other RAID devices because you don’t need to add drives of the same capacity. Just give the Drobo whatever drives you happen to have handy, say, a 750GB Hitachi, a 500GB Western Digital, and a 250GB Seagate, and it will use them all intelligently, giving you the most redundancy and the most space it can. And as prices on larger drives fall, you can pick one up, remove an old drive, add a new drive, and behold: an instant increase in storage space. And you can do all of this without any interruption. You can continue to work, creating, moving, or deleting files as you please as the Drobo works in the background. It’s quiet, runs cool, and although it’s USB, I can’t really tell a difference in speed when compared with the same files stored on my primary, internal drive. Maybe high-end media people doing video editing or drive-intensive media work might be able to tell, but for me, it’s just fine. It just sits on top of the Mac Pro and does its thing. I can easily connect the Drobo to any other Mac, or use the DroboShare to make the Drobo a stand-alone NAS device. So how am I using it? I’ve moved my iPhoto library, Lightroom catalog, iTunes library, and my main Documents folder to the Drobo. I suppose I could get fancy and mount the Drobo as my home folder if I wanted, but that’s not without its issues. I could probably also create aliases (or symlinks) for the folders in my home folder too. But I’m content to just leave things as they are, keep things in folders right on the Drobo, and access them directly. Reader Request: If anybody can tell me the best way to easily force iMovie 8 to store everything somewhere other than the default locations, please let me know in the comments. I’m still cloning things to my external drive once in a while, just to be on the safe side, and letting Time Machine do its thing to that internal drive. Even though I trust the Drobo, having a backup I could easily take offsite is pretty handy. Many people use the Drobo as their Time Machine drive. And it could be used as a SuperDuper! clone too. Mac OS X treats it just like a normal USB drive, and that means it’s bootable.

Final Thoughts

I’d be curious to hear about how you’re backing things up, so be sure to leave some comments and share your thoughts and experiences. Truth be told, as much as I really do trust the Drobo and my other drives, there’s still a part of me that wants to create DVD copies of everything for storage in an ETL Verified 1-hour fire protection (up to 1700°F), waterproof safe. I’ll be sure to let you know how that goes.

No CSS Reset

rossboardman — Thu, 17 Apr 2008 07:15:36 +0000

When asked recently about using a CSS reset stylesheet, I readily admitted that I don't use them. I don't use them for my blog or for any project that I work on. Admitting such can raise an eyebrow or two. Reset stylesheets are definitely becoming commonplace — as you'd expect with companies like Yahoo and industry leaders like Eric Meyer actively using them.

So, why haven't I jumped on board?

What is a CSS Reset?

In case you've never heard of such a thing, a CSS Reset is designed to set a number of element styles to a specific baseline that creates consistency across various browsers.

In the beginning

When the idea of a reset style was first introduced, it was very basic. It reset the margin and padding for all elements. The problem with that was it caused havoc with elements that didn't want their margins or padding reset (namely, form elements).

* { margin:0; padding:0; }

From there, people worked on adding to and fine-tuning the reset stylesheet to be more flexible and to reset more styles. The Meyer reset is probably the finest culmination of this effort.

Eric Meyer's Reset

Eric Meyer's reset took the concept of resetting margin and padding and took it to a whole new level, stripping styles from a number of elements, forcing you to think about what you wanted and add them back in. List items would no longer have bullets, headings would no longer be bolded, and most elements would be stripped of their margin and padding, along with some other changes.

Working with Nothing

The problem I've had with these resets is that I then find myself declaring much more than I ever needed to just to get browsers back to rendering things the way I want. As it turns out, I'm perfectly happy with how a number of elements render by default. I like lists to have bullets and strong elements to have bolded text.

And I'm okay if the various browsers show things slightly differently.

I'm okay if one browser displays an H1 a few pixels larger or smaller than other browsers. If one browser defaults to circle bullets and another to squares, that's usually not a problem. If it is, then I create a style that addresses that specific issue. I don't reset it back to zero and then set it again to what I really want.

One of the principles I took away from the Web Standards community was the concept that pixel perfect precision across the various rendering engines was impractical and a remnant of the table-based layouts of yesteryear. With CSS and progressive enhancement, it was okay that things might look a little different from one browser to the next because of variations in what they supported.

Building up

With that said, the idea of developing a base CSS file that defines some common styles that I often want from project to project — like turning off margin and padding for form elements — is a good idea.

We're seeing various CSS frameworks crop up such as Blueprint, YUI and 960.gs. Each breaking the system down only to build it back up again. Each starts with a reset, then adds on typography and a grid system.

Each of those still seem like more than I need, even though none are that large in size. Blueprint is the heaviest at around 13KB uncompressed but also includes lots of extras like styles for error messages and a print stylesheet.

Less is more

One of these days I'll put together my own base CSS or maybe I won't. To date, I haven't felt myself being overly repetitive in the styles that I set; and I haven't thought to myself, "oh, the hours I'd save myself if only I had a reset stylesheet."

So, while I have nothing against CSS reset stylesheets, I simply don't use them personally and I think that's okay.

Encoding filter for Java web applications

rossboardman — Tue, 15 Jan 2008 23:35:04 +0000

Encoding filter for Java web applications

(tags: charset utf-8 encoding jsp java)

What happens when test code goes in to production

rossboardman — Fri, 11 Jan 2008 23:36:10 +0000

What happens when test code goes in to production

(tags: woolworths test code prodution)

Do image maps work in HTML email?

rossboardman — Thu, 10 Jan 2008 23:33:06 +0000

Do image maps work in HTML email? - Campaign Monitor Blog

(tags: image maps html email support clients gmail hotmail)
Katrina victim sues U.S. for $3 quadrillion

(tags: katrina us sue weird)

How To: Full Text Search on SQL Server 2000

rossboardman — Wed, 09 Jan 2008 23:28:16 +0000

Full Text Search on SQL 2000 Part 2

(tags: search sql sqlserver)
CES 2008: Alienware’s Monster Wraparound Gaming Monitor

(tags: monitor wraparound dual)
jquery toggle showhide

$(’a.toggle’).click(function() { $(this).parent().next().toggle(); return false; } );

(tags: javascript jquery toggle showhide)

Interface elements for jQuery - Real examples of Interface elements

rossboardman — Mon, 07 Jan 2008 23:34:32 +0000

Interface elements for jQuery - Real examples of Interface elements

(tags: jquery javascript ajax)