Grab the new Oracle InstantClient libraries

The new Intel Mac versions are available from the Oracle downloads site. Install them in /Library/Oracle/. You can do side-by-side installations in folders with whatever names you want, since apps find them by using the $ORACLE_HOME environment variable (and it’s friends). I’ve got mine in /Library/Oracle/instantclient/10.2.0.4. Also make sure that you’ve got the files required to run sqlplus and the sdk. You can drop those in the same directory.

Oh, and don’t forget to copy over your tnsnames.ora file.

Symlink the libraries

In the directory where you’ve installed the instant client, run this:

ln -s libclntsh.dylib.10.1 libclntsh.dylib

Set the environment variables correctly

You’ll probably want to put these lines in your .bash_profile, but they also must be run (or source‘d) from the command line to take effect:

export ORACLE_HOME=/Library/Oracle/instantclient/10.2.0.4
export TNS_ADMIN=$ORACLE_HOME
export LD_LIBRARY_PATH=$ORACLE_HOME
export DYLD_LIBRARY_PATH=$ORACLE_HOME
export PATH=$PATH:$ORACLE_HOME

On to the next step, making Rails & Oracle play nice.

Getting Rails to talk to Oracle

First,

sudo gem install activerecord-oracle-adapter --source http://gems.rubyonrails.org

This installs the oracle adapter, which is how ActiveRecord deals with Oracle. It doesn’t, however, install the Ruby oci8 driver, which is how Ruby talks to Oracle. We’ll do that now.

Compile the ruby-oci8 library

Make sure you’ve got the Oracle Instant Client SDK installed in your Oracle Instant Client directory (/Library/Oracle/instantclient/10.2.0.4)

The most recent stable version of the oci8 library is 1.0.1. Download it and unpack the file in the finder: it should unzip into ~/Downloads/ruby-oci8-1.0.1.

Now we can finish configuring the environment before we compile the library.

cd ~/Downloads/ruby-oci8-1.0.0
export SQLPATH=$ORACLE_HOME
export RC_ARCHS=i386
ruby setup.rb config
make
sudo make install

These steps should cause some compiler output to scroll by. Pay attention if you run into any errors on the setup step; the error messages are reasonably helpful at pointing you towards any problems.

Test connectivity

At this point, we’re done. We’ve got the latest Oracle InstantClient, and we’ve installed the ruby-oci8 library. Now it’s a question of making sure that everything works as advertised:

ruby /usr/bin/irb

In the IRb console, type:

require 'oci8'

If the console returns true or [], you’re in business.

Configure your database.yml

The last step is to make your application use the Oracle connection. In your database.yml, use the following to make it work:

development:
adapter: oracle
database: your_instance_name
username: your_user_name
password: your_password

The database name comes straight out of your tnsnames.ora file. You don’t need to specify any other connection information in database.yml, since the tnsnames.ora file has everything you need.

Your application is now talking to Oracle, without Rosetta!

Fix the ruby_fat and ruby_ppc setup

If you followed my previous instructions and went through all of the shenanigans with the ruby_ppc and ruby_fat versions and would like to undo them, it’s quite simple. Just remove the ruby_ppc files, and the symlinks to them (called ruby, and rename ruby_fat as ruby:

cd /usr/bin
sudo rm ruby
sudo rm ruby_ppc
sudo mv ruby_fat ruby
cd /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin
sudo rm ruby
sudo rm ruby_ppc
sudo mv ruby_fat ruby

Then, you should also remove the 2 management scripts:

sudo rm /usr/bin/ppc_ruby.sh
sudo rm /usr/bin/fat_ruby.sh

And that’s enough for the cleanup. From here you can start following the instructions beginning with getting the new Oracle libraries.

namespace :db do
  namespace :schema do
    desc "Create a db/schema.rb file"
    task :dump => :environment do
      require 'active_record/schema_dumper'
      puts "Creating schema:"
      File.open(ENV['SCHEMA'] || “db/schema.rb”, “w”) do |file|
        ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, file)
      end
    end
  end
end

This task as shown does exactly what the default rake task does, except for the puts line. Let’s just pretend that it’s a radically different and wonderful version that solves world hunger and raises your children. Now, if you drop this into a rakefile in your app’s lib/tasks directory, and then you run rake db:schema:dump --trace you’ll notice that the schema.rb file gets created twice. What the???

Check the docs

So I started poking around the Rake docs. Rake::Task.define_task does the following:

Define a task given args and an option block. If a rule with the given name already exists, the prerequisites and actions are added to the existing task. Returns the defined task.

Aha! So instead of overriding the existing task (monkeypatching it), I’m adding to it. That’s why the schema gets dumped twice. But what if I don’t want that? What to do if I want to replace the rake task with my new version?

Check the internets

About an hour of googling later, I finally came across a post from Matthew Bass explaining the solution to my problem:

Rake::TaskManager.class_eval do
  def remove_task(task_name)
    @tasks.delete(task_name.to_s)
  end
end

def remove_task(task_name)
  Rake.application.remove_task(task_name)
end

# Override existing test task to prevent integrations
# from being run unless specifically asked for
remove_task 'db:schema:dump'

# Now define db:schema:dump again, the way we did above

And that was it. It’s relatively straight-forward, but has a tendency to do strange things when rails gets updated. So you could abstract it into a plugin, with tests, but don’t forget to test it whenever you gem update rails.

Alternative solution

While I was googling I also ran into a very interesting post on alias_task_chain, a method that patches Rake tasks to work like more typical methods with alias_method_chain. If you were clever and wanted to spend the time, you could get a solution to the problem using this method.

What you know

