alexjsharp.com

This may seem like a bit of an edge case, but if you’re using a setup similar to mine, it is very relevant. Here’s the long and short of it: if you’re hosting private git repositories on a server that only allows access to a non-standard ssh port (i.e. not port 22), then you must build git from source. The reason for this is that the version of git in the Ubuntu Gutsy package manager is 1.5.2 (as of this writing), and that version does not support specifying port numbers in your remote urls. Pooey.

So, we have to build git from source. I highly recommend following this tutorial. That post doesn’t cover installing the git documentation, so I’ll hit on that real quick. Follow Chris’ post until you get to the last section, where you compile and install git.

To install the man pages, you need to install a monstrosity of a package (somewhere around 700mb after installed) called asciidoc. Note: this will take A WHILE. (If anyone knows how to do this without downloading a 700mb package, please let me know and I’ll update this post.)

sudo aptitude install asciidoc 

Now, download and unpack the latest stable version of git, and substitute these last two steps for the one’s Chris has:

make MOZILLA_SHA1=1 prefix=/usr all doc
sudo make MOZILLA_SHA1=1 prefix=/usr install install-doc

It’s July 4th, and I’ve been posting about css and cool job postings. How selfish of me.

Happy birthday America!

I am not a css designer. I hate the language, I hate the implementation, I hate the inconsistency of browser support. This is no fault of css or the good people who have pioneered and built the language. Rather, it is more the nature of a client-side technology. Javascript has suffered many of the same problems, but cross-browser support has gotten noticeably better in recent years.

Unfortunately, css is probably the one web technology (other than HTML) that is nearly impossible not to use. For the most part, my deep hatred of css programming is due to the “hackish” nature the language has been forced to adopt, almost exclusively because of Microsoft Internet Explorer 5.5 and 6, the massive number of bugs these browsers have, and Microsoft’s failure to patch these browsers. That said, let’s get on with it.

Often I need to display a series of items on the same line. Whenever possible, I try not to use floats because of the plethora of bugs in earlier versions of IE. My first attempt is often to use <li>’s, set list-style: none; and display: inline;. However, due to the nature of how a display: inline; element is meant to be displayed, this approach is simply not useful for any type of content beyond a menu/nav bar. So, we are forced to float the list items. I don’t know about you, but I feel defeated.

First, here’s a sample of what kind of data we need to display:

<ul id="products">
  <li>
    <div class="prod_img"><img src="path/to/image" alt="blah" /></div>
    <div class="description">
      <strong>Here's a little description.</strong><br />
      <span>Here's some more.</span>
    </div>
  </li>
  <li>...</li>
</ul>

And here’s the style rules that should satisfy our needs:

ul#products {
  list-style: none; 
  overflow: auto;
  border: 1px solid black; /* border added to illustrate forthcoming IE display bug */
}
ul#products li {
  list-style: none;
  float: left;
}

We have the overflow: auto; declaration so that the containing ul “hasLayout”. We have to to do this when a containing element contains all floats, or elements that don’t flow in the normal course of the document. As expected, IE 6 screws this up. We have to add a seemingly ambiguous height property declaration:

ul#products {
  height: 100%;
}

There, now we’ve got it. Inline list items that can contain block-level items, while remaining on the same line.

A short rant

Maybe this a bit whiny/preachy, but having to resort to this kind of thing royally pisses me off. It’s not that it’s a lot to type, or that I had to implement some css hack that only IE version x will recognize. No, it’s simply that I had to make a special exception just for older versions of IE, while everything else works the way it’s supposed to work.

That, in a nutshell, is why I enjoy server-side programming, and why I for the most part deplore client-side programming. With server-side technologies, you know your boundaries. You are confined to the limits of your server operating system software, and the limits of the language in which you’re working. If you work within those limits, generally speaking, things will work the way they are supposed to work.

With client-side technologies, namely CSS, you end up spending just as much time learning and implementing the bugs, workarounds, and compatibility issues that you do actually writing code! This problem is not exclusive to Microsoft, albeit they are a big part of it. A perfect example is cross-browser compatibility for the various css display modes. All of those display properties have been part of CSS since CSS version 2 was released. Are you ready for a laugh? CSS2 was released in May 1998, now more than 10 years ago! Seriously!? Ten years, and we still can’t get cross browser support for inline-block. Rant over.

Check this out. What a great way to advertise a position.

If you, like me, are the type who occasionally likes to resize your text while reading a web page, you may be unhappy with how Firefox 3 handles this. In Firefox 2, and all other browsers (to my knowledge), the browser simply resizes the text on the page. In Firefox 3, images and everything are resized/re-rendered. I don't like this; all I want is my text resized, not a bunch of blurry images while I'm trying to ready. Eh.

I recently published my first public plugin called mass_assignment_murderer. You can get it here from github. Currently, a subversion release is not planned. Basically, the plugin addresses the mass assignment problem covered in Railscast Episode 26.

