blog.mauricecodik.com

Dancing Gophers: Amazon Your Video Widget

2008-02-26T20:48:00.007-06:00

Fellow Amazonian Russell Dicker reposted his customer video review of the Caddyshack dancing gopher doll on his blog using the new Amazon associates Your Video Widget.

The Your Video widget lets Amazon affiliates annotate their videos with Amazon.com products and share them on their website. Check out this video for an example:

Since this widget is part of the Amazon associates platform, the creator of the video widget earns a referral fee for all Amazon purchases made by viewers that click through on the links in the video. This is true even for embeds of the video on other websites: Russell is going to make all the associates cash for purchases made from the video on this post.

I think this widget has great revenue potential for associates. If you create a popular viral video and publish it as a YVW, you can end up with thousands of your associates links all over the internet. It's ideal for publishing product review videos or for trying to monetize all of the funny videos you have laying around.

Disclosure: I'm an SDE on the team that developed the Your Video Widget. This is not an official Amazon message. All opinions expressed are my own and not of Amazon.

Actionscript 2 is terrible

2008-02-08T21:06:00.000-06:00

I've been doing a some flash development for work recently. It mostly involves adding features to an already existing flash project, which means its written in Actionscript 2.

I was really excited to learn AS2. Javascript is already one of my favorite languages, but it's sometimes a pain to deal with because of cross browser API and language differences. Since actionscript is an ecmascript dialect as well, I hoped that working with AS2 would be just like writing JS, but without the JS headache.

The reality was totally different: Flash 8/AS2 is the most painful to use development platform I've ever had to deal with. No joke. Here are some highlights:

1. In any sane dynamic language, what would you expect the output of this to be?


var x = undefined;
x.doIt();

I'd expect it to kick and scream. What does AS2 do? absolutely nothing. It just proceeds happily along as if nothing happened. You can imagine the silent failures and the hard to debug problems this can cause.

2. Speaking of debugging, if you were hoping to see a stacktrace anywhere, you can forget about it. This is also one of the most annoying things about working in javascript as well.

3. setTimeout is a pretty useful function. In fact, its so useful that it was added in the AS2 standard library. However, if you try to call it from an actionscript class, it'll fail to compile: it was just left out of the namespace! Thankfully, it's still callable if you tell the compiler to bugger off:

_global.setTimeout(function () { ... }, 300);

I'm amazed Macromedia's QA let this product launch with this bug. I'm even more amazed it was never fixed in any flash 8 player/compiler updates.

4. When the Flash CS3 compiler detects an error, it adds a line of text into a "compiler errors" window, which by itself isn't too bad. However, it still outputs a SWF and tries to execute it anyway. Not only does this slow down the development cycle, but it also squashes your perfectly good SWF from your previous compile.

5. AS2 doesn't include regular expressions in it's standard library. Awesome.

There's a lot more I could whine about: combo boxes that stop working once your SWF is dynamically loaded in another, buttons that stop responding to click events once you give focus to a text entry box, tedious manual merges of FLA files, strange delayed initialization issues, etc. Overall, it's really terrible. It's pretty clear to me that Macromedia didn't really care about flash as a development platform, and were happy with it just being used for animation.

Thankfully, AS3 seems to be much more pleasant to work with. I don't know if this due to Adobe's influence, or if Macromedia finally started to take flash as a dev platform seriously after flash 8. If you are starting a new flash project now, don't bother with AS2, just do it in AS3. Flash 9 already has 96%+ penetration in the US, the upgrade process is relatively painless for most flash 8 customers, and your developers will be much happier.

HAppS Experiences

2008-01-22T09:53:00.000-06:00

Last year I was working on a series on how to use HAppS, a haskell web applications framework, to build simple webapps. I was basing that series on my experiences developing the new version of the Openomy apis, which we finally launched a few weeks ago!

HAppS is a pretty nice framework.. even though its meant to be for generic web apps, I really think that building REST apis is its sweet spot: it's really good at generating xml out of your haskell types, and the HaXml xml parsing library is one of the nicest ones I've ever used (using combinators really beats hand rolling a SAX parser or hammering out an XSD).

Unfortunately, HAppS is moving very very quickly. The posts I wrote last March are almost completely obsolete now. We ended up having to rewrite a sizable chunk of the API service when we upgraded to the much nicer HAppS 0.9.1.

Ian wrote up some more details about our experience on the Openomy blog.

Building a Haskell Web Service, Part 2: The "Hello,World" Service

2007-03-27T21:59:00.001-05:00

This is the second post in a series about implementing the next major revision of the Openomy external API as a web service written in Haskell. Instead of focusing on the problems we faced getting started as I mentioned in the last post, I figured it would be more useful to show some code instead. I'll leave the rants for some other time ;)

