My subway ride was smooth as usual. Having left the office later, the subway cars were not as crowded and almost halfway through the trip I managed to snag a seat and sit comfortably for the rest of the stops leading up to the north end of the Yonge line, Finch station.

This is where the fun begins.

I reach the top of the three sets of stairs that lead from the subway platform to the bus platform. Then I move through a set of double doors to my left leading outside. The picture above fails to show the full magnitude of the crowd of people that I had to squeeze through to get to the location from which I shot it. The two lines of people that usually form for the 36 Finch West buses both curve in the same direction and run parallel to each other on the other side of the platform.

At this point, I know I’m in for a long wait in the cold and I’m visibly anxious. I watch all the buses that pass by.

Out of service. Out of service. 60. Another 60. 36C (to Jane, not far enough for me). Another 36C. A 36D (Weston, still not quite far enough). Out of service sign that switches to DETOUR ON ROUTE (wait, what?). Another 60…

As the 36’s stop to pick up people, I start to move closer and closer to the front of the line. But my bus is still to arrive. About an hour passes. I make fists with my hands to keep them a bit warmer. My feet hurt I am shivering. I continue to wait, wondering if maybe there was a detour on Finch West causing delays in getting buses back to the station.

Finally, a 36B. This one will go all the way down to Humberwood, well past where I need to get off. I’m close to the back door and desperate to get out of the cold. As we file onto the bus, I feel an unpleasant sensation between my shoulder blades: I’m being pushed from behind. Another passenger turns to yell at the man behind her, demanding to know why he’s pushing her. Clearly, the people behind us are as desperate to get on the bus as we are and considerably less polite about it.

The bus is packed as tight as a sardine can. The driver tells riders at the front door that he has no more room and that another bus is behind him; he doesn’t know if it is another B. The back door is particularly crowded. The riders there exit the bus and re-enter, playing a precarious game of human Tetris (no, not that human Tetris) against the two bars that trigger the door to open at stops. The driver tells people to try entering via the back door. Each time he does, the passengers near the back door groan.

We pass by the major stops: Dufferin, Bathurst. The bus is still roughly as packed as it began.

At Keele, a person further to the front squeezes past me to get to the back door. As he passes by, the messenger bag that is hanging on my right shoulder is pushed behind me and lifted way up. Finally, he manages to break through and exit the bus.

Not until Weston do enough people clear out to give me some space to breathe. There are still no seats however; I’ve been standing the whole time.

Now I’m home, quite irritated and wondering why my usual commute had suddenly doubled in length. TTC’s official Twitter feed for service notices says nothing about it. It reminded me of a customer service tip that might be useful to the TTC: perception matters.

Even if you’re doing the best you can, if that’s not what it looks like to your customers, you have lost them. That’s why the photo of the sleeping fare collector caused such a stir in the community. We now pay more than ever for each ride, including Metropass holders, and we want to see the return on that investment.

RAM holds the current information that a program is working with, but it doesn’t hold on to it forever. Once the program has exited, the RAM it was using is (ideally) reclaimed by the operating system for use by other programs. If a program needs to keep information for the next time it executes, it will get written to the hard drive or to another form of persistence.

I imagine short-term memory as being very similar to RAM. The thoughts are in your head, but they aren’t going to stay there forever. Even long-term memory is not entirely reliable; the act of recalling something changes it slightly. So if our memory isn’t the best place to keep ideas for later, where should we keep them? In writing.

The act of reading words doesn’t change them. The letters which were printed may become illegible but they will never change. The information that those written words encode persists, and is the same every time you read it. The written word is how we have aggregated the collective information of our entire species with the accuracy and efficiency that we needed to make our social and technological advances.

One of my goals for 2010 is to write more things down and stop trying to keep so much in my head.

I’ll close this brief thought by quoting a blog post I read recently about writing:

The amount of information our brains can fit into our short term memory at once isn’t a lot. If you never have thoughts that require notes, then all your thoughts are small or unoriginal enough to fit into your tiny short term memory.

Writing allows you to record your short term memory into a format that you can examine and reflect upon, so you can suss out what makes sense, and how it makes sense, and then expand on the original seed. When you expand your thought all the way into a piece of coherent writing, it becomes complete. It would have been impossible for you to have that size of a thought without writing–your brain just isn’t powerful enough.

@joncrowley: "I'm convinced that the key to failure is thinking of life as something that is done to you, rather than something you do."

It’s easy — comfortable, even! — to feel like you are stuck in a rut, a victim of circumstances that prevent you from being truly awesome, but it’s simply not true: you are always in control.

