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!

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.

Me and its godparents from conject proudly introduce the little sibling of our first baby. Parents always love to show around the achievements of their little geniuses and make big plans for their future – so do we. Wassily (named after his famous Bauhaus role model) is really good with colors. For now his drawings decorate my fridge only and conjects Munic office, but thats where all artists start their carrier, right? Soon after he has learned some basic rules of composition, we will start preparing the portfolio for his college of art application. Some time you’ll wish you had snatched some of his early work.

Indeed there are a plenty of alternatives which do include all genders: People, folks, fellows, mates, buddies, pals … I’d even accept homies, although it originates in homeboy, but might also come from homegirl. Whatever is special about a group but valid for all members of that group may be used: hey hackers, freaks, late risers … are some of those, which would appeal to me. But I wouldn’t use late risers whenever there is an early bird in the group

So what about the option to add some female counterpart to the male part of the phrase to be more inclusive or to even point out mixed gender? We discussed guys and girls for our job announcement to make clear, that there are females among us. But the original meaning of girl is that of a female child – young, premature and dependent. Therefor it is not a proper equivalent to guy, rather the complement to boy, and many adult females don’t like to be called girl, at least not in a professional environment. The alternative being more similiar to guy in meaning could be gal, but that word is just as little a perfect match – some consider it sounding ugly (but does guy sound beautiful? – not really), it is not common in all english-speaking regions, it is considered old-fashioned in some parts of the world.

So we thought again about girl, because there seems to be a shift in its meaning recently. Starting with the riot grrrl movement in the 90s, third-wave feminism reclaimed the word. The derogatory use of the word girl was objected by removing the vowel and duplicating the r. That made-up word with the unspeakable growling sound said: You call us girls – yes, we might be girls, but not in the sense that you think of (well-behaved, handsome, neat) – here comes our own definition of girlishness. It was a loud and angry call for respect.

Apart from the fact that being called something and call oneself something are two different things, some say that the redefinition of the word has advanced so far, that being called a girl today and being a self-confident, respected, notable person isn’t an antagonism anymore. Another trend in our world is the prolongation of the youth up to the age of thirty-something. That also might be a reason, why the term girl nowadays seems to also include older females, which are young at heart. But seriously: Can you think of a wise, experienced woman with white hair, telling fascinationg stories about her rich life and would you still call her a girl? I doubt.

To finally come to the point after this excursion into linguistic history: In most cases pointing out gender differences is unnecessary and should be avoided. Mixed gender is best expressed by neutral wording. If the group we are talking to is named and described as exactly as necessary, but as general as possible, then for sure all girls, boys, guys, gals, women, men and everyone who doesn’t fit any of those schemes, but who feels involved in the description will be encouraged to read, listen, answer and apply. And needless to repeat, the term guys alone is a no-go, as it excludes people who might be our target audience, but at the same time it’s way too general.

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.

Do you love to be surrounded by as much and good as possible technical equipment or do you prefer to sit in a group of at least three peers discussing a detail no matter how small the screen is? And what do you like about your favourite setting? In our team both work modes coexist peacefully completing each other and also the happy medium (2:2) can be observed sometimes – and of course also the small screens are of high quality.

