The release of the iPhone OS 4.0 developer beta has a lot of people working themselves into a lather (another) over changes in the iPhone developer program agreement, which have the effect of banning applications not created using the native development tools. More specifically, cross-compiled Flash applications (among others).

I’ve got three thoughts about the changes, but they basically amount to “big effing deal.” You can talk or blog about it all you want, but I think it’s all hot air (including this post ;-), and we should all just get back to work.

The King Makes the Rules

First, it’s Apple’s platform, and just like every sovereign nation gets to make their own laws, Apple gets to make the rules for how people get to participate. If you want to create native applications and distribute through the App Store, you follow the rules. Period.

There are important, strategic, and rational reasons why Apple doesn’t want to allow a cross-platform framework like Flash to become powerful on their platform. These reasons are based on long experience with Adobe (more here), and with cross-platform frameworks for the Mac.

You may not like it, but it’s hard to argue that Apple doesn’t have the right to do as they please.

There is Already a Permitted Cross-Platform Framework

Second, any developer who wants to build a cross-platform mobile application, that works on iPhone, Android, Blackberry, etc., can do so today, using technologies that Apple doesn’t just permit, they actively support. HTML5, CSS, and JavaScript run very well on the iPhone, Android, and Palm’s webOS, and any other mobile platform of importance.

Why would any developer whine about being locked into Apple’s platform turn around and tie themselves to Adobe’s proprietary Flash platform? At least Apple is aggressively driving their platform forward, Flash performance on anything but Windows PCs has been abysmal for many years, with only a few signs of change, and only recently, under competitive threat.

Let the Market Decide

Finally, if you’re so offended by Apple’s position that you can’t just develop using open standards like HTML5, you feel the need to “punish” Apple, well… go for it. Android, Blackberry, webOS, and soon Windows Mobile 7 all have developer programs and app stores, and offer a range of alternative models for how to manage and control a mobile platform.

Instead of ranting on your blog or crying in your beer, get coding for the platform that best fits your idea of how the vendor should build and manage their ecosystem. Go be a part of their success, and prove that your preferred model works.

If you turn out to be right, you can be sure Apple will notice, and adapt. (Posting angry words on your blog, not so much.)

One of the things that drew me to evaluating and purchasing the Thesis theme for WordPress was the outstanding typography that seemed to be a part of every Thesis site I looked at.

The settings for fonts are simple to use — you choose a single typeface for each option — but behind the scenes, Thesis builds a complete “font stack,” that is, a comprehensive collection of fonts to use, sorted in order of preference. This ensures that your text will look good, no matter what fonts are installed on a viewer’s computer.

For example, when you choose Georgia for your main font, behind the scenes Thesis specifies a series of fonts that are similar to Georgia:

font-family: Georgia, 'Times New Roman', Times, serif;

The variety of typefaces offered by Thesis is somewhat limited, due to the nature of fonts on the web today; there’s only a dozen or so that are “safe” to use, because everyone has them. But recently a few services have come along, which take advantage of new features in modern web browsers to offer more variety in type. Possibly the most “mature” of these (with mature being a relative term) is TypeKit. But how do you use TypeKit with Thesis, when Thesis only allows you to choose fonts from a pre-defined list?

It turns out that this is quite easy to accomplish. In a nutshell, you treat TypeKit as a second custom.css file. There are three simple steps:

1. On TypeKit, create your “kit” for your web site. Use the same CSS selectors here that you would use in your custom.css file if you were specifying them there:

   

   You can uncheck any font weights that you’re not planning to use, and you can leave the default CSS Stack setting. Be sure to click the (big ass?) Publish button!

2. When you’ve got your kit specified, copy the embedding code from TypeKit:

   

   Click the Embed Code link at the top right of the page to see this.

3. Switch back to your site, and paste the TypeKit JavaScript into Thesis, in the Header Scripts section of the Thesis Options panel:

   

