Here's this week's blog update. Let's see if I have anything to say!
I keep getting beset by crises, but this week wasn't bad considering - I recorded over 2 days of actual planned development work in our time reporting system! Woohoo.
Ray's providing primary support for the VLE part of our Structured Content publishing system now. So when this week our system made a staff member cry, I wasn't there to see it. The bug in question wasn't really our fault for once, and we did a workaround. But it's the first time I know of that we actually made somebody cry in front of a developer because of a software bug.
(I have made somebody cry at work once before. But that was something I said, not a bug! Don't worry, it was a long time ago and we made up.)
The other crisis was that cron (periodic server tasks) kept breaking. The main thing cron does for ordinary users is send out forum emails, so apologies if you didn't get forum emails at some points... I don't think we actually lost any subscription emails (if it stays broken for more than 2 days, the old emails get discarded) but there were periods when emails were delayed for a rather long time.
The server team put emergency fixes in place, and I've done workarounds (maybe) for both situations now: in one case this appears to have been caused by file corruption [possibly due to attempts at simultaneous access to the same file], and in the other case by a syntax error introduced last release which for some reason hasn't caused problems up until now. We think this may have been slowing down a stats process because the error occurred about 27 million times each run, causing the PHP error log to reach 4 gigabytes.
Anyhow, back to development. For the dashboard back-end, I'm building proper unit tests; after I complete each little part of the code, I write a test for it. Coverage, i.e. the proportion of the code used when running tests, is currently at about 81%. Pretty good!
This should make the software quite reliable, but I think it about doubles development time, even though this is new code designed to be testable - something I didn't really take into account when doing estimates. That said, I always double estimates anyway, so this is only eating into that safety margin - the reason I'm behind schedule is not that things are taking longer than predicted, but that I'm getting less time to develop than predicted...
Developing with unit tests is a very different experience to most Moodle development (in most cases, doing comprehensive unit tests in Moodle is far too much hassle, because the structure / lack thereof isn't suited to it, and the PHP language also makes life more difficult). These unit tests all run on my system (in 0.7 seconds) without going anywhere near a Web server or database, something which is rather difficult to arrange in Moodle.
Although doing complicated tests can still be a bit tedious, I certainly wish I could work this way all the time...
New blog post
Here's this week's blog update. Let's see if I have anything to say!
I keep getting beset by crises, but this week wasn't bad considering - I recorded over 2 days of actual planned development work in our time reporting system! Woohoo.
Ray's providing primary support for the VLE part of our Structured Content publishing system now. So when this week our system made a staff member cry, I wasn't there to see it. The bug in question wasn't really our fault for once, and we did a workaround. But it's the first time I know of that we actually made somebody cry in front of a developer because of a software bug.
(I have made somebody cry at work once before. But that was something I said, not a bug! Don't worry, it was a long time ago and we made up.)
The other crisis was that cron (periodic server tasks) kept breaking. The main thing cron does for ordinary users is send out forum emails, so apologies if you didn't get forum emails at some points... I don't think we actually lost any subscription emails (if it stays broken for more than 2 days, the old emails get discarded) but there were periods when emails were delayed for a rather long time.
The server team put emergency fixes in place, and I've done workarounds (maybe) for both situations now: in one case this appears to have been caused by file corruption [possibly due to attempts at simultaneous access to the same file], and in the other case by a syntax error introduced last release which for some reason hasn't caused problems up until now. We think this may have been slowing down a stats process because the error occurred about 27 million times each run, causing the PHP error log to reach 4 gigabytes.
Anyhow, back to development. For the dashboard back-end, I'm building proper unit tests; after I complete each little part of the code, I write a test for it. Coverage, i.e. the proportion of the code used when running tests, is currently at about 81%. Pretty good!
This should make the software quite reliable, but I think it about doubles development time, even though this is new code designed to be testable - something I didn't really take into account when doing estimates. That said, I always double estimates anyway, so this is only eating into that safety margin - the reason I'm behind schedule is not that things are taking longer than predicted, but that I'm getting less time to develop than predicted...
Developing with unit tests is a very different experience to most Moodle development (in most cases, doing comprehensive unit tests in Moodle is far too much hassle, because the structure / lack thereof isn't suited to it, and the PHP language also makes life more difficult). These unit tests all run on my system (in 0.7 seconds) without going anywhere near a Web server or database, something which is rather difficult to arrange in Moodle.
Although doing complicated tests can still be a bit tedious, I certainly wish I could work this way all the time...