Maven - filtered apt page

Yet another story of my love-hate relationship with maven ;-)

I had a standard easy task: add a "Downloads" page to the maven-generated site, with links to the assemblies generated during the build. Easy task, right?

First step - make maven-assembly-plugin put it's outcome to the site directory - easy :-)
In the maven-assembly-plugin configuration section add:

<outputdirectory>${project.reporting.outputDirectory}/download</outputdirectory>

This would put assemblies directly into target/site/download directory, with the name like artifact-name-0.1.0-SNAPSHOT-kind.zip, ready to be linked from the site.

Now, lets make a menu item in site.xml in case it is not already there:

<menu name="Overview">
    <item name="Download" href="downloads.html">
    </item>
</menu>

If the name of the downloaded file didn't change every release, it would be enough to create a downloads.apt file with static links to download directory and that's all. This was the way I did it in my previous project. I configured assembly to skip the VERSION part of the generated file name and it was it.
This time, I wanted the file name to retain the version information, so after looking at the maven-site-plugin help (at the bottom) I decided to rename the file to downloads.apt.vm and try the VM support for apt. (I could have used an Expression in site.xml and be done...)

VM support appeared in the 2.0-beta-6 version of the site plugin, but I use the latest Maven 2.0.8, so the right version should be just downloaded, right?
Wrong.
In the master-master-pom included by master-pom included by my pom, the site plugin is set to 2.0-beta5 (thank you, maven help:effective-pom :-) ). Somebody must have decided it is nice to have the latest site plugin back then.

OK, so now the downloads.apt.vm is actually parsed.

I have put the ${pom.version} in the file, hoping it would resolve to my 0.10-SNAPSHOT. No way - it doesn't. So I tried a few variations - no help.
But hey - they say it works for them! Either they lie, or there is another gotcha I just don't see.
I wish I had a second pair of eyes then, but we don't pair program for just a quick config change (we should with maven).

apt.vm's apparently are not filtered with project properties, just custom ones. After taking a glimpse of supposedly working POM/apt.vm pair, I added the required <properties> to my pom:

<properties>
 <currentVersion>${project.version}</currentVersion>
 <artifactZip>${project.build.finalName}.zip</artifactZip>
 <downloadDir>download</downloadDir>
</properties>

Now it works as I wanted.

A nigthmare flight

So, we (me and Wojtek) flew to Sydney few days ago to met other Atlassians and suck in their knowledge. Today I'm sharing a nightmare story about how things can go wrong ;-)

The troubles started in Warsaw when our flight was delayed for 1,5 hour because airport London-Heathrow wasn't able to accept our flight. We waited in the plane in case we would get approval earlier. But that didn't happen.

We arrived exactly the moment our next flight was supposed to depart. We had to switch terminals. Then we had to run to our gate. Stewardess said during the flight from Warsaw that we're not the only ones going to Sydney and that they were informed. We had hope that may be they'll wait. So we ran. We got to the gate exhausted. We saw that airplane was still there. But unfortunately the ground crew didn't want to let us in. They said it was too late for us.



So we went to the customer service for help. It was late before 11:00PM. There wes a lot of people waiting in the queue. A lot of them wanted to go to Sydney.






After 11:00PM 4 of 6 people from customer service went home as their shift was ended. Only manager and another guy stayed to help us. We waited there for about 2,5 hour to get a voucher to a hotel. Fortunatelly hotel was close to the airport.

We were supposed to go to the customer service in the morning for some help. We had a luck that we were supported by a great customer service rep. It was very hard to find a place on a flight to Sydney. The guy tried a lot of combinations - flights through Dubai, Kuala Lumpur, US. After 45 minutes he was able to find for us one place on a flight to Sydney through Hong Kong, and one place through Hong Kong and Melbourne.




I was on the second flight. We flew for 12 hours to Hong Kong, then I instantly went to Melbourne (another 9 hours). In Melbourne I found out that my baggage was lost. Then I had to wait in a gigantic queue to customs. I also had to report missing baggage. This caused me to miss my flight but fortunately Qantas made no problems issuing my another flight. So I flew to Sydney. Wojtek's baggage was also lot.



(from Melbourne to Sydney Australia looks same all the time ;-)

No one knows where our baggages are :-(

I learned few things: don't fly through London, 2 hours between flights seems like enough time but in case something goes wrong it's not enough. Always mark you baggage in some way - you may not remember color of your bags, but I'm sure you'll remember the marks.

In case airline did something wrong ask for a compensation. They don't want to tell you but they usually have some policies that you can use. We got vouchers for lunch and dinner in London because Wojtek asked about them. He also got some cash in Sydney for some shopping. Also don't combine ticket bought separately - this limits responsibility of your carrier.

Why you should hide your new gadget from your wife

My new smartphone arrived last Friday.
The weekend has been quite full of social events, so I had very little time to play with my new toy. I hoped that Sunday evening, after all the social duties fulfilled, I will be finally able to install all the stuff in the download queue and give it some proper half-night manual testing (Monday SCRUM planning starts at 10:00, right?)

No way - my wife discovered that the phone came with Bubble Breaker pre-installed. So, instead of a serious software provisioning and proper acceptance testing by a qualified person (which would be me), the hardware is occupied for casual gaming.

Fortunately, I was spared from a "do you really need to spend ...$ for a toy" discussion beforehand, so I guess I will patiently wait for my turn. Maybe I write a blog post or something...

BTW - it's ETEN M700

Ranks and Rants - problem solving?

I'm writing this post in response and addition to Jens Schumacher's comment to the Ranks and Rants post.

I just recalled the meeting we had with the creator and CEO of LCC Centralwings. I'm going to test problem solving technique he described - do you remember it?
As far as I remember there was four steps to talk about some problem/fuck-up with someone who did something wrong. The most important thing is that you have to do this face-to-face instead of on the team forum. If you intimidate the person this would be the worst thing you could do - it will help neither the guy nor the team.
So, if you call the guy to some "isolated" and quiet place you should follow the algorithm ;)

1. Describe what the person did (DO NOT JUDGE!); tell the raw facts e.g. You answered your cellphone three times during our meeting


2. Explain what IT DOES TO YOU e.g. It disrupts me - I cannot focus on the meeting agenda and on the task we want to accomplish here


3. Describe the consequences if this person will persist doing the wrong thing e.g.I will not come to the meeting with you ever again because if I can't focus on the job the meeting is useless to me


4. End with something optimistic e.g. Anyway you have to know that I think you're a great engineer and I like you very much or Let's go and have some beer ;)

It's not so easy to talk to somebody this way - I know. But I think it works in many cases - IMHO it is definitely worth trying.

The very important thing with problem solving is to remember to Attack the PROBLEM not the PERSON. It sounds like cliche but it's a principal in my opinion.

What else we should remember when the problem occurs? I think that we should try to solve the problem AS SOON AS WE SEE IT - not after one month or a year (like we were used to in our previous corporation).

One more cliche in this post: COMMUNICATION is the key to the success. When we started communicating with each other after a year from the team startup we became the REAL team. Before that we were just nine individuals doing some stuff together.

PS. Sorry guys for butting in your blog but I still feel very close to all of you (although I now live 2000 kilometers from you) and I want to add my few cents from time to time. I hope you don't mind.

My Managerial Screwups - Part I (of plenty)

A major part of a life of a manager (as any othe rprofession I guess) is making mistakes. Mistakes are inevitable and it is a good idea to realize that they ARE going to happen to you. A lot. Even if you are good at being a boss. So I have decided to amuse you with a series of stories documenting my managerial screwups.

Let's start with what happened yesterday. It was a nice Friday and we were just finishing our first ever Scrum sprint for a new employer. We were optimistic. The sprint was coming along nicely, we had already managed to do finish more user stories than the team hoped for, including one high profile, visible feature. At 5:30pm I decided that it was time for me to call it a weekend. But some of the guys wanted to stay for a bit more and finish things up (can you spot the problem already?). We agreed that they would send me a finished version of the code, so that I could formally announce the end of the iteration and pass the thing to potential early adopters.

After coming back home I connected to our build server and noticed that builds are down. WTF? I noticed in the IM that one of the guys was still working at the office, so I asked him what was going on. Turned out the SVN repository had crapped out on the team, so they couldn't commit their changes and what I was seeing was an old, broken version of the code from earlier in the day, which was known not to compile. But the SVN eventually went back up just as the guys were leaving the office and they decided to commit from homes. Everything was supposed to be fine in an hour or two (can you spot the next problem here?)

I came back to the build server web page at around 9pm, after putting my 4 month old to sleep (took me an hour on this occasion. Little bloke kept refusing to close his eyes, even though he was tired beyond imagination. Kids are weird). Guess what was going on? The builds were still failing, even after the latest and greatest commits! I called a conference on IM with whomever was available to figure out the problem (remember, this was Friday evening, after 9pm, what was I thinking?). Four people were online. They established that Maven plugin was apparently the culprit - it ran out of memory for some unexplainable reason. The guys tweaked and massaged the code for about an hour (could be longer, I am not sure), until eventually one of them told us that his wife was really starting to get pissed off at all of this. At this point I have realized that this is going too far (too little, too late). I have called it a day and announced that we will do an errata build on Monday, hopefuly it will not take more than an hour to fix the code (we have a good idea about what is wrong).

Now, what are the lessons to learn here? Let me list them for you (in no particular order):

• never, ever make your team work on Friday evening, from home or otherwise, unless you are in a business of saving lives. It is not worth it. Also - you have no right to do it. Also also - it won't work, they are tired, they will make mistakes and overall the whole effort is likely to fall apart. I owe an apology to the team - guys, I have screwed up, it will never happen again. I guess you should be taking this mishap into consideration the next time we evaluate each other
• never finish the Scrum sprint on Friday. Whatever can go wrong, will go wrong. Don't assume everything will be fine. I guess from now on we should be ending iterations on Thursdays and allowing for Fridays to be a fixing time in case there is trouble
• don't go home until you physically receive build artefacts from the team and see with your own eyes that the final commit does not break anything in the automated builds and tests (local copies on developers' machines do not count - they always work fine for some weird reason)
  
• to paraphrase the words of Hector Barbossa: the rules of Scrum are just guidelines. You tailor them and adapt to the circumstances. You don't HAVE TO finish the iteration on the day it was planned to be finished. Display some flexibility
  
• software sucks. SVN is generally stable, isn't it? No it isn't! It will betray you at the worst moment like every other piece of shit code out there. And don't get me started on Maven - it is clearly a spawn of Satan himself. Still, it is better than alternatives ;)
  

Ranks and Rants

Today was a very special day for us. Let me start with some introduction first. We worked at a very big corporation before and one of things annoyed us was the annual review. Each year my manager had a task to gather input from other people that worked with me, then process it, and at the end provide some feedback for me and decide whether I'm bellow, in or above average of other employees. You probably have something similar in your company. It's a very popular process. And it sucks.

It sucks because usually it's anonymous - you don't know who reported on you, it unidirectional - you can't discuss and explain things. So if someone says that you did something wrong, you can't talk with him/her, you can only try to explain this to the manager. That sucks because this doesn't solve any problem, it doesn't promote any healthy way of dealing with problems in the workspace. I know, I've been there. It doesn't promote communication. I'd say it discourages it.

Also it sucks because it's done rarely - year is a very long time. You don't remember what happened at the beginning of the year or in the middle. So usually you tend to comment only last months before review. Also if something went wrong and you got a bad mark you'll screwed for the whole year.

So we came up with something different. We've decided that in our team outside this big corporation we would want to promote open, direct and honest communication. We came up with the idea of monthly based reviews when all team members sit together and discuss.

We had a first session today and I'd like to share with you my thoughts.

The rules are very simple. Each has 7 minutes to talk (1 minute per person x 7 people). When someone talks you shut up and listen, no comments, no discussions allowed. You can say good or bad things about each person. If you think that someone was better than you assign a point. You have 7 points at maximum, one person can get only 1 point. In case you feel that someone was worse than you don't give him/her a point. Everyone is involved. After all people said what they think you can begin discussion - so you can talk about what was wrong, defend yourself, try to explain, resolve things. That's all. After the meeting you forget about bad things that happened. You must not go back to them and bring them up again.

Simple? Right?

Well, but when it comes to real life things can become messed up. In our case it was hard to stay calm and not to interrupt others. We resolved this by enforcing this rule. We had some bad feelings towards some of us so you can imagine that the air was thick ;-)

After everyone talked we started discussing things. It was great that we had a chance to talk about problems. The main topic during our meeting was the communication process. We saw that many bad things can happen if you don't communicate well. Well, in our case happened. For the most of the time (prior setting up the office) we used e-mail based communication. When we started talking with each other face to face after we setup the office things changed dramatically for the better. People felt it and talked about this today.

We all agreed that in case we want to success we have to communicate better - talk more often, share more, be more open. We not only have to do things, we need to provide context to others (why, why not, when, what if). This way we'll be able to understand each other.

I think that today's session cleared the air and showed that we need to focus on communication. It also proved that it's good to discuss things in open manner and even if something is wrong we can talk about it (and we should). It was a really refreshing experience. It helped us understand each other better.

Tomorrow we'll discuss how to improve this meeting, and how often we should do it.

I'll update you next time we do this. You'll be able to see if it works or not from time perspective.

Have you ever wondered how those other cool companies look like?

Here's a couple of photos from Flickr, Digg or Facebook. Here's also a great resource for photos of other companies - a lot of them like Intel, LinkedIn, Twitter, ....

How does our office compare? :-)

70 years of Donald Knuth

I've just read that Donald Knuth turned 70 yesterday! His one of the big minds behind current computer science.

He wrote a series of books about art of programming. He also created one of the most advanced typesetting system called TeX. I once learned it's derivative called LaTeX to publish a book. It's a programming language for documents!

Donald is also responsible for promoting the O(n) notation. Read more on Coding Horror about his achievement.

We're settled (allmost)

So, here's another set of photos from our office. We managed to make it habitable ;-) We have some cleaning to do, some other tweaks here and there, some shopping, etc. But the main part is done.

Here's Łukasz unpacking his new MacBook Pro, he likes the thing ;-)


Slawek's and his desk, yup - this monitor is sooo big ;-)


Wojtek after unpacking already started coding ;-)))


Marek is thinking hard...


Our handy-man Janusz, he has skills:

And nice tools also:

He assembled our kitchen!

Our big server room, with highly professional ending (those cases, wiring, etc.;-), done mostly by me.


Łukasz fighting with a printer that is talking in German:


Jacek and Piotr at battle stations and ready for action ;-)


You can see also other photos