At this point, you should be able to reload your site, and see the new font(s) in action, wherever you have set them to be used. If you want have additional control over the use of your TypeKit fonts, such as bold, italic, text spacing (tracking), etc., you can add it to your custom.css file as normal. This is all straightforward CSS. TypeKit is only specifying the font family; all other font settings are handled by Thesis (automatically) or your custom.css file.

There is one aspect of customizing your CSS font specifications that might not be obvious: when a typeface comes with a more broad range of weights, say, from light to ultra bold, how do you specify which weight to use? The answer is very simple, just add a font-weight CSS attribute with a numeric value from this list:

font-weight: 200; /*  Thin               */
font-weight: 300; /*  Light              */
font-weight: 400; /*  Normal             */
font-weight: 500; /*  Medium / Semi-Bold */
font-weight: 600; /* (not used)          */
font-weight: 700; /*  Bold               */
font-weight: 800; /*  Black              */
font-weight: 900; /*  Heavy              */

So, if you want to use the Milibus typeface for your navigation menu, but the default weight of normal seems a little light to you, while bold is just too bold, to use the semi-bold face just add this to your custom.css:

/* Make the weight of the nav menu a little stronger for Milibus */
.custom ul.menu li.tab a {
    font-weight: 500;  /* semi-bold */
}

Again, do not specify the font-family in your custom.css file for elements that will use fonts from TypeKit. TypeKit handles the font-family for you; you do everything else in custom.css.

I hope this inspires you to get (more) creative with type on your web site!

Two weeks ago I relaunched the Aldosoft web site, improving both the visual design and the code behind it, and adding a blog for posts like this one. Some things remain the same; it still runs on WordPress, because that’s perfect for a content-focused site like this one. This article is a brief description of the technical changes and additions.

The Old Aldosoft

The New Aldosoft

The most obvious difference is visual. After playing with a number of options for a new design, I chose the Thesis theme framework. I’ll eventually write more about why I selected Thesis, but for now, it combines great visual design, including fantastic typography and flexible layouts, with terrific customization options. It also generates outstanding, beautiful HTML and CSS. I have customized it moderately, but mostly stuck with the Thesis minimalist, text-focused aesthetic.

In addition to WordPress and Thesis, I’m using a variety of WordPress plugins to add visible features, or otherwise affect the display of this site, including:

• Subscribe to Comments
  Allows people to subscribe to new comments on individual posts. Great for people who read an article covering a specific topic, and want to be notified if more information is added.
• Text Control
  Prettyfies (technical term) text, and allows me to use simplified markup (instead of raw HTML) when formating longer posts with lots of structure (sections, lists, etc.). It allows the use of Textile, Markdown, or WordPress’s built-in formatting, on a post-by-post basis.
• Twitter Tools
  There are a variety of Twitter plugins for WordPress. TwitterTools is the most powerful, though not the simplest to use.
• WP-Cufon
  Makes it easy to use the Cufón font replacement technique, which lets you reliably and accessibly use more than just “web safe” fonts. I’m using it to display the Titillium typeface for headlines, etc.
• WP-Syntax
  I’ll have a longer post about syntax highlighting soon, but this is the plugin I chose to make posted source code more readable.

I also have a set of administrative and “infrastructure” plugins, which are not visible externally, but I find extremely useful in managing any WordPress site:

• Akismet (included with WordPress)
  Absolutely mandatory anti-comment spam tool. Life would suck without it.
• Google Analyticator
  Activates Google Analytics (visitor statistics) on the site. Technically Thesis has an option that could replace this, but Analyticator is so much more automatic and complete.
• Google XML Sitemaps
  Automatically generates a sitemap.xml file whenever I update the site. Creating a site map for Google is an essential part of getting good rankings in search results.
• Redirection
  A sophisticated tool for automatically redirecting people when they come to a bad URL. Probably too sophisticated, the user interface is complex, but I’m used to it…