HAppS is a web container in Haskell. Along with HTTP, it supports receiving emails via SMTP, has libraries to make DNS requests, has code to add ACID capabilities to your arbitrary in memory data structures, and apparently they are implementing integration with Amazon S3 and EC2: very awesome. At first glance it does seem to be a slightly bloated framework -- there is a Google Summer of Code project proposal out there to implement a more lightweight web framework -- but in practice all of that extra stuff doesn't really get in your way if you don't want to use it.

My only real beef with HAppS is that the documentation could use some major updating-- it seems that the API is changing so quickly that the HAppS tutorial isn't keeping up. Thankfully, the authors of the framework all hang out on #happs on irc.freenode.org and are really helpful. The tutorial does have some working examples and the general concepts are still accurate, but some of the code samples don't even compile. Here is the working the "Hello world" web service in HAppS, that I wrote when trying to learn the framework. From now on I'm going to assume basic knowledge of working in Haskell and that you're using HAppS 0.8.8.

HelloWorld.hs:

module Main where

import HAppS

-- define the data type you will be returning from your handlers.
-- for simplicity, we will just use a File, which is represented by
-- its filename and its id number.
data ServiceValue = File String Integer

-- a handler that just responds with a File named test.txt
getFile () () = respond $ File "test.txt" 1

-- since our web service will return XML, we need to tell HAppS
-- how to convert a ServiceValue to XML. This is done by creating
-- an instance of the ToElement typeclass. HAppS provides
-- a few XML primitives that makes generating XML pretty simple.
instance ToElement ServiceValue where
  toElement (File filename fileId) = listElem "file" [] [
                      textElem "id" [] (show fileId)
                  ,    textElem "name" [] filename
                  ]

-- we also dont want any stylesheets attached to our returned XML.
-- HAppS uses the ToMessage type class to convert values to
-- the actual message sent down the wire. this calls
-- the default toMessageM which knows how to use ToElement,
-- and adds other things such as the right content-type and
-- an XML prolog
instance ToMessage ServiceValue where
  toMessageM = toMessageM . XML NoStyle

-- glue it all together: make the getFile function listen to
-- the GETs to the /file url. noState tells the type system and
-- HAppS that this service is stateless.
main = stdHTTP [ h ["file"] GET $ ok getFile, noState ]

The comments should give a basic overview of how it works. To compile this with ghc, run:

ghc -package HAppS -o helloWorld HelloWorld.hs

Running it starts serving our simple requests from http://localhost:8000/file.

HAppS models the handling of web requests as a list of filters, which are passed into the stdHTTP function which implements the server's main event loop. The "h" function lets you bind a particular handler to a URL and HTTP method, in this case our simple getFile function. The rest is telling HAppS how to turn your internal values into XML, and generating these values based on the requests being received. The use of type classes makes the framework extremely flexible: returning other formats is just a matter of creating your own instances of ToMessage (HAppS also includes support for JSON out of the box).

In the next post of the series, I'll show how we're using HAppS' filters to validate incoming service calls and handle user authentication.

Building a Haskell Web Service

2007-03-26T10:58:00.000-05:00

This is the first post in a series about implementing the next major revision of the Openomy external API as a web service written in Haskell.

One of the cool things about having a website outside of your normal job is the ability to experiment with different technologies. We've done this pretty successfully with Openomy: it started out as a monolithic C# mod_mono + mysql application that stored files on the local disk and has now evolved into a much smaller mod_mono frontend, 4 services (3 in rails, 1 in java) and backed by Amazon S3 storage.

The next part of the original application we wanted to reimplement was the handlers for the Openomy API. The current implementation was inflexible, hard to extend, and was poorly suited to our new backend infrastructure.

We chose to implement the API bridge in Haskell for a few reasons:

You can model the external API as two functions: one that maps the client's input to the XML we send to our services, and another for our services return XML to our external output. This made us think that it may be fun to do it in a functional style.
We were worried about library support, but it turned out that Haskell had all of the libraries we needed: a web container, a powerful and flexible way to transform XML, an http client, and simple cryptography libraries.
After reading the paper on HaXml, I was really looking forward to using their combinator library to produce the XML mapping functions we needed. It seemed like a very powerful and flexible framework, without being as tedious and error-prone as working with other XML libraries in other languages.
Most importantly, it would be the most interesting: I've been wanting to learn Haskell for some time now.

However, there were also a few arguments against picking Haskell:

It's one of those languages that will stretch your mind, especially if you're coming from a mostly object-oriented programming background. Picking it for a major project is a large risk and may delay getting the new service out the door.
Haskell is mostly a research language: the community isn't very large and we didn't know any people that had successfully used it for a mainstream application.
The API bridge is heavily IO dependent (making service calls over HTTP). Haskell's monadic IO system takes a little time to get used to and understand.

