• Skip to content
  • Skip to primary sidebar

Sazbean

Software Development Management

Main navigation

  • Home
  • About
You are here: Home / Archives for Aaron Worsham

Aaron Worsham

Aaron Worsham / Feb 11, 2009

JSON and the Argonauts

greek-statueThe Greeks sure were fond of super-hero team titles.  There was Jason, commander of the Argo and her crew of the best of the best, pitted against irresistible forces beyond moral man’s endurance.   What does this have to do with JSON, the JavaScript Object Notation standard used by the web 2.0’s best of the best of overcome an accent foe called Same Origin Policy?  Can’t think of a thing, I just really liked the title.

A funny thing happened on the way to the Mashup. I’m sure someone somewhere, maybe even here, told you that RSS feeds were going to revolutionize the way we distribute information.  We were all so right in so many ways because RSS, or ATOM if you prefer, has opened up the world to the unimagined possibilities available online.  Think of some way that you want to consume information.  Go ahead, I’ll wait.  Ok, you are all right you can consume information that way. Oh, heh, I mean almost all of you are right.  That guy in the back with the Helvetica shirt in Metalica font, I’m sorry but we can’t help you with your idea.  Thing is, as much as you may want to have a single page that can then pull and update XML based RSS feeds from any site in the world from within the browser without refreshing, you’re not allowed.  It is for your own protection actually.  We call it the Same Origin Policy.

Here is the idea.  When your web browser pulls down a web page’s code from a modern site, it is usually pulling down a collection of HTML, Stylesheets, Javascript.  That HTML tells the page what content goes where and what images to place by the content.  The Stylesheet (CSS) tells the browser how to make that content look and how to make it act on the page.  Then the Javascript is there to give the page life, make it interact with events, make it do impressive things that we have come to love and cherrish.  In the AJAX world, those impressive things involve grabbing information from the server and updating the page without screen refresh.  Javascript is nye omnipotent in the browser, and yet there are some quantum limitations built into the works.  Beyond the sandboxing of JS, there is one little design decision from Netscape 2.0 that has totally altered the web 2.0 landscape.  Netscape decided that a browser would only allow scripts to interact with domains that the page came from.  If a page is loaded from www.bobsdiscountlasers.com then AJAX calls are limited to bobsdiscountlasers.com.  The grand illumination of mashups, where data flows from many different locations onto one page in a relevant way, almost never happened because of this.

Web browsers weren’t designed with mashups in mind, and ‘the warts have been there from day one’, [David Boloker, cofounder of the OpenAjax Alliance and IBM’s CTO of Emerging Internet Technologies] says. Browsers contain a security feature called the same-origin policy that’s meant to keep malicious code hosted on one site from grabbing data, such as stored credentials, off another site. The same-origin policy prevents websites from one domain from requesting data belonging to another domain. ~ Security services and Mashups

But, of course, Mashups do exist.  We see Google Maps on thousands of pages not under the google.com domain.  How is it done?  We’ll get to the hero of the day in a second, for now lets look at other popular workarounds

  • Mashup at the Server Side:  Since the JS limitation is browser based, you could do all of your mashups at the server.  The server could serve as the collector of the different sources of information, combine them intellegently and cache the results.  At best this idea is inconvenient because it adds layers where they need not normally be.  At worst this does not scale when you have a single location for distributed information
  • Flash/Flex:  The Flash VM doesn’t have the Cross Domain limitation that plagues JavaScript.  A file on the server gives a list of permitted sites that the Flex app can pull data from.  I have talked with Adobe Evangalists about this option and they seemed to hint that this design decision was intented to hit javascript where it was weakest.
  • AJAX Proxy.  Similar to the first method, a proxy allows the client to pull the information through it.  It isn’t stored on the proxy, though it can be cached, and no combination is done.  Again, this is a scaling issue

