Sunday, December 5, 2010
Wednesday, September 29, 2010
Consider the current working version (x) sacred – the upgrade process should not touch it because you always need to provide an option to roll-back to (x) – perhaps even a couple of hours after the new version (y) has been deployed. Design hint: when upgrading, lay the new version (y) along-side and not on top of version (x). This implies a migration of configuration files at the application layer and data migration at the data layer from version (x) to version (y).
In a high-availability environment, consider is it possible to run both version (x) and (y) concurrently – this is to support the concept of a rolling upgrade where you upgrade each node in turn.
By far, the trickiest part of designing an upgrade process is considering evolutionary changes to the data schema. New tables, columns or constraints may have been added. You need to pay close attention to changes to the schema during development and always think about what this means for the migration of existing data. It’s usually a good idea to embed the version number in the name of the schema/database.
It’s essential that data created with the old version (x) is available with the new version (y) – but also, ensure that the operations the system provides on the data exhibit a consistent behavior where expected.
Wednesday, September 22, 2010
The presentation was entitled "From whiteboard to product launch". The intent being to share my teams experience in bringing a brand-new product to the marketplace. It covers a wide variety of areas including process, architecture and team organization.
The slides are available here and the audio is available here (I recommend you flip through the slides while listening to the audio).
Monday, December 29, 2008
Monday, December 8, 2008
Thursday, December 4, 2008
Wednesday, November 12, 2008
In the past, I have used the forward engineering features of Hibernate for this very purpose. Once the tables have been created in the database, I take advantage of a neat feature in JDeveloper where you can reverse engineer a data model diagram. So the process kind of goes like this Object model->Java code->Hibernate DDL->Database->Data model. It worked well in thrashing out the data model for my last project. Of course, it may not work for everyone but that’s ok – it works for me and that’s all that matters ;-)
For a new project I’m working on, I thought I’d try something different. I thought I’d give Grails a spin. This worked even better because Grails can generate such a lot of boiler-plate code for me enabling me to move a lot faster. It can also generate a scaffolding UI so I can interact with and test out the model. Here was the process:
- Download and install Grails from grails.org
- Follow the Quick Start guide to familiarize yourself with Grails http://grails.org/Quick+Start . During the Quick Start guide, you will learn how to create an application a domain class and a controller
- Configure Grails to use Oracle instead of HSQL (I needed to externalize the database so I could browse it and reverse engineer the data model diagram using JDeveloper) – to do this modify grails-app/conf/DataSource.groovy – change the driver class name and the JDBC url – you may also have to copy the Oracle JDBC driver (ojdbc14.jar) to the lib directory
- For each entity (where name is the name of the entity you want to model)
$ grails create-domain-class
- Modify the generated class located in grails-app/domain/name.groovy – add the attributes
$ grails create-controller
- Modify the generated controller class located in grails-app/controllers/nameController.groovy – change the body of the class to look like
def scaffold = name
- Run the application
$ grails run-app
- Point your browser to the application
- Populate the model by interacting with the controllers through the generated scaffolding
- Add some more entities by going to back to step 4
- If you want to auto-populate the model with data on startup, add your code to grails-app/conf/BootStrap.groovy