Development Blog: Viget Labs

Clinton R. Nixon, Senior Developer, April 16, 2008 3

I was incredibly excited to see the announcement of Google App Engine (GAE) recently. I can run web applications on Google’s grid, and have access to their authentication and back-end data store? Sign me right up!

Since it was announced, GAE has taken a lot of heat from pundits. For the most part, they are right, once you cut past the hyperbole. It is exceptionally limited: you cannot run spun-off processes on the server, there are no cron jobs, and the data store, BigTable, is not a relational database. It does threaten to lock in your application: if you use Google authentication, good luck migrating your users, and moving from BigTable to a relational database elsewhere would possibly be tough.

However, limitations can provoke creativity, and enhance applications built for that space. There are a lot of applications you can build without background processes, and if the end-game for your application is not to be bought, having Google’s authentication in place could vastly increase your user registration rate, as most users will not have to sign up for a new account. If you want to make a web application that does an interesting, simple task, GAE may be the best platform around once it gets out of beta.

From a development perspective, the fact that GAE only runs the Python programming language is definitely limiting. It is obvious why it was chosen: Guido van Rossum, the inventor of Python, works at Google, and they needed to limit the Python virtual machine to disable writing to the filesystem or other machine-specific tasks. Google’s announcement that they plan to support other languages, however, excites me. One of Google’s main languages is Java. The Java virtual machine (JVM) is a great piece of software; many languages have been ported to it including Ruby, our favorite here at Viget, and new languages have been written for it, such as Scala, one of my personal favorites. It is fairly trivial to use the JVM to sandbox these languages and limit their abilities to manipulate the machine as Google has done with Python. I expect to see JRuby supported soon, and a flood of languages thereafter. What this means for Rubyists is Google putting resources into developing JRuby, or even Rubinius, if they choose that route for a sandboxed Ruby.

The other exciting part about GAE to me is that they have a software development kit (SDK) to run GAE apps locally. This has already been ported to Amazon’s EC2, allowing you to run GAE apps there. BigTable, Google’s data store, is an interesting concept, and the development community has expressed interest lately in document databases, like CouchDB. With this SDK, we have been given a specification for the interface for BigTable. This is interesting: we may well see competing implementations of this non-relational database come out, allowing GAE apps to use any of them on non-Google machines. This can only result in innovation in database design, something which I have not seen a lot of in the last few years.

Patrick Reagan, Development Director, April 15, 2008 0

A little more than a year ago, we started something unprecedented in my career here at Viget: We made the decision to make some of our code freely available to the public.  The software was Tyrant, and while we haven’t put together an “official” release, this first effort was enough to spark an interest in releasing more of our work to the larger developer community.

A few months later, we reconvened to discuss ideas for Rails plugins that would be useful to other developers.  After a lively discussion and some good ideas, we left the meeting feeling invigorated with plans for a new VPS to host both a Trac installation and a public-facing Subversion repository.

Some of those original ideas died out, but others live on as active projects, and even more have been created as we encounter new challenges.  This is all part of the life-cycle of a healthy open source ecosystem, where new approaches to problems and changes in technology give way to better solutions. 

Continue reading "Open Source, Take Two."

Mark Cornick, Web Developer, April 04, 2008 0

A little over a year ago, the open_id_authentication plugin for Rails made its debut, intending to make OpenID authentication simple. And it did, for a while. But, like Rails itself, OpenID is a moving target and the OpenID specification, as well as the ruby-openid library, have both moved on to version 2.0 since then. The API changed enough that the plugin wouldn’t work with the newer library, effectively leaving applications that use it in the OpenID 1.0 world.

This all changed last Thursday. After much deliberation, a new version of open_id_authentication has landed, with support for ruby-openid 2.0.x, and OpenID 2.0 along with it. The upgrade process is pretty painless; a few database tables need attention (the new plugin will generate a migration to take care of those) and you’ll need to tweak any mocks you’re using in your tests/specs (you are using mocks, right?) It took me about half an hour last night. If you’re doing OpenID in your application, or if you think you want to, now’s a great time to take another look at this plugin.

Brian Wynne Williams, CEO & Co-Founder, October 17, 2007 1

Alex Iskold has a great post on Read/WriteWeb about The Future of Software Development. He does a good job of quickly summarizing the evolution of software development, and why older methods don’t work. In my view, his post title is misleading—he’s really describing the current state of software development for web applications.

Our work with start-ups over the years has pushed us to apply agile methods because requirements change constantly in an evolving business. As we meet new clients, we often go through a similar description of the way software development practices have improved over the years. Some key points from Alex:

The Old: Waterfall Model

“The idea was to construct systems by first gathering requirements, then doing the design, then implementing it, then testing, and finally getting it out the door in one linear sequence.”

“We have come a long way since then and learned a lot about making software. The Waterfall Model is now considered a flawed method because it is so rigid and unrealistic. In the real world, software projects have ill-defined and constantly evolving requirements, making it impossible to think everything through at once. Instead, the best software today is created and evolved using agile methods. These techniques allow engineers to continuously re-align software with business and customer needs.”

The New: Agile

“First, software has to embrace change. Today’s assumptions and requirements may change tomorrow, and software needs to respond to changes quickly. To meet the challenge, agile approaches advocate focusing on simplicity. Make the simplest possible system that satisfies today’s requirements and when tomorrow comes, be ready to adapt.

“The software systems created using agile methods are much more successful because they are evolved and adapted to the problem. Like living organisms, these systems are continuously reshaped to fit the dynamic landscape of changing requirements.”

Small Teams

“With a bit of discipline and a ton of passion, high quality engineers are able to put together systems of great complexity on their own ... ust a handful of great engineers can now successfully build systems of great complexity. Craftsmanship has finally come to software engineering!”

Alex also explains refactoring and testing, practices we apply here at Viget.

Agile isn’t perfect, particularly in a consulting environment, and I would stress lean teams over small team (though they’re often both). The future of software as Alex describes it is here now, and the best web products being built today apply these methods effectively.

Ben Scofield, Development Director, September 24, 2007 0

Patrick gave the low-down on our full Europe experience, but I wanted to call special attention to one session in particular: Tobias Lütke‘s “Outsourcing to Open-source”.

Lütke is one of the driving forces behind Shopify, one of the oldest and largest Rails apps on the web. His company only has five employees, though, and so was faced with a challenge: how can such a small team accomplish all of the various tasks that needed to be done? In building a merchant platform, you’ve got internationalization to worry about, dozens (if not hundreds) of different payment gateways to integrate with, and the worry of letting your clients customize their storefronts, just to name a few things.

Shopify solved these problems by open-sourcing the relevant components of their application. End-user customization is allowed by Liquid, which they released to the community and were receiving patches for even before their product launched. For payment, they built and open-sourced ActiveMerchant, bundling a few gateways at the start and relying on others to integrate the rest of them as they were needed.

One of the more interesting outsourcings they did, however, was related to the ActiveMerchant documentation. Shopify is a Canadian company; all of the core documentation is in English. Furthermore, it gets updated fairly regularly, so translating it and keeping both (or all of the) versions up-to-date would be onerous. Instead, Shopify has a system for allowing the community to take over maintenance of the translated documentation. Each language has a progress bar, tracking the current state of the translation - French might be 100% complete, while Italian sits at 80% until someone finishes it up.

Whenever the core documentation is updated, all of those completion statuses are updated - the 100% numbers get reduced to 99%, and so on. As a result, the translation maintainers know that something new has happened, and can go back in quickly and update their version of the content.

It’s a win-win strategy - Shopify gets free development time, and the community gets useful tools - and I think that many small teams and companies would do well to consider it.