Grails, listDistinct and pagination

A beautiful red box in Grails documentation says that pagination doesn't work when using listDistinct() method. One should rather use HQL for pagination. Well, I have wrote really huge query using createCriteria().listDistinct() and the citation below caused me almost heart attack. 

The listDistinct() method does not work well with the pagination options maxResult and firstResult. If you need distinct results with pagination, we currently recommend that you use HQL. You can find out more information from this blog post.

I could rewrite it to HQL but the query I wrote is really heart of the system. So, it could take me few weeks to rewrite it and I don't have time and energy to do it. I am willing to scarify a bit from performance of the system. 

I have discovered the solution described below. It is not the best one from performance point of view, BUT it works and it is not causing high consumption of memory (there are thousands of records in DB nowadays and it works well). 

class ResponseService {

  def load( def params ) {

    def idList =  Response.createCriteria().list {
      projections { distinct ( "id" ) }
      // here are your restrictions...
      // e.g. eq( 'name', parameter.name )
    }
    if( idList ) { 
      // define range startIndex..usedMax
      int idListSize = idList.size()
      int usedMax = params.startIndex + params.max - 1
      def usedIds
      if( usedMax >= idListSize ) {
        usedMax = idListSize
      }
      // select only IDs we want to fetch 
      usedIds = idList[ params.startIndex..usedMax ]
      // fetch all Responses based on selected IDs
      def results =  Response.getAll( usedIds )
      return results
    }

  }

}
These resources inspired this solution: 

• http://floledermann.blogspot.com/2007/10/solving-hibernate-criterias-distinct.html
• http://stackoverflow.com/questions/3905476/gorm-createcriteria-and-list-do-not-return-the-same-results-what-can-i-do  

TextLab for Mac

Ultimate application to validate, clean and format JSON, XML, SQL, HTML.

How to interview Java developers

Three years of interviewing Java developers and I am about to write it down... here it goes, here is my way of doing interviews.

Step 0

Make a little preparation. I usually create a template for the interview - so my interview has desired meaning and all my questions are answered. Here is an example of my template: 

Past: [what he has done so far?]
Present: [what is he doing nowadays?]
Future: [plans for future?]
Rating: [areas like OOP, Java are rated, use your own scale]
Salary: [salary expectations]
Start date: [possible start date given by the applicant]
Notes: [something to remember the person]

I store all of these notes in my personal wiki provided by my company. So I can go back to my notes whenever I need. 

Step 1

Introduction is fine as the first step. As interviewer you get info about the applicant. The applicant should know what is your role in the hiring process (are you manger, java developer, architect...). But, don't waste time with this that much, there are more important things to discuss. 

Step 2

I usually ask developers questions related to these topics: OOP, Design paterns, Java, SCM and frameworks. But how to find what to ask first or where to put more focus on? I usually ask for the biggest project the applicant has participated. If there is some, then I ask how he did it? What was at the beginning of development - has he started coding immediately or is he used to do some design work? What about requirements and some specification? What about GUI protype? Is he using SCM? What design patterns were used and why? What frameworks does he know? Does he know the Java language? Here are few question (it might be beneficial): 

1. What is an interface and you can use it during coding?
2. Have you used an interface? If yes, how?
3. What is the difference between List and Set collection classes?
4. Do you draw class diagrams before you start coding? If yes, give him an example - so he is forced to draw UML class diagram. After he is done, give him Eclipse or Netbeans and ask him for implementation of his diagram.
5. Do you use JUnit? What about mocking?
6. Do you prefare work on back-end or front-end? 
7. What design patterns have you used and how?

The answers for these questions are signs which will tell you where to dig in. If the application is not using design patterns, then you should be interested if he knows how to implement class diagrams and if he knows something about OOP. On the other hand, if the applicant knows nothing about SCM - then you can just rate it as 0 and continue with other areas. 

By the way, if the application's answers are satisfactory and I like the project, I ask for the link where I could download or use it. 

Step 3

