Confitura 2013 afterthoughts

Confitura, the biggest free-of-charge Java conference in Europe, took place on the 6th of July in Warsaw. TouK's presence was heavy, with 5 separate talks, all chosen in call for papers, no sponsored bullshit. We were sponsoring deck chairs during the conference, and beer on the after-party, though. Both were quite popular. Oh, and we had Bartek Zdanowski with TouK Lab, doing funny things with lights, Jenkins, and raspberry-pi.

Last year, together with Tomasz Przybysz, I had a talk about Groovy and Grails. This year I had the pleasure of presenting revised Test Driven Traps.

Now, this wasn't the same talk I had in Tallinn. In fact, I rewrote most of it, with three major changes.

While at first I was focused on three goals of TDD (security, design, feedback), I've noticed that I underestimate the value of communication. The funny thing is, I do use TDD in that manner frequently, it just didn't appear to me as very important. Which, as an afterthought, was a big mistake.

Perhaps the reason for it, is how people distinguish between TDD, BDD (Behaviour Driven Development) and ATDD (Acceptance Test-Driven Development). I use Spock most of the time, and Spock mixes all three approaches very well. To be quite honest, I've been mixing all three of them in every testing tool I ever had. Whether my tests looks more like BDD or ATDD (that is, had more emphasis on communication and specification) depends on the nature of the project, and the nature of my client. Technology is not a problem here. It just used to be more awkward to write down user stories as a tests, in languages which were not as flexible as Groovy.

I had a lot of success using tests as a communication tool. Both internally, with developers, including myself while returning to an old code base, and with external clients. But I also had some failures.

A few months ago, while doing a mobile banking project, I had a session with a domain expert. We were trying to get to the bottom of fees and pricing in a specific payment scenario. While we were siting and talking, I wrote down a simple specification

static Closure fixed = {BigDecimal value -> new FixedFeeAddedCalculator(value: value)}
static Closure percentage = {BigDecimal value -> new PercentageFeeCalculator(value: value)}

def "should calculate fees"() {
    given:
        biller.feeCalculator = billerFeeType.call(billerFee)
        biller.feesForChannels = [new FeePerChannel(channel: Channel.USSD, feeCalculator: channelFeeType.call(feeForChannel))]
        biller.feesForPrefixes = [new FeePerPrefix(msisdnPrefix: "123", feeCalculator: prefixFeeType.call(feeForPrefix))]
    when:
        BillerFees billerFees = biller.calculateFees(productPrice, "1234", Channel.USSD)
    then:
        billerFees.total + productPrice == totalMoneyPaid
        billerFees.feeForChannel == feeForChannelPaid
        billerFees.feeForPrefix == feeForPrefixPaid
    where:
        productPrice | feeForChannel | channelFeeType | feeForPrefix | prefixFeeType | billerFee | billerFeeType || totalMoneyPaid | feeForChannelPaid | feeForPrefixPaid | feeForBillerPaid
        100          | 7             | fixed          | 3            | fixed         | 10        | fixed         || 120            | 7                 | 3                | 10
        100          | 7             | percentage     | 3            | percentage    | 10        | percentage    || 120            | 7                 | 3                | 10
        123.4        | 10            | percentage     | 10           | percentage    | 10        | percentage    || 160.42         | 12.34             | 12.34            | 12.34
        123.45       | 10            | percentage     | 10           | percentage    | 10        | percentage    || 160.47         | 12.34             | 12.34            | 12.34
        123.45       | 10.05         | percentage     | 10.05        | percentage    | 10.05     | percentage    || 160.68         | 12.41             | 12.41            | 12.41
        100.99       | 0.99          | percentage     | 9.99         | percentage    | 0.09      | percentage    || 112.17         | 1                 | 10.09            | 1
        100.99       | 0             | percentage     | 0            | fixed         | 0.01      | percentage    || 101.00         | 0                 | 0                | 0.01
        10           | 0             | fixed          | 0            | fixed         | 100       | fixed         || 110.00         | 0                 | 0                | 100
}

Those static fields/closures are a little hack, so that I'm able to use something more readable in the 'where' clause, than a 'new' with the name of the class. After we confirmed, that it looks OK, but we don't really know whether this is accurate, I just copied the 'where' part with a little description, and sent it to the bank for confirmation. It looked pretty much like what the bank likes to send with their requirements. The expert was happy with this, I was happy with this, we've had that working for us before.

No word about fees and pricing has been heard from them since. And that's about six months now.
Which shows, that no matter how good your tools are, no matter how smart domain experts are, if you have a fundamental problem with communication with your client, you are doomed anyway. And working through a proxy with clients from another continent, all I have are problems in communication. The technology is simple and easy, compared to that.

But I digress, I do encourage you to think of tests as a communication tool. It's a blast when it works. And it does help a lot with keeping our domain knowledge up to date. Something requirement documents fail miserably to do.

The thing I do not know, is whether it is better to keep specifications and user stories separate from the rest of your tests or not. I've tried both approaches, but I don't have any conclusion yet.
I also added a few simple thought on domain setup, to my presentation. Most systems need some domain objects before even unit tests will run. You can create that step by step, calling each constructor in every test, but this soon becomes a DRY violation, and a pain in the ass, as the domain gets more complex. Not to mention refactoring problems. A simple factory helps, but doesn't change that much, so in my experience, the best way it to have your aggregate roots built in a single class, preferably using the same builders you use in production code (if you use any). This kind of setup definitely simplifies writing new tests, and is trivial to refactor.

But that's most useful for unit tests. For integration tests, there are three approaches I'm aware of. The first one is the 'go crazy, copy data from production'. Fortunately, this is possible only if you join an existing project, that had no tests before, so I'll just skip that, as I am inherently incompatible with such situations. The other two are more practical.

You can have an empty database (you can even create it on the fly), where every test has to provide the data (domain objects) required for itself, or you can have a prepopulated database, with a precise set of data, representing some sample domain objects, and have that reflected in your test code in form of static finals. In both approaches, a rollback (for transactional Dbs) or a manual clean-up (for everything else) keeps the database at the initial state.

Everybody seems to prefer an empty database. But a prepopulated database has two great advantages: it usually simplifies test setups, and may have big impact on test performance. Just a few weeks ago I switched one of our projects to use the prepopulated database, and saved 15 seconds of test time.
15 seconds may not look like much, but our integration tests run now in 1m30s. I've saved another 2 seconds, by removing an ugly sleep in one test, and I can save a few more seconds, by just not being wasteful.

