NCover in a relative path

Just a small note for anyone trying to get NCover to run in a relative path.

Make sure you include CoverLib.dll and register it (run Regsvr32 CoverLib.dll).

I had errors where it would run on one computer but not on another and that when it couldn't find the dll it's simply froze after the unit tests had run. I'm using v1.5.8.

Interaction design, UCD and Agile

Today I was at yet another seminar, this time at Agical about how UCD combined with Agile methods does work and how it can be beneficial.

It began with Illugi Ljótsson och Eric Idebro describing the "write a big document and throw it over the wall"-problem and that UCD and Agile development methods weren't that far apart if they where only allowed to work together, iteratively.

To allow for this they would have an interaction designer in their scrum. In a 4 week scrum the interaction designer helped with usability and each friday he did user testing to get feedback for the coming week.

I got the impression that this kind of feedback would work and that it would help a great deal to have that kind of expertise at hand during development.

Do we really need a 4 step publication routine with document comparison if all the users really need is a way to get text out on the web quickly?

They also made the point that what the product owner asked for and what the users actually needed where quite some way apart. When using this method you have more material to help guide your decisions on what to build in addition to making the application more user friendly.

Andy Hunt: ”How Hard Can it Be?” at Valtech

Today I was at a seminar by Andy Hunt called "How Hard Can It Be?" at Valtech (Stockholm, Sweden).

It was a great and very funny seminar and I recommend anyone that has a chance to go to the next one.

One thing that got to me was the discussion about complexity... that is accidental complexity and essential complexity. One example he used was the way a language like Java could isn't very intuitive for people new to development compared to a language like Ruby due to accidental complexity.

In Java you would need "public static void Main(.... System.out.println(..." for the basic Hello, World example, whereas in Ruby you would type 'puts "Hello, World!"'.

IDE's do us a great disservice in hiding accidental complexity by using macros to autogenerate code that is required by the language, but probably isn't of any value for the task at hand.

The point of it all is that when the domain is complex, we have essential complexity, but we should avoid accidental complexity, extra code that creates noice, making the code less readable without adding any value.

He also hinted on the irony of the waterfall method that it wasn't supposed to be used the way it has and in fact the document describing the method was a example of a flawed, non-working model of development.

Some time ago I found a really nice book that uses this way of avoiding accidental complexity that Ruby does for introducing newcomers to programming, Learn to program (pragmatic bookshelf).

On the way home I listened to a podcast about RoR, the Ruby on Rails Podcast episode featuring Stuart Halloway. I've only listened to one episode so far but it was great :), got me thinking of contributing a bit more to Open Source.

Degrading link_to_remote

I've been learning RubyOnRails and I noticed that the 'link_to_remote' helper didn't degrade gracefully...

Here's the fix I used (Inspired by this blog post).

(in helpers/application_helper.rb)

  def link_to_remote(name, options = {}, html_options = {})
    unless html_options[:href]
      html_options[:href] = url_for(options[:url])
    end
    
    link_to_function(name, remote_function(options),
                                         html_options)
  end

Just keep in mind that this uses a HTTP GET when javascript is disabled. A HTTP GET should not have side effects. I can't think of a good way to do a HTTP POST from a link (trigger a form-post) without using javascript.

Dojo at Agical

Yesterday I was at a dojo at Agical in Stockholm.

The idea of a dojo is to as a group drive out the design of a piece of code using TDD. The goal is to practice TDD outside of real live projects.

We used a method called randori that meant that we worked on the code as a pair, describing to everyone what we did and switching out one of us every now and then. It was a trilling experience to say the least, if only too short! I'm definitely going to go to more of these dojo's :)

When we where done we got into discussing the differences between BDD and TDD. What does it really mean to drive your development based on behavior?

The sense I got from it was to not let the testing run away with you. To focus on the real behaviour. What is the point of creating tests for code that define a behavior that you don't have any story for? Excessive error handling can be a suspect in this category.

Aside from that I also got some repetition on the TDD cycle: Red, Green and Refactor. Focus on passing the test, save all refactoring for when it's green. To get ahead of yourself is like premature optimization, tempting but probably not a good idea...

The discussion then continued into whether Code Coverage is a good metric from a BDD perspective. When doing BDD/TDD the number will be high, but it will not tell you if you implemented functionality that was really required or not. You're goal is to solve the problem at hand, not achieving full coverage.

But there are uses for it, one opinion where that the coverage serve as well needed positive feedback for the developers, another that it can be a great tool for finding uncovered code that ought to be run by a test.

I wish that I'd had the time to stay after the dojo, but it was late and I had an early morning :(. It's not often that you get the chance to meet people that actually know their way around these concepts in real life!

Just a heads up on some Opera browser behavior...

I just discovered a bit of a quirk of Opera (9.01). When you read the .value of a text field and the text field contains something like "Hello <b>world</b>", opera returns "Hello <B>world</B>". I did not find any way of fixing this, except to not assume lowercase input (which seems obvious to me now :). However, I found this interesting blog post about this upcase behavior and other similar things. Just hope this post can help someone avoid the premature assumption that the browser would return what's actually there :).

TinyMCE inside of an ASP.NET Ajax UpdatePanel

Yesterday I went hunting for information on how to get the
web WYSIWYG editor TinyMCE to work inside of an ASP.NET UpdatePanel.

There are a few solutions for this on the web, nothing near as complete as Jesper Lind's post (Swedish), but even that failed to work. I replied to the post asking if he had some simple example that he could show and as a result we now have this complete example.

Here is a VB.NET version of Jesper's example I made when adapting the code to work in my VB.NET project at work.

Update: 2007-07-30
Having had some experience with using this I'd highly recommend that you use webservices as the editors inside of any non-trivial updatepanel setup can become quite slow to reload.

To use TinyMCE on an Ajax form, load TinyMCE at page load as usual, but run "tinyMce.updateContent(text-area-id)" after you load text into the textareas so that it is displayed. If you have any problems with IE6 not updating the content, check this thread out. Also run tinyMCE.triggerSave(true, true) before saving so that TinyMCE copies text back from the editors.