alex in a nutshell

It’s such a good feeling to finish a long project. CommSec Cash Management was an interesting project to work on. Put simply, it’s a self-contained bank within a bank, offering high interest savings and transactional accounts, Debit Master Card, Internet banking, full back office capabilities and integration with existing CommSec’s trading products and Commonwealth Bank’s existing payments systems.

Building such a thing from the ground up was quite an experience from professional point of view; it was a long project too (started prototype in August 2007, started development in September 2007, pilot in April 2008, went live for public in June 2008).

Two weeks after launch - no major issues, which is even a better feeling.

…now I just need a holiday before starting to work on a new assignment…

I’ve been using MS Enterprise Library on a number of projects. There are several blocks that used more often than others. I find validation block particularly useful. However, I usually like to tweak it a bit. The thing I don’t like is when you want to validate an object you require to write a substantial amount of code:

Validator<Customer> validator = ValidationFactory.CreateValidator<Customer>();

ValidationResults results = validator.Validate(customer);

Also it’s possible to create a validator for another type and validate an object with it without any problems, errors or exceptions:

Validator<WRONGCLASS> validator = ValidationFactory.CreateValidator<WRONGCLASS>();

ValidationResults results = validator.Validate(customer);

This feature is for flexibility, however, I haven’t found a need to use it the way it was intended. On the other hand I have encountered a number of situations where developers copy-pasted code responsible for creation of a validator without changing the type of a target object. This results unexpected behaviour during testing.
In order to fix this every business object is derived from a common parent BaseBusinessObject class, which has the following method defined:

public ValidationResults Validate()

{

Validator validator = ValidationFactory.CreateValidator(this.GetType());

return validator.Validate(this);

}

As a result, validating an object is now a lot simpler:

customer.Validate();

Usually it makes sense to have a base business object class anyway, so it’s not much of an overhead.

As of November 6, 2007 I will no longer be an independent consultant at Commonwealth Bank of Australia, my workplace for the past 18 months. I’m not going to another organisation, however. I’m switching to a permanent position of Application Architect instead.

I’m excited!

We’re using a customised version of Cruise Control, hence we all stuck with old one-per-project Cruise Control Monitor (v. 0.9.1.940).

Major hassle for me is to monitor a number of projects in tray. This version doesn’t support multiple project configurations with only one entry in the config allowed for a project:

<?xml version=”1.0″ encoding=”utf-8″?>
<CruiseControlMonitor xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://www.sf.net/projects/ccnet”>
<PollingIntervalSeconds>15</PollingIntervalSeconds>
<ProjectName>Name-Of-Your-Project-Here</ProjectName>
…

As a result, every time I restart a machine I need to start 4 instances of CCTray and manually select corresponding projects from a list. Annoying!

Simple fix is:

• Create multiple config files, with just ProjectName entry being different
• Create however many shortcuts to CCTray you need in your Startup group and specify a corresponding config file as a parameter
• Enjoy the view of multiple CruiseControl Monitors sitting in your tray:

Mitch Denny’s and Paul Stovell’s posts on frameworks are thought-provoking, especially because I’m in a beginning phase of a rather big project. We have layered architecture with UI, complex middle-tier that talks to a number of external systems and DBs.

We have a number of developers on the project with the same number to start in next few weeks. After initial launch I expect 50-60-70% of staff to be moved to some other projects with new (and, most likely, junior) developers taking over their positions.

Do we need a custom framework on top of what .Net provides? Yes.

Do we need a framework even if it’s going to be outdated tomorrow? Hell, yes!

Why do we need any framework at all?

1) Consistency of development process. I don’t want new starters to invent a wheel and create their own solutions. Framework can be verified, tested, performance-tested, approved by architects. Do I have a luxury of trusting every developer’s judgment on everything? Not on a large project.

2) Efficiency. I want developers to productively write code (mostly UI and business logic) and don’t worry about plumbing, validation nuances, etc.

Are we going to write everything ourselves? No. We’re going to re-use as much as we can. This brings a second question:

Adopting external frameworks. Is it good?

.Net provides a lot of stuff out of the box, however, not everything. Validation, Data Access and control library are obvious weak points that require addressing on pretty much any project. Tracing and logging can be extended way further than standard implementation in order to be really useful in n-tier systems.

So, re-use third-party or write your own? I have seen projects where everything was written in house as a principle, including reporting engine. It took a lot of time and was inferior comparing to what’s available on the market. Yes, the framework did almost 100% of what’s needed and was written with specific project in mind, but it had its own limitations, just like any other framework in the world. It would have been more efficient development-wise and beneficial to customers to utilise existing libraries.

YAGNI principle teaches us that we should not over-engineer for future as we won’t need it most probably. I think this principle is being violated more often during in-house framework development rather than during third-party framework re-use. Given a choice between utilising 20% of Enterprise Library or writing these 20% ourselves, I’m going to opt for the first option because it’s faster and does the job. I’d rather use it as a base and write a little bit of custom tweaking code on top of it when required; it’s more efficient this way. For example Enterprise Library Validation block doesn’t support cross-field validation. Fine! I can write it within the scope of my project, but at least I don’t need to write the entire validation framework.