And that brings me to the next change in my presentation. I've pointed out the importance of performance in TDD. You have 30 seconds for unit tests, before you loose the patience of a developer. Make your tests run more than 3 minutes, and devs will only run them before push to the repo. Make them even longer, and nobody's gonna care about tests anymore.

This is a single reason, why I thing GORM (Grails object-relational mapping) is not good enough for bigger projects. Grails use Active Record pattern, with a nifty mocking of database access methods via @Mock annotation, for unit tests. But with a complex domain and large aggregate roots, you get a heavy performance hit because of those annotations, and you end up with unit tests having half the speed of integration tests.

And that's pretty bad. I have ~900 unit tests running in about 2.5 minutes, on i7. And most of that is due to @Mock annotations. I could bring it down to less than 30 seconds, if I could mock those bastard database calls the normal way, but with active record, I would either have to do meta-programming, or go into mixins and categories. The first option is error-prone, the second very cumbersome. Both are probably inefficient. Comparing the amount of work required to make those unit tests fast, with mocking a simple repository interface, puts all the other benefits of Grails active record into question. My conclusion is to not use GORM, if I'm going for anything more than 300 man-days. Or not use Grails altogether.

Those conclusions are kind of obvious, I suppose. The reason why I don't see them used too often, is because people do not treat tests as a normal object (or functional) oriented code. That at least was my excuse for years and years, till I finally found out, this approach ends up in unmaintainable test code, that keeps you production code from ever being refactored as well.

And that's pretty much all of my presentation changes.

Confitura 2013 was a fantastic experience. I am usually scared shitless, when giving a talk at a conference. Somehow, maybe because I know a lot of people on the audience personally, I'm less scared in here. During the first half of this year, I gave 6 talks, led two workshops, helped organize Warsaw Java User Group, and wrote a book. Confitura was a great finish for that marathon. Now I need a summer break.

33rd Degree day 1 review

33rd Degree is over. After the one last year, my expectations were very high, but Grzegorz Duda once again proved he's more than able to deliver. With up to five tracks (most of the time: four presentations + one workshop), and ~650 attendees,  there was a lot to see and a lot to do, thus everyone will probably have a little bit different story to tell. Here is mine.

Twitter: From Ruby on Rails to the JVM

The conference started with  Raffi Krikorian from Twitter, talking about their use for JVM. Twitter was build with Ruby but with their performance management a lot of the backend was moved to Scala, Java and Closure. Raffi noted, that for Ruby programmers Scala was easier to grasp than Java, more natural, which is quite interesting considering how many PHP guys move to Ruby these days because of the same reasons. Perhaps the path of learning Jacek Laskowski once described (Java -> Groovy -> Scala/Closure) may be on par with PHP -> Ruby -> Scala. It definitely feels like Scala is the holy grail of languages these days.

Raffi also noted, that while JVM delivered speed and a concurrency model to Twitter stack, it wasn't enough, and they've build/customized their own Garbage Collector. My guess is that Scala/Closure could also be used because of a nice concurrency solutions (STM, immutables and so on).

Raffi pointed out, that with the scale of Twitter, you easily get 3 million hits per second, and that means you probably have 3 edge cases every second. I'd love to learn listen to lessons they've learned from this.

 

Complexity of Complexity

The second keynote of the first day, was Ken Sipe talking about complexity. He made a good point that there is a difference between complex and complicated, and that we often recognize things as complex only because we are less familiar with them. This goes more interesting the moment you realize that the shift in last 20 years of computer languages, from the "Less is more" paradigm (think Java, ASM) to "More is better" (Groovy/Scala/Closure), where you have more complex language, with more powerful and less verbose syntax, that is actually not more complicated, it just looks less familiar.

So while 10 years ago, I really liked Java as a general purpose language for it's small set of rules that could get you everywhere, it turned out that to do most of the real world stuff, a lot of code had to be written. The situation got better thanks to libraries/frameworks and so on, but it's just patching. New languages have a lot of stuff build into, which makes their set of rules and syntax much more complex, but once you get familiar, the real world usage is simple, faster, better, with less traps laying around, waiting for you to fall.

Ken also pointed out, that while Entity Service Bus looks really simple on diagrams, it's usually very difficult and complicated to use from the perspective of the programmer. And that's probably why it gets chosen so often - the guys selling/buying it, look no deeper than on the diagram.

 

Pointy haired bosses and pragmatic programmers: Facts and Fallacies of Software Development

Dima got lucky. Or maybe not.

Venkat Subramaniam is the kind of a speaker that talk about very simple things in a way, which makes everyone either laugh or reflect. Yes, he is a showman, but hey, that's actually good, because even if you know the subject quite well, his talks are still very entertaining.

This talk was very generic (here's my thesis: the longer the title, the more generic the talk will be), interesting and fun, but at the end I'm unable to see anything new I'd have learned, apart from the distinction between Dynamic vs Static and Strong vs Weak typing, which I've seen the last year, but managed to forgot. This may be a very interesting argument for all those who are afraid of Groovy/Ruby, after bad experience with PHP or Perl.

Build Trust in Your Build to Deployment Flow!

Frederic Simon talked about DevOps and deployment, and that was a miss in my  schedule, because of two reasons. First, the talk was aimed at DevOps specifically, and while the subject is trendy lately, without big-scale problems, deployment is a process I usually set up and forget about. It just works, mostly because I only have to deal with one (current) project at a time. 

Not much love for Dart.

Second, while Frederic has a fabulous accent and a nice, loud voice, he tends to start each sentence loud and fade the sound at the end. This, together with mics failing him badly, made half of the presentation hard to grasp unless you were sitting in the first row.

I'm not saying the presentation was bad, far from it, it just clearly wasn't for me.

I've left a few minutes before the end, to see how many people came to Dart presentation by Mike West. I was kind of interested, since I'm following Warsaw Google Technology User Group and heard a few voices about why I should pay attentions to that new Google language. As you can see from the picture on the right, the majority tends to disagree with that opinion.

 

Non blocking, composable reactive web programming with Iteratees

Sadek Drobi's talk about Iteratees in Play 2.0 was very refreshing. Perhaps because I've never used Play before, but the presentation was flawless, with well explained problems, concepts and solutions.

Sadek started with a reflection on how much CPU we waste waiting for IO in web development, then moved to Play's Iteratees, to explain the concept and implementation, which while very different from the that overused Request/Servlet model, looked really nice and simple. I'm not sure though, how much the problem is present when you have a simple service, serving static content before your app server. Think apache (and faster) before tomcat. That won't fix the upload/download issue though, which is beautifully solved in Play 2.0

The Future of the Java Platform: Java SE 8 & Beyond

Simon Ritter is an intriguing fellow. If you take a glance at his work history (AT&T UNIX System Labs -> Novell -> Sun -> Oracle), you can easily see, he's a heavy weight player.

His presentation was rich in content, no corpo-bullshit. He started with a bit of history of JCP and how it looks like right now, then moved to the most interesting stuff, changes. Now I could give you a summary here, but there is really no point: you'd be much better taking look at the slides. There are only 48 of them, but everything is self-explanatory.

To Java SE 8 and Beyond! | Simon Ritter

While I'm very disappointed with the speed of changes, especially when compared to the C# world, I'm glad with the direction and the fact that they finally want to BREAK the compatibility with the broken stuff (generics, etc.).  Moving to other languages I guess I won't be the one to scream "My god, finally!" somewhere in 2017, though. All the changes together look very promising, it's just that I'd like to have them like... now? Next year max, not near the heat death of the universe.

Simon also revealed one of the great mysteries of Java, to me:

The original idea behind JNI was to make it hard to write, to discourage people form using it.

On a side note, did you know Tegra3 has actually 5 cores? You use 4 of them, and then switch to the other one, when you battery gets low.

BOF: Spring and CloudFoundry

Having most of my folks moved to see "Typesafe stack 2.0" fabulously organized by Rafał Wasilewski and  Wojtek Erbetowski (with both of whom I had a pleasure to travel to the conference) and knowing it will be recorded, I've decided to see what Josh Long has to say about CloudFoundry, a subject I find very intriguing after the de facto fiasco of Google App Engine.

The audience was small but vibrant, mostly users of Amazon EC2, and while it turned out that Josh didn't have much, with pricing and details not yet public, the fact that Spring Source has already created their own competition (Could Foundry is both an Open Source app and a service), takes a lot from my anxiety.

For the review of the second day of the conference, go here.

Java Developers' Day 2010 review

On the 7-8th of October 2010, Cracow held Java Developers' Day conference. This year it was two days long, so I guess they'll have to think about changing the name. My expectations weren't very high. First of all, I've heard an opinion that JDD is getting worse every year. Second, for the same price as GeeCON you got only one track. Third some of the lectures seemed really uninspiring.

For example, I was afraid, that the one about Flex is going to be the same one I've seen on 4Developers, half a year ago in Poznań. And, of course, there was the one most controversial to all the people I had a chance speaking with, the sponsored lecture from Wipro Technologies, titled: “Wipro in Europe and development opportunities on Polish market”.

Doesn't sound like something you'd like to listen to on a Java conference, does it? More like an advertisement, to me.

Fortunately, my doubts were mostly unfounded.

The first day started a little earlier than planned, with Bill Burke talk about RESTful Java. Quite nice, I must say, as long as you have no idea what REST means, as half of the lecture was very basic. The other part was about JAX-RS (and RESTEasy implementation), and that's where it got my attention. I haven't had a chance to use JAX-RS yet, but the simplicity and efficiency of it is very appealing. I'll have to give it a shot, especially when .NET/Java web service integration is sometimes very painful.

The second talk,  “Java programming in days of multi-core processors”, by Angelika Langer, was gorgeous. Maybe it's because of my limited experience in concurrency, maybe because Angelika presented a more in-depth view on the things happening under the hood, than I am used to, and maybe because she threw away the incorrect model most books present. What I'm sure about, is that Angelika is a great trainer and speaker, with vast knowledge and expertise.  It was a pure pleasure to listen to her and I can only hope to be so passionate and sharp at her age.

Not that she's that old, mind you. It's just that terms like “burned-out” and “tired” do not seem to have anything to do with her.

Then there was Jarosław Błąd from e-point, talking about performance tests in JEE. That was also quite nice, though a little too basic. I wish the speaker could show us a little more real case scenarios and stories, as it was obvious he had a lot of interesting thoughts on that matter, but probably because of NDAs, he decided to go with more theoretical and generic information instead. Anyway, this was a sponsored talk done right. Thanks e-point for not leaving us with just advertisements.

After the lunch came the hit of the day, Ted Neward talk about functional programming for busy developer. A few slides passed by, when Ted asked the audience, whether we would rather see presentation or life coding. Guess what the answer was.

The great thing about the lecture was that Ted didn't use anything more than standard Java, to show us the benefits of thinking in terms of functional languages. The examples were practical, with stuff you can really find from time to time in your code, and the advantages clear and explicit. Somewhere in the middle of the show, Ted said, that he wants us to remember, that we do not have to use anything fancy like Scala, to start solving some classes of problems in a much better way. I only wish he had more time on his hands, but I was lucky to sign in for Scala workshops with him on Friday.

I didn't go for Flex presentation, partially because of the beforementioned doubts, partially because I've met some friends and speakers on the way. I really wish I could be there, on their lectures, especially on Łukasz Kuczera talk about Lift+Comet and Łukasz Szydło presentation about Apprenticeship, but I could either do that or go for the workshop with Ted Neward, and after what Ted had shown us a few hours before, I was sure his workshop will be a mind opener.

And here is for all those anxious about just one track on JDD10. There were actually two on Friday, if you count the workshops, and even though that doesn't seem like much, the quality of what Ted had to offer, beat up the disadvantage of not being able to change every session for something different.

The last lecture on Thursday was “Brave changes: how to make new ideas happen”, given by Linda Rising. While not Java specific, that was quite interesting to me, mostly because of the latest changes I've been part of at TouK (both my own initiatives that you can read about here and here, and overall works on defining company goals and vision). Thing to remember: what your audience is eating is more important than what they are listening to. Scary but true.

Then there was the integration party. And as expected from programmers, Nintendo Wii had a much bigger take than girls :)

For three hours on Friday, I've been enjoying Ted Neward's Scala workshops. I won't give you much details, except it was really great, since Witek Wołejszo wrote a nice summary already.

And I didn't dare to go for “Wipro in Europe and development opportunities on Polish market”. I was afraid, that my positive experience from JDD10 could be a bit reduced.

Overall, another great conference. Thanks to Witek Wołejszo, Piotr Przybyłek and Tomasz Dziurko for this interesting trip.

NYAC & COOLuary 2010 review

NYAC stays for Not Yet Another Conference, and it gives a promise I was happy to verify. The event took place in Cracow on 19th-20th of June, thanks to Grzegorz Duda. Tough timing I'd say, just a week before Javarsovia, but the audience was supposed to be small, so that wasn't a problem. NYAC was actually two things: a one day conference with carefully chosen speakers that got a bit more time than usually, and another day of an unconference.

If you didn't have a chance to participate in an unconference (Open Space Technology), it's totally people driven. Everyone is able to start a meeting, and it's usually a discussion, not a lecture.

But let's start from the beginning. I got there on Friday evening, and my luck was definitely with me, as I bumped into Paweł Lipiński at a gas station. He warned me about the post-soviet hotel, so we walked back carrying loads of beer, that helped shield us from the ugly face of socrealism and it's terrible architecture. Well defended, together with Wojtek Erbetowski, we spend the late hours enjoying the drink and a smalltalk.

The first day started.

So what's so different about NYAC, you ask. First day is just a conference, after all. True, but Grzegorz had a great idea, to make a survey about the best polish java speaker. He used the outcomes to invite some of the most interesting people in our field. He asked them to make a few lectures, one after another, and he gave them more time than usually (which turned out to be not enough anyway), and a much smaller audience.

The effect?

Well, it's like a difference between a stadium-sized concert, and a jam session in a private house.  The second one allows you to be more involved, and get much closer to the source of fun. Is it the way to do conferences? Yes, but only if you have the top guys out there. And that was the case. Have a look at the agenda, the only problem you could have is to decide which session to choose from.

Fortunately, being here and there, I've already seen some of the presentations, so it was a bit easier to me. Sławomir Sobótka had three great talks about Craftsmanship, Domain Driven Design and JPA/Hibernate traps (we all know that JPA 1.0 was a big step backward, compared to pure Hibernate, but Sławek had some really great examples of the most popular pitfalls). Szczepan Feber with Łukasz Milewski gave us a handful of good tips about continuous integration. Igor Czechowski talked a bit about his nightmares with Maven. Paweł Lipiński warned me that I may not find anything new in his talks, so I skipped them, but I really wish there was a camera, since Paweł is a great speaker and it's always refreshing to see his enthusiasm.

All together it was a condensed, great event, that I've left with a nice set of notes and a mind full of thoughts.

Then there was a party, though Grzegorz didn't give the address, just the name of the pub, and as with all the names, it was easy to forget and hard to find using GPS.

Great aspect of going to so many conferences (I've been to six this year) is that eventually you get a nice pack of people to drink with, but with such a small scale (there was something about 50 attendees) it's easier to get to know everyone and not feel lost in the crowd anyway.


Some people stayed till like 3am, but since I was kind of on a mission gathering/crunching knowledge, I decided to get back at midnight.

The second day was all about self organized groups of talkers. We had a flipchart where everyone could post a proposal, then we grouped together similar topics, and sorted them out considering whether the guys we wanted to join in, were leaving early or waking up late. Seriously. After all, talking about DDD without Sławek or about A/B/TDD without Paweł would be like wasting resources.

The only “real” presentation that day, was a sponsored talk from Tomasz Skutnik (e-point) about class loaders in JEE, and it was unexpectedly good, I must say.

I also had a chance to animate a smalltalk, which I used to confront and verify some of the ideas I've been preparing for my Javarsovia presentation. The feedback was good, and some of the points from the discussion helped me to refactor my final talk.

All together it was a great weekend, and I can recommend NYAC/COOluary with my heart. It's a moving conference, every year in a different city, so stay tuned to Grzegorz's site, and don't forget to visit the event whenever you have a chance.

GeeCON 2010 general impressions

GeeCON 2009 in Cracow was a wonderful experience, and this year Poznan held the conference. If you ever wonder whether GeeCON is worth the time and money, the answer is plain and simple: definitely yes.

I'm not able to give you a full review this time, as I'm leaving tomorrow for Paris, and I haven't prepared myself yet, but let me summarize the most important topics.

There were two different presentations about Erlang way (Actor and Agent models) of solving the problem with concurrency. One was a general overview of the problem and possible solutions running on JVM, and the other was about Akka Project/Platform that looks very interesting and above all, is simple to use (at least from what we've seen at the presentation). So far I've been trying to shield myself from concurrency problems with web servers, stateless services and optimistic locking on database level, but the solution presented here is really appealing. I'd love to try it out.

Joonas Lehtinen had a very nice lecture about Vaadin. There was a talk about Hades which is probably going to replace the solution I usually use (hibernate-generic-dao). Kuba Kurlenda is testing it on real project right now.

Stephan Herrmann was talking about an evolutionary idea for Object Oriented Programming:  Object Teams. This may be the next big step we need, but it would have to gain some momentum and find a real life use in a big project. Unfortunately Object Teams do not yet have a successful example to follow. The main question I see is whether it's worth investing the time of your team, while everyone already knows about design patterns, which solve similar problems.

There was a presentation about Spring Roo framework which is something you should know before you move to Grails or Ruby on Rails. Even if you do not plan to do it, it's a great way to create prototypes.

Waldemar Kot had a very condensed, content rich but easy to learn lecture about Complex Event Processing. It was definitely worth listening to. I'll try to infect my SQL friends with this idea, as it seems like something they would really like to do, when they move from PL/SQL to Java. Thomas Sundberg repeated his talk about Software Craftsmanship that he gave at Agile Central Europe. There was a little bit about Comet (push style Ajax), agility, OOP and lots of other interesting stuff.

And there was a great party, but that's a completely different story.

If you have a chance to go to GeeCON 2011, do not hesitate to.

PS: all the pictures come from the official GeeCON gallery. I don't know about the authors, though.

Mentoring in Software Craftsmanship

Maria Diaconu and  Alexandru Bolboaca are both strong supporters of Software Craftsmanship and Agile movements in Romania, with years of experience as developers, leaders, architects, managers and instructors. On their lecture at Agile Central Europe Conference they were talking about Software  Craftsmanship movement. While Sobótka at 4Developers was showing what Craftsmanship from the code point of view is, our guests from Romania gave us a brief introduction into the process of becoming a Craftsman.

The fact, that university education for programmers doesn't give us skills suitable for professional environment is old news (at least in Poland and Romania). While steps are being taken in the right direction, it's going to take a while to get there, and that's where  Software Craftsmanship movement comes in handy.

The core concept of the presentation, was that if you want to go pro, you should understand the way you need to follow. In other crafts, there are practices recognized as the core of a profession. Programming is so vast, that you may get lost on the way, and certifications like SCP do not help much, as they are too technology oriented, looking more like a “technological masturbation” (technology for itself) rather than a way to really learn something useful. Software craftsmanship has a concept of mentoring, which is based on one of Agile  principles: “individuals and interactions over processes and tools”.

How does it work in practice? To become a craftsman you start as an apprentice at some master of your choice. If you're lucky, you'll find someone to work for and learn from. If not (you have to work in a bad environment to get by, or everyone around doesn't have more experience than you do), you can choose a well known writer, such as Martin Fowler or Robert C. Marting (Clean Code is a great start) and learn from him (all of them, even better). But that's not enough. Next step would be to participate in the community (local language user groups, etc.) and finally, to get your ass to other places and learn from people out there. That means conferences, but also a week-out pair programming in another company, far, far away, an idea more and more popular in US, as you can see at software_craftsmanship google group. After all a journeyman has a “journey” part in it, doesn't it?

So easy so far, right? Nothing new and mind-shaking?

The thing is to understand, that while official certifications are a great magnet for potential employers, skills of a good programmer don't come from certification books. Skills come from work experience with other good programmers. That's why Pair Programming is so important. That's why you should start going for local language/craftsmanship group meetings even if you do not understand everything they are talking about. That's why it's more important to work WITH a great programmer than to work FOR a well known company.

I've seen so many people understating the technology to the ground, yet failing to create a good software solution,  because they've never ever seen, how a good solution is build. I've heard opinions that “no software is maintainable” from people with 10+ years of experience in Java.

All you really need is a mentor. A master, that can show you, what a great software is written like.

Sławomir Sobótka, answering the question “How to start with Java” on Jacek Laskowski's blog, wrote lately: “I'd leave SCJP and similar sadomasochisms for later, maybe in a few years time, or even better, I'd boycott it all together”. He is damn right.

Robert C. Martin has a very interesting entry on his blog “Developer Certification WTF?”, where he is explaining why  official certification programs are so much bullshit these days. Beware of big companies as well, remember that “big and successful company” doesn't mean “a good place to get better”. On the contrary, it sometimes means: “a place where an apprentice is treated like shit and a code monkey”. Check the company for people and methods that you're going to be involved with on daily basis, before you send your CV. Ask a lot of questions, talk to the guys working there, if you can, ask to spend some time with the team, do some pair programming, and see what they are up to.

While chances are, in most companies your CV is going to be processed forward basing on buzzwords and certificates, the most important thing is to check whether the people you are going to work with can inspire you, bring you to the next level. And vice-versa. This is exactly what Thoughtworks is doing. Don't be afraid to risk you stability and position to get more knowledge and experience. If you've been playing Heroes of Might and Magic, you probably know damn well, that to choose experience is better than to choose money in the long run. Always.

If you want more tips what to look for when searching for a good employer, have a look here.

Mentoring should not to be underestimated. When Piotr Jagielski began his speech about refactoring test code, at Agile Central Europe Conference, he started with saying that he was very lucky to get a great mentor at the very beginning of his work. I'm sharing similar experience: while I've started my carrier as an analyst in a long waterfallish kind of a project, when I've moved into programming I was extremely lucky to work with Piotr Szarwas, the guy who in one year taught me more than 5 years of university and two years of former software experience all together.

And if you already are a good programmer, remember that learning never stops. When you are a master, you are a student as well.

“Even today, I dare not say that I have reached a state of achievement. I'm still learning, for learning is boundless.“ [Bruce Lee, Tao of Jeet Kune Do]

ACE Conference: Reachel Davies – Retrospectives

Reachel Davies, author of “Agile Coaching”, with ten years of experience in XP, Scrum and Agile (seven on the board of directors of the Agile Alliance), and 19 overall in IT, is a serious girl in this industry. Funny, I'd think she has some psychology background, but no, she's an engineer to the core. I'd think that because her presentation made so many points on the psychological part of our line of work, that my sister (who is a psychologist as well as a jazz singer) may be interested.

Her talk was about the underestimated art of retrospectives in our agile methods. Teams tend to forget about it or do it a wrong way, while it's the main thing that can help them get better.

She suggested another technique for retrospectives, to create a constant time-line where the team would put their sticky notes, writing:

• what happened
• what was frustrating / stressful
• what was useful / fun

That can give you a very interesting insight in what was happening during the project. She also pointed out that people's moods take a big part in the efficiency of the team, and to have a valid historical view, you should include them as well (like biorhythms). To get that, anything would be good, from putting your spirit level on a scale, up to drawing a picture. Back to kindergarten anyone?.

That may seem silly, but the team is the most important part of the project, and as such, we need to pay attention to everything that happens within. For example, while voting on things to change during a retrospective can help, we should beware of serious disagreements. There are things, like personal values, that you cannot change with a simple statement, and there are things (personal values again for example) for which people would rather be fired than give up on.

That was pretty familiar to me, as I cannot agree to include chaos and lose quality for the sake of other things. And don't talk to me about quality versus work performance dilemma. It's a myth. You'll never be faster by writing uglier. In the long run, bugs and accidental complexity will bring you down big time.

It's quite an interesting twist to think about retrospectives in a more general sense. You can (should?) use them outside of IT as well. About three years ago, I've been to a sailing camp at Mazury where my trainer, who was a youngster, after every not-so-perfect maneuver, would ask: “What went wrong?”.  As simple as it is, the question generated a lot of afterthoughts that helper us pass the exam in the end.

Now, think for a while, what else could also benefit from a well performed, regular retrospective?

A marriage, perhaps?

ACE Conference general impressions

Getting up at 4am is never easy for me, and so it wasn't this time, especially after getting to bed only three hours earlier. Nonetheless, on the 8th of April, thanks to TouK, I was getting myself on a train to Cracow for 2 days long Agile Central Europe Conference, when out of a sudden I saw a man walking out his dog. That made me think: if this guy has so much love for his pet to walk it out in the middle of the night, then I definitely have enough passion for knowledge to stop complaining and be extremely happy that I have a chance to learn something.

And boy, how happy I am that I've been there.

While both 4Developers and Winter Agile Tunning, that I've attended last month, were really great (I can recommend both and I'd like to be there next year), ACE conference was simply fantastic. It seems that it's not only my opinion. Kuba Kurlenda, to whom I gave my free conference pass, that I got (won?) on Winter Agile Tunning for asking Szczepan Feber a hell lot of questions, was also delighted.

There are two organizers mentioned on the site, but as far as I know, it was put together by one man, Paul Klipp, who is a president and Scrum Coach at Lunar Logic Polska, and founder of half a dozen different groups and other undertakings.

So what was so special about this event? Apart from great speakers, that is. First of all, there were only two tracks, but you wouldn't be bored, because as a “bonus third track”, there was an Open Space, where everyone had a chance to put his favorite subject and get some people to talk about it. Breaks between presentations were half an hour long, which was also motivating to get to know each other and start talking. That was what I missed the most on Winter Agile Tunning, a chance to talk with everybody. Finally, Paul was aware that people are getting tired at the end of a day, so instead of putting not-so-hot topics on late hours, he got us the most funny/innovative to wake us up, and after that, we had Lighting Talks, lasting for 5 minutes each, which is precisely as long as you can keep your focus on the subject when you're exhausted.

Big kudos to Paul for all of this. The only two things I'd change were, that we didn't get any pens/notebooks together with conference materials, which is something of a surprise (I wasn't prepared for that and had nothing to note with, except my phone), and that it could've started at noon, so people from other parts of the country would have a bit more time to get there (and to sleep at night).

I had a chance to talk with Paul about it, so chances are, he'll use those ideas next time, as I'm sure there'll be more ACE Conferences in years to come.

So much for the general impressions. I'll have to make one post for presentation, for the sake of readability. Stay tuned.

Tomek's tray notes on Scrum

As Nigel Baker was giving his speach titled "10 tips that ScrumMasters should know, (but probably don't!)" at Winter Agile Tuning, Tomasz Przybysz was taking notes on a paper tray. I've heard the talk was pretty good and a few people were trying to copy his tray. Since the original presentation is not yet available, I thought I'll help with putting my own photo (phone quality) on-line.

Maybe Tomek will take a while to put some insight into his notes? What say you, Tomasz?

Click on the image to get the full (readable) size version.

4Developers 2010 Review

I've been to 4Developers in 2009 in Cracow, together with Tomasz Przybysz and we had very nice impressions, no wonder then I wanted to signed up for 2010 edition in Poznań as well. Tomasz was sick, but Jakub Kurlenda decided to come with me. This time our company was sponsoring the conference so I had a stand-up banner to carry.

Getting up at 4am is annoying, and you need to get up so early to get to Poznań by car. Thanks god it was  Friday, I could be dangerous if woken up at this hour on Saturday.

After arrival we were invited by high-heels hostesses. Now I'll be a bit stereotypical programmer for a while: what on earth are so lovely hostesses doing on an IT conference? Yeah, sure they look nice, but hey, I thought I'm paying my money for the knowledge. If I wanted to go for good looking girls, I'd visit a local Salsa club. The best high-heels can do is distract me. And I'd rather you spend my bucks on better food, more speakers or just lower the price instead of this.

Unless, of course, these were local IT students helping for free. I strongly doubt if Poznań has so many female IT students all together in all its higher education facilities, but if that is the case, I'm starting to regret I've not moved to Poznań.

While I am at the organizational part, lets say that the rest was quite flawless, with tasty sandwiches, drinks, cookies and console games in between lectures. Two exceptions were: a bad lunch, served at Orbis Polonez hotel (and a total rip-off at 50zł) and no place to sit down while outside of conference rooms.

Not that we had any time, mind you. All the presentations had a tendency to take more than scheduled, and while it's quite fine with me (it actually means there are people who'd rather listen than go for a cookie and coffee), the host didn't seem to like it much. I think there should be more buffer time for breaks or maybe even an open space in between, to make everyone happy.

Fighting for live

Let's get back to the lectures. The conference had four tracks, and I've started with 'Fighting for live – derivatives and successors of Java are taking over the world' by Michael Hunger. That was a big disappointment. Michael was way too theoretical. I'm afraid nothing from his speech would be useful to anyone in the room. And he didn't give us much more than what we can actually find on wikipedia: just a brief list of some from 400+ languages running on JVM. The only interesting parts were actually played from youtube. I've not been waking up at 4am to watch youtube in Poznań. I can do it back home, you know.  As I said, a total disappointment.

Microsoft Cloud: Windows Azure

Angry and sad at the same time, I've decided to switch rooms to see Maarten Balliauw talking about Windows Azure. I've been thinking about using Google App Engine for my next project, so I wanted to know what Microsoft has to offer in terms of cloud computing. And boy, they do have stuff in there.

Maarten gave us a quick overview of a few projects surrounding the M$ cloud, and after that showed us how to move a simple ASP.NET application to Azure. Jakub Kurlenda, who I believe never had a chance to work with .NET, was amazed. `It can't be that simple` – he said – `There's got to be a lot of problems with complex solutions`. Well my friend, remember that M$ has inherited all the good stuff from Borland togethere with Anders Hejlsberg. Sure it sometimes doesn't work perfectly, but still their tools are quite sexy. And way easier than anything you can find in Java world.

The Microsoft Azure does look very interesting. You get an MS SQL, Storage Service for unstructured data, front end web servers, back end servers and a AppFabric Service Bus to connect different services in a via-VPN-like manner. You even get an information marketplace Codename "Dallas", to sell and buy services and data. Now this sound like an App Store of cloud computing, doesn't it?

I think the war between cloud computing providers is going to be quite a show soon. And no matter whoever wins, I think that Microsoft won't lose.

Not so Funky It Management

For the third lecture I've visited the `IT Management` track, where Peter Horsten, a guy who moved from Netherlands to Poland to create his company (Goyello) in Gdańsk, gave a speech about `Funky It Management`, but after half an hour I've returned to Java track uninspired. Peter is a great speaker, but for the first thirty minutes I heard nothing I could actually use or didn't know already, so I wasn't going to risk the rest of the time.

TopLink Grid and Oracle Coherence

That made me see only half of presentation from Waldemar Kot about TopLink Grid and Oracle Coherence, and I really regret that. Waldi, as he is sometimes called by friends (and notoriously by Jacek Laskowski) works for BEA... errr... Oracle, and while I do not know whether he is only consulting or also building systems for his clients, he is sharp as a Gillette, precise as a laser and full of knowledge. I really enjoyed his talk, there was a nice mix of theory and practice, and finally, some stuff I could actually use at work. Thanks Waldi.

Flex 4 and iPhone news

After a horrible lunch, Piotr Walczyszyn gave us a tutorial in using Flex 4. Years ago, I had a chance to use AMF to communicate between a heavy Flash frontend and a PHP backend, and it worked quite well. I have to note that especially debugging was nice, something I wouldn't expect from a binary and proprietary format. For the last two years, I've been hearing about how easy it is to have a Java backend and Flex rich frontend. A lot of people I've met at the last year's GeeCON conference actually worked that way. I was very interested in the topic and after the show I can tell you this, Flex is a way to go if you want to have a rich (heavy?) Intranet client. I think though, that its use for public/Internet services should be considered carefully. Too much bells and whistles and you are going down on frontend complexity and throughput. But you already know that, don't you?

If using Java, I'd go for Flex 4 if Wicket is not `rich` enough for the solution. If Wicket is fine, I'd stay away from anything more complex (and difficult to test). I don't have a lot of love for GWT, after what I've seen at work. But that could be a GXT fault, not a Google failure.

One of the most interesting news Piotr spread, was that Flex is being implemented on Android and... wait for it... iPhone! How's that possible, you ask? We all know Apple doesn't want to loose its AppStore market to on-line flash applications. Well, they are building a native Flex to Objective-C compiler, that's how. If they manage to implement a runtime on Symbian and Windows Mobile, it may be the only truly portable technology. Unless you call HTML 5 a programming language, of course.

Java SE 7

After that Marcin Katas was talking about Java SE 7, which is scheduled for the end of this year. There was a lot about new Garbage Collector, that I don't really care about, a few thing about OSGi-like solutions to dependency hell,  support for dynamic languages, new concurrency classes, closures and  Project Coin (small changes/additions to the language).

The only thing I can say is: why so late? And why so little?

Especially for Project Coin.  This is actually quite sad. Java as a language is being left behind its competitors. Really, Automatic Resource Management is a concept implemented YEARS ago with `using` in C#. Come on people, I'd at least expect stuff like .NET LINQ in new version of JDK, not even mentioning some long needed fixes for stuff like collections and generics. It's been four long years since Java SE 6, there should be a Java SE 8 already.

I really think they should release a new version in a fixed interval of time, like Ubuntu is doing, like it was before Java SE 6. And forget about the hardcore backward compatibility, like with fu...-up generics. Banks that are still using J2SE 1.4 are not updating anyway.

Sobótka on Craftsmanship

And finally, I've been waiting for this one, Sławomir Sobótka, owner of Bottega, guy whose blog I'm actively reading, shared his thoughts about software craftsmanship.

That was by far the best presentation at the conference. Absolutely brilliant. I would not be able to put more meaningful information in such a short time and accessible way even had I tried for months. And to be honest, that was also the most important subject, useful to everyone, touching the work of every software developer in the room (and in the other .NET room as well). Kudos to you Sławek.

Too bad, there wasn't anything new to me then. But maybe I should be actually glad, maybe it means I'm keeping up with the front line. Maybe, or maybe we are just reading the same books, groups and feeds (or I'm reading his blog actually). Anyway, I'm very happy about this lecture. What a beautiful world would it be if everyone was as passionate for craftsmanship and quality as  Sławek is.

I didn't make it for OSGi speech from Jacek Laskowski. Sorry Jacek, but waking up at 4am doesn't leave you a lot of strength for the last lecture. I've seen Jacek in action a few times, and it's always a pleasure as he is a great showman (in a positive sense). I hope I'll see you again at Warsaw's JUG meetings, but now I'd rather get back to bed before midnight than get sick after the conference like all my friends did. Yeah, I've heard that Jakub Kurlenda got down just like Tomasz Przybysz a week ago, after the Winter Agile Tunning.

The price of knowledge has always been high, I guess.

Alltogether it was a very interesting conference and definitely worth the money.

Reviews (in Polish) from others can be seen here and here and here and here.

Winter Agile Tuning Review

I've found Winter Agile Tuning conference purely by accident, reading someone's blog. I have to admit that I've never heard about it before event though it was a second edition already. As I had ma chance to talk with, Jakub Dziwisz, one of the organizers, I understood why. Jakub didn't think about it as a country wide conference, more like an way to animate local Agile society. Well Jakub, I've counted at least four people from Warsaw and quite a bunch of speakers from abroad, so I believe you'll do well with changing your target audience expectations for the next edition.

Having an Agile conference somewhere nearby (I consider Cracow nearby as it's 3h by train from Warsaw) in a suitable time, is a good enough reason to go. After  I'd checked the website I knew, I cannot let it pass by. The program was interesting, with some well known names (i.e. Szczepan Faber, guy who wrote Mockito, the best mocking library in Java world), it was practically free of charge (50zł) and it was starting at 2pm on Saturday.

2PM! Do you know what that means? It means that you do not have to get up at 5am to catch a train or at 4am to get there by car. You don't have to be totally exhausted, intoxicating yourself with gallons of energy drinks. You don't have to get there a day before, wasting a perfectly sweet Friday night. It means that you get up at 8am, like normal people, you have enough time to eat lunch, and after the conference it's exactly the right moment to go to an afterparty.

I wish all the conferences would start at at least at noon.

Back to the event. I went there with a friend of mine, Tomasz Przybysz, one of not so many programmers I've met, that actually cares about the quality of his work, and as there were two tracks and two of us, we've decided to split and exchange the knowledge during breaks.

I've chosen the 'Craft' track while Tomasz went for the 'People'. That was a pretty good choice of mine and I only wish I could be on '10 tips that ScrumMasters should know...' by Nigel Baker. But let's start from the beginning.

Sweetest acceptance tests

The first lecture was given by Bartosz Bankowski and Szczepan Faber. At the last moment, they've changed the topic of the presentation from an enigmatic 'Be a VIP and rid your WIP' to 'Sweetest acceptance tests'. Can't say I was disappointed.  They took us through an example of working with Sweetest which is a sort of a plugin to a wiki that allows for a very fluid and direct translation between a wiki-defined set of acceptance requirements and automatic (junit) acceptance tests.

How does it work exactly? It's quite simple: you talk with your client, you both write his requirements in a wiki, the tool creates junit automatic acceptance tests for you. Here's a demo.

It fits very well with a TDD/BDD approach and allows you to have a bit more contact with the client, as the client can see on the wiki what his own acceptance requirements are and which are already implemented.

Lately, we've spent two days creating acceptance test scenarios for my client in doc format, which could allow him to formally say 'yes'. We've been doing it by checking his requirements (again), checking whether we have implemented them right, and writing all down.  The thing is, that since we do TDD/BDD, we already have all the tests that tell me whether his requirements are met, because we start implementing a new feature by writing a test for it. The main failure of the situation was that we've been writing those scenarios AFTER the whole project was implemented. Had we had them written down BEFORE, maybe even had them connected to unit tests, we'd be done before we've started.

That's what Sweetest is for.

Not that it's something totally new. If you're doing TDD you are already implementing client's requirements as tests (or at least you should start every feature with a single test for it, and then go down the implementation and Red-Green-Refactor line up to the point when it's fully working and is fully covered), but everything that helps with communication, well.. helps. And as in my example, can save you a few days writing docs.

I've been to another conference in Cracow last year where Szczepan was presenting Mockito framework. Just like the last time, his presentation was vivid, fluent, interesting and straight to the point. That's what makes a happy Panda.

Let them speak in their own language

Next was Konrad Pawlus 'Let them speak in their own language. How we enabled domain experts to build acceptances tests - case study'. Konrad shared his experience with developing Test Driven software for financial market. The clue was to allow domain experts, guys used to Excel, to verify software in a way that was familiar to them.

To do that Konrad (or his team) created a Visual Basic tool, that could convert xls files with example calculation to a scripting language, and then fire up this scripting language in a similar manner to junit tests. At the end, domain expert could verify everything down to the last number (and knowing that Excel actually creates a lot of errors with rounding that is very important), create new tests to check scenarios they never thought about before.

This is quite a cool way to bring customer into testing and have a robust feedback right away instead of getting a lot of bugs and change requests at the end. It's not something new as well, there are frameworks like FitNesse by Robert C. Martin that accomplish this, the thing was that for some clients/projects you need to have an exact Excel equivalence in calculations, which means simulating Excel's errors as well. Even those, the customer is not aware of. That's where it's nice to actually verify everything back with Excel.

Estimation of software complexity in Agile projects

After that came Jarosław Swierczek with his 'Estimation of software complexity in Agile projects'. Now that was quite cool and controversial lecture. Jarosław stated that SCRUM's poker planning is nothing more than an expert estimation, something that have also occurred to me some time before.

Don't be fooled by the 'expert' part, expert estimation is nothing more than calculations based on intuition, something which may work for experienced people and repeating projects, but often end up with pulling numbers out of your ass. Sure, the poker thing helps a lot, having other people verify your 'out-of-ass' calculations helps as well, but it's still intuition. We would wish that it's at least heavy wizardry but it's not. It's not science at all.

Jarosław Swierczek stated that according to some statistics a bit more than 70% of expert estimation is wrong, when wrong means more than 30% difference. Unfortunately I had no chance to ask him where did he have this percent from and I believe that this may not be true for poker planning (does intuition work better for a group?), so it all stays as anecdotal evidence.

Anyway, he was able to show us a nice, scientific formula for estimating complexity and time-cost. Things that were especially interesting:

- You need at least two years of historical data (estimations of complexity and time + the actual results) to be able to do anything more than 'pull numbers out of your ass'.

- You need to choose a formal method of calculating complexity and stick with it (event the Functional Point method is not that bad)

- Complexity has got NOTHING to do with the time it takes to finish something

- How much time it takes, depends your team's performance, which should be calculated from sprint to sprint, which is depending on stuff like technology/experience/distractions, and can actually be calculated by expert method ('my intuition tells me I'm gonna be super fast/slow because I have a lot/little experience in this technology')

Jarosław has got his own consulting company Aion www.aion.com.pl where they help other companies with estimating complex projects, so of course you should be wary about marketing bullshit, but what he presented made a lot of sense to me.

Journey through tests and prototypes

The fourth lecture was given by Piotr Trochim, a game developer (his current linked-in profile shows CD Projekt RED, the company behind 'The Witcher'). Piotr was talking about TDD in game development, a situation which is quite different to typical enterprise/b2b/Internet development in that you create a hell lot of prototypes of different ideas before actually deciding what you are going to put into the trunk of your repository.

Well, we (Internet/intranet software developers) actually create a few prototypes too, especially when changing the technology, so it applies as well to us.

Since creating well written prototype does not pay off in the long run and only slows down the prototyping, Piotr suggested this change is TDD cycle:

- First create a working prototype or a few prototypes (max 4h) if you need to have to choose between something. Don't worry about tests, do it as simple and fast as possible.

- Decide whether the idea/technology is fine to be used on production

- DELETE the prototype(s) completely (never commit the prototype as it is very badly written)

- Now write the solution again, using TDD and best practices

- When you're finished, create a tool to help monitor/debug the solution. This could be anything from stuff as simple as logging annotation (so you can turn logging into debug mode and see what happens), to state visualizers.

For me the most important part was to NEVER commit the prototype and always delete it completely. This is something I've seen way too often, when programmers commit a completely chaotic prototype just because it works and try to extend it later with very poor results. It usually ends in refactoring bigger/longer than actually writing the same stuff the proper way.

It was also interesting to note, that while Piotr is using C++ for development, he creates most of the prototypes in C#, as it's simply easier.

Yeah, I wouldn't like to return to C++. The expressiveness of this language simply sucks.

BDD and Ruby On Rails using Cucumber and Rspec

Last lecture was from Pawel Wilkosz about BDD and Ruby On Rails using Cucumber and Rspec. Frankly speaking I was tired, I don't work with Ruby and using TDD for more than last 4 years I didn't have much to learn in here.  That's where I'd rather be on 'People' track, where all the guests were having an Open Space kind of discussion.

And then there was an afterparty, but that's a completely different story.

You can find official pictures from the conference in here.
All pictures by Krzysztof Dorosz.