Draconis Software Blog

Pulling Subversion Logs for a Single User

May 19th 2008 Posted to Networking, Operating Systems, System Administration by Steve Whittaker

There are many times during a project where I use the svn log command in order to see what has changed and to get a feel for the pace of development. It's also great when you're dealing with clients; you're only one command away from telling an inquisitive client exactly who did what task and when they did them. However, svn log is missing one important feature -- the ability to filter by a particular username. When I asked in #svn on freenode, they suggested I use the --xml option and parse the resulting output.

The following is what I came up with. It's a ruby script that uses the delightful Hpricot gem to parse the xml. It takes one argument, the subversion username that you wish to retrieve the logs for. I hope that it's useful for someone else! You can curl it from http://pastie.textmate.org/197763.txt if that makes it easier, too.

PLAIN TEXT
RUBY:
  1. #!/usr/bin/ruby
  2. require 'rubygems'
  3. require 'hpricot'
  4.  
  5. username = ARGV[0]
  6. if username.nil? || username == ""
  7.   puts "Please specify the username to cull log entries for."
  8.   exit
  9. end
  10.  
  11. puts "Requesting SVN log, this may take a bit."
  12.  
  13. doc = IO.popen("svn log --xml") do |f|
  14.   Hpricot.XML(f)
  15. end
  16.  
  17. entries = doc.search("logentry").find_all do |entry|
  18.   (entry/"author").innerHTML == username
  19. end
  20.  
  21. entries.each do |entry|
  22.   revision = entry.attributes["revision"]
  23.   author = (entry/"author").innerHTML
  24.   date = (entry/"date").innerHTML
  25.   msg = (entry/"msg").innerHTML
  26.  
  27.   puts "r#{revision} - #{author}"
  28.   puts "#{date}"
  29.   puts "#{msg}"
  30.   puts "-"*80
  31. end

A Rails Developer’s Thoughts On Using Grails

May 15th 2008 Posted to Rails by Costa Walcott

We strongly believe in using the right tool for the job.  While we currently think of Rails as the de facto choice when it comes to writing webapps, we'll always consider other options, such as one of the many other Ruby web frameworks, or going with another language such as Python.

Lately I've been looking for a chance to play with Grails.  Briefly, for those who aren't familiar, Grails is a web framework that uses the Groovy language - an agile, dynamic language designed for the Java Platform.  Grails was meant to use some of the main tenets of Rails (convention over configuration, "Don't Repeat Yourself", et al) while using Java web technologies like Spring and Hibernate.

Fortunately, I was finally able to find a chance to play around with Grails - as a simple way of "porting" an existing Java web application to a dynamic language and framework.  My reasons were the following, which I'd imagine are true for many other Grails developers:

  1. The ability to include straight Java code in the project meant being able to re-use existing code, especially if it was not directly related to the webapp.  For example, I was able to take a terse image generation function and drop it right into the project.
  2. Having the framework based on Spring, Hibernate, Acegi and Sitemesh meant there were fewer conceptual changes moving from the old code-base.  Working on the code I often felt that I was maintaining the original ideas while reducing the inherent verbosity of Java.
  3. The previous point applies to the interface code as well - the views in Grails use GSP, which is very similar to JSP and made porting the views almost trivial.
  4. Moving from another Java framework to Grails requires less of a "sell".  A Grails project packages as a WAR file no different from any Java project.  It will have all the positives (and negatives) of a Java app.

So, having used Grails a for a while now, how does it stack up to Rails?  Here a few of the things I enjoyed about Grails:

  • The GSP tags have the power of JSPs, along with a few features that make them simpler.  They've also added some tags that don't have equivalents in JSP, and are quite nice.  In particular, I liked using the "sortableColumn" tag, which generates columns in tables that handling sorting.  This is something I would like to use in Rails.
  • Grails does not currently use migrations (schemas are generated from field declarations in model objects), and while for some projects this could be an issue, it made development that much faster to add a few fields and have the database automatically be updated.
  • By default Grails uses a messages.properties file that contains message codes like validation errors and other generic error messages.  In some ways it's nice having all these messages in one place. Also, the validation errors use a default message per constraint type, which can then be overridden.

 As well as some caveats (I won't go so far as to say "problems"):

  • Grails uses some different terminology than Rails.  Models are "domain classes", validations are "constraints", and so on.  Not much of an issue, but it may take some getting used to.
  • The form helpers in views are not as sophisticated as Rails.  Less boilerplate code is generated for you, and more thought has to be put in to maintaining states and values of form elements.

Of course, there's nothing that Grails does that couldn't be done in Rails with a bit of extra code or a plugin, and I'd imagine for the most part this is true for Grails as well, so it's really more about simplicity and core conventions.  I'm still working on the port, so I'll be sure add updates as I get more experience.