Seriously, what’s the problem with utilising 20% of a large-ish third-party framework? After all, code re-use isn’t such a new concept.

VS.Net add-ins are being installed by default to My Documents\Visual Studio 2005\AddIns folder.I’ve got a roaming profile at my work computer and My Documents folder is located on a remote drive, which, in its turn, causes all the add-ins to fail during load due to trust issues.

Simplest solution is to move add-ins to a new location and then change your VS.Net 2005 settings via Tools >> Options >> Environment >> Add-in/Macros Security:

Hit OK, restart your Visual Studio and voila!

We’re writing a new framework for our new project and decided to use Enterprise Library Validation Block as the foundation for user input validation. It worked out really well; we’re building a library of our business-specific re-usable validators. With unit testing in place, it’s heaps better than using any validation inside the forms.

There is one question that puzzles me however - why the hell decimal isn’t allowed as a parameter in attributes at CLR level?

24.1.3 Attribute parameter types

The types of positional and named parameters for an attribute class are limited to the attribute parameter types, which are:
- One of the following types: bool, byte, char, double, float, int, long, short, string.
- The type object.
- The type System.Type.
- An enum type, provided it has public accessibility and the types in which it is nested (if any) also have public accessibility.
- Single-dimensional arrays of the above types.

I’m sure CLR guys had their reasons, but since I haven’t found any documentation about that topic I’d like to know the answer.

Using double and internally use Convert.ToDecimal isn’t n option I’d like to pursue.

I’m a shareware author and that implies a lot of email-related routine. Since I hate routine tasks, I’ve been looking at ways to streamline my emails workflow lately. Here is what I mean by routine tasks. Each shareware author sells his software over the Internet via one of the online sales providers (Regnow, RegSoft, Plimus, ShareIt, etc.). Whenever somebody purchases your software you receive an email with order details - product purchased, number of copies, total, GST/VAT, user name, address, etc. Your regular routine is:

1. Check email
2. Copy user name from email into Clipboard
3. Run Code generation utility
4. Paste user name and number of licenses into the code generation utility
5. Click Generate code button
6. Copy generated code into Clipboard
7. Create an email based on a template for particular product
8. Enter user name into the email
9. Paste generated code
10. Press Send button

The most important bit is that you have to be physically present in front of your computer in order to perform the above mentioned 10 steps. What if you want to store the user details in the database or check customer’s email against previous orders to offer a discount? More routine!

As a software developer I can write my own email processor. While it’s an option, I see it as a waste of time. Then Biztalk, perhaps? It’s nice and easy for a programmer, BUT with Standard Edition’s price of US$8,500 it’s not really an option for many people. Here is the alternative - Advanced Email Parser (AEP).

Why? First of all its cost. It starts at US$400, 1/20th of Biztalk’s price. Enterprise license costs double that (AU$999 + GST in Australia). Compare that with the cost of BizTalk Server 2006. Secondly, AEP is quite simple to use, user doesn’t require programming skills to create simple solutions. However, you may require a skilled programmer in case of complex business processes integration (various back-end systems, databases, web services, etc).

Here is how I can fix the above mentioned problem of processing an online order for my shareware program Quick To-Do Pro with AEP. (more…)

I haven’t been blogging in August, but I can’t say I’ve been on holidays. Quite contrary. It’s been quite stressful during last couple of months. Stressful, but rewarding in the end:

Picture quality isn’t great as it was an unexpected surprise and it was a coincidence that one of my team members had a camera on him. Thanks, Jaffer!

Here is what it looks like on my desk:

Pre-compilation of ASP.Net web sites gives some nice benefits out of the box. For example,

1. Faster response time for users, since pages and code files do not have to be compiled the first time they are requested. This is particularly useful on large sites that are updated frequently.
2. A means to identify compile-time bugs before users see a site.
3. The ability to create a compiled version of the site that can be deployed to a production server without source code.

Let’s discuss these points.

1. It’s a nice feature to have but there are other tools to hit every page of the web site as after deployment which will achieve the same result. Moreover, web site testing tools like Selenium can do the same job as well as verify the functionality according to pre-defined tests.
2. If you’re using a tool like Selenium, this is covered. Also, nothing is stopping you from integrating pre-compilation into your build process for the sake of checking for errors, but deploy the original version if required. And integrating Selenium or any other similar tool into your build process will do a much better job.
3. This is only required if you deploying to a client and want to keep your intellectual property protected. It doesn’t apply to a lot of cases.

By now you probably sense my antagonism towards pre-compilation. Why? Because of the deployment restrictions it creates with regards to hot fixes. Even if you pre-compile for deployment and update, this is what can be done with the .ASPX files:

You can change the layout of .aspx files and add elements that do not require code, such as HTML elements and ASP.NET server controls without event handlers. You can also add new .aspx files, which will be compiled normally on first request.

Which basically mean that you can hot fix a typo in HTML mark up, but that’s about it. No code changes at all!!! Consider this before you implement it in a corporate environment, where every change requires authorisation and deploying the new version of the entire pre-compiled web site is not an option outside of scheduled release process.