Marcin Hoppe

MSDN Tester Center

2007-10-26T07:09:08Z

MSDN has just opened a new site for testers: MSDN Tester Center. It looks promising (there are a couple of videos, some articles, and lots of links).

I think that test engineer role is still not appreciated throughout the industry. That's a pity because it makes it hard for developers to choose a career path in testing. I think Microsoft got it right: their SDET positions attract lots of talented people. I hope more companies will follow this path in the future.

Visual Studio as an editor. Only an editor

2007-10-02T12:45:23Z

Today I learned how Jean-Paul Boodhoo structures directories in his projects and compiles his code with NAnt. I use a similar approach so the posts reinforced my confidence that this is the right way to go (one might even say that such a layout is very ALT.NET-ish). What I liked the most, however, were not the folder structure ideas themselves, but an idea to use Visual Studio merely as a code editor (with ReSharper it might even be a really good editor).

The benefits, for me, include:

reduced compile time for large projects,
flexibility of code structure and layout,
ease of including and excluding folders with source code to compile for different targets (you can easily exclude test code, for instance).

What Jean-Paul suggests and that I haven't tried out yet is to use a single C# project to keep all the source code files (including tests, if I understood him well) and making a developer responsible for clean separation of components. It's worth noting that it doesn't force an entire project to be compiled to a single assembly. NAnt is really showing its flexibility in tasks like these.

I had a chance to use such an approach on two projects that I have been on and my experience is that delivery of those projects was a superior experience. Automated testing and deployment are much easier to set up when one abandons Visual Studio.

By the way, have you read an article "Does Visual Studio Rot the Mind?" by Charles Petzold? Absolutely fantastic piece of well-thought Visual Studio criticism.

P.S. Did anybody except for me noticed that Scott Hanselman is now working for Microsoft?

Jon Skeet writes a book: "C# in Depth"

2007-09-20T20:18:00Z

Have you ever been to the microsoft.public.dotnet.languages.csharp newsgroup? If you have been there for more than a few moments you must have noticed an individual answering even the toughest C# questions like crazy, Jon Skeet. Jon is a C# MVP and maintains a blog and a collection of very interesting articles about various aspects of C# programming. Two things you can always expect from his posts are thoroughness and accuracy, both taken to the extreme.

A couple of days I noticed that this fine gentleman is working on a book entitled "C# in Depth", which is going to be published by Manning (at work I use one of their books and I must admit that it is one of the most useful books that we have at the office). Jon's book is targeted at C# developers who have not yet mastered the entire set of new features introduced in C# versions 2 and 3 (including LINQ magic!). It's interesting to see a book devoted to C# programming language and not really to .NET class libraries or the runtime. I personally lacked such a book on my shelf.

On a similar note, an unified C# 3.0 language spec was recently published. It is a definitive document for anyone who would like to master C#. I find this spec to be extremely well written, very readable and very informative. I even started to think about reading it cover to cover (well, maybe except for the grammar).

New Job and New Topics

2007-08-10T08:07:00Z

After about 3 months of silence I'd like to return to blogging. There are a couple of things that happened during my months of blogging silence. I also have a few neat ideas to implement here on this blog.

First and probably the most important thing that happened to me was a job change. I began may short career as a software developer at a company that can be described as small or medium (we are talking about 100 people here) and that company was later bought by a big international corporation (we are talking about 15 000 people here). Both companies had their pros and cons but I definitely enjoyed the smaller company more. And now I am in a small (or medium) company again!

As of August 1, I am a software engineer at Kainos, the largest IT consultancy in Northern Ireland. The company exists for over 20 years and is very mature and has very serious approach to quality. ISO, TickIT, you name it :). The headquarters are based in Belfast and I will be working in Polish branch of the company that opened a couple of days ago in the city I live in, Gdansk.

What is the most important thing for this blog is that I have shifted my focus from mainly business logic (which, by the way, was a terrific way to get hooked on TDD) to more technology focused position. I have joined the SharePoint team and for the last two weeks (well, almost) I am learning MOSS 2007 development. SharePoint seems to be a very exciting technology and gets a lot of buzz nowadays. It's a fresh product and there is much to be written on it.

The second thing is that I have never been really very much into Web development. I decided to change and learn some things about the Web and underlying technologies. It seems to me that now we have quite exciting times for this. JavaScript has its renaissance now, probably due to things like AJAX, Gmail and Firefox.

Some of you may think that it is too late for this kind of stuff and that this is no longer cool and fresh. I found it interesting only when it matured and went mainstream. I think it might be an interesting perspective.

