jan blog

Am I getting something wrong? (thinking about OOP)

2010-08-02T01:00:00.002+02:00

Maybe I am totally wrong but here is what is in my mind. Most of the books that describe object oriented programming, architecture or whatever are making examples using “objects” like person, cat, mammal and then big hierarchy of classes. Of course, more advance books are explaining why huge hierarchy of classes can be wrong and why it is good to use composition. I will not even try to explain that in this post.

And then having these classes you can read about different aspects of OOP. Some of the examples can be:
dog.bark()
person.walk()
person.openDoor()
engine.start()

And I agree that these are almost great examples (except person.openDoor() where I will come back later on).

So let me try to explain where are I am aiming with me question (in the caption of the post).

For learning OOP these may be good examples but from my experience so far these are cases that I don’t meet so often in practice.

Let try one example. Imagine class Can (not verb but noun). Coming from the examples above one could model method: Can.open(). Uhmmm, is it really possible that Can is able to open itself? I wouldn’t say this is reality.

So what is solution here? Quite straight forward. Model a class CanOpener. Then model method CanOpener.open(Can can). This is now much closer to reality.

But what is Can and what is CanOpener from the programming point of view? Well I would say:
Can - is data
CanOpener - is service

And in most of the projects this is what I meet. Most often you are working with data and then perform something on that data. If you try to model your solution as explained at the beginning of the post you will finish with domain classes that have hundred of methods and probably thousands of lines. But very often domain classes are just data while services are actually performing real work. But be careful not to fall into trap of procedural programming.

So come back to example from the beginning: person.openDoor(). As I mentioned this is not good example. And again I would model this quite differently:
Door
DoorOpener (interface)
Person (implements DoorOpener)

It is clear that doors can be opened by person, but they can be opened by engine or wind. So “item” that is able to open door is again service while door is just class keeping data (entity). And yes, you need to add code to open door into Person but again this can be great situation to use composition.

I hope I successfully explained how I try to model solutions for programming problems.

And just short note at the end. Please do not add Service, Manager or similar words at the end of class name. It can easy trap you into procedural programming as you will place too much responsibility into those “managers”.

Starting with Startup - Agile Acceptance Challenges

2010-07-31T00:00:00.000+02:00

When starting with the agile development (Scrum as base in our case) there are always some challenges that you will meet at the beginning and during the road.

I will try to explain structure of the team and acceptance of different agile parts.

Team

We have started with team of 6 (including me). Two of us already had experience with Scrum, one of us had experience with classical water-fall models and three had no experience with project management models. Few months later the team was extended with the tester.

The structure of the team was (is) following:

3 senior developers - 2 with agile experience and 1 with water-fall experience

1 intermediate developer - experience only with ad-hoc project management model

1 junior developer - no experience with any project management model

1 designer - no experience with any real project management model

1 tester (few months later) - experience with water-fall models

So let see how this team went through agile adoption.

For each part I will split acceptance into three parts:

- with agile experience - acceptance of the team members who had agile experience

- no experience -acceptance of the team members that had no experience with project management methodologies

- water-fall experience - acceptance of the team members that had experience with water-fall project management models.

Writing requirements (user stories)

With agile experience

Team members that already had agile experience had no issues in writing user stories.

No experience

Team members without experience with project management methodologies accepted user stories as the form of writing requirements. At the beginning there were some issues to write user story of the right size (sometimes they were too small or too big) but they got the right form very quickly.

Water-fall experience

In the case of developer user stories have never been really accepted. My feeling was that there was no even wish to understand what is advantage of user stories. User stories were constantly too big (e.g. As admin I can do anything). Actually this colleague have never accommodated to agile development and left the company later.

In the case of tester acceptance of user stories came much faster. For him it is much easier to understand what to expect when user story is implemented. It is obvious that tester prefers user stories than complex use cases or other functional specification.

Estimation

With agile experience

Surprisingly here we needed some time to accommodate. The reason was that I have decided to use story points as estimation method. But the team member with agile experience was used to ideal person days estimation. It was confusing for him for some time. But at the end estimation model with user stories was fully accepted

No experience and water-fall experience

After some turbulences at the beginning estimation model was accepted. The most issues were regarding over-estimation and under-estimation. But with help estimation became better and now is constant.

Meaning of DONE

Meaning of DONE in agile is very interesting. You should finish user story in the way that in the future you should not come back to that user story. User story should be ready for production.

With agile experience

Anybody with agile experience should not have problems to get meaning of DONE. At least that was the case with us.

No experience

At the beginning it was not so clear what DONE means. There were questions like: Is it already DONE? Can I improve this? I have such good idea, can I add it?

All the time I have insisted only on implementing user story and focusing on tasks. Very soon they realized what done means and actually realized why DONE is very helpful.

Water-fall experience

Here situation was much more interesting.

