If you set your page’s body height to 100% and your window is 900 pixels high, you would expect your body to be 900 pixels tall. This seems to be supported in both IE and Firefox 1.0.7.
What about 200%? IE gets this right, Firefox says 3600! WTF.
Here’s a set of readings of the body.offsetHeight property:
Not what I was expecting.
Rails on my blog’s host server was upgraded to the latest RC early this morning. My Typo 2.5.5 got very upset with this, and my blog has been down all day.
Upgrading my Typo was fairly easy. Sync up the code on my dev machine, use WinSCP to sync the directories up (fix up the .htaccess file, because I failed to merge the conflicts before I started!) I had to restore my /public/files directory as the WinSCP sync deleted it.
When you run the Typo Admin code after this, it detects that a DB migration is needed and does the work for you. Sweet!
Lisa noticed that my blog sidebar was all screwed up. The problem is that my blog has code snippets using the typocode filter for Typo. The CSS to layout the code works great in Firefox, but doesn’t in IE.
I changed my azure theme CSS definition for the .typocode selector to have a width – 500 pixels works for this theme – and an overflow setting of auto to cause the scrollbars to show up. The existing CSS has a selector for .typocode pre that has overflow: auto, but this didn’t work for IE. Moving this up to the .typocode selector and adding the width is the key.
Rails provides a simple mechanism to allow the output from an action to be cached. Unlike the page caching, this allows all the filters to be executed, then the cached results returned. The filters executing is important for authentication.
This is great until you have an action that returns something with send_data (send_file probably has the same issue). Caching just doesn’t work in this case, and sends the wrong data to the client when the cache is hit.
Don’t use Action caching on actions that return binary data.
Update: I’ve written some code that fixes this problem, and documented it here
Lisa and I are members of a team of people that do Microsoft Puzzlehunt whenever it comes around (a little more frequently that once a year). Over the weekend we did Puzzlehunt 9. This year, we were 31st out of 62 teams.
We seem to be solving about the same number of puzzles every year, but we keep slipping back in the overall classification. Every other team seems to be getting better!
This time, we ate too much bad food, stayed up way too late, and tried to work on complex things without enough sleep.
We did have a good time!
I have a Rails app that uses lighttpd. My app has a bunch of routes setup to handle incoming requests. Lighttpd has a set of re-write rules to convert the incoming request into calls into dispatch.fcgi. This is the default configuration.
One thing that hadn’t been made very clear to me until I went looking for it is that the lighttpd re-write rules are no longer necessary.
To get the requests into my Rails app, all I need to do is define dispatch.fcgi as my 404 handler, and any request that doesn’t exist in the file system will be handled by my Rails app.
This is fully documented here but as I said, it wasn’t obvious to me until I needed to fix it!
I spent a bunch of time getting some code running on a Debian configuration last night. Mostly, the instructions from the bougy man
are pretty good, but I ran into a few issues that weren’t covered there.
1. Debian Ruby package seems to suck. It looks like this is common knowledge, but still a pain. I had to build the Ruby code from scratch. Source downloads can be got from ruby-lang.org
2. You need to build FastCGI. This code can be got from fastcgi.com
3. The gems code is now up at version 0.8.11, so substitute those numbers in the RailsOnDebian instructions to get the latest.
My development environment is Windows. My production environment will be some form of Linux. I have a Debian server setup to test production issues. I have started playing with SwitchTower to deploy my production environment.
Once I’d set the whole thing up, SwitchTower almost worked first time. I eventually found the two reasons it didn’t work first time:
So, how to solve this? A quick search through the subversion documentation found two items:
Adding these two properties to my Rails scripts (dispatch.fcgi and everything in the script directory) and all is well with my SwitchTower processing.
We have a medium size Big Green Egg Currently, it contains about 10lbs of pork butt, smoking at about 250F (a little warm, but I’m working on it). After about 16-18 hours, this cheap piece of meat will be fantasic!
With a little of Lisa’s BBQ sauce, this is a food item that people fight over at our parties.
The Big Green Egg makes this process very easy. The thing lights up really easily, retains heat really well and will go at 200-250F on a single load of charcoal for 14-18 hours. Its almost foolproof.
Strangly, I purchased a house from Leo and his wife back in 1997.