In the end I'd like to mention that I opened a second blog, Just Curiosity, which will be less technology focused and less in-depth. .NET and development topics will remain the domain of this blog.

How to keep List sorted?

2007-05-15T08:46:00Z

Recently I ran into a need to keep a list of integers sorted in ascending order. The list was used as an internal representation of a set, so I didn't have to create a new class implementing IList or anything similar. The whole issue was to implement adding new elements properly. Of course, I started with writing a routine to find a proper place for a new element, move all subsequent elements and so on. This is quite a bit of code and it is easy to make a mistake here....(read more)

TDD Tip: Leave a Broken Test

2007-04-05T06:28:00Z

How do you know where to start when you sit in front of your screen in the morning? Half of the developers population will probably start with a cup of coffee, some will visit Slashdot or Channel 9 (that's me!). There is, however, a breed of developers, that starts by checking out the fresh code and gets to hacking right away. If you are this kind of developer, this little tip is for you. Procrastinators already know what to do.

How often do you as yourself a questions like: what do I start with today? Or what was I working on yesterday? How often do you browse your post-it notes to pick the next task and you're lost? If you often find yourself in situations like these, there is a very helpful tip I learned from Kent Beck's Test Driven Development: By Example. The trick is: leave a broken test. The last thing you do before you turn off your screen is to write a test that fails. Name it appropriately so that you know what behavior it tests and make it fail. Write a failing assert or just leave Assert.Fail call. When you sit in front of your IDE next morning and start with running your tests, you will have a clear sign of where you finished yesterday and what you should implement next. This is especially useful to have a test like this on Monday. I don't work during the weekends, so I always find it very helpful to restore the context in a couple of seconds.

There is a little issue in this method and this issue is teamwork. By no means, don't check in your failing test as others may think it is... well, a broken test. A bug. Something they need to fix ASAP (if you have loose code ownership). They will either blame you (not very likely but possible) or fix it themselves. Either way, leaving a broken test committed into the source code repository is clearly not a good idea. If you have any comments or ideas about this tip, please share!

Persisting Domain Objects with the Serialized LOB Pattern

2006-11-08T11:52:00Z

I have been recently working on a pet application that downloads stock quotes and a bunch of fundamental data from Yahoo! Finance and puts the data into a nice little domain model. After some development I got tired of downloading the data with each run of the application. It really made testing and playing with the app a little bit annoying. Since this is a totally personal project carried out just for the purpose of good fun and exploration of market data available on the Web, I haven't paid much attention to design patterns, layers and other enterprisey stuff. Somewhere in the middle of development it turned obvious that I had to add persistence to an application that was not designed up-front and not prepared for adding such a functionality.

What saved me was a pretty well developed domain model with lots of small and well defined classes representing quotes, dividends, splits, key ratios and other pieces of the stock exchange mini-world. After a little bit of investigation I managed to change my application so that it had a single root object called Universe that held references to every other single domain object and was a perfect candidate for serialization. Then all I had to do to make my domain model ready to be persisted to a database was to decorate each of the domain classes with the [Serializable] attribute.

The next step was obviously to design the database schema. As the only thing that I was going to store in the database were big chunks of binary data (my serialized graphs of domain objects) that had some sort of identifier. The first idea that came to my mind was:

CREATE TABLE [Objects] (
    [ID] VARCHAR(50) PRIMARY KEY,
    [Bytes] VARBINARY(MAX) NOT NULL
);

and it turned out to satisfy all my needs.

Now all I needed was a database gateway that would enable me to save objects to the database, read and delete them. Reading objects from the database turned out to be a two step sequence of an embarrassingly simple SELECT statement and very rudimentary deserialization:

public static T GetObject<T>(string id) {
    const string SqlStatement = "SELECT [Bytes] FROM [Objects] WHERE [ID] = @id";
 
    T ret = default(T);
 
    byte[] bytes = null;
 
    // Read bytes from the database.
 
    using (SqlConnection conn = new SqlConnection(ConnectionString)) {
        conn.Open();
 
        SqlCommand cmd = new SqlCommand(SqlStatement, conn);
        cmd.Parameters.AddWithValue("id", id);
 
        SqlDataReader reader = cmd.ExecuteReader(CommandBehavior.CloseConnection);
        if (reader.Read()) {
            bytes = reader.GetSqlBinary(0).Value;
        }
    }
 
    // Deserialize read bytes.
 
    if (bytes != null && bytes.Length > 0) {
        IFormatter formatter = new BinaryFormatter();
 
        using (MemoryStream s = new MemoryStream()) {
            s.Write(bytes, 0, bytes.Length);
            s.Seek(0, SeekOrigin.Begin);
 
            ret = (T)formatter.Deserialize(s);
        }
    }
 
    return ret;
}

Deleting objects from the database was even simpler:

public static void DeleteObject(string id) {
    const string SqlStatement = "DELETE FROM [Objects] WHERE [ID] = @id";
 
    using (SqlConnection conn = new SqlConnection(ConnectionString)) {
        conn.Open();
 
        SqlCommand cmd = new SqlCommand(SqlStatement, conn);
        cmd.Parameters.AddWithValue("id", id);
 
        cmd.ExecuteNonQuery();
    }
}

Saving objects involved two steps: deleting the old version of an object (in case we were overwriting some old version of the object graph) and then inserting new BLOB to the database. Here goes the last snippet:

public static void SaveObject<T>(string id, T obj) {
    const string SqlDeleteStatement = "DELETE FROM [Objects] WHERE [ID] = @id";
    const string SqlInsertStatement = "INSERT INTO [Objects]([ID], [Bytes]) VALUES (@id, @bytes)";
 
    byte[] bytes = null;
 
    // Serialize the object to bytes.
 
    IFormatter formatter = new BinaryFormatter();
 
    using (Stream s = new MemoryStream()) {
        formatter.Serialize(s, obj);
 
        bytes = new byte[s.Length];
 
        s.Seek(0, SeekOrigin.Begin);
        s.Read(bytes, 0, Convert.ToInt32(s.Length));
    }
 
    // Delete any previously existing object with the same id
    // and save the bytes to the database. Execute both
    // statements in one transaction.
 
    using (SqlConnection conn = new SqlConnection(ConnectionString)) {
        conn.Open();
        SqlTransaction trans = conn.BeginTransaction(IsolationLevel.Serializable);
 
        try {
            SqlCommand delCmd = new SqlCommand(SqlDeleteStatement, conn, trans);
            delCmd.Parameters.AddWithValue("id", id);
 
            SqlCommand insCmd = new SqlCommand(SqlInsertStatement, conn, trans);
            insCmd.Parameters.AddWithValue("id", id);
            insCmd.Parameters.AddWithValue("bytes", new SqlBinary(bytes));
 
            delCmd.ExecuteNonQuery();
            insCmd.ExecuteNonQuery();
 
            trans.Commit();
        } catch {
            trans.Rollback();
            throw;
        }
    }
}

When I got back to the office the next day I picked up Fowler's Patterns of Enterprise Application Architecture and learned that my beautiful and elegant solution already had a name: the Serialized LOB pattern. How sweet :).

By the way, extracting relevant data from HTML markup is itself a very interesting topic and recently .NET community was equipped with a very powerful tool that makes it a whole lot easier to parse Web pages: the HTML Agility Pack library, available for free along with the source code at CodePlex. This is so interesting and so exciting that it probably deserves a post of its own.

Designing Web Services: Messages vs RPC

2006-09-28T14:06:00Z

The most natural way to create Web services in ASP.NET (this technology is often referred to as ASMX) is to write a facade class or interface using pure OO approach and decorate the class and the public methods with proper attributes (WebServiceAttribute and WebMethodAttribute, respectively). For simple Web services, we may even use ADO.NET DataSet objects (or strongly typed data sets) passed as arguments or as a return value. While this is probably fine for small Web services acting mainly as a very thin gateway to the database, it may not be appropriate for large enterprise Web services that interact with rich business logic layer.

There is also a mismatch between the underlying technology (SOAP and WSDL) that is very much message oriented and the most popular usage style which basically utilizes Web services as yet another RPC (Remote Procedure Call) technology. This kind of approach to designing distributed systems may lead to tight coupling not only between the service and its clients but also between the service and the business logic layer (it probably has something to do with the curious temptation of some developers and architects to transfer serialized business entities across the wire).

The approach one should take when designing new enterprise-class Web service is to think about it in terms of message exchange rather than in terms of distributed objects as we often do now. This may lead us to a whole new world of Web services that support message-based security, asynchronous message exchange scenarios and long-running business processes.

I will try to blog more on topics related to Web services quite often. This post was meant to make a gentle introduction to the way I perceive Web services technologies and their usage. Next posts will probably vary from architecture level musings to code-rich technical posts. More to come soon!