05 April 2008

ACCU 2008 Conference

Disclaimer: These are my interpretations of what I learnt from the talks rather than a transcription of what they said. This means that I probably misheard and misinterpreted some parts which may be hazardous to your health.

DisplayLink were very generous and allowed me to attend the ACCU 2008 conference this year. I chose to go for Wednesday and Thursday's talkhttp://www.blogger.com/img/gl.link.gifs, but next time I plan to attend the whole conference. I thought I would present some thoughts on those talks I did attend.

Overall it was well worth spending the time at the conference, meeting a variety of interesting people. I know people always say you learn more in the bar afterwards but I would say there would have to be some pretty intense knowledge exchanges to beat the information I picked up over the two days.

Value Delivery For Agile Environments
Tom Gilb
Slides

I can sum up the talk in three words "Measure Measure Measure". Tom Gilb used his keynote to explain EVO, an envelope framework to surround a smaller development-centric process, which was in this case Agile. He sees Agile as deficient in that it is a development process geared for delivery, but less thought is put into what you actually deliver.

The problem comes then with what do you measure, how you measure, and then how do you interpret those metrics. By doing this and combining it with a fast deliverable methodology like Agile then you end up with constant iterations with feedback able to deal with the changing nature of the world (most probably defined by requirements).

I felt that the talk had an implicit feeling of "How To Survive". You need to identify your stakeholders, the people that determine the success and failure of your project and make sure that the needs of the most important and influential ones are met. If they like what you are doing by meeting and possibly exceeding their needs then you are more likely to gain extra resourcing as you are then seen as a successful group.

Bits And Mortar
Ric Parkin

Like an extended episode of Grand Designs we were taken through an analysis of buildings. Well, no not really, but some of the theories that we are using in computer science have been looked at before and not only recently, in a completely different problem domain, and this field is architecture (and the evolution of buildings).

I'm not the world's biggest fan of analogies because pedantics always want to poke holes in it and take it off course thus negating any benefit from using it. I wish I never used analogies but I am like a lemming following everyone else. Luckily there was a thoughtful audience and the core was suitably abstract to avoid those problems.

The basis of the talk was the work of an architect Christopher Alexander. He posited the theory of patterns which obviously directly relates to what engineers are doing right now, and in fact sometimes he doesn't even refer to architecture and buildings.

Due to my ignorance all of this was completely new to me, and I could take a lot away from the talk because a lot of the ideas of the evolution of a building (and therefore design) is directly applicable to the realm of computer science. If you look at a building as a finished intransient product after it has been completed then you forget about the lifetime of the building and how it evolves much like a codebase. Knowing when to rebuild or rip-down parts requires suitable knowledge of what you are doing and you can also apply patterns other people have proved to be successful subsequently.

Unfortunately (for Ric) the talk will be forever remembered as the place he uttered in public "I don't mind introducing bugs".

Practical Multi-Threading
Dietmar Kuehl

This talk covered the basics of the new C++ standard. It was a packed room so a lot of people are interested in this area.

It certainly looks like writing multithreaded applications will be much less code in C++ than it has traditionally been. I like the idea of getting more functionality for less code. Items like condition variables will be supported in the C++ Standard Library. There was also a brief part about some of the TR2 features (C++0x + 1) like futures which makes using concurrent processing of independent blocks of code even easier and simplifying the synchronisation.

Also some of this will be helped even more by the lambda expressions as I can see some of the simple operations can be kicked off and calculated independently on a single line.

Also there was some coverage of Intel's Threading Building Blocks which provides concurrent containers and also concurrent algorithms like parallel_for or parallel_reduce. This all provides some higher level semantics for expressing the concepts of multiple threaded processing.

When Good Architectures Go Bad
Mark Dalgarno

This was more of an interactive session where people's experiences fed directly into the talk, so it means each time you would hear a write-up about it there would be a different opinion. Luckily my group had some interesting anecdotes. I do wonder why we all stay working in computers if we suffer this much abuse(!)

We used our experiences of the world to come up with examples of where the architecture had begun to "smell" and what this represented. Then looking at case studies we attempted to identify and find potential solutions to eliminate these smells. For my example of a system that had been going for a very long time through so many different platforms, teams, languages, I said to cancel it because it was not making enough money to warrant its existence.

The most frightening solution to architectural decay which also came up at the SPA conference when Mark did it previously, was "Kill The Architect". I thought I was cynical(!)

This was a talk where you got more out of it if you put more into it. Hopefully Mark will put up some of the responses he got from the audience on his blog. In fact he could probably write a very frightening book about it.

