Wednesday, October 31, 2007

No I don't want to unlock your iPhone for you

Just because I've got one, and I love it, doesn't mean I'll help you with yours. It was hard enough for me to unlock mine that my recommendation on the device is this:

"If you aren't a developer familiar with SSH, firmware, networks, bootloaders, and Unix go buy something else. This device is not for you."

That includes buying one that is already unlocked. You will eventually screw up and be back to using ssh and command line shells.

I've got my own projects, and I really don't want to spend my life unlocking other people's phones when I could be having fun.

So, no, I don't want to help you unlock your phone.

The only person I will help is my wife, and that's because, well, I love her. If you aren't her, I don't love you enough, and you can't afford my hourly rate.

Monday, October 29, 2007


I've never been in a meeting that was longer than one hour, or had more than four people that achieved anything. I'm being generous with the hour, too.

Why do long meetings continue to exist? I'm becoming more and more convinced that long meetings are a power play. They exist to re-inforce the importance of the person who was able to convince everyone else to show up. Nothing else. Who needs a four hour meeting attended by 20 people about a project that's late?

I'm curious to hear about situations where they've had a good meeting (decisions made) that lasted more than an hour or a large number of attendees. Do they work for you?

Wednesday, October 24, 2007

Rails, models and modifying columns

I had my first WTF moment with Ruby and Rails over the past couple of days. I'm working on a personal project (you'll see it soon), and I'm using Rails. It's an opportunity to learn a new language, and see if the buzz around Rails is true.

Anyways, I was having problem with a model, here's the code I had:

class Call < ActiveRecord::Base
  def my_status(user)
    if (a_party == user)

  def update_my_status(user, status)
    if (a_party == user)
      a_party_status = status
      b_party_status = status

My controller looked like this:

 @call = Call.find(params[:id])

This didn't work. No matter what I did, I couldn't modify call. I put a tonne of debug lines in, and eventually got to this:

 @call = Call.find(params[:id])
 @call.update_my_status(@call.a_party, true);
 if !@call.a_party_status 
   @call.a_party_status = true
   if @call.a_party_status
      # Hrm, first method didn't work, but the second one did?
      # They both failed!

Amazingly, setting the value outside of the class worked, but setting it inside of the method in the class didn't. I was stumped. Google wasn't any help, it seems this is something that no one else runs into as a problem.

Finally, I found a tutorial that showed me what was going wrong, even though it didn't say it explicitly... It had the following example code:

>> player =
=> #<Player:0x28ef720 @attributes={"team_id"=>nil, "name"=>nil, "number"=>nil,

Looking at that, it all clicked. ActiveRecord makes extensive use of the "method missing" functionality available in Ruby. Essentially, it looks at what you are trying to invoke and performs the action on the fly if Ruby can't figure it out itself. That explains what is going on with the "update_my_status" method. Since it is an assignment, Ruby will create a local variable, "method missing" isn't invoked and the class attributes are never changed! The solution? Put "self." in front of the attribute assignments:

  def update_my_status(user, status)
    if (a_party == user)
      self.a_party_status = status
      self.b_party_status = status

That was extremely frustrating. I need to see if there is a "warnings as errors" option. It's also an indication that I need to start working on my own stuff earlier in the evening. My brain seems to shut down after 9:30.

Oddly, it seems that I'm the only one who has this problem. After talking a friend, he said, "I always put self. in front of everything out of convention".


Oh, and Rails? It Rocks.

Tuesday, October 16, 2007

Hey, I found an iPhone bug!

This one would be fun to track down. :) After a week of use, I noticed that the volume control (and slider) weren't as responsive as they used to be. The visual control was no longer smooth, tending to move forward and back. My guess is that the animation was semi-predictive, and then corrected for the true value reported by the hardware. Since there was an increasing lag between the control and the visual update, the phone would appear to visually jerk the volume display. A quick reset and the problem's all gone. I wonder if the 1.1.1 touch has the same problem? I wonder what interupts are firing when a keypress/volume change happens?

Thursday, October 11, 2007

Testing and Testers.

Q: What do you do with a tester that feels his responsibility begins and ends with reporting a fault? Refusing to be involved in the resolution, only in the discovery and reporting.

A: Sack their sorry-ass and hire yourself someone who knows what their job really is.