I’ve had a couple of job interviews in my life:

1. With a finance director, when I first left school and didn’t really know what ‘working’ was all about
2. A two-day interview-cum-assessment during the university ‘milk-round’ period. I became distinctly opinionated during the second day because I was terribly hung-over (but I believe, to this day, that I was right)
3. A half-hour in the office interview with my prospective project manager, when working at Siemens
4. A day-and-a-bit working with a company for the job that brought me to Inverness

Seth Godin writes today about the end of the job interview, because he believes that traditional job interviews are ineffective at identifying the suitability of a person for a role, and usually poor at selling the company and the job to applicants.

Of the above four interviews, the last one was the best, because I met with, and worked with the people that were to be my colleagues and bosses. We learned about each other in a practical, real, environment, and I learnt about the company and its projects.

Hurrah! Two things I spotted today in Ruby Insider, which will make my life easier:

• Deprecated, a Rails plug-in (for Rake) that identifies common deprecated features
• Rakemin, a web-based Rake task invocator – coming soon

Grrr.. just had horrendous experiences trying to show the code in my earlier post.

First an upgrade to Textile 2.6 was in order, followed by sticking stupid double equals signs around everything. But then, because Textile thinks double equals is a tag for no textile, the double equals in the code gets stripped out.

So I ended up updating the noTextile() method to check for not two, or three (because three consecutive equals is valid code in many languages), but four consecutive equals. No, I can’t show you what it looks like, because my version of Textile strips out four consecutive equals.

There are quite a lot of things right about Ruby on Rails. One thing that isn’t is its growth rate, which means that books and tutorials are frequently behind the feature set that is currently stable. This leads to deprecated code or tutorials which no longer match best practice. Correspondingly, when you write Rails code, you’re never sure whether what you’re writing is optimal.

Consider link_to_unless_current, which provides a link to a page, unless you’re already on that specific page. Sounds great, and indeed it is. But it doesn’t do quite what I want. What I want is to have an easy way of highlighting the particular controller in use, and providing links to other controllers, just like the image in this post.

Instead, there’s a more generic method, link_to_unless which provides links based on a condition. You can then write code like this:

<div class="choices">
     <ul> 
        <li><%= link_to_unless ((controller.controller_name == "schedule")), "Schedule", :controller => "schedule" %></li>
        <li><%= link_to_unless ((controller.controller_name == "context")), "Contexts", :controller => "context" %></li>
        <li><%= link_to_unless ((controller.controller_name == "project")), "Projects", :controller => "project" %></li>
        <li><%= link_to_unless ((controller.controller_name == "task")), "Tasks", :controller => "task" %></li>
    </ul> 
</div> 

Of course, you can iterate around a hash if you want to.