The first small remark is about line 3: markup{//doSomething} is similiar to markup.call({//doSomething}). BuilderSupport intercepts all method calls and MarkupBuilder produces xml tags from these method calls. So this will lead to an enclosing <call> tag. Surely not what we want.

Now let’s have a closer look at the body parameter. This is a GroovyPageTagBody, a special Closure which captures output using a special Writer (GroovyPageTageWriter). These bodies are usually called by various GroovyPage.invokeTag methods (see another following article on how to investigate groovy pages rendering) and return either a StreamCharBuffer (a special Writable and CharSequence) or the result of the closure evaluation, which is also Writable or a CharSequence if we are lucky.

So what is the right way to pass a CharSequence to the builder if we want our MarkupBuilder to use it as tag content? This will not work:

The String will be evaluated, but as it’s not in a method call, our MarkupBuilder doesn’t know what to do with it. There are two possibilities to do it right:

If we now replace “some text” with our GroovyPageTagBody call, we are nearly done. But wait, there’s one more thing. mkp (short for markup.getMkp()) returns a MarkupBuilderHelper (since Groovy 1.6.6, prior it was the builder itself). Instead of mkp.yield("some text") we could also use the yield method of the MarkupBuilder itself: yield("some text", true). But, hey, what means true? It’s the XML escaping of the text, which is also done if we pass the text as last parameter to the builder method (as in line 2 above). If we expect our body to contain markup, we should omit escaping. Of course there is also a helper method for that and our corrected example now finally looks right:

One last remark: Prior to Groovy 1.7.2 MarkupBuilderHelpers yield and yieldUnescaped methods were duplicated in MarkupBuilder itself, so the mkp prefix could be omitted. This is no longer true. You have to either fall back to the ugly boolean parameter or use the helpers pretty named methods.

There are plenty of stories to tell, so it was not easy to choose which one to write about. There are for instance the girls I work with, who are inspiring, amusing and fun to work with every day. They earn my respect, but instead of glorifying my colleagues (you can meet them in this blog btw) I want to take my hat off to three of the great ladies out there, each one totally different from the other.

Barbara Liskov

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

She’s the one who the Liskov-Substitution-Principle (LSP) was named after, because she formulated it together with Jeannette Wing. As I’m not an educated computer scientist, I had to do some homework and read about it (a general introduction and an article on LSP and dynamic languages) Apart from LSP being one of the fundamentals of object orientated programming, Barbara Liskov worked on and published about data abstraction in general, developed CLU, an object orientated language, ARGUS, a distributed programming language and THOR, a distributed OO database system. She’s the institute professor of MIT’s Programming Methodology Group where she works since 1972, here current research topics are – guess what – distributed applications. For her work she received the Turing award and the Von-Neumann-Medal – a real heroine.

Kathy Sierra

And there you have it. I think ‘girl code’ is quite a compliment. Because caring about things like beauty makes us better programmers and engineers. We make better things.

Although she seems to be around for a decade now (founder of Java Ranch, editor and author of the O’Reilly Head First Series), I stumbled about her amazing blog some weeks ago only. Its a pitty that she had to discontinue her activity due to death threads and now even closed her twitter stream. Nevertheless “Creating passionate users” is worth the lecture and allthough the articles are some years old, they come up with refreshing views on usability, are sometimes provoking and always fun to read and to watch. Just to point out one: Code like a girl talks about clean code and the aesthetics of source code and turns the prejudice about girls caring more about beauty then boys from a negative to a positive connotation. If you call cool things “girl things” it doesn’t make that things bad, no – on the contrary it makes the girls cool. Other articles are called “T-shirt-first-developement” and “Featuritis vs. the Happy User Peak”, but you should go and discover them yourself.

Hedy Lamarr

Any girl can be glamorous. All you have to do is stand still and look stupid.

Hedwig Eva Maria Kiesler, after leaving Vienna and her first husband, an arms producer, during world war II, changed her name and became a glamourous Hollywood actress. She was admired for her beauty, which as she experienced at least in Hollywood doesn’t go very well with being noted as intelligent. Thats one of the reasons why it took a long time, until her invention was notified, appriciated and honoured (she received the EFF pioneer award in 1997). Together with George Antheil, anvantgarde composer and her neighbour, she invented a “Secret Communications System” based on piano rolls (patented in 1942), an early form of frequency hopping, which is a technique of switching the frequency for communication on the transmitter and receiver side simultanously. Similar methods are the base of our todays mobile communication systems.

Photos credits:
Mirko Raner (Barbara Liskov), James Duncan Davidson (Kathy Sierra), Movie trailer screenshot (Hedy Lamarr)