DelayedJob scheduling improvements

Last week I talked with a guy who noted that the scheduling patch I’d blogged about for DJ was insufficient for scheduling something every day at 8AM. This is because running a job and then scheduling the job again after a success pushes the job out a little bit each time (maybe in a week or so it runs at 10AM, e.g.)

I thought about trying to make a run_at class method that would let you specify it, like “run_at ’8am’”, but that quickly fell through when I realized ’8am’ is ambiguous – 8AM every day? Every Wednesday? Every 4th week in July?

I fall inline with Brandon Keepers when I say that I don’t want to re-implement cron, because (imo) cron is one of the best scheduling tools out there already, and it comes packed onto every Unix distribution that ends with x.

Instead, I changed the run_every method to now accept a block, so you can pick the new best time to run if you’d like, or just keep using the same old (8.hours) syntax.

Think something like this:

If you like it, here’s the GitHub Repo.

You’re Right

A few weeks ago, there was a fun argument over a feature at work. It was split down the middle. Feature arguments are a lot of fun, because everyone gets to pretend they know what the ambiguous “User” wants, when nobody really does.

The lines were clearly drawn, I was on the opposite side of our PM, and he had to go to a meeting. While he was gone, a (really smart) fellow dev hopped into the conversation, asking what we were arguing about. I explained the issue (surely with dripping bias), and asked him what he thought.

He sided with the PM, and explained his (different line) of reasoning. It was cogent and persuasive. As he was closing his argument, I just cut him off. “No, you’re right.”

The PM came back in, my boss in tow, started up the discussion again, and I exclaimed that I’d switched sides. I regurgitated the (really smart) fellow dev’s reasoning, and that was that.

There were a lot of important things that happened there for me. One, I just outright said that someone was right, which until then I hadn’t done very much. When I was younger it’d get to the point that I’d draw up ridiculous straw men or insane special pleading fallacies to make my point, even when I knew I was wrong, and would “win” the argument.

When you “win” with shit reasoning, everybody loses, for two reasons. One, other smart people recognize your shit reasoning, and even if they can’t argue their way out of it, they lose respect for you. Two, and this counts especially if you’re making something that other people have to use, shit reasoning leads to poorly modeled and horribly thought out products.

There’s a lot of value in being honest and working hard to identify the best ideas. One of the consequences of this is the realization that your ideas aren’t always the best and aren’t always right.

The unpredictable effect of me conceding the argument with, “you’re right?” Feeling liberated. Suddenly I wasn’t stuck to a losing side, had seen the light, and was then arguing for something that made even more sense. Also, I think by reiterating the (really smart) dev’s reasoning, I’d helped bring everyone onto the same page, but that was only by luck – if the (really smart) dev had been in the original discussion, the discourse probably wouldn’t have lasted more than 2 minutes.

There are arguments that are fun to have, where neither side can be 100% right, and there are arguments that aren’t fun to have, because one side is 100% wrong. In the second type of argument, it’s important to be on the right side, even if you’re late to the game.

Most importantly? Make sure your teammates and coworkers know you’re aware of your own fallibility.

Bgtwt Open Source’d!

After (I think) removing the passwords and everything else sensitive in the code, I’ve open sourced the code behind bgtwt.com.

I’m not sure if it will get any patch submissions or not, but I figured with it being closed, it definitely wouldn’t. If you submit anything you’re proud of (you can find the code here: http://github.com/terrbear/bgtwt), and I like it, I’ll happily put it up on the site.

You’re also free to copy the code and do whatever you want with it. I’ll attach the proper license in a few days.

If you’re looking for a feature that would be awesome and want to start playing with Rails, I’d like to integrate acts_as_unvlogable into bgtwt.

Rails and OpenID: Start Your Engines

(Apologies for the ridiculously lame title, but I laughed while writing it, so it stays.)

If you care about your user’s security, and your time, it’s time you stop asking them for passwords. Storing user passwords and handling authentication offers a bunch of problems that have already been solved, and requires a lot of work to do it right.

Think about it. If you’re storing user’s passwords in your database, you’ve automatically got sensitive information on your server. Maybe it’s just a College Football Pick ‘Em site, which stores nothing too important … until you store a user’s password. Let’s face it, most users don’t use a new password for every site, so if someone breaks into your server, you’re responsible if that information is lost.

So, you’ve got to make sure your server’s security is up to date. Then, it’s still possible there’s a break in, or you have a malicious developer. So you have to encrypt the passwords. But not just encrypt them, because that would still be susceptible to dictionary attacks. You have to salt each password.

What about brute force login attempts on your sign in page? Have you handled that?

These are just some of the problems that you have to solve the minute you decide to store someone’s password.

A better solution? OpenID. Below I’ll explain how to use my newly written (really repackaged) OpenID Rails engine, and you can be on your way to making the world an easier place to sign in.

Read the rest of this entry »

Developer Requirements

Apologies for the terribly named post.

I was thinking on the way to work this morning about classes that I thought helped me write software, and classes that were meaningless. Keep in mind that I’m only evaluating these classes according to what’s helped me work, not what’s helped me in everyday conversation or social gatherings or whatever.

• Statistics – I only took 3 hours of statistics, but I think having a fundamental understanding of measuring things is incredibly useful. It helps you learn where to look for problems and pain points.
• Science – This isn’t really a class, because I don’t think any of the science classes you take in college help you learn about the scientific method. That’s not entirely a bad thing, because there’s a lot of information they need to give to you so you can understand the higher up physics courses, for example. Understanding how to isolate variables and constraints and make testable hypotheses informs everything I do nowadays.
• Automata – If you think of regular expressions as pictures, instead of arcane symbols, it helps a lot.
• Technical writing – Being able to communicate effectively over email, understanding desirable typefaces, etc., I think have been helpful.
• Data structures – You know, it’s funny. It was one of the first CS classes I took, so I thought it’d be dumb, but I got to work out a lot of how queues and stacks and trees worked before having to rely on them heavily.
• Systems programming & Operating systems – When you start running your own applications (because of funding or because it’s too complicated to convey to someone else), knowing about schedulers and memory leaks and threads and processes and shells is incredibly useful.
• Assembly or C – Most of my early classes were in C++ (I know, not C at all), but at least I got some of the syntax, and then I did several classes that involved asm. I think those were awesome, just because you understand what needs to be done to move information around a computer, and how (and when) it gets expensive.

Not so helpful:

• Algorithms – I think this is probably more a result of the teacher than of the class itself. I think having a basic understanding of bigO is important, but it’s not important for an entire semester. I think understanding code and statistics provides a better foundation for optimizing and choosing algorithms, and our teacher didn’t offer any of that.
• Chemistry – I still don’t understand why I needed to take this class.
• Circuits – Has had no bearing, whatsoever, on how I do my job. I’ve tried my hardest to block out how inductors and capacitors work.

This is an incomplete list, but if you happen to come across it, maybe it’ll make you smarter.