Sunday, April 27, 2008

Grails and Simple AJAX

For me there is no doubt that Grails is currently the most exciting existing web framework. But these days when talking about web development first thing that comes into mind is AJAX. And of course there is number of AJAX plugins for the grails (GWT, Flex, YahooUI...). But what when you need only simple AJAX functionality. Do you really have to include some of these big frameworks. Well actually no. Grails has built in simple AJAX support. Following tags can be particularly useful for simple AJAX functionality incorporated into Grails web application.


Among other common attributes of mentioned tags following are really useful:

  • controller - name of the controller to use

  • action - name of the action within controller

  • update - element to update or map containing elements to update in the case of success or failure

  • params - parameters to send with the call

Attribute that really enables AJAX behavior is value of update attribute. Content of the page placed between

<div id="value_of_the_update_attribute">

will be replaced with the result of the action specified by the action attribute.

For other attributes and more details you can have a look at the grails documentation.

Let explore remoteFunction tag as this one is interesting. This tag can be attached to the onX events of other Grails or HTML tags. To create simple grails application with the controller in the command line type:

grails create-app simple-ajax

Now switch to simple-ajax directory and type:

grails create-controller example

Now we can create view for the ExampleController so the ground for our example will be prepared. In the simple-ajax/grails-app/views/example directory create example.gsp file with the following code:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="layout" content="main" />
<title>Edit Project</title>
<g:javascript library="prototype" />
<div class="body">

So far important line to notice that imports one of the by default supported Ajax frameworks is

<g:javascript library="prototype" />

To prepare page extend the example.gsp with the following code.

<select onchange="${remoteFunction(controller:'example', action:'continentSelected',update:'continent', params:'\'continent=\' + this.value' )}">
<option>select continent</option>
<div id="continent">
Selected continent:

To get more info how to work with g:select tag have a look at this post.

Idea is that when continent is selected we will display selected continent :) This will ensure remoteFunction tag assigned to the onChange event of the select tag. Still we need to update controller to support this behavior. So add the following code into ExampleController

