(Incidentally, I just violated the “Try to reproduce rule” in trying to respond to Mindy’s comment. When I viewed this page in Chrome before, the comment did not display. I asked Mindy for help before checking myself in Firefox, where the comment correctly displayed. Restarting Chrome did the trick. Sorry for bugging you, Mindy!)

Hat tip to Jeremy Fields, who was the first to share screencasts with me this way ;)

I’m all about looking towards the future, and I would like a future with less sub-par code. :)

thanks for this article, it’s realy good, I’m a freelancer developer so I know what you writing about :).

debugg3r

1) It forces you to spec out your code before implementing it. It’s difficult to TDD your way into an unnecessary refactoring in my experience.

2) It gives you the freedom to write crappy code. With a good test suite in place, you don’t have to worry so much about “is this code good?” and focus solely on “is this code right?” Good can come later.

It’s easy for me to tell when I’m cranking out cruddy code fast or getting myself stuck inside a (re)factoring black hole. But it’s much harder for me to see where the line between them is the closer I get to it.

So far the most successful technique I’ve found for avoiding either extreme, is to spend 15-30 minutes getting my head around the task at hand and then setting a time-box for myself. The length of the time-box is determined by a combination of considering deadline, how much time I think it should take, and how much time I *want* to spend on the task at hand. Additionally, I’ve also found pairing is often a good way to achieve this particular kind of balance. It is easier to avoid either extreme when you’ve got someone else looking on.

Again, great post.

Can I assume that this will still work within a prepared statement and that it will also benefit from the performance optimisation that comes with using them?

Thanks
Imogen Pond

I removed the SQL regexp which brought the query down to milliseconds, and used a ruby regexp on the results instead. It was far quicker doing the regexp in ruby than in the SQL query.

If a regexp query is run often, it probably will pay to cache the result in a boolean column.

You could still use exceptions in a similar manner by adding a Credential#save! method, if you really wanted to replace a single if-else with a raising an exception ;)

You’re missing a test.

https://gist.github.com/1184743

Cody - valid concerns, to be sure. Since we’re not handling an enormous number of keys (63k at present) and because we only run these searches whenever a PUMA employee publishes or updates a piece of content (which only occurs a handful of times per day), we found no harmful effects of running KEYS in production. YMMV, but for a read-heavy app like this one, it’s working SO WELL.

I am curious about how you are seeing usage of the KEYS command in production.

We ran into serious issues with this command as it appears to lock Redis for the duration, as the keyspace is walked.

Additionally, even the Redis docs suggest against using it as part of regular application code:

http://redis.io/commands/keys

competence should breed confidence, but for careers where you can fake it (like software development), you can get far by just pretending you know your stuff (just dont let them find out your a phony).

I agree that the goal should be to make forward progress and get everyone comfortable with that progress as quickly as possible; I also agree that in the real world, it’s much more akin to a landgrab than a turtling operation. However, I can see some overzealous newbie taking this the wrong way, and saying “Hey, I should portray confidence, so even though I have no clue how to solve problem X, I’m going to be decisive and say that we should take approach Y.”

I think when it boils down to it it’s a subtle distinction between being confident and being prematurely decisive. Confidence is good - the more we trust our ability to understand, the sooner we can reach good decisions. But premature decision-making is bad, because overconfidence can lead us to make the wrong decision and blow up.

Of course, the flip side is “fail as early as possible”, so who knows. I’m just thinking aloud :-)

https://gist.github.com/1002869

Either way, thanks for the help!

We’re doing some serious interface renovations, you can see a live demo at http://rails-admin.heroku.com/.

It’s not tied to any authentication or authorisation library (although it does have hooks for some), so you can do something custom like RailsAdmin.authorize_with { redirect_to root_path unless warden.user.admin? }, or use a library like cancan to say something like can :access, :rails_admin if user.admin?.

Thanks again!