ebzlo

Proposal to replace the ABCDE standard in multiple choice questions

Tue, 13 Mar 2012 04:06:00 -0400

(disclaimer: I have never been a credentialed teacher)

When I used to teach fairly regularly in a classroom environment, one of the things that would regularly be a source of confusion when working on multiple-choice questions, as a class, were the answers “B” and “D” (whew! That was a mouthful).

Completely possible classroom scenario:

Teacher: “The answer is B.”
Student: “D?”
Teacher: “Yes, B.”
Student: “D like in Day?”
Teacher: “Yes. B like in Bay.”

Kite currently uses 12345, but I realized this could potentially be confusing in situations like this:

Teacher: “The answer to number #3 is 5.”
Student: “5? Answer 5? Or 5?”
Teacher: ”Answer number 5.”

So, I would like to propose a new standard!

I would like to use AEIOU for multiple choice questions (obviously, if we go above 5 choices, that’s going to have to be re-thought). My reasoning is as follows!

Already engrained into a student’s head at a young age. So it becomes easy to mentally find the index for “O” than it is some random letter. e.g. “O” = 4th answer, “D” = 4th answer
Because they’re the unique vowels in our alphabet, they naturally make different sounds.
They’re not numbers, so they can’t be confused with the actual solution to a math problem.

Neat little feature with Ruby's Time object

Wed, 07 Mar 2012 22:49:23 -0500

My co-founder and I were discussing how we might calculate the end date of a canceled subscription for Kite (we don’t want to pro-rate subscriptions).

We decided we wanted to expire the subscription on the same day of the current or following month. Meaning a subscription of March 15th expires on April 15th (or May 15th and so on).

Of course, we then need to figure out what happens when someone subscribes on January 31st. It turns out, if we just get the created_at.day value and use it to instantiate a new Time object, Ruby does the math for us if the date doesn’t exist.

irb> Time.new 2012, 2, 28
=> 2012-02-28 00:00:00 -0800

irb> Time.new 2012, 2, 31
=> 2012-03-02 00:00:00 -0800

Being good enough doesn't necessarily make you good.

Tue, 13 Sep 2011 03:23:00 -0400

A professional developer carries certain expectations:

Meeting deadlines.
Accurately estimating timelines.

When I first began programming, none of these things were a concern for me. It was easy for me to bunker down in my room with cans of soda, pizza, and my keyboard filled with traces of the aforementioned items.

I could try new things, make mistakes, and nobody was going to have a problem with that and nobody was going to care if it ended up taking much longer. This sort of mentality was extremely conducive to growing.

At some point during my professional career, I became blinded by the goals of my employer and had forgotten to set my own. Hacking together a solution quickly was commonplace and sometimes warranted by my management overlords, because while it wasn’t the best solution, it was good enough. I became complacent and lost sight in the importance of keeping up with new technologies.

It’s now been about six months since I left that position. In that time, I’ve fallen in love with Ruby (now imagine going from PHP4 to Ruby), learned Rails, discovered the magic of Heroku, dabbled with Amazon’s services, moved over completely to Git, and among other things.

I’ve been a little behind, but it feels good to finally be caught up again.