Apart from simply distributing the share of work and apart from parallelizing preparation as well as oral presentation, my impression is that lecturing in pairs has positive side effects similiar to pair programming:

• better discipline, better flow: It is easier to fight off disruptions or to get back to the topic after disruptions (e.g. students questions, unforeseen complications with the students OSs etc.)
• mentoring, sharing knowledge: The knowlege you share is not only more details on the topic you are teaching, but also knowledge about the teaching process itself – as you watch how your pair talks to the students, how she partitions the topics, how she words the tasks and how the students react, you can adjust your own teaching style. This is learning by doing at its best.
• better quality, less errors: As the passive pair lecturer has a distant view on what is being said, she is better able to add details and corrections – thus improving the lecture quality. And of course the different focus of expertise allows for a more comprehensive presentation. Complex topics can even be presented in a dialog style.
• fun: No matter how bright you are, it is always fun to work together with like-minded people. If you have fun, you will convey the enthusiasm for your topic. Students will be better motivated, hence teaching will be improved.
• confidence: Shy people need extra backup to talk in front of a crowd. Having a fallback helps.

As for CouchDB itself: The workshop preparation was an excellent opportunity to dive into the principles of non-relational databases, especially schemaless key-value-stores. Apart from the CAP-theorem and the idea of resigning consistency in favour of availibility and partition tolerance, I am also excited about the option of having data and application together – thus disposing the need of manually keeping application versions and data migrations in sync. Can’t wait for a real world project to try CouchDB!

That’s how I made it…

This is the Lilypad board. The alligator clips are connected to a temperature sensor and a three color LED, the red adaptor links the board via USB to the computer to upload the code [Get it here]. Coding is done in C++ in a processing-like environment.
You only need to specify what should happen in the setup and in the loop phase, the arduino magic takes care of the rest. This let’s you start really fast without knowing anything about hardware programming!

The LED (having three inputs for red, blue and green) glows blue if it’s cold…

… like in this box of frozen peas. Testing hardware is much more fun than testing software!

When it’s hot, the LED turns red. In between there’s a gradient from blue to cyan and from yellow to deep red.

The sewn on board (middle), sensor (left) and LED (right). At the bottom of the board there’s a hole to hide the ugly battery on the back of the shirt. On the top of the picture you can see the layout of the circuit. It’s important to have a design where the cables (or, for Lilypad, the silver threads) don’t cross too often, because it makes sewing easier – you have to isolate each crossing.

The first few stitches with the silver thread, leading away from the positive pole. This was surprisingly easy, because the thread is really soft and not at all like wire.

The first circuit is finished, connecting the board with the sensor. Using alligator clips to check if it’s still working… and it is! The LED shines yellow.

The reverse side of my shirt after sewing everything together. I used band-aids to isolate the threads. Note the long stitches – those are connections running mainly on the back side and covered with tiny silver pearls when coming to the front. Having all stitches on the front side would have made it impossible to make the shirt look like three flowers growing next to each other, it would have just looked like a circuit. I also added some petals (using normal thread in purple and turquoise) to make it look prettier.

And yes, I really do wear it! Only feels a little bit nerdy… and there’s a switch on the board to turn it off.

The problem is, that Converter provides no way to determine which drawings have been added. So I tried the following, like I would have done in Java – subclass the Converter and add the needed methods.

But I can’t override the AddDrawing-Method, because it’s not marked as virtual in the super class (and I can’t change the super class). Now what?

I chose to factor out the conv.AddDrawing(drw) part of the original method in a new method “AddToConverter”, create a TestService class and override the new method there similar to how I planned to do in the TestConverter. Leads to more methods that need to have less restricted access than I’d like to… bäh.

In all other classes I still think that the only use of regions is to find which parts of a class should be extracted into a new class

Luckily, there’s ReSharper, a great tool for visual studio, that let’s me use all the shortcuts I know from IntelliJ IDEA.

But as all the rest is so new and exciting, be prepared for a lot of beginner’s posts about C#, Team Foundation Server, working off-site and alike.

rlwrap is a wrapper that uses the GNU readline library to allow the editing of keyboard input for any other command. Input history is kept between invocations, separately for each command; history completion and search work as in bash and completion word lists can be specified on the command line.
rlwrap compiles and runs on most Unix(-like) systems, including cygwin.

Get it here

The architectural design patterns Alexander describes cover problems like: how to design an entrance situation, how to choose an appropriate building height and how to make streets that are a pleasure to walk along. Each of the patterns is not very complex in itself but by adapting it to a specific context and by combining it with others it unfolds its potential.

From an architectural theory point of view the patterns are an expression of postmodern design thinking and an antimodern reference to the past. It is critized that design patterns lead to eclectic application of past architectural style elements such as a column there, a porticus here and funny roof and window shapes everywhere. This postmodern spirit of the 80s can bee seen on every street corner. The kind of criticism described for architecture can’t be applied to software code directly for obvious reasons. But every now and then in legacy code you will stumble about some pattern which seems to be applied out of context – just as eclectic as an unexpected column, which seems to be there just because someone wants do demonstrate that she knows pattern 123 (columns near entrances are a good thing) and to show off her detailed knowledge about the greek doric column system.

In architecture the strong tradition of theoretical reflection leads to constantly evolving new design approaches. As a consequence the design pattern method was consigned to history together with the early postmodern style. That may be one of the root causes for the phenomenon that today design patterns are better know to developers then to architects and building engineers. I even thought for some time, that Alexander had picked the idea of design patterns from some computer science book and adapted it to the built environment.

I was amused to see that design patterns were brought back to architecture in 2007 by computer scientists themself: Some folks defined patterns for building hacker spaces. Allthough they are concentrated around organizational and financial questions they also cover spatial and architectural topics such as the Kitchen Pattern.

That makes a total of “Generic Attribute Registration Protocol Virtual Local Area Network Registration Protocol”. Wow.

svn switch ^/branches/new

or merging the trunk

svn merge ^/trunk

Before that I always did svn info, copied the path, etc. etc.