cloudlab.io

Launch Lessons

Fri, 09 Mar 2012 23:23:52 -0500

Since launching cloudlab we’ve gathered a wealth of lessons on what to do (and not to do). In this update, we’re going to share some interesting analytics and some hard-learnt lessons with you in the hope you can see where we’re going with cloudlab.

We chose Hacker News (HN) as our first point of release. HN is a great site to get brutally honest feedback and as far as prospective customers go, represents the scene we’re primarily targeting. After a good half-day, it also showed up on Reddit.

Graphs & Numbers

Both of these sites (and the aggregators following them) generated a nice bit of traffic:

In terms of conversion (new users), if we take the number of visits as ~950 and the number of new users as ~50, roughly 5.2% of users who saw the landing page decided to sign up. Awesome!

Looking a little deeper at user engagement the result was surprising:

Of the users who signed-up, only 25% of actually made it to the meat of the product, the IDE¹. This is the part of the product that is the most awesome, yet only one percent of all visitors made it there!

Demographically, the U.S. and Europe represented the majority of visits which lines up with expectations:

Nearly three quarters of the traffic directed at the server was from a WebKit browser, with the next ~25% being Mozilla-based:

Good news is that the server held-up and had no troubles with our provider AppHarbor.

First Impressions Last

What a turd. Since they’re apparently too good for their “links” to be actual links
<a data-target="#registerModal" data-toggle="modal" class="btn btn-large btn-success">
a user with noscript

Analysis: we use Bootstrap extensively². Opening modal dialogs can be done be done with a href or a data attribute. This was a usability problem that was foreseen but put on the backburner - who cares about the landing page when the meat of the work is behind the scenes? USERS CARE.

Solution: it sounds elementary - always make sure that you fallback for a browser without JavaScript enabled. If you don’t support their choice then at least let them know that they need it enabled, preferably somewhere visible.

Sign in

Register

x Leave

(sorry, I’m sure it’s a cool project, but I’m not signing in to anything just to test it, unless it’s really, really worth my time)
a user with a good point

… the fixed password policy isn’t really amusing. I guess you guys will track it and see what happens, but I bet that you’ll notice a way depressed return user rate, because every time I’ll want to log back in I’ll need to go search through my email first, and I’ll never really “activate” as a user after the first time or two playing around.
a user with a very good point

Analysis: trying to make registration painless is something you want. We thought that by sending passwords out in the mail and logging you in immediately, this would be as painless as possible. The fixed-password policy which account recovery easy while ensuring robust security. WRONG.

Solution: use BrowserID. Don’t have to worry about passwords or email verification.

Crux of the Matter

There was one major piece of feedback that really struck home:

What kinds of data formats do you support, and how big can the data get? I have something like 5 terabytes of data lying around waiting to be analyzed. JSON doesn’t really sound compelling when I’m talking about huge matrices or gigs of timeseries data.

If your scripting environment makes lots of assumptions about your platform in a way that makes it nonportable code, and you don’t open-source it, it’ll be hard to get people to make the investment and move projects onto your platform now knowing it could disappear at any time.

We agree. Going down that path of making all data JSON in a RDBMS was a road that ended up being a dead end. To date, less than ten new sets of data have been uploaded. It’s a monumental failure. People don’t want to have to convert their data to JSON and then back again. It’s a transport language³ dummy!

So now we’re going down the Dropbox route⁴. You link your account and we pull and push files from your favorite provider. If you don’t have a Dropbox account, they give you a 2GB one for free. To enable this different way of treating data, we’ve partially implemented a number of CommonJS specifications.

Rounding Up

No plan survives battle, and no launch goes according to plan. Feedback, no matter how harsh, is something that validates and disproves any preconceived notions you have about what you’re trying to make. Revel in it and most importantly, learn from it.

Integrated Development Environment ↩
We need a designer/developer. More on that soon. ↩
Yes, yes, strictly it is a superset of JavaScript. ↩
If you’re interested in testing out this new Dropbox/CommonJS functionality, drop us a line ↩

After many months of work, but we’re ready to unveil our cloudlab.io alpha! Cloudlab is...

Tue, 21 Feb 2012 07:17:00 -0500

After many months of work, but we’re ready to unveil our cloudlab.io alpha!

Cloudlab is a numerical processing environment built around cloud storage and cloud computation, but without the nasty parts. You put your data in as JSON¹ and process it using ES5 JS bound to native math routines. You can store your tools (scripts) with us, and even execute your tools remotely. Think of it as a hybrid between Matlab, Parse and JSFiddle.

Right now, pricing is cheap (free²). In the future we will price accounts according to a combination of physical storage, computational complexity and API requests.

Caveats

