Storing a collection of reference types and value types is a common practice in Software Development. Since the introduction of the Generic Types in Framework 2.0 working with collection elements has become much easier.

The ArrayList type used to be the common type for storing objects but the new kid on the block “Generic List” has taken away the popularity from the ArrayList. Since elements were stored as an object casting reference types from object to enclosing type needed the extra coding and decreased the performance. With value types the developers faced the boxing issue at storing time and unboxing when the data was retrieved from an instance of ArrayList object.

With Generic List type you have instance access to the elements of an instance generic List object without the need to cast or unboxing the data. The generic List has far more members that its predecessor ArrayList. I’m not going to delve into each member and explain what they do. I’m sure most of you already familiar with them and they have been well documented on MSDN Library or by other developers.

In short the generic List functionality (members) is best used with .Net Framework’s value types but not with reference types. As long as you are using generic List to pass a collection of data around you would never face the fundamental problem I’m about to highlight in here.

Please examine the following snippet:

The above code makes generic List a glorious type to work with because it offers the encapsulated “Contains” logic to see if values exist in the collection or not at ease.

Please examine the following snippet:

 
On paper the capability of generic Predicate delegate combined with other generic types such as generic List is smashing but at least in case of generic List it offers hardly any practical solutions in real world.

The downside of working with generic Predicate and generic List are as follow;

• Possibility of duplicating logics: Even if you declared MarkExists method with public or internal visibility access you can’t be assured other types can access the enclosing type at all time.
• Too many members to declare: You can’t possibly declare one target method for every name there is in Person’s FirstName property. How about other business logics that you might have with other members in Person type?

In one of my earlier blog posts I talked about encapsulating logics which is one of the most fundamental practices in SD. Any logics that you would write against a generic list object would not be necessarily encapsulated. This is the very reason why as soon as I need to write any logic against a generic List object instead I would declare a new type and extend the generic Collection type and encapsulate them within the extended generic Collection type.

I can pass on such objects from members to members or from the declaring type to another types knowing I have access to all predefined logics against my custom collection type.

The generic Collection type has very simple object model and extremely easy to extend. This is actually an advantage that the generic Collection has a very simple object model. The generic Collection type can be found in System.Collections.ObjectModel namespace.

If you only develop database applications then the chances that you are using more complex collection types are high such as the powerful collection types that you would get with the O/RM tools or the custom collections you built for your own needs. This post is less relative to entities and entity collections.

Smarties 2008 is not a database application but for almost every type there is you would find an extended generic Collection.

Often you are required to introduce sorting capability to the extended Collection types or add a simple AddRange() method to ease up inserting objects to the collection. The generic Collection does not offer AddRange() method by default but from the constructor you can pass any objects that implement the generic IList interface. We all know that not always it is possible to pass data on initialisation time.

I’d get a lot of joy out of my work when the output is of something that is both practical and so damn easy to use. You would find many commands in Smarties 2008 that are unique and in terms of productivity they are simply unbeatable. The same day that I published this post I released version 1.9.0 of Smarties 2008 that the main focus was to introduce sorting to the extended Collection type and to ease up working with generic IComparer, IComparable, and generic IComparable interfaces.

