Claudio Lassala in Software Development: Blog

Up for a geek dinner in Houston?

Tue, 26 Aug 2008 17:21:46 GMT

In case you haven't heard of it, check out information about Houston Alt.NET Geek Dinner #3. Topics we're likely to be babbling about are:

Code Clarity / Fluent Interfaces / Code without comments
Model View Presenter pattern
Continuous Integration

If you feel like eating pizza and talking with other geeks, make sure to join us there.

C# In Depth - Great book

Tue, 05 Aug 2008 19:17:30 GMT

Back from my visit to Brazil, and ready to start blogging again. :)

During this last trip I've read the following book:

C# in Depth: What you need to master C# 2 and 3
by Jon Skeet

Read more about this title...

I decided to read it because of JP's review. After reading a few pages, I knew I had to read the book cover to cover, and that's what I did. The book covers briefly some key aspects of C#, important things introduced in v2.0 (such as Generics, anonymous delegates, etc.), and then the new features in v. 3.0.

For me, the book was a great refresher for things I already knew, as well as it gave me a lot of insight on things I certainly didn't know (such as a more thorough understanding of expression trees, lambda expressions, etc.). I'll definitely have to go back to a few chapters in order to fully grasp some of the things presented there.

I believe this is a must-read book for any C# developer.

Speaking at the HDNUG in August

Thu, 17 Jul 2008 13:34:26 GMT

I'll be speaking at the Houston .NET User Group on August 14. This is the abstract:

Refactoring, Patterns, new language features, code quality, and more!

Command design pattern, Lambda Expressions, Extension Methods, fluent interfaces, refactoring, test-driven development, writing elegant code, and more. This session will cover a little bit of many things learned from projects I’ve been working on. We expect every attendee to learn a few tricks that can be applied immediately, and also to feel encouraged to go out and research more on whatever area appeals the most. Besides learning those things, we really hope attendees will start thinking and approaching their code in a different way.

I like this talk a lot, and got some pretty good feedback from people who have seen it before, so I'm certainly looking forward to it. See you there!

P.S.: Now back to my "vacation" in Brazil. :)

Material from last night's presentation at the C# SIG

Wed, 18 Jun 2008 18:52:10 GMT

I think the presentation last night went pretty well, and I get some great feedback from the attendees, so that's always good. :)

We’ve covered a LOT of ground:

Refactoring, separation of concerns, test-driven development, Command design pattern, Action delegate, multi-threading, lambda expressions, fluent interfaces, object mappers, extension methods… Of couse, everything in small doses, just trying to raise awareness about those things.

It all started with a simple WinForm app, going through the cycle of adding code to Click events on buttons, and then refactoring things out of the UI, extending it to support keyboard binding, designing a shortcut controller in a test-first style, doing more refactoring and using the Action delegate and refactoring the code to the Command pattern, then improving things a bit so to support asynchronous commands… then I’ve quickly covered object mappers and lambda expressions, and finally how to improve test code using extension methods and fluent interfaces.

The source code can be downloaded here.

Some people asked me how they can learn more about this stuff, and where to go find resources about it. Here are a few links to some of my previous blog entries that may help:

Good Resources on Test-Driven Development (TDD)

Learning in spiral

The whole testing thing...

Test-Driven.NET: a great little tool

Speaking at the Hal-PC C# SIG next week

Wed, 11 Jun 2008 15:30:46 GMT

Next week I'll be speaking at the Hal-PC C# SIG in Houston. This is something that came up last minute. Markus was booked to present there but won't be able to, so I was asked to fill in for him.

The session is going to be a "C# Tips and Tricks", where I'll be covering a bunch of things. The abstract is:

Claudio will cover a number of tips and techniques he has used in recent project work, including the command design pattern, Lambda expressions, extension methods, fluent interfaces, refactoring, and more. His objective is to present a few tricks that attendees can apply immediately and to inspire them to learn more about the other, more extensive topics covered.

Hope to see some of you out there! :)

Checking out the Source Analysis for C#

Tue, 27 May 2008 22:24:54 GMT

I've just spent about 30 minutes checking out the recently announced Microsoft Source Analysis for C#. I definitely love the idea, but I'm not sure I'll be using it just yet. Here are some of my impressions (again, I haven't spent a lot of time on it yet)...

All using directives must be placed inside of the namespace

Hmm, but VS itself violates that rule on every class we create...!

The property must not be placed on a single line. The opening and closing curly brackets must each be placed on their own line

Huh? But that an auto-implemented property. What would we want to split that into multiple lines?!

Variable names must not start with 'm_'

Hmpf, that's the standard with have here at the company...

A closing curly bracket must not be preceded by a blank line

Ok, this one I like.

Tabs are not allowed. Use spaces instead

Huh? Thanks, but no, thanks. I've seen a lot of people complaining online about this one too. What's the problem with using tabs??

The call ... must begin with 'this.'...

Ah, I like that one. This is something we've made as part of our guideline here, but couldn't use FxCop to trap for that, since the 'this.' doesn't make into the IL.

Now, the problem here is that, again, the code that VS generates violates this rule all over the place, such as on the example below:

I'll continue to use this tool to see if it's going to stick with me. I've tried it on a very small project, and got 246 violations; the vast majority where produced by code generated by VS. On a big project, I'd probably end up with a LOT more violations, so I'm not sure I can live with that. I believe there is a way to disable some of the rules, but haven't looked for it just yet...

Anyway, I do appreciate Microsoft releasing tools like this one. Hopefully, more and more developers will start paying more attention to how they write code.

Interesting training material

Tue, 27 May 2008 20:30:19 GMT

As an MVP, I got offered a license to InnerWorkings training material. I've been checking out some of it, and it looks pretty interesting.

I noticed they had some material on Domain-Driven Design Patterns, Enterprise Patterns, and some related topics that I'm always interested on, so I decided to try it out.

There is a "Developer Interface" app, where we keep all the material purchased. Each course has a number of tasks, and each task presents the scenario to be solved, the challenges, and reference material (with links to chapter of great books such as Eric Evan's on Domain-Driven Design).

The task provides a way to launch the sample project in Visual Studio. Once in VS, we get an "InnerWorkings" Tool Window that gives us quick access to the problems we need to address in the solution, and the useful links.

You can either try to address the problems by yourself, or cheat and see the solution. Once you're done with it, you may click the 'Judge Project Code" button that gets added to VS to have your code analyzed to see if you've implemented things in the way that was expected.

I'll certainly be checking out some of the other courses they have available (I need to catch up with some stuff such as WCF, WPF, Silverlight, LINQ to XML, etc.).

Getting rid of the slow help engine in Visual Studio

Fri, 16 May 2008 20:27:57 GMT

It's been a few years already since the last time I've installed VS' help (MSDN) on my machines. The thing is huge, slow to come up, and it didn't use to be that good. I just got used to using a SlickRun magicword to quickly search google, which searches not only MSDN, but also other resources (often much better than MSDN) such as CodeProject, blogs, etc. Since I'm connected almost 100% of the time, why use the slow local MSDN library?

Also, every once in a while a reach for the F2 key in order to start a "rename" refactoring in Visual Studio, and and up pressing F1 by mistake, and then there go 2 minutes of my life, waiting for the help window to come up (even though, again, I don't even have MSDN installed).

Talking to Mike today, I remembered I used to have a little VS macro that'd search on Google the text I have selected in VS. I thought it'd be good to just re-map the F1 key to that macro. It solves to problems: allows me to quickly perform a Google search from VS, and it doesn't get me stuck waiting for the VS help window to come up if I've hit the F1 key by mistake. :)

You can find an example of such macro here. In order to change the keybinding, go to Tools-Options-Keyboard, search for the "GoogleSearch" macro, and bind the F1 key to it.

Matching my own record: 5 and a half years at EPS!

Fri, 16 May 2008 15:01:31 GMT

Wow, today, May 16 2008, I'm matching my personal record at working with a company: 5 and a half years, or to be more precise, 2003 days. :)

Here's a little history:

I've had my first full-time job when I was 12. It lasted only for a full week; I just couldn't stand the boss. :)
When I was 14, I took a temporary job (also full-time), filling in for a friend for a full month.
The next Monday when I was done with the previous job, I was hired by a company across the hall: that was the company where I had stayed for 5 years and a half years. I started as a courier. After a year, I got promoted to a financial clerk (at the age of 15). Almost three years later, got promoted to a programmer/analyst.
From the previous job I went to a new company, as an IT guy (doing mostly software development, but also a lot of computer setup, networking, hardware, user support, etc.). I worked there for about 3 years.
Next, new company, now dedicated to software development. Worked there for about 14 months.
On to another company, where I've worked for about 8 or 9 months.

The reader have probably noticed the pattern: after the company where I've worked for over 5 years, my stay at every job was getting shorter and shorter.

Eventually I've decided to go solo as an independent consultant. I had my clients, I've put together some conferences for software developers, etc. That lasted for about 8 months. I wanted to have no strings attached to any company because at that time there was a good chance EPS would be hiring me, so I wanted to make sure I could join the company at any time. And that happened in November of 2002.

The rest, as they say, is history. :)

Material from Tulsa School of Dev 2008 is online

Thu, 15 May 2008 15:40:10 GMT

I've just uploaded the material I've presented last week at the Tulsa School of Dev 2008. The material includes slide decks and source code for my three sessions (C# 3.0, Design Patterns, and LINQ).

The material can be downloaded here.

Attributes on constants? Haven't thought about that...

Thu, 15 May 2008 14:48:59 GMT

I'm currently reading this article on CodeProject where the author is creating an MVP framework (seems like a good article so far...). In there, the author applies attributes to constants of a type. I had never thought that was actually possible. I want to make sure I keep that at the back of my mind, because I think I'll be using it sometime soon.

As a quick reminder, this is how that can be implemented:

public class SomeClass
{
    [Special("Some special attribute")]
    public const string SomeConst = "This is some constant";
}

public class SpecialAttribute : Attribute
{
    public string Foo { get; set; }
    public SpecialAttribute(string foo)
    {
        Foo = foo;
    }
}

This blog post has a handy method to get a list of constants defined on a type (including its baseclasses):

/// <SUMMARY>
/// This method will return all the constants from a particular
/// type including the constants from all the base types
/// </SUMMARY>
/// <PARAM NAME="TYPE">type to get the constants for</PARAM>
/// <RETURNS>array of FieldInfos for all the constants</RETURNS>
private FieldInfo[] GetConstants(System.Type type)
{
    ArrayList constants = new ArrayList();

    FieldInfo[] fieldInfos = type.GetFields(
        // Gets all public and static fields

        BindingFlags.Public | BindingFlags.Static |
        // This tells it to get the fields from all base types as well

        BindingFlags.FlattenHierarchy);

    // Go through the list and only pick out the constants
    foreach (FieldInfo fi in fieldInfos)
        // IsLiteral determines if its value is written at 
        //   compile time and not changeable
        // IsInitOnly determine if the field can be set 
        //   in the body of the constructor
        // for C# a field which is readonly keyword would have both true 
        //   but a const field would have only IsLiteral equal to true
        if (fi.IsLiteral && !fi.IsInitOnly)
            constants.Add(fi);

    // Return an array of FieldInfos
    return (FieldInfo[])constants.ToArray(typeof(FieldInfo));
}

And here's a little test method to show how to get the attributes out of the constants of a type:

[TestMethod]
public void TestMethod1()
{
    SomeClass obj = new SomeClass();

    FieldInfo[] fields = GetConstants(obj.GetType());

    Assert.AreEqual(1, fields.Length);
    Assert.AreEqual("SomeConst", fields[0].Name);

    object[] attribs = fields[0].GetCustomAttributes(false);
    Assert.AreEqual(1, attribs.Length);

    SpecialAttribute special = attribs[0] as SpecialAttribute;
    Assert.IsNotNull(special);
    Assert.AreEqual("Some special attribute", special.Foo);
    
}

Vista gets on my nerves...

Wed, 14 May 2008 23:16:00 GMT

This is just stupid: I have a folder somewhere that I've created. It's not under any security sensitive folder such as Program Files or Windows. I've copied some files into that folder. Then, I tried deleting the files. Vista asks me typical security questions, and I say "yes, just delete the damn files". Eventually it just comes back to me and tells me "access is denied".

Then I try moving the files into a subfolder. It has no problems with that. Tried deleting the subfolder; no luck. Moved the files back to the original location.

Next, I try opening a Command Prompt, running it as admin. I tried deleting the files there, no success either.

Finally, I tried running Windows Explorer as admin, and voila, the stupid thing lets me delete the files that I HAVE CREATED!!! Oh joy. How hard should it be for me to delete a stupid file that I've created myself, sitting on a folder that I've also created, outside of any O.S. folder???

Lambda Expression and Object Mappers

Tue, 13 May 2008 14:38:00 GMT

Here's a simple implementation of an object mapper using lambda expressions that I've shown yesterday at the Tulsa School of Dev. Say we need to copy some data from one object to another. For this example my objects are a Book and an AlternateBook. The class are shown below:

public class Book
{
    public Book()
    {
    }

    public Book(string title, int yearPublished)
    {
        Title = title;
        YearPublished = yearPublished;
    }

    public string Title { get; set; }
    public int YearPublished { get; set; }
    public string AuthorFirstName { get; set; }
    public string AuthorLastName { get; set; }
}

public class AlternateBook
{
    public string AuthorFullName { get; set; }
    public string Title { get; set; }
}

I could have a mapper that worked like this:

Mapper mapper = new Mapper(book, alternateBook);
mapper.AddMap("Title", "Title");
mapper.AddMap("AuthorFirstName", "AuthorFullName");

That approach would have some problems, though:

The properties are mapped using string literals, which means we don't benefit from strong-typing or IntelliSense (bugs could easily arise because of typos or properties that don't exist on the objects);
The properties have a 1:1 mapping, which in the sample above wouldn't really work, since I had to map "AuthorFullName" directly to "AuthorFirstName", as oppose AuthorFirstName and AutorLastName.
The mapper would have to use Reflection to look up the properties on the given objects and then assign their values (not the most optimized way of doing it...).

The approach using Lambda expression would look like this:

var mapper = new Mapper<Book, AlternateBook>();

mapper.AddMapping((b, ab) => ab.Title = b.Title);
mapper.AddMapping((b, ab) => ab.AuthorFullName = b.AuthorFirstName + " " + 
                                                 b.AuthorLastName);

Points to note:

As I instantiate the Mapper I provide the type of objects as Generic parameters;
The AddMapping method takes in lambda expressions that receive two parameters (b and ab, for book and alternate book, respectively), which I then use to set the mapping. That gives me both strong-typing and IntelliSense support.
The lambda expression also opens up control over how things are pushed into the target object. In the sample below, I can format how the alternate book's AuthorFullName property gets populated;
Since the lambda expression is compiled down to a delegate, there's no Reflection involved, so the code should run faster when executed.

Now, in case you're not familiar with lambdas yet: the expression does NOT get executed when we are passing it as a parameter to the AddMapping method. At that point we are only registering the m apping; the actual execution occurs whenever we want it to. I would probably, say, at the application start, register all mappings I'm likely to use. Eventually, when I need to actually process the mapping (copying some data from one object to another), I can just call the ApplyMapping, passing in the objects involved with the mapping. For example:

Book book = new Book 
{ 
    AuthorFirstName = "Claudio", 
    AuthorLastName = "Lassala", 
    Title = "Some book" 
};

AlternateBook alternateBook = new AlternateBook();

mapper.ApplyMappingsTo(book, alternateBook);

Console.WriteLine(
    "Book:"+
    "\r\n  Title: "+ book.Title +
    "\r\n  AuthorFirstName: " + book.AuthorFirstName +
    "\r\n  AuthorLastName: " + book.AuthorLastName);

Console.WriteLine(
    "\r\nAlternateBook:" +
    "\r\n  Title: " + alternateBook.Title +
    "\r\n  AuthorFullName: " + alternateBook.AuthorFullName);

The code above should produce the following results:

So, how's the Mapper class implemented? Here we go:

public class Mapper<TSource, TTarget>
{
    private Collection<Action<TSource, TTarget>> m_Mappings = 
                    new Collection<Action<TSource, TTarget>>();
    public Collection<Action<TSource, TTarget>> Mappings
    {
        get { return m_Mappings; }
    }

    public void AddMapping(Action<TSource, TTarget> action)
    {
        Mappings.Add(action);
    }

    public void ApplyMappingsTo(TSource source, TTarget target)
    {
        foreach (var mapping in Mappings)
        {
            mapping(source, target);
        }
    }
}

The class keeps a list of all the mappings within its Mappings collection, which is a collection of Action<TSource, TTarget> delegates. Both TSource and TTarget are Generic types provided to the class. The AddMaping method takes in the delegate (which we pass in as a lambda) and adds it to the Mappings collection. The ApplyMappingsTo method takes in instances for the source and target object, iterates through the Mappings collection, and invokes each mapping (don't forget it, the mapping is a delegate).

That's it. Again, this is just a simple implementation. I'm pretty sure there's a lot of improvements to be done on top of this, and there's definitely something some people wrote out there around the same lines; I'll be looking for that myself in order to see how I can improve this.

For instance, one thing that pops up is: what if the developer messed up and specified the mapping going from the target to the source instead? Like so:

mapper.AddMapping((b, ab) => b.Title = ab.Title);

We certainly don't want to copy the title from the Alternate Book to the Book object. I don't know of way yet to have the compiler catch that problem (any ideas?). During runtime, though, I know I could have the AddMapping method analyze the Expression Tree for the lambda it was given, and make sure that the target appears at the left side of the = sign, and the target appears at the right side.

Another improvement that could be made is some optimization. For instance, itake the following code snippet:

mapper.AddMapping((b, ab) => ab.AuthorFullName = b.AuthorFirstName + " " + 
                                                 b.AuthorLastName);

There, the developer has used string concatenation to build up the value to be assigned to the property. The AddMapping method could have some logic that analyzes the expression tree, and if it finds something like string concatenation, it could replace that with using a StringBuilder. Of course, such optimization should only be done if we can clearly see that as being something that we really needed to squeeze better performance out of.

Also, it'd be convenient to have the mapper just figure out what properties to copy from the source to the target by looking for properties that map 1:1 (that is, property name and type exist on both objects), and then let the developer only supply special mappings for properties that require transformation.

I'll be doing some more research on better ways to do this kind of stuff.

The Temple of the King

Mon, 12 May 2008 06:21:56 GMT

After some pretty tough weeks with a lot of work and little sleep, I spent an afternoon with my friends Milton and Lucas having some fun making some home-recording of Rainbow's Temple of the King. Nothing like having some fun to relieve some of the stress. :)

Check it out:

http://www.youtube.com/watch?v=BefV66tSyEI

The Twitter thing is not so bad after all

Sat, 10 May 2008 23:51:25 GMT

A few weeks ago I mentioned I had broken down and signed up for Twitter. Even though I have not yet fell for it yet, I do some of its value. It does have an obvious problem: if you're not careful, you can quickly get carried away and become and totally unproductive person. What I've been doing is to have a Twitter client open in one of my computers, and every once in a while I check out what my peers are up to (usually on short breaks or when my computer is taking to long to process something).

Here are the things I've either experienced or seen that I kind of dig:

This morning I had to go from the hotel to the campus where the Tulsa School of Dev was going to take place. I was supposed to start my keynote at 9am, so I came down to the hotel's lobby at around 7:50am, thinking I'd get a shuttle and be at the campus at around 8:15am (I had no idea how far the place was). Somebody from the hotel tells me they wouldn't drive to the place. Somebody else says they would. Twenty minutes later a "definitive" word comes that they really would not take me there. Ok, no problem, but they could have me told that before, right? Anyway, I asked whether they could just call for a cab, which they said they would. Another 40 minutes go by, and nothing. They called the cab company 4 or 5 times, and on the last time, the company says they don't have a cab in the area (it's not like I was in the middle of nowhere; I was in downtown...). Well, I start barking at people, and eventually one of the hotel's drivers says he's taking me to the place, and that it didn't take 10 minutes for us to get there (while we're on our way, the hotel calls the guy to say he's in trouble because he wasn't supposed to take me). What the hell? It's 10 minutes away from the hotel!! What's their problem? Anyway, around 8:30am, I had twittered expressing my frustrating with my wait for a cab. When I got to the auditorium, at 9:01am, Dave said he had seen my twitter, so he knew I should be getting there anytime soon. I didn't have Dave's cell phone number, so I was just hoping he'd be checking on Twitter. So I was actually glad I used Twitter for that (yes, I did give the hotel's manager an earful when I got back there this evening).
Every once in a while I see somebody twittering links to articles or blog post on things that I'm personally interested in.
I end up connecting with people in ways I would not have even imagined before. For instance, in my list of friends and followers, I have a mix of people who are personal friends, and people who knows me from the software development community (people who follows this blog, sees me presenting, or reads my articles). The other day I twittered to say I had finished watching the first season of Heroes, and all of a sudden I start getting replies from people who also enjoyed the show, and I've ended up learning about some other things related to the series that I didn't know about (such as the fact that there are short graphic novels on the series' website that extend episodes and provide more details about characters and things like that). I really like this social aspect where a person ends up relating to another by means of other things they like but wouldn't know they shared it because they usually meet in the realm of, say, software development.
You learn some fun tidbits, like when Rick smashed his bass sometime in the 80's and had to borrow one from Testament. :)
Some people (like Kevin Miller) are already finding ways to use Twitter to produce some business value.

One other thing I'm not liking about it right now is the fact that I don't own an *i*Phone, I just own *a* phone; a regular Sony phone that has a tiny little web browser, which makes it *really* hard to type anything on it and post to Twitter, or to follow posts. And an iPhone isn't getting in my budget plans for the foreseen feature (there's just too many other things taking higher priority).

Note: I was typing this post offline; when I got online, I saw a tweet from somebody pointing out to a post by Rick that's very similar to this one of mine. :)

Tulsa's School of Dev

Mon, 05 May 2008 20:16:58 GMT

This Saturday I'll be speaking at the Tulsa's School of Dev. I've had a great time last year, so I'm looking forward to going there again, do some presentations, attend others, and meet some old buddies there.

Here are the talks I'll be delivering:

Keynote: Using the New Features in C# 3.0
Design Patterns in .NET
Intro to LINQ

The full agenda can be found here.

That's a free event, so make sure to check it out!

Improving tests with Extension Methods

Tue, 22 Apr 2008 15:52:16 GMT

In my constant search for making it easier to write tests for common things in our framework, I believe I was able to clear some things up by using extension methods. Not that this hasn't been done before, it's just that I want to document how I got to it so that I can use this post to explain the approach to other people (and maybe help somebody else learning about this). :)

The scenario is: we need some clean and easy way to test validity of entities after business rules have been evaluated. One approach would be to write the test like so:

[TestMethod]
public void SomeTest()
{
    CustomerEntity entity = new CustomerEntity();
   
    bool entityViolatesRule = false;

    // make the checks and assign true/false to the entityViolatesRule variable

    Assert.IsTrue(entityViolatesRule, "Some assertion message...");
}

Disclaimer: nope, I don't name my tests like that. It's just that the test name isn't important here!

The test would need whatever logic necessary for checking whether the entity violates a given rule, and then call an assertion for it.

In order to clean that up a little bit, I created a Violates extension method on my Entity class. The extension is only meant to be used by tests. The method takes in a RuleViolationExpectation object, meant to carry the expectations for the violation of a specific rule. An assertion would be called from within that method:

public static class EntityTestExtensions
{
    public static void Violates(this Entity entity, RuleViolationExpectation expectation)
    {
        bool entityViolatesRule = false;
        // some code that looks at the expectation and checks 
        // whether the entity meets the expectation... 
        Assert.IsTrue(entityViolatesRule, "Some assertion message...");
    }
}

The RuleViolationExpectation class looks like this:

public class RuleViolationExpectation
{
    public Entity Entity { get; set; }
    public Type RuleType { get; set; }
    public string Message { get; set; }
    public ViolationLevel Level { get; set; }
}

The test could now look like this:

[TestMethod]
public void SomeTest()
{
    CustomerEntity entity = new CustomerEntity();

    entity.Violates(new RuleViolationExpectation 
                    { 
                        RuleType = typeof(CustomerNameIsValidRule), 
                        Level = ViolationLevel.Violation, 
                        Message = "Customer name must..." 
                    });
}

I liked that better because I got rid of the Assert, as well as any logic that checks whether the entity violates the rule according to the expectation. Now all the developer has to do is to call the Violates method on the entity, passing in the expectation, and the framework does the rest (verification and assertion).

One thing bothered me, though: the call to the method read sort of funny, kind of like "entity violatates rule violation expectation...". That didn't really express the intent well: it's not that the "entity violates a rule violation expectation".... it's more like the "entity should violate a specific rule according to the given expectation".

I then rewrote the test based on how I'd like it to read for better comprehension:

[TestMethod]
public void SomeTest()
{
    CustomerEntity entity = new CustomerEntity();

    entity.Violates<CustomerNameIsValidRule>()
          .WithMessage("Customer name must blah blah blah...")
          .OnLevel(ViolationLevel.Violation)
          .Verify();
}

I thought that read much better. It's more like "entity violates the CustomerNameIsValid rule, with a message like 'Customer name must blah blah blah...', and on level Violation, so Verify all of that for me". For the records, the other level option is Warning.

Notice that from the call to Violates on, that's really just a long chained method call, split up into several lines just to make the code easier to read, without requiring horizontal scrolling.

In order to enable such syntax, I've added one more extension method to my EntityTestExtensions class:

public static RuleViolationExpectation Violates<TRule>(this Entity entity)
    where TRule : Rule
{
    RuleViolationExpectation expectation = new RuleViolationExpectation();
    expectation.Entity = entity;
    expectation.RuleType = typeof(TRule);
    return expectation;
}

The method takes the expected rule type as a generic type, instantiates the RuleViolationExpectationViolation class, associates the expectation with the entity, assigns the type of rule to the expectation, and returns it.

Next, I created a RuleViolationExpectationExtensions class, and added extension methods to it, like so:

public static class RuleViolationExpectationExtensions
{
    public static RuleViolationExpectation WithMessage(this RuleViolationExpectation expectation, 
                                                       string message)
    {
        expectation.Message = message;
        return expectation;
    }

    public static RuleViolationExpectation OnLevel(this RuleViolationExpectation expectation, 
                                                   ViolationLevel level)
    {
        expectation.Level = level;
        return expectation;
    }

    public static void Verify(this RuleViolationExpectation expectation)
    {
        expectation.Entity.Violates(expectation);
    }
}

Each method extends the RuleViolationExpectation class, and takes in the value for one of the properties we need to assign on the expectation, we assign it, and then returns the expectation back to the caller. Got it? It's just a bunch of methods acting upon the same object.

The Verify method is the one that works a period (".") at the end of the sentence, by telling the framework we're done setting up the expectation, and it's time to verify the entity against the expectation. The method just leverages the Violates method that we already have on the entity; the one that takes in the RuleViolationExpectation object.

The actual implementation I've done for this in our framework is more complex and complete; the expectation class has a couple more properties that we need to check for, and it also has logic that validates the expectation so to make sure the developer has provided everything the framework needs in order to verify the entity against the expectation. If there's piece missing, the framework call an assertion and tells the developer what's missing.

Also, I've created a CodeRush template that makes it REALLY easy for developer to write the code and not miss any piece. The way it works is: I put the name of my entity variable into the clipboard and then type rve (Rule Violation Expectation, but I'll probably change this), and I get this:

All the developer then needs to do is to fill in the expectations, hitting enter to go through the "fields" (orange highlighted areas) in the code:

Moving along with a test-first approach, I'm already thinking that the developer can write the test first for the rules evaluation verification, and then I'll write a plug-in that will read the call to "Violates..." and generate the business rule, where the dev then only needs to write the actual business logic. In case the test hasn't been created first, I can also have a plug-in that'll look at an existing business rule and then create the test based on it.

I believe such approach has very little friction even for developer who aren't not entirely comfortable with TDD and test-first. What do you think?

Putting LINQ queries together, one piece at a time

Mon, 21 Apr 2008 15:49:09 GMT

Last week, good pal Rod Paddock asked me an interesting question about LINQ, and I think this may be useful to others (not that the answer may not already be out there somewhere, of course...).

The main scenario was that different queries had to be run depending on some options. The from and select parts of the query where pretty much the same; the parts that varied were the where and orderby ones. Here's some code to illustrate a simplified scenario:

Collection<string> months = new Collection<string> { "January", "February", 
    "March", "April", "May", "June", "July", "August", "September", "October", 
    "November", "December" };

IEnumerable<string> query = null;

int? minNumberOfLetters = 5;

if (minNumberOfLetters.HasValue)
{
    query = from m in months
            where m.Length >= minNumberOfLetters
            select m;
}
else
{
    query = from m in months
            where m.Length >= minNumberOfLetters
            select m;
}

bool shouldOrderByLength = true;

if (shouldOrderByLength)
{
    query = from m in months
            where m.Length >= minNumberOfLetters
            orderby m.Length
            select m;
}

foreach (var item in query)
{
    Console.WriteLine(item);
}

The code should query only months whose name length is equals to or greater than minNumberOfLetter (in the sample above, that'd be 5), unless that variable holds a null, in which case all months should be returned. Also, the query should be ordered by the length of months names, in case shouldOrderByLength is true (obvioulsy, both minNumberOfLetter and shouldOrderByLenght wouldn't be hard-coded, but instead, read from user input or whatever...).

The main problem with such code is that there's a lot of redundancy in the queries. What if, for instance, instead of doing select m, we wanted to do select m.ToUpper()? We'd need to make that change in multiple places.

Queries can be broken up into smaller pieces. Queries don't get executed until they're iterated over, either by using in a foreach block, or calling ToList() on it (which uses a foreach internally...). That means we can tweak with them until right before the iteration happens.

So, we can refactor the previous code where we first declare the part that doesn't vary in the query:

var query = from m in months select m;

Remember, the query above does NOT get executed just yet; we are just defining it, but not executing it (think of it as building a SQL query by concatenating strings, and eventually executing the query against the database).

Then we can add the where clause to the query if appropriate:

if (minNumberOfLetters.HasValue)
{
    query = query.Where((string m) => m.Length >= minNumberOfLetters);
}

Same with the orderby clause:

if (shouldOrderByLength)
{
    query = query.OrderBy((string m) => m.Length);
}

Whenever we're done building the query, then we can iterate over it as needed.

Another cool thing we can do: say we need to order the query according to some specific logic; for example, if some variable is true we want to order the query by the month's name, otherwise we want .to order it by the name's length. That could be done something like this:

Func<string, object> orderBy = null;

if (orderByName)
{
    orderBy = (string m) => m;
}
else
{
    orderBy = (string m) => m.Length;
}

query = query.OrderBy(orderBy);

Basically, we declare a Func<string, object> variable that is going to hold the expression for ordering. In the if-block we assign a lambda expression to the variable accordingly. Finally, we add the call to OrderBy to the query, passing in the expression.

Here's the complete final code, in case you want to mess with it:

Collection<string> months = new Collection<string> { "January", "February", "March", 
                  "April", "May", "June", "July", "August", "September", "October", 
                  "November", "December" };

var query = from m in months select m;

int? minNumberOfLetters = 5;

if (minNumberOfLetters.HasValue)
{
    query = query.Where((string m) => m.Length >= minNumberOfLetters);
}

bool shouldOrderByLength = true;

if (shouldOrderByLength)
{
    query = query.OrderBy((string m) => m.Length);
}

bool orderByName = true;

Func<string, object> orderBy = null;

if (orderByName)
{
    orderBy = (string m) => m;
}
else
{
    orderBy = (string m) => m.Length;
}

if (orderBy != null)
{
    query = query.OrderBy(orderBy);
}

foreach (var item in query)
{
    Console.WriteLine(item);
}

Ok, ok, I'm signing up for this Twitter thing...

Thu, 17 Apr 2008 04:15:48 GMT

Markus has been harassing me about to get into these Facebook and Twitter things. I've signed up for Facebook a few weeks ago (even though I don't waste my time with those little applications they have there...). Now he's been on my tail saying I have to do this Twitter thing, which I have seen people talking a lot about it, but I still can't really see why I'd want to use it. :)

I've decided to give it a go... let's see... I'll either get hooked, or just not use it for too long. It seems to me like a new spin to the whole Big Brother thing. :)

Well, anyways, I'm there: http://twitter.com/ClaudioLassala

At the MVP Summit this week

Tue, 15 Apr 2008 01:06:46 GMT

I'm out to Seattle for the MVP Summit 2008 the whole week. Always fun to be here. It's great to get together with all these people, from all over the world, that I got to know over the Internet throughout the years.

It's just very cool to hang out with people from so many different countries, coming from very different cultures, speaking very different languages, but at this point they're all focused into discussing the things they passionately work with.

Failed assertion throws an exception...

Fri, 11 Apr 2008 18:46:43 GMT

Hmm, this is something I did not know: when a testing framework's Assert method fails, an exception gets thrown. We don't actually see that exception, because the framework catches it. We usually don't see it because tests normally look like this:

[Test]
public void SomeTest()
{
    Assert.IsTrue(false, "whatever");
}

However, say the test was written like this:

[Test]
public void Test()
{
    try
    {
        Assert.IsTrue(false, "whatever");
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.GetType().FullName);
    }
}

