Posts Present & Past

Formula for Styling Web Forms

04/29/2010

Web forms are ubiquitous, and in my line of work I find myself building plenty of them, each time from scratch. That’s why I’ve recently put together a little style sheet to serve as a starting point for styling my HTML forms that includes the selectors and styles I find myself using most often. Take a look at the demo page for formula.css.

Software for Web Development

04/05/2010

Application icons in the Dock For the most part, I design and develop on Mac OS X and Unix. I thought I might give out a few tips on building your own arsenal of Mac software for Web development.

Apache HTTP Server 2

As noted in a previous post, I use Apache, which comes bundled with Mac OS X, to develop locally. That way, I can write dynamic pages and preview them without uploading anything to an external development server or the production server. In order to do so, I usually set up virtual hosts for each site I am working on:

VirtualHostX

VirtualHostX is a free application that offers a GUI for editing the Apache virtual hosts configuration file. You can pay to unlock the application if you need more than three virtual hosts configured at one time (which I haven’t as of yet).

Sequel Pro

Sequel Pro provides a clean, Apple-style GUI for managing MySQL databases. You can create, drop, and modify databases and tables, create stored procedures and functions, and easily build and test queries in the query editor. The only major functionality that is missing is user management. I’m still relying on MySQL’s command line utility for setting up database permissions. The Sequel Pro website promises these features in the next major release, though I don’t see any sign of further development online, and I have not seen a software update in a while. Update (4/6/10): see first comment.

Coda

For almost everything else, I use Coda. Coda is, as far as I am concerned, the ideal editor and FTP client. Each project you work on can be saved with stored FTP and/or SSH connection details and code snippets. The editor is very flexible with syntax highlighting for many markup and programming languages and extensible via third-party plugins. The application also features a GUI CSS editor, which I have never used, opting instead to hand code my style sheets. You can easily switch from code view to a preview of your document in Webkit and any Web browser you have installed. The list of features goes on, but they are all laid out on Panic’s website. Despite the long list of features, the software does not feel in the least bit bloated. The interface is clean and stays true in every detail to the OS, and I have never run into a bug.

Billings 3

For the business side of my work, I use Billings to keep my projects organized, track my hours, and or course, bill for my time. Billings lets you keep it simple or keep very detailed records. I like erring on the side of logging too much information during the course of my jobs, which allows me to generate fairly detailed invoices with minimal effort when the time comes. The interface is mostly to my liking, though several features that should be front and center (such as project notes) seem to be buried in odd places. I have run into some bugs, but for the most part they are fixed in frequent software updates, and unfortunately, I have also seen a bug introduced in an update. Overall, Billings’ utility outweighs its annoyances.

Do you have anything to add about these applications? Have you found better software for the job? I’d like to hear about it.

Like Bells’ Palma

04/03/2010

I recently saw Like Bells on tour at The Loft at Tommy Doyle’s in Cambridge, Massachusetts. Like Bells is a progressive post-rock band featuring cymbal-heavy percussion, violin, guitar, bass and sparse electronic accompaniment. Their energetic performance featured new material from their second and latest album, Palma, yet to be officially released. It is a departure from their debut album in that it tends toward being more upbeat and utilizes vocals to a higher degree, though they remain sparse. Check them out at www.likebells.com and www.myspace.com/likebells.

Virtual Hosts in Apache

09/16/2009

I usually find it convenient to develop my websites and Web applications locally before pushing them to the production server. Mac OS X conveniently comes with the Apache Web server pre-installed. In fact, all you really need to do to start using it is to check the “Web Sharing” checkbox in System Preferences… > Sharing. You can then use your Web browser to navigate to http://localhost/, and you should see whatever files are in your Web root. The default Web root (root directory from which Apache serves files) is /Library/WebServer/Documents on Mac OS X. However, it’s useful, especially if you are working on more than one project at a time, to be able to host multiple sites on your Mac. To do this, you need to set up virtual hosts in Apache. Here is a step-by-step tutorial on setting up virtual hosts:

  1. Open the file /private/etc/hosts, and add one line for each virtual host you want like so:

    127.0.0.1	newhostname
    127.0.0.1	othernewhostname

    The IP listed should always be 127.0.0.1, and the name of the host can obviously be whatever you choose.

  2. Open your Apache configuration file (/private/etc/apache2/httpd.conf on Mac OS X Leopard), and add these lines if not already present (you can add them at the end of the file):

    NameVirtualHost *:80
    Include /private/etc/apache2/extra/httpd-vhosts.conf

    The Include directive tells Apache to look in a separate configuration file for virtual hosts, which makes it easier to manage. Make sure you use the path that corresponds to your installation of Apache. The path listed above corresponds to Leopard.

  3. Open the configuration file (you may have to create it, if it doesn’t exist already) that you pointed to in the main httpd.conf file, and add the following for each new host name you specified in hosts above:

    <VirtualHost *:80>
    	ServerName newhostname
    	DocumentRoot /path/to/root
    </VirtualHost>
  4. Restart Apache. The easiest way to do this on a Mac is to go to System Preferences… > Sharing and uncheck “Web Sharing”, then check it again. You should then be able to use your browser to navigate to http://newhostname/.

