A day in the life of...

Seeing as I haven't had enough free time to write part 3 recently I thought I'd post this little teaser. Would it surprise you to know that this very diagram generated into code and I was able to run it? The signals on the ShowWelcomeMessage had to be hand coded, but hopefully I will be able to get some kind of custom code generation plugin to get the signals auto generated in future.

Here is a list off the top of my head 1 - Ugly code! Why do some people set local variables to null when they have finished with them? This is .NET! The garbage collector will collect "unreferenced" objects when it is ready, an object is unreferenced if you no longer use the variable that holds the reference to it! Why do people name variables so poorly? Firstly I *hate* Hungarian notation. C# is a strongly typed language so I cannot multiply a boolean by a string, so why do people use variable names like "bIsMale" and "iAge"? 2 - Catching all exceptions An exception is something you expect to happen, but shouldn't happen if all goes well. If such an exception occurs you might know how to solve the problem and enable your application to continue, but if the exception type was unexpected how can you possibly know the cause of the error or what state your application is now in? Therefore I hate code like this try { DoSomething(); } catch { } 3 -

Going beyond wizard interfaces If someone had said to me "Process oriented application", in the past I would have thought to myself "Wizard-like interface". Whereas I find "Wizards" very useful in certain situations I also find that they are too time intensive for a user who knows what they want to do, how to do it, and just want to get on and do it! The thing is, I think an application layer should be process driven. The business objects layer is there in order to represent the logical business entities of the application, and the application layer should be there to drive the logical flow of the users' interaction with those objects. So, the question is "How do we implement a process oriented framework without enforcing a wizard-like interface?" The answer I think is to use Signals. Signals The process may imply that there is always a specific path through an application. Although the user may influence that path by selection options

An onion has layers... ...Shrek In the beginning When I first started writing applications they would typically be a single program editing a single datasource. As time went on this changed because people wanted to share data, so client/server applications appeared. It didn't stop there though, N-Tier applications became much more common. Applications were typically split up like this: RDBMS--DAL--Business classes--UI Due to the fact that I use ECO for my business layer , and that ECO has the DAL built in, the illustration for me would look something like: RDBMS--Business classes (ECO)--UI Thinking of business problems as classes instead of tables really helps to simplify your design, so I have been very happy writing applications this way for some time now. The application layer In December 2005 I was tasked with the job of writing quite a complicated Compact Framework application. Although this application was going to be complicated it needed to be very simple to use, as the

I've been writing an app for the compact framework for some months now. It's quite a complicated app that includes an object persistence framework, a task oriented application layer and a loosely coupled GUI which is generated through factories (the app only has 1 form, but lots of user controls + factories). The app has been experiencing apparently random OutOfMemoryExceptions, no matter how hard I have tried I have found it impossible to reproduce one of these errors. I have spent quite some time really optimising the memory useage of my OPF so that it works on the bare minimum of memory yet still operates quickly enough (and I'm very pleased with its performance too). However, the OOM exceptions persisted! I wrote a logging tool which records the last X actions the user performs, when an unexpected exception occurs this log is written to disk along with a stack trace of the exception. I noticed that the top of the stack trace always read... at Microsoft.AGL.Com

This is just a copy/paste of a reply I made in a newsgroup, but I think it is quite informative so here it is.... KEY Square brackets denote a class [Person] Rounded brackets denote a role (Pets) Let's say you have a Car class and a Garage class, an individual car is regularly serviced at a specific garage so you have the following association [Garage] (Garage) 1----0..* (ServicableCars) [Car] Car.allInstances->select(Garage.Code = '1234') The above OCL will fail because "Garage" is a class so the parser is expecting stuff like "allInstances". So you might think this should work Car.allInstances->select(self.Garage.Code = '1234') but it doesn't because "self" refers to the root object and not the object at the parsed node where it is specified. This is what aliases are for: {aliasname} + {pipe} Car.allInstances->select(currentCar | currentCar.Garage.Code = '1234') This was possible in Bold too (native wind

I've been reliving my childhood and playing with WinVice, a Commodore 64 emulator. A friend and I were working on a game at the point the C64 died and it never got finished. We recently dusted off those old 5 1/4" disks and finally worked out how to get it working again! If anyone fancies taking a look you can find it here http://noname.c64.org/csdb/release/?id=33963 Be warned though, it really was unfinished. Some rooms lead to dead-ends and there is no way to quit the game, so the occasional reset (of the C64) + reload is required!