Developer with water-fall model experience had constant problems to get work DONE. There were always small tasks that can be easily finished later. There were always some missing features because they were not specified enough in the user story description. The "wrong" influence of the water-fall could be felt most of the time.

But tester was much happier. He read user story and had understanding what to expect from it. This way he can test and easily see if it is DONE. There are no answers like: I will do it later. It quite simple - if you sent user story for testing everything must work.

Testing

Under "testing" I mean writing unit and integration (as we use Grails) tests. Here situation differs from team member to team member. Some of them understand and know how to write good tests and some of the are still fighting to get the tests right. The most common issues are like:

- writing test that tests too much functionality and spread through number of classes or services.

- writing test that tests method not functionality

Conclusion

My feeling is that team accepted agile development very good. For team members without project methodology experience agile acceptance was easy and what is the most important natural. They have feeling that it is the right way to do the work. The most problems had a developer with water-fall experience. But the proof that having water-fall experience does not mean it is impossible to accommodate to agile is new team member that also came with water-fall experience but is accepting agile approach very good.

What is your experience in accepting agile?

Starting with Startup - Minimizing Unknowns

2010-06-17T00:17:00.000+02:00

In the previous post I have explained some reasoning why have we selected certain technologies, tools and processes. As mentioned all decisions were made to minimize number of unknowns in the project.

So process was selected in a way so we can adapt easily - means Agile.
Tools and technologies were selected according to project needs and common knowledge of the team.
Hopefully team will get know each other as time passes by and I have believed that everything will go fine (and mostly lucky for us that was the case).

But the biggest unknown was still there - PROJECT.

You cannot start development before you know what need to be implemented. Just having list of user stories would not be enough. You have to understand similar projects, you need to feel similar projects, know what are your main differences and how to use them to be successful.

Or in short - team has to share the same VISION.

And next few sprints were devoted exactly to this. Project investigation. We have been doing 1 week sprints and each project member was investigating different aspects of the similar projects. We have studied things like:

features
user interface
easy of use
lot of discussion with product owner to get feeling what are his main ideas

At the end of each sprint we had demo. Demo was used to present in details what are doing similar companies (should I say competitors :) ). This way all project members (including product owner) were able to better understand what is expected from us and in which direction we should roll out project.

We did couple of week length sprints and when we have feel confident enough we were able to start with the project.

So let summarize steps we did so far:

process selection
team educatin
tools and technology selection
project investigation

And now we are finally ready to start with the project. So in next posts I will describe some challenges we had during project development. Stay tuned :)

Starting with Startup - Tools and Technologies Reasoning

2010-05-31T23:04:00.001+02:00

For those that read 'Starting with Startup' posts I want to apologize for not writing recently but last months we have been working a lot. You know how it is in startups :)

In the previous posts I have explained processes and tools we have decided to use. There were some comments and questions why this and not that technology and similar.

When you start with the startup everything is completely new. The following list captures the most important new things that each member of the startup team meet:

team members
project
processes (you cannot expect that each team member will have experience with the process you select)
technologies (you cannot expect that each team member will have experience with all technologies you select)

As we all know it is much easier to predict result if there is minimum of unknowns. And in the startup company more or less everything is unknown - from the project to the project acceptance from final users. So what you try is to minimize unknowns. And to do that you have to carefully select each aspect of the technology and process.

I would say that selection of agile and Scrum is more or less straight-forward. You want to be able to adapt to each new situation that will come up and what gives you more possibilities for that than agile development.

How to minimize unknowns in the project will be topic of further posts.

And at the end comes technology. And here is reasoning similar. You select what suites the best for the team and the project that is in front of you. And that is reason why we didn't select some upcoming technologies like GIT. We have created list of tools we need and then selected those that are the most known to all of us. And the result of selections are in details explained in the previous post.

Starting with the Startup - Setting Up Development Environment

2010-02-15T22:06:00.000+01:00

After we have set basics for using Scrum we can start with our first sprints. Our first sprints were devoted to choosing and setting up development environment.

So let explore what do we know so far about the project (of course I knew much more than I can write in this post).

* Our main focus are desktop and mobile web applications

* Our core business is in the field of affiliate networks

* We will use agile process or to be more specific Scrum

So I will jump directly into decisions we had to make and what have we decided:

Web development framework

Basically we have been deciding between two choices: Grails and Wicket. Who is reading my blog from time to time probably already knows answer to this. We have decided for Grails.

Build process

Although Grails have nice build commands we needed something that is easier to integrate with the builds of other projects. Basically we have been deciding between maven and ivy. As Grails supports ivy much better than maven we have decided for ivy.

Continuous build process

More or less we have not been thinking too much here. We have decided for Hudson. Hudson is easy to install, has great front-end for management and number of very useful plugins. One note: although Hudson has Grails plugin we are not using it. We are using ivy in the Hudson to build the Grails projects.

Bug tracker