About a month ago, I bought a copy of the Haskell School of Expression and started learning the language. Shortly afterwards, I convinced Ian to start learning it as well, and soon we had started. We were both a little nervous about it-- the day we started working on it, we observed that this may be the beginning of the worst software project in the years we've been working together. We've also been tracking how many times we've said "we're f*cked" during development. I'm sure we're well into the double digits by now :)

After a few initial bumps on the road, the project is moving along nicely now. The problems we had getting started will be the subject of the next post.

UPDATE: Part 2 has been posted.

Long time no see

2006-09-06T23:20:00.000-05:00

It's been a couple of months since I've last written, but I assure you there will be much more to read here soon. Some updates and short thoughts:

The Ruby Cookbook was just recently released. It's huge, and has a lot of useful recipies for all-around ruby hacking. I contributed an adaptation of this old blog post of mine as one of the recipies entitled "Enforcing Software Contracts" on page 367. Hope it helps you all add some metaprogramming sauce to your programs.

I recently moved out to Seattle, WA to take a job as a Software Development Engineer for Amazon.com as a member of the Community Content team. I'm really enjoying the switch so far, and I'm looking forward to becomming a regular to the seattle.rb events soon as I become more settled. An update to the "About Me" post is coming soon.

While signing in to write this blog post, I stumbled upon the new Blogger beta. It looks like blogger is finally catching up to the state of the art in blogging platforms. However, the beta still doesnt support publishing to other domains, which is a total dealbreaker for me for now. Hopefully that feature is coming back soon. On another note, the beta supports a new GData powered API.

That's it for now-- more coming soon.

Google Checkout will not kill Amazon

2006-06-29T17:45:00.000-05:00

The blogosphere is going nuts about Google Checkout today. The most controversial opinion comes from Rafe Needleman over at CNET, which calls Checkout an "Amazon Killer"

He couldn't be more wrong: People don't shop at Amazon just because you have your credit card information saved there-- almost all major e-commerce sites let you save your credit card info. People shop at Amazon because of low prices, huge selection, cheap/free shipping and great reliability. Google checkout provides none of this-- it is not a store, just a system to store credit card info. It is merely the Google version of Yahoo Wallet. Amazon and eBay have nothing to worry about. In fact, there's nothing stopping them from supporting Checkout themselves (aside from potential not-invented-here reasons).

Checkout is certainly significant, but not for the reasons Needleman mentions: The best part about Checkout comes by integrating it with Google advertisements. Forget cost-per-click, it's now cost-per-sale! This change makes click fraud is no longer something to worry about, which was one of the thorns in Google's side, at least in terms of Wall St perceptions of their business model.

I think Needleman's post is just another example of people gaming the blogosphere, as Richard MacManus ranted about the other day-- just write any "XYZ vs Google" post with an sensationalist headline and watch the hits roll in (this is the #3 post on techmeme right now). For this, Needleman gets a "nofollow" on my link-- this type of stuff shouldn't be encouraged.

google checkout amazon

RailsConf '06 Wrapup

2006-06-25T17:37:00.000-05:00

RailsConf 06 just finished a few hours ago, and overall it was a great conference. Here are the day by day highlights:

- Intro to Capistrano: This session had people sitting out the door trying to listen. I hadn't seen cap in action at all til the conference, and I was really really impressed. We're seriously considering switching to cap instead of our current NUnit-based deployment and build cycle for Openomy.

- Rails Optimization: This talk started out a little slow, but then was amazingly impressive. Stefan Kaes demonstrated how to optimize your Rails app- what types of things to avoid, etc. He developed a view compiler which does some automatic optimizations on you views (such as pre-computing url_for calls, inlining some helpers, etc) which cause almost a 5x performance increase on complex pages!

- Demos & Lightning talks: Lots of really cool stuff was shown off. I was really impressed with Tunecore, a service that allows artists to submit albums to a variety of music services. Rightcart was also a really cool way to embed a shopping cart to arbitrary webpages.

- Keynotes: All of them were fantastic. Martin Fowler was an excellent speaker, and Paul Graham presented a great essay as usual. I already blogged about DHH's great talk last night. Dave Thomas' opening keynote a Hilbert-style "3 big problems for Rails adoption," which was a good call to action to kick everything off. Interestingly enough, by the time the conference was over, a few people had announced solutions to a few of these.

- Metaprogramming: There were 4 pretty good talks on the use of DSLs, metaprogramming, and other advanced Ruby. The best was Scott Halloway's "MetaRails" talk, which explored how a few of the more interesting features of Rails are implemented (ex, class reloading).

Overall, the conference was phenomenal-- you can never beat the excitement and energy of a "first conference." RailsConf '07 will be co-sponsored by O'Reilly, so it promises to be a much bigger show. I'll definitely try to make it out to that.

