I have run into one problem though – running it under Spork generates no results! As far as I can tell, this is a problem with the way Spork caches your application files. SimpleCov uses the Ruby 1.9 built in profiling features, and either 1.9 or Spork need the files under inspection to be loaded after the profiling has started. Unfortunately your application files aren’t reloaded when you are using Spork, that’s kind of the point!

Some people seem to be able to get away with merely turning off application file caching in config/environments/test.rb, but that didn’t work for me. Instead, I have come up with a different solution: Only turn on code coverage reporting when I run RSpec outside of Spork. At the top of spec/spec_helper.rb I have the following block:

1
2
3
4
5
6
7

if(ENV["RUN_COVERAGE"])
  require 'simplecov'
  SimpleCov.start 'rails' do
    add_filter "/spec/"
  end
  puts "Running coverage tool\n"
end

That way I can run RUN_COVERAGE=true rspec spec/ in the root of my application directory, and RSpec will run with SimpleCov enabled. As an added bonus, the code coverage metrics aren’t running on every test run, so my tests are faster!

One thing that bothered me though was the repetition in my forms – the format for showing labels that line up nicely next to the form elements was the same across all input types, and so was the error handling. This got me thinking: why should I retype all of this when the Rails FormBuilder class is already doing half the work? Surely I could just override some of the methods to make this work?

I needed to learn more about Ruby metaprogramming to get it to work – I still wanted the core functionality of the default rails FormBuilder, just with some extra DOM nodes wrapped around it. Ruby lets you redefine methods at runtime, but also allows you to alias the old methods so you can refer to them inside your new version of the method. So I ended up writing a method that does the Bootstrap boilerplate DOM wrapper creation and calls the original method to generate the input element itself.

I still haven’t overridden all of the FormBuilder methods because I need to actually test them (and I don’t have a use for them yet), but the basics are here in this Gist: https://gist.github.com/1236567. The methods I have overridden are in basic_helpers, the ones that output multiple inputs are in multipart_helpers. The great thing is I have only had to add method names to those two arrays as needed – none of the input types have needed special casing. This might not be the case for all of them, but one can only hope. If you do find this useful, or want to add and test some more of the helpers, please form my Gist and leave me a comment here.

I’m going to talk about how the extension mechanism works. It uses the Managed Extension Framework (MEF), which you can read about here: http://www.codeplex.com/MEF. You don’t need to know a lot about MEF to write an extension – in fact you can get away without knowing anything apart from how to download it and which attribute to use on your extension class.

To create a custom graph processor, you’ll need to create a new Class Library project in Visual Studio. This project needs to reference Quickgraph.Graphviz.dll, System.ComponentModel.Composition, and DependencyViewer.Common.dll. The first two you can get from the lib directory in the Dependency Viewer project, and the Common dll you can get by building the DependencyViewer.Common project. Once you’ve got your project up and running, create a new class that implements DependencyViewer.Common.Interfaces.IGraphProcessor.

The IGraphProcessor interface is pretty basic so far. These are the important methods:

• PreProcessGraph
  • This method lets you change formatting options on the graph before the other graph elements are processed. You could use this to set the size, background colour, etc.
• ProcessEdge
  • This method lets you change formatting options on a dependency connection after the defaults have been set (there aren’t any defaults yet though).
• ProcessVertex
  • This method lets you change formatting options on a project node after the defaults have been set. By default the Name is set to the name of the project and the shape is set to Ellipse.

You can have blank implementations of any methods you don’t need.

To get the main application to find your custom graph processor, you just have to register it as an implementation of IGraphProcessor by adding the Export attribute to your implementation. So in this case, you’d put [Export(typeof(IGraphProcessor))] on your class.

Once you’ve done that, build your project, copy the dll into the directory where you are running the main application, and then the magic happens. MEF will automatically pick up your implementation when you next render your solution.

There is an example implementation in the Dependency Viewer project called TestProjectProcessor. It finds non unit testing projects that reference NHibernate and colours them a different colour, so that you can see what projects refer to your data projects. I got the idea from Melle Koning’s blog post on the subject here.

Remembering I had seen some argument over whether using a generic repository was a good idea or not, I started searching around and found quite a few blogs saying it was a bad idea. They made sense, and one blog had a great solution: Create a Repository<T, U> abstract class for common CRUD style operations, inherit your specific Repository from that, and only expose meaningful methods in your interface to client code. The benefits of this approach are many – your client code can only see methods that are applicable to each model class, you don’t have to duplicate your common CRUD operations for each model class, and it is easy as pie to unit test.