Be forewarned: this is a public alpha test. We’re still working on many things and there are some bugs. If you have data that is essential to you, do not rely on cloudlab (just yet) to manage it for you. Additionally, the server³ may experience heavy periods of traffic and interactive sessions may reset more. This is natural and will go away once we can afford to scale it up.

If you believe you want something like cloudlab.io to exist into the future, as a user you can donate to us⁴ which will fund future development of the software and hosting resources. If you are interested in investing in this operation, please contact this address.

API is currently under development but will support more data formats in the future ↩
A free account is for life and you get a megabyte of tools and data (each) ↩
Yes, a single server ↩
Pinboard has something to say on the matter ↩

Interfacing with Cloudlab

Mon, 23 Jan 2012 13:46:38 -0500

Developing applications that do interesting things with the potential to make exciting things happen is the bread and butter of the hacker. So with that in mind, we’ve been working on ways to allow our users the ability to fully harness the platform’s capabilities by providing powerful yet simple developer tools.

Just in the past few days we’ve integrated our REST API into cloudlab. This API provides an easy way to get your tools and data in and out of the system - basic CRUD stuff. Most excitingly, one final endpoint allows you to spawn a virtual instance of the cloudlab environment on the server side, which you can then integrate into your own numerical processing application using cloudlab as the service.

Currently we’ve only provided a simple .NET library that interfaces with cloudlab, which you can grab on GitHub. We haven’t added serialisation / deserialization of the protocol data structures yet, as different JSON providers have different characteristics. This library was developed on Mono and should work in your cross-platform applications (Windows, Mac, Linux, iOS and Android via MonoTouch and Mono for Android).

We’ve also hacked-up a simple command line interface application that uses the aforementioned virtual instance to create a simple REPL. This demonstration application was also developed using Mono and is available on GitHub.

For all of these features you will need your API key which can be found under the Special section of your Account. We’re very keen on getting this part right, so if you’re a developer and you want to see something implemented or modified or want to create a binding to your favourite language of choice please contact us. We won’t bite and we’ll give you all the help you need to make it happen.

Benchmarking

Mon, 02 Jan 2012 19:35:23 -0500

In trying to build a good replacement for other numerical processing applications, we’ve needed to benchmark the performance of cloudlab versus other places in which JavaScript can be run to process numbers. The following table lists the result of five successive runs of Benchmark.go

Browser	1	2	3	4	5	Avg	Total
Win7 Chrome 16	8.44	8.53	8.33	8.59	8.44	8.466	42.33
Win7 Safari 5.1	11.51	10.15	10.19	10.27	10.51	10.526	52.63
Win7 Firefox 9	116.49	110.00	109.51	109.50	110.70	111.24	556.20
Mac 10.7 Chrome 16	8.15	8.08	8.11	8.12	8.11	8.114	40.57
Mac 10.7 Safari 5.1	7.04	7.08	7.04	7.05	7.06	7.054	35.27
Jurassic (2.2)	566.12	563.16	563.31	566.12	565.50	564.842	2824.21

var Benchmark = {
  js: function() {
    'use strict';
    var _sts = (new Date()).getTime();

    var arr = [];
    for(var i = 0; i < 1000; i++) {
      arr[i] = i;
    }

    var _sum = 0;
    for(i = 0; i < 1000; i++) {
      for(var j = 0; j < 1000; j++) {
        _sum += arr[j];
      }
    }

    var _ets = (new Date()).getTime();
    return (_ets - _sts);
  },
  go: function() {
    'use strict';
    var _jsTotal = 0.0;
    var _start = (new Date()).getTime();

    for(var i = 0; i < 100; i++) {
      _jsTotal += this.js();
    }
    return {
      'Javascript': _jsTotal/100,
      'Total': (new Date()).getTime() - _start
    };
  }
};

No real surprises here, although we expected more from the latest Firefox. Now, if instead we use cloudlab’s built-in Vector type with it’s native-backed math, we get a different result:

This graph represents 250 runs of Benchmark.go using the native math provider we’ve hooked-up to Jurassic. Performance is variable, but excluding the two outliers, it ranges from as fast as the browsers to ~33% faster. So it’s mostly faster (we’re working on that), but you also get some awesome math:

native: function() {
    'use strict';
    var _sts = (new Date()).getTime();

    var vec = new Vector(1000);
    for(var i = 0; i < 1000; i++) {
      vec.v(i,i);
    }

    var _sum = 0;
    for(i = 0; i < 1000; i++) {
       _sum = vec.sum();
    }

    var _ets = (new Date()).getTime();
    return (_ets - _sts);
  },

Summary

We love math and Javascript sorely needs more of it. We’re hoping to really make hard math easy and let you process ‘Big Data’ using the tools of the web.