I’m running the standard MacOSX package install from mysql.com (Mac OS X 10.5 x86_64). I tried setting my ARCHFLAGS to the correct architecture, pointing to the correct config, and nothing helped. After Google turned up nothing, I decided to bother the nice folks in the #rvm channel. There I was given a handy little tip that goes as follows:

1. Uninstall the version of Ruby you’re trying to install the MySQL gem on
2. place the following in your ~/.rvmrc file:

   rvm_archflags="-arch x86_64"

3. Reinstall Ruby using RVM
4. Install the ruby gem:

   export ARCHFLAGS="-arch x86_64" ; gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

   (use the correct path to your MySQL config file. If you installed mysql with MacPorts, it will be in /opt somewhere).

The problem turned out to be that RVM was not installing the x86_64 version of Ruby 1.9. And if Ruby’s architecture doesn’t match MySQL’s, then you have problems. Once they match, then it’s back to Ruby bliss.

class Foo < ActiveRecord::Base
  serialize :bar
end

In this instance, assume an object of type “Bar” is what’s being serialized. After save, the data appears fine, but when you retrieve the data, instead of your Object you end up with yaml that looks like this:

[#<YAML::Object:0x3fcade8 @ivars={"attributes_cache"=>{}, "attributes"=>{"updated_at"=>"2008-11-04 19:33:05", "id"=>"1", "message"=>"Hello World!", "created_at"=>"2008-11-04 19:33:05"}}, @class="Bar">

This most likely means that the model of the object being serialized is not loaded yet. This can be resolved by simply doing:

class Foo < ActiveRecord::Base
  Bar

  serialize :bar
end

This will load the model before serialization occurs and you’ll be all set.

While trying to figure out what was going on, a couple of things became apparent. If I moved tests around or deleted specific tests (mainly update and destroy tests), it caused previously failing tests to pass. Also, setting “self.use_transactional_fixtures” to false in “test_helper.rb” caused most tests to pass. As I was checking on that further in one of my apps (one that I didn’t delete all the comments from), I noticed this:

“Every Active Record database supports transactions except MyISAM tables in MySQL.  Turn off transactional fixtures in this case; however, if you don’t care one way or the other, switching from MyISAM to InnoDB tables is recommended.”

Cue the lightbulb.

Jumping into mysql and running “show engines;” confirmed the bulb. InnoDB was disabled. So now we ned to remedy this little problem.

If you already have a ‘my.cnf’ file, you’re ahead of the class, so please hold on while the rest of us catch up.

The MySQL package installer drops mysql in:

/usr/local/mysql

If you look in the support-files directory, they have several my.cnf sample files. So now we need to get one of these into play.

Copy

/usr/local/mysql/support-files/my-medium.cnf

to

/etc/my.cnf

At this time I’d like to welcome back those of you who already had a my.cnf file.

Now open your my.cnf file and uncomment the lines that start with “innodb_” (starting at line 123 in my config file). Save the file and restart MySQL. If you go back into mysql and rerun “show engines;”, you should now see InnoDB support has been enabled.

Now when you run your tests, all should be well in the world again.

You can comment out ERb delimiters in your view by adding a pound sign before the equal sign.

<%#= str %>

When rendering a collection, you have access to a zero-based “partial_counter” variable that increments on each iteration.

<%= div_for(entry) do %>
	<%= entry_counter %>
<% end  %>

Todays lesson brought you by chapter 10 of “The Rails Way” by Obie Fernandez.

About a year and a half ago, however, I switched jobs and found myself dealing with the CSS of others that was quite different from my own. They went on about how nice their style was and how in time I would come around. After all, they all eventually adapted to the same style. I was fairly adamant at the time that, no, I was pretty set in my style ways and didn’t see myself switching any time soon. It only took a couple of months.

My style at the time was a declaration with each property on its own line.

body {
  margin:0;
  padding:0;
}

The style of the new shop was to use single line styles as follows:

body {margin:0; padding:0;}

Since the time I switched over, I’ve grown to love this format. My initial argument against it was I felt it was harder to read and find the individual declaration I was looking for. But if you follow a simple set of rules, it’s actually very easy to scan a large css file and find what you’re looking for.

Out of curiosity, I checked out the CSS of some bloggers I read to see what styles they use.

The closest I could find to my old style was Paul Boag. Here’s a sample:

body {
  background:#d6e59b url(../images/background.jpg);
  padding:2em 0;
}

#content {
  width:600px;
  padding:0 20px 0 30px;
}