mass_assignment_murderer provides an ActiveRecord class method cleverly titled, has_mass_assignment_murderer, which protects your models from mass assignment through a has_many or many-to-many association. Specifically, it looks for an methods that end with “_ids” and then calls attr_protected on those methods.

For a future version, I’m thinking of simply auto-protecting all such methods in all models, without having to make any sort of declaration.

Thanks to Radar on the #rubyonrails irc channel for showing me the way with this one. Basically, I updated my rails gem to rails 2.1, and I had not frozen rails in all of my projects. This broke my mephisto project for this site on my development machine, so I wanted to freeze rails version 2.0.2 to this project. Here’s how it’s done:

rake rails:freeze:gems VERSION=2.0.2

If you didn’t have the pleasure of experiencing the awesome memory leak rubygems 1.1 caused, consider yourself lucky. If you are on a modestly sized VPS, such as a slicehost 256 mb slice, I do not recommend running gem update --system to upgrade rubygems. It is almost sure to slow your server to a screeching halt. Here’s how you install it manually:

mkdir ~/sources
cd ~/sources
wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz # you could use curl instead of wget, it just depends what is installed on your system
tar -zxvf rubygems-1.2.0.tgz
cd rubygems-1.2.0
sudo ruby setup.rb

And you’re good to go! No more memory leak.

Finally! I may be the happiest blogrammer (that’s blogger + programmer = blogrammer) right now! I finally solved the multitude of problems described in a previous post. My requirements were pretty straightforward: I wanted to use a non-standard SSH port, and I wanted to rely on public key authentication, no passwords.

Capistrano kept spitting out the “Permission denied (publickey)” error. This made no sense to me, because I can SSH to my server just fine. I was totally stumped, until I found this. The problem was that I’m hosting my git repository and my application on the same server. Basically, my server was trying to ssh to itself, and it was getting denied, because I had not set up a public key for my server, only my local workstation.

At that point, the solution is simple. Just run the following command from your server: ssh-keygen -t rsa. Hit ‘enter’ through all the prompts (unless you want a password), and you now have a ssh public key at ~/.ssh/id_rsa.pub. Open this file in your favorite text editor, copy the entire file, and paste it at the bottom of ~/.ssh/authorized_keys. (There will likely only be one really long line in this file, so make sure you start a new line and then paste it in.)

Now, here’s what my ‘deploy.rb’ file looks like:

set :application, "example.com" 
set :scm, "git" 
set :deploy_via, :remote_cache
set :repository, "ssh://username@example.com:11155/home/username/git_repos/repo.git" 
default_run_options[:pty] = true
set :app_server, "example.com" 

set :user, "username" 
set :runner, user
set :port, 11155
set :deploy_to, "/home/username/public_html/#{app_server}" 
role :app, application
role :web, application
role :db,  application, :primary => true 

So I decided to participate in the "let's all download Firefox 3 at the same time and crash the server" frenzy, and I got my Firefox 3. As a mac user, I will say that I am happy that Firefox 3 is now a native mac application, which I think means that it is Cocoa-based? Still, I have a few reservations.

First, the damn thing looks exactly like Safari. I suppose that may not be a bad thing, seeing as how Firefox 2.x was one of the more visually displeasing OS X applications you could possibly feast your eyes upon. Still, maybe a little originality in the UI would have been nice. I'm also not crazy about all the browsing history madness that comes up when I'm typing in a URL. It's just too much crap on the screen, and I find it a bit distracting.



There's just way too much going on there with all the colors and icons, and it's just a bit overwhelming. Other than that, everything seems to be ship shape. As long as I don't get any more infinitely spinning rainbow wheels, I'm a happy camper.

I just noticed that script/plugin install now accepts a git:// url protocol. So, why should you use script/plugin install instead of just cloning a repository into your plugins directory? Because using the install command automatically executes the plugin's "install.rb" file. Most plugins don't make use of it, because most plugins don't need to; but for others it can be very important.

This is more a record of my own thoughts and errors than a real post. So, reader beware.

Since switching my scm from subversion to git, I’ve run into a host of deployment problems with capistrano:

1. I can no longer deploy without supplying my server password. I have ssh configured on my server to perform public key authentication, so I don’t need to enter a password. Still, I keep the PasswordAuthentication option set to ‘yes’. I would like to turn this off, for security purposes.
2. I have to put default_run_options[:pty] = true in my deploy.rb file. I never had to do this before, and this is the line that requires me to enter my server password.
3. :deploy_via, :remote_cache doesn’t work. If I put this line in my deploy.rb file, it causes my deployment to fail. The update goes lightning quick anyway so I suppose it isn’t a big deal, but the fact that it breaks my deployment recipe just irks me.

If any other slicehost account holders are having similar problems please leave a comment or shoot me an email; maybe we can get this madness worked out.

So I finally decided to ditch wordpress and move to mephisto. The process was a bit more difficult than I'd hoped it would be, particularly due to switching my scm to the red-hot git. I still don't completely understand what was causing my errors, but I think once I figure it out, I'll write a post for fellow slicehost account holders looking to make a similar switch.