Archive

Author Archive

On Teams: Religious Debates Erode Respect

July 15th, 2010

“religious debates … consist largely of people expressing strongly held personal beliefs about things that can’t be proven. … they rarely result in anyone involved changing his or her personal view. … besides wasting time, these arguments create tension and erode respect among team members, and can often prevent the team from making critical decisions.” - Steve Krug, Don’t Make Me Think

There we have it, religious debates erode respect.

Author: Adam Kahtava Categories: Software, Team Work Tags:

Finishing a Marathon

June 7th, 2010

At the 32km marker a series of signs were staked into the grass along the course. The first sign read “You’re doing it!”, the next “Only 10 more kms!”, and the next “You’re running a marathon! You ARE a marathon runner!” A tear welled in the corner of my eye, perhaps from the pain in my quads, or the reality of still being 10km from the finish, but more likely because it finally dawned on me that I was indeed running a marathon - an event I’d been looking forward to since running the Half Marathon a year earlier.

Training for a Marathon was relativity easy. Basically you run one long run every week, in addition to running 6-10km 4 times every week, then rinse and repeat for 3 months. As boring as that may sound, once I got into a routine, and found a running partner, I looked forward to running. Here’s the schedule I followed (I know, I know, don’t laugh, it’s from the far from reputable About.com): Basic Marathon Training Schedule for Beginners.

My next goal is to qualify for a Boston Marathon (qualifying time is 3 hours and 10 minutes) and run alongside the 20,000 participants in the Boston next year. I’m not too far off the qualifying time, as I managed to finish this Marathon under 3 hours and 30 minutes - look me up in the 2010 Scotiabank Calgary Marathon Results.

Get out there and run! :)

Author: Adam Kahtava Categories: Calgary, Personal Tags:

We All Live In An Uncle Bob Dialog

May 31st, 2010

Robert C. Martin (affectionately known as “Uncle Bob” in the development community) has a number of great books demonstrating the benefits of OOD/OOP and good design principles. Those acquainted with his books will also be familiar with his generous use of conversation dialogs between developers.

A sample excerpt:

RCM: “Will you help me write a little application that calculated bowling scores?”
RSK: “… Sure, Bob, I’d be glad to help. … I used to be a pretty good bowler … “
RCM: “Let’s begin with scoring a single game …”
RSK: “OK, we’re going to need some test data. Let me sketch out a little picture of a scorecard …”
RSK: “Shall we start at the end of the dependency chain and work backward? …”
- A Programming Episode from Agile Principles, Patterns, and Practices

This dialog continues for some 40+ pages as we’re walked through a paired programming session demonstrating test driven development and refactoring techniques. Admittedly, while reading these dialogs, I initially thought they were a bit over-the-top (campy), but as I actively listen to the communication happening within my team I realize that these dialogs are happening all around me.

An excerpt from this past week:

Me: “Will you help me write a stored procedure to retrieve the customer’s cart items count and default lightbox items count?”
Dev: “Sure, Adam, I’d be glad to help.”
Me: “Cool! This will be more efficient than aggregating the data from multiple repositories …”

Pull yourself in, that’s right, a little closer to the campfire, now sing it with me, “We all live in a yellow submarine… errr… an Uncle Bob dialog, an Uncle Bob dialog.” :)

Author: Adam Kahtava Categories: Musings, Software, Testing Tags:

Book Reviewed: Rework by Jason Fried and David Heinemeier Hansson

May 27th, 2010

Rework by Jason Fried and David Heinemeier Hansson has been on Amazon’s top ten list for a couple months now and for good reason, it’s captivating, easy to read, engaging, and fun. However, I was disappointed with the lack of references. If the authors had included references to texts that back up many of their opinions (books like the Mythical Man-Month, Peopleware, etc…) then Rework could have more impact on corporate decision makers. Unfortunately, without the external references this book is easily passed of as highly opinionated and subjective.

Author: Adam Kahtava Categories: Book, Review Tags:

Transparency, the Underpinnings of Becoming an Unprofessional

May 25th, 2010

The business world is full of “professionals” who wear the uniform and try to seem perfect. In truth, they just come off as stiff and boring. No one can relate to people like that.
Don’t be afraid to show your flaws. Imperfections are real and people respond to real. … Don’t worry about how you’re supposed to act. Show the world what you’re really like, warts and all … talk like you really talk. Reveal things that others are unwilling to discuss. Be upfront about your shortcomings. … You might not seem as professional, but you will seem a lot more genuine. - Rework: Jason Fried, David Heinemeier Hansson

I’ve struggled with the personal vs professional tension for sometime. Back in 2002, I started this site with the intention of professional self promotion (image above is my site from 2003). The results were predictable: the tone boring, the topics dry and most visitors saw through the veil of self promotion. I’ve matured since then (well I hope I have). :) Over the years I’ve found that a personal, down-to-earth tone maintains a healthy level of transparency both on the web and in real life. As Gandhi once said:

