Wicket - Checking out

Have been trying out Wicket lately . Had heard a lot about it and hence thought of giving a shot at it. I have always been doing web development in java world and having known Struts, JSP for almost all the time Wicket was sort of a shock initially (never have done any serious swing programming). All UI programming done in java with some html markup. I have done some JSF but this is remarkably different. But soon, I got over it... I can feel OO's power throbbing inside it (since it is mostly java code and it is component oriented) but I think that unless I do some good amount of development and add features to an application, I won't be able to make out whether there is true power in it... Ajax without javascript is something to look out for... So if you are javascript novice (which I was sometime back, now I know a bit of it - these javascript libraries help a lot) this is something good. Getting a good feeling compared to JSF at the least (though component libraries in JSF are much more). I will keep posting

Improving website's responsiveness - follow up

Have been working more on these lines. I think the better place to go to get tips on the above topic is in YUI performance links. YSlow is a good starting point. There are a plethora of tools out there...
Starting from AOL pagetest, YSlow, Firebug. Yahoo's performance related pages talk about lot of browser behavior and also tricks to get the best out of it... I think folks should start looking there. And this is only if you are serious about improving your site's performance.

note: Have been out for some time. Lots of work... Now things should get back in track

Improving website's responsiveness - some learnings

For the past few days, we have been working on improving the performance of some of the new features in our product/web application. Some of them have really worked for us. Thought of sharing them:

1. Look for the optimum amount of data to be shown to the user: This is not a technical tip but has to do more with sensitivity to the usage of your site/application. There is a need to get only so much data which the user can see with convenience. For example in our application, we were showing around 25 rows on search results and the vertical scroll bar became pretty big. The side-menu occupied very small part of the browser real-estate. We then changed it to 10 rows and found the page to be more balanced. And that also reduced the amount of data we send across to the browser which increased responsiveness quite a bit. So do look to resize your pages as needed. Don't keep them too big.
2. Gzipping/Compressing your response: If you are sending a huge amount of data in your response consider gzipping the content. This reduces the time taken to push the content across to the browser and for internet sites this could do a lot of good to the responsiveness. When doing this keep two things in mind. One: You would be able to use this only if the target browser can handle gzipped content (most browsers do that now a days). Two: Gzipping needs horse (read CPU) power and you better have what is required.
3. Sourcing images/static content using hostname aliases: This is more of working around the limitation of the browser. The browser typically cannot make more than two parallel requests for such components with the same hostname. Hence if you create aliases to your host, that will increase the number of parallel requests the browser can make to get these components. Simple! Not so fast. Keep in mind that, this increases the number of DNS lookups and that adds to the overhead. So strike a balance. We plan to have 4 aliases in our application.
4. Bundling and Minifying JS and CSS files: You know that for included JS and CSS files, the browser makes separate requests. Again two things here: Bundling these files into one file reduces the number of requests - a good thing. But keep in mind that you should not lose out on the caching of the browser of these files. So if a set of JS (or CSS) files are common to many pages, bundle them separately and include it in your pages instead of putting them into the page specific bundles. The second thing is to minify or compress these files. The reason is same as compressing the response. JSMin is quite famous for JavaScript compression. YUI has a compressor which is based on Rhino and it has support both JS and CSS compression. We are planning to use this as we found better compression with this.
5. Use latest js libraries: If you are using JavaScript libraries, check out whether you are using the latest version. In most cases the latest version would be more performant (there could be exceptions), so would be good idea to move to the latest version. We are using jQuery and are planning to migrate from 1.2.1 to 1.2.3 version.
6. Remove unnecessary inline js and css: It is always a good idea to externalize the inline js and css into linked js and css files. The js and css files are cached by the browser. This reduces the amount of markup sent across in the response each time.
7. Use css instead of images for your page styling (like curves): Earlier whenever we wanted different kinds of styling like curves and dots, we used images. Now these can be done by css and rightly so. Using images for these effects will increase the number of requests for painting the page and hence reduce responsiveness. Many js libraries provide plug-ins for these nowadays.
8. Using http 'if-modified' in AJAX calls: AJAX is a great technology (that is cliche and probably everybody knows it, but still could not resist it). It has helped all of us to make very responsive applications (ok I am sorry). We can further improve this if we introduce the 'if-modified' http header in these calls. This ensures that if the data is already present in the client side (may be a JavaScript variable), the same is not sent across again unless it has changed. This is just extending the behavior of browsers to images, js files etc to ajax calls. Most JS libraries make this pretty easy.
9. Optmize JavaScript: In today's web applications, processing using JavaScript is pretty high. This is the same with our application as well. It is a good idea to optimize JavaScript towards this. Using a good js library like jquery solves most of the problems. At the same time, optimization must be kept in mind for other javascript code in our application. And that too across browsers

The above are the techniques we have tried/ are trying in our application. These have helped us in making our application much more responsive. Apart from these techniques, I found the below tools very handy:

• Firebug: This is one great tool that can be used with Firefox. I can't imagine JavaScript debugging without this. It is very powerful with css and html as well. It is almost a developer's dream come true. It is shame that it does not exist for IE (where it would have been even more useful).
• Fidder/Charles: Both are http debugging proxies. Allows you to analyze request and responses including time, content.