Instant REST on Rails: ActiveResource

2006-06-24T22:55:00.000-05:00

DHH gave his keynote at RailsConf tonight, and it was totally awesome. It focused on the new CRUD features that will show up in Rails 1.2, and all of the niceness that comes out of them.

Taking a page from REST protocols such as Atompub and the related GData, Rails will support "resources." These resources are designed to support basic CRUD operations, which are driven by the full set of HTTP verbs: GET, POST, PUT, and DELETE. This, combined with the #respond_to and #to_xml methods already in Rails, as well as some enchancements to the Routes package, allow programmers to build very DRY RESTful websites and webservices.

The coolest part of the keynote was the Steve Jobs-esque announcement of the ActiveResource library, which DHH just started building a few days ago. This new library would abstract a REST webservice built following certain conventions, similar to how ActiveRecord currently abstracts a relational database. For example, you would write:

Person = ActiveResource::Struct.new do |p|
  p.uri "http://www.myhost.com/people"
  p.credentials :username => "maurice", :password => "pass"
end
person = Person.find(1)
person.name = "Maurice"
person.save!

Which would connect to the REST resource located at the give URI, and then use GET/POST/PUT/DELETE to interact with it-- essentially giving your REST webservice a free library that enables you to consume it. In this example, it would call "GET /people/1", turn the resulting XML into a struct. Then it would POST an updated copy of the struct to the service.

ActiveResource will make it almost trivial for Ruby programs to consume RESTful services and make it really easy to integrate multiple Rails applications, all while keeping a very simple API. Overall it looks great, and I'm really looking forward to be able to play with it.

Tags: railsconf activeresource REST

Windows Live integration is going to be HUGE

2006-06-22T19:36:00.000-05:00

An article on CNET the other day described Microsoft's announcement of an SDK that would allow deskop applications with Windows Live ID. Richard MacManus commented shortly afterwards about how big this for Microsoft:

This strategy will define Microsoft's future, because in many ways it's the bridge between the old world (desktop software and the Windows OS) and the new world in which Google is a pioneer (web apps)

I totally agree-- Microsoft is one of the few companies with the reach to be able to take the web application mainstream. Just the Live ID API has potential to be the ultimate single sign-on solution: imagine being signed on to all of the windows live services just by starting a user session in Windows. Users may never have to sign in more than once again, and Microsoft would have an instant audience for its Live services.

This has implications for the online storage space as well: MSFT could automatically give all its users a small Live Drive account, sign-on to it on start up, and integrate it with Windows Explorer. Depending on how well this is executed, it could totally change the game for the many online storage services out there (including Openomy).

It will also be interesting to see is how tight the integration will be: Microsoft has gotten into a lot of trouble before by integrating IE and Windows Media Player into the OS. Successfully integrating the desktop with Windows Live would make life a little more difficult for many web startups and reignite antitrust concerns. With all the changes going on at MSFT recently, I'm really looking forward to seeing how this one plays out.

Econ 201: Oligopolies suck

2006-06-20T18:48:00.000-05:00

Basic economic theory explains that oligopolies are inefficient, and should be avoided in favor of a free market with many many competitors. In college, we even mathematically "proved" it (with a few simplifying assumptions, of course)! Even if it is a fact, it's still great to see real-world examples that prove my old Econ 201 prof right.. there have been a few in the news recently: DRM and Net neutrality

What's missing in both cases is a good dose of competition. Unfortunately it's the innovator's dilemma again: their significant market power makes these companies lazy and gives them the ability to do as they please. Telcos can provide over-priced, slow service to users, and then can threaten to charge web companies for being able to interact with their customers. The entertainment industry can impose DRM'ed content on all of us, essentially taking full control over how content is used and distributed. Both of these issues would go away immediately if consumers had viable alternatives.

Where the heck are all the companies that are trying to disrupt the current state of these industries? I can think of many that have tried, but none that have made a lasting impact.

H1-Bs and startups

2006-06-09T14:14:00.000-05:00

This post on the Meebo blog the other day about their experience with H1-B visas caused quite a stir in the comments. This year the H1-B quota was all used up about 2 months, leaving a lot of companies and a lot of people in a pretty bad situation: now two of meebo's new team members cant work in the US for another year and a half! Thats *aaages* in internet time. When this happens for a large corporation its already bad enough, but for a company the size of meebo, those two new employees represent like 20% of their workforce!

When the topic of immigration policy comes up, there's always a pretty fiery debate. The comments were full of stories about abuse of H1-B workers and the standard protectionist economics arguments in favor of the quota. While the protectionist argument does make a lot of political sense-- the people that benefit directly from it are the ones with the larger voting power-- economically it's probably the wrong solution.

