Martin Wawrusch

2 quick ones I stumbled upon while readying a new app to run with the asset pipleine enabled, scottyapp.com.

Adding a new asset class folder requires a server restart.

The current version of Rails RC5 + Sprockets seems to read the folder structure at boot time, so when you add a fonts directory under /app/assets it is not picked up until you restart the web server. 

Compass seems to interfere with the new image_url and similar helper methods.

In your sass file you can use image_url(‘myimage.png’) instead of url(‘/images/myimage.png’) to access your images so that you get the correct sprocketized asset reference. However image_url does not return the correct path when you also use compass. To fix this use url(image_path(‘myimage.png’)) instead.

BTW, this also works for fonts_url and so on.

Rails 3.1.rc5 on Cedar

Heroku has published instructions how to use Rails 3.1.rc5 on their cedar stack. You can find them here: http://devcenter.heroku.com/articles/rails31_heroku_cedar

Previously this required, among other things, that you include therubyracer or therubyracer-heroku. Not anymore. You can now use the built-in node.js engine which is located at your local bin directory. This means that you need to check your path on heroku to ensure that it includes the local bin as well. The process is described at the link above, just make sure that your path ends with :/bin:bin . That’s right, both a bin from the root and from your local directory. It’s a bit hard to spot and cost me a couple of hours.

The Asset Pipeline

Perfectline discovered a nice little feature in the asset pipeline; you can now set :debug in your javascript include helper to avoid concatenation of asset files. Pretty much essential for debugging, unless you want to debug something like error x on line 17932. 

Here is the code sample:

javascript_include_tag :application, :debug => Rails.env.development?

Cloudfront

PaaS like Heroku should never be used to serve static content. It’s just a waste of precious compute cycles and slows down the end user experience. Instead you should use a content delivery network, and Rails 3.1 and Amazon Cloudfront makethis dead easy. Cloudfront has a feature that allows you to populate the CDN from any url. This is called a distribution with custom origin and you can learn about it here.

To make this work:

1. Create a Cloudfront distribution for your site and set the custom origin to yoursite.com
2. Edit your production.rb file and change config.controller.asset_hosts to your Cloudfront asset link at Amazon. Or, better yet, use a cname and map assets.yoursite.com to your CDN and link to that.

That’s it, and you will immediately see performance improvements.

I wrote a quick jQuery plugin in Coffeescript today. Nothing fancy, just an easy way to display tweets. Turns out it was faster to actually write that one then to find it on the Internet, there are just too many Twitter plugins out there. Take a look at what it does:

It simply displays the tweet text, nothing else, and rotates it’s content with an unobtrusive fade.

I posted it on gist.github.com, it can be found here . The compiled version can be found here. 

The really interesting observation about this is how easy it is to create jquery plugins in Coffeescript. Once I had figured out how to deal with the options (Thanks to Jim Myhrberg) the rest was trivial, took me about 15 minutes.

I have recently moved to an ‘API first’ development approach, even for MVPs. Basically, as you need an API for mobile and fancy stuff like chrome extensions (launching my first one this week) why not start with an API first? It helps tremendously in focusing on the essence of what the app is about by removing all the distractions of the user interface. It is also boring to a point where you really want to get only the essential features done, which aligns perfectly with the concept of an MVP (As you probably have guessed by now I am not big with the teaser screen MVP crowd, but that’s something for another post)

So I have created a fancy API, it even supports OAuth2 and is fully documented, now what? Leave it just as a part of the app, offer it as a free service only? Hell no! APIs are there to make money, but we are still at the beginning of the era where people are accustomed to use and pay for APIs, so we need a marketplace that takes care of all the details involved in selling my API. For me the important points are:

• I need a means to collect usage information per API user.
• I need a means to indirectly get paid for usage, like for example in the Apple iTunes store. I don’t want to deal with payment, at least not until I reach simplegeo.com heights.
• I need distribution. Badly. Selling an API is hard, developers are a tough crowd, so all help here is appreciated. Posting on programmableweb.com is not enough :P.
• I do not want to pay for the right that an API marketplace can sell my APIs and earn commission, but I accept a 30% commission.
• I do not want to proxy through some third party site. I don’t care how good your caching is, I don’t need it, especially when you do not support OAuth2.

Now there are a lot of other things I would like to have, like

• a button on my website next to the API definition with a huge Subscribe to this API on XXX. 
• an automated, skinned email service that sends daily usage reports to my API users.
• widgets that I can embed on my site showing usage statistics.
• the ability to automatically create client libraries and documentation
• the ability to have an online shell to try it out.
• helper libraries to create the xml (why not json, btw) necessary to support most of the other items on this list.

but those are not really that important to me, they are add ons. If someone finds my APIs so useful that she wants to pay for them then she will probably invest an hour in playing with it first, so although wrappers provide convenience they surely don’t matter if I cannot easily sell.

After figuring out what I need I started to look for someone to help me with it. Quite a few companies are working in this space right now, unfortunately none seem to get it right the way I want it. 

Apigee.com provides a nice shell, great documentation (check out their slides and videos), but no Oauth2 support. Paying $1,500 per month for a six day MVP is not really an option. As far as I understand they also do not provide a marketplace and billing for their clients.

Mashery.com targets a different market (netflix.com is one of their premier users) which leads them to not even publish prices anymore. It’s going to be interesting to see what they are going to do with their $11 millions. 

3scale.net is a very strong contender, but unfortunately they are not a marketplace which is a real pity as they understand APIs very well. If my needs were a bit different they would be my first choice.

webservius.com seems to come very close to my needs, they provide a proxyless solution as well. I really wish they would clean up their website, remove 80% of the copy and be more aggressive in terms of marketing - they are the only ones I haven’t heard of before.

Mashape.com is close in terms of handling payments and even provide some sort of automated API wrapper library generation, but their integration process wants to own you and does not work with OAuth2 yet. They do have a marketplace though which is great. If they change their integration process a bit I will definitely sign up with them.

So as it seems there is a real opening for a genuine API marketplace modeled after Apple iTunes. I hope that in six months from now the situation is different and we have a couple of vendors, and web app owners can expose their APIs hassle free through them, allowing their users to choose which one to pick. There is really no reason to support only one API marketplace as an API provider. 

All this is happening in the data space already (see factual.com and infochimps.com for prime examples), why can’t this happen in the genuine API space as well.

LAMP has served us well. It gave us Facebook and millions of other sites. But it shows it’s age. Time for something new.

If you are developing web apps in 2011 you will probably want to go a completely different route. No more Linux, no more Apache and definitely no more SQL. Here is what works for me:

PAAS

This basically removes the L & A. No more need to deal with Linux or Apache by yourself.

• Heroku - Everyone but people near Seattle know about Heroku :)
• DuoStack - A new PAAS platform that offers both Ruby and Node.js hosting. 
• Nodejitsu - Similar to Duostack, but without the Ruby.
• SimpleWorker - A background queue in ruby as a PAAS. You just enqueue your code with a single statement and Simple Worker does the rest. Real magic. It transforms how you develop even simple apps.

Languages

I am biased, I admit it. Some people have other preferences, and there is no mention of clojure or scala in my list even if they are great languages. Still I believe that the languages here will provide you with both the best developer experience and productivity.

