In 2008 the Labour government at the time tried to pass an unjust File Sharing law. The resulting NZ-wide Internet Blackout, inspired by the Australian blackout, made a huge difference, and forced the bill to be reviewed.

Now in 2011, the National government is trying to pass a relaxed, but still unjust, File Sharing law. I have already blacked out my social profiles, but it's time to step it up a notch. Over this weekend I will be blacking out all my websites (http://jevon.org http://openiaml.org and others). If you have a site or online profile, I encourage you to do the same.

For more information about why the law is unjust and what you can do to protest, check out the Facebook page, the Twitter #blackout hashtag, or Creative Freedom NZ.

EDIT: You can see what my websites looked like while blacked out at http://jevon.org/blackout.html.

I'm currently at the student-run NZCSRSC 2010 conference, and was the host of an abruptly-chosen unconference session, based on Robert O'Callahan's keynote talk, "Making an Impact". The big things we discussed were:

Firstly, what is impact? The question was proposed, what research can you think of has made an impact on society? Conversely, what research hasn't made an impact? It's difficult to decide what is "good" and "evil", particularly in the context of societal impact; and in technology, new knowledge will generally be reused in unexpected fashions.

The major point that came across is that openness is good. In particular, aspiring researchers should start a blog where they can disseminate their research and forge relationships. Open access journals are becoming the norm, but if you can't access a particular article (because your university doesn't subscribe to a particular access model, you should send an e-mail to the authors, as it may be possible to get a copy that way. Consequently, publishing online is also good. In many cases you can republish your work online academically, with the correct copyright notice.

I totally agree with this - this is why I have tried (somewhat unsuccessfully) to keep a blog going, and (successfully) publishing my contributions through openiaml.org and under an open source license (EPL).

Finally, an important skill is to be able to evaluate and discuss your own work, even in the case of negative results. I personally prefer research publications that present at least one negative result, as this shows the author is not completely emotionally attached to their work. This is a hard thing to do, but very important.

Since openness and blog publishing were discussed so strongly, I thought it would be a sensible idea to publish the concepts discussed.

I've always been curious about obtaining useful (and pretty) statistics from my Subversion logs in my project, both the implementation side and the research side. But I hadn't found anything useful, until this afternoon.

Today I had a go with StatSVN, which analyses your development logs (and hammers the SVN server a little bit to get all the diffs) to create some pretty graphs.

So now you can see the development history of IAML as of r1808 (today).

The lines of code graph is interesting, although in this case, LOC is a measure of the physical lines of code - so this includes whitespace and comments. I also like the graph of developer activity.

Once I get an automated build script working, it would be pretty neat to add this as an automated task

Is checking out your Google Code-based project slow over Subversion? Apparently it's a known issue since November 2009, but the fix is pending...

I was interested in improving the performance of my test cases, so I decided to write a few profiling methods so I can analyse what is taking the most time (the first fundamental rule of optimisation: know what to optimise). The preliminary results (executed only on a single large test case of 9 test methods) are interesting:



13% of the time is spent inferring model elements;
54% of the time is spent executing code generation;
4% of the time is spent copying previously generated (cached) code generation files;
and 29% of the time is spent actually navigating the generated application.

However, these results are affected by the code generation cache. If I only consider the first test method (i.e. there is no way to reuse previously cached information), I get a more accurate representation of the necessary time for a single test case (which does very little web application navigation):



Here we can see the initial inference time and the initial code generation time - notice they are identical (in seconds) to the overall test time.

If we remove these constant costs, we can get a picture of the average cost per test case:



12% is spent loading from cache;
11% is spent waiting for AJAX calls to return; and
70% is spent navigating around the application otherwise.

More investigation is necessary to actually see which parts of my tests I need to focus optimisation on (by profiling the entire test suite, for example).