Kuroko Project

Recently at work, I needed to parse ugly data files from an ancient classified-ads database that a predecessor devoted an entire Ruby application to. While painstakingly building regexes, I remembered looking at Treetop a few months ago.

Treetop is a Ruby library for writing Parsing expression grammars. PEGs are another way of constructing grammars and could be thought of as super-regexes: they don’t allow left-lookup or ambiguity in the parse tree, making them not so useful for natural language but killer for computer languages. Around 40 lines of code and 7 rules took the place of what the original author devoted dedicated tempfiles and regex arrow code to.

That being said, PEGs are conceptually harder to get grips on, and Treetop’s documentation is not entirely clear on some hangups you might find. Most of which you can solve using the excellent mailing list, but I know I wished during the past few days that I could get it summed up for me.
Continue reading…

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.

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 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


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.

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)

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.

In the wake of the Intel-OLPC fallout, the chief designer of the OLPC technologies asked Groklaw about ideas for an open hardware project. Even better, it made me aware that OLPC itself is still an ongoing process, rather than being cut-n-dried.

To me, this tickles my inner-struggling-hardware-geek in a really good way. Not just in Jepson’s commercial efforts in the “making components public and affordable” part, but also in her advocation of the “we’ve got no vendor secrets, here’s the exact part-list, schematics, and source-code” method of development.
Of course, making it open isn’t a guarantee of success(OGP, OpenMoko), but it’s a nice perceptual move away from the Wintel alliance’s long standing policies of “we know what’s best for you, and there are no user serviceable parts inside”.

(Yes, my reading list for the past two months has included Stross’ Halting State and Vinge’s Rainbow’s End)

Powered by ScribeFire.

_why had a neat post on Io today, showing off a cool introspection+meta trick that I wasn’t aware of. And since it’s _why, the Io mailing list has shown another flurry of activity, which I’m hoping will snowball into another group of fresh users, to eventually reach that goal of “1.0″..

Interestingly enough, Io was the language I learned right after Ruby, for much the same reason: trying to get a good grip on concurrency in simulation environments, after too much exposure to UnrealScript.
 (And along those lines, Thunder and Lightning still stands as the only major game project using Io as a scripting language).

So, Zed spewed. Since I guess I’m now a Rails “professional”, I guess I’m supposed to have some sort of up-in-arms opinion.

I really couldn’t care less.

Once you pick up that Zed writes in a deliberately provocative manner, reminiscent of the SA Forums, the rant’s main points boil down to his personal experiences with consulting, and elements of the Rails community being too uptight.

The only thing I found really entertaining about the affair(outside of the Rubinius praise) are the responses popping up on mailing lists looking to move away from Mongrel, because they just can’t trust software written by a person who posted “something like that”. If your sentiments are similar, I hope you’re not using OpenBSD(Theo), ReiserFS(Reiser), or anything GNU-related(Stallman)

In my professional life I’ve had to use a lot of software I considered brain-damaged(custom Java object-frameworks, antiquated news databases, PHP), but the dislike almost always stemmed from experience with the software itself, not the person/teams behind it.