Mini Chrome Game

When the power goes out, there is this fun game hidden in Chrome. Watch out for the the pterodactyls.

H1B Visas and Indentured Servitude

Update: There is a ton of nuance this post has brought to my attention. Yes, you can transfer your application to your new employer, see this quote:

Generally, if your I-485 application has been pending for 180 days or more, you are eligible to change jobs and continue your green card application.

Search Google for A21 or read some Quora.

The last thing I want to do is mention politics here, but talking to friends over the weekend and reading the news today, I’m pretty convinced that the only people benefiting from the H1B are the employers (or owners). The effect on workers is a reduction in salary as the number of H1B visas go up.

This isn’t about immigration or saving US jobs or preventing offshoring, it is simple economics. The system is rigged to screw everyone involved except owners. Breaking it down:

  1. H1B workers have limited mobility (yes, there is the H1B transfer, but you have to start over on your green card application).
  2. Unwillingness to restart the green card application limits mobility.
  3. Limited mobility paves the way for abuse – lower salaries, no raises, fewer benefits.
  4. The H1B holder is thus more appealing than the American, thus lowering her salary.

We should be letting more foreigners into the country, so how do you do that?

  1. Allow H1B holders to transfer the green card application to the new employer.
  2. A possible minimum salary threshold, but this is a slippery slope.

The other suggestion is to set a minimum salary threshold (75th percentile), this means you have to pay big bucks for the H1B so you must really need that person. Yes, this will probably do away with the bullshit hoops companies have to jump through – advertise the opening, prove there is no qualified US citizen, etc. – but still erects an artificial barrier. We would miss a newly graduate Einstein.

Really, in the end I believe in less border, more meritocracy.

Bring RSS Back

The Death of Google Reader really meant the death of RSS. The technologies that moved to Google to die – feedburner, pubsubhubbub, blogger, etc. – also diminished the mindshare of RSS. Interestingly, Google was constantly trying to divert resources from these technologies to build their various attempts at social networks. But basically, Reader died so that Google+ could be born. Also, the technologies Google seemed to be trying to distance itself from could be chained together to give the world a truly open social network in the form of OpenSocial or Diaspora and let the users retain control over the content they produced and consumed. It seemed as if Google realized the world actually wants to live in a Bubble, Facebook was moving quickly in that direction, so they followed as quickly as possible.

At, or before, this time, Chris Cox and Paul Buchheit saw this bubble trend and left Google to found FriendFeed which was a hybrid of a totally open social network and a curated news feed. This worked pretty well so Facebook bought it and killed it, integrating a brain-dead version of the feed into their own product.

With Google Reader gone, there was a big hole in the RSS market that was slowly filled by three different types of readers. First, you had the Google Reader knock-offs which are now dominated by Feedly. Second, you had the next-generation readers like Flipboard which presented their content in a magazine format and was highly curated. Third, you had Twitter and Facebook Bubbles injecting news into your social feeds based on your previous interactions. The main difference between the three are the level of curation: Feedly – you curate everything; Flipboard – you curate some things (categories to follow); Facebook/Twitter – you curate nothing (Twitter gives you the appearance of curation, but sponsored tweets ruins this).

Looking back at the demise of RSS and the growth of the Bubble, it seems like an utterly obvious de-evolution of technology. How complicit were these companies in destroying self-curated news feeds?

The point of this post is to puzzle out a few questions:

  1. Why didn’t RSS go mainstream? (Google Reader folded)
  2. Why do people believe Facebook and Twitter are news sources? (They know no better way)
  3. If Facebook is turning into a news stream, why should I stay? (I probably should not)

How can we get people to think for themselves? How can we get people interested in curating on their own?

I’m beginning to think this is no longer possible.

Swagger for Spring


More specifically, Spring Boot. Swagger is meant to describe your APIs in a quasi-HATEOAS way, but you must provide Swagger definitions and run code generators to output your documentation. What if all the definitions were in Java annotations and code generation never has to happen? And the Slate UI picks up all your changes in real time and generates sample code in multiple languages and provides a real-time console to experiment with each endpoint?

This is what I did with these projects.

I’m using the Swagger-springmvc (now springfox) project as a basis for better documentation generation through annotations. All the work I did on this has been committed to my fork at and my Swagger Core fork at

I’ve also ported Slate UI to auto-ingest Swagger-based JSON endpoints as described above, but this is not yet in github. Will set up a new repo as the fork is drastically different (php vs. ruby, etc).

PHP Slate is now on GitHub.


A lot of people think there is a hard and fast rule that POST is to create and PUT is to update. This is not entirely true as they can be used interchangeably. The key difference between these verbs is their idempotence as described in RFC 2616. The idea of idempotence is also reflected in the target of these verbs, for example:

  • POST generally goes to a generic address such as /articles/ and a new article is spawned, for example /articles/42.
  • PUT goes to a specific address such as /articles/12 and updates that resource.

To sum it up, PUT can be run once or a thousand times and the end result will be the same. POST on the other hand always has side effects and this is the main difference between the two.