• Woopra
  Another web stats tool, basically a competitor to Google Analytics. I’m trying both.
• WordPress Database Backup
  Automatically sends me a backup of the WordPress database, once a week, via email. Automatic backups rule.

This list of plugins is constantly evolving. I’ll try to post updated versions a couple times a year.

That’s what’s new on the technical side. Of course, as much work as the technical pieces were, I rewrote nearly every word on every page, and that was a lot more effort. In the end, a web site is only as good as the content, and the technology is secondary. Ideally I’ve done well with both.

The Thesis theme for WordPress is arguably the most advanced premium theme for WordPress-driven web sites. It combines fantastic layout flexibility (1-, 2-, and 3-columns, in various arrangements) with strong design customizability (colors for virtually every element are customizable, plus borders, padding, fonts and sizing, etc.) and terrific typography. Out of the box it looks great in all major web browsers, and can be customized wildly to achieve incredible diversity in visual design.

But, oddly, printing pages from a Thesis-based site will often remind you of how the web looked in 1996. That’s because by default the Thesis theme applies its styling only to on-screen display. Printing is entirely unstyled:

The gory details of the how and why are in a DIYThemes forum posting I made a couple days ago, Thesis prints unstyled by default. This is not good. Fortunately, it is possible to extend Thesis with PHP code, in ways that most themes would never dream of, and this gives us options for better printing.

The beginning of a solution is to add a stylesheet for print; the recommended placement is in thesis/custom/print.css. Then you add the link tag to your site via a hook function in your custom_functions.php file:

1
2
3
4
5
6
7

function add_print_stylesheet() {
    echo "\n";
    echo '<link rel="stylesheet" href="' . THESIS_CUSTOM_FOLDER . 
         '/print.css" type="text/css" media="print" />';
    echo "\n";
}
add_action('wp_head', 'add_print_stylesheet');

Now you have an active, but empty, print.css stylesheet. You still have unstyled content when you print. What’s next?

There are two approaches you can take:

• Create a new print.css stylesheet from scratch, adding only the minimum styling required to make printouts look the way you want. Ultimately, this can produce the best results.
• Import the on-screen stylesheets into the print stylesheet, and then add further additions, customizations, and overrides from there.

The second option will result in printouts looking exactly like your site does in a web browser. For some kinds of content this will not be ideal, but for most pages it’s better than being completely unstyled when printed, and it is a lot easier than writing a new stylesheet from scratch. If you’re looking for the quickest way to get to “pretty good,” this is the way to go.

To do it, put this in your print.css file:

1
2
3
4
5
6
7

@import url("../style.css") print;
@import url("layout.css") print;
@import url("custom.css") print;
 
#sidebars {
    display: none;
}

The #sidebars block removes your sidebars when printing. This is what most sites will want to do, but if you don’t, just delete lines 5-7.

The Aldosoft site is a mostly static content site, with a few pages describing who we are and what we do. When I started working on the redesign for the site, one of the main things I wanted to add was a blog for, well, articles like this one.

It’s pretty easy to use WordPress to build an entirely static content site, based on Pages. This is what the old Aldosoft site did. The setting for changing the Home page from a list of Posts to a static Page is easy to find, and obvious in use.

Putting a blog onto the site, “pushed off” the home page to a section at the same level as other pages of the site, is not so obvious. There’s a number of different settings which seem relevant, but how they all fit together is not clear. The documentation in the WordPress Codex (from which the title of this post is taken) is not written with the latest version of WordPress in mind, and makes it seem more complicated than it actually is.

Various Google searches turned up more semi-obsolete, incomplete, or just plain wrong answers. (Any article that says you need to add new files to your theme is outdated, at least for WordPress 2.8+ installations.) This article documents the simplest approach required to build a site like this one, a basic mostly-static WordPress site, where the blog is not the focus of the home page, but pushed down to the same secondary level as all the other pages.

You need to do three simple things:

