Bill Lovett

I started out with Prototype, then switched to JQuery, then settled on YUI.

Prototype was an early choice because it offered a lot of Ajax functionality and there was good-enough documentation available. I switched to JQuery based the allure of a smaller file, selectors, and compact syntax.

After using JQuery on a few projects, I started to dislike some of its efficiencies. It felt less like JavaScript and more like a JavaScript-like DSL, one that took a bit of mental readjustment if you'd been away from it for a few days. There were fewer JQuery widgets available at that point than there are now, and they were third-party efforts. Putting all the pieces together and finding good documentation took some effort.

I took notice of the YUI framework after watching Doug Crockford's JavaScript lectures at Yahoo!. It was comprehensive, had a good collection of widgets, and strong documentation. More generally, I liked what Yahoo! was doing with their Developer Network overall. YUI quickly became the best option for me to build what I needed to build without distraction.

Alphabetically, clustered by element, id, and class selectors. This keeps selectors with a common cascade in close proximity to one another without making it hard to keep track of where you are in the file.

I don't like using one stylesheet for typography, another for color, another for positioning, et cetera. I just use one file. CSS is fragile enough without getting tripped up in which file things are supposed to go in. I also dislike elaborate cascades, because you end up throwing down an !important at every turn.

Incrementally, going from the outside inward and from the top of the page downward.

It's rare to have a strain of markup lead you to a totally unworkable dead end. With enough time and determination, almost anything can be made to look and work properly, more or less. But keeping the markup to a bare minimum takes a little more discretion, and working in small steps punctuated by a round of browser refreshes helps you know when you've fallen off track. That way, when the document is complete there's no doubt whether it will or won't behave correctly.

Borders and background colors for everyone, the more gaudy the better.

Web page markup is all about boxes, and layout problems often just a matter of the browser having an unexpected notion of where a box sits and how big it is. A visible border usually cuts right to the discrepancy, and for those situations where borders throw off a pixel-precise design a background color can do just as well.

I aim for XHTML Strict compliance. I'm more concerned with getting the thumbs up from the W3C Validator than I am with the esoterics of why XHTML without a suitable MIME type is pointless, or why XHTML was (or wasn't) an appropriate next step from HTML 4. Consistency here means less risk of getting caught off guard by doctype switching. Beyond that, it's mostly academic.

A site's favicon usually gets short shrift, presumably because they can be hard to get right. Smart quotes also tend to get skipped, which is similarly unfortunate.

Meta descriptions are the primary oversight. A page without a meta description is more likely to display in search results with a less-than-ideal summary snippet, or possibly no snippet at all. So even though your website looks great, a potential point of first contact ends up being less effective than it should be.

I pour as much content as is appropriate from the Flash site into the parent HTML page, then style it out of the viewable. This gives the search engine spiders something better to read than a blank page. A multi-page Flash site contained within a single HTML page isn't an ideal scenario in the first place, but you can still make the best of a bad situation.

When applied to headlines, it can be a great solution that saves all sorts of time on image production. But when you're trying for exact fidelity with a designer's comp, it can be a bit too complicated. I'd just as soon forego all the font sizing calculations that sIFR does in favor of a less flexible Flash file that needs less fiddling to look right, or a CSS background image sprite.

Into namespaced modules, similar to how the YUI framework does it. It helps keep things logically organized. For example:

        var ILOVETT = function() { return {} }();

        YAHOO.util.Event.onDOMReady(function() {
            ILOVETT.externals.init();
        });

        ILOVETT.externals = function() {
            return {
                init: function() {
                ... 
                }
            }
        }();
      

I use swfobject rather than the markup that Flash emits, because swfobject makes it easy to provide substitute content.

Through conversations with the designer during the design process. When that's not possible, by keeping a close eye on the level of indentation in the HTML: the more deeply nested the markup, the more likely things have gotten too complicated for their own good.

Sometimes you just need a lot of divs to make a layout work. It's not the end of the world, it just means you need to be intimately familiar with how everything fits together, and what each div is contributing to the effort. A little documentation goes a long way here.

I've done projects with CakePHP, Symfony, and CodeIgniter. I standardized on the latter, because it was the easiest to pick up, was fully featured, had good documentation, and took care of a lot of minutiae without being overly demanding about how I structured my project and database. Most of all, I like the way that CodeIgniter's ORM is wholly optional. You can write your complex queries directly, or use the framework's Active Record implementation at your discretion.

I've used portions of the Zend Framework as well, but not its MVC classes. Especially with regards to the View layer, they seemed more complicated than what was already working out in spades for me with CodeIgniter.

I use Perl for crawling, scraping, and the random import/export chores that sometimes come up during a project. I use Bash scripts for deployment and packaging.

Yes. The databases I work with are most often geared toward content management, so their schemas not usually epic. I consider that a good thing.

I got started with MySQL 3, but I've also worked with Postgres and SQLite.

Using rsync. I looked into Capistrano at one point after having been introduced to it during a Rails project, but didn't find it to be natural fit for non-Rails projects. I like the greater level of control I have driving rsync from a Bash script.

I use Subversion, but recently switched to Git. I like Git's speed, and the fact that it keeps all its files under one subdirectory at the root of your project. The distributed aspect isn't that big a deal to me, but I do like the way a project can be comprised of submodules from other repositories.

Emacs. Peruse my .emacs file if you wish.

OS X.

Yes. I spend a lot of time there.