July 4th, 2011
Automated tests are undeniable extremely important, preferably executed in an continuous integration environment. We can divide them in 3 major kinds: unit tests, integration tests and GUI tests.
Unit tests test small pieces of code, i.e. methods, classes. Integration tests test the interactions between different classes like they would used in a deployed application. GUI tests test the user interactions.
The Webdriver framework provides a Java API on the Selenium framework. It works quite nice!
The problem I sometimes see with webdriver tests is that they are used as integration tests which makes them much slower than needed. E.g. you don’t have to verify validations in your webdriver tests, do it in the unit tests. You don’t have to verify that your data is retrieved from the DB, you have integration tests for that. When your unit tests cover your dao’s, your services & your controllers and you have integration tests chaining all your layers, then there’s absolutely no need for testing business logic at the GUI level.
Mock your controller objects to your needs and your webdriver tests will look much simpler and run much much faster!
Tags: automated tests
Posted
in java | No Comments »
June 21st, 2011
Today I played with the @Cacheable annotation at work. We have several web applications using different other jar modules. In each jar module, we would like to include a default CacheManager configuration so we don’t have to duplicate it in every web application we would like to use it. We could simply include the spring-cache.xml context file from that jar in our spring-web-applicationContext.xml and the cache would be enabled for that jar using the default config it provides. In the web app, we could inject all different CacheManagers in one CompositeCacheManager so our caches would be found by the web app. That works nicely.
But, in Spring 3.1.0.M2, there is only one problem. When a cache is defined on a @Cacheable annotation, we _must_ include the CacheManager in the CompositeCacheManager, otherwise an IllegalArgumentException is thrown. That’s not exactly what I expected..
I expect when no CacheManager is configured defining the cache that is specified on the @Cacheable annotation, the @Cacheable is simply ignored on that method. That would allow us to use that same module jar, but without caching enabled.
Wouldn’t that be more flexible?
I logged an issue in the Spring Framework Jira (https://jira.springsource.org/browse/SPR-8477) with a patch provided.
If you like the enhancement, please vote for it, so it gets included in the 3.1 release.
Tags: cacheable, Spring
Posted
in java | No Comments »
June 8th, 2011
Doing overtime, you’re probably familiar with it. On almost every project I’ve been working so far, at least once (and in many cases, multiple times) the question was asked: does anyone like to work late tonight or on Saturday? We’ll provide some pizza or Chinese takeaway..
Well, it’s that time again. My current project isn’t exactly what one would call a success story. Were working with 3 teams of 8 developers on the same project, i.e. the same code base. The code base can be (and is) divided in several bounded contexts but there is also a lot of common stuff in the shared kernel. Hence we have to deal a lot with merge conflicts, not enough communication between the teams (despite all the good will), duplication of code/functionality, big builds, etc. The third team was added 3 or 4 months ago to increase our productivity to make sure we would reach our deadline.
Unfortunately, it worked out the other way around. For almost 4 sprints(i.e. 8 weeks!), hardly no functional stories were completed (to be fair, we did a 6 week architectural refactoring – but only ended up doing the half of what we wanted to do in those 6 weeks). So the overhead of adding a third team was clearly disastrous for our productivity. And it still is today.
Last month, the client decided after some special crisis meeting to keep going like we were doing, so with 3 teams. The deadline was extended by 2 months (but is now a really really dead deadline – can’t help it, but I always have to laugh with deadlines, probably due my history on other projects) and the scope was minimized to the bare minimum. In order to reach that deadline, the teams will now have to produce more functional stories than they ever did before (even when there were only 2 teams) and to make matters worse, not a single day of vacation was taken into account. Very smart and courageous decision!
So last sprint and this sprint, we have a few bank holidays (at least they should have known about them, the client _is_ a bank), so to compensate those lost days, we were asked to do overtime.
My answer was, and I didn’t have to think about it, NO! Simply, because overtime is not the answer for problems like this. Period. Only in rare cases, like deployment or urgent failures or when everything else has been tried, overtime can be considered. If 8 hours a day don’t suffice to get the job done, something is wrong. So deal with the real problem!
On this project, the solution would have been simple. Go back to 2 teams, start with the 3rd team on the next project. The overhead will be _much_ smaller. Give the developers _real_ hardware (instead of that shitty Dell OptiPlex 760 crapware). Pair less, pair pragmatically. Keep focused on functionality instead of refactoring after refactoring. Sure, everyone likes clean code, but you have to stay focused on the client needs. Reduce the number of developers per team.
If they would have done all this, and we would have been still in the red zone, I might have answered otherwise. This was one of the reasons (if not the most important one) I became a freelancer 4 years ago. I have been working too much hours for someone else. OK, there was a bonus at the end of the year, but others who worked much less had the same bonus as well, and comparing that bonus with all the extra hours didn’t help much either.. And now, even if they to pay me adequately for every extra hour, I still consider overtime as the last solution.
To end, 2 quotes that pop up into my mind:
* You can’t make a baby with 9 women in 1 month.
* bad planning on your part does not automatically constitute an emergency on my part.
Tags: craftsmanship, professionalism, software processes
Posted
in java | No Comments »
May 24th, 2011
For the last 9 months I’ve been pair programming, almost every day.
The company I’m working for really believes in 100% pair programming, day after day. One developer takes the lead of a story and each other day (or half day), an other developer joins the lead (repairing). Pair programming has it advantages like less bugs, knowledge sharing, better insight into the story, etc.. The technique is a well known XP practice. More on the subject can be found on e.g. wikipedia.
So what do I think of it after 9 months? I simply dislike it.
Let me explain that. I really believe in the strength of pair programming and I’m convinced people should develop in pair, but not every single moment. The scenario’s I can think of pair programming can be useful are e.g. a difficult problem to solve, design, introduction of a new team member, implement a story as an example, something unexplainable is happening, a weird bug..
The problem I have with 100% pair programming is the lack of freedom. The freedom to think at my own pace, the freedom to check something out in the codebase, the freedom to try something out differently, the freedom to give your mind a break and read the newspaper for 5 minutes. And last but not least, the freedom to advance fast. I’ve really missed these freedoms the last months and quite from the beginning I worked there. It’s not something that grew on me (well somehow it did, the frustration only increased, but it was there from week 1). 100% paired programming has a counterproductive effect on me. What bothers me the most is the slow pace I experience (the other ones are personal and maybe I should forget about them in the interest of the team). I really feel slowed down when I’m pairing. Maybe that’s because my pair can’t work as fast as I do? Or maybe he’s not as good as I am? Nope, some of them are even better than me  So, what it is slowing me down then? I believe it’s the need to speak everything out, the need to think synchronized and the overhead to do so. Sometimes, it creates discussions that aren’t even worth having.
So what about the knowledge transfer? Give me the code, I’ll read it and I should understand it. If not, I’m not the one to blame (to quote Marting Fowler: Any fool can write code that a computer can understand. Good programmers write code that humans can understand.) And what about avoiding bugs? Well, I’m a big believer of TDD and I think I’m practicing it quite well.
And you know what I also dislike in pair programming? The constant noise of conversations! We’re working in a big room where 3 teams are developing and it is never, never ever quite. And that’s really really annoying. How can one think, focus, get into the zone? It’s wearing me out. I’m glad when the day is over and I can go home.
100% pair programming is not my cup of tea and I’m pretty sure it never will be. To me, it’s simply wrong.
Tags: agile, pair programming, XP
Posted
in java | 1
Comment »
March 18th, 2011
You’re probably familiar with it, the build is broken. In a team with a lot of developers committing all the time, this might become a real pain. The build should succeed at least a few times a day otherwise the team might start to feel ‘naked’ not being backed up by a process giving continuous feedback. After all, that’s the whole idea of Continuous Integration platform: commit small working chunks of code, commit a lot, get fast feedback. If the build is broken, fix it asap. New intermediate releases should be deployed on the test environments frequently, so make sure you’re not introducing an impediment.
More on the subject can be found here: http://martinfowler.com/articles/continuousIntegration.html. Interesting read!
Unfortunately, with a lot of developers working on the same project, this might become hard. At least, so it seems.
I’m working at a project with about 30 developers. One can imagine a lot of code is being committed into Subversion every day. To make things more complex, a huge refactoring has been started about 6 weeks ago, moving a lot of code from the ‘old’ architecture into the newly defined bounded contexts. This is done by a ‘side track’ team. Two other teams are still developing new stories. So far, so good. But where’s the hard part you might be wondering?
To me, refactoring is just like writing new code. Make small changes, commit, keep an eye on the CI, make small changes, commit, … . But for some reason, when people start refactoring, committing in small steps seems to be very hard. As a result, big commits are submitted into SVN, other people get huge merge conflicts. The build starts failing, tests are broken, the application isn’t even booting anymore.
So, the 3 teams on the project decided to introduce the build token. As long as the build token is taken by the build master (indeed, we introduced a build master to keep an eye on the build.. *sigh*), no one is allowed to check in. As that didn’t work very well – the build is till broken -, the teams went a step further. A build queue was introduced and only the one with the build token is allowed to commit. But he should run his unit and integration tests first, taking about 25 minutes.
So, when receiving the commit token, one should update his code, run the build with all the tests and when it succeeds, he is allowed to commit.
IMHO, all that is kinda stupid. Creating a queue results in even larger checkins. People are getting blocked. People are syncing all the time to avoid merge conflicts and have to run their builds all the time on their local machine. So their watching build traces all the time. Off course, the build is succeeding on the CI now, but at what expense ?!? I mean, why do we even bother having a CI? We already know the build still succeeds as it builds on everyones machine before committing. Why bother maintaining and watching it ?
As a side note, for those who ever had to work with Visual SourceSafe (I felt your pain), one had to lock a file before something could be changed. Really annoying when working with a lot of people in a team. But this situation with the commit queue is much worse! Not a few files are locked, but the whole project is locked!
Again, IMHO, my only advice to brake this stupid spiral is to return to committing small chunks of code. Not running all the test locally (only the ones involved). Not caring about a stupid commit token, BUT keeping an eye on the CI. Every developer is responsible for his acts. He should feel bad about breaking the build. And this only works with fast feedback from the CI in order to avoid one forgets he committed some stuff and should keep an eye on the CI. Staged builds are the answer here. Or if possible pre-commit builds on the CI. TeamCity already has this feature.
So in short, let the CI work for you, don’t work for the CI.
Commit small. Commit fast. Be responsible. Feel guilty. Fix asap.
Tags: CI, craftsmanship, software processes
Posted
in java | No Comments »
|
