Development Blog: Viget Labs

Tony Pitale, Web Developer, May 04, 2009 3

In my introductory post, I explained what Garb was, and how it could be useful to those wishing to get access to their Google Analytics data. In this post, I would like to introduce the latest version of Garb (0.2.1 as of this writing) and explain the many changes and new ways to use Garb to get at your data.

Getting sessions and profiles is still exactly the same.

  Garb::Session.login('username', 'password')
  profile = Garb::Profile.all.first

What's new in 0.2.1 is the way in which reports are built and results are retrieved. Check it out:

As a Report Class

  class Exits
    include Garb::Resource

    metrics :exits, :exit_rate
    dimensions :request_uri
  end

Getting the Results with a Class

  Exits.results(profile, :limit => 10,
                         :offset => 20,
                         :start_date => (Date.today - 30),
                         :end_date => Date.today)

  # With Filtering and Sorting

  Exits.results(profile) do
    filter :request_uri.contains => 'fun', :exits.gte => 1000
    sort :exit_rate
  end

One-off Report

  report = Garb::Report.new(profile)
  report.metrics :exits, :exit_rate
  report.dimensions :request_uri

  # With Filtering and Sort

  report.filter :request_uri.contains => 'fun'
  report.filter :exits.gte => 1000
  report.sort :exit_rate.desc

  # Getting Results

  report.results(:limit => 10,
                 :offset => 20,
                 :start_date => (Date.today - 30),
                 :end_date => Date.today)

The results returned from Garb will be OpenStructs with methods for each of the metrics and dimensions in an array.

  results.exits       #=> 1234
  results.exit_rate   #=> 0.20423810234
  results.request_uri #=> '/some/fun/url/to/a/page'

Overall, we feel that the improvements are solid and make more sense. Be warned: if you've used a previous version of Garb, then updating to the latest version will very likely break most of what was done previously. I hope everyone can find a use for this, and I encourage all to check out the project on Github and to read the documentation in the Wiki.

Tony Pitale, Web Developer, April 24, 2009 8

Since Google announced that they would be releasing an API for their de-facto analytics tools I was pained with the effort to contain my excitement. The results were a reporting tool and a new gem: Garb.

Continue reading "Introducing Garb: Access the Google Analytics Data Export API with Ruby"

Clinton R. Nixon, Development Director, September 24, 2008 4

I’ve been enthusiastic about the Scala programming language for a few months now, and this week’s been very exciting for the Scala community. A new Scala book from the Pragmatic Programmers was announced today, and Alex Payne from Twitter gave a presentation at C4 that strongly indicates Twitter’s writing part of their platform in Scala. Given this week’s news, I thought I’d explain why I’m using Scala, and what that means for the Lab.

Continue reading "Scala: The Adventure Begins!"

Clinton R. Nixon, Development Director, 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."