• Ruby - If I regret one thing in my startup life then it was neglecting Ruby. It is such an elegant and powerful language that is my primary choice for web apps now. We use it with Rails; and Sinatra to expose an API.
• Node.js - While technically not a language it is a game changer, like Ruby was for Web 2.0 apps. The benefits are clear: Use of a language everyone knows. Super fast. Resource efficient. Async everywhere.
• Sass + Compass - CSS was always a sour point in developing for the web. In a way it felt like writing design in assembler. With Sass we now have a language on top of CSS that takes the tedious parts out of CSS development and makes it reusable and much faster. No more need to remember all those nasty browser idiosyncracies.
• Haml - Some love it, some hate it. It transforms HTML code into a structured form that can be easily manipulated by indentation. It has a bit of a learning curve but it is one of those technologies that provide a real productivity increase.
• Coffeescript - The little language that will make it big with Rails 3.1. It sits on top of Javascript (which means that it can be used for browser development and the backend with node.js) and provides a Ruby inspired syntax. Once you started with it you will never go back to Javascript.

Database

This is a short list. If you want to create scalable web apps fast and have fun then right now your best choice is

• mongodb -They just got it right.
• hosted on mongohq - This is the easiest way to run your mongo dbs. They take care of operations and backups and let you scale beyond 100 gigs of data for a very low price. Definitely a company to watch, they just got accepted to y combinator. Paul Graham trusts them, so should you.

APIs

So many to choose from, here are the ones I really care about: 

• websolr - Fulltext indexing as a service. Integrate it into your app with a few lines of code and you have full text indexing capabilities.
• mailchimp - If there has ever been a good use case for freemium it is Mailchimp. The deal is basically like so: You get mailing lists with up to 2000 subscribers per domain for free, and can send 12,000 mails per month for free. If you need more you have to pay, but you can combine that with the supercheap Amazon SES.
• postmarkapp - The other email solution. I like to use them for mails that I really need to track, which is super easy with their REST interface.
• pusher - This is the app for you if you need quick and reliable real time communication and node.js is just overkill.
• Embed.ly - Whenever you feel the need to embed content in your web app use their service. Dead simple.
• Typekit - No more excuse to use ugly fonts on the web. For me one of the greatest contributions in the last couple of years.
• Amazon S3 - Combined with PAAS a really strong solution. Host all your assets there, maybe even expose them trough cloud front and remove the load from the PAAS, which should not serve static assets anyways.
• Twitter - Even with their recent shakedown on independent developers a good platform to use.
• Facebook - 500 million users can’t be wrong :)
• Recurly - We choose recurly because it is so dead simple to setup and operate. Plan processing and payments has always been a pain. They make it fun.
• simplegeo - The one service you need for your geo location apps.

Other

• Geckoboard - Now that it is so easy to create web apps you will probably want a dashboard. Geckoboard provides just that. Link it to your favorite services and expose your own data points.
• Uservoice - A beautifully crafted feedback solution. It appeals to the average user, and those are the ones you want feedback from.
• Disqus - After years of being used mostly in blogs disqus is finally catching up in web apps too. It is a great way to provide a topic specific community. For example you should add disqus pages to all your help pages and those pages that describe your API.
• Hoptoad or Exceptional - Still undecided between those two. In any case, they provide an essential service - they track your application exceptions.
• Zendesk - If you have an app that requires extensive customer support this is definitely the app for you.
• Github - They are at the core of cloud based software development. 
• tumblr - Create a simple blog for your app and blog about what’s happening. Makes blogging work even for people like me.
• Google Apps - Free email for your web apps, and even more if you make use of their online document and spreadsheet products.

What’s missing?

• Some great analytics solution I am still looking for (maybe kissmetrics)
• A continuous deployment server with analysis capabilities and automated fault tracking. Perhaps MikeCI will go in that direction.
• A social ramp up platform that I can seamlessly integrate into new apps. 
• An integrated hosted browser testing platform that is affordable.
• A planning app that lets me connect all my app’s stats and provides me with an interactive overview of the apps financials, churn and other metrics and compares that to my forecasts.

I guess we can not pack all that into one 4 letter acronym. But then again, it shows how much leverage we have. And best of all, while not all of them are free you can run almost unlimited apps for ~100 per month.

And it is also quite telling that we moved from a technology focus to a service focus. If you play it right most of the admin aspects of running a web app just vanished.