Archive

Archive for March, 2010

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.

The iPhone

March 16th, 2010

About a year ago I purchased my first ever cellphone (an iPhone) - before the smart phones I'd grab any old freebie phone that came with a multi-year phone contract.

Getting an iPhone was simple enough, but the reactions to owning one have been surprising. Responses have swung from: "Right on! Welcome to the fold!" to "Oh, an iPhone, it's just a status symbol."

I will be the first to admit that I'm more likely to whip out my new phone, but did you see my old phone? It was a the size of an Oh Henry! bar, the buttons faded, the screen cracked, and the antenna was a lightning rod - yes that is a picture of my old phone. Sure, I could have been a hero, milked another 5 years out of the old phone, but... I could also give up my washing machine for a washboard, my bike for a horse, and start burning candles. :)

Author: Adam Kahtava Categories: Musings Tags:

More Reasons For Testing: Prevent The Morning-After Syndrome

March 11th, 2010

Testing (Test Driven Design, Unit Testing, Mocking) is a part of developer popular culture - most developers understand that by writing the tests first we're forced to focus on the important details as we build software, that by writing tests we prove that our software works as we build it, and that by running our test suite against our changes we gain assurance that our code still works, but did you know that testing is also a cure for the 'morning-after syndrome'?

The 'morning-after syndrome' as described by Uncle Bob (Robert C. Martin):

Have you ever worked all day, gotten some stuff working, and then gone home, only to arrive the next morning to find that your stuff no longer works? Why doesn't it work? Because somebody stayed later than you and changed something you depended on! I call this 'the morning-after syndrome'. - Robert C. Martin, Agile Principles, Patterns, and Practices in C#

Bob makes the point that by writing tests we make our code more stable and brittle to change, which prevents our coworkers from making casual breaking changes. Sure-sure, brittle tests are frustrating when refactoring, but at the same time these brittle tests accentuate the importance that the code under test should not be modified. Core components that your system depends on should be stable and brittle.

Bob continues:

Many factors make a software component difficult to change: its size, complexity, clarity, and so on. But we are going to ignore all those factors and focus on something different. One sure way to make a software component difficult to change is to make lots of other software components [like tests] depend on it. A component with lots of incoming dependencies is very stable, because it requires a great deal of work to reconcile any changes with all the dependent components. - Robert C. Martin, Agile Principles, Patterns, and Practices in C#

Author: Adam Kahtava Categories: Book, Quality Assurance, Testing Tags:

Memcached On PowerShell

March 9th, 2010

Memcached has been around for a while, but it's still pretty neat.

Experiencing a bottleneck with your Object Relational Mappers, Services, Middleware, Database, or whatever? Then Memcached it!

Memcached was intially developed for LiveJournal by Danga Interactive in 2003, and is used by many large sites (YouTube, Amazon, Twitter, to name a few). Today, you can find a Memcached library for all your favourite languages (here's the list).

Now; cache testing is tough period, and testing Memcached (which is accessed through a telnet client) is even more difficult - it's fair to mention that there are a large number of wrappers for Memcached outside the .NET world, but I couldn't find one for that met my needs.

Introducing Memcached on Powershell

Sample usage and output

Loading the script (source can be found here)

CODE:
  1. PS C:\> .\memcached-on-powershell.ps1

Checking Memcached stats on an empty instance

CODE:
  1. PS C:\> memcached-stats 127.0.0.1 11211
  2. Total items in cache:  0
  3. No slabs found

Checking Memcached stats after items have been added to the cache

CODE:
  1. PS C:\> memcached-stats 127.0.0.1 11211
  2. Total items in cache:  3
  3. Stats for Slab:  1
  4.          Key: 'resume-service:resume:adam-kahtava'
  5.          Key: 'open-source-service:github:adamdotcom'
  6.          Key: 'open-source-service:googlecode:adam.kahtava.com'

Clearing all Memcached items

CODE:
  1. PS C:\> clear-memcached-items 127.0.0.1 11211
  2. Total items in cache:  0

Checking Memcached stats on a cleared instance

CODE:
  1. PS C:\> memcached-stats 127.0.0.1 11211
  2. Total items in cache:  0
  3. Stats for Slab:  1
  4.          Empty

If your test obsessed then you might be interested in the Memcached tests.

As always feel free to contribute, view, or download the source here.

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

Developers, Don’t Let Your Babies Grow Up To Be Programmers

March 2nd, 2010

Experts continue to warn of a looming shortage of North American scientists, engineers, developers, and IT workers in general. Efforts like the K-12 CS Model Curriculum attempt to introduce computer science concepts to children as they progress through grade / high school in hopes that they'll fill this void, but there's another issue in play. Developers don't let their children grow up to be programmers.

My hunch is that, most engineers, developer, or related IT professional would rather see their children succeed them - becoming doctors and lawyers and such, not an IT professional.

Malcom Gladwell (in Outliers) presents an interesting account of career progressions within family trees:

In 1982, a sociology graduate student named Louise Farkas went to visit a number of nursing homes and residential hotels [she was looking for] the children of people [who had immigrated] at the turn of the last century. And for each of the people she interviewed, she constructed a family tree showing what a line of parents and children and grandchildren and, in some cases, great-grandchildren did for a living.

Here is her account of "subject #18":

A Russian tailor artisan comes to America, takes to the needle trade, works in a sweat shop for a small salary. Later takes garments to finish at home with the help of his wife and older children. In order to increase his salary he works through the night. Later he makes a garment and sells it on New York streets. He accumulates some capital and goes into a business venture with his sons. They open a shop to create men's garments. The Russian tailor and his sons become men's suit manufacturers supplying several men's stores The sons and the father become prosperous. The sons' children become educated professionals.

Farkas's ... family trees go on for pages, each virtually identical to the one before

From my observations, many developers / IT workers are first generation middle class, first generation post secondary educated, immigrants, or all of the above (myself included). Being a developer or IT professional is a small step up the ladder in helping our successors succeed.

Author: Adam Kahtava Categories: Musings Tags: