Thursday, May 29, 2008

Struts, Velocity and flexible Content Type

Using Struts2 I wanted to have an output generated by Velocity with text/xml content type. I struggled couple of minutes to figure out how to change it. I used the force and read the source (org.apache.struts2.dispatcher.VelocityResult) - what a surprise, what a flexibility ;)

protected String getContentType(String templateLocation) {
return "text/html";
}
My solution to this is simple (just copy-paste):

public class FlexibleVelocityResult extends VelocityResult {

private String contentType = "text/html";

public void setContentType(String contentType) {
this.contentType = contentType;
}

protected String getContentType(String templateLocation) {
return contentType;
}
}
It also requires slight change (addition) in your struts.xml file:

<result-types>
<result-type
name="flexVelocity"
default="true"
class="com.bielu.struts2.dispatcher.FlexibleVelocityResult"/>
</result-types>
From now on when you want to dispatch your action using new Velocity dispatcher you have to do sth like this:

<result name="success" type="flexVelocity">
<param name="location">velocity/rss/rss.vm</param>
<param name="contentType">text/xml</param>
</result>

Voila!

Tuesday, May 27, 2008

Couple of book reviews

Last few months have been very busy for me - at work as well as at home. I've read many interesting books (still more to come) and I wanted to write very short and shallow review for each of them. Here we go:


Random pick from the library. Not quite memorable book but still contains some wise pieces of advice how to be leader and enable people to be innovative (appropriate offices, relevant people, good competitive atmosphere, wise budgeting, etc.). Nothing new, nothing to be discovered but put in a very tangible way. Writer's style is very nice and easy and the book can be "swallowed" in couple of hours.



Very very short yet constructive book with many pieces of advice regarding leadership. If you are (or want to be) the leader you should definitely read this small guide and take to heart most of the hints.
The most valuable for me was the part saying that leader works for the team, not the opposite. Leader is the team's servant! And leader should lead people not manage them (i.e. managers usually show the way to achieve the goal, they drive people - leaders don't) - difference between manager and leader.



Reading this book I was feeling like this guy:
Not because of the contents but layout. Yes - Microsoft is not even able to publish correctly a book. I have an excellent sight, I don't use glasses (although I read a lot), but I was hardly able to read this book because the letters are too small. Generally book is also too wide i.e. there are too many words in one row. You may think that this is unimportant? Try to read this book then!
About the contents. Author tries to answer the question "How to introduce and implement Scrum in the enterprise?". He gives a lot of examples which are very interesting and save the book. In general the book is boring and over intellectualized (IMHO). Yet I think that if you work in big enterprise and would like to implement Scrum you should read this position.



Absolutely brilliant book! If you don't know what Scrum is and would like to get to know it quickly, this book is for you. Great style, a lot of pictures ;) easy to understand with real-life examples. This book also gives you insight into doing Scrum with XP - it really works. This book rocks! Couple of hours reading, btw.



I have to read this book again because during many of its pages I was sleeping. It is somewhat boring, however it contains invaluable and timeless knowledge on how to keep your team/company productive and what can limit the team's efficiency. It focuses many aspects of development team's life and gives a lot of real-life examples. This book made me thinking for a long time.