Some clients approach me saying that they want a website. Some say that they want a website that looks nice. Some say they want a website that performs functions x, y and z. Some say they want a website set in 12pt Verdana with a background that’s exactly this shade of green, on a 960 pixel grid. And written in PHP with a custom CMS, please.

There’s nothing wrong with any of these, although the last client always tends to give me pause, for reasons I’ll discuss at the end of the article. I like to think of hiring a web professional the way I would hire a contractor to work on my house. Because, really, that’s what you’re doing: you’re hiring a contractor to work on your digital house. Not all contractors are the same. They produce work of differing quality, in different styles and at different prices.

The problem for most home owners/clients is that the sheer number of choices is overwhelming; they don’t even know where to start. If you want a contractor for your house, there’s a very clear geographic constraint on the choice — the contractor must be in the same place as you, so they can come to your house to do the work. But with the web, that’s not true; we’re all just one e-mail away from each other. (6 degrees of separation? Hah!)

Who might you hire?

Chances are pretty good that you’re not the first business in your industry to have a website. They’re also pretty good that you’re not the first business of your size to have a website. So look at some of these other businesses on the web, and find out who did their sites. Most web pros will have some link to themselves somewhere on the sites they design, usually in the footer or on an “About” page.

Start building a list of potential contractors in this way. You can also do a Google local search to find web designers in your area. They have the advantage of being able to meet you face to face, which is something that I really like, although it’s not necessary.

You’ll very quickly end up with 10-20 potential site builders this way. Collect ‘em all.

Who do you like?

This is the most fun part of selecting a web designer: making a short list. Everybody’s a critic, and this is your chance. Start by browsing their web sites.

If their site is old, clunky or ugly, then maybe you should take them off the list. If they tend to make sites radically different from the kind of site you’re looking for, take them off. If their personal style doesn’t match up with your vision of your site, then perhaps they’re not right for you. Although be careful; some people have amazing ranges and can surprise you.

Many web pros have a blog. Read some of it. Do they seem like the kind of person you would want working for you?

After going through this, you should be down to some kind of a short list.

Your ideas

Note that, so far, I haven’t said much about refining the ideas for your site. That’s because you don’t need to do that alone. The analogy about hiring a contractor isn’t really appropriate anymore. Really, when you hire someone (or some company) to build your site, you’re hiring an architect and a contractor all at the same time. The architect will help you refine your vision when you’re deciding on the addition to your house; let the web professional do the same.

You shouldn’t refine your ideas alone. The best designs come from lots of interaction between the designer and the client.

Talk to them

Now we get down to the nitty gritty. E-mail or call every member of your short list, and make an appointment. Speak with them. Ask them about their process. How do they get you from where you are to having a completed site? How much feedback is there between them and you along the way? What does their process emphasize? How flexible is the process?

Although there are wrong answers to these questions, there aren’t any right answers. What’s important here is that the way they work fit with what you want. Personality is a big part of this. You have to be able to talk to your web pro, and you have to be able to trust that their process will produce the end result that you’re looking for.

Get a quote

This one speaks for itself. Get a quote. Find out what their pricing method is. Do they bill hourly? Is it a flat fee? What are the restrictions about changing details of the project mid-stream? What kind of timeline can they work with? Is the quote firm?

Again, there aren’t really right answers, although there can be wrong ones. Comparing quotes is very difficult, as they are frequently apples and oranges. Unfortunately I don’t really have any good advice here, except this: in the low range of web design, you almost always get what you pay for, but above that it’s a free-for-all, and price frequently bears little correlation to the quality of the finished product.

Be wary of hidden costs

Be careful about hidden costs. For example, all web sites need to be hosted somewhere. Does your web designer offer their own web hosting? Many do. If so, what do they charge? What does the charge include? You can easily price this against any web hosting company’s rates to see if what you’re paying is reasonable.

If they don’t offer hosting, will they set you up with a reputable web host? Will they charge you for that?

How does your site get updated? Will you be able to do it, without breaking anything? If not, how much will it cost you to make changes? Be wary of being nickel-and-dimed to death with site updates, especially when nickels cost $80 an hour.

Search engine optimization (SEO) is another favored charge. Some web pros won’t submit your new site to the search engines. Or they will charge you for it. Some will issue repeated charges for re-submission every few months. This is a very bad idea: once the search engines are aware of you, they will re-index your site regularly. Re-submission is usually grounds for removal of your site from their search results. There can be a wide variety of charges associated with SEO; make sure that they are legitimate and useful for you.

Choose someone!

By now you’re very well equipped to choose the best web designer for you. You know a lot about the people on your short list: you understand something about who they are, how they think and how they will approach your project. Weigh that against your budget, and make your choice.

Trust your designer

Once you have chosen a designer, don’t be afraid to trust them. If you don’t think you can trust them, don’t hire them.

If you know as much as your designer does about web technology, then hiring them is a bad idea; let them sort out the design and the tech. They know if PHP is the best technology for your site or not. Discuss it with them, but listen to what they have to say. After all, you hired them to be your web expert. As long as you have enough input in to the process, they should be trusted to make the best decisions for you. If they can’t, then you hired a bad web professional — fire them and get your money back.

With trust and confidence on both sides, you will end up with a site that you love.

This is truly great news, for several reasons. One is that Microsoft is now arguing for greater openness. That can only help the marketplace. The other is that, for the first time in a long time, they’re making a very good decision with respect to IE, and they’re making it for the right reasons. They’re making it because they want to play nicer with their clients and their developers. That’s what I call a win-win: they win, and we win. Everybody wins!

But wouldn’t it be nice to have a single method call, that uses url_for syntax?

class Object
  def request(options = {})
    method = options.delete(:method) || :get
    options.reverse_merge!(:only_path => true)
    ENV['REQUEST_URI'] = app.url_for(options)
    ENV['REQUEST_METHOD'] = method.to_s
    Dispatcher.dispatch
  end
