You know what? I’m starting to miss compulsory semicolons as statement terminators in Ruby. “What?” I hear you say. “But not needing semicolons is one of Ruby’s cardinal virtues! Are you mad?” I don’t think so, but maybe you’ll disagree after I explain further. Here’s a piece of code that I might write if semicolons were the only way of terminating a statement: Category.should_receive(:find_by_permalink) .with(‘foo’) .and_return(mock_category); Or how about a complex find query def find_tags_for(tag_maker, order = ‘count’) klass = tag_maker.

We’re looking for somebody who can make Flash 8 and javascript play well together on IE 6/7, Firefox and Safari. If you fit the bill, please drop me a line at pdcawley@bofh.org.uk with a pointer or two to examples of your skills and you, me and my boss will have a nice little talk. We need a flash application which can be controlled via Javascript - we really don’t want to go sticking 10-15 tiny flash buttons on every page if we can help it, just so they can tell the main app (sitting in another window) that the user did something.

If you’ve been running on the Typo edge recently, you’ll be all too painfully aware that there have been issues with the cache being flushed at the wrong times and not flushed at all at others. Which is not a happy state of affairs. However, I’ve recently got back to working on Typo and, after a few warmup refactorings and some missteps, I think caching is working properly now. There’s lots more work to do (there always is) but I reckon that you could do worse than bump your installation to r1513, which is what I’m running here.

Remember back when I wrote about metaprogramming and programming being the same thing? Well, Libraries, Domain Specific Languages, Domain Agnostic Languages, Pidgins, YAML, .INI files and the like are all the same thing. They’re all notation. That’s the thing to remember. Good notation makes life easy. Bad (or inappropriate) notation makes it hard (or, in some cases, fun). There’s no point striving to write a pidgin or DSL if your problem can be solved easily enough with a well factored set of loosely coupled classes.

Reification: The mental conversion of a person or abstract concept into a thing. Also, depersonalization, esp. such as Marx thought was due to capitalist industrialization in which the worker is considered as the quantifiable labour factor in production or as a commodity. - OED In the sense that the OED has it, I’m not what you could call a fan of reification. At work, we have a rule that anybody who starts talking about ‘resources’ when they mean ‘people’ gets a (verbal) slap.

I’m reading ??Beautiful Code and it’s very good indeed. However, you have to feel sorry for Tim Bray - his chapter, “Finding Things” is excellent, as you’d expect. The only problem is, he’s following Jon Bentley, author of that perennial classic, Programming Pearls. It’s been a while since I (re)read anything by Bentley and I’d forgotten how good his prose was. Which isn’t to say that Tim Bray is a bad writer.

Reification Notation Reticence Lucidity Intent Learn ’em. Live by them. What did I miss? Which ones don’t belong on the list. What am I talking about?

A few days ago, Obie Fernandez: <typo:flickr img=“430323096” size=“small”/> commented on the advert found in the current Linux Journal which features a photograph of an attractive woman with the slogan “Don’t feel bad, Our servers won’t go down on you either.” Obie threw together a mock ad for a document management company which showed a bunch of latinos being harrassed by a US Customs and Immigration patrol with the slogan “Don’t worry.

One of the handy tools that Ruby makes available to us Domain Specific Pidgin builders is instance_eval. With instance_eval you can take a block that was created in one context, with all its lovely closed over local variables, and evaluate it in the context of an instance of an arbitrary object. Which means that any references to instance variables and calls to methods are made as if your block were a 0 argument method of that class.

So, I’m busily writing an article about implementing an embedded little language in Ruby. It’s not something that’s going to need an entirely new parser, it borrows Ruby’s grammar/syntax but does some pretty language like things to the semantics and ends up feeling far more like at declarative language than the usual Ruby imperative OO style. Because I tend to chromatic’s view of many ruby programmers’ ability to cry -“Wolf”, I don’t want to claim that it’s a full blown Domain Specific Language, but it’s sufficiently language like that ‘API’ doesn’t seem to fit as a description either.