You can’t ensure the outcome of every endeavour you undertake, but you choose your actions, your reactions, your thoughts, and your words. Even though you command all of these things, you may still feel like you are burdened by obligation or paralyzed by fear.

Take the reins. Steer your life in the direction of your desires. Work hard to achieve those things which are most important to you as you cut away those things which bring you down. Don’t let life just happen to you. Your life is finite and fleeting. Be present and engaged in every single moment and wring out every bit of joy and excitement that you can. Unless you have a very strong belief in life after death, this time which is steadily elapsing is all you’ve got. Even if you do have faith, why waste time?

That’s what I think anyway, but it’s your call.

One of these parallels between humans and computers is the way that we multitask. Computers only seem to multitask by switching between tasks rapidly, with the exception of new multi-core and multi-processor systems, which can run as many tasks in parallel as there are cores or processors. So it was interesting to read recently that the prevailing theory is that humans multitask in precisely the same way!

Analogous to a multitasking CPU, current experimental psychology research shows that interference occurs when we attempt to perform even simple tasks simultaneously. There are certain exceptions to this, particularly when one of the two tasks is stored in “muscle memory”, but this is because we can perform such tasks without even thinking about them. In many other cases, the effectiveness with which we perform the tasks is diminished when we are doing more than one task at the same time.

It is also common wisdom in IT that when somebody is deep in his/her work (commonly referred to as flow), an interruption of even a few seconds can result in 15 minutes of lost productivity. While I’ve never verified the actual number, I have often had trouble putting myself back on a task after being jolted out of it by a short interruption.

When a CPU switches tasks, it must perform a context switch. The current state of the program that is running on the computer, including the values stored in the registers, a reference to the next instruction to execute, and other housekeeping information are stored in memory (RAM). When the program comes back, the stored information is put back into its proper places so that the CPU can pick up where it left off. This is a fairly costly operation as the CPU cannot access RAM even a fraction as fast as it can access its registers. Of course, this means that when a CPU runs two programs simultaneously, it is less efficient at each than if it were concentrating entirely on one program or the other. Determining when to switch to a different program is therefore an incredibly important concern in the design of modern operating systems.

I’ve witnessed human “context switching” in a co-worker of mine. When I knock on her door to ask her a quick question about work that I’m doing for her, she asks me to give her a moment and looks to be deep in thought. She then asks me to repeat my question and answers it with surprising conciseness and accuracy. She has told me that she needs to switch from the mindset of what she’s currently working on to the mindset of what I’m asking her or she can’t answer properly.

This isn’t to say that multitasking is bad, but I am acutely aware that when I do multitask, I am not going to be able to perform each task as effectively as if I were focused entirely on one. Also, there are certain points at which it is easier or more natural to switch from doing one thing to doing another, particularly where I’ve accomplished a sub-goal in the task or where I’ve written down detailed notes on the current state of what I’m doing, which makes it easier to switch back to it later.

What do you think?

Near the beginning of the year, I decided that I needed to switch gears in my career. I made a very dedicated push towards becoming a full-time Ruby developer, leaving my comfortable position as a J2EE web content management and identity management specialist. My leisure time was consumed with sharpening my Ruby skills and learning new technologies. I made Rails Pub Nite a monthly ritual and networked like crazy on just about every networking site I could. I followed a number of job site feeds and sent out many cover letters and resumes.

Finally, my break came from a very unlikely source: Facebook. I posted to a Ruby on Rails group on Facebook to advertise my skills and experience and offer my services. This was seen by the Systems Manager at the Canadian Society of Immigration Consultants, who asked me to send her my resume. I did so gladly and not too long after that I was asked in for an interview.

The project they needed me to work on was definitely very appealing, if a bit ambitious. They wanted to replace the monolithic pile of .NET that was currently doing an incredibly bad job of managing their records and processes and replace that with something leaner, meaner, and more attuned to their needs developed in-house using Ruby on Rails. This was my chance to gain experience working on a large Rails project from the ground up and to do so for a technologically progressive organization providing a valuable service to so many people all over the world.

That project is still on-going, and I recently accepted a permanent position with the Society. We hope to launch an initial release of the project early in the new year and I’m definitely bracing myself for a challenging job in 2010.

The professional networking I did then paid off in other ways as well. I previously wrote about how I helped a very good friend of mine land a job at PostRank. He moved to Kitchener/Waterloo while I moved back to North York, yet another of the changes that 2009 brought.

Finding myself back in Toronto after two years living in Mississauga, I quickly got to work making new friends and reconnecting with old. I’ve started participating in some Meetup groups related to my various interests, as well as events with #GenYTO and the Freshbooks crew. In just a few months, I’ve met some awesome Torontonians (I couldn’t possibly link to you all!).