Very similar to that style is Dan Cederholm of simplebits.com

body {
  margin: 0;
  padding: 0;
  font-family: "Lucida Grande", "Lucida Sans Unicode", "Lucida Sans", Helvetica, Arial, sans-serif;
  font-size: 62.5%;
  color: #474a51;
  background: #f4f4ed;
  }
a:link, a:visited {
  color: #317b9e;
  text-decoration: none;
  }

You can see two differences here. The closing brace is tabbed in with the declarations, and he puts a space between the declaration and the values, as Boag does not.

Now we’ll get into some developers using single line declarations. First off is Eric Meyer. You’ll notice he does ‘mostly’ single line. The body declaration is broken over a couple of lines. If you scan through the css at meyerweb, you’ll see several instances of that treatment. Eric also does the space between the declaration and the value.

* {font-size: 100%; padding: 0; margin: 0;}
body {font: 0.84em/1.333 Arial, sans-serif; margin: 0; padding: 0;
  color: #202020; background: #FFF;
  min-width: 40em; margin: 0 auto;}
h1 {font-size: 2em; margin: 2em 0 0.5em; padding: 0.25em 0;}
h2 {font-size: 1.5em; margin: 2em 0 0.33em; padding: 0.25em 0;}

Next up is A List Apart and Dan Rubin from superflousbanter.org. Both use primarily single line styles. The differences you’ll notice are A List Apart puts spaces between pretty much everything.

* {margin: 0; padding: 0;}
body {font: 0.8125em Verdana, sans-serif; line-height: 1; color: #333; background: #FFF;}
html body a:hover {color: #000; background-color: #F4F2E4;
  border-bottom: 1px solid #9A8E51;}
h2 {font: 1.5em Georgia, "Times New Roman", serif; letter-spacing: 1px;}
h3 {font: bold 1em Verdana, Arial, sans-serif; letter-spacing: 2px;
  text-transform: uppercase;}

Dan Rubin on the other hand uses no spaces except for the right before and after the braces.

body { background-color:#210D00;font-family:helvetica,arial,sans-serif;font-size:small;text-align:center;min-width:1000px;margin:0; }
#content { float:left;background:url(../i/bg_content_top.gif) no-repeat;width:618px;margin:58px 0 0 37px;padding:16px 0 0; }
#content2 { background:url(../i/bg_content_bottom.gif) no-repeat bottom;padding:0 0 16px; }
#content3 { background:#fff url(../i/bg_content_middle.gif) repeat-y;padding:3px 60px 1px; }

Finally, we come to Ordered List. This style is almost exactly like the what I use. This is because the two members of OL are both former lead developers of my department.

.wrapper            {float:left; display:inline; width:940px;}
.primary            {float:left; display:inline; width:630px; border-left:320px solid transparent; margin:0 0 0 10px;}
div#post_info h4    {color:#C0BA8D; font-size:116%; margin:0 0 15px;}

I realize that some people style a certain way due to the editor used when cutting the site. For instance, I use Coda to code HTML/CSS. When it auto-completes a style, it will put a space between the colon and the value. I find this very annoying. Especially since editors such as CSSEdit (also in my Dock) has had a preference for default spacing for years. Hopefully their upcoming all-in-one editor, Espresso, will have that as well (the current beta does not).

One final note. This site was styled prior to my metamorphasis with a lot of WordPress styles rolling over, so yes, it’s in the old style, and probably will be for quite some time.