ryan norris

Eventually, I will certainly upgrade my iPhone to – well, I was thinking the iPhone 4. I’ve never had a problem with the iPhone 3G.

Until now.

(more…)

The iPhone OS 4 SDK licensing agreement has been, well, unpopular.  To anyone who has paid attention to Apple over the past 20 years, it’s certainly not surprising that they want to lock down the ecosystem.  This has been their modus operendi for as long as I can remember.  So while Apple’s “take the ball and go home” strategy certainly generates a roll of the eyes from many, what’s surprising is the indignation that Adobe developer’s have expressed in being locked out of Apple’s poker game.

That indignation seemed to find an ally in Google.  At Google I/O 2010, there was much ballyhoo about open standards and open platforms.  There was direct mention of Flash being an important part of the internet at large, and Adobe fans seemed to have found a Mao for their Ho Chi Minh.  Outside of sharp words, Adobe had very little ammunition in this battle.  Adding Google as a key ally seemed at least to justify their position – even solidify a dynamic place in the marketplace for media delivery.

The politics of this war are less about openness of platform, however.  Apple’s exclusivity practices in the past few decades have been largely about limiting competition and thus maximizing margins from a niche product.  When the product suffered and competition increased in the early 90′s from Microsoft and others, Apple was only able to recover not by changing their strategy but by executing on the fundamentals that allowed this strategy to succeed in the first place – high quality.  Today, Apple has maximized the potential for the platform itself – whether it be a mobile device, laptop, or media center, to sustain it’s own profitability.  But with the computer and handheld market on lengthy cycles between purchases, maximizing revenue opportunity becomes a challenge of ensuring that customers are purchasing Apple product more frequently.  This is where the iTunes Music Store is so critically important to Apple’s strategy.

Flash as a platform is flawed, says Steve Jobs.  His arguments have some merit, particularly on handheld devices.  But once again, this is a proxy argument.  The problem with Flash isn’t that Jobs can’t control the content developed in the platform.  The problem is that by allowing Flash into the Apple ecosystem, Jobs would be opening a wormhole into an alternative media delivery platform.  Flash is a development tool – but by leaps and bounds it’s greatest claim in the frontier of the internet is multimedia content delivery.  YouTube, Brightcove, and Vimeo are all powered by Flash and all deliver the same content for free that Apple wants to be able to charge for.  This is where Apple dogma and Google dogma meet, and Adobe is simply a place for this war to be fought.

Adobe cannot win and remain sovereign in this battle.  Apple’s desktop platform is the chosen home for many creative’s who use Adobe’s landmark products like Photoshop and Fireworks.  Google owns YouTube, has built it’s own rich internet application framework, and fully backs the HTML5 standard that allows the modern web browser to do all of the things one could only do with the support of Flash in the past.  Google has Adobe smiling with a knife at their back.  For Google, the relationship is convenient to buy time until Android devices overtake Apple devices (likely in 2011).  Apple’s aggression gives Adobe little choice but to ally with the greater but less immediate threat.

Apple’s fatal flaw in this fight is not the control over development for their devices, but how users will get media delivery to those devices.  It’s not that Google is on the opposite side of the debate – they simply don’t care.  Google is a data company that is using mobile platforms as another tool for understanding their users as to maximize the ad revenue that has made them so successful.  Whether or not the user buys their content from Amazon or Apple or Walmart is inconsequential.  If the user clicked an ad for one of those companies to buy an MP3 and Google made $.05 from that click – it’s been a successful day for Google.  The Google approach is open solely because it maximizes revenue potential by maximizing the channels that can generate that revenue – not because of some religious developer fervor.

So Adobe can scream and yell at Apple all they want about openness and freedom.  They have the backing now of a much stronger, much better positioned ally that could turn on them at any minute.  One move for Adobe could be to find a way to exclusively integrate their products with iTMS.  Such a move would at least leverage them against any passive Google aggression.  But ultimately they are but a proxy in the coming Apple/Google apocalypse.  To me, it’s more curious that Apple has decided to bring this battle to such an intermediary first, rather than to try to stunt the emergent competition in Google head on.  It could well be that the cost of such a direct war would be so great to Apple that they’d rather not play offense but instead focus on defense – ensuring exclusivity of content delivery on Apple platforms.  It could also well be that we’ll be watching TV on our Android devices in 2015 and forwarding through the “I’m an Android.  I’m an iPhone.” commercials.  Only John Hodgman will be wearing the Steve Jobs mock turtleneck.

Among the various extra-curriculars that take up my downtime, baseball is up there.  Baseball was a passion for much of my youth.  As I got older and my attention turned towards my career and the world at large, the dawn of Michael Lewis’ “Moneyball” changed my view on baseball entirely.  Baseball became, for better or for worse – less interesting to watch for 180 days a year and more intriguing to capture in the snapshots of statistics and numbers that engulfed baseball in the early 2000′s.  Lewis was demonstrating not a new approach to how baseball was played, but how Oakland A’s manager Billy Beane was simply exploiting an efficiency that none of his contemporaries had (yet) uncovered.