I have created a demo for each supported language (C# and VB.NET) that is not just specific to a single command (as I often do). It shows off several commands in actions and you will see how easy it is to create sortable collections using Smarties 2008. Please don’t think entity collections or try to compare what you see in the demo with what you get with entity generator of O/RM tools. In real world you would have far more non-entity types than entity types anyway.

Before watching the demo I would like you to think of a class with at least three properties, an extended generic Collection type since you would be encapsulating logics, and the comparer type that is needed for sorting the reference types in the collection. Lots of work for very basic functionality even if you would use the copying and pasting techniques, isn’t it?

To be precise the demo takes 51 seconds to produce the output. In fact the only thing was done for this demo was the three private fields that I declared by hand earlier and the rest was done just by few clicking of the mouse.

Here is the link to Demo Page.

A class represents a template for an object that can have attributes and/or behaviours. The object itself normally represents something in real world i.e. Person or something that physically does not exists but one can define it i.e. a Blog Post.

In .Net development platform classes and structs are the core object templates. Classes and Structs derive from .Net’s Object class. Then there are Interfaces. An interface is a contract template that you can sign with class and struct types to ensure they implement the same members on the contract.

Quite often I use the phrase “Rich Class” to suggest the class in question exposes common services to its users. Also a “Rich Class” is the type that encapsulates all possible logics within itself. This is the most fundamental design strength of a class.

Here is an example to what I mean. You have a class called Person with FirstName and LastName properties that the user can use to retrieve values and to assign values to the designated fields. Now imagine the Person class is used by hundreds of developers. If the developers need to show the full name of the person they need to write a concatenating statement like the code snippet below:

textBox1.Text = person.FirstName + “ “ + person.LastName;

If the Person class was “rich” then it would have either a ReadOnly property called FullName or overrided the ToString() method of System.Object to make it easier for the users of the Person class.

Examples:

textBox1.Text = person.ToString();

or

textBox1.Text = person.FullName;

The poor design of Person class made all developers to code extra unnecessary.

You can also design rich classes that expose services to its users. For instance, I look at the implemented Dispose() method of IDisposable pattern as a service for types. This is up to the user whether they want to call it or not. Incidentally, in C# 2.0 if you intend to use the “using” keyword the type now is required to implement the IDisposable interface.

Similar to IDisposable you can introduce ISerializable and ICloneable as services too. Developers can’t predict everything to what the user of the type would intend to do therefore it would always be a good practice to make a type as rich as possible.

I like to design rich types because I know such types would save me a great deal of time later on when I have less time. Creating rich classes is very difficult and time consuming something that developers never have.

Considering that developers are required to learn more to be able to use the never ending new technologies it makes time ever more precious. I have noticed in the past 2-3 years software quality has dramatically dropped. Obviously apart from the lack of time and rushing the product out to bring in the money there are other factors involved too, the lack of skills/experience, out-sourcing, and few more to mention.

Now to the good part…

Smarties 2008 helps developers designing better types by reducing the coding time and freeing the developer to work more on the types. With Smarties 2008 many painful routines can be done with a couple of clicks.

Smarties 2008 features:

Region Commands: If you use #regions to organise code that will boost productivity then you would find Smarties 2008 very handy and even if you dislike #regions then Smarties 2008 gives you all the commands you to remove them from your source files. 

Refactor Commands: Common refactor commands plus many unique commands that are pure time-savers.

Smart Interfaces: You can click 2-3 times and implement one of the supported Interfaces with full statements generated. The supported interfaces are IDisposable, ISerializable, and ICloneable.

Data Commands: Even though Smarties 2008 is not an OR/M or DAL Generator we have recently added Data Commands related commands. One of the things you can do is to create Flat BO/VBO from one of the nine supported database engines. I’m currently working on adding DAO support to save you even more time.

This is true to say if developers have the right tools they would be more productive therefore can produce better software. A single feature in photoshop the king of graphic applications doesn’t do much and it doesn’t make you creative either but collectively you can do so much and make eye catching graphic images. In that sense Smarties 2008 might appear not to do much at first glance but collectively you can achieve a lot.

Imagine you need to create a class that has four properties, of any types, the class has to implement IDisposable, ISerializable since it would be transported over the wire, and ICloneable interfaces. I’m not done yet… Then the class also need to produce an XML string to pass the data to a legacy system. With Smarties 2008 all you need to do to declare the fields and the rest is done by few clicks. With a couple of more clicks you can even create a generic collection of above type. When you have powerful features at your feet then you wouldn’t need to be so economical in your design.

I really just touched the surface as to what you can achieve with Smarties 2008. Please free to visit the site to download a free trial or to watch the videos to see what Smarties 2008 can do for you.

I promised to blog about the lack of DAO support in Business Object Generator command.

As you might have noticed by now I have created a new menu under Smarties 2008 called “Data Commands” to list all the relevant commands there. One of the first commands that I added for “Data Commands” was the BO/VBO Generators. Basically my goal was to add the capability for the developers to create flat BO or VBO from database tables.

Early on into the work I mentioned about DAO and how simple it would be. After working for a few days to see how I could do that I gave it up because I could only see myself doing what I did in the past with my actual OR/M project.

I have also concluded touching DAO would side track me from Smarties 2008 project all together. Believe me when I say this I have a weakness when it comes to DAL because I’m so passionate about making this process easier.

There are three main approaches that I think of for creating DAL. Before I talk about them let me explain or sell using Business Objects to you instead of the conventional way of using DataSets.

There are millions (exaggerating of course) of Software Development principals that one need to follow to reduce risk of failure. The more you know the more you realise how painful software development actually is. One of the SD principals is to have an object template that represents an entity within a domain i.e. Employee. My biggest problem with DataSet class has always been it cannot be defined as an entity.

Picture this if you will, you have a method called ProcessEmployees(DataSet emp) that accept a parameter of DataSet type. If you are going to expose such method to consumers then each method that accept DataSets needs to check if the DataSet contains all the correct attributes for an Employee. This is a nightmare for sure.

With strong BO types you never face such fundamental issues. It would be ten times more difficult to create DAL with BOs than using DataSets but all is worth it. If you use the same approach all the time and more or less use the same database engine then you can always spend a quality time designing something that you can re-use for the next projects as well. This is another software development principal. The extra time you spend always pays back ten times more at later time.

DataSets can come to rescue when the structure of data is not known until runtime (late-binding). A good example of that would be the GetSchema() methods of Connection providers.

As I mentioned before there are three main approaches for creating DAL for application systems. These are:

• Direct Interaction with ADO.NET
• ADO.NET > DAO Helper > BO
• OR/M

Direct Interaction with ADO.NET

In this approach you would code against ADO.NET directly which you would end up writing the same kind of routines all the time. The hardest part would be populating data from DataReader to BO and writing that boring insert routine. I believe I can add supports to Smarties 2008 for this. Writing this article has already given me some fresh ideas that I would conclude them at the end of this article. I’m thinking loudly now.

ADO.NET > DAO Helper > BO

In this approach you would use a DAO Helper i.e. Microsoft Enterprise Library to avoid writing the same routine to interact with the backend database. In this approach still populating BO on data fetch events are a pain.

OR/M

It does all you need from generating the BO, BO Collection Types and DAOs. OR/M doesn’t exactly reduces the number of methods you need to write for data operations since you still need to write the routines to instruct the underlying OR/M framework what to do but the routines you write are far more easier than the ADO.NET > BO. There are disadvantages in OR/M such as synchronisation, dependencies i.e. mapping, and losing over 60% of its power in web environment.

You can be assured that all above approaches have pros and cons therefore no one can say for certain which one is the best. Considering the size of database, deployment environment, and what you want to achieve makes one of the above approaches to stand out but for others it might be the worst approach.

I know of many developers that are totally arrogant towards OR/M and I know of I.T. Managers that would use DataSet in an Enterprise System for the sake of DTO.

I know one thing for sure I never use DataSet in place of BO and I have refused to work on projects that the man in charge wanted to use DataSets in the past. I’m not an advocate of Linq either and I doubt it very much Linq has brought any true advantage for the developers except for the fancy lambda expression which will be limiting where as in my opinion OQL (Object Query Language) can handle more object queries. When Linq is part of framework itself then you have to wait until the next release to see more lambda expressions support. Then once you use the new expressions you cannot re-use your code (investment) in the previous version of .Net Framework. It might not sound a big issue to you but in business world it is.

What I have achieved with my OR/M project was this… You could run virtually all SQL aggregate functions and mathematical functions in memory (Client-Side) to avoid hitting the database server for the simplest operations. If I’m not mistaken Linq supports some of the SQL aggregate functions in memory too.

When you fetch a record set from database the data will resides in the client machine. If you wanted to get an average figure from one of the columns then you would have to write a routine and run it against the database that has the same where clause and joins to get the result back. It made a perfect sense to me that the lack of support in the client-side causes system to hit the database far more. We developers are not going to be immune to the “green” campaign and one day we are required to write ‘greener’ software. Hitting the server for a small operation is not ‘green’ at all. You might laugh at this but one day Microsoft will issue guidelines on how to write greener software, remember where you read about this first.

I have predicted long time ago Microsoft’s attempt to OR/M would be the same with DataSet. I had a chance to look at vNext ADO.NET long time ago and it really scared me how much mapping I had to do to get it to work and also how many layers are in place to handle simple operations.

I really think Microsoft should stop adding certain things as part of .Net Framework because they can’t simply do a good job, not because of technical incompetence but because of the Framework nature which has its draw backs too. The ADO.NET 2.0 provider model is great isn’t it? Well 99% of it but it can fail just because of the 1% implication involved with different data types in database engines.

The nightmare (it is really) is the Parameter’s type. Each provider knows how to handle its own Data Type enumerator when is used but universally the DbType is not truly compatible with all the providers. To make this to work you need to add a new layer in between to do the mapping when writing DAL that meant to support multi-platforms. The OR/M developers write their own provides on top of ADO.NET to handle this one issue. The .Net Framework did not server its purpose very well with data providers.

What is DAL?

Data Access Layer is made up different objects that each server a purpose. In general there are Entity (BO) that stores a single row of database table, Entity Collection Type that stores a collection of table rows, and DAO (Data Access Objects).

DAO’s responsibility is to have all the data operations either specific to an Entity or to act as a helper class when the entities in DAL have been given the responsibility to handle their own data operations. I recall numerous discussions about DAL models which are Domain, Entity, and Direct Table a couple of years go. No one came out as a winner because simply one solution doesn’t fit all problems.

Personally, I don’t like entities to have any knowledge of how to interact with the backend database for two reasons, security and loosely-coupled. When you place all data operations with DAO then you can introduce security. The Proxy pattern works very well with DAOs. A proxy class is like an object but is not the object itself. You can also think of a Proxy class as a wrapper around an object.

The best way to understand something is to use a real world example. You are responsible to write a DAL within your organisation and distribute it to different departments which in return the developers within each department write their own UI on top of your DAL API. Within your organisation each department have different access rights to database tables. For instance HR can modify an Employee record but Accounting Dept. can only view or make very limited updates to the Employee table.

The first thing you’d notice is that if the Entity had the knowledge how to interact with the backend database then the developers in each department can do all sort of things with the Employee table. This is where Proxy classes shine. You have two choices now. First choice is to create one proxy class for each department and limit the members you expose in the proxy class. The second choice would be to implement a security check against the user login credentials in the proxy class to see if he/she can execute methods.

How Smarties 2008 can help?

If an OR/M is not a solution and BO is a must then there isn’t much option available to ease up the process. Smarties 2008 version 1.3.0 supports nine database engines to create BOs from database tables. The supported databases are MS SQL Server, MS SQL CE, MS Access, Oracle, Firebird, Sqilte, PostgreSql, MySql and VistaDB.

Smarties 2008 can help ease up the first two approaches by creating rich BOs and BO Collection types. While I’ve been writing this article I had some refresh idea that could ease up the first two approaches even further.

After all I might be able to work on DAO that I know would save developer a lot of time. My mistake was thinking OR/M and multi-platform database support in DAO that I originally meant to design. I can now narrow this down to the database engine that the developer is using to create the Business Objects. With this approach I can write all the routines for populating BO on data fetch events and write that boring insert routine.

One of the unique capabilities of Regionize process engine of Smarties 2008 is that it can Regionize a single member too.

I made it a principal of mine that the Regionize feature of Smarties 2008 must support this capability. I didn’t have a use for it at the time of my decision and obviously couldn’t see all the conditions (thousands of them) at the time but I normally get a distinctive feeling about something from time to time that tells me if I should do something or not.

I’m very pleased to say once again my distinctive feeling worked out as a reliable tool for me. In fact Regionizing a single member has become a vital capability for Smarties 2008 itself and very convenient for its users.

If you have used Smarties 2008 in the past and happen to know about other productivity tools then obviously you must have realised most tools wouldn’t Regionize the newly created members by the tool itself but 99% of the cases Smarties 2008 does. This means when you are using other tools that have similar refactoring features for instance you are left with the job of Regionizing the members by yourself. If this is a one off job then I wouldn’t complain about it either but when you are doing it as a routine in your new projects it becomes annoying and time consuming.

Picture this scenario if you will, you would Regionize a class first then manually add your own custom #regions to them. For instance under the #region Method Members you would create a child region named BL Methods. If you to Regionize the same class again the BL Methods will disappear because it was listed under a parent region that the Regionize process engine considered it as its own. In such scenarios you have to re-create your custom #regions again. Annoying isn’t it?

I haven’t assumed users would never create custom-regions inside the regions that the Regionize process creates. Therefore if you are adding new members by hand you can Regionize them without losing all your custom #regions. However, you would still lose the custom regions by the Regionize process engine too but only under the root region where the member is moved to, I’ll explain why that is shortly.

Any tools that don’t support Single Member Regionization would lose all the custom-regions under the root regions that it created unless the regions are being marked by a symbol to avoid that. Smarties 2008 never removes custom-regions that are placed in root of a type definition during the Regionization and also never mark regions with symbols to tell them apart.

Personally I never liked the idea of enforcing my users to Regionize the entire class because a new member is added. Once again my distinctive feeling says there are users out there that they wouldn’t want to Regionize the entire class more than once. Beside the point, would you reconstruct the whole building from scratch if you wanted to add a wall in one of the rooms?

The Regionize process engine reconstructs only the root region and its child regions where the single member is going to be moved to. Do you recall the constraint values and other conditions such as the sorting orders that you can apply to different members from The Regionize Process in Smarties 2008 post?

When you are adding a new member to an existing root region it may or may not meet the constraint values that you have specified also you might have changed the constraint value since the root region was created. For this the Regionize process engine reads the entire members and adds the new member to be processed to figure out how members need to be grouped and listed. The finishing result would be exactly as if you Regionized the entire class again without actually doing it.

As you might know I have recently added a new grouping kind called Field-Property to the Regionize process engine. This grouping kind lists encapsulated fields along with their properties under a separate root region. Single Member Regionization can even support this group kind.

Since Single Member Regionization can be a vital capability for some users I’d try to see how I can preserve the user-created regions inside of the root regions that are created by the Regionize process engine in the near future.

I had identified two main issues with organising members soon after I started working on the Regionize process:

1. Every member kind that can be described is unique in its own rights.
2. Type Definitions cannot have the same Regionize profile or Code Layout.

1. Every member kind that can be described is unique in its own rights

Member kinds cannot be seen as the same because they have different characteristics while not compiled. A property with getter and setter are two methods when the project is compiled but in your code files you can easily distinguish between a property and a method. 

Due to this fact every single member kind is handled by different part of the process engine to ensure maximum flexibility and extendibility. For instance Custom Events are handled totally differently than Non-Custom events. 

Even though event-handlers are methods the Regionize process can see them as different kind of member that it needs its own unique way of grouping. Event-handlers have common characteristics in how they are named. The names can be split into two identifiers. The first part tells the type the event is a member of and the second part tells the name of the event itself. The Regionize process engine can optionally group and list the event-handlers by the type the events are a member of. 

I hope using the above examples gave you the idea how actually member kinds are different and how the same member kind can be seen as different member kind that needs it own way of listing and grouping.

2. Type Definitions cannot have the same Regionize profile or Code Layout

To explain this better I have to talk about grouping members a bit first. If we use Methods as an example, we can group this member kind in the following ways; 

1. By Visibility
2. By Abstract (MustOverride in Visual Basic)
3. By Override
4. By Overload
5. By Interface Implementation
6. By Virtual (Overridable in Visual Basic)
7. By Access Scope (Instance or Static/Shared)
8. By custom constraints such as the attributes the method declared

Smarties 2008 currently does not support No. 8 grouping but it has been scheduled to add supports for 1.1 version release. 

All of the above method groupings would be listed under a parent #region. For instance to Group methods by their visibilities you would have a parent #region called Method Members and for public methods you would get a child #region called Public Methods. For abstract grouping a parent #region called Abstract Members is created then all methods would be listed under Method Members.

Now that you have the idea what I mean by grouping members we can go back to the second issue. 

I always use Microsoft Enterprise Library projects as an example when I want to talk about the real world example. When you have a single Regionize profile or Code Layout that describes how members are grouped then the same rules is applied for each Class, Structures and interfaces in your projects. The Microsoft Enterprise Library solution contains nearly 3,500 .cs files.

Obviously when you get into Regionizing your members you would get to this point where you do not want to apply the same kind of grouping to all type definitions in the project. For instance, would you want a class that has methods with public visibility only to be grouped and listed under the Public Methods #region? Of course you wouldn’t but the Regionize Profile/Code Layout will do it if the option was enabled.

My first attempt to solve this problem was by introducing profile management where you would create a profile and then add the code files that you would wanted to be Regionized against it. 

Even though I worked on this feature very hard without being regretted I have taken it out from Smarties 2008. There are things that would look good in theory but in real world they are so impractical and my approach was one of them. The Microsoft Enterprise Library solution was the reason that I knew for sure Regionize Profiles or Code Layouts wouldn’t be a practical solution because as a user point of view I had to create dozens of profiles or code layouts to cover a big solution like Microsoft Enterprise Library.

Smarties 2008 meant to be all about productivity and I noticed the Profiling approach would actually decrease productivity by forcing the developers to create and manage the profiles or to force them to accept a single profile for life. Even though in my approach the developers didn’t have to learn anything to setup a profile I still found it too much to accept the whole thing. The developers that I have worked with during Smarties 2008 development had neither the time nor the patience let alone wanting them to do the extra work for something that meant to be automated.

To solve this problem I came up with the idea of introducing a constraint to each process that creates a #region. The constraint is an integer value that represents the number of members, the number of visibility kinds, the number of member kinds, and so on.

Going back to the Methods again, you can now instruct the Regionize process engine to group methods by Method Visibility only if there is n number or more visibility kinds to be found. This only means when you are Regionizing from a single Type Definition to the entire solution the constraints are checked against every Type Definitions and the Regionize process engine can group members differently with a single call.

I have implemented the same idea over all kind of members that can be described. Setting up the conditions is as easy as checking and unchecking boxes or increasing or decreasing the constraint values. During the total rewrites of the engine I have also added supports so that users can specify their own sort orders almost for everything the Regionize process engine does. In my humble opinion the way the current Regionize process engine works will cover over 95% of your needs which it has been the goal so far. As I have mentioned earlier I have scheduled to build more feature into the Regionize process engine to increase its capabilities and usability.

Happy Regionization with Smarties 2008

In the next blog post I’ll talk about Single Member Regionization.

I’m talking about #region directives of course. Region directives have been an underestimated feature of Microsoft Visual Studio for very long time now.

Warning! #region directives are highly addictive once you become a regular user giving it up would be very difficult. Between you and I, well and the rest of the world, I’m a regular user too. So as a regular user I would like to pass on my own experiences to you.

The ability to visualise code is an important aspect of programming because it helps a better understanding of the implementation part of the object template that one is developing. You would never draw an UML diagram to visualise the implementation part. The UML diagram would only have the pre-defined members such as the object’s attributes and/or the behavioural members but not the members that developer has to create to complete the object template. Please keep this in mind for a second. 

Something as simple as having larger white spaces in the document to create members can significantly help. The more members you create the more difficult navigation becomes.

To be able to visualise, navigate, and to expand the coding area I’ve been using regions for a long time now. Grouping members by their kinds under their designated regions helped with the visualisation part as well as navigation. Surrounding members with their own regions helped expanding the coding area as well as the navigation.

Many developers choose to outline control block of members to expand coding area and to help with the visualisation. The outlining approach has its draw backs. It is much harder to manage outlined members. Outlined members are very hard to look at in particular for users with astigmatism, like me. There is no grouping capability using outlining.

On the other hand regions gives you grouping capability and you can do further grouping by creating child regions as well as expanding the coding area. You can choose different sorting order under each region something that you can’t do this easily with outlined members. Its draw back is the labour work when managing them by hand.

I’ve been creating regions by hand despite it added the additional labour work for me. The benefit I got from it was worth doing it in this manner. Gradually I developed the basic styling that I could use for all type definitions but I couldn’t do more than that for the additional labour that I had to do.

The benefit of region directives was very obvious to me and I wanted a tool that can do that for me so I can avoid the labour work but have all the benefits I wanted, selfish huh? Not exactly because I ended up developing such tool myself, I was certain there must be many developers like me wanting the same functionality. The tool I developed is called Smarties 2008 you can read more about it on my site at MojabSofware.com. Internally Smarties 2008 is known as “King of Region”, simply because it adds so many capabilities to the region directives that always were missing in Microsoft Visual Studio IDE.

I was originally working on a different project for 18 months, without taking a single day off, until my computer broke down and it was sent out to be amended.  

Luckily, having a laptop around I had decided to develop a simple tool to ease up my project development. I was working 16 hours a day, on average, and I was so fed up with writing the same kind of code all the time i.e. declaring properties, implementing IDisposable, ISerializable, and organising the large number of members I was writing for each type definition.

The unwanted break from my original project made me realised that I do not want to do the same amount of typing ever again. The little tool that I meant to write turned into a fully blown project called Smarties 2008. Without being a bias, I can say if I had Smarties 2008 it would have saved me from milions of keystrokes.

I have no regrets my original project didn't go anywhere as I'm personally very happy to offer Smarties 2008 to other developers instead.