It took me about 3 hours to dig into the Trac code and learn enough Python to hack together a way to create a Design Spec snapshot using Trac. The problem is that we’re using the Trac wiki as our main information warehouse now. We wanted a way to be able to take a page in the wiki and create a snapshot of it to be added to a design specification. That way, at any one release we have a snapshot of the wiki pages that explain everything about it.

Since Trac already takes care of version control, it wasn’t too hard to conceptuallize that we just wanted another wiki page called DesignSpec that would just have a list of links to specific versions of different wiki pages. The design spec itself would then be version controlled as normal and we can just associate software release 0.0.1 with DesignSpec version 45. So, really all we needed was a quick way to add a link to the design spec from all the wiki pages.

I just added another button next to the Edit button that says Add to DesignSpec. The code that does the work is pretty simple:

if addToDS:
self.perm.assert_permission (perm.WIKI_MODIFY)
self.req.hdf.setValue('wiki.action', 'addToDS')
self.DS = WikiPage("DesignSpec", version, self.perm, self.db)
self.DS.set_content(self.DS.text + " * [http://ourIP" + self.env.href.wiki(self.page.name, self.page.version) + " " + self.page.name + "]\n")
self.DS.commit(author, comment, self.req.remote_addr)
self.req.redirect(self.env.href.wiki("DesignSpec"))


I’m just glad we don’t have lines of code watchers out there that for some reason or another equate productivity with how many lines of code you write. It would be hard to justify 7 lines of code taking 3 hours to write.

Here is my Trac modification to have collapsible title indexing. I used this script as the base. The following is my new execute method in TitleIndex.py:

Given the speed at which our wiki is growing, we’ll need a more efficient way or indexing all the pages. Right now Trac just lists every page one after another. The idea was proposed to have a collapsible tree/list so that we can expland and contract the lists based on their prefixes.

I borrowed Stephan Diehl’s prefix finding script and started hunting around for an implementation of a CSS only collapsible tree. I found numberous JavaScript implementations but nothing CSS only. I shy away from using JavaScript to do things that CSS is better suited to be doing. Then I found out that css hyper-display: folding is what I’m looking for but doesn’t look implemented so far as I can tell. I poked around with a JavaScript implementation but it wasn’t elegant enough for me so I may just write my own JavaScript to handle it.

Dispite the direction our project is heading, .NET, I’ve just set up a Gentoo Linux server running Trac. There had been some talk around our team about needing a local web site for our team. I figured a wiki was the best place for it and took the initiative to set it up. Trac is pretty cool. Other than a wiki, it comes with a ticketing system and integrates with your Subversion repository. I’ve set it up for my own side projects as well. I wanted to use Collaboa but it wasn’t being nice to me when I tried to install it.

Most of our current codebase is written in Perl with some CMMI level 5 compliant and with it comes a whole slew of metrics that need to be collected and analysed. The term “metrics” is used as a statistical measure for the most part. Business folks love throwing words around that really don’t mean what they think they mean. More on that later.

The point is that I’ve been tasked to write tests for a Perl script that queries our database for some records. I’ve had very little experience creating Perl scripts from scratch but that hasn’t been a problem. I also know that there must be testing frameworks for Perl out there that would make my life a lot easier. I just haven’t spent the time investigating them. With that said, I’m not using a framework. I want some way to abstract the database stuff from the testing code so I wanted to create an object that handles all the database stuff. The Code Project has a good post which starts off with Camel POOP which gives a pretty good intro to object-oriented programming (OOP) in Perl.

Since I was abstracting out the datbase nonsense, I wanted some way to be able to insert data into the database without having to construct an SQL query by hand each time. The solution I found was to create a method that takes in a hash of all the data values for the row to be inserted. Being a Perl noob, I found Alex Batko’s post on hashes.

Here’s the code I came up with:

UPDATE:
I forget to mention why this is of any use to me. It allows me to insert test records into my database easily and have it very readable. Ultimately, it would be nice to put all the test records into a fixture file like how Rails does it. It makes it nice and clean that way. However, I don’t want to waste time trying to decide on how to represent the data in the fixture and then how I’m to parse it. For now, this is easiest for me. So when I use this method I do something like this:

Let me start off by saying the project I work on suffers some major flaws from lack of any testing framework to a lack of any design structure at all. For the past few weeks, I’ve been tasked to research our options and find a framework that fits our particular project.

I searched long and hard and there isn’t any doubt in my mind that Ruby on Rails is the best framework available right now and it fits our project perfectly. There’s just one hangup for the team: Ruby. Most people haven’t even heard of Ruby (head in the clouds or they just aren’t web developers). Today in the morning, the boss told me we were going with Rails. The word spred quickly and within minutes he was hounded with objections. The Java kiddies don’t want to learn a new language and want to have Java on the resume. Other folks would prefer C# to Java. And everyone else, I’m not sure they know enough about web development to really make a good arguement one way or another.

I was tasked to find the best framework for our environment and I did. Later in the day, I was told we were going with Java due to popular demand. Basically the Java guys threw a fit and said they’d quit because it won’t benefit them to put Ruby on Rails in their resume. I say screw them. The direction of the project shouldn’t be determined because of what someone want’s to put on their resume. It should be determined based on facts and the facts are that Ruby on Rails (RoR) is hands down the best framework. There really isn’t any argueing that. What people are argueing is that Ruby isn’t popular so we shouldn’t use it.

Corey mentioned that we could still benefit from the power of a scripting language and use a Java framework. He was talking about Jython or JRuby. Since the Ruby ship has apparently sailed, Jython is looking better and better. Alex Greif has a blog post about using Spring as the framework using Jython for the controller actions. Thomas Risberg talks about something very similar in his blog. Let’s take that one step further and integrate Jython into Velocity as mentioned by Jason R. Briggs. This essentially takes Java out of the picture as far as development is concerned. Combining these two approaches will allow us to use a Python for both the view and the controller. Of course there’s still going to be all those XML files to deal with but I suppose we’ll have to live with it.

I tried to slowly introduce Ruby to members of the team but when I did they just seem dumb founded at where to begin and didn’t really even seem to put much effort into learning something new. I think the Python approach might be an easier sell to the bosses since they’re Python programmers and the Java guys are going to have to learn a new language and develop with it whether they like it or not. Good developers shouldn’t be affraid to learn new things and those that are certainly shouldn’t have an influence on major decisions. I’m no expert at Ruby on Rails (RoR). I only looked at it seriously for about two weeks but I certainly feel confident enough that I can go build whatever I need to with it. In fact, I already had a prototype for our project built in Rails which I did in two days. It’s practically fully functional.

In the end, the decision needs to be concrete by this Friday. The funniest thing is that I’m tasked to fix up the trade study document justifying our position. I wonder how that’s going to look in the end? I’ll try to post an update as to our direction next week when all is said and done.