I’ve been following Adam Turoff’s excellent Haskell tutorial and he’s just reached the part where he explains Monads. To listen to a lot of people, Monads are the bit of Haskell that breaks their brains. As they’re usually described, Monads are the part of Haskell that allow you to write code that has side effects. You know, stuff like reading a file or generating a random number. What most of the tutorials I’ve read don’t do is explain why Monads let you use side effects.

Fixtures suck! Mocks rock! Don’t you dare let your tests touch the database! Well… yes… I suppose. Except, mocking can be a complete pain in the arse too (made slightly less of a pain in the arse if you use the null object options) - it’s awfully easy to end up with huge long setup methods that spend all their time faking out a mock object and about two lines testing what you need.

Back when I was still programming Perl, one of the common mistakes that you’d see when people wrote lazily initialized object accessors was code like: sub get_content { my($self) = @_; $self->{content} ||= ‘default content’; } Code written like this would trundle along quite happily, until you had an attribute where, say, the empty string or 0 were legal values for the attribute. The problems were especially painful when the default value wasn’t something that perl treated as false.

Mmm… back from Scotland with a chunk of reading done: Harry Potter And The Deathly Hallows. Mmm… top notch stuff. Wraps up the series perfectly. The Book Thief. Wow! Seriously… wow. Whatever you do, don’t read the last chapter of this in public. I was a wreck. Beautiful. Sad. Really Sad. Life affirming stuff. Read it. The Complete Polysyllabic Spree. Nick Hornby writes exceedingly good litcrit/columns. Compilers: Principles, Techniques and Tools aka The Dragon Book.

The bags are packed, there’s a pile of reading matter (mostly the classics, Turing’s papers, The Dragon Book…), the iPod is charged and we’re off to Scotland for a week with no connectivity. See you in a week. Don’t wreck the joint.

Have you noticed the difference between Good Clever and Bad Clever? For instance, I recently spent a couple of hours working out to make a Genre model which acts_as_nested_list work in such a way that when ask one of the trunk genres for its tracks it finds all the tracks associated directly with the trunk or with any of the genre’s sub genres. It’s made doubly complicated by the fact that the genre is related to its tracks through a relationship model, and triply complicated that we’re going to want to be able to be able to search within the basic set of results (because, usually, we don’t want 300 tracks on a page…)

<typo:flickr img=“632526335” size=“small” /> A few years back, we got dad a place on a coracle building course as a birthday present. He had a great time and came back with a half finished coracle that he never quite got round to finishing. Until now, it seems. Despite what you might think, the photo above isn’t taken from inside my parents’ boathouse, it’s taken from inside their garage. That’s not a river, that’s the road.

As far as I can tell, one of the Smalltalk optimizers’ mottoes is “Cheat all you want, but don’t get caught”. Well, this morning, I caught Squeak with its hand in the till. One way I attempt to bootstrap myself towards understanding of code is to try and make it better, if that makes sense. So, I’d run SLint over the OmniBrowser package and was trying to shorten a method. One thing that struck me as rather ugly was a piece of code that ran like this:

There’s something enormously liberating about writing an RSpec description that starts like: describe ArticlesController, “feeds:” do before do the_mock = mock('everything', :null_object => true) ActiveRecord::Base.stub!(:find).and_return(the_mock) end it “/articles.atom -> atom feed” do get :index, :format => ‘atom’ response.should render_template(’_atom_feed’) end … end The :null_object flag to rspec’s mock function is remarkably potent.The resulting mock will return itself from any method call that hasn’t got some other expectation set up. When I’m testing that my index methods render the appropriate views for the format, I don’t care that all the various variables have been set up correctly - I’ve already tested that in another description - I just want to get to the point where I’m about to render a template.

So, I just pushed the first step of what I’m thinking of as the Great Typo Controller Reorganization to the typo repository and updated things here. It’s always scary when I do that - local testing’s all very well, but running on a live site is a different matter. I’ll be talking about the changes in a later post, there’s a couple of things in the recent change that I’m rather pleased with, as well as a Rails plugin that I hope will be widely useful, but which I need to document.