Every day for the 2 weeks leading up to to Christmas, imason gave each employee a small gift. One of the gifts was something of a "confetti canon". A few colleagues and I had wars between us and on one occasion I videotaped Boyan shooting the confetti in a senior co-worker's office.

I wanted to try out Windows Movie Maker, so I put together a short clip of the confetti shooting coupled with some Benny Hill music (The idea for the music came from the Benny Hillifier - a site where you can take any YouTube video and apply Benny Hill's Yakety Sax to it).

Using Windows Movie Maker, it took only 10 minutes to make this short video (The haste in which I created the video will quickly become apparent when you watch the video). Although Windows Movie Maker has a couple neat features, I still prefer Corel/Ulead's VideoStudio Professional which I used to create my Summer 2008 video. The price tag of $79.99 is well worth it, but Windows Video Maker is free so if you don't need the extra features provided by VideoStudio, Windows Movie Maker might do the trick.

Here's the short movie clip that I've entitled "Fun at imason":

Many of my co-workers here at imason are University of Waterloo alumni. I often hear people talking about Waterloo Economics Associate Professor Larry Smith. He's apparently a very knowledgeable and entertaining professor, but I didn't have the privilege to attend Waterloo.

Somebody posted a "Larry Smith Lingo & Prof Quotes" page and although these are probably more entertaining for those who have attended his classes, I still found them to be very amusing anyway. Here are my favourite 11 quotes:

• I'm sorry, ladies and gentlemen; we're finishing this course come hell or heart attack
• You can go to the Bank of Canada website and look up these numbers [about forms of money]. It's more fun than visiting a porno site.
• People who have REAL lives get hundreds of email messages a day. How do I know you're a real person? When I ask you how it's going and you say: Damn email's driving me crazy! Yes! You've reached manhood!
• Maybe I should fall down and break my neck. That would be entertaining
• Masturbation is merely the act of making love to the one you love best.
• I'm a legend in my own mind.
• Beware, beware, danger there lurks. Warning, warning, run in the other direction...
• Americans know of only two countries America and Not-America.
• A person who can see in the land of the blind will be king
• I wonder where she [Buffy the Vampire Slayer] was in my highschool. . .all my teenage fantasies rolled together.
• I don't need to impress you, I impress myself

While working on my .NET State Machine workflow today, I ran into an issue: I wanted to send an e-mail to a user every XX days to remind them to finish filling out a form, and I wanted those e-mails to continue being sent until the form had been filled out.

At first I thought this would be a simple While Activity with a Delay Activity timer inside it, but a Delay Activity has some limitations: I originally added it to my StateInitialization Activity, but it can’t be used inside a StateInitialization Activity because it inherits the IEventActivity interface. This also means that you can only use a Delay Activity as the first Activity in an EventDriven Activity, which prevents you from putting a Delay Activity inside a While loop.

So I took a quick look at other people running into the same issue and found this user group discussion, but I didn’t see any viable solution for repeating the Delay Activity indefinitely.

So to solve this, I added a new EventDriven Activity to my State Activity and set the Delay Activity as the first Activity in the EventDriven Activity.

Then I added an IfElse Activity to check if the form had been filled out or not. If the form is filled out, I change the state to “CompleteState”. But if the form hasn’t been filled out, I set it back to the current state which will re-trigger the EventDriven Activity, thus re-starting the Delay timer.

It will continue this loop until the form is filled out, sending an e-mail every time it executes. This is exactly the functionality I was looking for, but the approach to accomplish this was slightly different than I had expected.

In my 6+ years in the software development business, I’ve used a variety of techniques for performing developer knowledge transfers. When I hold a knowledge transfer session, I like to set my own objectives (What am I hoping to get out of the session?), familiarize myself with the objectives of my audience (What is my audience looking to achieve?), know the audience’s skill level (If I move quickly, will they be able to follow?), and I like to be familiar with the logistics (Have I booked a training room? Do I have sufficient hardware? Software is installed? Do I have Admin privileges?)

When your audience is large, the technique is much different than when the audience is small. It’s more difficult to completely engage a larger audience, so the key is to do hands-on training to ensure your audience is following along. I’ve done sessions that weren’t hands-on, but they were far less effective than the hands-on sessions, and are usually a result of time/logistics constraints than anything else.

To date, my most effective developer knowledge transfer session involved choosing 2 or 3 small feature enhancements (Or bugs), and using a “Pair Programming” approach to develop these features. This obviously works best in a pair (i.e. training 1 other person), but I think it can also be effective for training up to 3 developers. Using a meeting room on a projector, each developer would take turns writing some code. This keeps them engaged and when they aren’t writing code they stay focused because they need to know what is happening for when it’s their turn to write the code.

I feel that this is the absolute best way for new developers to learn about the code, and it’s the most rewarding way for the developer(s) who wrote the code to showcase his/her code. In addition to the learning benefits, you are also using your time efficiently by actually addressing a new feature or existing bugs. If you’re on tight deadlines, this approach allows you to keep the project moving forward while transferring knowledge at the same time. The last benefit of this approach is you can incorporate a code review into the session by getting an objective viewpoint from the developers you are transferring the knowledge to (Assuming the recipients are experienced enough to have constructive suggestions).

In summary, the benefits of hands-on knowledge transfer are as follows:

·         Productivity in that the project keeps moving forward (Tight project deadlines are a reality in our industry)

·         Hands-on learning for the recipients (Make sure to use proper source control in case something goes wrong J)

·         Simultaneous code-review (Find all those divide by zeros)

·         Better focus from the participants (Nobody falls asleep)