1. Create a new page (not post), with no content (the page content will be replaced by your blog posts, once you finish step #2). This should be named whatever you want to call the blog section; here it’s just “Blog”. The page slug should be what you want to use for the URL to your blog; in my case it’s “blog”. (Told you this would be simple.)

2. Set the front page to “static” mode, and activate displaying your posts (your blog) on the new page. Settings > Reading > Front page displays:

   

   You are setting the “Front page” (or root of your site) to be the static page that will be the home page, and the “Posts page” to be the page you created in step #1.

3. Change your permalink structure, and use the Custom permalink structure to add your blog’s slug to the permalinks.

   

   This is optional if your preferred URLs don’t need to have posts appear “under” the main blog listing page. It will work either way.

There additional steps you will want to take if your theme does not automatically recognize the new Blog page, if you want to add links to your blog archives, etc. But those are steps you would need to take for any WordPress site, not specific to hosting your site’s blog at the secondary level.

I recently needed to install the PostgreSQL database server on my Mac for development with Ruby on Rails. I ran into a few gotchas, and while I was eventually able to Google and guess my way to success, it took a while. This installation guide is as much for me, 6 months from now, as it is for others who may wish to also install Postgres.

These instructions were current as of April 22, 2009, and were executed on Mac OS X 10.5.6 with Rubygems 1.3.2 and the Postgres 8.3.7 distribution. The shelf life of these instructions is probably brief, though they should work at least as a rough guide until the next major release of Mac OS X, or of Postgres.

Preferences and Biases

There are other Postgres + Rails instructions which recommend the use of either MacPorts or Fink. I personally dislike these solutions; part of it is having used Fink in its early days and having it screw up royally, and part of it is a sense that the efforts are misplaced. (Why not make your Open Source contribution of how to get a project properly compiled and installed on Mac OS X directly in the project itself?) In any event, I refuse to use either…though I agree that they have a place for people less comfortable compiling software directly from source code.

I also prefer not to use pre-compiled binary installations of Open Source tools, unless the maintainer has demonstrated a long-term commitment and expertise in building and maintaining the package. Marc Liyanage did a terrific job with PHP 5 for Mac OS X releases up through “Tiger.” MySQL is doing a great job creating Mac OS X installer packages for the MySQL database. But many binary installations either make odd decisions about where to put things, or don’t get maintained, or make module/configuration/packaging decisions different from what I need, or all three.

So I generally prefer to compile from source code, and install my additions to Mac OS X in /usr/local. Dan Benjamin explains the logic and benefits of /usr/local in exhausting detail, I won’t go into it further. Either you agree, and these instructions may be useful to you, or you don’t, and you should keep Googling.

Prerequisites and Preconditions

• These instructions are for Mac OS X 10.5 “Leopard” only.
• You need to be comfortable, or better yet confident, on the command line.
• You need to have Apple’s developer tools installed.
• You need to have current versions of Ruby on Rails and Rubygems installed.
• You need to understand what it means to update your $PATH environment, preferrably in ~/.bash_login. You do have a ~/.bash_login file, right?

But mostly this document assumes that you’ve already gone through the outstanding instructions for installing a complete Ruby on Rails development suite provided at Hivelogic. Indeed, if you didn’t use those instructions, at least mostly, you probably shouldn’t use mine either.

The Instructions

There are two things that need to be installed, the Postgres server and the Ruby gem for the Postgres database driver. You will also want to add a launchd task for starting and stopping the database server.

Installing the PostgreSQL Database Server

Postgres traditionally runs as a “daemon,” or background process, and manages all control to its files, especially its data. This requires that you create a dedicated user account and group, which only Postgres will use. While you could do this in the Accounts preference pane, it’s better to do this from the command line, so that the system won’t treat the Postgres user like a normal user. This is done with the Directory Service command line utility, dscl.

Before creating the Postgres user you need to pick out internal ID numbers for the user and group. You need to find a number that is not currently in use, so start by seeing what is in use. View the list of user accounts and ID numbers (note that some output is elided):

$ dscl . -list /Users UniqueID
_amavisd           83
_appowner          87
_appserver         79
[...]
_mysql             74
[...]
alderete           501
daemon             1
nobody             -2
root               0

Next the groups:

$ dscl . -list /Groups PrimaryGroupID
_amavisd                       83
_appowner                      87
_appserveradm                  81
[...]
_mysql                         74
[...]
tty                            4
utmp                           45
wheel                          0

Within these lists you want to find an ID number under 500 that is not in use. My primary source for these instructions recommending adding 100 to the ID for MySQL, which seems reasonable. It’s also probably helpful to find a number that is available for both the user and the group ID, so you don’t have to worry about which is which. From the output above, I chose 174, which met both criteria.

With chosen user and group IDs, create the user. Here we are creating a user with a $HOME of /usr/local/pgsql, the location where we will be installing Postgres. We’re also creating the user in such a way that it’s useful only as a daemon; it is not possible to log in to the system as this user, either at the normal login screen or via ssh.

$ sudo dscl . -create /Users/postgres UniqueID 174
$ sudo dscl . -create /Users/postgres PrimaryGroupID 174
$ sudo dscl . -create /Users/postgres HomeDirectory /usr/local/pgsql
$ sudo dscl . -create /Users/postgres UserShell /usr/bin/false
$ sudo dscl . -create /Users/postgres RealName "PostgreSQL Administrator"
$ sudo dscl . -create /Users/postgres Password \*

Now verify that the user was created as expected, by reading back the values from the system:

$ dscl . -read /Users/postgres
AppleMetaNodeLocation: /Local/Default
GeneratedUID: 0024E028-00A9-48FB-B14A-68026D442870
HomeDirectory: /usr/local/pgsql
Password: *
PrimaryGroupID: 174
RealName:
 PostgreSQL Administrator
RecordName: postgres
RecordType: dsRecTypeStandard:Users
UniqueID: 174
UserShell: /usr/bin/false

Follow a similar procedure to create and verify the group:

$ sudo dscl . -create /Groups/postgres PrimaryGroupID 174
$ sudo dscl . -create /Groups/postgres Password \*
$ dscl . -read /Groups/postgresAppleMetaNodeLocation: /Local/Default
GeneratedUID: 7A7F8760-455F-4315-84DD-2DA330AD9845
Password: *
PrimaryGroupID: 174
RecordName: postgres
RecordType: dsRecTypeStandard:Groups

With the dedicated user and group created, you can now download, compile, and install Postgres. The source code distribution can be downloaded from one of the Posgresql.org mirrors. If you use Safari to download it, be sure you’ve turned off the Open “safe” files after downloading option. (And leave it off, it is a known security risk.)

Move the archive to your preferred location (such as /usr/local/src), start a Terminal session there, and:

$ tar zxvf postgresql-8.3.7.tar.gz
$ cd postgresql-8.3.7
$ ./configure
[...]
$ make
[...]
$ sudo make install
[...]

Note: there may be options you want to enable with the configure script, such as encryption or authentication methods. Use ./configure --help to get more details.

Installing the software does not actually create a location to store the database data, or initialize the system databases. Do that next:

$ sudo mkdir /usr/local/pgsql/data
$ sudo chown postgres:postgres /usr/local/pgsql/data
$ sudo -u postgres /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Password:
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
[...]
Success. You can now start the database server using:
    /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
or
    /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start

You’ll want to create a Postgres user (distinct from the system user for Postgres), but before you can do that, you need to start the server. Below I describe how you can have Postgres start automatically when your computer boots, but for now, let’s just start it up manually:

$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start

Now create that Postgres user, and a default database for it to use. This is the account that you will eventually use in the database.yml file of your Rails applications. And finally, use the psql command line tool to verify that we’ve successfully created the user and database.

$ sudo -u postgres createuser alderete
$ createdb
$ psql
Welcome to psql 8.3.7, the PostgreSQL interactive terminal.
[...]
alderete=# \l
               List of databases
           Name           |  Owner   | Encoding 
--------------------------+----------+----------
 alderete                 | alderete | UTF8
 postgres                 | postgres | UTF8
 template0                | postgres | UTF8
 template1                | postgres | UTF8
(4 rows)
alderete=# \q

Note: The above illustrates creating a database user and new database, both named for my Unix account name, “alderete”. Using the Unix account name simplifies using Postgres’s command line tools, you won’t have to enter the Postgres account name every time. But that will only work if your name is “alderete” too. ;-) Instead, use your Unix (or “short”) account name instead! This will likely be visible in your command line prompt, but it will also appear in the list of users you generated at the beginning of these instructions.

