5 GWT – Common Problems with Solutions

Wednesday, October 26, 2011 Labels: , , , , ,
I'll start by saying that I'm not a massive GWT fan, but yes there are many who are. That’s why I come up with some solutions to some common problems associated with GWT.

Problem: Long compile times, as your project grows so does the amount of time it takes to compile it. I've heard of reports of 20 minute compiles, but mine are on average about 1 minute.

Solution: Split your code into separate modules, and tell ant to only build it when it's changed. Also while developing, you can massively speed up compile times by only building for one browser. You can do this by putting this into your .gwt.xml file:

<set-property name="user.agent" value="gecko1_8" />

Where gecko1_8 is Firefox 2+, ie6 is IE, etc.

Problem: Hosted mode is very slow (on OS X at least) and does not come close to matching the 'live' changes you get when you edit things like JSPs or Rails pages and hit refresh in your browser.

Solution: You can give the hosted mode more memory (I generally got for 512M) but it's still slow, I've found once you get good enough with GWT you stop using this. You make a large chunk of changes, then compile for just one browser (generally 20s worth of compile) and then just hit refresh in your browser.

Update: With GWT 2.0+ this is no longer an issue, because you use the new 'Development Mode'. It basically means you can run code directly in your browser of choice, so no loss of speed, plus you can firebug/inspect it, etc.

http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM

Problem: GWT code is java, and has a different mentality to laying out a HTML page, which makes taking a HTML design and turning it into GWT harder

Solution: Again you get used to this, but unfortunately converting a HTML design to a GWT design is always going to be slower than doing something like converting a HTML design to a JSP page.

Problem: GWT takes a bit of getting your head around, and is not yet mainstream. Meaning that most developers that join your team or maintain your code will have to learn it from scratch

Solution: It remains to be seen if GWT will take off, but if you're a company in control of who you hire, then you can always choose people that either know GWT or want to learn it.

Problem: GWT is a sledgehammer compared to something like jquery or just plain javascript. It takes a lot more setup to get it happening than just including a JS file.

Solution: Use libraries like jquery for smaller, simple tasks that are suited to those. Use GWT when you want to build something truly complex in AJAX, or where you need to pass your data back and forth via the RPC mechanism.

Problem: Sometimes in order to populate your GWT page, you need to make a server call when the page first loads. It can be annoying for the user to sit there and watch a loading symbol while you fetch the data you need.

Solution: In the case of a JSP page, your page was already rendered by the server before becoming HTML, so you can actually make all your GWT calls then, and pre-load them onto the page, for an instant load. See here for details:

Read more

0 Best vs Worse Clients

Monday, July 18, 2011 Labels:
I have been working with different clients for different projects. I have experienced different clients from good to best, bad to worst.

Best Client:

  • They know what they want
  • After initial requirements they continue with the development plan.
  • Pay timely for what is developed (incremental builds – mostly weakly)
  • They negotiate the time/cost/issues as development process proceeds and new requirements jump in our out and keen to sort out differences and move forward.
  • They understand the professional and healthy relationship with software house and developers is in their own interest and vice-versa.

Worse Clients:

  • They never know what they want.
  • Even provided by a development plan, they keep on changing it.
  • After locking down the requirements/costs, they still don’t accept what is agreed.
  • When the moment of payment comes, they start miss-behaving.
  • They lie a lot (It’s always best to avoid voice-calls with them) and save the chat/email histories for such clients.
  • They try to force new requirements in locked requirements and on the same cost.
  • They are never happy, no matter what you do.
  • They are wanna be who saw a movie or heard a success story and say to software house that they want an exact-copy of that web-site just in 2000$.
  • They fraud and miss-guide their investors (if any)

Point of discussion is, there are good and bad people there, you have to deal with them all, but software-houses must have some rules of engagement.
Read more

0 Why one should follow MVC along with Cohesiveness

Thursday, April 28, 2011 Labels: , , ,
In web development, MVC (Model View Controller) design pattern is considered most basic infrastructure for a web project. It does the separation of UI (user interface / presentation layer) from Business intelligence (data processing) and flow of control between User Interfaces and data processing layer. This way one can focus on only one layer and extends/customize it to its limit.

The web projects following this approach are easy to maintain, debug, enhance and test and they are quite extendable. Not only this, one can use different technology for each layer.

The popular MVC framework for Java developers are

  1. Spring MVC
  2. Struts
  3. Stripes
I recommend at least java developers to follow one of MVC framework. It would be highly beneficial for them.
I recently went through a project which was built using IBatis, Strips, JDBC and JQuery. As it was developed by an offshore team hired by a company and running under its CTO. It had designed all the design for this project

 I found following drawbacks in their project

1. Not using MVC strictly

2. Naming Convention 

3. Putting all the code (data processing, JQuery, Presentation layout in mostly in per JSP bases. Because of that code was redundant.

4. Project was also following Strips layout structure as Tiles do in struts, but its use was very limited.

5. Debugging code was awful because mostly code was writing in JSPs, sometimes control moves directly from one JSP to other to get the required results and sometimes some service come in to play.

In short, it was all mess. I wrote above paragraph to identify the areas where one should focus and try to avoid them in any case.

Enough talk on MVC, what if one doesn't have this pleasure, still one can separate components/modules in different files/layers.

Yes, they’ll have to get the same privileges from themselves.

So they all have to do is to get these privileges.

How?

Well I tell you. It might help you in your future projects.

Four functional components
1. Design a web-site with four functional components (Header, Menu, Footer, and Body) into different files (Presentation Layer)

Common file for CSS and JavaScript
2. Have common/separate file/files for CSS and JavaScript/Ajax (never put them in html)

Service layer
3. Data Processing/Business logic, try to put them in to separate file too and get the results from there. These files (weather you are using PHP, JSP) will behave like a service layer (where you business logic resides)

SQL Query File
4. Use common file for SQL queries to be used in your service classes.

Database Connection
5. Put database connection pooling code in one file and use it as you needed in your service.

If you follow above five practices, you will achieve cohesiveness and MVC like behavior and it will help you on the longer run.

This is all from me for now. Give your comment and feedback and your thoughts on it.
Read more
 
Waqas Sadiq © 2014