This was just an overview. For more detailed information on setting up virtual hosts, see: Apache Virtual Host documentation.

A very easy way to manage virtual hosts on Mac OS X is through a handy application called VirtualHostX, which is free, except that it limits you to three hosts. You can register it for a small fee to remove this restriction.

CSS Good Practices

08/28/2009

In any sort of collaborative context, especially when it comes to code and the Web, following a standard is important. As such, in order that my CSS files are descriptive and legible to others as well as to myself, I follow a set of conventions in each new document that I create.

Note that while some Web developers prefer to rely on their development software to format their style sheets, I do all this by hand (i.e., I type the code directly as opposed to manipulating it through a GUI).

Filename

The first thing to consider is naming your style sheet appropriately. I always name my main style sheet baseline.css, because it serves as the style sheet from which I can build more specialized styles (e.g., a print version of the site). Where I need a style sheet for a particular media type such as print or projection, I use the name of the medium, giving us print.css and projection.css respectively. More often than not, I also want to include a separate style sheet for Internet Explorer that I serve through conditional comments. I name this file ie.css, or if I’m targeting a particular version, I include the version number (e.g., ie6.css).

The Header

At the top of every style sheet that I create, I make sure to describe the file’s context. I use a template that I keep whenever I start a new CSS file:

/*
author: [my name and URL]
project: [the URL of the site I'm working on]
scope: [where the style sheet applies (usually "site-wide")]
*/

You can get as detailed as you see fit for the scale and needs of the project you are working on. For instance, I might want to denote a version number with version: 1.2. What I’ve included above is the bare minimum.

Aside from being useful to others working on the same project or someone simply taking a look at your source, I find this information invaluable when, for example, I’m looking through a bunch of files on my computer called baseline.css and I need to find the one that corresponds to example.com. In general, the more documentation you provide with your code, the better.

Structure

Especially on bigger projects, keeping the body of your style sheet organized is a must. I always break the body down into sections and I employ easy-to-see headings to mark each section I make. Here is the style I use, but of course, the format is up to you:

/* THIS IS A HEADING
***************************************************/

As for what I find useful in terms of making divisions, it depends somewhat on the project, but I usually have at very least the following sections:

  1. ELEMENT DEFAULTS
  2. LAYOUT LOGIC
  3. PAGE-SPECIFIC

Item (1) is where I put all of the rules for plain old HTML elements such as p {...}. Item (2) describes the way that pages are laid out. This section contains rules pertaining to structural elements that are common to multiple pages. Item (3) contains rules pertaining to the content of specific pages. I like to keep this separate in order to avoid clutter in the rest of the style sheet. For the most part, the sections move from more general rules to more specific ones. On larger projects where I divide the body of my style sheet into many sections, I even include a table of contents.

Rules

The following is an example of a rule with only one property. I like to keep these on one line:

p { line-height: 1.5em; }

When I have a rule where I’m setting multiple properties, I break it up over separate lines:

p {
	line-height: 1.5em;
	font-style: italic;
	}

Note that the only part not indented is the selector, so that you can easily scan the document with your eyes for a particular element or class in the same way that bibliographies are indented so that you can scan the left margin for an author. Where I am grouping multiple selectors, I like to keep them on separate lines for this purpose:

p,
li { line-height: 1.5em; }

Note also that I always include the semicolon following the last declaration in my rule, so that if I add a new declaration, I don’t need to worry about what’s already there.

This particular format is just a suggestion. Your own style may vary according to your preferences as long as it is legible and consistent.