ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Saturday 22nd April 2006

Saturday, 22nd April


Concurrency Requirements

Hubert Matthews

Full details to be announced


Producing Better Bugs: a satirical look at bugs in software

Roger Orr

We who attend the ACCU conference have written many, many lines of code over our combined working lives in IT. The statistics on the average rate of bugs per thousand lines of code imply that we have been responsible between us for producing thousands of bugs. This raises a number of interesting questions. What is a bug, and what makes a 'good' bug? Are we getting better or worse at writing bugs and do modern techniques of software design make any difference to our ability to produce bugs?

In this session I would like to answer some of these questions with a view to sharing some guidelines on how to produce better bugs.

Every stage of the software process is involved in the production of bugs: design, implementation and testing all have their own contribution to the task. I will describe the distinctive features that each stage has in the life of a bug and try to give advice relevant to each stage. This will help you to ensure that the right decisions are taken at each and every stage of writing a program to ensure that your bugs will be more interesting than average bugs; produce better 'war stories', be harder to find and harder to fix. We spend a lot of our programming life writing bugs - we should make sure as professionals that our time and effort is well spent.

Any programmer who has some experience of introducing, or removing, bugs. The examples shown will be mostly in C++ or Java but detailed knowledge of these languages will not be assumed.

Changing your organization

Allan Kelly

It sometimes seems that we all know how to do agile development. The books make it sound so easy, all we have to do is become lean and everything will be good.

But, how do we get from here to there? How do we change our organization? The big problem is: how do we change.

In this session Allan will consider how organizations change, he’ll present some ideas, some theories, some suggestions and ask the audience to share their experiences.

C# Traps and Tips, and Coming Delights

Jon Jagger

This is a talk in two parts.

Part 1 will present an assorted collection of lesser known C# traps. After diagnosing the pitfalls each trap presents I will discuss techniques for avoiding them. The pitfalls cover diverse areas of the language including enums, structs, properties, readonly modifiers, overloading, overriding, iteration, events, and threading.

Part 2 will present an overview of the new features in C# 2.0 (pragma directives, anonymous delegates, static classes, partial types, get/set accessibility, generic types, generic methods, iterators, nullable types, the ?? operator) and also some of the proposed new features in C# 3.0 (implicit typing, object initializers, collection initializers, anonymous types, extension methods, lambda expressions).

Buy, build or a bit of both

Seb Rose

Commercial-off-the-shelf (COTS) software is cheaper than bespoke developments, but it won't necessarily provide all the features that your customer may need. The trick is identifying which parts of the system can be COTS, which can be provided by customisation of existing software and which need bespoke development.

The session will use a case study of an internet home delivery service which utilised many forms of software procurement and integration. I may also throw in a few comments about building construction.

Practical Multi-language Generative Programming

Schalk Cronjé

It has been 6 years since the landmark publication of Generative Programming by Czarnecki and Eisenecker, yet few of those techniques have become internalized in the knowledge spheres of software engineers. In this presentation I distill a number of the complex topics down to practical application advice on how to use these techniques today. Some of these techniques might already be used subconsciously in some form by software engineers. I aim to externalize some of these techniques into practical examples which can very easily be applied by software engineers. I also keep it simple so that a team with just editors, compilers and XSLT processors can build generative systems without having to resort to any expensive or complex tools. This includes using XML to capture configuration knowledge, implementing components using generic programming techniques and glueing everything together using C++ traits classes generated from configuration knowledge.

Whereas C++ generic programming has primarily still been the domain of library writers, this session highlights the powerful, practical nature of generic programming in C++ in the development of enduser systems and also why it forms an important cornerstone for applying generative paradigm to C++. Likewise, in other languages there are some good language-specific techniques for separating concerns. As part of this session I'll try to demonstrate generative programming works very well in a multi-language environment and how it can glue heterogeneous components together.


STL Patterns: A Design Language of Generic Programming

Kevlin Henney

