The Guest Lecture - Part 1
Thinking back to my days learning computing science as an undergrad I remember a number of guest lectures that I was encouraged to attend. These were invariably delivered by some learned expert in a particular field. Their experience and knowledge were deemed so invaluable that they would be invited to impart some of that experience to a group of students in the hope that they might absorb some of it.
I remember attending several of these. Some of them I understood. I don’t think I ever understood their significance however. I certainly never thought I’d ever be giving a guest lecture myself! I’ll say more on this and Perfect Image’s involvement in giving lectures later.
In particular I remember a number of guest lectures from members of something referred to as ‘industry’. These were different to our usual lectures since as well as teaching us a particular subject, the speakers would frequently make reference to software development in the ‘real world’. In particular they would frequently attempt to impress upon us the difference between our own university projects and software development in a commercial environment.
Based on my own experiences I now understand exactly what they meant. My degree course taught me about computing science, whereas now in my profession I develop software; the two are different. Does this mean that my university didn’t teach me the right things? No, of course not; computing science teaches you the fundamental principals of a huge topic, and arguably commercial software development is just one specialisation of that. Had I chosen a career in aerospace for example, I would have been equally prepared. The job of the degree program director is to distil this huge topic into the bare essentials for a wide range of professions whilst teaching the fundamentals that all programmers should know. The fact that I don’t need to know how a compiler works in order to do my job doesn’t mean I shouldn’t have been taught it in the first place.
I think that is one of the real values of guest lectures: it allows students to experience a specialisation of what they are learning, be it used in academia or any sector of industry. Just a few weeks ago Perfect Image gave its first university guest lecture, courtesy of Codeworks and Sunderland University. The lecture would form part of a series organised by Codeworks, and it fell to fellow developer James Allen and me to deliver it.
Getting involved in guest lectures has been one of Perfect Image’s goals for some time. Our marketing executive Sarah Maluila had been trying throughout 2008 to secure us a slot with one of the colleges and universities in the region using the tagline “to educate and inform the North East”. The breakthrough that led to the lecture came in October when Codeworks offered us a lecture spot with Sunderland University.
Neither James nor I had ever delivered a lecture, although between us we did have a bit of teaching experience. Naturally we had been on the receiving end of quite a few lectures and from the outset we both knew we wanted to avoid giving a dry lecture and instead to deliver something that would encourage participation and discussion. The big question was what subject to deliver the lecture on!
Over the past few years we have improved our development process through the adoption of a number of practices and technologies. We are strong advocates of an agile development process and as such have adopted many patterns that complement this approach and encourage better quality software. Examples of these include: the model view controller and model view presenter patterns; inversion of control containers and dependency injection; various object relational mappers; test driven and behaviour driven development; and domain driven design. Our experience is that such approaches have resulted in the delivery of superior products in a reduced time, and therefore much of the time spent initiating new graduate developers is used to teach them these methods. Most graduates have little or no knowledge of these techniques as they often cannot be covered in detail by degree courses because of their specialist nature. Any of these subjects would therefore be an ideal candidate but we had to keep in mind that we would only have an hour to cover the topic. One hour is not a long time to teach anything, and we didn’t want to have to rush through the subject, so in the end we opted for a much simpler concept.
The lecture would focus on testing, and in particular unit testing with a view to introducing test driven development. The goals were to familiarise the students with unit tests and show how automated testing could improve the quality and readability of your code. Although there is documented evidence that a test driven approach can improve the development process, it would still be a tall order to convince students – who only one hour earlier – might never have heard of unit tests at all.
To be continued....
Nigel
MSpec
Here at Perfect Image we have just switched from using Test Driven Development (TDD) to Behaviour Driven Development (BDD). The library we have chosen to use for writing our BDD tests is Machine Specifications (MSpec). It’s a great framework and if you are interested in doing some BDD yourself you should take a look at it here and download it from Github here.
This was actually the first time I had used Git and it took some getting used to as a SVN user but after a little resistance (and moaning) I found it’s actually pretty easy to use. Don’t be put off by the command line interface, it does have a GUI but I actually found it best using bits of both. There are plenty of tutorials out there on the web to help you out too.
MSpec includes its own test runner whereas before we used MBUnit. We had no problems wiring it into our NAnt build scripts to work with NCover. It even produces a nice HTML output of the results from the tests ran. The only issue we had was that it did not have the option to produce an XML output which we needed to be able to display reports in Cruise Control .Net - our Continuous Integration server.
My team leader James had looked at the problem a little and was able to point me in the right direction to start off, which saved me having to track down the significant code in the project. What I ended up having to do was add an option to the runner for an XML output and then add the functionality of mapping the results to XML. Luckily, it is very similar to how the HTML is produced so I was able to use that as a skeleton to base my work off. The XmlWriter made this very easy to do:
public void Render(XmlWriter reportBuilder, Dictionary<string, List<ContextInfo>> contextsByAssembly)
{
reportBuilder.WriteStartDocument();
reportBuilder.WriteStartElement("MSpec");
if (_showTimeInfo)
{
RenderTimeStamp(reportBuilder);
}
RenderAssemblies(reportBuilder, contextsByAssembly);
reportBuilder.WriteEndElement();
reportBuilder.WriteEndDocument();
}
...
private void RenderAssemblies(XmlWriter reportBuilder, Dictionary<string, List<ContextInfo>> contextsByAssembly)
{
contextsByAssembly.Keys.ToList().ForEach(assembly =>
{
reportBuilder.WriteStartElement("assembly");
reportBuilder.WriteAttributeString("name", assembly);
RenderConcerns(reportBuilder, contextsByAssembly[assembly]);
reportBuilder.WriteEndElement();
});
}
The XML structure itself was very simple. Basically, all you need are nodes for assemblies, concerns, contexts and specifications. Each of these has a name with the specification also having a status to show whether it passed or failed. I also added a section for displaying the time when the report was generated so that it looked like this:
<MSpec> <generated> <date>23 October 2009</date> <time>17:37:05</time> </generated> <assembly name="MyAssembly"> <concern name="MyClass"> <context name="When doing something"> <specification name="should display something" status="passed" /> <specification name="should also do something else" status="passed" /> </context> </concern> </assembly> </MSpec>
Now that we had an XML output to work with, an XSLT was needed to create the report page on the Cruise Control project page plus another one to produce a little summary box for the dashboard. Being the first XSLTs I had written, they were far from being works of art but they were close enough to the original HTML output, give or take some questionable colour choices (James made me pick magenta, honestly). All that was left to do was to tell Cruise Control to add the contents of the XML to its log file and display the summary and full report using the XSLTs which were uploaded to the server.
This is how the summary looks on the dashboard:
And here’s how the report page looks:
At this point we were finally in a position where MSpec gave us everything that we had when we were running TDD tests on MBUnit and so we thought it would be a good idea to contribute back to the community.
This is where I was really impressed by Git. I was easily able to make a branch of the project on Github and then commit my changes to this branch. Then it was simply a case of sending a pull request to the owner of the original repository, Aaron Jensen, and waiting for him to respond. A few days later, I received a message from Aaron saying he liked my additions and after I corrected some differences with the formatting, they were added to the trunk.
You can now see for yourself if you are running the latest version of MSpec. Just add “--xml <filepath>” to your MSpec command. The XSLT files were added in the misc folder if you wish to add the reports to your Cruise Control server also.
Barry
