dottodotnet

A work colleague and I recently attended the University of Nottingham Jubiliee Campus, to present a talk to second year Computer Science students that were taking part in the group project module. The talk was entitled 'What's it like to work in an agile software development team?'.

The talk focused on how the Esendex development team tackle software development, and we presented some ideas for the planning and development aspects of their own group projects. I did the same module when I was an undergraduate at Nottingham and the module stands out for me as the closest thing you experience at university to working as part of a real software team in industry.

It was tough selecting exactly what to put in the talk, 'agile development' is a broad subject and means different things to different people. We could have easily talked about the Agile Manifesto for the 50 minutes we had, but in the end I think we did well cherry picking the parts that would interest the students and be relevant to their group projects. We also thought it important to run through a demo of some of the concepts we talked about and this part was especially received well.

We carried out a 'mini retro' at the end of the talk, asking the students to leave some feedback on their way out. We split the board in two; 'What went well?' and 'What could have gone better?', providing the students with some post-its and pens. We were very pleased with the feedback, as you can see the feedback was 90% positive :)

You can't see the comments on that pic unfortunately, but here's some I've cherry picked...

Content truly excellent! All highly relevant & interesting, right level of detail.

First live demo from a guest lecturer :)

Great to see a live demo, putting theory into context.

Actually related to the group project.

Students might have struggled following the detail of some examples. Slow down a little. Font size & colour, for demo.

Here's the slides if you're interested, looking forward to getting invited back again next year hopefully.

git clone --recursive REPOSITORY_URL -o REPOSITORY_ALIAS

• --recursive - Gets the submodules too
• --o - Sets an alias for remote repo rather than defaulting to origin (useful when working in teams)

A neat script for retrieving database size in MB. I found it useful for checking on Amazon RDS instances.

SELECT table_schema "Database", SUM( data_length + index_length) / 1024 / 1024 "Size (MB)" 
FROM information_schema.TABLES 
GROUP BY table_schema ;

Most developers construct a DataContext within a using statement to make sure that resources are cleaned up when leaving the block.

using( var dataContext = new LinqDataContext() )
{
   // Perform some data operations
   dataContext.Insert(obj)

} // Dispose of the DataContext and release resources

However it's not needed, the .Net garbage collector does that for you and the need to dispose of the DataContext is made less of critical requirement knowing that LINQ DataContexts do not keep expensive database connections open (something that surprised me) like some other ADO.Net objects.

To summarise, it isn't the end of the world and you aren't a bad developer if you don't dispose of your DataContext objects. I do however think it's good practice to work with IDisposable classes in this way; plus it releases those resources slightly quicker than just leaving it to the garbage collector.

Zzzzzz....

Start-Sleep -s 5 # 5 seconds
Start-Sleep -m 5000 # 5000 milliseconds

PowerShell has two kinds of errors; terminating errors and non-terminating errors

Terminating errors are the errors that can stop command execution cold. Non-terminating errors provide an additional challenge, as you need to be notified of failed operations and continue with pipeline operations. Powershell by default tries to continue when non-terminating errors occur. Something I don't want to happen when I call Powershell with my CI server to release software. If there are errors I want the script to stop and tell me what is wrong - not the script to continue and report that everything went OK.

$ErrorActionPreference is a variable that describes how PowerShell will treat non-terminating errors. $ErrorActionPreference has four self-explanatory options:

• Continue (the default)
• SilentlyContinue
• Inquire
• Stop

To exit your script with an error code (if an error occurred), you'll need to exit using the $LastExitCode variable. This variable returns a number that represents the exitcode of the last script or application, needed for your CI server to know if the script ran successfully. Here's a template for what I use with the Jenkins CI server...

$ErrorActionPreference = "Stop"

# Do something...

exit $LastExitCode

Anything else?

Well, yeah... $error is an array of all the errors that have occurred in the current session up to the number specified in $MaximumErrorCount. Also, $? is a boolean value that is $true if the previous operation succeeded and $false if it did not.

Commands are created by a client, put onto a command bus for the server to process in it's domain. Commands are simple messages/requests to mutate state. It's not about editing data, but about performing tasks. Commands are always in imperative tense (present), asking the system to do something. As they are in the imperative tense, they are essentially questions and as the language suggests, the server has the right to refuse.

Command handlers handle these commands and are simple facades/coordinators over the domain below and methods should be thin; like MVC controller actions. Behaviours should be pushed down to the domain below and not exist in the handlers themselves. As each command changes state, it also typically results in events being pushed onto an event bus for recording and processing by event handlers.

Commands and events are very similar in design, only differing by their intentions. Events are described as verbs in the past tense. As the language suggests, it has already occurred, so no point in throwing exceptions. However, you can come up with a counter event. Event handlers typically insert data into denormalised database tables in the query database (the read side) but can perform a range of other tasks, such as send an email.

We've been having some 'difficulties' with Jenkins the past couple of weeks. This whitepaper from the guy that wrote most of the Jenkins core code looks like it could be interesting... 7 Ways to optimise Jenkins/Hudson.

Commands mutate state and trigger events which describe the changes which have occurred inside the write store. It is the responsibility of the read store to subscribe to these change events and update their read store appropriately (using event handlers).

All application queries from end users are made to the read store, which can be anything from a relational database to XML files. This data store is simply a thin read layer that's heavily optimised for reads. Each application's data view (think view models in MVC), typically maps to denormalised data tables rather than using joins (which slow down queries and prohibit scaling without headaches).

That's it, in a nutshell! The read side is a lot simpler than the write side of CQRS and something developers are more accustomed to. Working with denormalised data rather than third normal form makes queries quick and very easy to maintain; something for the junior devs :)

Consistency is over rated!!!

In a CQRS system, making a write does not immediately change what is read.

This is why CQRS systems are described as offering eventual consistency. CQRS evangelists question the importance of real-time consistency. They argue that by the time end users see data it is already stale. FOr example, requesting a data object via a web app results in a series of delays before the data can be displayed to the end user and hence is to a degree stale i.e. retrieving data from the data store, populating a DTO, returning data in a web response, page rendering in a browser.

I think I agree and if this is an issue for you, I suggest you question the importance of real-time consistency for your business. I'd argue that there is a time period/delta that for which in-consistencies can be tollerated and hidden from the end users. However, I do think that efforts should be made to keep this to a minimum and perhaps this delta should be actively monitored, especially for systems where it matters (e.g. a message system with high SLAs).