end

First we pull the method (:get, :post etc.) out, if it exists. By default we want it to be :get. Then we call url_for and have it only return the path, without any leading domain info. Next we populate the environmental variables and call the dispatcher. The return output will be the HTML your app renders.

To make the trick universally accessible on your development box, put the above code in ~/.irbrc:

Then, fire up the console to your favorite rails app, and call:

>> request(:controller => 'my_controller', :action => 'the_action')

You should see the HTML output scroll by.

It sounds like a great idea, right? I mean, why should I have to worry that Microsoft released IE7? If I used this tag, and specified IE6, then my page would always render correctly in IE, even if IE was on version 28.

WRONG!!!

Let’s really look at this situation. There are two wrongs here, and Microsoft wants to add a third. Let’s look at how we got here.

1. Microsoft made a bad browser: it didn’t (and still doesn’t) support the CSS standard
2. Developers everywhere screwed up by coding pages that take advantage of the IE bugs, in a way that breaks in standards-compliant browsers (never mind that conditional comments makes this unnecessary)
3. Microsoft upgrades IE to version 7, and those bad sites break
4. Microsoft says, “If every web developer were to just change how they work, we could have upgrades that are ok.”

Do you see the fatal flaw in the logic?

It’s right there in steps 1 and 2.

If Microsoft made browsers that support the standards, we wouldn’t be in this mess. I say, no to Microsoft’s proposal. I say, if Microsoft doesn’t want to make browsers that support the standards, then their customers get what they deserve if the web starts breaking for them. I say, how about Microsoft step up to the plate and make a rendering engine that works instead of relying on everyone else to fix their problems for them.

“But what about all of those pages that the IE7 upgrade broke?” you ask. Those are bad pages, and IE7 is a bad browser. They’re either not coded to standards, or IE7 choked on the correct standards-compliant code they were using, or both. That’s why they broke. The people who paid for that development should switch developers to get someone who knows what they’re doing, who will code pages that actually work. The browser shouldn’t have been released if it didn’t support the standards.

This is why they’re called “Web Standards.” Because they’re standard. I make a page that works in Firefox, I know that it works in Safari. I should know that it works in IE. If that’s not true, then it’s IE’s problem, not mine.

Note to Microsoft

FIX YOUR D*** BROWSER ALREADY. It’s almost been a decade since IE5 started support for CSS 2, and they still haven’t gotten it right. They make $50 billion dollars a year and can’t make their browser behave.

Note to web developers

FIX YOUR D*** PAGES ALREADY. It’s almost been a decade since CSS2 came out. You haven’t figured out how it works yet? You call yourself a professional? Get with it.

I’m a bleeding-heart liberal

Zeldman posted about people just like me. He says, “We won’t get converts by breaking sites and ridiculing their creators for not knowing as much as we do.” He’s right.

Except that we’ve tried that, and it doesn’t work. It doesn’t work because many of the web pages out there aren’t made by professionals. Anybody heard of Dreamweaver WYSIWYG mode? If the pages work, people are happy. Except that they don’t work. If they work in IE6, but not in IE7, they never worked. They just had the illusion of working.

Let’s make an analogy, to print design. If I, a rank amateur in the print design world, decided to print a book in 5 point Comic Sans and it was totally illegible, that’s my problem. It’s not the printer’s problem, or the reader’s problem. It’s mine. I screwed up, I made content that wasn’t accessible to anybody. Some readers have figured out that if they use a magnifying glass, it’s not so bad, they can read it. That doesn’t mean that my book wasn’t broken. Now let’s say that these people buy another book of mine, this time printed in 72 point Bembo. With their magnifying glass, they now complain that the new book is broken! They can’t read it. Nobody else can either, because the type is just too big. If I said, “Well, every publisher needs to do something so that my books are legible” you would say I’m stupid. It’s up to me to books that are legible. And that’s right. That’s why it’s up to Microsoft to stop making a browser that’s broken and expecting people to work around them. And it’s also up to developers to stop coddling the browser that’s broken.

Why the doctype switch isn’t targeting

One problem in this debate is that people are confusing doctype switching with version targeting. Using a standard doctype is like a contract: I, the developer, support this standard of HTML and CSS, so that you, the browser, can render it properly according to the same standard. The standard provides a common language, a shared vocabulary, so that the garbage I put in to the system is the same garbage that comes out. Targeting a browser isn’t the same thing. When I use conditional comments or other CSS hacks, I’m saying “hey browser, you’re don’t understand this sentence in our standard vocabulary, so I’m going to give you a sentence that you understand.” That’s not the same thing as saying which vocab you’re using. It’s like talking to a child — if you use a word the child doesn’t understand, you talk around it, explain it, you don’t switch languages. If I use the new meta-tag, and I target IE7, IE8, or IE42, it should render my page the same, according to the contract I say I’m holding to in my doctype declaration. End of story. If they don’t then they’ve got bugs.

Really?

Are we really going this way? I can’t believe that this industry is even considering Microsoft’s proposal. If the browsers aren’t upholding their end of the contract, why should we work around them? Let them be broken, let people decide they don’t want a broken browser, let the bad browsers die.

Updated (12/11/07): The ruby-oci8 library just went to full 1.0.0 release. I’ve updated that section to reflect the new file names.

Updated (5/5/08): The oracle adapter installation has been on-again-off-again with successive Rails releases, but there’s an easy fix for it. I’ve updated the relevant section.

At my new job, I’m using Ruby on Rails to connect to multiple databases — multiple Oracle (10g) instances, as well as MySQL and FileMaker. There’s a lot of challenges to doing this, so I’m going to post some of the less obvious solutions as they come up.