So recently I found myself thinking about the role of the manager in baseball.  As other teams began looking at the Oakland model for constructing successful, cost-conscious rosters, many copied their formula.  Others began to look for other efficiencies.  But the manager role – the ultimate “chicken” contrasted to the players as pigs, has only had cursory evaluation for their affect on the outcome of the game.  These evaluations are subjective by and large, and have all concluded in one way or form that managers tend to have zero net effect on the success or failure of a team.  But baseball managers are perhaps one of the most agile practitioners today.  They must be responsive, they must have enough foresight to plan only enough in that they can mitigate risk, but not so much as to commit themselves to a shortsighted approach.  Their sprints are innings, their releases are games.  They create ample time to adjust and re-plan.  They are agile creatures – perhaps the original agile management style.

(more…)

I tried Google Buzz this morning. My general impression when it was first announced was like many others: I don’t need another outlet for random thoughts.  I don’t need yet another source for random socialization.  I use Twitter.  I use Facebook.

So when I posted an innocuous message questioning the value of the tool I had just used, I got an immediate response.  To me, this is the type of gratification that people get (or used to get) from setting their Facebook status.  Or Tweeting.  Social media, from the consumer’s perspective – is virtual screaming.  Just without the caps lock key.  It’s everyone’s way of saying look over here, it’s me, I like politics and I love books and I have a cold and does anyone want to grab a drink tonight? What Facebook realizes increasingly (and Twitter, always resistant to changing their innate simplicity, has gave a moment’s thought to) is that eventually you have so many contacts, so many friends, so many followers, so many people who follow you that the signal to noise becomes unbearable without some sort of filter.  All of the conversations, statuses, likes, fandoms, retweets, hashtags, and groups eventually just become an incessant buzz, and we stop paying attention to a lot of it.

The immediate response was a result of having all of 14 people paying attention.  Compare that to the 150 people I’m connected to on Facebook.  Or the paltry 80 or so followers I have on Twitter.  My satisfaction with the experience with Google Buzz at that moment was purely a result of it’s infancy. But the buzz grew immediately louder.  I then noticed that the buzz had gotten into my GMail inbox.  To a guy who likes the mantra of Inbox: 0, this was distressing.  Part of the deal with Twitter which elevates it appeal over Facebook is that it is a pretty passive social media.  Direct messages infect your inbox, but those are fairly rare.  Simple replies to your tweets or even mentions can just fade to noise.  But now that there was a level of replication between ubiquitous social exchange and my more formal communication in email – Buzz had taken the most invasive and distracting part about Facebook and actively decided to emulate it.

At least Google Wave, while useless for my everyday interactions (though potentially useful elsewhere) lived out on an island that I could blissfully ignore.

I think that Wave, Buzz, and GMail eventually need to work out whether or not they’re the same thing or different things.  Facebook is looking to build a “GMail Killer,” and so it seems there is some idea out there that people don’t like email and would rather live in a world where the overwhelming noise of social media permeates everything.  It’s clear that for Google, taking email and putting eyes on the inbox with greater frequency will lead to more exposure to advertisers and inherently, more ad revenue.  But Facebook has ALWAYS had this model and hasn’t been able to consistently demonstrate that users will give advertisers the chance through all of the other noise.

It’s tempting to say that people will ultimately reject this model and the invisible hand of the market will demonstrate that when the inbox becomes too busy, people will just tune it out.  Google has provided options for getting Buzz out of your inbox.  But given the potential upside, particularly in Google’s business model, I’m also unconvinced they won’t try to force this particular feature right down their user’s throats.

Sigh. For reasons that may or may not be sensible, equals() and hashCode() are finalized in GWT’s JavaScriptObject.

(more…)

I have to get around to shipping this one to the GWT committers, but this one bit me hard.

(more…)

It has come to pass that in my travels, I have been introduced to or worked with people with certain grudges in the technology realm.  Myself included, it is pretty simple to run into a problem in an experience that sours you on a particular tool.  Hell, my father-in-law held a pretty decent grudge against Honda automobiles until the early 90′s.  The reason’s for his slight towards the maker of the Accord was a bit different from the people I come across who hold technologies in low regard – the people who roll their eyes at Java, the religious fanatics who loathe all things Microsoft, the experienced programmers who will never touch Perl.  We tend to be shaped more by our poor experiences than our positive ones.  The technologist “grudge” is the burden some people carry with them for a lifetime after a poor experience, and while it’s understandable and to an extend prudent to adopt a once bitten, twice shy perspective, it is more valuable to take that experience and either improve the subject technology (particularly in the instances of community software) or evaluate alternatives that exist.