We get the following printed on the Output window:

NUnit.Framework.AssertionException

So why would somebody ever write a test like the one above, you may ask, right? Well, like I mentioned the other day, I wrote a framework for integration tests that has a bunch of assertions for some things so that the developer doesn't have to write those over and over again. Even though those things are hidden from the developer, I try to capture as much information as possible, and if any assertion fails, I give all the details to the developer so that he know exactly what failed during the integration.

When running a specific test here, I noticed that I was getting some extra information that shouldn't really be there, and that was because one assertion was failing and was getting trapped by a try/catch somewhere, and after some digging I actually realized this behavior of assertions throwing "AssertionException"'s.

The whole testing thing...

Thu, 10 Apr 2008 03:37:36 GMT

I keep hearing how developers say it's kind of hard to get their minds around this testing thing, so I was then thinking to myself: "how did I get into this, by the way?"

It was at DevTeach 2003 when I first heard about unit testing. Scott Bellware was presenting a session about it. I decided to sit in and see what that was all about. Scott showed NUnit, and how to write some unit tests (sorry, that's as much I can remember so many years later...).

Right after seeing that session, I decided to start writing some tests for some new code I was writing. At the time, I was writing the test after I wrote the production code, still trying to figure that NUnit thing. I was pretty pleased by having automated tests for some of my code.

Late in 2005, the same Scott came to Houston to present a full-day TDD workshop. Again, that was kind of long ago, and my memory is fuzzy. I remember Scott touched on dependencies, mock objects, how Test-Driven Development (TDD) helps keeping track whether the implementation is going on or off track, etc. I guess that was when I've heard of using TDD more as a design methodology than as a testing methodology, but I'm sure I didn't quite *get* the idea back then.

Around that same time, I was working on a project here where we've decided we wanted developers to write more tests. We were using NUnit, and writing "integration" tests, not "unit" tests (as I came to realize later). We were writing tests to make sure the data put into our business entities were being saved and retrieved correctly to and from the database.

Right before starting off a new project (early in 2006), I looked back and noticed that a lot of redundant code was being written for those tests (instantiate entity, stick test values to its properties, save it, reload it, check to make sure the values saved are the ones expected, delete it, and have assertions all around to make sure things were working).

Decided to make that easier, I wrote a testing framework that'd do all that boring and repetitive work for the developers. For each business entity, the developer would create a test fixture class, make it inherit from a baseclass from my framework, override a method to provide test data to be pushed onto the entity, and give the baseclass the type of entity under test. The framework would then take care of doing all the heavy lifting and report any problems to the developer by means of assertions with as much detailed information possible (which property has failed, in which process, why, what could be causing it, etc.).

We had also noticed how much of a pain it was to create some specific test data that a given entity needed in order for it to be properly tested. I've then added some helper methods to my test framework that allowed the developer to pretty much ask for "5 entities of type Customer for tests", or something like that, and the framework would take care of creating those, giving it back to the developer (who could also tweak with the test entities, of course), and then cleaning it up afterwards.

The framework worked well, and the great thing about it was that it was pretty easy to get some good code coverage with those tests. However, at the time I *thought* we were doing unit tests, but we were actually doing integration tests. It finally downed on me that we should also be able to test things in isolation. That is, if what we need to test is a business rule, we shouldn't need a live connection to the database, or even a data access layer for that matter. "A-ha, so that's what those mock objects are all about, then", I thought to myself.

With that in mind, I decided to improve our testing framework so to make it easier for our developers to write unit tests for our business rules, so that they didn't have to worry about the dependencies we have in our middle-tier framework in order to do so. After I've done some research on mock frameworks, I've decided to go with TypeMock, which I wrap up in my own special framework for testing our middle-tier components.

I'm currently working on rewriting some pieces of our testing framework in order to make use of some of the new features in C# 3.0 (such as object and collection initializers, lambda expressions, extension methods, etc.). This allowed me to clean up my API's a lot (or so I think).

Everything I've mentioned so far has definitely improved my skills with doing TDD as a "testing" methodology, trying to make sure our code has some tests around it. That is something that most developers have a better time understanding and trying to do it, so that's certainly valid.

Doing TDD as a "design" methodology is something eventually I got the idea and decided to start practicing it. This is definitely much harder for developers to get used to, because it really requires a different approach to writing software; different from what they've been doing for so many years now. However, like it's been said over and over again by other people, when you really stick with TDD, then you start feeling bad about any code you write that you didn't design beforehand, test-first.

By no means am I saying that I have mastered TDD (far from that), but I'm just certain that the code I wrote test-first is of much higher quality. Not only I believe my design is more solid (both because of the thought I've put through the design, but also because of the side-effect of getting the implementation under test), but I find it's much easier to explain something to another developer by showing her the tests first, and then digging into the implementation.