The first challenge I had was to get RoR to talk to Oracle. There isn’t a lot of information about this online, because the people who tend to use Oracle are not the people who tend to use open source software like Rails.

Upgrade Rails to version 2.0

To start out, I wanted to use the most recent release candidate of Rails: version 1.99. I figured that I might as well upgrade before writing my first application, so that the codebase is all Rails 2.0 and up. Leopard comes with both Ruby and Rails, and upgrading is actually very easy:

sudo gem install rails --source http://gems.rubyonrails.org

Then enter “y” at each prompt, to install all of the dependencies. That’s it! Check yourself with

rails –v

You should see Rails 1.99.0 or Rails 2.0.

Getting Rails to talk to Oracle

Now,

sudo gem install activerecord-oracle-adapter --source http://gems.rubyonrails.org

This installs the oracle adapter. It doesn’t, however, install the Ruby oci8 driver. We’ll do that now.

Make sure you’ve got the Oracle Instant Client SDK installed in your Oracle Instant Client directory (/Library/Oracle/instantclient/10.1.0.3)

There’s a problem on new Intel Macs with this library. Oracle hasn’t seen fit to release an Intel version of the library in the past year and a half, and that’s going to cause problems since the Ruby binary is going to run as Intel-native, but the Instant Client will run under Rosetta. To solve this, we have to make a PPC version of the Ruby binary.

Make PPC and fat versions of Ruby

This is easier than it sounds. We don’t have to recompile, since the Ruby binary in /user/bin is fat. You can check this:

file `which ruby`

This should show you a PPC and a i386 version:

/usr/bin/ruby_fat: Mach-O universal binary with 2 architectures
/usr/bin/ruby_fat (for architecture ppc7400):	Mach-O executable ppc
/usr/bin/ruby_fat (for architecture i386):	Mach-O executable i386

All we have to do is extract the PPC version as a standalone binary, and trick the system into using that only. It will make our Ruby slower, but it will get Ruby to talk to Oracle, so I’m willing to take the performance hit. It’s so fast on the Intel Macs anyway, unless your Rails apps are doing massive amounts of processing, you probably won’t notice.

We’ll use ditto to extract the PPC version:

sudo ditto -arch ppc7400 /usr/bin/ruby /usr/bin/ruby_ppc
sudo mv /usr/bin/ruby /usr/bin/ruby_fat

Now we’ve got two versions of the Ruby binary — the original fat version, and a PPC only version.

There’s a catch here, though: we actually have two copies of the ruby binary on our system. The second binary is a part of the Ruby Framework, and that’s the binary that’s used by irb, rake and other very useful Rails helpers, so let’s fix this one too:

sudo ditto -arch ppc7400 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_ppc
sudo mv /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_fat

Now we’ll need a facility for switching between the fat and PPC only binaries. Create /usr/bin/ppc_ruby.sh:

#!/bin/bash
ln -fs /usr/bin/ruby_ppc /usr/bin/ruby
ln -fs /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_ppc /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Create /usr/bin/fat_ruby.sh:

#!/bin/bash
ln -fs /usr/bin/ruby_fat /usr/bin/ruby
ln -fs /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_fat /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Now, make them both executable:

sudo chmod 0711 /usr/bin/ppc_ruby.sh
sudo chmod 0711 /usr/bin/fat_ruby.sh

Run ruby_ppc.sh to switch to using the PPC version:

sudo /usr/bin/ppc_ruby.sh

Verify this worked:

file `which ruby`

This should return /usr/bin/ruby: Mach-O executable PPC.

We’re getting closer. Now we need the ruby-oci8 library.

Compile the ruby-oci8 library

The most recent stable version of the oci8 library is 1.0.0. Download it and unpack the file in the finder: it should unzip into ~/Downloads/ruby-oci8-1.0.0.