Caging The Effects Monster: The Next Decade's Big Challenge
Simon Peyton-Jones

Unfortunately due to beer-and-lack-of-sleep-related circumstances I decided to close my eyes in a darkened room for the duration of this talk. I did not feel too guilty as I had seen Simon's talks for the BCS SPA Cambridge meetings. I posted about that talk here.

The functional programming track at the ACCU Conference seemed to be really well attended and seems to have grabbed the imagination of a number of people.

The Future Of Concurrency In C++
Anthony Williams
Slides

This talk was hosted by the maintainer of the Boost.Threads library. He went through some of the more complex parts of the upcoming C++0x and C++0x TR2 as well as what is available through Boost.Threads currently.

One of my favourite parts of the entire thing is the concept of thread-local storage as a built-in keyword. No more GetTLS and the suchlike. I could immediately see a use of a static member of a class that is per-thread in order to create a memory allocator for STL containers which would allocate via only the thread's heap. If you know that some information is local to a single thread then you won't have any memory contention (in the program - I am not thinking about the hardware or underlying implementation) to slow down the memory access. You have to have a clear design and use of this though otherwise you could blow your program's brains out, but also that design works very nicely with thread pools...

Unfortunately some of the higher level concepts will take until probably the next standard TR2 to get to compilers. Of note this will contain thread pools and futures. Futures mean you can run a thread for a calculation and start it off in a single statement and thehttp://www.blogger.com/img/gl.link.gifn check the result after doing some more work and it will wait until the result is posted. Also getting the result will then propogate any exceptions that had occurred on the calculation thread.

The good thing is a large portion of the C++0x threading implementation is available through Boost.Threads thanks to Anthony's sterling efforts for 1.35, so you can always have a play.

Adobe Source Libraries : Overview And Philosophy
Sean Parent
Adobe Source Libraries (ASL) Open-Source
Lots of interesting papers and articles
Alexander Stepanov's collection of papers, articles and presentations

I can think of worse things to be remembered for but I hope that Sean Parent is not only thought of as Alexander Stepanov's boss. He heads up the Software Technologies Lab at Adobe that create generic libraries that are used in all Adobe's products. This talk was divided into two sections, one concentrating on the data structures and generic programming, and the other about declarative UI.

A very interesting part of the talk is the way he said he was using Alexander Stepanov's skills, he basically said "Write a book defining generic programming". The research for this has lead to lots of leaps forwards for Adobe's programming technologies. Also he said that Stepanov gives lectures to the Adobe programming staff to improve their education.

This talk started a little above my head by defining Regular Types which is very similar to the definitions and rules for what can be derived for functional programming except you can have side-effects. This then provides the basis for generic programming.

We had a close look at the ideas behind the Move library currently maintained by Adobe but could go (back) into Boost. This library uses Return Value Optimisation to minimise and eliminate copies, and I was surprised to learn this was through the use of passing by value rather than by reference.

There was also a look at the copy_on_write functionality which meant the object is only copied when it is written to and it uses the move library as part of its basis. This also provides the platform for Adobe's history tool in Photoshop and minimises memory impact. Then there was a look at the Forest container which approaches the binary tree in a very tidy way. Also they have a string library that uses the move library so concatenations are much more efficient.

They are the right tools to solve certain datatype problems in a very concise and efficient fashion. But the idea behind it all is to only use small pieces of code as building blocks towards the larger solutions. What they want to do is reduce the number of lines of code declaring the applications by a very large factor (like from 3 million to 30,000).

The second half of the talk was based around declarative UI and the structures Adobe have put in place to solve problems that still exist to this day. I've looked at the two main libraries that make this up before called Adam and Eve, where both really amount to being constraint solvers, one solving the data and one solving the layout.

The layout library is probably the simplest to explain as it works out from the size algorithms you provide the layout that follows the guides that have been set up. This also means that it can scale the layouts with relative ease. The scripting language is used to define the layout called Eve.

The property library is used to solve data dependencies (a lot of which are typically cyclic) for user interfaces. I have used something similar but much more simplistic in the past because it keeps the data separate from the UI itself. This also means that you can script the operations.

The papers and documentation on the Adobe site can probably explain all this much better then I ever could, but they are al interesting building blocks for solutions to some overlooked problems.

Overall I enjoyed the talk especially the first half as it was a bit eye opening their practical approach to implementing generic programming with real benefits. Unfortunately the talk was really badly attended considering both halves were up against some tough competition (especially about functional programming), but hey they all missed out on some really good stuff.