Following up from my last wedding update, this is the location for the reception:
Here is the church Julia and I are to be married in:
James should recognise it: he drives past it daily to get to Massey. It’s the Aokautere Community Church, and is the reason we changed the date of our wedding to the Sunday.
Microsoft has just released a new font which is intended for programmers, check it out (and download it) here.
I’m not yet sure whether I’ll switch from good old Courier, I’ll give it a few weeks.
Let me know what you think,
Well, I don’t know if I ever mentioned it, but my wedding day has been pushed back by one day, to allow for Julia and I to get everything we want. It is now January 7th, next year.
In other news, I must thank the people spamming my blog with dubious trackbacks, it certainly is worthwhile advertising their garbage on this blog, as my 1500 total visits since January or so will most certainly be following these links 😛
For those out there that know of software engineering methodologies, I doubt you know of metrics-based development. That is understandable, it’s not something that we are really taught, in fact for me personally it’s something I made up just these last few months. I don’t claim that it is anything profound or earth-shattering (even to like-minded software geeks), it’s merely what it is: a way to develop software that puts emphasis on the improvement of certain code-level metrics.
Clearly, the ultimate program in this metrics-based methodology is an empty one. That is also clearly not a very good program, so I don’t propose that this methodology be the core development methodology. A better idea would be to use this as a ‘guiding light’, to get an idea of how a project is progressing over it’s development lifecycle.
To aid in this understanding, it is suggested that the metrics be run at least daily (which can be automated). Each day numerous calculations will then be made, resulting in plenty of graphs being generated dynamically every day.
On top of this, a number is calculated between 0.0 and 1.0 that states the ‘health’ of the project, as calculated by these metrics.
The metrics performed include:
* Unit testing (JUnit)
* Unit test coverage (Clover)
* Static source code analysis for code smells / antipatterns (PMD and CheckStyle)
* Source code dependency analysis (JDepend)
The real value in this methodology is in two key areas:
* The ability to get rapid feedback on the introduction of good or poor code.
* The ability to easily see improvements and deprovements of code quality in a visual manner.
Visually seeing change is far better than the old solution: reading 100’s of pages of automatically generated logs on a daily basis, assuming the code was being built daily. This is clearly impossible, and thus the ability to track project change at this detail is also impossible. Metrics-based software developments opens up this ability, in a very simple graphical way that anyone can understand (in fact, every graph explains the ideal direction for the values to go).
To make it clear, this exists: I am running this methodology as part of my research this year, and it improves visibility hugely.
What else can developers do to make their own lives easier?