Before we can compile this library, we have to fool the system into making it PPC only, or it’s not going to work. With your favorite text editor, edit /usr/lib/ruby/1.8/universal-darwin9.0/rbconfig.rb. Comment out line 17 ('-arch ppc -arch i386' and replace it with '-arch ppc'. Save your changes. Leave the file open in your text editor, because we’ll come back to it.

Now we can finish configuring the environment before we compile the library.

cd ~/Downloads/ruby-oci8-1.0.0
export DYLD_LIBRARY_PATH=/Library/Oracle/instantclient/10.1.0.3
export SQLPATH=/Library/Oracle/instantclient/10.1.0.3
ruby setup.rb config
make
sudo make install

Now you can go back to your text editor and restore line 17, save your changes and exit.

Test connectivity

At this point, we’re done. We’ve fooled our system into running a PPC version of Ruby under Rosetta, and we’ve installed the ruby-oci8 library. Now it’s a question of making sure that it works:

ruby /usr/bin/irb

In the IRb console, type:

require 'oci8'

If the console returns true, you’re in business.

Configure your database.yml

The last step is to make your application use the Oracle connection. In your database.yml, use the following to make it work:

development:
adapter: oracle
database: your_instance_name
username: your_user_name
password: your_password

The database name comes straight out of your /Library/Oracle/instantclient/10.1.0.3/network/admin/tnsnames.ora file. You don’t need to specify any other connection information in database.yml, since the tnsnames.ora file has everything you need.

Your application is now talking to Oracle!

sudo gem install rails --source http://gems.rubyonrails.org

Then, enter “y” at each prompt, to install all of the dependencies. That’s it! Check yourself with:

rails -v

Right now it will show Rails 1.99.0 which is the current release candidate. When rails goes fully 2.0, the same instructions should work to get the full release installed.

And don’t forget, you can always rake rails:freeze to lock a Rails app to a particular version of Rails by copying all of the Rails libraries into the /vendor directory.

Happy coding!

Most recently, I wanted to code this algorithm:

If on the current page
  show <a href="blah1">link 1</a>
else
  show <a href="blah2>link 2</a>

Rails has, of course, the nifty link_to_unless_current, but all that does is show the text of the link:

If on the current page
  show link
else
  show <a href="blah">link</a>

That’s not quite what I’m looking for. But when I was looking up link_to_unless_current in the docs, I realized that there IS an else condition on link_to_unless_current. The function takes a block as its last parameter, and that’s what gives you the “else.”

This code, in a view:

<%= link_to_unless_current('Link text', my_url) { 'Alternate text' } %>

produces this algorithmic result:

If on the current page
  show Alternate text
else
  show <a href="my_url">Link text</a>

Mission accomplished.

Andrei Herasimchuk has just written an open letter to John Warnock at Adobe, suggesting that he, and really Adobe, contribute a small group of roughly 10 core fonts to the public domain. That’s not so cool. What’s cool is the rationale behind the request. If these fonts — fonts like Frutiger, Helvetica Neue and Warnock Pro — go public and are released in Windows and MacOS distributions, then web designers might be able to use more than FIVE fonts for designing web pages.

Given the technological limitations that web designers face, what with problems in cross-browser support for standards as well as requirements for testing sites on multiple platforms (mac, win, cell phones, screen readers), it would be nice if we got a break for once, and were able to expand our design options beyond Helvetica, Times, Trebuchet, Georgia and Verdana. As nice as those are, the inability to rely on any kind of typographical range is a real handicap. If you’ve ever wondered why many “Web 2.0″ sites look alike, look no further than the choice of 3 good sans-serif fonts that are truly avaliable cross-platform. Choice of fonts will allow our sites to have unique character and identity. Seriously — if Adobe released just 10 fonts in this manner, it would triple the number of available choices.

Mr. H, you have my support.

This is great news!

Wait a minute. Let’s try that again.

This should be great news!

The IE7 blog posted today about all of the CSS rendering bugs that they’ve fixed. The list is extensive, including almost all of the problems from positioniseverything.net. Notice that I say almost. The float clearing bug is still a bug in IE7. It seems so strange to me — they can squash all of the bugs but one? That’s like running the 100 yard dash and stopping at yard 98. Why can’t they seem to do what every other major browser developer has done? Is Microsoft so incompetent that they can’t even toe the line anymore? So much for being the largest, richest, most powerful corporation in the computer industry.

The impending mass adoption (because of the automatic update) of IE7, with is myriad bug fixes should make every web designer jump for joy, but alas it’s a mixed bag, because IE7 falls a little short of expectations. On the fateful day that IE7 rolls out, our sites will have to be instanteously compatible. Thankfully, for the most part they will. But be warned if you’ve ever used float clearing to make a layout work…
At least there will still be ways to target IE7, despite the fixing of the Holly hack, * html hack, etc. by the IE7 dev team. Not only have new hacks been discovered, which I won’t comment on, but it’s easy enough to put all IE7-directed CSS into a single file, and use conditional comments to target that file to IE7 alone.

My point, however, is that we shouldn’t have to. IE7 should just render the standard which Microsoft, as a member of the W3C, helped create. Just like everybody else.

Before I convince people that I’m just a cynical reflexive MS critic, I have to say that they’ve done quite a bit more than I thought they would. I mean, they made it to yard 98. I honestly didn’t think that the initial release of IE7 would get that far in the race for standards compliance. Kudos to the IE7 dev team for that.

For an interesting discussion about what people think, look at the conversation on Dave Shea’s post in the comments.

My current job is really the first time I’ve had to use Windows regularly since Windows for Workgroups 3.11. That’s way back in 1995 when Windows 95 was still vaporware, much like Vista is now. Isn’t it already 3 years overdue? Anyway, that’s not relevant to this discussion.

I’ve had many discussions with people over the years about the old Mac vs. Windows debate. I’m no rabid Mac advocate: it’s not the best solution for all people at all times. Hardcore Windows users frequently complain that on the Mac there is no Registry, that you can’t really configure hardware devices etc. I would argue that on the Mac you don’t have to. It’s convention over configuration.

When I first started using a Mac, I had many of the same misgivings. Where were the menus with the bazillion options to choose from? Why couldn’t I regulate every little detail of the interface? As I used my Mac more, I realized that I didn’t have to. The configuration options I wanted were absent, but the need for them was absent as well. And I say the MacOS is better off for it, because it lowers the barrier to entry.

I frequently think about interface design in terms of my mom. I know, a lot of people do this, but it works. My mom has fought with Windows for years: it doesn’t do things the way she wants. What she doesn’t realize is that she probably can make it work the way she wants it to, if only she knew how. And therein lies the problem. It’s too complicated to get Windows configured just so, and so most users end up just living with it. Why should a $300 piece of software just be “lived with?”

The MacOS takes a different approach. It comes with a working configuration that is easier to use than what you get with Windows, and with fewer options. This means that the application and system interface isn’t cluttered with 1001 widgets all of which let you configure system, and so all you see are the features you want access to. This seems to be the goal of the UI revisions in “Office 12,” but they still don’t seem to have figured it out. Too many options mean that most of them just don’t get used.

If the system has good conventions, or default options, then you don’t have to spend your time fighting with it, and it generally does 95% of the tasks that 95% of users need done without any hassle. This is true of the Mac OS, and it’s true of RoR. The main difference is that the RoR folks have made their goal explicit.

Accomplishing 95% of what I want to do easily: that’s design elegance.

</epiphany>

But now I need to serve Rails as well. Getting Apache to do RoR with fcgi can be a hassle, and it’s apparently slow as well, so I decided to switch to lighttpd, or lighty as it’s called.

For development purposes, using the standard script/server is a no-brainer; however I want a “production” environment as well. One that can serve Rails, and legacy PHP, and do SSL for authentication, while talking to MySQL. I discovered that lighty can do all of these things, but how?

I looked around, and once you get to the deployment phase of RoR, there isn’t a lot of good information on the web, especially for smaller set-ups like mine; essentially, I’m almost the only person who hits my web server, as it houses some personal productivity stuff just for me that most other people don’t find interesting. That and my photo collection for friends to browse.

So I looked and looked, and found a lot of disjointed bits and bobs, but I didn’t find a good how-to for non-unix geeks. But, given the ease of use of lighty, I’ve put one together. Enjoy!

Requirements

1. Tiger (OSX 10.4)
2. XCode 2.0 or newer and developer’s tools
3. Patience and a nice snack while waiting for compiling to happen

Building Ruby, Gems, RoR, FastCGI, PCRE

Go to Dan Benjamin’s excellent instructions to do all of these things, and follow them well. However, stop when you get to the lighttpd instructions, because we’re going to make a change. Do this instead of what he says:

curl -O http://lighttpd.net/download/lighttpd-1.4.11.tar.gz
tar xzvf lighttpd-1.4.11.tar.gz
cd lighttpd-1.4.11
./configure --prefix=/usr/local --with-pcre=/usr/local --with-openssl
make
sudo make install
cd ..

The only difference is the addition of –with-openssl to the configuration, which will compile lighttpd with SSL (v2 and v3) support.

Building MySQL

You can choose to build MySQL according to the HiveLogic instructions, or you can use the MySQL 5.0 packages from the dolphin’s mouth, so to speak, and avoid the compile time. This works for version 4.1 as well. I’ve tried both versions with the setup described here, and both work.

Don’t forget to install the MySQL native bindings (again, from the HiveLogic instructions) as well.

But, I’ve already got this stuff working!

Chances are, you’ve already got a full setup that works, because you saw the HiveLogic instructions long before I ever wrote this page. If that’s the case, then all you need to do is follow my lighttpd compile instructions, which will over-write the pre-existing lighttpd version, with no ill effects.

Building PHP

First, download the PHP 5.1.2 full source code, and unpack the tarball by double-clicking it in the finder. I would recommend moving the unpacked “php-5.1.2″ folder to the same folder where you downloaded all of the source code from the hivelogic instructions.

Second, open a terminal, and execute the following commands:

./configure --enable-fastcgi --enable-discard-path --enable-force-redirect --with-zlib --with-xml --with-mysql=/usr/local/mysql --prefix=/usr/local/php5-fcgi --disable-cli --enable-memory-limit --with-layout=GNU --with-regex=php
make
sudo make install

When this is done, you’ll have a working cgi-fcgi version of PHP. We’ll hook this up to lighttpd in a minute, when we get to the lighty configuration files.

SSL

Before we start configuring lighty, we’ve got to get an SSL certificate. If you’re creating your own, you can follow the instructions from the lighty web site:

openssl req -new -x509 -keyout host.pem -out host.pem -days 365 -nodes

If you already have a certificate that’s a .crt and a .key file, you have to make them snuggle up into a single .pem file:

cat host.key host.crt > host.pem

Both of these methods result in a single .pem file, usually named “host.pem” where “host” is the name of the server you’re using the certificate for. This file can be stored anywhere you want on your system, since the lighty configuration takes an explicit path to it.

Configuring lighttpd

Now the more difficult part: we get to configure lighty. I’ll present the config files one chunk at a time, explaining what the various commands do. I’ve chosen to store mine in /etc/lighttpd/ to mimic how Apache stores its files (/etc/httpd/). Any path will do, just change the references to that directory in the coming intsructions.

First, we’ll set up 2 top-level files, which are both quite simple. They set up two nearly identical configurations for the lighty daemon, that run side-by-side. The first scans port 80, and serves http requests. Let’s call this file lighttpd.conf.

include "lighttpd_shared.conf"

server.port = 80

server.errorlog    = "/etc/lighttpd/lighttpd.error.log"
accesslog.filename = "/etc/lighttpd/lighttpd.access.log"

The first line causes lighty to parse the main configuration file, which we’ll go through below. The next line binds lighty to port 80, the default for http, and then we assign error log files.

We do something very similar for the other top-level file, the one that configures the SSL daemon. I’ve called mine lighttpd_ssl.conf.

include "lighttpd_shared.conf"

server.port = 443

server.errorlog    = "/etc/lighttpd/lighttpd_ssl.error.log"
accesslog.filename = "/etc/lighttpd/lighttpd_ssl.access.log"

ssl.engine         = "enable"
ssl.pemfile        = "/etc/lighttpd/host.pem"

In this case, we’ve bound the daemon to port 443, the default for secure connections. We’ve specified log files, and then enabled the SSL engine and specified the path to the .pem file.

By the way, the log files must exist before you run the daemon, and have the right permissions. To do this, simply touch the files, assign them to “www” and set the permissions:

cd /etc/lighttpd
touch lighttpd.error.log
touch lighttpd.access.log
touch lighttpd_ssl.error.log
touch lighttpd_ssl.access.log
sudo chown www *.log
sudo chmod 0666 *log

Now, on to the meat of the matter. Both of our top-level files parse the lighttpd_shared.conf file, so that both daemons run in parallel and do the same things. This means that all pages in our web server can be served with a regular or a secure connection. Here’s the meat:

server.modules = ( "mod_rewrite",
                   "mod_access",
                   "mod_fastcgi",
                   "mod_userdir",
                   "mod_accesslog" )

# Main folder containing web documents
server.document-root = "path/to/main/"

# Allow http://www.domain.com/~username/ style requests
userdir.basepath = "/Users/"
userdir.path = "Sites"
userdir.include-user = ("username") # only allow requests for this user (optional)

# If no file is specified, what to look for?
index-file.names = ( "index.html", "index.htm", "index.php" )

# Required event handler for OS X
server.event-handler = "freebsd-kqueue"

# Run the server under the user-name "www" for security purposes
# To bind to port 80, the server must be called by root user, but we don't want
# the server to have free run of the box, so it runs as "www"
server.username = "www"
server.groupname = "www"

# Set up the appropriate MIME type mappings
mimetype.assign             = (
  ".pdf"          =>      "application/pdf",
  ".sig"          =>      "application/pgp-signature",
  ".spl"          =>      "application/futuresplash",
  ".class"        =>      "application/octet-stream",
  ".ps"           =>      "application/postscript",
  ".torrent"      =>      "application/x-bittorrent",
  ".dvi"          =>      "application/x-dvi",
  ".gz"           =>      "application/x-gzip",
  ".pac"          =>      "application/x-ns-proxy-autoconfig",
  ".swf"          =>      "application/x-shockwave-flash",
  ".tar.gz"       =>      "application/x-tgz",
  ".tgz"          =>      "application/x-tgz",
  ".tar"          =>      "application/x-tar",
  ".zip"          =>      "application/zip",
  ".mp3"          =>      "audio/mpeg",
  ".m3u"          =>      "audio/x-mpegurl",
  ".wma"          =>      "audio/x-ms-wma",
  ".wax"          =>      "audio/x-ms-wax",
  ".ogg"          =>      "application/ogg",
  ".wav"          =>      "audio/x-wav",
  ".gif"          =>      "image/gif",
  ".jpg"          =>      "image/jpeg",
  ".jpeg"         =>      "image/jpeg",
  ".png"          =>      "image/png",
  ".xbm"          =>      "image/x-xbitmap",
  ".xpm"          =>      "image/x-xpixmap",
  ".xwd"          =>      "image/x-xwindowdump",
  ".css"          =>      "text/css",
  ".html"         =>      "text/html",
  ".htm"          =>      "text/html",
  ".js"           =>      "text/javascript",
  ".asc"          =>      "text/plain",
  ".c"            =>      "text/plain",
  ".cpp"          =>      "text/plain",
  ".log"          =>      "text/plain",
  ".conf"         =>      "text/plain",
  ".text"         =>      "text/plain",
  ".txt"          =>      "text/plain",
  ".dtd"          =>      "text/xml",
  ".xml"          =>      "text/xml",
  ".mpeg"         =>      "video/mpeg",
  ".mpg"          =>      "video/mpeg",
  ".mov"          =>      "video/quicktime",
  ".qt"           =>      "video/quicktime",
  ".avi"          =>      "video/x-msvideo",
  ".asf"          =>      "video/x-ms-asf",
  ".asx"          =>      "video/x-ms-asf",
  ".wmv"          =>      "video/x-ms-wmv",
  ".bz2"          =>      "application/x-bzip",
  ".tbz"          =>      "application/x-bzip-compressed-tar",
  ".tar.bz2"      =>      "application/x-bzip-compressed-tar"
 )

# Don't server these files statically, for security
static-file.exclude-extensions = ( ".fcgi", ".php", ".rb", "~", ".inc", ".pl", ".yml" )

# Use mod_access to deny direct access to files ending in ~ or .inc; these are usually
# code or backup files
url.access-deny             = ( "~", ".inc" )

# Disable auto-generated directory listings, for security
dir-listing.activate        = "disable"

# Disable range requests for PDF files
$HTTP["url"] =~ “\.pdf$” {
  server.range-requests = “disable”
}

# Set up a fastcgi server for PHP
fastcgi.server = ( “.php” => ((
                     “bin-path” => “/usr/local/php5-fcgi/bin/php”, # path to php binary
                     “socket” => “/tmp/php.socket”,
                 )))

# Now create virtual subdomains for each rails app we want; myrailsapp.domain.com
# Repeat the following block for each rails app, and for each one
# replace “myrailsapp” with the name of your application
# This sets up separate fcgi processes for each application

$HTTP["host"] =~ “^myrailsapp\.” {
     var.myrailsapp = “/path/to/rails/app”
     server.document-root = var. myrailsapp + “/public”
     server.error-handler-404 = “/dispatch.fcgi”
     fastcgi.server = ( “.fcgi” =>
                     ( “localhost” =>
                         ( “bin-environment” => (”RAILS_ENV” => “production”),
                           “bin-path” => var. myrailsapp + “/public/dispatch.fcgi”,
                            “socket” => “/tmp/myrailsapp.fcgi.socket”
                         )
                      )
                 )
}

You can tweak the fastcgi performance by using the lighttpd instructions for directives such as “min-procs” and “max-procs” but that’s up to you.

Lighty at startup

Wouldn’t it be nice if lighty launched at startup, and we didn’t have to worry about it? How about if it relaunched whenever it crashed? That would be even better. Save the following to /Library/LaunchDaemons/net.lighttpd.plist and watch the magic happen, thanks to froehle:

<?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>net.lighttpd</string>
	<key>OnDemand</key>
	<false />
	<key>Program</key>
	<string>/usr/local/sbin/lighttpd</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/sbin/lighttpd</string>
		<string>-f/path/to/lighttpd.conf</string>
		<string>-D</string>
	</array>
</dict>
</plist>

Oh, wait, before the magic, there’s one more (/Library/LaunchDaemons/net.lighttpd_ssl.plist):

<?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>net.lighttpd_ssl</string>
	<key>OnDemand</key>
	<false />
	<key>Program</key>
	<string>/usr/local/sbin/lighttpd</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/sbin/lighttpd</string>
		<string>-f/path/to/lighttpd_ssl.conf</string>
		<string>-D</string>
	</array>
</dict>
</plist>

Of course, if you’ve installed the lighttpd binary someplace other than /usr/local/sbin then you should change those 2 lines in each .plist file, and you should specify the path to your .conf files properly.

Graceful restarts

Wouldn’t it be super-nice if we could issue graceful restart commands? It’s actually very easy in Tiger (10.4) since launchd monitors apps it has started, and re-opens them if they’ve quit or crashed. That means that all we have to do is cause a graceful shutdown, and launchd will take care of the restart for us. Put the following in /usr/local/sbin/ in a file called “lighttpdctl” (named after apachectl) with the appropriate path to your config files:

#!/bin/sh
sudo killall -9 lighttpd

Make it executable by doing this:

chmod u+x /usr/local/sbin/lighttpdctl

Now, from anywhere (since /usr/local/sbin is in our path), you can call lighttpdctl to do a graceful restart. Note, if you’re running a port 3000-bound script/server development instance of lighty, it will also quit.

We’re done

Well, almost. You now have to restart your machine to have launchd do its thing. If you issue the kill command to lighttpd and the configuration is bad (for whatever reason), and lighty bails on startup, launchd will no longer monitor the process. This means that when you’re mucking around, there’s a lot of sudo lighttpd -f/etc/lighttpd/lighttpd.conf -D from the prompt until you’ve got it working, followed by a restart. I’m pretty sure that there’s a better way to do the config debugging, but I’m not 1337 enough with FreeBSD and launchd-speak to do it any better. If somebody out there knows, please post it in the comments.

Enjoy!

Let’s recap what’s happened, though.

1. MSFT announces that known hacks won’t work, and that developers should rely on conditional comments to target IE. At this point, I thought, “Oh no, here we go. They’re going to prevent us from targeting IE7, and IE7 won’t actually render things properly, so we’ll be left out to hang.”
2. MSFT makes progress, best illustrated by Molly Holzschlag’s recap of IE7’s rendering progress (including the rendering of Malarkey’s site). I’ll admit, with the latest release of IE7 beta 2, I thought there was light at the end of the tunnel. Removing the ability to specifically target IE7 isn’t a problem as long as it renders according to the standards.
3. Roger Johansson points out that the latest IE7 beta, the so-called “layout complete” version, doesn’t clear floats properly! Check the comments if you want to see some vitriol.
4. Nick Rigby points out that the “layout complete” IE7 only fixes 6 of the 7 bugs in his IE7 test suite.

So, essentially, IE7 is still going to be a broken browser, but without hacks we’ll have no way to target it. Wasn’t the whole point to have an IE browser that didn’t need special support? Thanks, Microsoft, you’re doing a bang-up job spending lots of money to make lots of headaches.

script/server

trick for development to be fantastically useful. It’s quick to use, the server itself is fast, and it’s everything I could want. That is, until it’s time to go in to production mode. I’ve been running Apache, using OSX’s built-in build, but I’m considering switching my whole setup over to lighty because of the funkiness of Apache and Ruby’s fcgi. So I tried it. Building lighty was really easy. Getting lighty to then serve my static pages was also very easy. Then I tried getting it to serve my ruby apps, and that’s where the problems hit.

It turns out that my one big config problem was this: “url.rewrite” does not work inside a $HTTP["url"] matching block. So, for example consider this case, where I want to rewrite URL’s intended for my rails app which has 2 controllers, admin and view:

$HTTP["url"] =~ “^/input_path/” {
  url.rewrite-once (”/(admin|view)/(.*)” => “/some/other/path/$1/$2″)
}

If the incoming URL matches “/input_path/” then lighty starts processing the code inside the braces, but the url.rewrite-once fails to act. Instead, the server will invariably look for files inside /input_path/ and serve up a 404.

The proper way to do this sort of work with lighty is to have the regex do all the work:

url.rewrite-once ("^/input_path/(admin|view)/(.*)" => "some/other/path/$1/$2")

This isn’t documented anywhere on the lighty web site, but there is a message on the lighty mailing list that points out the problem.

I have to say, other than this hitch, I’ve been very impressed with the speed and ease of configuration that lighty offers. Once I get PHP to work with it, I’ll be a happy camper.

I recently had a rather interesting problem, however. My first teaching project was a little app to generate a bookmarks page, and it allows me to categorize bookmarks. Relatively straightforward, right? Well, I got the code to handle logging in, the categories, subcategories and bookmarks done just fine with no hitches, but then I wanted to test out caching.

In development.rb I set caching to true, and then enable page caching on my “view” controller &emdash; the one that is not behind the login and simply outputs the bookmarks list. I reload the page, and presto, the index.html page magically appears in my app’s public folder. “Sweet,” I think. I then edit one of the pieces of bookmark data, and my sweeper class kicks in, logs that it is expiring the page, and then expires the page.

  def expire_view(model)
    model.logger.info("Expiring the cached index")
    expire_page(:controller => "view", :action => "index")
  end

Except that the page doesn’t actually expire. What the f*@#!?!

After several days of poking around, trying action caching instead, and a few posts to various forums, I figured out what the problem was. I had reconfigured my routes.rb to essentially point all bogus URL’s to the view::index action, which was the page being cached. After I changed routes.rb back, the page started expiring. I’m guessing that :caches_page and expire_page() only work when there are single URL’s pointing to the page being cached. Has anybody else had a similar experience?