Another brilliant book on leadership and team management subject. Author gives us excellent book in which he tells a story (it is not a user's guide book). This book is letters in 90%. While reading it you identify with characters given in this book which makes it much easier to understand and put oneself into presented problematic situation - this was the intention of the author, of course. This book is really really great and everyone who is in position of power (or wants to be :) has to read it. It is probably classic management book by now.



Boring, boring, boring (2nd edition)! Only examples save this book. I'm really disappointed with this book. It is a classic one! If I didn't know what was XP about it would be hard to learn about it from this book.
Besides that I really love the last chapter (or last but one) when Kent describes how they "invented"/discovered XP.



The best book I've read recently. More so, Mike Cohn is my favorite author after reading this book and the next one (see below). If you want to have productive development team that collect requirements in an effective way, write User Stories. If you want to learn how to write User Stories - buy this book! The style is genial, the contents is awesome and the examples (including case study) are just amazingly easy to implement in practice. After reading this book you can immediately start implementing Scrum and writing excellent User Stories.



A bit over intellectualized book. Mike Cohn put a lot of effort into making this book credible, thus you can find many references to scientific works on estimating and planning subjects. Sometimes I was thinking I'm reading a scientific book which was hard ;) but the author uses brilliant examples that keep you focused on reading. Again the case study is just genial - you read, you think and you can implement it in your project. This is definitely the book you should at least read.

Monday, May 19, 2008

Quality doesn't suck

I disagree with this post written by my friend regarding quality. This is my response - maybe not direct and not to all objections but still valuable ;)

- Quality? - all right, but if time permits...

How often do you hear that? If you hear that often it means that probably your product's quality sucks.

Suppose that your team has to implement some stories in the fixed period of time (let's also suppose you are not using Scrum and you are not iteration-oriented). Then the customer pushes the higher management to move the deadline - of course for the earlier date. Team lead will not throw away any stories (what she should do) because the higher management would fire her. What she will do? Tell the developers to implement the same amount of features in shorter time. Developers subsequently will also have to sacrifice something - most probably they will not sacrifice their family life and free weekends. They will sacrifice QUALITY.

According to "Peopleware" book your product requires much higher quality than your customers need. Why? Because Quality, far beyond that required by the end user, is a means to higher productivity.

Reading the same book further there is an excellent example. I will try to rephrase it here. If you think of high quality (either company, nation, culture, etc.), what pops to your mind in the first place? For me it would be Japan. Again, if you think of high productivity (either company, nation, culture, etc.), what pops to your mind in the first place? Japan? This phenomenon can be explained this way:

The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.

But this post complains that there is no need to think on the design, architecture, etc. for too long - just do it. Yes - you're right. That's the XP idea of simplicity - design what you need today - tomorrow you will refactor your code, design and architecture, but if only you will need to do it.

That's the quality for me. More so if you utilize Scrum framework and follow XP guidelines you incorporate relevant (i.e. high) quality into your estimates. And there is no way higher management could impose the team to deliver the product faster with the same set of features. Your team velocity does not lie - you will not deliver more user stories because the number of story points is too big. The team can deliver the product faster but they will implement less features.

Agile development somehow imposes on you high quality (but if you are agile it doesn't automagically ensure that your product's quality is high). More so agile teams show to be more productive than "waterfall-like" ones. And here we meet high quality with high productivity. What you think about this version of the original quotation?

The trade-off between price and quality does not exist in Agile Development. Rather, the idea that high quality brings on cost reduction is widely accepted.

Wednesday, May 14, 2008

Who am I?

If you want to check what is the current method name in Java you have two ugly possibilities to do it:

package com.bielu;

public class MethodName {

public String methodOne() {
return new Exception().getStackTrace()[0].toString();
}

public String methodTwo() {
return Thread.currentThread().getStackTrace()[2].toString();
}

public static void main(String[] args) {
MethodName name = new MethodName();

long start = System.currentTimeMillis();
for (int i = 0; i < 100000; i++) {
name.methodOne();
}
System.out.printf("First method - new Exception() - in %d millis\n",
System.currentTimeMillis() - start);

start = System.currentTimeMillis();
for (int i = 0; i < 100000; i++) {
name.methodTwo();
}

System.out.printf("Second method - Thread.currentThread() - in %d millis\n",
System.currentTimeMillis() - start);
}
}

Results from my machine:

First method - new Exception() - in 8141 millis
Second method - Thread.currentThread() - in 80561 millis


As you can see the second method is ten times slower.

In any case I do not recommend using either of the shown techniques in the production code. You should consider using AspectJ in a pure form (don't like it) or Spring Framework AOP capabilities (most preferable way).

Anyway - why should you want to know where you are? :-)