I just released AnsiColor 0.2.0 that now supports the ANSI conceal code. Conceal code 0x8 is a hacky way to hide data inside text using ANSI sequences. Jenkins uses it to annotate output with something that looks like ha:<long base64 string>. You can see this implemented in ConsoleNote.java. The previous version of AnsiColor produced garbage by stripping the conceal sequence, therefore revealing the content inside the conceal block (issue #3). Fixed in this commit. Also updated Jansi to 1.7 – Jansi makes this plugin possible.

Update your Jenkins.

I’ve written about delay-processing certain image versions in this article. We’ve made some progress since with a much more robust implementation. Check out this new post on the Art.sy Engineering blog.

We use the Analytical gem to include various thirdparty Javascripts in our Rails application. Our test environment was configured with dummy values in config/analytical.yml.

We wrote a few simple tests to make sure the analytical code is being included properly. For example, we can check whether Google Analytics is included on the splash page.

Or, more complicated, test whether a user ID is sent to Kissmetrics.

The drawback of this approach is that the Analytical code is included with every other test that doesn’t need it. With every Capybara test that runs in a browser, this hits DNS, then makes an HTTP request to Google and Kissmetrics. We cannot stub that with VCR or another gem because we’re using a real browser. But we can selectively enable Analytics without a configuration file by emptying the :test block in config/analytical.yml by configuring it before any test that needs it.

It helps to be open-source. Looking at the internals of Analytical, its options are processed inside each controller on load, then merged with request options on every request before anything is rendered. The code above updates the configuration between those two steps. Note that since we’re modifying a static we have to make sure to cleanup after ourselves.

tl;dr – the source is here

Here’s how I mount a Grape API on Rack and also serve static pages. Most useful for building a service with documentation.

Setup bundler with the required gems. I am using the next version of Grape (frontier branch and the next version of rack-contrib which contains Rack::TryStatic that we’re going to want to use).

Static content goes to a new public folder, for example public/index.html.

Our application will need to boot with all these gems, we’ll do it Rails-style by starting with a config/boot.rb file. It brings in Bundler.

Lets define our Acme Grape API that will have a system resource that answers ping requests with “pong”. This goes into api/api.rb.

The application requires Bundler, all the gems in Gemfile and our API. Lets define it in config/application.rb.

Note the odd File.expand_path construct, borrowed from Rails, - it translates a relative path to the current file into an absolute path, there’re allowing us to run the application from any directory – useful for hosting where you never know who boots the application.

Continuing to borrow from Rails, we will want different environments (development, production, etc.), so it’s a good idea to keep things organized. Setup the environment in config/environment.rb and then load the application.

Finally, we need to “rackup” this whole thing in config.ru. We will use Rack::TryStatic to serve static pages when available and pass through to the Acme API otherwise.

Run the application with bundle exec rackup.

Full source on Github.

I *heart* Github and its magical green merge button. The entire fork/pull/merge workflow has been singlehandedly responsible for a massive amount of open-source contributions by making it so easy! I wrote a quick post on how Art.sy uses Github to build Art.sy on the new Art.sy Engineering Blog, here.

Octopress documentation can be quite confusing. It took me a while to understand what the heck Octopress is doing to branches and remote origins. It’s actually pretty simple, so I am going to try to un-confuse you. I will also show you a better way to contribute to an existing blog and explain what’s happening in those Rake tasks.

We are going to deploy a blog to Github pages, so we need a project, such as username.github.com. Go to Github to create one. Use your username instead of “username”.

Next, fetch Octopress and install it locally. This gets the files from its main repository and applies a default theme.

Octopress comes with some handy Rake tasks to get you started. To deploy to Github pages run rake setup_github_pages. When prompted, enter the GIT URL to your new repository, such as git@github.com:username/username.github.com.git.

So what the heck happened here? It pointed our clone to our new repository. It also created a _deploy directory with another git repository that is going to contain everything that is being deployed. The remote in that directory is the same as the one in our octopress directory, but the checked out branch is master. Btw, we’re now on the source branch.

Now is a good time to read Blogging Basics. You should edit _config.yml with your blog name, etc. Lets create an article and deploy it.

Edit the generated file and add some text at the bottom.

Generate the blog.

You can also preview it with rake preview.

Before we deploy the blog, save the source and push it to Github. Note that we’re pushing our source branch.

You’ll have to repeat the above every time you make changes, to save them.

Deploy the blog. What this does it rake everything inside _deploy and push it onto the master branch.

If you go to http://username.github.com you should see your blog with the blog post once Github has regenerated the pages – usually a minute or two. And on https://github.com/username/username.github.com you should be able to see the generated files on master along with a source branch with the blog source.

You’ll have to do this every time you want to deploy your changes.

So how does one start contributing to an existing Octopress blog (or yourself from a new computer)? What we want is the same setup as above, but not from scratch.

You’re all set. Create posts and stuff. Happy blogging with Octopress.

In 93’ I wrote a Guestbook CGI in C++. Then in 94’ I made my first blogging system. I honestly don’t remember what technology it used, but I think it was some hairy PHP with a ton of issues. Data must have been stored in text files or something like that. The technology has since evolved and got hours of work poured into it. This blog’s code is here. But don’t use it. It all works, but it’s proprietary and riddled with legacy. I would have done something very different today. So …

I wanted something modern, fresh, nerdy and open-source for the new Art.sy Engineering blog. Last week I played with Octopress. It was confusing at first, but now feels completely natural and clean. Octopress is fully integrated with Git and Github pages, so we love it. Check it out. Bookmark it. Subscribe to its RSS.

There’s also an awesome first post by @mmcnierney14 on responsive layout with CSS3 and a collection of our open-source projects.

I’ve upgraded our project from Mongoid 2.0.2 to 2.4.0. It took me a few days since our specs raised a couple of real issues. If you’re doing the same, take Mongoid from the tip of 2.4.0-Stable.

If you remember, 2.0.2 dropped pagination support and a helpful Kaminari gem took over (details here). Once again the upgrade had a surprise, the number of items on the current page was wrong, displaying the entire count of a collection. I thought this was a bug in Mongoid and created #1584. Turns out that the behavior of count on a Mongoid::Criteria is now aligned with the Ruby driver, which takes a curious boolean skip_and_limit parameter that basically says whether to take limit and skip options into account (doc here). So calling Foo.limit(1).count may return 10 if there’re 10 Foos. The fix is to call Foo.limit(1).count(true). I am going to guess this was a bug in the Mongo driver and the additional of a boolean was a clever fix hack?

Kaminari needed to pass the boolean, which meant adding a current_page_count to the Kamiari collection wrapper, pulled in #194. Next version (probably 0.14.0) will have the fix. In the meantime, I am not super happy with my implementation:

• It’s not possible to know whether count takes a parameter, method(:count).arity doesn’t provide enough indication for optional parameters, so the code relies on a ArgumentError.
• MongoMapper needed the same fix, but is lacking a way to pass count to the driver. The current implementation calls to_a, which can’t be good when you just want a count.

I posted this to a Ruby forum a while ago.

I got controllers in a namespace and controllers outside of the namespace. For example, I have a PagesController and a Admin::PagesController. When I run rspec from the top, tests pass and I get the following warning: spec/controllers/admin/pages_controller_spec.rb:4: warning: toplevel constant PagesController referenced by Admin::PagesController. This makes no sense. I do have a PagesController and an Admin::PagesController and specs for both that are declared properly.

This was only happening under Spork, so I posted a similar question to the sporkgem list.

I also found a workaround, to require the Admin controllers first in spec/spec_helper.rb.

Finally, @tilsammans figured it out. It’s the same problem as what I have: an Admin namespace and an Admin class.

It was because I also had a class Admin, as well as a namespace Admin. Since Admin was a class (a model) it inherited from Object which made the top-level ApplicationController available inside the Admin namespace. The reply by Andrew White on http://groups.google.com/group/rubyonrails-core/browse_thread/thread/bab5e87ee10d2ecb lead me to find the right answer. In the end I renamed Admin to AdminUser and everything fell into place.

This is rather counterintuitive and one would think Ruby should somehow handle this situation, but it at least makes technical sense.

I love fabricators. We use the awesome fabrication gem that lets you do some pretty neat things in Rails specs.

For example, we have a page that lists users in alphabetical order. The retrieval is implemented in a controller.

The fabricator for a User generates a global sequence to give each user a unique name.

To test the above-mentioned controller, we would fabricate a couple users and ensure that they are returned in the correct order.

What could possibly go wrong here?

I made a beginner mistake that just looks like someone else’s fault (specs fail depending on which order you run them). To get a failed test we fabricate 8 users before this spec is run. The next two users that are fabricated are Joe 9 and Joe 10. When sorted alphabetically Joe 10 comes before Joe 9, duh. It’s a good lesson in not relying on external behavior for tests – in this case we should not rely on knowing how names are generated in a fabricator to test that the users are sorted by name. Instead, we should assign names explicitly.

You may have read my previous post about the MongoDB 1.4.x Ruby driver hell.

We rolled back to 1.3.1 and were running fine in production for a long time. On Friday, we started seeing intermittent deadlock: recursive locking errors from the driver and our site was struggling to stay up. Very quickly the error rate rendered it unusable. A Google search yielded Mongo Ruby driver bug RUBY-274, describing the exact error, which pointed a Ruby 1.9.2 threading issue #4266, explained in this blog post.

We were confused why this suddenly started happening with no apparent reason, created a ticket with our MongoDB provider MongoHQ and bounced the replica set members one-by-one as well as our app on Heroku. It did nothing.

Kyle, the maintainer of the Ruby driver at 10gen was replying to RUBY-274 and told us to upgrade the driver to 1.5.2. We did. All tests passed (we have over 2000) and our staging site was operating normally. But after pushing it in production where we have a replica set, we were now seeing a different error: stack level too deep, with /app/.bundle/gems/ruby/1.9.1/gems/mongo-1.5.2/lib/mongo/util/pool.rb:72 on top of a cut-off stack trace. By then I haven’t gotten up from my chair for six hours straight and you bet I was thinking the Ruby driver was the worst piece of crap as I was angrily typing RUBY-393, a knee-jerk reaction.

With a bit of calm and holding onto a better error someone on my team dug through this and hit the the root cause. We made a mistake in a data model and ended up with a recursion in a query. Instead of reporting an expected stack level too deep error for this one particular request the Ruby 1.3.1 driver blew up with deadlock: recursive locking and no stack trace, caused by a bug in Ruby 1.9.2, while other queries would immediately start failing bringing the entire site down with this error. The newer version of the driver did much better and only failed the specific query, which was much easier to diagnose. Pilot error – lessons learned. Sincere apologies to everyone involved at 10gen and MongoHQ – you guys were there when I needed you.

The 1.5.2 driver has been running rock solid over the week-end. I am hearing good things about it from other teams too. If you’re on 1.3.1 or 1.4.x, you should consider upgrading.

One of my favorite talks at QCon 2011 was about Webmachine. I was very curious to see what those well-disciplined Erlang people had come up with. At the end of the talk I had learned that Webmachine used a resource-based model that enabled well-behaved HTTP applications, which is RESTful by definition. So I went to NYC.rb today to hear about the Ruby version of Webmachine and to write a post about how these two frameworks compare.

Should you build your next RESTful API with Grape or Webmachine?

Both frameworks as saying that you should not force HTTP onto an MVC-shaped application. Both excel at serving HTTP resources.

Webmachine is an executable model for HTTP, while Grape is a DSL for RESTful APIs. This means that in Webmachine you don’t perform actions – you declare resources. In Grape you declare API methods and fill out the responses. In Grape you have to be disciplined about those API methods - they should represent resources, not RPC service endpoints. More differences appear in branching: halting execution in Webmachine is done by returning appropriate answers in resource-specific functions, while halting execution in Grape is done by throwing a specific exception that carries an HTTP error code. Routing-wise, In Webmachine you map URIs to resources, while in Grape you define namespaces and method paths that translate into invisible routes. In Webmachine you implement resource callbacks, while in Grape you use procedural logic within the API method implementation. Webmachine is trying to be a complete executable model and is therefore more structured, while Grape wants you to use middleware for aspects such as ETag-based caching and doesn’t try to prevent you from jumping in the water when you don’t know how to swim.

We had a long discussion about this outside of Pivotal Labs with @seancribbs and @johnjoseph (who even mentioned Prolog at some point). It helped me frame my opinion around mostly philosophical differences between the two frameworks. I could very well use Webmachine to build an API and be very happy with it (I would not be happy building an API in Rails). I would grant Webmachine an advantage over purity from the developer’s perspective – it’s harder to step outside of the programming model. I would grant Grape an advantage over favoring the API consumer, since it focuses on the expressiveness of the API. For example, Grape now has self-introspection for automatically generating documentation, a feature that seems harder and maybe even unnatural to build for Webmachine.

Fundamentally, Webmachine declares resources served via HTTP, while Grape declares an API. Your choice?

When choosing to use an open source project you might want to know whether it’s still developed or at least maintained. For Ruby projects I used to check Rubygems release dates. Here’s Grape’s.

Nothing for the last six months? Not very good – there hasn’t been a release for a while, but that’s more a tribute to the stability of the project.

You could check the number of forks and watchers for projects on Github.

It measures the project’s popularity quite well, but maybe not its activity.

My favorite way of measuring a project’s activity is to look at the Github network graph. It’s an amazing and useful feature. Here’s Grape’s.

The project is clearly happening. But you can see how this is all over the place – that’s a typical picture for open-source efforts: few core and relatively irregular contributors, long branches and abandoned ends for feature attempts that don’t get merged.

When a small group of people truly collaborates, their feature branches make it into master most of the time. They are also constantly picking up commits from the source. What does a really dense collaborative project look like? Here’s a picture from one of our private repositories. If yours looks like this, you got a team!

Maybe someone can use this idea to build a nice feature to measure a Github project density?

Building a software platform is not just an investment in the future, it’s a software architecture philosophy. A proper API is a manifestation of some of the core principles of domain driven design – spend a lot of time figuring out what your domain is, then build software that represents the immutable concepts behind an API and, finally, implement different businesses that can quickly thrive, die or pivot, on top of that. We’ve spent considerable amounts of time iterating on our own API and are constantly improving the artifacts around it as we learning from good examples of Twilio, Stripe, etc.

There’re several ways to build an API reference: entirely by hand, generated from code comments or by adding metadata at runtime. The first one is inanity and the second one is not leveraging the magic of Ruby. Hence I am a huge fan of the latter, as it offers the best chance of creating something that actually reflects code.

You can now do this in Grape with desc blocks.

Aside from the description passed to desc, you can specify a hash with anything in it. There’re a few conventions, such as :params, which will merge with any values specified in the URL of the API call.

We can introspect the API at runtime, adding a Rake task, for example, that lists all API calls with their parameters.

Notice how we’ve used the required option for parameters – it’s, once again, a convention. Grape doesn’t care – it’s pure metadata attached to a route. You can create similar conventions in your own API – we have some “partner” and “admin” APIs that we’ve marked in a similar manner.

This is now in the frontier branch of Grape, which is Grape v.next. Live on the edge.

A while ago I wrote about how we package and push Rails assets to Amazon S3. We version assets with the GIT hash – varying the assets by URL enables setting indefinite cache expiration and works well with a CDN. In that post you could find a Rake task that would delete any old assets and replace them with newer assets. It’s time for a revision with some new features.

The first problem we have solved is how long it takes to sync contents between a local folder and S3. The old task fetched the entire bucket file list, which grew quite a bit over time. The S3 API supports a prefix option.

The second issue is with asset rollback. We deploy assets to S3 and then code to Heroku. The asset deployment deletes the old assets. There’s a small window in which we have old code and new assets, which is obviously not okay. We’re actually saved by CloudFront which keeps a cache for extended periods of time. A solution is to keep two copies of the assets online: current and previous. The code preserves the most recent copy by looking at the :last_modified field of the S3 object.

Here’s the task with some shortcuts and a complete task as a gist.

Since we’re versioning assets with a GIT hash in the URL, another improvement is to set cache expiration to something longer.

I wrote about how we do asset packaging with Rails, how we Jammit and push them to S3 in this post. We’ve had a few surprises since then, one that had to do with compressed assets.

If a browser sends an Accept-Encoding: gzip header for a resource that has both an uncompressed and a compressed copy (eg. client.js and client.js.gz), the server can respond with the compressed version of the file along with the original Content-Type (eg. text/css) and Content-Encoding: gzip headers. This is called content negotiation. Unfortunately S3 has very poor negotiation skills. CloudFront CDN does better, but only if the server behind it supports it. So putting a CloudFront in front of S3 produces the same effect and Amazon recommends using a custom origin server (a fancy word for another web server), other than S3 if you want to enable content negotiation. We’d rather not serve static assets from Heroku because it requires checking them into source control. And we’d rather not add a web server that we have to maintain – too much infrastructure when multiplied by the number of developers.

The solution is, as usual, to monkey-patch extend rails. We’re going to tell our Rails application to serve a compressed file if the browser includes the right headers by rendering an URL to the compressed version.

In Rails 3.0 (your mileage will vary for 3.1) paths to assets are written via ActionView::Helpers::AssetTagHelper’s path_to_javascript and path_to_stylesheet. We can figure out browser capabilities by examining request.env['HTTP_ACCEPT_ENCODING'] and rewrite those URLs to our liking.

config/initializers/asset_tag_helper.rb and spec/initializers/rails/asset_tag_helper_spec.rb

The .cgz extension replaces the .gz extension to workaround a bug in Safari. The rewrite_path_to_gzip? check ensures that we’re rendering something under assets and that we’re using an external server (not in development). Your condition may be different.

Finally, we must set the proper content encoding headers when pushing the assets to S3. Here’s the meat of our Rake task.

Note that the Content-Type for a .css.gz file is the same as for a .css file (text/css) and that Content-Encoding is set to gzip.

To verify that your implementation worked, examine the page source and make sure you got a .css.cgz link for stylesheets. Then, navigate to the .css.cgz URL – it should display an uncompressed CSS.

For purists, this implementation is really bad. A browser may request a web page with Accept-Encoding: gzip, but then request the CSS from another server without it. I am going to decide that this never happens in real life.

I remember bringing a 14Kbps modem from the U.S. back to Europe in mid-nineties. I couldn’t wait to stick it into the ISA slot on my 486 and was underestimating how much trouble it was going to be to occupy my parent’s phone line all the time or discussing the phone bill at the end of the month. Things have changed in 15 years – we finally have Internet on airplanes for about ten bucks a flight.

So I just redeployed our production site with a few minor bug fixes from my seat on a Delta flight to Miami – going to Art Basel with the entire Art.sy team!

I’ve released DNI 2.0 today. It’s a major release with a new HTML bootstrapper, better elevation support, Windows 8, etc. It has been stable for quite a while now and a few people are using this build in production.

http://dotnetinstaller.codeplex.com/releases/view/50143

Build 2.0.81.0

#7968: Support elevation as a subsequent command within the bootstrapper. First UI shows un-elevated, but clicking install elevates. (dotNetInstaller only)
#8005: Added a new os_filter type 'greater than' (+) and 'less than' (-).
#6289: Added a new setup bootstrapper, htmlInstaller, driven by an HTML-based UI engine.
#6618: Added #STARTPATH, #STARTEXE and #STARTFILENAME substitution variables.
#6955: Added #OSLANGID substitution variable, operating system language ID.
#6620: Added #OSLOCALE substitution variable, operating system ISO language and region (eg. en-US).
#6956: #LANGID and #LANGUAGE are always set to the value in the currently executing configuration. #LANGUAGE may be empty, while #LANGID will default to the operating system value.
#6604: InstallerEditor no longer needs a configuration file to link a bootstrapper and the configuration does not need to be saved before creating an exe.
#6798: InstallerEditor will display file names when embed files are missing during linking.
#4884: InstallerEditor will notice that a configuration file has changed on disk and offer to reload it.
#6786: Bootstrapper will return a 3010 exit code when a reboot was required.
#6786: Added /noreboot to the bootstrapper to suppress actual reboot when required. Bootstrapper will simply return a 3010 exit code in this case.
#7004: The user-defined browse control will always return paths without the trailing backslash except for drive paths (eg. C:\).
#6730: InstallerEditor displays a * next to field names that are required and displays an error if the user tries to delete the value.
#7148: Added support for Windows 2008 SP2 and Windows 7 SP1.
#7252: Enabled Visual Styles: modified default manifests with a dependency on Microsoft.Windows.Common-Controls 6.0.
#7382: Added disablewow64fs_redirection at setup configuration and component level to run native x64 Windows applications (cmd, regedit, etc) from dotNetInstaller.
#7916: Added MUI support with MuiUser (preferred language set for the user) and MuiSystem (preferred language set for the system) options in configuration lcidtype.
#8277: Language selector dialog in dotNetInstaller will automatically select the operating system language if available.
#8256: Added /noRunOnReboot to the bootstrapper to suppress actually writing the RunOnReboot registry key.
#272583: Added support for Windows 8.

Vanity aside, Wired published a very well written article on Art.sy [link] in the December issue. I think it’s objective, describes the company vision well, and the story about a mobile prototype is completely accurate.

Also, got to love the photo taken at Haunch of Venison!

We’ll be at Miami Basel Nov 30th-Dec 3rd, don’t forget to say hi!

My first QCon, QConSF ‘11 was very good. I’ve been watching InfoQ for a very long time and wanted to go to QCon ever since.

What I loved about this conference is that it was mostly technical in nature and that the best speakers were hands-on industry practitioners. I also greatly enjoyed the fact that most attendees were architect-level engineers, which made for well balanced conversations over the frequently supplied drinks. The rare talks that I didn’t like were given by sponsoring companies’ PMs. Yawn.

The first day was like climbing a mountain of infinite wisdom. It started with a panel of software gurus that put objects on trial. I’ve been unlearning OOP for the last year of writing Ruby, hence I found myself completely in sync with the prosecution. Along with a number of Russians in the crowd I was particularly touched by the Souz capsule vs. the U.S.A. Shuttle analogy on class reuse. I lived near the Gagarin Square in Moscow. Tears were shed. The Russian space program was a great example of throw-away technology that turned out to be a lot cheaper to manufacture and enabled faster innovation.

There was an entire track dedicated to the concept of beautiful code. I got my Ruby CR/LF alignment porn at guilhermecaelum's talk and disagreed with about everything else during that track. In general, I think that code is more like a child than a painting. Code might first be cute, but it eventually grows into a complete being with evolved needs that requires additional complexity and structure. You can still teach it new things, but it gets incrementally harder. In contrast, each extra minute you put into a baby’s early days pays off big dividends in the long term.

I frowned during most of Rod Johnson’s keynote on Thursday. I certainly didn’t expect to hear a call to entrepreneurship at QCon. Much like great engineers often make terrible managers, they often make awful CEOs and CTOs. Running a business is a people, not a technology problem.

Then I went to the Lean Startup talk, where @joshuakerievsky confirmed that lean principles work well for the kind of social location-based coupon technology that thousands are building these days, because most of it will be thrown away anyway as these companies crash and burn. More seriously, I assume some of lean concepts speak poorly to many experienced engineers. Should we validate an idea without writing any code when possible? Yes. Should we write the bare minimum to produce a prototype that learns about the market? No. Prototypes turn into real products much faster in the hands of a business than engineers turn them into solid implementations. Pain, suffering, famine and death ensue. We need to both build high quality code from day one, and build it fast, in order to succeed when we hit product-market fit and the business explodes. That’s also why you should be hiring fewer people from the highest grade of software developer A-list.

I watched @emcooke's excellent Web API talk next. Evan came to GA a few weeks ago and gave a short version of the talk from a couch to a few techies. This is exactly the kind of talks I wanted to see more of. The guy had his hands in the code. He succeeded at building an API that people loved. He had priceless advice on each and every slide.

I really enjoyed @stevevinoski’s the talk on Webmachine. I’ve never written anything in Erlang. At first I saw Webmachine as a silly framework for declarative RESTful programming. But as the talked got into more complex issues a light bulb lit in my head and I think I totally got it. It’s unlikely that I’ll ever get to use this framework, but I went from being a skeptic to actually learning something.

@daniel_jacobson from Netflix described the recent evolution of the Netflix API. This was mostly about the internal API that thousands of devices use. They chose to create an API variation for every device a longtime ago and are now bringing scripting-like functionality to a middle-tier, server-side. Think of it as a server-side proxy for your API where you execute sequences of operations that are device-specific. Instead of performing chatty operations between a client and a server, you compile and execute them on the proxy.

There was a keynote on Dart on Friday. Why you would want to have type-checking during development and turn it off at runtime is beyond me. Does a thousand smart developers make an awesome language? Does a tree fall in the woods?

Fortunately @rauchg killed it in a live coding session for Socket.IO w/ node.js. He built a chatty client-server and OMG, he types way faster than me.

There was a nice NoSQL applications panel where each vendor tried to sell each-other’s products. It was so polite!

Last, but not the least, I met with a bunch of old friends that live in SF and even got to touch a Kindle Fire warm out of Amazon!

I mean, I am flattered to be #20 of the most poachable techies in NYC list, and you got about half of your facts right (eg. my Github account) but seriously?

I’m at QConSF 2011.

The keynote was in the form of a trial with a dressed judge and witnesses. A penguin, a ball and a UML object were the accused. Brian Foote, a software ethnologist, talked about reuse. He argued that the American reusable space shuttle wasted a ton of energy vs. the Soviet Союз space program that left everything except a small module with cosmonauts behind. That's enough energy and metal to build out a Stanley Kubrick space wheel a mile in diameter. Joshua Kerievsky made a parallel between object inheritance and real life. Having a vasectomy to avoid having children is the kind of discipline objects could use.

I got 5 seconds around 1m20.

http://www.ny1.com/content/ny1_living/consumer_watch/150699/startups-provide-non-traditional-spin-to-job-fairs

Mea Culpa. Alla Klein was a fake.

I had a software company called Vestris Inc. in late nineties, incorporated in the BVI. I was 20, had no idea what I was doing, and improvised a lot. I started with a bunch of shareware: XReplace-32 was probably the most successful. I also had a classmate collaborating on a search engine called Alkaline, which made quite a bit of money. The cash was collected from a Swiss bank in Geneva in-person. We sold in 40 countries to thousands of satisfied customers. For enterprise clients I wrote invoices and contracts out of my tiny apartment and we had a phone number, a fax and a voicemail for 24h support. The latter was run by a fake person, Alla Klein. Nobody ever saw Alla, but she was very much in charge.

The following things made Alla very successful.

1. Alla would spend a lot of time helping customers outside of crisis, earning credits that could be spent in bad times. She had a relationship with every customer, free, small or large.
2. Alla had clear ownership of support problems. She would deal with issues, immediately and was the only point of contact and voice.
3. Alla always got back to customers via e-mail to make sure all their issues were resolved.  She was proactive in reaching out and tracked dissatisfied customers offering her time and expertise.
4. Alla was honest in her communication. She never made promises or refer to another person in charge. She never offered apologies or excessive sympathy. She always stated hard facts.

This combination made Alla our number one employee. In fact, she was regularly cited by customers that communicated with sales as one of the most competent support people that they ever had to interact with. She was also asked on a couple of dates. True story.

I’m speaking at NYC.rb tonight @ Pivotal Labs, RSVP.

Update: Slides from the talk are here.