So, at the end of 2009, I find myself in a new place — well, new in the sense that I haven’t been here in a couple of years — with a new job and new friends.

I am looking forward to 2010 with much excitement.

You can’t fix yourself.  You have to rebuild.

Take stock of who you are, where you are, and what has changed about your life and yourself.  And then do the things that will make you happier, make you smarter and better and stronger, and do them because you want to.  No one who is trying to fix a loss, or a heartache, is going to move on – if you do this, you are defining yourself by your tragedy.

This is such an important point that I felt I needed to echo it and add a bit of my own experience to it.

I’ve made the mistake of trying to “fix” myself. I’ve continued making that mistake for very many years. Jon explains that we can’t fix ourselves because we are simply so complex that it’s like trying to patch the foundation of a building. I’ve discovered that there’s an even more sinister factor at work when we try to fix ourselves.

To dedicate effort to fixing ourselves, we must first think that we are broken.

It’s sinister because in our well-intentioned attempts to improve the things we do not like about ourselves, we are subconsciously reinforcing the belief that our current state is unacceptable, that we are not good enough right now. Nothing could be worse for self-esteem.

If you are truly “broken” you will heal with time, just as your body does. If you feel that the requisite time has passed but you are still deeply injured, I would suggest seeking professional help to put yourself firmly on the path to recovery (again, just as with our bodies). But if you assume you are broken, I challenge you to question that assumption.

My attempts at self-improvement had always started from the position that I am currently not acceptable and that I must fix myself to become good enough. But then I noticed situations in which I thought a lot worse of myself than others thought of me and it caused me to question the way I think about myself. I realized that contrary to what I believed then, there is nothing fundamentally wrong with me. I am acceptable as I am now.

The lesson I have learned about trying to “fix” ourselves, then, is this:

Start from the position of accepting yourself for what you currently are, then figure out how to do even better. Do not “fix”, improve!

Self-esteem expressed in Ruby

It’s a valuable life lesson made incredibly concise in my favourite programming language, Ruby. I leave the interpretation to the reader. It relates to some themes that I’ve already written about before and will probably write more about in the future.

As with the first tutorial, I’ve pushed a branch based on authlogic_example that you can use as a concrete example.

First, let’s bring in the declarative_authorization gem:

# My example code was written before GitHub decided that they don't want to
# build gems anymore but this line should do the trick.
config.gem "declarative_authorization", :source => 'http://gemcutter.org'

Now, we need to make an ActiveLdap model class like LdapUser but for groups. We’ll call this LdapGroup:

class LdapGroup < ActiveLdap::Base
  ldap_mapping :dn_attribute => "cn",
    :scope => :sub,
    :prefix => "ou=groups,o=users"
 
  has_many :members, :class_name => "LdapUser", :wrap => "member",
    :primary_key => "dn", :foreign_key => "dn"
end

The ldap_mapping part is very similar to the previous one for LdapUser, but the has_many is where the real ActiveLdap magic starts!

We are letting ActiveLdap know that an LdapGroup has LdapUser members, which are defined in the multi-valued attribute member, where each of the values is the DN of an LdapUser. If you’re looking for a bit more detail, refer to the ActiveLdap documentation. Keep in mind that the code above is for the specific schema used by my example application and you may have to change it to match yours.

With that, we should be able to list all of our LDAP groups and find the members of any particular one in the console:

>> LdapGroup.all.collect { |g| g.cn }
=> ["super_admin"]
>> LdapGroup.find("super_admin").members.collect { |m| m.dn }
=> ["uid=ebianco,o=users,dc=example,dc=com"]

Now we’ll create an association between LdapUser and LdapGroup so that given a user, we can figure out which groups he/she is a member of. We’re going to tell ActiveLdap that a user’s groups are those groups in which the user’s DN appears in the group’s member attribute:

belongs_to :groups, :class_name => "LdapGroup", :many => "member",
  :foreign_key => "dn"

Let’s check our handiwork in the console:

>> LdapUser.find("ebianco").groups.collect { |g| g.cn }
=> ["super_admin"]

Now why did we go through all of this effort? declarative_authorization allows us to provide an instance method for User, #role_symbols, that returns an array of symbols representing the list of roles that the user has. With our ActiveLdap setup, mapping a user’s roles to LDAP groups becomes a one-liner:

def role_symbols
  ldap_entry.groups.collect { |g| g.cn.to_sym }
end

From here, we can define the authorization rules for our LDAP-based roles. declarative_authorization reads these from config/authorization_rules.rb:

authorization do
  role :super_admin do
    has_permission_on :users, :to => :manage
  end
  role :guest do
    has_permission_on :users, :to => :read
    has_permission_on :users, :to => [:create, :update, :destroy] do
      if_attribute :id => is {user.id}
    end
  end
 
end
 
privileges do
  privilege :manage do
    includes :create, :read, :update, :destroy
  end
end

Now we can use declarative_authorization as usual. I won’t go through all the details but if you want a primer on using declarative_authorization, you can start here and browse the commits on my authlogic_example branch.

That love of music carried into high school. I had stopped playing piano but in music class I picked up the clarinet quite quickly. I transferred to another school after grade 9 because the school I was in was planning to cut their music program entirely and I could not imagine being without it. At my new school, I was blown away when I heard the excellent performances of the senior jazz band and ensembles. I was fiercely determined to play with them but not many modern jazz arrangements called for a clarinet. So I learned to play saxophones.

At the same time, I continued tinkering with computers, teaching myself how to program because I wanted to program video games one day. An exhibit at the Ontario Science Centre featuring the “new” graphical web browsers, Netscape and Mosaic, inspired me to try my own hand at web publishing as soon as we were able to get connected to the Internet. In high school programming classes, I was well ahead of the curve, frequently finishing assignments meant to take hours in a matter of minutes.

And so, when I graduated from high school and decided I wanted to go to university, I had a difficult choice to make: which of these two things would I choose to focus on?

I ultimately decided that I was more passionate about computing and that it would also lead to a better career, so I decided to major in Computer Science.

Even then, I didn’t entirely stop playing music. I started taking clarinet lessons, intending to enhance my skills well beyond the intermediate proficiency I had achieved in high school. My teacher encouraged me to play for a youth symphony orchestra. My stand partner eventually became my first girlfriend and my stint with the orchestra culminated in a performance of von Weber’s Clarinet Concertino.

I’m not sure exactly when it was, but I did eventually stop playing music to devote myself entirely to my Computer Science coursework and related projects. My clarinet has been sitting in storage for a long time, untouched, unplayed, unloved. The piano my sisters and I used to play is still in our family home, but has been in need of tuning for a very long time and has also been neglected.

I’ve begun my career as a web developer and I feel that I’ve made an excellent choice. But recently, I felt like I needed to bring music back into my life. Taking advantage of the Toronto Symphony Orchestra’s youth program, tsoundcheck, I bought a package of tickets for three concerts, two of which I’ve already attended. Now, also for the first time in years, I have thought about taking my clarinet out of storage, having it checked out, and playing it again.

I am rediscovering my art; I am rediscovering my music.

class WebTransaction
 
  # Base URL for transaction web service
  SERVICE_URL = "http://accountingservice.com/"
 
  def transaction_url
    url = SERVICE_URL
    url << "VAL1=foo"
    url << "&VAL2=bar"
    url
  end
 
end

The class is meant to represent a transaction being posted against a rather odd web service that actually uses GET rather than POST for posting transactions (bad web service!). In my actual code, the URL parameters appended to the SERVICE_URL base would be determined on a per-object basis but I’ve simplified it here.

Here’s the punchline: SERVICE_URL was changing! Calls to transaction_url would keep on appending more variables to it. If you’re particularly clever with Ruby, you’ve already figured out exactly why. But if you’re scratching your head like I was, here are some hints:

• In Ruby, constants aren’t. In fact, they’re really no different from variables except for the fact that Ruby detects that variable names in all-caps are probably supposed to stay constant and warns if you try to assign to them.
• <<, for strings, will append to the end of the string.
• Ruby strings are mutable. That is, operations on a string variable will usually be done in place, rather than returning a new string. (Method calls, on the other hand, are a different story!)
• Assigning a String variable to another String variable will assign the reference. That is, the two variables will be pointing at the same object.

Hit the jump to see the solution to this little mystery…

SERVICE_URL is only directly assigned to when it is declared. But what happens when I assign SERVICE_URL to the local variable in transaction_url, url. They’re pointing to the same object!

Then I go ahead and I start appending things to the end of the string. Ruby has no complaints because I’m not assigning to SERVICE_URL but the object that it is pointing to is being changed! The operation is causing the URL parameters to be appended in place.

And that, friends, is what happens when constants aren’t. Let’s fix this little error:

class WebTransaction
 
  # Base URL for transaction web service
  SERVICE_URL = "http://accountingservice.com/"
 
  def transaction_url
    url = SERVICE_URL.clone
    url << "VAL1=foo"
    url << "&VAL2=bar"
    url
  end
 
end

Now, instead of appending to the string object referenced by SERVICE_URL directly, I’m creating a copy of the object and then appending URL parameters to that.