If you want to make sure that Americans get the best jobs, then focus on making Americans the most qualified for that job and optionally provide businesses with an incentive to hire them. Depending solely on articifial barriers, such as an immigration quota, only avoids solving the true problem and creates the wrong incentives. For example: the most common suggestion given in the comments was to open a meebo office in another country. The current quota program encourages companies to send jobs offshore, where the workers wont be paying US taxes or contributing to the US GDP.

The truth is that the kind of people Meebo is looking for really are in short supply: not any schlub that knows some javascript is going to cut it. They want the smartest and the most innovative people they can get-- if the first ones they find happen to be born outside of the US, then so be it. It is more costly for the economy for companies like meebo to either have to lower their hiring standards or to wait for a local hire to appear, than it is to bring someone in from another country. (While it may only take an extra month to find a local hire, by that time meebo could've pushed out two new releases of features to their servers!) These startups and technology companies are keeping the US on the cutting edge of technology, and it is in the country's best interest to make sure they have the workforce they need to keep it that way.

I'm not advocating totally removing the quota either... there were many examples in that thread of comments that describe why this is undesireable. A better system must exist between these two extremes. Hopefully, now that immigration reform has become a mainstream political issue, there will be some dialog that results in a better system for both businesses and Americans.

Disclaimer: I'm on an H1-B visa in the USA, and I'm really grateful for the opportunity to be here. However, this may cause me to be a bit biased on this issue ;)

The State Pattern, Ruby-style

2006-06-09T11:31:00.000-05:00

One of the cool things about using a language that allows for metaprogramming is that you can reduce the amount of boilerplate code you have to write. Common patterns can be put into libraries, and give you a small DSL that you can use to replicate this pattern all over your code. A good example of a common pattern with lots of boilerplate is the state pattern: where the behavior of an object changes depending on the internal state of the object. This can be accomplished by using a simple 'if' statement, or by modeling a finite state machine.

Check out a sample implementation on the RubyGarden wiki. We have a class for each state, a common parent class for the states, and a context class that delegates to the current active state class. That's a lot of code that doesnt really do much. Enter the StatePattern module, which puts all of this boilerplate in a small mix-in module, and ties everything together with some metaprogramming glue. Now we can write:


class Connection
  include StatePattern
  state :initial do
    def connect
      puts "connected"
      transition_to :connected, "hello from initial state"
    end
    def disconnect
      puts "not connected yet"
    end
  end
  state :connected do
    def initialize(msg)
      puts "initialize got msg: #{msg}"
    end
    def connect
      puts "already connected"
    end
    def disconnect
      puts "disconnecting"
      transition_to :initial
    end
  end
  def reset
    puts "reseting outside a state"
    transition_to :initial
  end
end

c = Connection.new
c.disconnect # not connected yet
c.connect    # connected
             # initialize got msg: hello from initial state
c.connect    # already connected
c.disconnect # disconnecting
c.connect    # connected
             # initialize got msg: hello from initial state
c.reset      # reseting outside a state
c.disconnect # not connected yet

.. and the boilerplate is all gone. How's it all work? Each call to state defines a new subclass of Connection that is stored in a hash. Then, a call to transition_to instantiates one of these subclasses and sets it to the be the active state. Method calls to Connection are delegated to the active state object via method_missing. This was a tricky one to get right! Download the source from here.

Domain Specific Languages and their Limitations

2006-05-10T00:27:00.000-05:00

It seems that a lot of people are raving about the use of domain specific languages in Ruby these days-- where clever uses of eval, load, etc make normal Ruby code look like the language of the problem domain. Rails has a few good examples of this, such as ActiveRecord, which can be considered to be a DSL for describing data models.

It's really great to see these ideas becoming more mainstream.. However, I'm concerned that it's an idea that can be taken too far. Here's an example from Jay Fields:

if the '$5-$10 Limit' list is more than 12 then notify the floor to open

A business user can read this and think: This looks like English, I can speak English so therefore I can edit this with out a problem. Let me specify that this can only happen after 5pm:

if the '$5-$10 Limit' list is more than 12 and it is later than 5pm
then notify the floor to open

What happens then? most likely, the program will break with a strange error about "it" being undefined. The key issue is that we are only simulating English: in reality it is still Ruby, which has a strict syntax and requires methods to be defined before they are used. From an HCI perspective, allowing users to pretend to write English code gives them an illusion of freedom-- which can cause significant frustration if the expectation of freedom is not met. The only way I can see around this is to make sure that the users of the DSL understand the basics of programming languages and are trained to understand the limitations of their particular DSL. I'd be interested to hear about how Jay and his team are dealing with these issues.

