We’re putting the finishing touches on the new website. It’s an amazing improvement over the existing one, and we think it will blow you all away.
The important new features are:
We should have it up within the next day or two. Let us know what you think!
A few days ago we had a disk issue in our monitoring system which caused a number of false-positive alerts to be sent. We are sorry to anyone this inconvenienced, and fixed the error as quickly as possible. We’ve added capacity to the test cluster and better monitoring in an effort to prevent this from happening again.
As they say, though, within every problem lies an opportunity. We saw some hiccups with our email server system during this time, and decided that it was time to revisit our email solution. A few weeks earlier I saw this post on the Skribit launch which mentioned SendGrid, a startup company focused on email service.
In addition to offloading the heavy lifting of maintaining a production-ready email system, there are some handy built in reporting features that should prove valuable in the upcoming months after launch. It was dead simple to switch over, and we’ve been pleased so far. I continue to be amazed at the services one can find now-a-days to make the process of building and deploying SaaS applications as smooth as possible.
I briefly mentioned in a previous post the frustration we found in integrating with our payment gateway API. Luckily just a about a month ago I fortuitously stumbled into a Hacker News thread about subscription billing startups. It only took about 5 minutes of clicking around the Chargify site to know we needed to have it. Simple but complete model for subscriptions? Check. Full API for integrating? Check. Pricing model thats not based on percent-of-total transaction fees? Big check.
Unfortunately, they were in private beta at the time, so we went back to other work It only took a few weeks for a beta invitation to arrive, and I’ve been huddled over my laptop ever since. All told it took about 6 hours to code, from scratch, a simple Scala binding for the Chargify REST API, which says something about both how simple and straightforward the API is, and how effective Scala is as a language.
The best news is that we’ve put the sources up on GitHub to share with everyone. If you’re going to give Chargify a try and are using a JVM language (Java, Scala, Groovy, etc…) give the binding a spin. As always, criticisms, suggestions and contributions are very appreciated.
Back at the start of this project we had to decide which technology stack to go with for developing and deploying our application. We came up with several requirements that would dictate the options. The chosen environment had to:
For stability, performance, ease-of-deployment and library support the JVM runtime with select parts of the J2EE stack came out on top in our comparison, which left only the choice of language. Java itself may be everywhere, but is missing some important features for expressibility and because of the verbosity of the language can feel like a bit of a productivity killer.
Instead, Groovy seemed to offer a good combination of flexibility and compatibility, and the clincher was the great work going on in the Grails framework. Spring, Hibernate and deployment as a standard J2EE application, but without all the extra work involved in plain old Java with XML configuration. Thus began a year-long love/hate relationship with Groovy and Grails. The dynamic nature of the language allowed for great speed of development with less code, however over time we realized that all that saved time was being spent debugging shallow but numerous runtime errors that slipped by due to weak compile-time checking.
About this time we started looking at Clojure and Scala as possible replacements, and between the two chose Scala due to it’s flexibility in mixing OO and functional code. I dove into Programming in Scala and within a few days was happily writing lots of (poorly functional) Scala code. It was a very pleasant surprise to find that not only the functional features and type inference made Scala as fast and clean to write as Groovy, but the strong typing severely reduced the cases where code that successfully compiled did not function as expected. It’s the best of both worlds, in our (short) experience, and with the addition of the Lift framework is fully as capable out-of-the-box as the Groovy/Grails combination.
More to come on this topic, but for now I’ll just say that, like James Strachan himself, had we found Programming in Scala a year earlier we probably would have never picked up Groovy in the first place.
This week we tackled payment processing. There are a ton of options out there from Paypal, to Amazon FPS, to Google Checkout, and more. Then there is the old mainstay – getting a merchant account. Even then you have quite a set of options to sift through, from finding favorable account terms to choosing the payment gateway.
We evaluated all the options, and although the “alternative” payment collection services all seem to excel at ease-of-integration, each one had downsides we weren’t able to accept. It seemed that getting a merchant account was the way to go, but how to go about it?
Luckily, I happened to find a great post on the subject, How to get a merchant account, over at Daniel Tenner’s blog. It’s really solid advice, and I’d recommend a read before tackling the problem.
With those tips in mind we managed to get reasonable terms, and are working now on integrating with the Authorize.net payment gateway. It’s been a little frustrating dealing with the oddities and limitations of the API, to be honest. If ever there was a market ripe for disruption…
