Grails: a quick tutorial (1)
View more presentations from Davide Rossi.
martedì 27 gennaio 2009
Jug Grails tutorial
Last week I had the great pleasure to make a brief presentation about Grails to the JUG Milano, mainly about Domain Classes and GORM. You can find the slides on Slideshare
mercoledì 17 dicembre 2008
Java 5 advanced for loop and null values
A quick note on an argument that may be obvious, but I never run through until today.
The advanced for loop (the for(Type t : Collection) form), introduced in Java 5 doesn't check for null collections. What this means is that if you pass to your loop a null collection (possible, when you don't have total control on the arguments that are passed to your method), the for loop will throw a NullPointerException. This is a correct behavior, since usually you don't want to consider in the same way null collections and empty collections, but can be a source of errors (possibly runtime errors...) if you don't take care of null values by yourself.
The advanced for loop (the for(Type t : Collection) form), introduced in Java 5 doesn't check for null collections. What this means is that if you pass to your loop a null collection (possible, when you don't have total control on the arguments that are passed to your method), the for loop will throw a NullPointerException. This is a correct behavior, since usually you don't want to consider in the same way null collections and empty collections, but can be a source of errors (possibly runtime errors...) if you don't take care of null values by yourself.
mercoledì 10 dicembre 2008
Two hearts are better that one...
A technique we are using these day, along side with the Pomodoro techinque time boxing, is Pair Programming, even if we are using it in a very unstructured way. As with every agile programming technique, this one revealed its usefulness, but has some 'dark corners'. What is Pair Programming ? Essentially it's just two people working togheter on a single workstation, sharing a single keyboard: one programmer (the driver) write the code, the other (the observer) review the code, trying to find out potential problems, bugs, bad code or thinking about possible improvements in code or design.
Some researches and studies have proven that pair programming reduce bugs of about 50%, with about a 15% cost increase (which is good, as bug fixing is much more costly if done at a later time, maybe by a developer who does't know the code...). A nice side effect is just that code and design decisions become shared among the team (at least two persons...), reducing the management risk (no programmer is a bottleneck, being the only one to know critical parts of the system, anymore...). There are obviously other benefits, like training on the job for less experienced developers, less distractions, better design and coding due to double knowledge and experiences...
Along with all these benefits, there are some drawback (as usual...).
According to the tries we are doing we saw that not all activities are good for pair programming. For example, there are some jobs that would be made exactly in the same way by both developers (as a result of common experiences), where the design is well known and the code quite consolidate, or some repetitive tasks. In this case the bugs are naturally few, and are quite easy to resolve. So, the contribution of the observer is quite low. The risk is to bring some boredom to the pair, and the attention in the long term is reduced by the pair practice instead of increased.
Another important thing to remark, which is not always kept in the right consideration, is that not all developers like to work for the whole day in pair. Some developers like to work alone, at least for some time, when trying some new technology or when doing some common task.
Another thing to think about is how to apply pair programming along with the pomodoro technique. Working for 20 / 25 minutes side by side brings the natural question of how to organize the work: for example is good to make an advance design, shared by the two, before writing the code ? Or is better for a developer to start coding while explaining his point, and then to review the design together ? Or every developer must try to prove that his design is good before starting ? All these approaches can lead to good results or to bad results.
In the next days we will try to use some of these approaches and to find out which ones work better for our project, a first pace in the road to agility.
Some researches and studies have proven that pair programming reduce bugs of about 50%, with about a 15% cost increase (which is good, as bug fixing is much more costly if done at a later time, maybe by a developer who does't know the code...). A nice side effect is just that code and design decisions become shared among the team (at least two persons...), reducing the management risk (no programmer is a bottleneck, being the only one to know critical parts of the system, anymore...). There are obviously other benefits, like training on the job for less experienced developers, less distractions, better design and coding due to double knowledge and experiences...
Along with all these benefits, there are some drawback (as usual...).
According to the tries we are doing we saw that not all activities are good for pair programming. For example, there are some jobs that would be made exactly in the same way by both developers (as a result of common experiences), where the design is well known and the code quite consolidate, or some repetitive tasks. In this case the bugs are naturally few, and are quite easy to resolve. So, the contribution of the observer is quite low. The risk is to bring some boredom to the pair, and the attention in the long term is reduced by the pair practice instead of increased.
Another important thing to remark, which is not always kept in the right consideration, is that not all developers like to work for the whole day in pair. Some developers like to work alone, at least for some time, when trying some new technology or when doing some common task.
Another thing to think about is how to apply pair programming along with the pomodoro technique. Working for 20 / 25 minutes side by side brings the natural question of how to organize the work: for example is good to make an advance design, shared by the two, before writing the code ? Or is better for a developer to start coding while explaining his point, and then to review the design together ? Or every developer must try to prove that his design is good before starting ? All these approaches can lead to good results or to bad results.
In the next days we will try to use some of these approaches and to find out which ones work better for our project, a first pace in the road to agility.
sabato 29 novembre 2008
Working with a pomodoro...
I was recently at the fifth Italian Agile Day, where there was an interesting discussion about the 'rigid' use of agile techniques, in particular about the Pomodoro technique. I knew this practice but never tried it seriously, so in the following week started to use it with my team (along with other techniques we already used, as pair programming...). I will not explain the pomodoro (by the way...'pomodoro' means 'tomato' in Italian...), as there are a lot of good resources out there in the Web, but want to express some random tougths about it:
- It really helps you to focus on your work and to decrease your distraction
- The standard time of 25 minutes for a pomodoro is not always optimal...I think this technique will be more effective not using always the same pomodoro time ( just a 5 minutes variation can do the work...). Obviously you change the pomodoro time before starting it, not during it. The gratest drawback of not having a constant pomodoro time is that you loose some precision in the extimation phase, as old pomodoro times can vary, but you gain in using more effectively your time
- It's not a capital sin if you go on working after the pomodoro rang, if just for a few minutes (3 - 5 min). In my experience sometimes the last minutes of a pomodoro can be the most productive, and there is no evidence of a bigger number of mistakes as someone (the agile radicals...) say. By the way, my pomodoro rang as I was starting writing this third point...
Maybe after some more use I will become more radical, but I always like flexibility, and don't think the same exact way is good 'as is' for everybody...
(total writing time: 1 pomodoro + 4 min...I'm slow when writing in English...)
- It really helps you to focus on your work and to decrease your distraction
- The standard time of 25 minutes for a pomodoro is not always optimal...I think this technique will be more effective not using always the same pomodoro time ( just a 5 minutes variation can do the work...). Obviously you change the pomodoro time before starting it, not during it. The gratest drawback of not having a constant pomodoro time is that you loose some precision in the extimation phase, as old pomodoro times can vary, but you gain in using more effectively your time
- It's not a capital sin if you go on working after the pomodoro rang, if just for a few minutes (3 - 5 min). In my experience sometimes the last minutes of a pomodoro can be the most productive, and there is no evidence of a bigger number of mistakes as someone (the agile radicals...) say. By the way, my pomodoro rang as I was starting writing this third point...
Maybe after some more use I will become more radical, but I always like flexibility, and don't think the same exact way is good 'as is' for everybody...
(total writing time: 1 pomodoro + 4 min...I'm slow when writing in English...)
martedì 11 novembre 2008
Grails & Spring together...
The news is fresh, and unexpected, but big, very big for the Groovy / Grails world. G2One, the company behind Groovy and Grails technologies, was acquired by SpringSource, the company of the popular Spring framework (read the news). What does this mean for the future of Groovy and Grails ? From the technical side, Grails is build on top of Spring, so the integration between the two technologies can be more tighter in the future. Also, SpringSource can dive into the world of dynamic languages backed by a mature and fast growing technology. But the most important thing is not technical but commercial. Backed by SpringSource, Grails will enter in the arena of enterprise applications from the front door. The technology is very good for big projects, as the social network LinkedIn and UK TV broadcasting giant BskyB sites demonstrate, but is still facing a lot of resistance in big and meaningful projects, maybe because it's considered too new or not reliable...This is likely to change in the future as a result of this acquisition. Tell your boss, and to the big boys in your company...Grails is going to become mainstream...
Iscriviti a:
Post (Atom)
