Travel Stories

November 1st, 2010

A couple fun stories from our trip around Europe.

The $30 laundry. We packed light, which made laundromats a frequent necessity. One evening in Italy we found a laundromat, I found the change machine, but couldn’t read the instructions. Thinking that these machines were universal, I fed it a 20 Euro bill. I was surprised when the machine expelled 20 Euro worth of flat pieces of metal that could only be used in that laundromat. I carried the fake coins around for the remainder of the trip, tried to use them at other laundromats, but never did find another washer that took the fake coins.

Emergency at Buckingham Palace. We met up with a friend in England who took us on a tour of traditional British Pubs – bangers & mash, along with many fresh pulled pints were consumed. The next day I decided to go for a run through the Royal Parks, I ran for an easy 45 minutes, but as I approached the heart of the park, in front of Buckingham Palace, I started feeling a tightness in my stomach. I frantically began my search for a toilet. I started scoping out the snack vendors for facilities, nothing, I started moving towards the park’s parameter, nothing, I looked for possible tree coverage, nope. Visions of being arrested for squatting in-front of Buckingham Palace were screaming through my mind just as a found a tourist map with clearly marked bathrooms, a quick stop at the Green Park tube station and I was back at it. Crisis averted.

The economy hotel. We booked most our hotels the day-of on Hotwire or similar bidding type websites. Not knowing what hotel we were purchasing led to a very wide variation of quality in our accommodations – which kept things interesting and fun. Hotel Wanda was definitely one of our interesting experiences. We struggled for sometime finding Hotel Wanda in the medieval streets of Florence, but eventually bumbled into a 20 foot door with a buzzer for our hotel, we rang, the door was buzzed open, we stood in a dark room of halls, doors, apartment entrances, plaster statues, and stairs – no signage. After some trial and error we discovered the hotel entrance on the 2nd floor where we were greeted by a man at reception (and the only member of staff in the hotel). The man apologized for being drunk, then showed us our room and disappeared. The room was huge, a giant ashtray was sitting on our table (both of us are somewhat sensitive to smoking), upon further inspection, the comforter was riddled with cigarette burns, and the lock on the door was broken. We decided to make the best of it, opened the windows to let some fresh air in, and headed out to explore the city. Upon our return (in the evening) we discovered there was a bar beneath our room, the smoke from the bar patrons, along with their conversations and the music were wafting into our opened windows. No hotel staff were to be found. We closed the windows, popped in the earplugs, and tried to salvage the night. It was a cheap hotel, and we certainly got what we paid for.

We weren’t the only one with similar experiences at Hotel Wanda:

an apparently very drunk gentleman yelled at us from down the street and asked if we were looking for Hotel Wanda. He apologized, took us upstairs and, despite being extremely intoxicated, attempted to tell us which rooms we could have. Although the rooms were very big, it was a bit dark and strange.- Crazy experience (and not in a good way)

Author: Adam Kahtava Categories: Personal, Running Tags:

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, 10 minutes, and 59 seconds). I’m not too far off the qualifying time, as I managed to finish Calgary in 3:22.

Get out there and run! :)

Author: Adam Kahtava Categories: Calgary, Personal, Running 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.

POWERSHELL:
  1. # Installs git for Windows via PowerShell
  2. #
  3. # Sample usage:
  4. #
  5. #  Install git:
  6. #    PS> install-git
  7. #
  8. # Adam Kahtava - http://adam.kahtava.com/ - MIT Licensed
  9.  
  10. function global:install-git {
  11.   install-file 'http://msysgit.googlecode.com/files/Git-1.6.4-preview20090730.exe'
  12. }
  13.  
  14. function global:install-file([string] $urlPath) {
  15.   $filename = download-file($urlPath)
  16.   invoke-item $filename
  17. }
  18.  
  19. function global:download-file([string] $urlPath) {
  20.   $urlSplit = $urlPath.split('/')
  21.   $filename = (Resolve-Path .).ToString() + '' + $urlSplit[$urlSplit.length - 1]
  22.   $webclient = New-Object "System.Net.WebClient"
  23.   $webclient.DownloadFile($urlPath, $filename)
  24.   return $filename
  25. }

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:

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

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:

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

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:

JAVASCRIPT:
  1. (function(){
  2.   document.domain = 'kahtava.com';
  3.   $.get('http://adam.kahtava.com/contact-me/', function(data) {
  4.     alert(data);
  5.   });
  6. })();

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.