Although we would be happy not to have bugs that is not reality. So we needed bug tracker. As most of us had experience with Mantis we have decided that our bug tracking tool will be Mantis

Libraries repository

We will be depending on some external libraries. As we don't want to have them stored on Internet we needed some tool that handles dependencies. We have decided for Nexus.

Source code control

Although there are new source code control system like git we have decided to use probably the most common one Subversion

Mobile web development framework

After lot of investigation you find out that the market with the mobile web application frameworks is quite poor. The only available and really useful open source solution is: WALL NG. Luckily we have managed to almost fully integrate WALL NG with the Grails.

IDE Tool

Although we didn't have any experience with InteliJ Idea as this is currently only tool with good support for groovy/grails we have decided that our IDE tool of selection is InteliJ Idea.

In-house Grails plugin repository

As Grails has number of useful plugins and we knew we will be using them. This leads that we need local Grails plugin repository. Grails repository is set in the Subversion.

Having setup like the one mentioned above should give you fluent build process that is easy to repeat in the any moment. Additionally Hudson will ensure that your build is in the fit condition because it will report all build and test breaks.

Starting with the Startup - Start Using Scrum

2010-02-04T23:05:00.002+01:00

After Scrum has been selected as process and the team have been educated about agile and Scrum we can start with setting up development environment. Very important thing to notice is that we can start using Scrum right away. Yes, Scrum can be used for tasks where you need to make decisions, investigation, setup of development environment and similar tasks.

As quite often those tasks are not too much time consuming and you want to review current status more often it is best to start with short sprints. E.g. we decided to make one week sprints. This means that you can review your progress, adapt to new findings and adjust your directions on the weekly basis. When you are deciding about length of the sprint you should ask question: For what time period can we be sure that we will not change our minds?

The first thing we did was not part of the sprint but we did that with the purpose. We wanted to select some Scrum tool.

More or less there are two basic options:

* Using excel for product backlog and sprint backlog
* Using some of existing (commercial or open sourced) Scrum tools

We have decided to use ScrumWorks basic edition with the addition of the big pin-board.

ScrumWorks enables you to have product backlog, sprint backlog with the burndown chart, and some advance reporting options. Pin-board is used for user story cards. Idea is to split the pin-board in columns (e.g. todo, progress, testing, done) so everybody can see the status of the current sprint by simply looking onto it. If you are asking: isn't Scrum tool enough, I would say no. The reason is that if you are not part of the team, to check the status of the sprint it is enough to check the pin-board. Without pin-board you would had to open Scrum tool and this is already enough to give it up on checking status of the sprint.

One of the most important features of the agile and Scrum is transparency. We want to be aware of the real situation in each moment. If the project or sprint is late we want to find it out as soon as possible.

So we have prepared our Scrum tools and now we are ready to start sprint(s) for setting up development environment.

So how we set up development environment will be described in the next post.

Starting with the Startup - Educating the Team

2010-01-31T22:37:00.000+01:00

In the previous post I have explained why we have choose agile approach or more directly Scrum. But before you start using agile approach it is very important to explain what is agile and Scrum to the whole team and of course to the management.

In our case we are lucky because we have full support from the management. It means there are no "artificial" obstacles in implementing Scrum. The only real obstacle are we. So before going on I made presentation about Scrum, team members did some reading and then we discussed about the whole approach.

So when you are educating team do not forget to explain to them:

Cores of the agile and the Scrum

And especially take care to explain:

Why everything in Scrum is time-boxed
What is user story and what are the differences between user story and use case
What means DONE
What is goal of the sprint
What is velocity and why it gives better estimation when things will be done than "classical" approaches
Why testing is so important in the agile approach
What is burndown chart and how it helps the whole team

It may be clear why these points are important but I will shortly explain why I think it is important to take care there is full understanding of them.

Time-boxing - very often developers are used to implement some tasks as long as they want. Even after deadlines. In Scrum everything is time-boxed because this way everybody have to be focused that features have to be finished in proposed time. So it is not possible to change architecture forever. In one moment you have to decide and do implementation.

User story - in lot of companies and even in schools developers are used to thing in use cases. While use cases are good very often they put limitation that need not to be set in given moment. Classical examples are: then user clicks the button.... How the use case knows there is .... button. User story explains functionality that user wants to achieve without too much details.

Done - Done must mean: I am confident that feature implemented can go online. It is tested, written in good quality and I believe there are no bugs. This should be approach for all features that are marked done. You should not return back to this feature.

Goal of the sprint - you have to set goal if you want to have good feeling at the end of sprint. How could you know if your sprint was success or failure without clear goal?

Velocity - velocity is number that based on the experience (yesterday's weather) tells you how much team can implement in the given period of time. Velocity is better than "classical" approaches because it covers meetings, phone calls, unexpected bugs and everything that is happening more or less regulary.

Testing - if there are no tests how can you change the code and be sure that you didn't break any of the existing functionality. Well you cannot and you have to check everything after each change. If you have lot of tests you just run them and find out immediately if you have broke some existing functionality.

Burndown - is great tool that tells you without mercy you current status. It will tell you if you are doing good or if you are doing bad. Just have it in front of eyes.

Conclusion: If you have decided to take agile approach do not forget to educate developers what is agile. It is better to do it at the beginning then fixing problems in the middle.

Starting with the Startup - Selecting Processes

2010-01-26T22:08:00.001+01:00

In the previous post about Starting with the Startup I explained that as our first step we have decided to choose processes. Of course one of the most important decisions to make is to choose right management methodology (framework). The product owner (managing director) was coming from the company with the strong full life cycle (waterfall if you prefer this way) process. He had no idea about any other processes and he was used to work in that way. Even all the next steps he planned were in that direction. There was plan to hire external consultant that will more or less write "book with the boxes" that we will implement. And that will be our solutions.

The good thing is that although he didn't know for something else than waterfall methodology he didn't like waterfall approach.

So as you may guess it was not hard to explain him what is agile, what is scrum and what are advantages of the agile approach compared to waterfall approach.

For those who don't know difference just shortly: in waterfall you define and plan the whole project in advance and then just implement what was planned. No changes are allowed or complex change request processes are defined to introduce new requirements. In agile style you create vision and rough plan of your project and then implement your project in increments and iterations. You allow project to grow and change in the way according you new discoveries or business needs.

Selecting agile approach out of the box would be mistake because for any decision you should have a good reasons. So let analyze situation we have.

We are startup company with small number of developers.
We have rough idea what is our goal
Our main focus are desktop and mobile web applications
The market where we are moving is changing rapidly
We are not sure and not aware of all the features we will need in our applications

Possibility 1: Waterfall (or similar strong processes) - if we choose this path it means that we need to define all the features of our applications. Oops, we are still not sure how many applications we will have. Not to talk about features of those applications. Ok, but if we analyze problem carefully maybe we would be able to define all the features in all the applications. But the next problem is: market is changing rapidly. Are we sure we want to create detailed plans too far in the future knowing that market will change in the mean time. Decision: this is not the way we should go.

Possibility 2: Agile (Scrum) - I would say this is the direct hit. Agile approach is good to use if you have clear vision but not clear plan. If you have small (up to 9 persons) collocated team. If you requirements can change fast according to new discoveries and you need to adjust your goals according to market changes. Well if you check the list above agile is covering situation we have.

Decision: So actually it was not so hard to make the decision. We have decided to take agile approach implemented with Scrum.

Starting with the Startup

2010-01-26T00:03:00.001+01:00

Few months ago (October last year) I have joined the startup company. An what is the real luck I have joined them really at the beginning. So when I came on my first working day there was server room prepared, tables with computers and few developers that joined the company a month before me. The core business of the company is (will be) affiliate networks and mobile web applications. It is quite young and very innovating area of the current industry trends. If you don't believe me Google it :)

The great thing in joining startup right from the beginning is that you have big influence on the whole process. It is never boring and commonly it is taken care that the team is created from great people and developers. And of course it does not mean that big and small companies do not have great people and great developers.

So when the team is established, servers are prepared and there is rough idea what needs to be implemented you can jump right away into development. You install Eclipse, and start writing code. And doing it this way you will fail in a few months :)

First steps to be done are to establish some basic processes. As my part is mainly considered to development processes I will go through development processes and development environment setup.

Well our decisions I will explain in the coming posts.

New feature on spend day with kids

2010-01-04T01:03:00.003+01:00

For those who are using spend day with kids site or find it interesting or useful just to let you know that I have added some new features. Now it is possible to search for indoor and outdoor places to go with kids. So for example now it is possible to search for indoor places to go with kids in the range of 50 kms from London or outdoor things to do with kids in the range of 20 kms from New York.

As I have recently changed my job position my free time become really limited so it is really hard to work on pet projects. Even this small change would be almost impossible if there would not be Grails. Thanks to it it's quite easy to add new features. Actually implementation took only few hours and updating all over 1400 places to visit took much more time.

I hope that in the coming days I will be able to write some posts about my experience with Grails in the startup company. We had lot of interesting points that deserves blogs posts.

RSS Builder in Grails in a Few minutes

2009-10-27T22:42:00.003+01:00

As I planned to include RSS feeds into www.spenddaywithkids.com I needed possibility to create kind of RSS Builder. The good example of what I needed is IceRocket RSS Builder. So you are not generating RSS feeds directly from the data on your site but you are writing them manually. This way RSS feeds become kind of communication channel between the web site and users.

I would stay with IceRocket but I couldn’t find possibility to do even simple formatting for RSS items. So my thought was let see how it is complicated to do it in Grails. And it turned out that it takes only few minutes to get very similar functionality. So here is short example done almost step by step.

Note: As my site is currently running on Grails 1.0.3 maybe not everything will be compatible with 1.1 version out of the box.

So let go with implementation.

First create grails application and named it rssbuilder.

grails create-app rssbuilder

Then create two domain classes:

class RssChannel {
   String name
   String channelLink
   String description

   static constraints = {
       name(blank:false, nullable:false, unique:true)
       channelLink(blank:false, nullable:false, unique:false, url:true)
       description(blank:true, nullable:true, maxSize:30000)
   }
}


class RssItem {
   String title
   String itemLink
   String summary
   RssChannel rssChannel
   Date dateCreated
   Date lastUpdated   

   static constraints = {
       title(blank:false, nullable:false, unique:false)
       itemLink(blank:false, nullable:false, unique:false, url:true)
       summary(blank:false, nullable:false, unique:false, maxSize:50000)
       rssChannel(blank:false, nullable:false, unique:false)
   }
}

Ah, don’t forget to install two plugins: Feeds Plugin and RichUI plugin.

Now we can generate controllers and views for two domain classes:

grails generate-all RssChannel
grails generate-all RssItem

Well now if you start application you are able to specify RSS channel and items for RSS channel. To provide possibility to specify better formatting for RssItem we can reuse <richui:richTextEditor tag from the RichUI plugin. In the create and edit view of the RssItem change summary and bind it to the richTextEditor. More or less you should input tag with the following:

<richui:richTextEditor name="summary" value="${rssItem?.summary}" width="525" height="525" />

Now to generate RSS feed we can reuse functionality of the Feed plugin. So create FeedController class with command grails create-controller Feed.

The code of the feed controller should be:

    def rss = {
       if (!params.id) {
           render "missing id in params"
           return
       }

       RssChannel rssChannel = RssChannel.get(new Long(params.id))

       if(!rssChannel) {
           render "rss channel not found"
           return
       }


       render(feedType:"rss", feedVersion:"2.0") {
           title = rssChannel.name
           link = rssChannel.channelLink
           description = rssChannel.description
           RssItem.findAllByRssChannel(rssChannel, [sort:"dateCreated", order:"desc"]).each() { item ->
               entry(item.title) {
                   link=item.itemLink
                   item.summary
               }
           }
       }
   }

So now if you start application and create RSS channel and some items in that channel all you need to know is ID of that channel.

If the Id of the channel is e.g. 1 in the browser write http://localhost:8080/rssbuilder/feed/rss/1 and you will see your feed.

I believe this was really easy :)

As soon as I switch fun places to go with kids to the Grails 1.1 I will create plugin from this.

Grails scaffolding for domain classes in packages

2009-10-26T00:06:00.003+01:00

While working on one simple subproject for spend day with kids I got one interesting issue. I don't use scaffolding too often but this time I needed to get proof of concept. And I came to something where I am not sure if it is a bug or feature. And just to be clear this is happening with Grails version 1.0.3 and I am not sure if it is reproducible in later versions.

Note: Having packages for domain classes is highly advisable and you should always use packages for all domain classes.
So let get to the point. I have create following domain class (please notice that package is defined).

com.jan.rssbuilder.domain.RssChannel

And after that I have created RssChannelController this way:

package com.jan.rssbuilder.domain

class RssChannelController {
   def scaffold = true
}

After accessing this controller I got following exception:

java.lang.IllegalStateException: Scaffolder supports action [index] for controller [com.jan.rssbuilder.domain.RssChannelController] but getAction returned null!

After changing controller by specifying domain class everything worked fine:

package com.jan.rssbuilder.domain

class RssChannelController {
   def scaffold = com.jan.rssbuilder.domain.RssChannel
}

Tips for working with front-end in Grails

2009-10-18T22:10:00.002+02:00

I have implemented few web projects with Grails and some techniques while working with Grails front-end turned out to be better than other. When I didn’t follow them later on I usually had to refactor the code and did it the correct way.

If you are reading this blog you noticed that I write very often about developing front-end with Grails. The reason is not that I am the best in the front-end but the reason is that I am the worst in the front-end. I am back-end developer and what I was missing in the majority of web frameworks was impossibility to make front-end more modular. In Grails this is easily to achieve thanks to Grails templates and tags. And then you are almost to code in the normal java code.

But come back to tips.

Tip 1: Always create one gsp page per state of the result.

Tip 2: Use templates and tags to make your pages more modular.

Tip 3: When ever it gives sense send custom model classes to the gsp page (not the domain classes).

Well tips are nothing without some example. As an example I will take my latest project fun things to do with kids.

In the first installment home page had following responsibilities:

As a starting point for visitors
To display found places to go with kids
To inform user that the city provided cannot be uniquely identified (there is more than one city with provided name)
To inform user that no attractions were found around provided city

As you can see that is obvious break of the SRP (single responsibility principle). Because of too much responsibilities the model I was sending to the page was quite complex and the page contained number of if blocks. And you must admit that having if blocks in the html page is not the best practice. Another side effect was that page had about 300 lines that is simply too much.

So what I did? Well, of course I did some refactoring.

I have created one page per responsibility and depending on result controller decide which page to display and provides correct data model (is this maybe kind of strategy pattern?). This way it is much easier to understand what pages are doing. And now they are up to 30 lines long.

But if you check pages you can see they are quite similar:

To see home page navigate to: spend day with kids
To see page with results navigate to: things to do with kids in Nottingham
To see page where there are multiple cities e.g. search for Malinovo. Select Malinovo, Slovakia to see places to visit nearby my home :)
To see page where there are no results check e.g. for Belgrade.

If you checked all these pages you can notice that they are very similar but little bit different. So how do you solve similarities. Very easy. Use templates and tags.

And the last but not the least, it is obvious that the data models delivered to the pages can be quite different and even some cases need not to contain any domain classes.

So I hope that those tips will help you while working on your own grails projects.

New features on spend day with kids

2009-10-17T13:44:00.002+02:00

I have finally found some free time so I decided to implement some new features on spend day with kids.

So far all searches have been performed with the same default parameters. The defaults were distance is 100 kms and the sorting of attractions was by type.

Very soon after the launch of the site I got mail from Jeff where he proposed that results should be displayed in the order of proximity from the provided city. I liked the idea immediately and now this feature is supported.

So now you can provide city or even address and specify the distance of places to be searched and additionally to select ordering type. Possible ordering types are of course by distance and by city.

As you probably know spend day with kids site helps you find great family days out and is implemented with Grails. While developing this site, so far I didn't hit any special interesting features that could be worth for blogging about. But if you have any ideas just let me know

Hope to have more material for blogging

2009-10-10T01:01:00.002+02:00

I am aware that last few weeks I was quite lazy with blogging but as I was changing employer so lot of responsibilities have been in front of me. Of course, important part was knowledge transfer. From the October I am in my new company.

First I would like to thanks my previous company for having a chance to work on interesting and exciting projects.

In the new company I am coming to the position of Head of Software Development. It is a small start up company and we are working on the green field project. Yes, you see it right, its green field :)

As my future work will include some new technologies and different market I hope that I will have lot of materials for blogging. We will mainly work with affiliate networks and mobile web development. As this is quite new field for me I believe I will be able to share a lot of interesting discoveries.

As the field we will be working in is very dynamic we are of course on Scrum and agile software development. Dynamic projects and agile software development create great combination. I am very sure we will have lot of fun.

Software books reviews down - permanently (so far)

2009-10-07T22:13:00.002+02:00

It has been some time as I planned to take down software books reviews. Although I don't think that the idea was bad it takes time to make the site grow and support from the community was not so good.
As running site takes some money, lot of time and I have two other sites online too: grails tutorials and things to do with kids I have to choose which one to take down.
So my decision was to take down the software books reviews.

Now I want to be able to concentrate on my new work and to try to extend functionality of the spend day with kids site. I promised few months ago that I will open source grails tutorials and I still plan to do that. The problem is that I need few days of additional work before I open source it and I am not able to find those day.

So for all that were visiting software books reviews, sorry but I had to take it down.

Getting data into Grails tags and templates

2009-09-27T22:32:00.003+02:00

In the post describing how to create and use grails templates and tags I made short example that showed how gsp pages can be readable if you are using tags and templates. One of the questions asked in comments was how do I get data into tag and/or template. Instead writing answer as comment I decided to write the whole post.

Scoped variables
Common way to get data into tag and template is using Grails scoped variables like application, session, request. This means that both, tags and templates, have access to those variables so you can use them.

Templates
To send data into templates you can and should use standard approach with the grails model.

For example if you are rendering template from tag or from controller (or some groovy code) you should use construct like this one:

render(template:"/templates/common/messageBoxTemplate", model:[title:"hello world"])

If you are rendering template from gsp page you should use construct like this one (actually taken from grails documentation):

<g:render template="displaybook" model="['book':book,'author':author]" />

To be honest I try to avoid using <g:render... from gsp pages because if you are using tags it is easier to read the gsp page. Another advantage of using tags is that it is easier to refactor the gsp pages. So when you find yourself writing <g:render template.... in the gsp page, introduce grails tag for that.

Tags

The advantage of tags is that they have access to the GORM classes and you can inject any grails service into tag. So if you need to perform some calculation that needs to be displayed on the gsp page tag is the right place for that.

Another way to send data into grails is via attrs map. Each tag is specified in the file ending with TagLib and the format of the tag is:

def messageBox = {attrs, body ->
  out << render(template:"/templates/common/messageBoxTemplate", model:[title:attrs.title, body:body()])
}

So tag is closure with two variables: attrs and body. Using attrs you can access any custom data sent to the tag.

So how do we send that data?

When displaying tag from the gsp page you are using construct like this one:

<g:messageBox title="Register, it takes only seconds">

In this case the title is custom data sent to the tag.

To execute given tag from the controller or some other groovy code you can use construct like this one:

g.messageBox(title:"Register, it takes only seconds") {
  //body to be displayed
}

So for example, to display number of registered users on the grails and groovy tutorials page I am using direct access to database from the tag and then sending those data to the model. But I could also create e.g. application scoped variable for this and gain some performance. So currently the code in the tag looks like this:

def dataInfo = {attrs, body ->
   def postsCount = TutorialLink.count()
   def userCount = User.count()
   out << render(template:"/templates/common/statsTemplate", model:[userCount:userCount, postsCount:postsCount])
}

Agile, TDD and upfront desing

2009-08-17T00:37:00.001+02:00

As TDD and agile software development are emerging as more and more used technologies for software development lot of software developers are jumping into it without having real knowledge.

From my point of view one of the misconceptions about TDD and agile is that you don't need any design and architecture upfront. TDD with refactoring will give me the right architecture in all cases.

Although I am big fun of agile software development I don't believe this is idea of the agile. Agile is here to help develop better software for better customer satisfaction. But it in no cases claims that you should forget about big picture, about documentation and about having at least basic understanding of your system design.

From my point of view you need to do basic design at least at the high level. Then for important parts you need to go to lower levels (if really necessary). And then agile together with TDD will help you to really get it right. To separate concerns, to make separation between domain objects in different tiers and so on.

So as conclusion, agile does not mean no more thinking. Agile means think about the problem, do basic planning and then use TDD and other agile tools to get it right.

g:form, g:actionSubmit and Internet Explorer 8

2009-08-10T00:05:00.002+02:00

While working on my latest grails powered web site things to do with kids I have noticed that one form performs ok in Firefox and Chrome but not in Internet Explorer. If this would be case with grails tutorials I wouldn't care too much because majority of visitors have Firefox or Chrome. But my statistics for things to do with kids are showing that there is more visitors using IE than other browsers.

The problem was following. E.g. on the home page of things to do with kids you enter the city name and then press enter on your keyboard. In Firefox and Chrome you get the list of places to visit but in IE8 nothing happened.

But if you used tab to move focus on the Show Me button then everything worked also in IE.

The initial code looked like this:

<g:form controller="home" method="GET">
 <input name="locationName" class="span-10 last" />
 <g:actionSubmit value="Show me" action="placesAroundLocation" />
</g:form>

After some investigation I noticed that closure called from IE was actually index in the HomeController. So this means that in IE8 when enter is pressed while focus is in the input box default action of the controller is called while in Firefox and Chrome action of the button was called.

So to fix the problem with the IE I have slightly change the code. I added form default action so now it looks like this:

<g:form controller="home" action="placesAroundLocation" method="GET">
 <input name="locationName" class="span-10 last" />
 <g:actionSubmit value="Show me" action="placesAroundLocation" />
</g:form>

I didn't check behavior in other versions of IE but if you have similar problem this may help you.

You don't need session in Grails service

2009-07-28T00:11:00.002+02:00

From time to time there are questions or blog posts that explain how to obtain access to web session from the grails service or domain class. If you really need to access session from the service class e.g. this post from Robert can help you.

But before you start reusing session in your services or even domain classes be careful and think if you really want that. Service should be more or less simple Java class and when ever possible should not depend on special environment classes. And session is actually very special web application environment class.

So what to do if in the service you really need that value from the session? Well the answer is of course very simple. Send it as a method parameter. Or another way is Robert's approach to create service that will return that value from session and inject it into service that really needs that value.

This way your services will not depend on the web container context and you can easily port them to other environment.

UK included on spend day with kids

2009-07-21T00:36:00.002+02:00

As you may know few weeks ago I have launched spend day with kids web site. In the first release only USA was covered but yesterday I have finished entering attractions for UK.

So please feel invited to visit spenddaywithkids.com and search for ideal places to have a day full of fun with your kids.

Groovy and Grails help build apps faster

2009-07-17T23:01:00.004+02:00

Actually this is not my post but a very interesting article about productivity gained using Grails and Groovy.

Usually I am not posting links to other articles but my feeling is that this one deserves this. I didn't notice link to this articles on other grails/groovy related sites so I want to share it.

So navigate to "Groovy and Grails help build apps faster" to read the whole case.

Spend day with kids Grails web app launched

2009-07-05T16:07:00.004+02:00

I have launched new Grails powered web site www.spenddaywithkids.com.

Idea of the web site is to help you find interesting places where you can go with kids. There are places like zoos, water parks, theme parks....

Developing this application was interesting for me because this was for me the first time I used google maps in some of my application. Also new for me was geocoding but actually this turned out to be as easy as reuse formulas available online. Currently on USA is covered but Europe should come soon.