Finally, add important Postgres directories to your various system paths. Add the following lines to your ~/.bash_login file:

export PATH="$PATH:/usr/local/pgsql/bin"
export MANPATH="$MANPATH:/usr/local/pgsql/man"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/pgsql/lib"

Be sure to source this file to activate the new environment settings:

$ . ~/.bash_login

Install the Postgres Ruby Gem

Normally installing a Ruby gem is pretty simple, but the Postgres database driver has native (compiled) components, and these need to be linked against the Postgres binary. The problem is that by default Postgres is only built for the hardware architecture of your computer (PowerPC or Intel), while the gem appears to try to link against both architectures. This causes an error, and the helpful suggestion that appears with the error message does not in fact work, producing the exact same error message.

The trick to getting past this is to set the preferred architecture right on the gem install command, like so:

$ sudo env ARCHFLAGS='-arch i386' gem install \
  postgres -- --with-pgsql-dir=/usr/local/pgsql
Password:
Building native extensions.  This could take a while...
Successfully installed postgres-0.7.9.2008.01.28
1 gem installed

(If you’re still using a PowerPC-based computer, change “i386” to “ppc”.)

This should allow the gem to install successfully.

Automatically Starting Postgres at System Startup

On my development systems I’m using the database constantly, and so I have it set to start up automatically, as part of my computer’s boot process. The “Leopard” way to do this is to add a launchd task to your system. This is a text file that you’ll save on your desktop, and then move to /Library/LaunchDaemons/org.postgresql.dbms.plist. The following was copied from my primary source (see below):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>org.postgresql.dbms</string>
    <key>UserName</key>
    <string>postgres</string>
    <key>GroupName</key>
    <string>postgres</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/local/pgsql/bin/postmaster</string>
      <string>-D</string>
      <string>/usr/local/pgsql/data</string>
    </array>
    <key>StandardErrorPath</key>
    <string>/usr/local/pgsql/logs/postgresql.log</string>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Once this file is in place, you can load it by restarting your computer, or with this command:

$ sudo launchctl load /Library/LaunchDaemons/org.postgresql.dbms.plist

If you can believe it, you’re done. Pour a cold one, or get right to it with rails mynewapp -d postgresql. Good luck!

Sources, Citations, and Credits

By far the most complete posting on this topic was
Working Software’s Building and Installing PostgreSQL on Mac OS X, which covered installing Postgres from source completely. While the instructions above are copy/pasted from my Terminal windows, I was copying lines directly from this article to paste into Terminal in the first place.

The one thing that wasn’t covered in the above article was installing the Ruby gem for Postgres, which is required to use Postgres in Rails. The normal gem install [gemname] produced errors, and most suggestions I found didn’t work any better. What finally did work was including the “-arch i382” option directly on the gem installation line, which appears to be orginally published towards the bottom of PostgreSQL on Leopard for Rails: A few notes. (A few other posts repeat this advice, so I’m not sure who first published it.)

Finally, although it’s quite dated, the Apple Developer Connection article PostgreSQL on Mac OS X provides useful background information, and notes about using Postgres from other languages besides Ruby.