Happiness is when what you think, what you say, and what you do are in harmony.

Author: Adam Kahtava Categories: Musings, Personal Tags:

Install Git On Windows With PowerShell

May 4th, 2010

I like Git and here's a PowerShell script that I use to download and install Git on my Windows based development machines.

# Installs git for Windows via PowerShell
#
# Sample usage:
#
#  Install git:
#    PS> install-git
#
# Adam Kahtava - http://adam.kahtava.com/ - MIT Licensed

function global:install-git {
  install-file 'http://msysgit.googlecode.com/files/Git-1.6.4-preview20090730.exe'
}

function global:install-file([string] $urlPath) {
  $filename = download-file($urlPath)
  invoke-item $filename
}

function global:download-file([string] $urlPath) {
  $urlSplit = $urlPath.split('/')
  $filename = (Resolve-Path .).ToString() + '' + $urlSplit[$urlSplit.length - 1]
  $webclient = New-Object "System.Net.WebClient"
  $webclient.DownloadFile($urlPath, $filename)
  return $filename
}

Not familiar with Git? Then head over to the best online Git resource available.

You can find more of my PowerShell development scripts here.

Author: Adam Kahtava Categories: .NET, PowerShell Tags:

Interviewing Tips: The Interview Anti-Loop and the Warren Harding Error

April 22nd, 2010

A couple non-traditional considerations when preparing for a software development interview.

Prepare for the Warren Harding Error, Thin Slicing, Snap Judgements, and rapid cognition.

The Warring Harding Error as described by Malcom Gladwell:

Many people who looked at Warren Harding saw how extraordinarily handsome and distinguished-looking he was and jumped to the immediate - and entirely unwarranted - conclusion that he was a man of courage and intelligence and integrity. They didn’t dig below the surface. The way he looked carried so many powerful connotations that it stopped the normal process of thinking dead in its tracks. The Warren Harding error is the dark side of rapid cognition. It is at the root of a good deal of prejudice and discrimination. It’s why picking the right candidate for a job is so difficult and why, on more occasions than we may care to admit, utter mediocrities sometimes end up in positions of enormous responsibility. - Blink: The Power of Thinking Without Thinking

As Developers (and Generation X / Yers) we tend to buy into the ideal that "on the internet no one knows your a dog", an ideal that's been seared into our minds by Sesame Street and the like. An ideal where sunny days, chase the clouds away, where knowledge, technical skill, and communication should outweigh appearance - a place where being a dog, human, or giant harry elephant should be irrelevant. Unfortunately that's not reality. Clean up for your interviews, put away those circa Cobain sneakers, and pack in the facial jewelery. Warren Harding (considered one of the worst US presidents) may have been elected based on his appearance. First impressions matter.

Beware of the Interview Anti-Loop

The Interview Anti-Loop as described by Steve Yegge:

when I was at Amazon ... We eventually concluded that every single employee E at Amazon has at least one "Interview Anti-Loop": a set of other employees S who would not hire E. The root cause is important for you to understand when you're going into interviews, so I'll tell you a little about what I've found over the years.

First, you can't tell interviewers what's important ... they believe they are a "good interviewer" and they don't need to change their questions, their question styles, their interviewing style, or their feedback style, ever again. ...

Second problem: every "experienced" interviewer has a set of pet subjects and possibly specific questions that he or she feels is an accurate gauge of a candidate's abilities. The question sets for any two interviewers can be widely different and even entirely non-overlapping. ...

The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. ...

And then you should wait 6-12 months and re-apply. That's pretty much the best solution we (or anyone else I know of) could come up with for the false-negative problem. - Get that job at Google

Don't Trash Former Employers and Employees

One final bit of advice that's often overlooked. Avoid talking badly about past employers and coworkers. If you had an unfortunate string of bad career experiences, consider hiring a therapist, or telling your Mom about it. The job interview is not the place to retrace or reflect on past personal struggles, and it's not the place for trashing former coworkers and employers.

Author: Adam Kahtava Categories: Interview, Musings Tags:

Please, Call Me Señor Developer Not Senior

April 20th, 2010

This March marked my fifth year of working in the software realm and five years since graduating University, and this year (according to industry standards) I'm now considered a Senior Developer.

Funny enough. Today, I don't consider myself a Senior Developer, but a couple years ago I would have told you to "Call me Senior". Back in those days I may have been a Senior Developer within the monocultured context of the domain, language, and environment I was working with, but certainly not within the larger context of the software realm. I had surrounded myself with homogeneous tools, like minded colleagues, and had fallen into the trap of thinking I was an expert when I wasn't - we all thought we were Senior Developers.

"When you are not very skilled in some area, you are more likely to think you're actually pretty expert at it ... The converse seems to be true as well; once you truly become an expert, you become painfully aware of just how little you know." - Pragmatic Thinking and Learning: Refactor Your Wetware