This last point is the one worth mentioning in my books. The great thing about separation of concerns is it should make things easier to pull apart for unit testing. Because my Repository methods have meaningful names, and are pretty fine grained, my mocking setup looks almost readable. It is immediately obvious from reading my tests that TaskController.List(5) should call ITaskRepository.GetLatestTasks(5). Not only that, but most of the Controller actions have been reduced to “Get this from Repository, return to View” or “Save this thing to the Repository”. They are small, obvious methods, and that makes them easier to test, and easier to maintain.

I thought it would be pretty easy to develop for as Python is interpreted, I thought I could just edit text files on the phone and run them to test them out. Turns out you can’t do that (not easily anyway), you need to package them on your computer, then upload the package to the phone, then install it, then run it. That killed that idea.

I looked at the Symbian emulator, and the PyS60 team have a mod for it that installs the python runtime so you can just run script files on the emulated phone. “This is great!” I think, before actually trying it.

For starters, the python runtime doesn’t work in the emulator when the emulator is running on Windows 7 x64 – damn. I have a VPC image with Windows XP on it though, so I fire that up, install everything, then try run it. The emulator crashes after about 15 seconds of loading.

After browsing the Nokia forums for a while, I find out the problem. VPC is actually connecting to the virtual machine over RDP, and so the audio drivers are the RDP Remote Audio drivers.

What do audio drivers have to do with a phone emulator I hear you ask? Good question, but it is one the Nokia forum dwellers have no answer for. Many people have complained that the Symbian Emulator does not work when connecting to the machine hosting it via RDP. There are other issues with particular sound card drivers or applications also causing it to crash. This is a prime example of bad error handling. Why, if the audio part of the emulator cannot work with some drivers, does it crash instead of continuing without audio?

So that brought down my plans for making millions of dollars from fart applications for Symbian based phones.

Once I got used to the larger monitor I had a pretty productive day though. The T240 is a decent monitor for developing on, judging from one day’s usage. Text is clear, and after a little tweaking the colour looked about right, enough for my purposes anyway. Not to mention it is a nice looking monitor. All in all, it was well worth the money I/the business spent on it.

I got the idea from Ayende’s blog, kindof. His blog is quite interesting to watch, because it is made up of lots of small updates. It almost seems like more of a note taking system than a blog sometimes, in a good way. For myself, I tend not to write blog posts because they take a little longer than I’m willing to give during the day to write, so Twitter’s 140 character limit could work for me. It’s just a trial anyway, if it doesn’t work out I’ll dump it.

So how I think I’ll work now is: Post short messages to Twitter like reminders, helpful hints, and status updates, and post longer information like information about side projects and interesting topics on my blog.

If anyone wants to follow me on twitter, here’s my page: http://twitter.com/jamiepenney. Be aware that there will be a bit more personal stuff there, my blog so far has just been technical but I’ll probably use Twitter for personal and work messages.

Enough talk, here’s the GitHub project: http://github.com/jamiepenney/ook-sharp

You’ll need the latest F# CTP installed to open this project in Visual Studio 2008.

My tool takes a visual studio solution, and produces a PNG image showing the dependencies between the projects in that solution. Pretty basic stuff, but it involves:

1. Parsing a Visual Studio .sln file.
2. Parsing the .csproj files referenced in the .sln file. (I don’t think it is C# specific but have not tested it on other project types).
3. Creating an in memory representation of the solution structure.
4. Creating a graph in QuickGraph to represent that structure.
5. Creating a dot file for GraphViz from that graph.
6. Pass that file to GraphViz and display the output.

This results in something like this:

The source code is here.

Updated: I’ve put this project on GitHub, and added Melle’s changes to it. You can find it here.

Feel free to do what you like with it, it only took me about 3-4 hours to get it all working. However if you actually use it as part of another project, please leave a comment.

You’ll need the latest version of GraphViz, which can be downloaded from here: http://graphviz.org/Download_windows.php. I’ve been using the development snapshot, but the stable release should be fine. When my tool first runs, it’ll ask you for the location of graphviz. You need to specify the location of dot.exe, which by default is in %Program Files%\GraphViz 2.21\bin.

Standard disclaimer: I’m not responsible for anything that goes wrong when using this thing. You have the source, you should check it out before running it. If it wipes your system and kills your firstborn child feel free to let me know, but don’t expect me to do anything about it.