reeses or tabasco? 1

Posted by s.f. on December 29, 2008

Everybody’s talking about it. Couple of days in jail, whole town changes, etc.

There are two camps over this currently: the Rails side(”Whoo! Chocolate in my peanut-butter! Less magic and plugins that don’t explode randomly between versions!”), and the Merb side(”DHH is going to defenestrate us all! They won’t taste great! These books from the tech section are out-of-date six months earlier than usual!”

I’m mostly in the Rails camp(due to work), with a little of the Merb camp. It would be nice to keep them existing as separate frameworks, if only because of the other elephant in the room: the Rails-branding(read: money) and need to provide splashdown points for decamping Java webapp programmers. However, the Merb team seems to think this won’t be an issue, so I’ll reserve judgment for when the behemoth finally appears.

In any case, the fact that DHH and the Rails team are willing to adopt formal APIs, clearly define module boundaries, and leave monkey-patching behind is a welcome sign.

a huge beanie is approaching fast 1

Posted by s.f. on November 25, 2008

In Rails, one form helper(well, besides a broken date_select) stands alone as cruel, sadistic, and impossible-to-please with just a simple hash. That form helper’s name: option_groups_from_collection_for_select.

It’s so painful that most people would re-implement it, rather than fall victim to its NoMethodError wails. But that’s not the path for us. When you’re using something like Base Without Table to clean up your email contact forms, you don’t have time to mess around with o_g_f_c_f_s’ hunger for has_many. That’s when you pull out OpenStruct, and cleave the beast in twain.
Continue reading…

Builder, indentation, and namespaces

Posted by s.f. on September 04, 2008

Builder is a neat piece of kit but, like most sane libraries, wasn’t designed around the brain-damage that is Business-dialect XML(chock full of custom namespaces and tags devoted solely to attributes).

Builder’s docs seem to imply that a namespaced tag always needs to be in block form:

xml.bqcm :UselessMetadata {|n| n<< "flue"}

or

xml.bqcm :UselessMetadata do xml.text!("flue") end

But you’ll end up with wonky indenting because Builder is sensibly expecting that you should take care of the whitespace yourself when using this form:

<bqcm:UselessMetadata>
flue
</bqcm:UselessMetadata>

The clean way to do it is giving the symbol as the first argument:

xml.bqcm(:UselessMetadata, "flue")

which provides:

<bqcm:UselessMetadata>flue</bqcm:UselessMetadata>

EDIT(2:18pm)
“But what if I have attributes AND a simple text value?”
Just make sure the attributes are sent in an explicit hash as the second parameter:

xml.bqcm(:UselessMetadata, {:QuestionableAttribute=>"chimney"}, "flue")

“I still want to send my text like I was doing, and I want proper indenting NOW NOW NOW”
Fair enough:


xml.bqcm :UselessMetadata do
xml.__send__ :_indent
xml.text!("flue")
xml.__send__ :_newline
end

it “should insert foot in mouth” do … end

Posted by s.f. on June 15, 2008

Last time, I was complaining about rSpec refusing to play nice with the TextMate plugin. I owe the team an apology(in the unlikelihood event of them actually reading the entry), as getting it working is a bit confusing.

On my systems, the TM plugin would insist that I had an ancient rails/rubygems version, and to try upgrading. After a long headscratch, I deduced that it was probably seeing the ancient Apple-installed gems even though I have shiny MacPorts-installed gems. For some reason, the TM plugin will ignore your .bash config files and even any TM_RUBY variables you try to set in the project. Instead, you’ll need to add a PATH variable to your underlying MacOSX environment file(~/.MacOSX/environment.plist).

Take your PATH from your bash profile(specifying your preferred location for rSpec/ruby/macports/etc.) and place it into a key just like the other variables in the file. Mine ended up looking like:
<key>PATH</key>
<string>/opt/local/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bi
n:/usr/sbin</string>
Save the file, then logout/reboot. The TM plugin should now be working.

After getting it working, I can say it’s been a resounding success in my testing. All of the new features for Depot Central have been thoroughly spec’d out, and even though this release will open the floodgates for public posting, it’s been the least problematic so far.

God, sphinx, and you

Posted by s.f. on April 15, 2008

god is my newest favorite tool for server and Rails monitoring, not to mention the entertaining conversations it can produce(”God was spanking the mongrels repeatedly, without letting them fully start”, “god spammed my mailbox with over 700 emails this weekend”, “I’m killing god right now, it should be back in a minute”). One of the last pieces I forgot to include in this setup was Sphinx and, in an apt demonstration of Murphy’s law, it decided to silently die this weekend while I was out of town. So the first thing I did today was to let god manage it as well.

One hurdle people might run into is whether to let god auto-daemonize the process(a useful feature indeed), but our hand is forced by Sphinx already daemonizing itself along with its own PID file(trying to let both god and a process daemonize itself is pretty much crossing the streams). Fortunately, sphinx provides its own “stop” command so we don’t have to go crazy trying to lookup a PID in our god config:


w.start = "searchd -c #{RAILS_ROOT}/config/#{RAILS_ENV}.sphinx.conf"
w.stop = "searchd -c #{RAILS_ROOT}/config/#{RAILS_ENV}.sphinx.conf --stop"
w.pid_file = File.join(RAILS_ROOT, "log/searchd.#{RAILS_ENV}.pid")
Easy peasy. I absolutely adore god's ability to plug into the event system on OSX, so between god and launchd, I've almost got a bulletproof config[1].

[1] “bulletproof” for the value of “resists .22 rounds hand-thrown at it by a grade-schooler”, mind you.

testing to irritation 2

Posted by s.f. on March 31, 2008

So after wasting spending a few days checking out other test frameworks for Ruby/Rails, I’ve come up with this:

Rspec:
The Textmate plugin is barely useable; it appears to have a completely different manner of loading files versus the standard spec command(placing a spec file next to its target and doing a simple ‘require’ worked for the spec binary; the Textmate plugin waves its hands desperately). Wolf howls and tumbleweed are all that is received from asking about it on the #rspec IRC channel.
The bundle works OK under Rails,but of course now the simple use of cache_fu is freaking it out when coming to fixtures(and not even guarding the acts_as_cached statement with ‘defined?’ works because rSpec hooks into Kernel and does all kind of crazy voodoo).
This post gushes about “rspec leaving TDD in the dust”, I’ll believe it when some more consistency is gained.
rspec’ers are going to accuse me of being another idiot user who can’t set up their system correctly. I’ve setup Mysql multiple times(binary release, DarwinPorts, Macports, version) and made countless other mistakes(and fixed them) on my G4 laptop since 2004; I have a hard time thinking that some obvious mistake I’ve made is gumming up the works.

Shoulda would be a nice alternative(plugs into existing test/unit, but it depends heavily on autotest, and autotest still petulantly refuses to believe in namespaced Rails controllers, despite the availability of a patch. I may try updating the patch in the next day or two and giving it another go, but after two days and negative productivity gains, my gut feels like sticking with Test/Unit and friends, because They Just Work. And Just Working is rated higher in my book, no matter what sexy new features are in abundance(like mocking/stubbing)

sittin’ calm after pres butan 2

Posted by s.f. on March 11, 2008

Last Monday, the Rails pseudo-content-management-system that I’ve been working on for the past nine months went live at the Yakima Herald.com, replacing a 4-year old system that ezmobius designed as his first Rails project.

This one’s brand-spankin’ new: Rails 2.0 from the get-go, fairly proper REST(where possible), using a dedicated SQL database, adherence to clean design(again, where possible), and copious use of plugins.
(current favorites: has_finder, thinking_sphinx, acts_as_state_machine, will_paginate, and acl_system2).

Granted, there’s still holes, and I’m already working to fix some poor architectural assumptions I made four months ago, but the newsroom is breathing relief at not having to jump through server hoops anymore(which weren’t ezmobius’ fault so much as limitations of tech and budget at the time).

Now eagerly waiting to see if I merit one of the expected Internet replies:

  • “Newspapers are no different than blogs! You’ve wasted your time reimplementing Mephisto! You’re dragging the rest of us Ruby folk down by not implementing something new that nobody’s ever seen yet!”
  • “Man, Rails isn’t really cut out for building a CMS. Why didn’t you use Drupal or Django? Fail, dude, fail.”
  • “Obviously your paper has money to throw away if they let you sit around for nine months instead of buying Ellington!
  • “you use rails haha i could hav don it in a month with PHP u suk”

My human brain needs beer now.

Shells at 30,000 Feet

Posted by s.f. on November 28, 2007

One of the things I’ve noticed is that most OSX hints for setting up anything in *nix-land tell you to add path statements just to ~/.bash_profile, usually assuming that you’re working on your own machine. But if you’re ssh’ing to another OSX(or -nix based) and set up the path in the same way, this will probably cause vlad(and capistrano, I guess) to fail with “command not found”, since they use a non-interactive shell to run commands. There are simple fixes: enable PermitUserEnvironment in your /etc/sshd_conf file. Which works, but 1: it’s a potential security hole(paranoia, a game we all can play!), and 2: it’s overkill, because having your path in ~/.bashrc is the proper way to do it, as pointed out here.