Recently I’ve been asked this so many times lately that I’m going to cache the response.  The question is:

“If you were starting a software company right now, what would you start with?”

Of course there are a million different questions you’d need to ask first.  But given what I’ve done historically, here’s what I’d do.

• Scala.  It’s been hugely productive, fast, fun and great for our team.  Functional without performance baggage and java-interop (for better or worse)
• MongoDB.  I don’t know many companies now that start with anything different.  MongoDB is a race car and if you keep it on the track, it’s as fast as in-memory caching.  Really
• Scalatra.  I’ve been using Java Jersey for years now and it’s great—performant, flexible, easy to read and super stable.  Why switch?  It’s just not native scala.  That means case classes are troublesome, JAXB annotations pollute the scala code, etc.  Scalatra has a super clean interface, is fast and has a great future
• Casbah.  If you can use case classes then Casbah is a fantastic driver for mongo.  I still believe in a DAO layer to abstract calls to the database—nothing hurts a server more than a full-table scan on 20 billion rows.  A good DAO layer will protect you from hanging yourself
• Swagger.  Of course!  But really, I’d start with swagger from day 1.  Make your API consumable by others and your team.
• EC2.  Yes, EC2 is still the best cloud hosting provider.  It probably won’t be that way forever but it’s great (if you manage it)
• Akka.  OK, Akka is an amazing middleware for concurrency.  It really shows what scala can do
• Twitter’s scala guidelines are a fantastic place to start for anyone writing scala.  See here
• No web server.  You can do it all with javascript and a scala backend.  And faster, really
• Tons of profiling.  From day 1, you should profile the hell out of your system.  The wordnik OSS tools make it easy.  Wordnik-OSS

Part of the swagger spec is declaring the base path for your api.  This appears under the resource listing and points to how clients should connect.  This is helpful if the resource listing isn’t in the same base path as the API itself.

In both the swagger-java-sample-app and swagger-scala-sample-app, these are configured in the web.xml, for example:

<init-param>
  <param-name>swagger.api.basepath</param-name>
  <param-value>http://api.wordnik.com/v4</param-value>
</init-param>

Problem is, you might be using programmatic methods to set this value.  So putting it in the web.xml is a pain to manage.

To get past this, you can delegate the base path to a class to make it more intelligent.  Simply assign the class in the web.xml as follows:

<init-param>
  <param-name>swagger.config.reader</param-name>
  <param-value>com.myapp.MyConfigReader</param-value>
</init-param>

And implement the logic in the supporting class:

class MyConfigReader(sc :ServletConfig) extends ConfigReader(sc :ServletConfig) {
 override def getBasePath():String = {
   // some fancy logic to determine base path
   val basePath = "http://node2.wordnik.com/v4"
   basePath
 }
}

Now you can do what you wish to report back what the base path is without mucking with the filesystem.  Viva!

parislemon:

Horace Dediu presents yet another amazing way to look at the rapidly evolving computer industry (here are Dediu’s other fascinating looks of the past few days).

The PC looks like a rainbow at its peak.

The Macintosh looks like a roller coaster with a misleading small first hill that tricks riders.

Android, iPhone, and iPad look like fireworks just taking off…

I just finished getting my 1966 Raleigh Superbe up and rolling.  Some observations:

* “All Steel Bicycle” can be translated into “Very heavy bicycle” or “Very rust-prone bicycle”

* Plastics fail before steel, always

* Squeaky brakes are an effective warning signal

* The dyno hub rules

The dyno hub is a electricity-generating front hub.  It has a very cleaver design where a large steel (yes, more steel) splined steel rotor is surrounded by an array of magnets which produces a consistent AC power to the lights, which are inside steel (yes, more steel) lamps on both the front and back of the bike.

Forget the battery!  After 45 years, this hub still works perfectly.  There are hints of rust covering this bike but the hub functions.  Ride over 5 MPH and you have a visible light on both front & rear.  Ride over 10 and you have enough light to see.  Ride over 15 and you have no excuse.  This thing works as long as you’re not sitting still.

It’s a trophy from the golden age of engineering when falling back to some sort of computer-controlled device wasn’t possible.  

Wordnik’s swagger spec + framework makes WADL look like your grandfather’s car.  Some notes from the docs, which are available at http://swagger.wordnik.com:

Swagger is a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services. The overarching goal of Swagger is to enable client and documentation systems to update at the same pace as the server. The documentation of methods, parameters and models are tightly integrated into the server code, allowing APIs to always stay in sync. With Swagger, deploying managing, and using powerful APIs has never been easier.

Who is responsible for Swagger?

Both the specification and framework implementation are initiatives from Wordnik. Swagger was developed for Wordnik’s own use during the development of developer.wordnik.comand the underlying system. Swagger development began in early 2010—the framework being released is currently used by Wordnik’s APIs, which power both internal and external API clients.

Why is Swagger useful?

The Swagger framework simultaneously solves server, client, and documentation/sandbox needs. As a specification, it is language-agnostic. It also provides a long runway into new technologies and protocols beyond REST.

With Swagger’s declarative resource specification, clients can understand and consume services without knowledge of server implementation or access to the server code. The Swagger UI framework allows both developers and non-developers to interact with the API in a sandbox UI that gives clear insight into how the API responds to parameters and options.

Swagger happily speaks both JSON and XML, with additional formats in the works.

How is Swagger implemented?

As a specification, Swagger is language-agnostic. But since a spec without a usable implementation has limited immediate value, Wordnik has released Swagger implementations in Scala, Java, and HTML5. Client generators are currently available for Scala, Java, Javascript, Ruby, PHP, and Actionscript 3. More client support is underway.

What is Swagger not trying to solve?

Swagger does not currently include a suggestion for supporting multiple API versions from a client or server point of view—versioning information (both of the spec and the underlying API implementation) are declared.

It does not tell you how to write your APIs. For example you can choose to delete an object from your system either by an HTTP delete operation or via HTTP GET with query param. While being a good, RESTful citizen is encouraged (and rewarded by an effective API sandbox client), it is not a prerequisite to use Swagger.

Swagger is not trying to solve all problems for all APIs—there will be use-cases that fall outside of the Swagger specification. For this reason, Swagger is an improvement on existing specs like WSDL 2.0 and WADL which must support legacy systems in order to be generally accepted.

All roads lead to 32 bits