The more I think about it, the more I think that we need controller tests in Rails that don’t render. Functional tests just don’t cut it if you’ve got anything non-trivial in either the controller actions or the view. I know we should be aiming for simplicity in precisely those places, but sometimes you just can’t distill everything into a fat model.
Looks like I’m not going to be using restful_authentication on this project. The instructions are convoluted, and what you end up with doesn’t test cleanly. Can’t be bothered with that. While I’m in learn-mode, authlogic looks like a better bet; I also like the fact that someone else has realised that model > ORM model.
Yup, that pretty much sums it up.
I’ve been fairly thoroughly exposed to Darcs, Mercurial, Git and Subversion now. The problems I’ve had have been hashed over in a thousand blog posts by others who tried all this out before me, so I won’t bother with tales of slowness, really slowness, or the revelation of git branching and stashing. Nor will I complain about git’s learning curve.
I just don’t think I’ll be using any of the others except for legacy codebases now. What finally sealed the deal was the realisation that git’s submodules were just svn:externals in disguise. Oh, and the fact that pretty much all the third party code I’m interfacing with these days is on Github.
So… first green fields Major Project in a while. It’s a Rails app, but I’m shifting to PostgreSQL and Amazon EC2/S3 for a bunch of it, so there’s going to be a fair amount of new learnings here.
It also feels slightly odd to be jumping back into Rails again. I’ve not done any new Rails work for a little while; the majority of my consulting has been on apps frozen at 2.1, so it’ll be good to be working on the fresh code-base.
I’ve shut down Other People Work for the next couple of weeks to get this project out of the door, although I reckon that what with various travel and visiting plans, I’ve only got about 2/3rds of that time to play with.
No time to hang around here blogging, there’s work to be done!
I know I shouldn’t leave it so long, but I’ve just updated to WP 2.7.1.
The new admin interface rocks. I could never see the point of the old dashboard, whereas this is actually useful.
When I try to use rawr on Windows, I get this:
=== Creating jar file: C:/Users/Alex/Documents/Projects/hello_world/package/jar/ChangeMe.jar
rake aborted!
stat.st_gid unsupported on this platform
It looks like the version of rubyzip bundled with rawr has a malfunctioning test for Windows:
RUNNING_ON_WINDOWS = /mswin32|cygwin|mingw|bccwin/ =~ RUBY_PLATFORM
That’s bound to fail on jruby:
C:\Users\Alex\Documents\Projects\hello_world>jirb
irb(main):001:0> RUBY_PLATFORM
=> "java"
I’m not sure what the “official” fix for this is; I’ll post an update once I’ve figured it out.
Update: I don’t know if it’s in any way proper, but editing the above test in %JRUBY_HOME%/lib/ruby/gems/1.8/gems/rawr-1.1.0/lib/zip/zip.rb to read:
RUNNING_ON_WINDOWS = (/mswin32|cygwin|mingw|bccwin/ =~ RUBY_PLATFORM) ||
(/Windows/ =~ ENV['OS'])
seems to allow the jar file to be built, and the executable file to be generated, but it doesn’t actually run. Hm. More work needed here.
Further Update: There’s a better fix in rawr’s gitorious repository for this now using rbconfig. I’m still working (with Logan Barnett’s sterling help) on getting it working.
Well, that was fun. Got up in front of the camera for the first time, which was different. It’s run park-bench style, so there need to be 3 speakers to kick things off; since I’d contributed to the opening question, I was picked.
This method of picking speakers does break the ice, but it also ensures that the first people up know nothing about the subject they’re asking about. I always feel like I’m not really contributing anything useful under those sorts of circumstances. I know I’m not good at thinking on my feet (how difficult should it be to explain mixins and Modules, really? Gah) but maybe I just need practice.
I definitely learned useful stuff, though. For starters, I think I’ve pretty much got a handle on AOP now, and where it might be useful. There’s a chance it might come in handy on a Rails app I’m working on. I know DHH and the others rejected AOP as an overall approach for the framework early on, but there’s a layer between the framework and the domain models where inheritance is a bit of a bodge. Hell, inheritance is the wrong way to do serialisation in my book – why does my Account class care about the database? Anyhow, I guess that’s opinion for you.
Also REST: now I get it. I didn’t see before how all the various parts of a practical web page fit into the REST style; you need some way to move navigation, personalisation and so on out of the resource, and ajax makes that trivial. I don’t know why I hadn’t seen that before. I’m still unsure on how to degrade it gracefully, but it’s one more piece of the puzzle.
There’s still not a lot of IronRuby noise, which surprises me, although there were a couple of other Rubyists around last night. I must make more contact with the London Ruby set, they seem like a fun bunch.
Also ended up drinking in Soho on a school night. This was Fun.
This bug is seriously unimpressive. It’s a six-year-old NEW bug which has just cost me (and my client) 3 days’ work. It makes SOCKS v5 essentially useless with Firefox, because there’s no way to specify the username/password pair to authenticate against the proxy.
Ok, so no other browser gets this right either. So what? Circuit-level proxies work with just about every other class of application, you’d have thought it’d be manageable here.
Feck. Back to the drawing board.
Why does Vista’s default visual theme have so little contrast between the focused window and the background? I can’t count the number of times in the past couple of days that I’ve sent input to the wrong window because I can’t tell the difference between foreground and background windows with my peripheral vision.
Bye bye Aero. I don’t think you’ll be missed.
I’ve just upgraded to Wordpress 2.6, and it struck me that it’d be handy to have a script to do this automatically. I’m sure others have their own versions of this, but here’s mine:
#!/bin/bash
DATESTAMP=`date "+%Y%m%d%H%M%S"`
# All these should be absolute paths so that symlinks work properly
NEWCODE=$(pwd)/blog/wordpress-$DATESTAMP
CURRENT=$(pwd)/blog/current
SHARED=$(pwd)/blog/shared
wget -O blog/latest.tar.gz http://www.wordpress.org/latest.tar.gz
# Extract it and change the directory name
tar -zxf blog/latest.tar.gz -C ./blog
mv blog/wordpress $NEWCODE
# Copy the new content code into the shared directory
cp -a $NEWCODE/wp-content $SHARED/wp-content
# Remove it and then link it back in. This preserves installed themes
rm -rf $NEWCODE/wp-content
ln -s $SHARED/wp-content $NEWCODE/wp-content
# Link the config in
ln -s $SHARED/wp-config.php $NEWCODE/wp-config.php
# Clobber the old link
rm -f $CURRENT
# Make a new one
ln -s $NEWCODE $CURRENT
There are a couple of rough edges (like not moving $CURRENT sideways before deleting it so that requests that come in mid-process aren’t broken), but it works for me. It assumes that you’ve got the directory ~/blog/shared, containing wp-config.php and your wp-content directory, and the new version of Wordpress will be installed at ~/blog/current (symlinked to a datestamped folder), so that’s where Apache should be pointed.