Gen-related

Christmas presents

What would I like for Christmas ?

A brand new Jaguar (can’t afford that)

A second-hand Jaguar (can’t afford that either)….

….think….

I’ll settle for no call-outs over the Christmas period due to system failures. OK – It’s one of these Christmas presents that you know you are gonna have, but are happy when you get it !

Gen systems are among the most stable systems I have ever worked with and their stability never ceases to amaze me – which is why on Christmas morning my mobile phone will be off and no call-outs need to be taken!

Christmas – sooooooo predictable !

Evil under the sun – but many moons ago!

Discovering a bug this week in a piece of CA Gen code that I’d written (many) years ago made me wish I had tools like “VerifIEr” or “Model Analyser” years ago.

The behaviour was that a local view I’d assumed was keeping its value wasn’t and I worked out why very early on, but it still cuased a latent problem.

Stupidly, I’d clicked “Initialise on every entry” on a local view which was wrapped up in a CA Gen batch program.

If I’d had VerifIEr or Model Analyser all those years ago, we could have found that out and fixed it through a proper automated code review.

What’s the evil ? Simply not having enough tools to review and find issues with your code at the time you write it OR not enough testing.

Put simply – tools like Model Analyser and VerifIEr save SOoooooooo much time !

Data model consistency

One of the strengths of CA Gen is the fact that it can manage your data model fron end to end. There are however dangers in NOT doing this.

Consider a situation where a site adds a new entity to the data model – the database team then add that table and a few indexes to the the database (independently – without using retransformation).

The development team then code the application around the new entity, test it in various environments and it goes into production.

However, the database team have to modify the DDL for each environment (because they need to tweak storage parameters, for example), and they accidentally misspell a column name when they apply the change to the production database.

The application is going to fall over.

OK – perhaps this says more about a site’s configuration management than CA Gen, but it does point to the fact that if you let CA Gen produce your DDL and apply it to a database, you will have more confidence in the consistency of the Logical Data Model and the Physical Data Model (i.e. your entities and your tables)

Let CA Gen do its’ work for you !

Now – if only we could import ERWin schemas into CA Gen…..

CA Gen on Wikipedia

The CA Gen entry on Wikipedia is sometimes the first time people come across information about the toolset.

Wikipedia is a collaborative encyclopedia, so t’s possible to add information to the entry to make it more complete.

Take the time to view the entry and edit it (it’s really easy!) and add to it – links, features and so on all make the entry fuller and more compelling to read!

See if you can fill in the missing Jigsaw piece!

Another effort-saving idea for CA Gen programmers!

In IET’s blog, they often come up with bright ideas for CA Gen developers.

The latest is no exception – here, they talk about an alternative mechanism for passing data through many levels of chained action blocks.

The method they describe works, but also has a number of additional bebefits to those they highlight:

• Improving developer efficiency – not only does it reduce the number of changed action blocks (leading to quicker migrations) but reduces the risks of “getting it wrong”.
• In environments where ALL changed action blocks undergo rigorous testing, reducing the number of changed action blocks will also reduce the level of testing required and hence improve efficiency of the testers.