But some of the weary techies I’ve worked with (particularly middle-management types, for some reason) go off the deep end.  I like to say that when you encounter a technical challenge – there’s likely someone else who has also needed to solve a similar problem.  In the instances where that isn’t the case – you’re in a pretty good position to gain something from solving it yourself.  But truth be told, there are very few large problems out there that people aren’t solving.  And yet IT organizations continue to re-invent the wheel – even when economics and time tell them that they should look for an off-the-shelf solution.  This only leaves one real driver for making the build decision when the buy decision is so apparent: politics.  And often it’s the politics of the grudge.

I firmly believe that every shop I’ve walked into that has rolled their own MVC framework, or RIA framework, or rules framework contains an individual who truly believes that the cost of supporting, maintaining, and continuously developing that software is still less than the cost of taking a turnkey solution – either one that is commercial or open source.  I recently had a manager tell me that there was an increasing drive through the IT management structure that the enterprise should own the source and rights to all of the systems that it supports.  This was a crazy notion – are their boundaries to this doctrine?  Will we be writing our own application servers?  RDBMS?  Messaging systems?  Where does this cult draw the line?  And with a little more digging, and without much surprise – I found that this manager had spearheaded a campaign to adopt a particular Javascript framework for client development that ultimately failed and cost the company several millions of dollars.  His dogma seemed crazy, and it was. But it was completely motivated out of fear that technology selection, no matter where the accountability lay – was an avoidable cost of enterprise IT, even if it meant adopting the more extensive cost of building all solutions from the ground up whenever the need arose.

I guess the moral of the story is really that as an IT manager, it’s important to recognize the power of the crowd (the community if you will) and the value it can add at virtually no cost to your organization.  That it’s important to understand why a 3rd party tool has been selected.  That it’s general limitations are known early on.  That your organization is prepared to adopt the tool as if it were it’s very own.  This means hiring experts who have used those technologies.  And above and beyond anything else, that when you fail – the goal must be to marginalize the cost of that failure.  You can hedge your bets, you can reduce risk.  But when the dust settles and a selected technology has failed the organization – be sure to take a good hard look in the mirror and be open about where the selection process has failed.

Sometimes it is the captain, and not the ship.

Okay, so maybe it’s always been this way and I’ve just not been paying attention – but it appears that GWT 2.0 now requires one to make RPC objects that will go across the wire explicitly implement java.io.Serializable.

A bland RPC implementation that was based on past work I’ve done was barfing all over me at GWT compile-time today:

Rebinding com.ryannorris.staffing.client.project.ProjectCreatorService

Invoking com.google.gwt.dev.javac.StandardGeneratorContext@9b32fe

Generating client proxy for remote service interface 'com.ryannorris.staffing.client.project.ProjectCreatorService'

[ERROR] com.ryannorris.staffing.client.Action<T> has no available instantiable subtypes. (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR]    subtype com.ryannorris.staffing.client.Action<T> is not instantiable

[ERROR]    subtype com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR] com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

I can’t say I ever had the pleasure of dealing with this bit of attention to detail from the GWT Compiler in the past.  And while I will readily admit I haven’t read every change to the underlying architecture that comes with 2.0, this would seem to be a piece that might be worthy of some special mention.

It is, of course, nearly common sense to make sure that your RPC objects can go across the wire in the proper way, and thus simply respecting the semantics of java.io.Serializable the same way we would in EJB per se, is pretty reasonable.  Just a little more heads up would have been nice.

Update 1: There seems to be some mention of fixing compiler feedback around RPC serialization here.  But this defect doesn’t suggest changes that might have actually altered behavior or requirements of the compiler since 1.7.

I’ve been writing a bit about Google Web Toolkit lately. It undeniably is disrupting traditional browser-based RIA development. But it does lack some features out of the box that most developers have grown accustomed to from frameworks like Flex and Ext. Field validation is one such feature. While the gwt-validation project exists to solve this very problem, an approach leveraging a good chunk of the existing GWT infrastructure can give you a robust, test-driven, and MVP-friendly approach for validation. (more…)

Javascript isn’t going away. But neither are 1′s and 0′s.  But one has to wonder what type of project or team that was looking to grow and build web-based, rich-client applications would actively choose to use Javascript on it’s own now.

For my part, there’s only so much patience I have taking on the burden of supporting multiple browsers and dealing with performance issues.  Particularly if I’m Agile, and I’m focusing on delivering so much value so quickly, it’s very hard to explain to a client that the underlying technology creates significant overhead that adds drag to the project.  This is an even tougher sell – particularly when you’re open with your client, when alternatives that meet the non-functional needs exist.

For your standard web applications that aren’t as client-centric as today’s RIA applications, it’s certainly true that you are barking up the wrong tree with GWT.  Rails, Grails, and Zend can all give you the non-enterprise delivery tools that accelerate development from the server-side and leave the Javascript problem to be solved in a less holistic, more tactical way.

But it’s hard to argue now that anything short of the compilation semantics of GWT is useful in the RIA realm (without the need for a intermediate runtime, of course.)  Javascript is too costly and too brittle in large-scale applications to be subject to human hands.  If you’ve hired a contractor to build you a web-based RIA and they’re not using GWT – it’s well worth your wallet to ask them why.