Stop passing code, start passing data. What all of these work arounds do is bypass the security concern with Same Origin Policy (SOP).  SOP was originally intended to combat early attempts at Cross Site Scripting (XSS).  Modern XSS has a nasty list of exploits that I don’t have time for here, but one way to think about it is this:  If you let Javascript pull code from untrustworthy places you are inviting problems.  One possible approach to this issue was to stop the push and pull of code but to allow the pushing and pulling raw data.  That is what JSON is, a way to encode data to be pushed and pulled using AJAX calls.  Though the X in AJAX stands for XML, AJAX really is more often using JSON because SOP will allow it to be used cross-domain.  So with JSON you can pull in Google Maps and that list of Micro Brewerys right in the browser, Mash them up using Javascript, and asyncroniously keep the data refreshed, the app reactive, and your buzz in good spirits (You are walking to these pubs, right?)

My prediction; RSS feeds are going to move away from XML and on to JSON in the future.  Or at minimum, support both.  John Resig, the creator of jQuery, even has a converter to get us all started.

Photo attributed to jasonr611

Technorati tags: software, json, javascript, javascript object notation, rss, atom, xml, mashup, web development, code

Aaron Worsham / Feb 5, 2009

Take the show on the road

shamrock1

This is a follow-up on yesterday’s post

My sister is in Ireland.  She is drunk right now (It doesn’t matter what time of day you are reading this, I stand by that statement), happy and having the time of her life.   God love her I don’t think I have ever been more proud.  You see, my sister is, or was, a very introverted person.  She always clung close to home and took whatever jobs were within driving distance of the folk’s place.  That, I told her more than once, was a teriffic recipe for Suckjob pie because she had no options and her bosses knew it.  The last company pushed her so far that, one night in a desparate cry for help, she requested applications from every college in Europe with an english website.  There was no grand plan involved, it was more like walking into the Merchant Marines recruiting office in the hopes they would take you far away no questions asked.  Thing was, she was exactly what some no-name program in Dublin (*cough*Trinity*cough*) was looking for.  They needed someone with her skills in the program and she needed some program to need her skills.  Perfect fit!

Those same set of circumstances apply to many people in the tech field looking for gainful employment.  One avenue I neglected to address in yesterday’s post was the double sided nature of location centric job searches. If you have worked in an industry like the tech sector for at least a couple years, one of your greatest assets is your network on contacts.  While those contacts are a fantastic resource for finding work, the options available are pretty limited to geography because the ‘mike knows a guy who needs a server dude’ chain will only stretch so far.  Think of it as a small, heavily spoked spiderweb centering on your immediate location.  If there is a job in your field, chances are your network knows about it and can get you hooked up. Its just that the number of hookups is directly related to the size of the community.  Here people in urban areas have an advantage over rural and major metropolitan over small cityscape.  Even still, outside of SF, NY, Seattle, Chicago, and Austin, most local networks can be pretty weak sauce even in high population demographics.  Those areas  are technology and media company hotbeds, groups that use ten times the average number of tech people for their size.  This is where being location flexible gives you a huge advantage when looking for a good job because you can tap into these and other hotbeds, live and work amongst your people, and grow ever more impressive networks.

Being open to relocation can make all the difference when searching.  Believe me, I know the reasons why you have dismissed the idea completely.  I too have a house, a family, community ties, school ties, a bad market for home resale, and friends and loved ones right here where I live.    But the chance to find a ‘Perfect Fit’ with your career can make an extremely compelling case to ignore those reasons and relocate anyway. [Note: the author of this post lives in Michigan and his snowblower committed suicide from sheer exhustion, your regional contentment may vary].   It all boils down to work/life balance.  I’ve personally found that when I love what I do and enjoy the place that I do it, I carry that contentment on home with me.  Equally, when I hate what I’m doing and who I’m doing it for, that discontentment follows me home and permeates everything I do.  Finding one that fits is much easier when you spread your options across the map.