Over the years I've observed that Experts and true Senior Developers are collectively regarded as such by their peers, not by corporate credentials, not by job titles, or duration of employment. Experts and Senior Developers are more preoccupied with getting things done, improving themselves, improving their environments, and helping others - not worrying about job titles and status.

"The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve." - Code Complete: A Practical Handbook of Software Construction

Please, don't call me a Senior Developer, I'm Mr. Developer or Señor Developer.

Author: Adam Kahtava Categories: Musings, Personal, Software Tags:

Give Away Everything: Creative Commons, Open Source, …

March 25th, 2010

remember from school other students preventing you from seeing their answers by placing their arm around their exercise book or exam paper.

It is the same [in the working world] ...

The problem with hoarding is you end up living off your reserves. Eventually you'll become stale.
If you give away everything you have, you are left with nothing. This forces you to look, to be aware, to replenish.

Somehow the more you give away the more comes back to you. - Paul Arden, It's Not How Good You Are, Its How Good You Want to Be

I identify with Arden's philosophy. The creative process is enjoyable. If I've had fun producing it, then why not share it? I think our tendencies to hoard, get hung up on copyright, and get picky about attribution stem from our fear of being taken advantage of and the fallacy of thinking we're special (we're not special). I think we should throw our code into the public, share our content, give away everything, and watch what comes back.

The painting above was created by Ron Krajewski, based on my photo (licensed under Creative Commons). Ron mailed me a copy of the painting - it's also available for purchase at Pet Art.

Author: Adam Kahtava Categories: Musings, Personal Tags:

The Same Origin Policy: JSONP vs The document.domain Property

March 18th, 2010

The Same Origin Policy ensures that the client-side code (JavaScript) running on a website originated from that website. This prevents website http://kahtava.com from accessing resources (via client-side code) on website http://malicious-password-sniffers.com or website http://adam.kahtava.com from executing resources from http://kahtava.com - note that the sub-domains differ, one being kahtava.com, the other being adam.kahtava.com

In most cases The Same Origin Policy is desirable. It helps to prevent malicious code that could potentially reveal sensitive information from being run on arbitrary website. However, the same origin policy also makes it difficult to share resources within a common root domain, or run external widgets on your site (like displaying The Project Badge within your site). There are a couple ways to circumvent The Same Origin Policy, but I focus on JSONP and the document.domain property in this post.

Ways to circumvent the Same Origin Policy

  1. JSONP
  2. Modifying the document.domain property
  3. Creating a server side web proxy

JSONP (JSON with padding)

How it works: JSONP dynamically creates a script element in the head of your HTML document which then requests data from outside your domain. JSONP exploits a loophole in the Same Origin Policy that allows JavaScript from an external sites to be run within your site (much like how web analytic tracking works). The JSON response, when returned, is executed within your browser at which time the JavaScript can manipulate your HTML page / DOM.

An Example Using JSONP with jQuery:

(function(){
  $.getJSON('http://adam.kahtava.com/services/open-source/projects.json?project-host:username=github:adamdotcom&callback=?', function(data) {
    alert(data);
  });
})();

Note the callback=? at the end of the URI, in jQuery this indicates a JSONP call.

Pros

  • Lets us make external calls to any endpoint that supports JSONP
  • Lets us make external calls from HTTP to HTTPS
  • Supported by all major browsers

Cons

  • A bit more complex upfront, but most server side technologies support JSONP, browsers are natively supporting JSON, and JavaScript libraries like jQuery continue to abstract away most of the complexity.

The document.domain property

How it works: the document.domain property contains the domain of the server from which the page was loaded. For example, the domain for http://adam.kahtava.com/ would be adam.kahtava.com whereas the domain for http://kahtava.com would be kahtava.com. The Same Origin Policy restricts resource access from kahtava.com to adam.kahtava.com unless we set the document.domain property to the root domain (in this case I'd want it set to kahtava.com to share resources with http://adam.kahtava.com).

An Example using the document.domain property:

(function(){
  document.domain = 'kahtava.com';
  $.get('http://adam.kahtava.com/contact-me/', function(data) {
    alert(data);
  });
})();

Pros

  • An easy way to access resources within our root domains
  • Supported by all major browsers

Cons

  • Prevents us from making external calls outside a root domain
  • Prevents us from switching between HTTP and HTTPS
  • Kind of a hack - technically, the document.domain property is supposed to be a read only property, but most browsers also provide set access

JSONP vs document.domain isn't a cut and dry comparison. JSONP lets anyone consume and share data, whereas overriding the document.domain lets you share resources within a common root domain. In simple cases where your only concern is sharing data within a single domain (exclusively on HTTP or exclusively on HTTPS), then overriding the domain works well, but in cases where you want to share or consume external data that may be passed over HTTP or HTTPS you'd probably want to stick with JSONP.

The Project Badge makes use of JSONP so it can work on your website. Most of my publicly available web services also make use of JSONP through a WCF JSONPBehavior.