Patterns offer an effective way of capturing idioms, allowing programmers a way of communicating and reasoning about their designs through a structured design vocabulary. However, many C++ programmers are trapped in a view of patterns that extends only as far as, or not much further than, the 23 twelve-year old Gang of Four patterns. Useful and seminal as these are, they do not provide the modern C++ developer with a sufficient vocabulary to communicate and reason about their designs.

This tutorial focuses on the generic programming concepts expressed in and around the Standard Template Library, communicating these as C++-specific patterns and connecting them together to form a language that describes the design and use of the STL, illustrating how generic programming is more than simply programming with templates.

For the STL literate this tutorial offers a different way of looking at the STL and an introduction to more advanced pattern concepts. For the pattern literate this tutorial offers an example of applying pattern concepts to an existing and understood library.

This tutorial is intended for C++ programmers with basic knowledge of patterns and at least a little knowledge of the STL.

Get Testing!

Paul Grenyer & Steve Love

Easy session for those stuck on how to get started with Unit Tests. We'll look at the mechanics of writing tests in some different ways, and explore some differences between test harnesses for C++ programs and C# programs. And if you don't know the difference between your Mocks, Nulls, Stubs, Fakes and Shunts, we'll look at that too!

Large projects are those defined to be of more than 100 people.

Be prepared to contribute as the latter part of this workshop will focus on identifying other key techniques that you have used in projects that will scale up or down the size of the project.

Target Audience: people with an interest in or experience of leading teams or projects.

Test Driven Development with C# and NUnit

Richard Howells

This session explains how to apply automated unit testing to .Net code written in C#. We will use the open source NUnit tool, to provide software help in framing test cases, running tests and reporting results.

We will extend the idea of automated testing to consider how writing test code in advance of implementation code informs the coding process and allows the detailed design of the code to evolve as the code is produced.

This will be an interactive session and the audience will participate in code development using TDD.

Context as the Deciding Factor in IT Decision Making

Allan Kelly-MacGregor

When we have a range of technology options available to us we have to make a decision which meets a variety of criteria. Some of these are clear and quantifiable, such as the costs of procurement, support, deployment and development. Others are less tangible but receive as much or more weight in decision-making, such as the aesthetic judgements on programming languages, solution architecture and operating system. These aesthetic considerations can be justified, but it's often difficult to give an objective explanation of why we hold our professional preferences, or indeed to check that our preferences are correct. The answer lies in the context of the options.

Developing a generative library for hard problems

Oliver Kullmann

In my talk I want to present a specific generative library (the "OKlibrary") together with a general generative framework for C++ libraries. The OKlibrary delivers general concepts and generic components for a certain class of hard algorithmic problems (variations of so-called constraint satisfaction problems), and has to fulfil very strong requirements regarding efficiency, flexibility and generality. The part of the general framework I (likely) will be most concerned about is the generic framework for testing and efficiency measurement.

The framework for generic testing has as starting point the observation, that taking the notion of a "(generic) concept" serious, a library needs not only (somehow) to provide definitions of syntax, semantics and complexity of its concepts, but it should also provide means for checking whether some model (either provided by the library or by the user) fulfils these requirements. Regarding syntax checks, with the Boost concept checking library we have a kind of reasonable work-around for verifying syntactical requirements (which will become superfluous with C++09), but how could we verify the semantical and complexity requirements? For principal reasons, only partial verification is possible in general, and thus checking the semantical and complexity requirements boils down to correctness tests and complexity measurements, something every library developer is doing --- but yet only in the back office, hidden away from the clients!

So the framework I will present has testing components and measurement components as integral parts of the library. The aim is to use the same principles which guide our "main programs" also for testing and efficiency measurement --- programming is based on abstract concepts, and high reusability is the goal. Naturally, since test components and measurement components are meta-functions (where the parameter are the classes to be tested or measured), template metaprogramming plays an important role here.


Curly Bracket Family Fortunes

Jez Higgins

Full details to be announced. Or perhaps not...