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.

Neat session state trick

Just thought I'd share a neat little bit of code for handling session state in ASP.NET.

The trick is to create a class that keeps it's own sessionstate, like this:

public class CustomerSession
{
    private string mName = "";
    private string mTelephone = "";

    // To enshure unique session key
    private static string mGuid = "PlaceGUIDHere";

    public string Name
    {
        get { return mName; }
        set { mName = value; }
    }

    public string Telephone
    {
        get { return mTelephone; }
        set { mTelephone = value; }
    }

    private CustomerSession() { }

    public static CustomerSession GetInstance(HttpSessionState session)
    {
        CustomerSession o = (CustomerSession)session[mGuid];
        if(o == null) {
            o = new CustomerSession();
            session[mGuid] = o;
        }

        return o;
    }
}

Then you can save data in session like this:

protected void btnSave_Click(object sender, EventArgs e)
{
   CustomerSession data = CustomerSession.GetInstance(Session);
   data.Name = txtName.Text;
   data.Telephone = txtTelephone.Text;
}

I heard about this in .NET Rocks! episode 82 where Richard Hale Shaw where speaking of his way of storing session state in a safe way. It's at about 54 minutes into the podcast episode if you want to check it out for yourself =)

Partial classes and regions

Just read this blog post about using partial classes to separate the public interface and the private and protected members, which is a great idea.

This got me thinking of a problem I faced this week when working on using the MVP pattern for windows forms development.

One of the forms had two very distinct areas. The left side contained lists to lookup information and the right side displayed the details. This seemed to me like the perfect place to use two views. Now to implement two views in the same code-behind file you'd want some way to separate them. Regions goes some way to solving this, but it's hardly ideal. I'd much rather switch between partial classes in different files than between regions.

Now here's the issue... if you create another partial class to a windows form (in addition to the .Designer partial) the Visual Studio 2005 IDE automatically thinks it is another designer form. You would think they had thought of this scenario?

Validation logic, security and the web

I just read a blog post by Rocky Lhotka where he discusses where to put the validation logic. This interests me quite a bit because it's one of those caveats I've found around ASP.NET and web development in general.

The problem with validation in a web environment
In web projects you often want validation to take place on the client (to reduce the number of post backs and give a better user experience), but it's not an environment you can trust.

How not to do validation
For obvious reasons, as stated above, you should not exclusively put validation on the client.

One way of solving it
I would agree with Rocky Lhotka that you should put validation in the business layer to begin with, and then duplicate that to the frontend to give the user a better experience. The main point here is that the business layer will be the deciding factor what gets though no matter if the UI validation isn't working as it's intended to.

Preparing for the future
Another important point Rocky touches on is that the UI is more frequently replaced than the business layer code, which gives some value to having the validation there no matter if it's implemented in the UI.

Security
One good rule I've come across is that you should treat everything coming from the user as potentially dangerous, and even better, do the same for anything that comes from the database. With this in mind, putting at least the critical validation in the business layer seems like a good idea.

Patterns and practices?
I'm looking into ways of building robust applications by using the MVP pattern (supervising controller) and TDD. I'll probably write more about that when I've gotten a bit more experience on the subject.

Weeks of .NET

This last month have been spent coding in .NET (mostly VB.NET) at my full time practice at Avancit AB. I thought I would share a few things I've come across in the projects I've been working on during that time.

T-SQL
I had a problem where I needed to get all mail addresses of all groups in a company except those in the current group. This was solved by the SP shown below:

ALTER PROCEDURE [dbo].[sp_GetMailAddressesByCompany]
(
 @intCompID INT,
 @excludeGroupID INT
)
AS
BEGIN
 — Get all addresses in company that are NOT in the excluded group
 SELECT addr.* FROM tblMailAddresses addr
  INNER JOIN tblMailGroupsToAddresses con
  ON con.intMailAddressID = addr.intMailAddressID
  WHERE addr.intCompID = @intCompID
  AND addr.intMailAddressID NOT IN
  (
   — Get all addresses in the excluded group
   SELECT addr.intMailAddressID FROM tblMailAddresses addr
    JOIN tblMailGroupsToAddresses con
    ON con.intMailAddressID = addr.intMailAddressID
    WHERE con.intMailGroupID = @excludeGroupID
  )      
END

BCP versus SqlBulkCopy
Another problem was where we had an application that needed to push tables from a client to a server effectively. The current version at the time used BCP which was run from a batch process and sometimes (but very rarely) failed.

I started to look around and I found that people where replacing BCP with SQLBulkLoad. I suggested we'd try it and we successfully implemented the transfer using it. As the whole process now took place inside the .NET application it was simple to setup a better error handling than was possible with BCP.

Macros
As for productivity, I've started to look into using macros in VS2005. The first macro I installed was one that reversed assignments. I know there are tools that do this, I think ReSharper has this ability, but I don't have it yet so a macro works just as good. You can find this macro at: http://www.codeproject.com/useritems/macroswapassignments.asp

DNR
Anyone still not listening to DotNetRocks are missing some great stuff. As I'm on a train or a bus for 3 hours a day I've listened to quite a few episodes in the last few weeks (1 to 40). Even the early episodes are great, they give a good insight into why things are the way they are and what is new in .NET 2.0 (as I started with 2.0, I don't have much of a reference as to the differences compared to 1.1).

TDD
Next week we're starting a project that will use TDD (Test Driven Development) for the first time within Avancit. It will be lots of fun and I'll probably write how that goes here later.