At this stage, you should have enough info to ask practical question. An example: let's say that the applicant told you that he has used design patterns in last project. Let's ask him "What design patterns have you used?". The answer might be "Composite and Singleton". "Hurray! I will let him to analyse a problem with tree structure and if that goes well, he could code it. If not I will let him implement the singleton pattern!", scream your brain with delight. 

Let your applicant to choose programming IDE (usually Eclipse or Netbeans). So he is not limited by a tool and he can be as efficient as possible. 

If your participant is not able to analyse and code all that what you gave him... let him to code some loop and sum some values from a field. You can also try to force him to write a unit test. 

Well, this is the most interesting part of interview. You can see your applicant solving issues and explaining stuff under stress. There is nothing better what could help you to see what kind of person the application is and how he is going to behave in your team or company. So, keep your eyes and mind open! 

Step 4

Ask for expected salary and start date (at least these two are quite mandatory). You can also ask what is he doing in his free time. If he is playing chess and practising fight art, I am pretty sure you will remember him.

Tips

Don't forget that the applicant is nervous. So ask the questions properly and rather slowly.

Don't help him too much. He should solve the tasks you are giving to him. Your task is to watch and analyse how he is proceeding. 

Give the same easy questions to junior and senior. So you are able to compare applicants in long term perspective. I like when seniors have to answer simple questions about programming - so I can see how good they are at explaining things.

An example of my notes:   

Past: high school, worked also for company XYZ as Java developer
Present: looking for job
Future: wants to be architect
Rating: OOP: 2, UML: 1,5, Coding in IDE: 2, Java: 3, Frameworks: Hibernate, Spring
Salary: 10 000$
Start date: 24.12.2012
Notes: plays guitar and online games, practising box in free time

TextLab for Mac

Ultimate application to validate, clean and format JSON, XML, SQL, HTML.

Flavour of blaming culture

Running and enjoying blaming culture in your company? It seems that blaming is easiest and most useless thing one could do while working on a project. 

What one might achieve with that kind of culture? It has got quite many "benefits" actually. Let's have a look at short example.

Johny has started to work as project manager on a brand new project. Scope of the project was to develop a software for a big shop. As we all know, there are always issues to be solved on a project and Johny has been working on them day by day. Time has passed and unfortunately, project deadline has not been met. "What a brilliant idea to find a victim" thought the project owner. It was enough to have just one meeting between project owner and sales guy to agree that the reason behind this all (delay, angry customer...) is Johny. Johny has been fired from the project and new, better and experienced project manager has been employed.  

One might argue "and what about follow-up discussions, steering groups, continuous feedbacks... it could help to solve Johny's problem", well, it could help but it didn't happened in the example. And maybe something even more, that is not something what these blamers are looking for. They need to find a person which is behind all the problems. Reasons, lessons learned and root causes are not needed actually.

So what do they get with this approach?

• New project manager gets
• Hero status
• Inheritance of delayed project
• Possibility and energy to make changes, because of his "fresh blood"
• Project owner gets
• Excuse why project is loosing money, because Johny did it wrong... of course. 
• Solution for the upper management "Johny project manager is fired, don't worry we have got a new one! So everything is going to be fine."
• Sales guys gets
• Reason why everything went wrong (again Johny the project manager). 
• Improvement for customer "The new project manger is better. You might expect pure gold since now." 
• Johny (the old project manager) gets
• Frustration 
• No feedback, thus no improvement
• Great experience with blaming culture 

How could we work in better way? So we all are really enjoying work with others in our company? 

1. Don't blame others! It really doesn't help. Take constructive approach in action.
• If you blame, you look like little child screaming on playground at your mom "heee has took me my paaail, tell him to returnt it back to meeee". 
• Yes, blaming is awkward. 
2. Give feedback
1. Say honestly what is wrong, what is bothering you and give others feedback in this simple way. 
2. You should do periodical feedback surveys - so you recieve feedback on a person not by supervisor, but by his/her colleagues and subcordinates. 
3. If you are not sure how to give a feedback, use the google. 
3. Believe that people want to enjoy work and beneficial collaboration with others.