In the long run, I don't think the main value from DSLs will come from allowing non-techincal users to encode business rules, but instead in helping programmers make their programs more DRY. The best examples of DSLs from the Ruby world, such as ActiveRecord, Rake and Capistrano all fall into this category.

That's not a bug, it's a feature!

2006-05-06T11:35:00.000-05:00

I spent about an hour trying to fix a bug in a javascript calendar I was working on... see if you can spot it:

I had dates in MM-YYYY format, that I was trying to parse the month out of. My code (simplified):


function parseMonth(mmyyyy) {
  var splitMMYYYY = split('-', mmyyyy);
  return parseInt(splitMMYYYY[0]);
}

Now the bug: month was being set to 0 for dates in August and September, both in IE and Firefox. See if you can figure out why.. here's the answer.

If thats not a bad default, I dont know what is.

More on walled gardens and protocols

2006-04-21T18:10:00.000-05:00

Richard MacManus linked to my previous post on GData. One particular sentence right at the end caught my attention:

I'm not sure if this points to less of a walled garden, or paradoxically more of one because Google is defining the protocol now.

This is misleading: Yes, GData is a new protocol in some sense, but its really just sending plain XML over plain HTTP. No wacky binary transmissions that need to be reverse engineered, nothing truly proprietary. It's certainly not an old-Microsoft-style "embrace and extend" trick-- It's based on open standards and the provided libraries are open source (Apache licensed).

I think that "protocol" has become a slightly loaded term. It's really just a convention used to communicate between two endpoints. So by this definition, any API (even the Openomy API I work on) can be considered a protocol. I think the past has left negative associations with the word protocol-- hearing a company say they are creating a new protocol just naturally raises red flags of vendor lock-in and closed tools.

I'm still optimistic about GData-- I'm sure there's nothing like that to worry about here.

GData: The end of Google's walled garden

2006-04-21T09:50:00.000-05:00

Google's recent release of the GData protocol has caused some confusion.

It's a matter of interpreting it correctly: GData is not a stand-alone application, it's just a protocol. It is a general framework for posting/editing/deleting XML data to already existing feed.

For example, check out the Google Calendar API. Here it is, in a nutshell: Google has an XML schema that lets you describe events on your calendar. Adding/editing/removing events on your Google calendar is just a matter of using the GData protocol to put/update/delete the XML representation of an event to a feed provided by Google Calendar. GData just handles all the infrastructure stuff, such as authentication, versioning, etc.

Other objects in Google-land have their own XML schema (Google calls these kinds). For example, the Message kind can be used to represent an email, a blog entry, a comment on a blog post, and a posting on a newsgroup. The Contact kind can represent a person, a location, or venue. Using the GData protocol, Google can create APIs that let you interact with each of these kinds.

Now, what does this all mean? In the past, Google has taken a lot of flak for being a walled garden: the data that users put on a Google app, is only accessible thourgh that application (Google Base is the most famous example of this). GData changes the situation completely: it provides a framework for Google to easily and consistently create APIs for all of their applications.

Put simply, GData means that the walled garden of Google's applications is coming to an end. I'm really excited to see what will come out of this.

Hash Auto-vivification

2006-04-18T22:42:00.000-05:00

One of the more convenient (but sometimes bug-creating) features in Perl is autovivification: a variable is created just by referring to it (or, comes to life on its own). This is useful for creating composite data structures out of hashes or arrays-- for example, writing '$a{"a"}{"b"} = 3;' creates a hash of hashes called %a for you automatically.

Ruby doesn't have this "feature" by default, but like many other things in Ruby, you can work around it. Here's one neat way to autovivify hash-of-hashes, using recursion and Hash default procs (posted by Bill Kelly on ruby-talk):


HashFactory = lambda { Hash.new {|h,k| h[k] = HashFactory.call} }

irb(main):181:0> x = HashFactory.call
=> {}
irb(main):182:0> x['abc']['def']['ghi'] = 123
=> 123
irb(main):183:0> x
=> {"abc"=>{"def"=>{"ghi"=>123}}}

Awesome...

Unfair competitive advantages don't exist on the web

2006-04-17T20:52:00.000-05:00

UPDATE: Here's another good post on this same topic over at
EarlyStageVC

When Ian and I presented about Openomy at the Techdirt Greenhouse this past March, we spoke right after Andy Kessler, an author and successful investor. He was a pretty tough act to follow-- he was a really good speaker and had some pretty interesting things to say. When discussing his invesment philosophy during his talk, he mentioned that when he is evaluating a potential investment in a business, he looks for what he calls an "unfair competitive advantage."