def index = {

def continentSelected = {
render params['continent']

Controller is simple enough. index action will display our example.gsp page when navigating to ExampleController while the continentSelected is action called from the remoteFunction tag. All it does it returns selected continent that is stored within params of the request. So when the user selects continent from the select box, ajax call to the continentSelected is issued and the content in the div id="continent" is replaced with the result from the continentSelected action.

So give it a try. Run the application by typing grails run-app in the command line and in your browser navigate to http://localhost:8080/simple-ajax

And we got simple Ajax. If this is not enough to see possibilities emerging change the controller code as follows:

def index = {

def continentSelected = {
def lst
def continent = params['continent']
if ( continent == 'America') {
lst = ['USA', 'Argentina']
} else if (continent == 'Asia') {
lst = ['China', 'India']
} else if (continent == 'Europa') {
lst = ['Slovakia', 'Serbia']
} else if (continent == 'Africa') {
lst = ['Egypt', 'Tunis']
} else if (continent == 'Australia') {
render ""
} else {
render ""

What we have reused here is possibility to use grails tags as method calls. Now have a look how to work with grails templates and tags and you will see that actually default AJAX support offered by Grails needs not to be so simple if you don't need fancy front end. Maybe more about it in some future posts.

Planning Extreme Programming

Few weeks ago I read book Planning Extreme Programming (The XP Series) by Kent Beck and Martin Fowler. To be honest according to the names on the book cover I expected more from this book. If you are professional and already have experience with extreme programming or agile software development this book will not give you too much. If you are new to this style of software development, or planning agile software development at all, I would for sure recommend this book so you can get overview and explanation why agile software development (particularly Extreme Programming) works better than more traditional approaches. Then for sure you need to read additional books to get even better understanding of the Extreme Programming.

In the book there is lot of comparison of planning we are applying in every day life and how to take that approach for software development.

After initial introduction in the few first chapters you are going into planning process more and more .

You will learn how to write user stories, how to do estimations, you will see that there is no plan but the planning process. You will learn why the first plan is the hardest one and then how the process of release planning works. After release plan is prepared iterations planning takes place. Iterations are steps within release that will help you to reach the final goal, successful project.

So for the end, my conclusion would be. If you are new to agile software development read the book as it gives excellent introduction and gives you understanding why agile approaches should work.

If you would like to find out more about user stories that are the base for the planning process you can read my review of the book User Stories Applied.

Wednesday, April 9, 2008

Scaling Scrum

My first contact with Scrum was related to "normal" Scrum: one team, at one place works on one project of average size. As I continued to investigate Scrum I have noticed that number of people are asking how to scale Scrum to larger projects and multiple teams. Question sounded so normal. Can I apply it to large projects?

Even now when I am explaining the Scrum this question is rising very often. Scaling seems like one of the most important things regarding Scrum. If we are not able to scale it, it is not worth to try it. Once I was asked this question by manager although I new they do not have any big project.

But as longer I am with Scrum this question seems odder to me. How many of you had a chance to work on such big projects spread around the globe? How many of you had a chance to work on projects that cannot be implemented by one team? I have been in small but also in very big companies and I didn't see project larger than 50 team members. Maybe I was in wrong projects :)

For me question is it possible to scale Scrum is not important. If Scrum can be successfully used on mid-size projects but it is not possible to scale it I would use it anyway on those mid-size projects. It is easy framework, it gives excellent results and usually people like it. So why should I bother with scaling anyway. I will think about that when I will need to lead on such big project.

So what is conclusion? Yes, it is possible to scale Scrum.
There is number of articles and books around the Internet. Just go and read them. But if you have really big project, then get somebody who has experience using Scrum on scaled projects.

As long as you are working on "normal" projects, you don't need to scale Scrum.

If you are new to Scrum, try to use it on small or mid-size projects. Don't worry about scaling. It will take some time until you are able to use it correctly on small projects and it will take much longer till you will be able to scale it without experienced Scrum Master.

Wednesday, April 2, 2008

Scrum: Lessons Learned

It is a year as we have started using Scrum as project management framework. At that time I was starting with a startup company and it was on me to decide and propose next steps. Somewhere at that time I read Scrum and XP from the Trenches and found implementing scrum web site. For me decision was clear. Most of the colleague had some experience with "kind of" agile software development. Unit testing, CI, SVN has been part of life. But Scrum, iterations, user stories have been something new and something we had to learn. Although I have studied lot of books we started with baby steps. Today I believe we are children but we have much more experience than year ago.

During our sprints we have made some common mistakes, we have made some less common mistakes and I will try to summarize what we have learned.

First let me shortly explain our situation. We are small startup company with number of projects. Therefore it is not possible to have consistent team size per project. Further on, very often we are not able to run more than two-three consequent sprints on the same project. Althout these are some Scrum pre assupmtations, I believe Scrum helped us a lot and we wouldn't be where we are if we would go without Scrum.

So what are the most important lessons learned so far:
  • Product backlog - although it is stated in all books and articles we very often failed to have prioritized list of features to implement called product backlog. When you don't have product backlog you are never sure about your future steps. So, always have product backlog with features to be implemented.
  • Product owner - when there is no real product owner, and this is unfortunately very often case in our situation, somebody else (product owner proxy) must take responsibilities of product owner. It our case it is me (playing role of developer, scrum master and product owner proxy).
  • User stories - although Scrum does not explicitly requires to express requirements as user stories, we found out that user stories are the best way to express requirement. It is easy to prioritize them, it is easy to understand them and it is easy to know when user story is implemented. At the beginning we used more generic terms for describing what we want to implement. That got us into position of never ending requirements (requirements that are never implemented).
  • Sprint planning - at the beginning we had short sprint planning session. We just listed what we want to implement without discussion. Consequence was that we didn't had common design understanding, we had different opinion of DONE. As we used longer sprint planning sessions (4-5 hours) those understanding got better.
  • Unfinished user stories - do not let sprint to finish with not all planned user stories implemented. If this is happening too often somewhere you are doing mistake. Lower your velocity, make better definition of DONE. If team is used that sprint can be finished but not everything is implemented this will repeat again and again. At the end of the sprint everything must be implemented otherwise sprint is failure.
  • Code quality - very often you want to finish tasks as soon as possible and therefore underestimating user stories. Then what usually happens is that at the end of the sprint code is not written with production quality and later on you have to return to that code. Actually what happened here is that you didn't finish user story. Therefore, give yourself enough time for user story implementation. Do not forget refactoring, discussions, integration tests, nice user layout and experience. Only if you satisfy all these requirements you will implement user story with production quality and will have potentially shippable code at the end of sprint.
  • Estimation - even after a year, we are still making mistakes when estimating. We can noticed improvements but we are still unsatisfied. For this problem for us there is still not solution.

And for the end, remember, Scrum is team work. Scrum master is here to help and protect the team, no to command the team.