Though there are times when making that life changing jump just isn’t worth it… I’m looking at you Web Developer in Anchorage, Alaska.

Photo attributed to genvessel

Aaron Worsham / Feb 4, 2009

For 'Bleeding Edge' prepare to pay in blood

knife-edgeIf you are in software development, take a good hard look at the code you are writing right now.  If the string of Roman characters resemble Java or .Net or C/C++ then I have some wonderfully awful predictions about the next ten years of your life; That language is your scarlet letter and will follow/define you for the next two jobs you end up accepting.  That sounds bad but you are the blessed among the damned – You can and will find that next job.  For Bleeding Edgers, the road is not so well paved.

In my last job I was a Bleeding Edger.  You know one if you work with one, always looking at the latest release of the newest language to see if it has a better solution to your particular problem.   In my case as a Software Manager, being a Bleeding Edger meant an obsession with ROI in our software solutions.  Links to anything that could trim development time and/or expense filled my Delicious feed.  I pushed my team to move beyond Java’s heavy web frameworks and to adopt Rails as a rapid application prototyping framework.  We cranked out good, solid software solutions 4 times faster than our java days and I was happy.  When a project came along that could use Flash, we wrote it in Flex instead because knowing how this company worked, they’d want a desktop and an offline version in the future.  A year later we were cross compiling the Flex code into an AIR application and saving a tremendous amount of time, and we were happy.

But being a Bleeding Edger means there will be dark days to contrast the brilliantly sunny ones.   Our ROI figures were not enough to protect all of us throughout this economic upheaval and some would have to make the sacrifice for the rest.  I would like to say that, as the manager, I fell on my sword for them but that’s not really the case.  The decision never reached my level.  I was the highest compensated on the team and so I was killed by simple, cold math.  The blood spilled that day is still dripping.  It still hurts.

The software job market is a rigged system.  Heavyweights in the market put enough momentum behind enough Java and .Net and C/C++ projects that they can be considered perpetual motion machines.  A class hierarchy between Java and .Net, perpetuated by recruiters with a simple word match on a job board, stacks the deck against the Bleeding Edgers in the mainstream.  You are a Hatfield or you are a McCoy or you are an innocent bystander likely to get shot in the crossfire.  The mainstream is not a system able to help the Bleeding Edger.  Sure, there will be the occasional posting that isn’t in your location and is looking for some bizarrely specific, must have requirement that categorically eliminates all humans including the guy who originally wrote the book on the library they are using.  In the end, Bleeding Edgers need to work outside of the system.

For the young, there are no unemployed Bleeding Edgers only uncompensated open source code contributors.  If you have the ability to live on nearly nothing, working outside the system can be a very rewarding and ultimately fulfilling life choice.  For the responsibility burdened older generations, there are really only two options as a Bleeding Edger.  The first, and likely most chosen, is to re-assimilate into the collective; scrub your resume of all references to Ruby and Jython, and  Grail, prop up your sun certifications if you have them, and become a team player.  The rest of us Bleeding Edgers, the ones the economy hasn’t driven to ditch digging, will become the countries next batch of serial startup founders.  We will be easy to spot, just look for the scars.

Technorati Tags: code, ruby on rails, ROR, software, software management, software development, web development

« Previous Page
Next Page »

Primary Sidebar

About Sazbean


Sarah Worsham (Sazbean) is a Webgrrl = Solution Architect + Product Management (Computer Engineer * Geek * Digital Strategist)^MBA. All views are her own.

Business + Technical Product Management

My sweet spot is at the intersection between technology and business. I love to manage and develop products, market them, and deep dive into technical issues when needed. Leveraging strategic and creative thinking to problem solving is when I thrive. I have developed and marketed products for a variety of industries and companies, including manufacturing, eCommerce, retail, software, publishing, media, law, accounting, medical, construction, & marketing.

Copyright © 2008 - 2025 Sazbean • All rights reserved.