Yes, having an unfair advantage would be excellent, and from an investment point of view, I agree it would be ideal. However, I think its a totally unrealistic expectation, especially when it comes to investments in web applications. The vast majority websites out there are just a product of good ideas, programmer-hours, and good execution. None of these things are a source of a sustainable advantage: any innovative website will spawn many many copy-cats, some of which will be run by people just as talented and motivated as the creators of the original site. This is completely unavoidable. If you honestly believe that no other company can copy or improve on your creation, you are kidding yourself.

Coincidentally enough, the folks at Techdirt did a pretty good job at explaining why insisting on an unfair advantage is silly in a post this past weekend about patents:

[...] in a competitive market there is no such thing as a sustainable competitive advantage. It's a myth -- and a somewhat dangerous one for those who believe in it. Instead, the way to succeed isn't through sustainable competitive advantage, but through continuous innovation -- that is, through a series of fleeting competitive advantages. You don't need patents for that -- just a smart, motivated team and a market to serve.

So what does this mean for people building web applications? Should you be worried that you don't have an "unfair" competitive advantage? I really agree with Mike here: as long as you have a smart, passionate team that is capable of moving quickly enough, I think you will have a fighting chance at success.

"Whats the next big thing in Information Technology?"

2006-04-11T22:14:00.000-05:00

One of the cool things about travelling a lot is all of the people you meet. A few weeks ago, I was at the airport waiting for my flight home and I decided to try out this new restaurant that opened up in the terminal. There was a sizable line outside of this place. The restaurant didnt want to seat a small group to a larger table, so they started combining multiple groups into one table.

A co-worker and I sat with an older gentleman on his way to visit his daughter in Florida. We started chatting, and after a while he asked us: "So, what's the next big thing in information technology?"

You would think that an IT consultant would have a semi-intelligent answer to this question, but I totally blanked: there's so much cool stuff happening that I didn't know where to begin. After a few seconds of thought, here's what I came up with: "Not too much is really brand new. Most of the cool things happening now are a result of people using existing technologies in new ways." He seemed very underwhelmed by this answer, and for good reason I think: Instead of hearing about whiz-bang cool stuff, he got an answer that seemed to imply that there was nothing worth getting excited about (which is really very far from the truth).

What would you have answered? How have you tried to explain what's going on in the world of web applications to a non-technical person?

The Great Ruby Rewrite

2006-04-11T21:08:00.000-05:00

Its been a while since I've really liked something Joel Spolsky has written.. here's a gem from his latest entry, the Development Abstraction Layer:

These companies are harder to find because in most circumstances they keep quietly to themselves, polishing code in a garret somewhere, which nobody ever finds, and so they fade quietly into oblivion right after the Great Ruby Rewrite, their earth-changing refactoring-code code somehow unappreciated by The People.

The funniest part about this is that I constantly pester Ian with the same suggestion: We should rewrite Openomy using Ruby on Rails. Of course I'm not serious, but it the mere suggestion annoys him like no other.

I really think Rails is great, and any new web application I write will most likely be written in it. However, is the small productivity boost really worth the 4-6 months of no development on the current live site? I don't think so..

Take Kiko for example. They launched a pretty cool web-based calendar application last September. At that time, there weren't too many of these around (the techcrunch post on their launch only mentions one real competitor). A few months after their launch they decided that the site should be totally rewritten in Rails. They thought it would only take a month -- it really took them 6!

Here's what happened in the mean time: 30boxes launched, Zimbra launched, and many others did too. They went from being one of the only ajax online calendars out there to being just one player in a crowded market. Would they have been better served by just gradually refactoring the current codebase as they add new features? Probably.

Taazza - Indian news, Web 2.0 style

2006-02-20T21:23:00.000-06:00

My good friend (and my career manager @ Sapient) Arjun Ramarathnam is working on a really cool side project: taazza.com, a news site geared towards the Indian subcontinent (Taazza means 'fresh' in Hindi).

I'm really impressed with what I've seen so far, especially since it comes from a guy that claims that he can't code! ;) . Just check out the screenshots on the landing page now: he uses Google Maps to let people read stories by regions, gives quick access to related content, lets you read both the blogosphere's and more traditional news coverage, and its all written in Ruby on Rails.

Now compare these slick features to the current largest Indian news website, Samachar. Taazza is just going to blow these guys out of the water-- its a good example of the cool stuff you can do by mashing up freely available sources of data.

Sign up on the main page for email updates, or just subscribe to the Taazza blog.

UPDATE: Arjun demo'ed Taazza at BarCamp Chennai and got rave reviews.. I keep hassling him to launch this thing already! :)

What's with all the Firefox hating?

2006-02-15T19:54:00.000-06:00