Currently I have three sites online: grails tutorials, software books reviews and spend day with kids.
For me it is just prove that development of web applications with Grails is easy and fun but know I will concentrate on extending my existing site and hope I will not get any fun idea soon :)

Let me know if you have some proposals for any of mentioned sites.

Book Review: Grails in Action

2009-06-30T22:50:00.003+02:00

I was lucky enough to get copy of the book Grails in Action from Manning. And of course I have promised to write review of the book.

My feelings about the book are somehow mixed. Basically book is divided into four parts:

Introducing Grails
Core Grails
Everyday Grails
Advanced Grails

The first two parts, Introducing Grails and Core Grails, are for more or less newcomers to the Grails so if you already have experience with Grails they are somehow boring. That wouldn't be a problem if my opinion wouldn't be that they are not written in an appropriate way for the Grails/Groovy beginners. My feeling is that beginners will get confused as the authors jump too much directly into action. So my advice for the beginners is to read e.g. Getting Started with Grails and then come back to the book Grails in Action.

But even if you already have Grails experience don't just skip over the first two parts, because after having some Grails foundation the first two parts become very useful and very easy understandable. Even for me (and I have some experience with Grails) there were useful information and discoveries.

Very good approach in this two parts from the authors is that they have devoted lot of energy to explain how to test Grails application. This is something I should definitely start to do on my own projects :)

The real fun comes with the second two parts - Everyday Grails and Advanced Grails. I have really enjoyed reading chapters from those parts. They are very nice and are really covering lot of skills you will need during real Grails projects.

In the third part authors are explaining how not to reinvent wheel by using number of available plugins. They show you how to fast and reliably put together advance features by reusing already existing functionality. I liked this approach and using it myself a lot.
There are also chapters devoted to workflows, exposing interface to outside world and using messaging.

After finishing third part you have really solid foundation to do some serious Grails development.

The fourth part is really advanced although I would include basic transactional behavior into at least third part of the book as this is probably more everyday grails than advanced grails. The fourth part will explain advance GORM related features, advance usage of spring and something you will for sure meet in the corporate environment - build and deploy process.

Conclusion
At the end I was very happy that I got a chance to read this book. This book will lead you from the beggining to the really advanced features of the Grails. If you are developing with Grails I am very sure you will have this book near you.
If you are just starting with Grails I would recommend, first read something simplier and then come back to this book. I am sure you will enjoy reading it.

And if you want to buy the book you can do it here :)

Book Review: Becoming Agile

2009-06-14T15:00:00.005+02:00

When I started to think that majority of agile books are somehow breaking DRY (don't repeat yourself) principle I was lucky enough to get a copy of the book Becoming Agile: ...in an imperfect world.

Introduction

What I liked the most in this book is that it is completely oriented to the real world. Therefore it will not try to teach you any of the existing agile frameworks but will help you to make your company (team) agile taking into account all constraints surrounding you. Book is oriented around agile principles and authors consider you environment agile if you are following agile manifesto principles.
Another value of the book is that agile introduction is taken from the complete beginning. From company readiness assessment up to the project deployment and spreading your agile process through out the whole company. The whole project lifecycle is covered. From the vision, through adapting idea to the deployment. This is something that I was missing the most in lot of books about agile.

Book follows imaginary company Acme media and its move toward more agile environment.
Getting started chapter will explain how to check your company readiness to adopt agile processes, ensure buy-in and inject agility into your existing process. When you have selected pilot project you are moving forward.

Kicking off chapter explains how to make feasibility study and how to decide if you should continue or stop with the project.

If you decided to continue with the project Populating the product backlog chapter will show how to create product backlog, what means "just enough" for a feature card and how to estimate and prioritize the product backlog.

Enough information for scheduling creates release plan and explains in how much details you should plan your iterations. And don't forget that having plan is not enough. What you need is planning because during the project your plan will change for sure.

When you have release and iteration plan you can move to the Building the product chapter. You will see how to welcome change, how to apply agile principles into development and how to ensure that you have working software at the end of iteration.

Embracing change chapter cope with adapting to change requirements. It explains common reasons for requirement changes and how to adapt to them. Next parts of this chapter will show you how to plan deploying and how to improve your process using retrospective.

If your pilot project was successful you will want to spread the agile process throughout the company. The Moving forward chapter will help you with this process.

Rest of the book explains the whole process from two different points of view. In one chapter the overall diagram of the project lifecycle is displayed and shortly explained while another chapter contains text description of the overall process.

Conclusion
Although at the beginning I was not sure if I want to read this book I must admit I have really enjoyed reading the book. I believe that this book must be mandatory read for anyone who want to become member of agile community.
The only downside of the book is that it covers really wide area (complete project lifecycle) and thus after reading this book you will need to read other books to improve your knowledge about e.g. estimating, testing, writing good user stories...

I really recommend this book to everyone that already are or want to enter the agile world.