I have been reading a lot of books, articles, websites, blog posts, other people's code, etc., trying to improve my approach to TDD (which always entertains me by getting blown away by some code other people write). This has been great, and I plan to continue doing so.

I'll probably have some more posts coming this way on the subject, as I get my mind around this thing. :)

Consider creating a custom collection

Thu, 03 Apr 2008 16:24:46 GMT

It's happened to me a few times when I create a property of a type List<T> or Collection<T>, where T is something simple such as a string or an int, and then later I regret I've done so. For instance, the other day I had the following scenario (I've changed things around in order to make it a little simpler for this post):

I have some class that had a Parameter property of type Collection<string>:

public class SomeClass
{
    private Collection<string> m_Parameters = new Collection<string>();
    public Collection<string> Parameters
    {
        get { return m_Parameters; }
        set { m_Parameters = value; }
    }

    public SomeClass()
    {
        this.Parameters("A");
        this.Parameters("B");
        this.Parameters("C");
    }
}

It used to work great when all I needed was a list of parameters there:

SomeClass foo = new SomeClass();
foreach (string parameter in foo.Parameters)
{
    Console.WriteLine(parameter);
}

However, in order to support something new feature, I also needed to store the old and new values for the parameter. Hmpf. Now, instead of a Collection of strings, I need a collection of something else. I then created a Parameter class, with the specific properties I needed:

public class Parameter
{
    public string ParameterName { get; private set; }
    public object OldValue { get; private set; }
    public object NewValue { get; private set; }

    public Parameter(string parameterName, object oldValue, object newValue)
    {
        ParameterName = parameterName;
        OldValue = oldValue;
        NewValue = newValue;
    }
}

Nothing too fancy. At this point I can change my Collection<string> to Collection<Parameter>. Obviously, I'll also have to change any code that works with that collection, since the generic type for the collection has changed:

SomeClass foo = new SomeClass();
 foreach (Parameter parameter in foo.Parameters)
 {
     Console.WriteLine(parameter.ParameterName);
     Console.WriteLine(parameter.OldValue);
     Console.WriteLine(parameter.NewValue);
 }

If I had gone with a richer type to begin with, I wouldn't have to change any caller of that collection; if I needed more information, all I'd have to do was to add more properties to the Parameter class. In this one case, making the change wasn't such a big deal because my property was exposed only within the assembly; if it was exposed as a public property, than that'd be a major breaking change because I'd have no clue as to who else would be using it in other assemblies.

That makes me think whenever I'm declaring a Collection or List of something, I should put a little more thought into whether it's likely that I'll need some extra information associated with it, and if so, I should create a special type for it.

Also, it turns out that what I really needed was some sort of dictionary, because I wanted to look up items by a given key (in this case, the parameter's name). The Collection<T> doesn't give me that behavior, but the KeyedCollection<TKey, TItem> does, so I created a ParameterCollection like so:

public class ParameterCollection : KeyedCollection<string, Parameter>
{
    protected override string GetKeyForItem(Parameter item)
    {
        return item.ParameterName;
    }
}

The class uses a string as the key (which is the ParameterName), and the Parameter as the value. So my SomeClass class ended up like this:

public class SomeClass
{
    private ParamaterCollection m_Parameters = new ParamaterCollection();
    public ParamaterCollection Parameters
    {
        get { return m_Parameters; }
        set { m_Parameters = value; }
    }

    public SomeClass()
    {
        this.Parameters.Add(new Parameter("A", "A old value", "A new value"));
        this.Parameters.Add(new Parameter("B", "B old value", "B new value"));
        this.Parameters.Add(new Parameter("C", "C old value", "C new value"));
    }
}

And besides using a regular foreach, I can also access the elements like this:

Console.WriteLine(foo.Parameters["A"].OldValue);
Console.WriteLine(foo.Parameters["B"].OldValue);

How's the band doing...?

Tue, 01 Apr 2008 01:16:12 GMT

Some of you know that I play guitar in a local band on what's left of my spare time. Every once in a while somebody ask me how the band is doing, so I guess I'll just post a general reply here.

Sometime last year we started recording 4 songs for our new demo. It's been taking awhile because we've been on and off for many months (business trips, Holidays, etc.), but now we have a recent mix of the songs online. You can check it out here:

If you're into Heavy Metal, let me know what you think. If you're not, I already know what you think. :)

We're currently working on a new song, which is going to be part of this demo. We've recorded some of it, and hopefully will finish it in the next few weeks. It's more of a ballad type of song, but with very strong lyrics. Definitely something to add some diversity to our set list.

We're still in our search for a drummer and a bass player, so if you know somebody in the Houston area that may be interested, please let me know.