The blogosphere has been picking on Firefox a lot recently: They claim it's slow, it's a memory hog, it crashes all the time. I find that really odd-- I've never had a problem with Firefox 1.5 on Windows. I've had a few issues with the older version available on Ubuntu Breezy (1.0.7), but very few that I couldn't blame on plugins. Even if it did hog my memory and crash regularly, I would *still* use it: It's so much more badass that IE. (I've been told that badass is my favorite word)

Regardless of what you think of Firefox, this little splurt of posts complaining about Firefox are a symptom of more general problem in many internet communities: The transaction cost on ideas is very low-- especially in the blogosphere. All it takes is for one popular blogger to complain about a well-known and well-liked product and the rants spread fairly quickly. Unless, of course, you're totally wrong. In which case you probably wont be a popular blogger for much longer.

I really make an effort to not fall into the blogosphere groupthink. I rarely link to anything without adding any value, as us consultants like to say. If you see me fall into that trap, please yell at me.

How to be a Mensch

2006-02-11T23:43:00.000-06:00

If you haven't discovered Guy Kawasaki's blog yet, add it to your news reader right now-- it's consistently pretty good. His latest post is on How to be a Mensch. He has pretty good advice on how to be a well-respected, noble person. Its certainly something I try to be.

When I was in college, I was president of UChicago's AEPi chapter for a year. As a mostly Jewish group, we were all well aware of what being a mensch means. When we were considering someone for membership, we would always used to ask ourselves: "Is this guy a mensch?" -- If so, these were the guys we pursued the most aggressively. Like in most recruitment situations, having great guys attracts more great guys, and makes for an all-around better chapter.

"Menschdom" is not just something we can aspire to as people, but as a company as well (in a sense). We try to do this with Openomy. So in Guy Kawasaki style, here's a list of ways you can make your organization be more mensch-like:

Be approachable: Your users *need* to trust you. I think its the little things that count the most here-- For example, we don't have any generic corporate email addresses may or may not have a person attached to them. If you have an Openomy question, we want you to email us directly.
Tell it to 'em straight: This one is related to the previous point. One of the coolest emails we've ever received was a person complementing our privacy policy and our terms of use. They are written in plain English, no legalese, and they both explain things clearly.
Be Fair: On our FAQ, we say: "Currently, all storage is 1gb. The plan is to increase this in the future. Let us know what you think is fair." (emphasis added). If you think our service is a rip off, we want to know about it. Everyone deserves to get their money's worth.
Set the right kind of goals:Companies are supposed to be profit maximizing. While that may be true in general, I want my company to be "fun maximizing." We're here to build something cool, that we enjoy building, and that our users enjoy using. If your product is cool (and evangelizable as Guy would say), then the profits just take care of themselves. We take this approach to an extreme on Openomy: we have a list of projects that we eventually want to implement on the site. Instead of doing them in order we think of them, they are prioritized by how cool they are. While it does mean that a few features spend much more time on the list than others, it lets us whip out some coolness pretty regularly.

To elaborate on this last point: Of all of the blogs that have written about us, the post I'm the most proud of is not from a big name blog. Instead, its a post from back in November on a blog called Tempus Fugate, that said:

They don't appear to have much of a business model, just a keen sense of "do-it-right"-edness. That's a technical term.

The coolest fact about Openomy is that it appears to be running solely out of a desire to build something useful, learn some lessons, and potential help some people. This may not sound ordinary, but in the universe of online ventures, it can be anything but normal. I recommend you check them out. It's worth making note of their upbeat and positive attitudes and attention to detail.

This blogger gets what being a mensch company means. Thanks for the kind words. (PS: The "business model" aspect is coming. While we value fun more than profits, the reality is that we can't pay for this out of pocket forever. The delay is related to the last bulletpoint: adding credit card processing isn't really that fun :))

When Ian and I were coming up with names for our Openomy servers, we symbolically named one our most important servers 'mensch.openomy.com'. Actually, all of our servers are named after Yiddish words-- can you guess the names of the rest?

Using Darcs

2006-01-28T14:45:00.000-06:00

The caboose blog has a good intro to using darcs for version control.

I was first exposed to darcs when I heard a cool talk by David Roundy, the author of darcs at ICFP 05 last September (darcs is probably the most popular Haskell software out there, aside from the Haskell compilers). The talk brought up other distributed SCMs, such as the subversion-based SVK.

Ian and I started out using subversion for Openomy but kept having trouble with branching: the process of looking through commit logs to find the right revision numbers to merge was really annoying, and we screwed it up more than once. It got to the point where merging branches actually made us nervous!

We decided to try something new and give darcs a shot-- we haven't looked back since. We don't use it in a purely decentralized manner: Ian and I each have our own repositories, but we keep centralized production and development repositories on our servers that we push to whenever we're done with new functionality. The merging headache we faced with subversion is totally gone, and we can pick individual patches to promote to production and hold others back in dev. It's a really great SCM and I encourage other developers to give it a try. Here's a link to the darcs manual to get you started.