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.

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.

svn switch ^/branches/new

or merging the trunk

svn merge ^/trunk

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

1. resurrect your branch by copying the revision you want to roll back (here: 28120) to a new branch:
svn copy http://svn.domain.com/branches/new_feature@28120 http://svn.domain.com/branches/new_feature -m “restore temporarily”

2. in your local copy, undo the specific change (c -28120 is the same as -r 28120:28119):
svn merge -c -28120 http://svn.domain.com/branches/new_feature

3. the usual: build, test, commit.

Unfortunately, you have to do this in two steps and maybe it messes up your merge info a bit, but we didn’t find a better solution. Simply rolling back from the deleted branch didn’t work.

If creating software were like producing cars, then more people would mean more output. Somehow I have never seen that work. Ever since Fred Brooks it’s been accepted fact that there is a diminishing returns curve we are on in adding people to a project. I was surprised when I found this blog post that showed that research indicated that the optimum productivity is actually at very small team sizes (actually 4.6)

http://www.erpwiz.com/teamwork-productivity.html

Does it really confer rapid development benefits?

Definitely, it does. Even if the scaffolding path is left early and conventions are overriden to the own needs, the start-up period is very short, as we don’t have to care for many different technologies. That kind of lightweightness makes us work not only faster, but also more precise and clean.

Writing tags was never easier – while with JSF we first deliberate about whether it’s worth the effort, with Grails we just do it. To work testdriven and to achieve a high coverage rate is also made quite easy, although the different test cases and mocking strategies are sometimes inconsistent and buggy.

Switching from Java to Groovy is a great pleasure, we loved to have list and map literals, closures, builders, to throw away our boiler plate “map” implementation in Java and to write compact, meaningful and focused code.

What slows down the development speed is the not so perfect IDE-support, which also holds true for the IntelliJ plugin, that we use. The bad, often old and even wrong documentation scattered over different places (foiling the promise “the search is over”) gets also in the way of rapid development. So we often had to fall back to source code reading – subsequently being scared by the underlying Spring class hierarchies.

What we were doing is to use a Microsoft Business Intelligence/Reporting Server to report on data in an Oracle production database.

Creating the OLAP cubes in the MS system, everything worked fine until I tried to pull in aggregate data over a date field from the database, giving me the mysterious “Not a legal OleAut date” error message that can be found in the various forums, but none in the context of OLAP cubes.

It’s not brain surgery to determine that somehow either the Oracle schema did have a weird column type – that we could rule out because it was a regular timestamp(6) column which worked nicely in other places of the cube – or the data itself was corrupt.

We started to look at the data in the table with a minimum / maximum query

and were surprised to find the minimum date displayed as “01/24/10″. With month/day/year display this would have been January 24, 2010, wouldn’t it? We expected the data to go well back into 2006. A closer look on this anomaly showed the culprit: One single line in our 10 mio row table had a timstamp date of actually 0010-01-24 instead of 2010-01-24. With the date display cut short to 2 digits, that was hardly noticable. I *am* a fan of ISO 8601!

What the error message was trying us to tell: The date was stored in Oracle allright, even if it were in ancient times, as Oracles datetime and timestamp can represent all dates from January 1, 4712 BC to December 31, 9999 AD. But the Microsoft SQL Server will do only January 1, 1753 to December 31, 9999 AD.

That’s what triggered the error message, once this one row was fixed, the error was gone. If I were Roman Emperor, I’d buy Oracle. Else I’d think about setting up some date constraints in my schema to prevent bogus data from entering – we didn’t find out how this could have happened, so better make sure to have your constraints in place before the bogus data comes along!

In case you wondered why 1753 – I had thought about the Boston Tea Party (wrong, that’s 1773), but actually according to Wikipedia this was the first full year after Britain had adopted the Gregorian calendar. Spain did in 1582, protestant Hannover in 1700, Greece in 1923. I sure do hope Microsoft has not localized too much.

We are running an MS SQL Server Reporting Services server for some internal reports on the Oracle production database. Nice enough report generator. Now, I have done more than just some MS Access in prehistoric times, and constantly feel reminded of that “put these 120 line SQL query into the puny little properties textbox and it will do what you want” type of development. Things have definitely improved over that with MS Visual Studio 2008 and the report designer, but then, without prior notice, I was struggling with Visual Basic…

I was trying to make a text output for the report header, formatting a string parameter as a date, and the current date in case the input parameter was NULL. Simple enough? Have a look:

Looks good, does it? Should work, shouldn’t it? Doesn’t.

DateTime.ParseExact() doesn’t like to be handed a null (VisualBasic: “Nothing”) value, and the IIF() function can’t prevent it. It actually is just a function as any other function, and before it gets called, all parameters have to be evaluated: Thus the DateTime.ParseExact is executed despite that was what I was trying to prevent. The “Nothing” check is futile, DateTime.ParseExact() is evaluated before IIF() is called, and throws the exception anyway. Feels like a “real” ternary operator, but is just a function.

The fix needs to introduce a guaranteed non-null date string even if it is never used:

Alternatively, you could convert the Now value back into a string, to pass into ParseExact. Ah, the hoops they make us jump through!

There is an equivalent problem in Oracle, if you will: COALESCE() will stop evaluating once it found a non-null value, NVL() will first evaluate the second argument as well.