There are a lot more features in these tools and they are worth investigating.

On the whole, we all wish to make our applications very responsive and with least amount of sweat. And these techniques and tools can surely help us.

Javascript: Some good links I found on javascript tips and performance

Was involved in the past few days on javascript performance optimization. Found some good links on the same.
http://aymanh.com/9-javascript-tips-you-may-not-know - Best thing I liked in this is some good explanation of null and undefined in javascript. Helped me understand an issue.

http://www.bloggingdeveloper.com/post/7-Easy-to-Apply-Tips-to-Improve-Your-Web-Site-Performance.aspx - This one talks about the loading images form multiple domains as one of the points - very interested and something which we are planning to implement

Javascript Libraries - jquery

I had almost never coded in Javascript before a couple of weeks. For my project we wanted to do some functionality on the client side and I needed to work on javascript. And I did not use much of direct javascript. I used a library called jquery. jquery has been around for more than two years now. There are other javascript libraries as well but I have exposure to none other right now.

• What jquery claims to be different is the way it uses CSS or Xpath selectors to work with the dom (both html and xml). Comes out pretty short and neat. I really liked that part. made things easy for me in many ways.
• It has support for ajax as well. I used that as well. Can work with html, xml and json output all of which can be manipulated in jquery/javascript pretty nicely.
• It has support for some ui components like sliders, capability to create curve edges to tables etc. I did not use directly. Other guys in the project have used.
• Also there are a bunch of plug-ins which are quite useful.

All in all it was a learning experience. And I did not think before that javascript coding could be this much fun… I still have only touched the tip of the ice-berg, so the opinion can change :)

Another great concept I got familiar with was closures. I have sort of got a hang of it. but not completely yet.

Mean to try GWT sometime as well.

JSF pitfalls article I read

I found a good article on JSF Anti-Patterns & Pitfalls on theserverside. This covers a good set of JSF pitfalls. I am summarizing them here
1. absence of constructor based dependency injection - The developer has to sacrifice some of the OO flexibility - Use spring instead
2. no provision to pass parameters to the managed bean methods - Developer use various hacks like implementing Map
3. dual call to phaselisteners - this is something which i did not realize - looks more like a bug to me :)
4. huge amount of navigation related xml - this is something we faced - Usage of * can help. This is some trick I probably missed in my project
5. using xml causing runtime exception - this is quite true; may be tools could help - author recommends annotation libraries from Shale and Seam
6. thread safety - some important info in this especially about custom converters and validators. something that should be kept in mind
7. creating component renderer tags with behavior - something to be avoided
8. exposing the entire object hierarchy in el - not sure about this one; done this quite a lot. seems more natural
9. coding to the implementation instead of interface - this is something which we must not do at all
10. not doing view state encryption on client side - good point in terms of security
11. jsf code that is bound to the servlet api - something which i have done a lot I think - this makes it non compatible to portlets - workaround mentioned

That is what is covered. The other issues I faced are already covered in a previous post. Folks who use JSF please keep these in mind

Dev Camp at Bangalore Thoughtworks

Just yesterday, I attended devcamp at Bangalore ThoughtWorks . It was first of the kind for me (I have not attended the bar camps before) and the experience was new. The camp followed the true spirit of unconference and I was immediately hooked to it. Jumping out of talks in between to check out others was something I did all the time. Another thing I learned about unconferences was that you go there to get a flavor of different stuff and may be contribute some very specific or very generic stuff. Details have no place there (at least that has been my first impression).

Some themes which I found interesting were Ruby and RoR, Semantic Web (which I could not attend much even going by my camp standards), Mashups and RIA frameworks. There were standalone sessions on Eclipse Plug-in Development, Android (missed that one) and others. There was one 'any language any website' session which was interesting. Another real good session on 'Product design and development' - really got to know some good concepts. The lightning talks were quite good - the shortness helps mitigating boredom and fostering breadth.

I will probably post later on specific topics I attended here.

Hearing Martin talk was another wish come true.

Overall had a good time and a great experience.

Online Community - Starting one

One day we folks sat over a cup of coffee and discussed… discussed on lot of things… software development and technology was a big piece in that. It was fun and we all loved it and learned from it… not something we can make happen all times…
We also discussed on how much the web has moved on… really lots happening out here and we are quite behind the scene…
Then it flashed… we wanted to discuss at any time and the web had the answer…. A wiki has come forth... Iflockt
Starting off with bunch of friends. Let us see what comes up.

Media Personalization

Just came across this in Business Line - "the media personalization platform" (check out news item). This first app being http://www.buzzmygoat.com/: videos that can be personalized and used in your mobiles and pages etc. Is there something in this for Youtube to add to itself?

BRMS (Rule Engine) vs OO Paradigm

I have not seen much on this topic. Folks probably don't think they are getting into each others way. In the traditional OO world, don't we encapsulate the rules within the corresponding object itself, so that it is truly abstracted from the rest of the world. Do rule engines violate that in anyway. May be or may be not. I think may be not. But some thought on that might bring more clarity on how we should use rule engines correctly.