We put our GWT-based job site (http://www.careercommons.com) in
production on Monday. This is a summary of my experience coding the
whole thing in GWT. Not sure how useful this is for other people, but
here it goes:
Some statistics:
------------------------
1. It has about 900 classes, including all the interface classes, data
transfer classes, etc. Not a big system for a team, but not a small
system for two people.
2. We have about 17 GWT modules, as one module would take too long to
load for this kind of application, in our opinion. It takes about 18
minutes to compile on my Windows machine, and 1 minute longer on my
newer and much faster Linux machine, which baffles me no ends. Why is
JDK faster on Windows? I am curious about the speed of compiling GWT
on a Solaris machine now.
3. It took six months to code. It was mostly done by me, with a friend
helping here and there. And it was my decision to use GWT. And I can
honestly say that without GWT, it would have taken a lot longer than 6
months, and the result would be much worse.
4. We use OpenOffice as the backend to generate Microsoft Word and PDF
documents. So, we have to create ODT documents on the fly. We have to
convert some data from HTML entered by the user into the RichTextArea
widget. The HTML to ODT capability is quite limited right now, but
will be improved as time goes on.
5. We use Tomcat 6.0.16 on the server side. As a production system, it
has its problems. But after using Tomcat for the last 8 years, we sort
of know what to expect and what to avoid.
6. We use postgres 8.3.3. as the database. In our pre-production
period, we were patching the database from deployment to deployment to
figure out the character of the system (every system reacts
differently in production, and we wanted to learn that character
before putting the system in production), and PLPerl is really good in
handling data migration on the fly. Underpowered (try passing arrays
in as parameters), that is for sure, but easy to handle.
Lessons learnt
------------------------
Now, these are lessons learnt by me coding this application. They
might not apply to your situations. And they are really common sense.
If you don't agree with them, I am all ears.
1. Can't reuse data transfer classes. Initially, we had general
purpose data transfer classes between the database and the browser.
Then we found out that we are transferring way too much information,
and data security was getting scary. So, mid-way, we decided to have
data-transfer classes that are tailored for particular remote methods.
Both approaches have their disadvantages, of course, but I am happier
now as I don't have to worry as much about data being leaked to the
wrong side.
2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
database. For the other 10%, it is a drag. We use Hibernate first and
then OpenJPA, the performance for some operations is still not good
enough for me. JPA is doing too much sometimes (fetching stuff not
needed), and too little in other times (not fetching stuff that is
needed almost right away). But no system can read the programmer's
mind, so I am extremely grateful to be able to use JPA for the 90%,
and I have no problem coding by hand the other 10%. The only thing is
that refactoring is made harder by JPA, as the queries are in
strings.
It would be nice to have a tool that allows programmers to code in
Java for the queries, to make refactoring of the entity classes
easier. But then that will need a GWT-like compiler to make it
possible to write queries in Java, so that people can develop and
debug in the Java mode, and then compiled into JDBC or JPA queries
strings for a "production-mode". Sounds like an interesting project to
me.
3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
and I moved it to GWT1.5 to anticipate the next version of GWT. But we
could not stay with 1.4, as the generics and annotations are simply
too valuable for refactoring. The lesson learnt is that even though we
don't create our own generics, just as a compilation checking tool and
its ability to facilitate refactoring for GWT, it is worth it.
4. Test the browsers. Don't assume everything will work in the same
way. We did have to avoid some browser problems, like one time we were
causing Opera to crash consistently over some HTML produced by MS
Word. That is not a GWT issue, of course, it is an Opera issue (it
should not crash when fed with that HTML), and our issue (we should
not feed Opera HTML that it is going to choke on). And the other time,
when we crashed IE with the PushButton widget; this is a GWT issue, as
it should not crash IE, and it is IE's issue, as it should not crash,
period. But compared to what we would have to handle hand-coding
JavaScript, these are minor issues.
The other thing is, if you have a lot of information to display, the
browsers don't display them in the same way. For instance, Firefox
would display information when it comes, IE would display only after
all the information has arrived, etc. So, a progress widget is easy to
code for Firefox, but much tougher for IE.
Other thoughts
---------------------
We are not usability experts, and we are not graphic designers either.
But because of the interactivity allowed by JavaScript (via GWT), we
wanted to build a system that is clean, and made the editing
operations in-place, so that the user's attention does not have to
switch to a new page, and then back, whenever they want to do
something. Instead, they will look at the same widgets when
information is displayed, and when they want to change the information
being displayed. I think we accomplished that.
For the site, we aimed to make the UI as clutter-free as possible, and
make the different operations available as cleanly as possible. I
think we succeeded in those two goals as well. But see for yourself,
as the site is free for everyone. Obviously, we have just started, and
we have not started to talk to companies and recruiters yet, so there
are no job postings right now. But you can enter information, and see
how the information is displayed, edited, etc.
If you did try the site, please let us know what you think of it. We
value your suggestions, criticisms, and comments very much.
Obviously, whether the site is going to be successful really does not
depend on what toolkit we used to code it.
Have you guys thought about open sourcing your app or part of it?, i'm really interested in the OpenOffice integration you talked about seems really cool.
> We put our GWT-based job site (http://www.careercommons.com) in > production on Monday. This is a summary of my experience coding the > whole thing in GWT. Not sure how useful this is for other people, but > here it goes:
> Some statistics: > ------------------------ > 1. It has about 900 classes, including all the interface classes, data > transfer classes, etc. Not a big system for a team, but not a small > system for two people.
> 2. We have about 17 GWT modules, as one module would take too long to > load for this kind of application, in our opinion. It takes about 18 > minutes to compile on my Windows machine, and 1 minute longer on my > newer and much faster Linux machine, which baffles me no ends. Why is > JDK faster on Windows? I am curious about the speed of compiling GWT > on a Solaris machine now.
> 3. It took six months to code. It was mostly done by me, with a friend > helping here and there. And it was my decision to use GWT. And I can > honestly say that without GWT, it would have taken a lot longer than 6 > months, and the result would be much worse.
> 4. We use OpenOffice as the backend to generate Microsoft Word and PDF > documents. So, we have to create ODT documents on the fly. We have to > convert some data from HTML entered by the user into the RichTextArea > widget. The HTML to ODT capability is quite limited right now, but > will be improved as time goes on.
> 5. We use Tomcat 6.0.16 on the server side. As a production system, it > has its problems. But after using Tomcat for the last 8 years, we sort > of know what to expect and what to avoid.
> 6. We use postgres 8.3.3. as the database. In our pre-production > period, we were patching the database from deployment to deployment to > figure out the character of the system (every system reacts > differently in production, and we wanted to learn that character > before putting the system in production), and PLPerl is really good in > handling data migration on the fly. Underpowered (try passing arrays > in as parameters), that is for sure, but easy to handle.
> Lessons learnt > ------------------------
> Now, these are lessons learnt by me coding this application. They > might not apply to your situations. And they are really common sense. > If you don't agree with them, I am all ears.
> 1. Can't reuse data transfer classes. Initially, we had general > purpose data transfer classes between the database and the browser. > Then we found out that we are transferring way too much information, > and data security was getting scary. So, mid-way, we decided to have > data-transfer classes that are tailored for particular remote methods. > Both approaches have their disadvantages, of course, but I am happier > now as I don't have to worry as much about data being leaked to the > wrong side.
> 2. (Non-GWT) JPA is godsend in 90% of what we need to do with a > database. For the other 10%, it is a drag. We use Hibernate first and > then OpenJPA, the performance for some operations is still not good > enough for me. JPA is doing too much sometimes (fetching stuff not > needed), and too little in other times (not fetching stuff that is > needed almost right away). But no system can read the programmer's > mind, so I am extremely grateful to be able to use JPA for the 90%, > and I have no problem coding by hand the other 10%. The only thing is > that refactoring is made harder by JPA, as the queries are in > strings.
> It would be nice to have a tool that allows programmers to code in > Java for the queries, to make refactoring of the entity classes > easier. But then that will need a GWT-like compiler to make it > possible to write queries in Java, so that people can develop and > debug in the Java mode, and then compiled into JDBC or JPA queries > strings for a "production-mode". Sounds like an interesting project to > me.
> 3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4, > and I moved it to GWT1.5 to anticipate the next version of GWT. But we > could not stay with 1.4, as the generics and annotations are simply > too valuable for refactoring. The lesson learnt is that even though we > don't create our own generics, just as a compilation checking tool and > its ability to facilitate refactoring for GWT, it is worth it.
> 4. Test the browsers. Don't assume everything will work in the same > way. We did have to avoid some browser problems, like one time we were > causing Opera to crash consistently over some HTML produced by MS > Word. That is not a GWT issue, of course, it is an Opera issue (it > should not crash when fed with that HTML), and our issue (we should > not feed Opera HTML that it is going to choke on). And the other time, > when we crashed IE with the PushButton widget; this is a GWT issue, as > it should not crash IE, and it is IE's issue, as it should not crash, > period. But compared to what we would have to handle hand-coding > JavaScript, these are minor issues.
> The other thing is, if you have a lot of information to display, the > browsers don't display them in the same way. For instance, Firefox > would display information when it comes, IE would display only after > all the information has arrived, etc. So, a progress widget is easy to > code for Firefox, but much tougher for IE.
> Other thoughts > ---------------------
> We are not usability experts, and we are not graphic designers either. > But because of the interactivity allowed by JavaScript (via GWT), we > wanted to build a system that is clean, and made the editing > operations in-place, so that the user's attention does not have to > switch to a new page, and then back, whenever they want to do > something. Instead, they will look at the same widgets when > information is displayed, and when they want to change the information > being displayed. I think we accomplished that.
> For the site, we aimed to make the UI as clutter-free as possible, and > make the different operations available as cleanly as possible. I > think we succeeded in those two goals as well. But see for yourself, > as the site is free for everyone. Obviously, we have just started, and > we have not started to talk to companies and recruiters yet, so there > are no job postings right now. But you can enter information, and see > how the information is displayed, edited, etc.
> If you did try the site, please let us know what you think of it. We > value your suggestions, criticisms, and comments very much.
> Obviously, whether the site is going to be successful really does not > depend on what toolkit we used to code it.
> We put our GWT-based job site (http://www.careercommons.com) in
> production on Monday. This is a summary of my experience coding the
> whole thing in GWT. Not sure how useful this is for other people, but
> here it goes:
> Some statistics:
> ------------------------
> 1. It has about 900 classes, including all the interface classes, data
> transfer classes, etc. Not a big system for a team, but not a small
> system for two people.
> 2. We have about 17 GWT modules, as one module would take too long to
> load for this kind of application, in our opinion. It takes about 18
> minutes to compile on my Windows machine, and 1 minute longer on my
> newer and much faster Linux machine, which baffles me no ends. Why is
> JDK faster on Windows? I am curious about the speed of compiling GWT
> on a Solaris machine now.
> 3. It took six months to code. It was mostly done by me, with a friend
> helping here and there. And it was my decision to use GWT. And I can
> honestly say that without GWT, it would have taken a lot longer than 6
> months, and the result would be much worse.
> 4. We use OpenOffice as the backend to generate Microsoft Word and PDF
> documents. So, we have to create ODT documents on the fly. We have to
> convert some data from HTML entered by the user into the RichTextArea
> widget. The HTML to ODT capability is quite limited right now, but
> will be improved as time goes on.
> 5. We use Tomcat 6.0.16 on the server side. As a production system, it
> has its problems. But after using Tomcat for the last 8 years, we sort
> of know what to expect and what to avoid.
> 6. We use postgres 8.3.3. as the database. In our pre-production
> period, we were patching the database from deployment to deployment to
> figure out the character of the system (every system reacts
> differently in production, and we wanted to learn that character
> before putting the system in production), and PLPerl is really good in
> handling data migration on the fly. Underpowered (try passing arrays
> in as parameters), that is for sure, but easy to handle.
> Lessons learnt
> ------------------------
> Now, these are lessons learnt by me coding this application. They
> might not apply to your situations. And they are really common sense.
> If you don't agree with them, I am all ears.
> 1. Can't reuse data transfer classes. Initially, we had general
> purpose data transfer classes between the database and the browser.
> Then we found out that we are transferring way too much information,
> and data security was getting scary. So, mid-way, we decided to have
> data-transfer classes that are tailored for particular remote methods.
> Both approaches have their disadvantages, of course, but I am happier
> now as I don't have to worry as much about data being leaked to the
> wrong side.
> 2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
> database. For the other 10%, it is a drag. We use Hibernate first and
> then OpenJPA, the performance for some operations is still not good
> enough for me. JPA is doing too much sometimes (fetching stuff not
> needed), and too little in other times (not fetching stuff that is
> needed almost right away). But no system can read the programmer's
> mind, so I am extremely grateful to be able to use JPA for the 90%,
> and I have no problem coding by hand the other 10%. The only thing is
> that refactoring is made harder by JPA, as the queries are in
> strings.
> It would be nice to have a tool that allows programmers to code in
> Java for the queries, to make refactoring of the entity classes
> easier. But then that will need a GWT-like compiler to make it
> possible to write queries in Java, so that people can develop and
> debug in the Java mode, and then compiled into JDBC or JPA queries
> strings for a "production-mode". Sounds like an interesting project to
> me.
> 3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
> and I moved it to GWT1.5 to anticipate the next version of GWT. But we
> could not stay with 1.4, as the generics and annotations are simply
> too valuable for refactoring. The lesson learnt is that even though we
> don't create our own generics, just as a compilation checking tool and
> its ability to facilitate refactoring for GWT, it is worth it.
> 4. Test the browsers. Don't assume everything will work in the same
> way. We did have to avoid some browser problems, like one time we were
> causing Opera to crash consistently over some HTML produced by MS
> Word. That is not a GWT issue, of course, it is an Opera issue (it
> should not crash when fed with that HTML), and our issue (we should
> not feed Opera HTML that it is going to choke on). And the other time,
> when we crashed IE with the PushButton widget; this is a GWT issue, as
> it should not crash IE, and it is IE's issue, as it should not crash,
> period. But compared to what we would have to handle hand-coding
> JavaScript, these are minor issues.
> The other thing is, if you have a lot of information to display, the
> browsers don't display them in the same way. For instance, Firefox
> would display information when it comes, IE would display only after
> all the information has arrived, etc. So, a progress widget is easy to
> code for Firefox, but much tougher for IE.
> Other thoughts
> ---------------------
> We are not usability experts, and we are not graphic designers either.
> But because of the interactivity allowed by JavaScript (via GWT), we
> wanted to build a system that is clean, and made the editing
> operations in-place, so that the user's attention does not have to
> switch to a new page, and then back, whenever they want to do
> something. Instead, they will look at the same widgets when
> information is displayed, and when they want to change the information
> being displayed. I think we accomplished that.
> For the site, we aimed to make the UI as clutter-free as possible, and
> make the different operations available as cleanly as possible. I
> think we succeeded in those two goals as well. But see for yourself,
> as the site is free for everyone. Obviously, we have just started, and
> we have not started to talk to companies and recruiters yet, so there
> are no job postings right now. But you can enter information, and see
> how the information is displayed, edited, etc.
> If you did try the site, please let us know what you think of it. We
> value your suggestions, criticisms, and comments very much.
> Obviously, whether the site is going to be successful really does not
> depend on what toolkit we used to code it.
Nice post specially the "lesson learnt" section, did you use GWT RPC
for data transfer? if so how is your experience with that? And why did
you choose GWT RPC over JSON transfer?
Thanks.
On Jul 30, 10:39 am, WadeC <wade.clin...@gmail.com> wrote:
> Can you expand on #5 and give some more details on the problems of
> running a TomCat production server and how you managed to get around
> these issues.
> > We put our GWT-based job site (http://www.careercommons.com) in
> > production on Monday. This is a summary of my experience coding the
> > whole thing in GWT. Not sure how useful this is for other people, but
> > here it goes:
> > Some statistics:
> > ------------------------
> > 1. It has about 900 classes, including all the interface classes, data
> > transfer classes, etc. Not a big system for a team, but not a small
> > system for two people.
> > 2. We have about 17 GWT modules, as one module would take too long to
> > load for this kind of application, in our opinion. It takes about 18
> > minutes to compile on my Windows machine, and 1 minute longer on my
> > newer and much faster Linux machine, which baffles me no ends. Why is
> > JDK faster on Windows? I am curious about the speed of compiling GWT
> > on a Solaris machine now.
> > 3. It took six months to code. It was mostly done by me, with a friend
> > helping here and there. And it was my decision to use GWT. And I can
> > honestly say that without GWT, it would have taken a lot longer than 6
> > months, and the result would be much worse.
> > 4. We use OpenOffice as the backend to generate Microsoft Word and PDF
> > documents. So, we have to create ODT documents on the fly. We have to
> > convert some data from HTML entered by the user into the RichTextArea
> > widget. The HTML to ODT capability is quite limited right now, but
> > will be improved as time goes on.
> > 5. We use Tomcat 6.0.16 on the server side. As a production system, it
> > has its problems. But after using Tomcat for the last 8 years, we sort
> > of know what to expect and what to avoid.
> > 6. We use postgres 8.3.3. as the database. In our pre-production
> > period, we were patching the database from deployment to deployment to
> > figure out the character of the system (every system reacts
> > differently in production, and we wanted to learn that character
> > before putting the system in production), and PLPerl is really good in
> > handling data migration on the fly. Underpowered (try passing arrays
> > in as parameters), that is for sure, but easy to handle.
> > Lessons learnt
> > ------------------------
> > Now, these are lessons learnt by me coding this application. They
> > might not apply to your situations. And they are really common sense.
> > If you don't agree with them, I am all ears.
> > 1. Can't reuse data transfer classes. Initially, we had general
> > purpose data transfer classes between the database and the browser.
> > Then we found out that we are transferring way too much information,
> > and data security was getting scary. So, mid-way, we decided to have
> > data-transfer classes that are tailored for particular remote methods.
> > Both approaches have their disadvantages, of course, but I am happier
> > now as I don't have to worry as much about data being leaked to the
> > wrong side.
> > 2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
> > database. For the other 10%, it is a drag. We use Hibernate first and
> > then OpenJPA, the performance for some operations is still not good
> > enough for me. JPA is doing too much sometimes (fetching stuff not
> > needed), and too little in other times (not fetching stuff that is
> > needed almost right away). But no system can read the programmer's
> > mind, so I am extremely grateful to be able to use JPA for the 90%,
> > and I have no problem coding by hand the other 10%. The only thing is
> > that refactoring is made harder by JPA, as the queries are in
> > strings.
> > It would be nice to have a tool that allows programmers to code in
> > Java for the queries, to make refactoring of the entity classes
> > easier. But then that will need a GWT-like compiler to make it
> > possible to write queries in Java, so that people can develop and
> > debug in the Java mode, and then compiled into JDBC or JPA queries
> > strings for a "production-mode". Sounds like an interesting project to
> > me.
> > 3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
> > and I moved it to GWT1.5 to anticipate the next version of GWT. But we
> > could not stay with 1.4, as the generics and annotations are simply
> > too valuable for refactoring. The lesson learnt is that even though we
> > don't create our own generics, just as a compilation checking tool and
> > its ability to facilitate refactoring for GWT, it is worth it.
> > 4. Test the browsers. Don't assume everything will work in the same
> > way. We did have to avoid some browser problems, like one time we were
> > causing Opera to crash consistently over some HTML produced by MS
> > Word. That is not a GWT issue, of course, it is an Opera issue (it
> > should not crash when fed with that HTML), and our issue (we should
> > not feed Opera HTML that it is going to choke on). And the other time,
> > when we crashed IE with the PushButton widget; this is a GWT issue, as
> > it should not crash IE, and it is IE's issue, as it should not crash,
> > period. But compared to what we would have to handle hand-coding
> > JavaScript, these are minor issues.
> > The other thing is, if you have a lot of information to display, the
> > browsers don't display them in the same way. For instance, Firefox
> > would display information when it comes, IE would display only after
> > all the information has arrived, etc. So, a progress widget is easy to
> > code for Firefox, but much tougher for IE.
> > Other thoughts
> > ---------------------
> > We are not usability experts, and we are not graphic designers either.
> > But because of the interactivity allowed by JavaScript (via GWT), we
> > wanted to build a system that is clean, and made the editing
> > operations in-place, so that the user's attention does not have to
> > switch to a new page, and then back, whenever they want to do
> > something. Instead, they will look at the same widgets when
> > information is displayed, and when they want to change the information
> > being displayed. I think we accomplished that.
> > For the site, we aimed to make the UI as clutter-free as possible, and
> > make the different operations available as cleanly as possible. I
> > think we succeeded in those two goals as well. But see for yourself,
> > as the site is free for everyone. Obviously, we have just started, and
> > we have not started to talk to companies and recruiters yet, so there
> > are no job postings right now. But you can enter information, and see
> > how the information is displayed, edited, etc.
> > If you did try the site, please let us know what you think of it. We
> > value your suggestions, criticisms, and comments very much.
> > Obviously, whether the site is going to be successful really does not
> > depend on what toolkit we used to code it.
About OpenOffice integration. We use JODConverter as the communication
library between our system and OpenOffice. It is LGPL licensed. It is
good enough for us right now, as we are getting DOC and PDF out of it.
We run OpenOffice as a server.
We create ODT on the fly, using JDOM to create content.xml, style.xml,
and metadata.xml; then we create the ODT file using the standard Java
library. A ODT file is really a ZIP file, containing these XML files
and other resources.
Creating the content.xml file inside an ODT file took the longest
time, translating HTML to ODT, and making sure the result looks
similar. We only have a simple CSS parser right now; we will improve
that, and eventually make it a full-fledged HTML+CSS to ODT later. If
that thing is half-decent and useful, I will open source it.
Khun Yee
On Jul 30, 1:07 pm, "Roger Marin" <rsman...@gmail.com> wrote:
> Have you guys thought about open sourcing your app or part of it?, i'm
> really interested in the OpenOffice integration you talked about seems
> really cool.
> > We put our GWT-based job site (http://www.careercommons.com) in
> > production on Monday. This is a summary of my experience coding the
> > whole thing in GWT. Not sure how useful this is for other people, but
> > here it goes:
> > Some statistics:
> > ------------------------
> > 1. It has about 900 classes, including all the interface classes, data
> > transfer classes, etc. Not a big system for a team, but not a small
> > system for two people.
> > 2. We have about 17 GWT modules, as one module would take too long to
> > load for this kind of application, in our opinion. It takes about 18
> > minutes to compile on my Windows machine, and 1 minute longer on my
> > newer and much faster Linux machine, which baffles me no ends. Why is
> > JDK faster on Windows? I am curious about the speed of compiling GWT
> > on a Solaris machine now.
> > 3. It took six months to code. It was mostly done by me, with a friend
> > helping here and there. And it was my decision to use GWT. And I can
> > honestly say that without GWT, it would have taken a lot longer than 6
> > months, and the result would be much worse.
> > 4. We use OpenOffice as the backend to generate Microsoft Word and PDF
> > documents. So, we have to create ODT documents on the fly. We have to
> > convert some data from HTML entered by the user into the RichTextArea
> > widget. The HTML to ODT capability is quite limited right now, but
> > will be improved as time goes on.
> > 5. We use Tomcat 6.0.16 on the server side. As a production system, it
> > has its problems. But after using Tomcat for the last 8 years, we sort
> > of know what to expect and what to avoid.
> > 6. We use postgres 8.3.3. as the database. In our pre-production
> > period, we were patching the database from deployment to deployment to
> > figure out the character of the system (every system reacts
> > differently in production, and we wanted to learn that character
> > before putting the system in production), and PLPerl is really good in
> > handling data migration on the fly. Underpowered (try passing arrays
> > in as parameters), that is for sure, but easy to handle.
> > Lessons learnt
> > ------------------------
> > Now, these are lessons learnt by me coding this application. They
> > might not apply to your situations. And they are really common sense.
> > If you don't agree with them, I am all ears.
> > 1. Can't reuse data transfer classes. Initially, we had general
> > purpose data transfer classes between the database and the browser.
> > Then we found out that we are transferring way too much information,
> > and data security was getting scary. So, mid-way, we decided to have
> > data-transfer classes that are tailored for particular remote methods.
> > Both approaches have their disadvantages, of course, but I am happier
> > now as I don't have to worry as much about data being leaked to the
> > wrong side.
> > 2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
> > database. For the other 10%, it is a drag. We use Hibernate first and
> > then OpenJPA, the performance for some operations is still not good
> > enough for me. JPA is doing too much sometimes (fetching stuff not
> > needed), and too little in other times (not fetching stuff that is
> > needed almost right away). But no system can read the programmer's
> > mind, so I am extremely grateful to be able to use JPA for the 90%,
> > and I have no problem coding by hand the other 10%. The only thing is
> > that refactoring is made harder by JPA, as the queries are in
> > strings.
> > It would be nice to have a tool that allows programmers to code in
> > Java for the queries, to make refactoring of the entity classes
> > easier. But then that will need a GWT-like compiler to make it
> > possible to write queries in Java, so that people can develop and
> > debug in the Java mode, and then compiled into JDBC or JPA queries
> > strings for a "production-mode". Sounds like an interesting project to
> > me.
> > 3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
> > and I moved it to GWT1.5 to anticipate the next version of GWT. But we
> > could not stay with 1.4, as the generics and annotations are simply
> > too valuable for refactoring. The lesson learnt is that even though we
> > don't create our own generics, just as a compilation checking tool and
> > its ability to facilitate refactoring for GWT, it is worth it.
> > 4. Test the browsers. Don't assume everything will work in the same
> > way. We did have to avoid some browser problems, like one time we were
> > causing Opera to crash consistently over some HTML produced by MS
> > Word. That is not a GWT issue, of course, it is an Opera issue (it
> > should not crash when fed with that HTML), and our issue (we should
> > not feed Opera HTML that it is going to choke on). And the other time,
> > when we crashed IE with the PushButton widget; this is a GWT issue, as
> > it should not crash IE, and it is IE's issue, as it should not crash,
> > period. But compared to what we would have to handle hand-coding
> > JavaScript, these are minor issues.
> > The other thing is, if you have a lot of information to display, the
> > browsers don't display them in the same way. For instance, Firefox
> > would display information when it comes, IE would display only after
> > all the information has arrived, etc. So, a progress widget is easy to
> > code for Firefox, but much tougher for IE.
> > Other thoughts
> > ---------------------
> > We are not usability experts, and we are not graphic designers either.
> > But because of the interactivity allowed by JavaScript (via GWT), we
> > wanted to build a system that is clean, and made the editing
> > operations in-place, so that the user's attention does not have to
> > switch to a new page, and then back, whenever they want to do
> > something. Instead, they will look at the same widgets when
> > information is displayed, and when they want to change the information
> > being displayed. I think we accomplished that.
> > For the site, we aimed to make the UI as clutter-free as possible, and
> > make the different operations available as cleanly as possible. I
> > think we succeeded in those two goals as well. But see for yourself,
> > as the site is free for everyone. Obviously, we have just started, and
> > we have not started to talk to companies and recruiters yet, so there
> > are no job postings right now. But you can enter information, and see
> > how the information is displayed, edited, etc.
> > If you did try the site, please let us know what you think of it. We
> > value your suggestions, criticisms, and comments very much.
> > Obviously, whether the site is going to be successful really does not
> > depend on what toolkit we used to code it.
> Nice post specially the "lesson learnt" section, did you use GWT RPC
> for data transfer? if so how is your experience with that? And why did
> you choose GWT RPC over JSON transfer?
> Thanks.
> On Jul 30, 10:39 am, WadeC <wade.clin...@gmail.com> wrote:
> > Khun,
> > Looks like an impressive site...
> > Can you expand on #5 and give some more details on the problems of
> > running a TomCat production server and how you managed to get around
> > these issues.
> > > We put our GWT-based job site (http://www.careercommons.com) in
> > > production on Monday. This is a summary of my experience coding the
> > > whole thing in GWT. Not sure how useful this is for other people, but
> > > here it goes:
> > > Some statistics:
> > > ------------------------
> > > 1. It has about 900 classes, including all the interface classes, data
> > > transfer classes, etc. Not a big system for a team, but not a small
> > > system for two people.
> > > 2. We have about 17 GWT modules, as one module would take too long to
> > > load for this kind of application, in our opinion. It takes about 18
> > > minutes to compile on my Windows machine, and 1 minute longer on my
> > > newer and much faster Linux machine, which baffles me no ends. Why is
> > > JDK faster on Windows? I am curious about the speed of compiling GWT
> > > on a Solaris machine now.
> > > 3. It took six months to code. It was mostly done by me, with a friend
> > > helping here and there. And it was my decision to use GWT. And I can
> > > honestly say that without GWT, it would have taken a lot longer than 6
> > > months, and the result would be much worse.
> > > 4. We use OpenOffice as the backend to generate Microsoft Word and PDF
> > > documents. So, we have to create ODT documents on the fly. We have to
> > > convert some data from HTML entered by the user into the RichTextArea
> > > widget. The HTML to ODT capability is quite limited right now, but
> > > will be improved as time goes on.
> > > 5. We use Tomcat 6.0.16 on the server side. As a production system, it
> > > has its problems. But after using Tomcat for the last 8 years, we sort
> > > of know what to expect and what to avoid.
> > > 6. We use postgres 8.3.3. as the database. In our pre-production
> > > period, we were patching the database from deployment to deployment to
> > > figure out the character of the system (every system reacts
> > > differently in production, and we wanted to learn that character
> > > before putting the system in production), and PLPerl is really good in
> > > handling data migration on the fly. Underpowered (try passing arrays
> > > in as parameters), that is for sure, but easy to handle.
> > > Now, these are lessons learnt by me coding this application. They
> > > might not apply to your situations. And they are really common sense.
> > > If you don't agree with them, I am all ears.
> > > 1. Can't reuse data transfer classes. Initially, we had general
> > > purpose data transfer classes between the database and the browser.
> > > Then we found out that we are transferring way too much information,
> > > and data security was getting scary. So, mid-way, we decided to have
> > > data-transfer classes that are tailored for particular remote methods.
> > > Both approaches have their disadvantages, of course, but I am happier
> > > now as I don't have to worry as much about data being leaked to the
> > > wrong side.
> > > 2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
> > > database. For the other 10%, it is a drag. We use Hibernate first and
> > > then OpenJPA, the performance for some operations is still not good
> > > enough for me. JPA is doing too much sometimes (fetching stuff not
> > > needed), and too little in other times (not fetching stuff that is
> > > needed almost right away). But no system can read the programmer's
> > > mind, so I am extremely grateful to be able to use JPA for the 90%,
> > > and I have no problem coding by hand the other 10%. The only thing is
> > > that refactoring is made harder by JPA, as the queries are in
> > > strings.
> > > It would be nice to have a tool that allows programmers to code in
> > > Java for the queries, to make refactoring of the entity classes
> > > easier. But then that will need a GWT-like compiler to make it
> > > possible to write queries in Java, so that people can develop and
> > > debug in the Java mode, and then compiled into JDBC or JPA queries
> > > strings for a "production-mode". Sounds like an interesting project to
> > > me.
> > > 3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
> > > and I moved it to GWT1.5 to anticipate the next version of GWT. But we
> > > could not stay with 1.4, as the generics and annotations are simply
> > > too valuable for refactoring. The lesson learnt is that even though we
> > > don't create our own generics, just as a compilation checking tool and
> > > its ability to facilitate refactoring for GWT, it is worth it.
> > > 4. Test the browsers. Don't assume everything will work in the same
> > > way. We did have to avoid some browser problems, like one time we were
> > > causing Opera to crash consistently over some HTML produced by MS
> > > Word. That is not a GWT issue, of course, it is an Opera issue (it
> > > should not crash when fed with that HTML), and our issue (we should
> > > not feed Opera HTML that it is going to choke on). And the other time,
> > > when we crashed IE with the PushButton widget; this is a GWT issue, as
> > > it should not crash IE, and it is IE's issue, as it should not crash,
> > > period. But compared to what we would have to handle hand-coding
> > > JavaScript, these are minor issues.
> > > The other thing is, if you have a lot of information to display, the
> > > browsers don't display them in the same way. For instance, Firefox
> > > would display information when it comes, IE would display only after
> > > all the information has arrived, etc. So, a progress widget is easy to
> > > code for Firefox, but much tougher for IE.
> > > Other thoughts
> > > ---------------------
> > > We are not usability experts, and we are not graphic designers either.
> > > But because of the interactivity allowed by JavaScript (via GWT), we
> > > wanted to build a system that is clean, and made the editing
> > > operations in-place, so that the user's attention does not have to
> > > switch to a new page, and then back, whenever they want to do
> > > something. Instead, they will look at the same widgets when
> > > information is displayed, and when they want to change the information
> > > being displayed. I think we accomplished that.
> > > For the site, we aimed to make the UI as clutter-free as possible, and
> > > make the different operations available as cleanly as possible. I
> > > think we succeeded in those two goals as well. But see for yourself,
> > > as the site is free for everyone. Obviously, we have just started, and
> > > we have not started to talk to companies and recruiters yet, so there
> > > are no job postings right now. But you can enter information, and see
> > > how the information is displayed, edited, etc.
> > > If you did try the site, please let us know what you think of it. We
> > > value your suggestions, criticisms, and comments very much.
> > > Obviously, whether the site is going to be successful really does not
> > > depend on what toolkit we used to code it.
Well, in my previous life, I was responsible for a software-as-a-
service system. We deployed at least once a week, and we had multiple
clients on one tomcat, even though we had a few tomcat servers. The
clients ran essentially the same code. We used to run everything on
Windows, and gradually we moved to Linux. So, we had a few interesting
problems with Tomcat in that kind of environment.
For instance, when we were using the DBCP in tomcat to manage the
connection pool for us, one time, we had a client seeing the database
of another client. Apparently, Tomcat mixed up some connections. Could
not reproduce the problem, but we used a separate connection pool for
each client after that.
When we were moving from Windows to Linux, at one time, we had a
Tomcat server running on Windows and Apache HTTPD running on Linux,
with Jk connecting them. Tomcat ran out of memory about every hour.
Ruined my Christmas trying to prove to our VC that even though hundred
of thousands of websites ran Apache+Tomcat and having no problem, that
problem was real, and only happened if the combination was precisely
that.
And so on. I doubt it is interesting for other people to read these
environment specific issues with Tomcat, which is off-topic for this
group, I think.
Don't get me wrong. I love Tomcat. It made my life much easier. I only
have praises, thanks, and compliments for the Tomcat guys. I would use
Tomcat in production with no hesitation. Especially now that I know
how what to look out for.
Khun Yee
On Jul 30, 1:39 pm, WadeC <wade.clin...@gmail.com> wrote:
> Can you expand on #5 and give some more details on the problems of
> running a TomCat production server and how you managed to get around
> these issues.
> > We put our GWT-based job site (http://www.careercommons.com) in
> > production on Monday. This is a summary of my experience coding the
> > whole thing in GWT. Not sure how useful this is for other people, but
> > here it goes:
> > Some statistics:
> > ------------------------
> > 1. It has about 900 classes, including all the interface classes, data
> > transfer classes, etc. Not a big system for a team, but not a small
> > system for two people.
> > 2. We have about 17 GWT modules, as one module would take too long to
> > load for this kind of application, in our opinion. It takes about 18
> > minutes to compile on my Windows machine, and 1 minute longer on my
> > newer and much faster Linux machine, which baffles me no ends. Why is
> > JDK faster on Windows? I am curious about the speed of compiling GWT
> > on a Solaris machine now.
> > 3. It took six months to code. It was mostly done by me, with a friend
> > helping here and there. And it was my decision to use GWT. And I can
> > honestly say that without GWT, it would have taken a lot longer than 6
> > months, and the result would be much worse.
> > 4. We use OpenOffice as the backend to generate Microsoft Word and PDF
> > documents. So, we have to create ODT documents on the fly. We have to
> > convert some data from HTML entered by the user into the RichTextArea
> > widget. The HTML to ODT capability is quite limited right now, but
> > will be improved as time goes on.
> > 5. We use Tomcat 6.0.16 on the server side. As a production system, it
> > has its problems. But after using Tomcat for the last 8 years, we sort
> > of know what to expect and what to avoid.
> > 6. We use postgres 8.3.3. as the database. In our pre-production
> > period, we were patching the database from deployment to deployment to
> > figure out the character of the system (every system reacts
> > differently in production, and we wanted to learn that character
> > before putting the system in production), and PLPerl is really good in
> > handling data migration on the fly. Underpowered (try passing arrays
> > in as parameters), that is for sure, but easy to handle.
> > Lessons learnt
> > ------------------------
> > Now, these are lessons learnt by me coding this application. They
> > might not apply to your situations. And they are really common sense.
> > If you don't agree with them, I am all ears.
> > 1. Can't reuse data transfer classes. Initially, we had general
> > purpose data transfer classes between the database and the browser.
> > Then we found out that we are transferring way too much information,
> > and data security was getting scary. So, mid-way, we decided to have
> > data-transfer classes that are tailored for particular remote methods.
> > Both approaches have their disadvantages, of course, but I am happier
> > now as I don't have to worry as much about data being leaked to the
> > wrong side.
> > 2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
> > database. For the other 10%, it is a drag. We use Hibernate first and
> > then OpenJPA, the performance for some operations is still not good
> > enough for me. JPA is doing too much sometimes (fetching stuff not
> > needed), and too little in other times (not fetching stuff that is
> > needed almost right away). But no system can read the programmer's
> > mind, so I am extremely grateful to be able to use JPA for the 90%,
> > and I have no problem coding by hand the other 10%. The only thing is
> > that refactoring is made harder by JPA, as the queries are in
> > strings.
> > It would be nice to have a tool that allows programmers to code in
> > Java for the queries, to make refactoring of the entity classes
> > easier. But then that will need a GWT-like compiler to make it
> > possible to write queries in Java, so that people can develop and
> > debug in the Java mode, and then compiled into JDBC or JPA queries
> > strings for a "production-mode". Sounds like an interesting project to
> > me.
> > 3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
> > and I moved it to GWT1.5 to anticipate the next version of GWT. But we
> > could not stay with 1.4, as the generics and annotations are simply
> > too valuable for refactoring. The lesson learnt is that even though we
> > don't create our own generics, just as a compilation checking tool and
> > its ability to facilitate refactoring for GWT, it is worth it.
> > 4. Test the browsers. Don't assume everything will work in the same
> > way. We did have to avoid some browser problems, like one time we were
> > causing Opera to crash consistently over some HTML produced by MS
> > Word. That is not a GWT issue, of course, it is an Opera issue (it
> > should not crash when fed with that HTML), and our issue (we should
> > not feed Opera HTML that it is going to choke on). And the other time,
> > when we crashed IE with the PushButton widget; this is a GWT issue, as
> > it should not crash IE, and it is IE's issue, as it should not crash,
> > period. But compared to what we would have to handle hand-coding
> > JavaScript, these are minor issues.
> > The other thing is, if you have a lot of information to display, the
> > browsers don't display them in the same way. For instance, Firefox
> > would display information when it comes, IE would display only after
> > all the information has arrived, etc. So, a progress widget is easy to
> > code for Firefox, but much tougher for IE.
> > Other thoughts
> > ---------------------
> > We are not usability experts, and we are not graphic designers either.
> > But because of the interactivity allowed by JavaScript (via GWT), we
> > wanted to build a system that is clean, and made the editing
> > operations in-place, so that the user's attention does not have to
> > switch to a new page, and then back, whenever they want to do
> > something. Instead, they will look at the same widgets when
> > information is displayed, and when they want to change the information
> > being displayed. I think we accomplished that.
> > For the site, we aimed to make the UI as clutter-free as possible, and
> > make the different operations available as cleanly as possible. I
> > think we succeeded in those two goals as well. But see for yourself,
> > as the site is free for everyone. Obviously, we have just started, and
> > we have not started to talk to companies and recruiters yet, so there
> > are no job postings right now. But you can enter information, and see
> > how the information is displayed, edited, etc.
> > If you did try the site, please let us know what you think of it. We
> > value your suggestions, criticisms, and comments very much.
> > Obviously, whether the site is going to be successful really does not
> > depend on what toolkit we used to code it.
> Well, in my previous life, I was responsible for a software-as-a-
> service system. We deployed at least once a week, and we had multiple
> clients on one tomcat, even though we had a few tomcat servers. The
> clients ran essentially the same code. We used to run everything on
> Windows, and gradually we moved to Linux. So, we had a few interesting
> problems with Tomcat in that kind of environment.
> For instance, when we were using the DBCP in tomcat to manage the
> connection pool for us, one time, we had a client seeing the database
> of another client. Apparently, Tomcat mixed up some connections. Could
> not reproduce the problem, but we used a separate connection pool for
> each client after that.
> When we were moving from Windows to Linux, at one time, we had a
> Tomcat server running on Windows and Apache HTTPD running on Linux,
> with Jk connecting them. Tomcat ran out of memory about every hour.
> Ruined my Christmas trying to prove to our VC that even though hundred
> of thousands of websites ran Apache+Tomcat and having no problem, that
> problem was real, and only happened if the combination was precisely
> that.
> And so on. I doubt it is interesting for other people to read these
> environment specific issues with Tomcat, which is off-topic for this
> group, I think.
> Don't get me wrong. I love Tomcat. It made my life much easier. I only
> have praises, thanks, and compliments for the Tomcat guys. I would use
> Tomcat in production with no hesitation. Especially now that I know
> how what to look out for.
> Khun Yee
> On Jul 30, 1:39 pm, WadeC <wade.clin...@gmail.com> wrote:
> > Khun,
> > Looks like an impressive site...
> > Can you expand on #5 and give some more details on the problems of
> > running a TomCat production server and how you managed to get around
> > these issues.
> > > We put our GWT-based job site (http://www.careercommons.com) in
> > > production on Monday. This is a summary of my experience coding the
> > > whole thing in GWT. Not sure how useful this is for other people, but
> > > here it goes:
> > > Some statistics:
> > > ------------------------
> > > 1. It has about 900 classes, including all the interface classes, data
> > > transfer classes, etc. Not a big system for a team, but not a small
> > > system for two people.
> > > 2. We have about 17 GWT modules, as one module would take too long to
> > > load for this kind of application, in our opinion. It takes about 18
> > > minutes to compile on my Windows machine, and 1 minute longer on my
> > > newer and much faster Linux machine, which baffles me no ends. Why is
> > > JDK faster on Windows? I am curious about the speed of compiling GWT
> > > on a Solaris machine now.
> > > 3. It took six months to code. It was mostly done by me, with a friend
> > > helping here and there. And it was my decision to use GWT. And I can
> > > honestly say that without GWT, it would have taken a lot longer than 6
> > > months, and the result would be much worse.
> > > 4. We use OpenOffice as the backend to generate Microsoft Word and PDF
> > > documents. So, we have to create ODT documents on the fly. We have to
> > > convert some data from HTML entered by the user into the RichTextArea
> > > widget. The HTML to ODT capability is quite limited right now, but
> > > will be improved as time goes on.
> > > 5. We use Tomcat 6.0.16 on the server side. As a production system, it
> > > has its problems. But after using Tomcat for the last 8 years, we sort
> > > of know what to expect and what to avoid.
> > > 6. We use postgres 8.3.3. as the database. In our pre-production
> > > period, we were patching the database from deployment to deployment to
> > > figure out the character of the system (every system reacts
> > > differently in production, and we wanted to learn that character
> > > before putting the system in production), and PLPerl is really good in
> > > handling data migration on the fly. Underpowered (try passing arrays
> > > in as parameters), that is for sure, but easy to handle.
> > > Now, these are lessons learnt by me coding this application. They
> > > might not apply to your situations. And they are really common sense.
> > > If you don't agree with them, I am all ears.
> > > 1. Can't reuse data transfer classes. Initially, we had general
> > > purpose data transfer classes between the database and the browser.
> > > Then we found out that we are transferring way too much information,
> > > and data security was getting scary. So, mid-way, we decided to have
> > > data-transfer classes that are tailored for particular remote methods.
> > > Both approaches have their disadvantages, of course, but I am happier
> > > now as I don't have to worry as much about data being leaked to the
> > > wrong side.
> > > 2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
> > > database. For the other 10%, it is a drag. We use Hibernate first and
> > > then OpenJPA, the performance for some operations is still not good
> > > enough for me. JPA is doing too much sometimes (fetching stuff not
> > > needed), and too little in other times (not fetching stuff that is
> > > needed almost right away). But no system can read the programmer's
> > > mind, so I am extremely grateful to be able to use JPA for the 90%,
> > > and I have no problem coding by hand the other 10%. The only thing is
> > > that refactoring is made harder by JPA, as the queries are in
> > > strings.
> > > It would be nice to have a tool that allows programmers to code in
> > > Java for the queries, to make refactoring of the entity classes
> > > easier. But then that will need a GWT-like compiler to make it
> > > possible to write queries in Java, so that people can develop and
> > > debug in the Java mode, and then compiled into JDBC or JPA queries
> > > strings for a "production-mode". Sounds like an interesting project to
> > > me.
> > > 3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
> > > and I moved it to GWT1.5 to anticipate the next version of GWT. But we
> > > could not stay with 1.4, as the generics and annotations are simply
> > > too valuable for refactoring. The lesson learnt is that even though we
> > > don't create our own generics, just as a compilation checking tool and
> > > its ability to facilitate refactoring for GWT, it is worth it.
> > > 4. Test the browsers. Don't assume everything will work in the same
> > > way. We did have to avoid some browser problems, like one time we were
> > > causing Opera to crash consistently over some HTML produced by MS
> > > Word. That is not a GWT issue, of course, it is an Opera issue (it
> > > should not crash when fed with that HTML), and our issue (we should
> > > not feed Opera HTML that it is going to choke on). And the other time,
> > > when we crashed IE with the PushButton widget; this is a GWT issue, as
> > > it should not crash IE, and it is IE's issue, as it should not crash,
> > > period. But compared to what we would have to handle hand-coding
> > > JavaScript, these are minor issues.
> > > The other thing is, if you have a lot of information to display, the
> > > browsers don't display them in the same way. For instance, Firefox
> > > would display information when it comes, IE would display only after
> > > all the information has arrived, etc. So, a progress widget is easy to
> > > code for Firefox, but much tougher for IE.
> > > Other thoughts
> > > ---------------------
> > > We are not usability experts, and we are not graphic designers either.
> > > But because of the interactivity allowed by JavaScript (via GWT), we
> > > wanted to build a system that is clean, and made the editing
> > > operations in-place, so that the user's attention does not have to
> > > switch to a new page, and then back, whenever they want to do
> > > something. Instead, they will look at the same widgets when
> > > information is displayed, and when they want to change the information
> > > being displayed. I think we accomplished that.
> > > For the site, we aimed to make the UI as clutter-free as possible, and
> > > make the different operations available as cleanly as possible. I
> > > think we succeeded in those two goals as well. But see for yourself,
> > > as the site is free for everyone. Obviously, we have just started, and
> > > we have not started to talk to companies and recruiters yet, so there
> > > are no job postings right now. But you can enter information, and see
> > > how the information is displayed, edited, etc.
> > > If you did try the site, please let us know what you think of it. We
> > > value your suggestions, criticisms, and comments very much.
> > > Obviously, whether the site is going to be successful really does not
> > > depend on what toolkit we used to code it.
We are also in the midst of a GWT production rollout and seeing
similar positives and negatives is comforting.
Anybody know if a compiler optimization is on the GWT guys roadmap?
Every time I see it brought up I hear the "Well, why aren't you using
hosted mode" or whatever line, but we also are starting to feel the
development time and build time squeeze.
Does anybody have any experiences with compile speed differences
between 1.4 and 1.5? We are seeing about a 15% slowdown, even with the
pruning of linkers and targets. For now it's okay to hand the build
over to our big honking CruiseControl machine, but, with a couple
dozen additional modules planned, and maybe translation into 3-4
languages, I'm worried GWT could end up being the majority of our
build process. Also, I'm dismayed to hear the performance difference
your seeing on Linux vs Windows. Our current build box is Win2003, but
we've had a plan to migrate over to CentOS. A performance regression
of that magnitude could cause us to reconsider. Has anyone else
experienced this?
Anyway, thanks again Khun for sharing your experiences. You shame
those of us that don't contribute our lessons learned back to the
community. (*cough* got to get off my butt and write one also *cough*)
ad #2: While you were using Hibernate, did you try using using
Hibernate Criteria API? That should allow you to do queries in Java,
and the would be changed during refactoring.
On Aug 1, 7:22 pm, Adam Malter <amal...@illegalcheese.com> wrote:
>Does anybody have any experiences with compile speed differences between 1.4 and 1.5?
Affirmative, 1.5 ~ 20% slower then 1.4, though we do not use 1.5 in
production yet, just made some investigation attempts.
> dozen additional modules planned, and maybe translation into 3-4
> languages, I'm worried GWT could end up being the majority of our
> build process.
Same to us ( http://www.triniforce.com/pk.html ). Slow compilation was
one of the reason why we decided not to use standart GWT i18n
approach. We keep dictionaries in database, it gives the following
obvious advantages:
1) Only one compilation
2) Customer is able to add/modify localization ( our app is
redistributable one ).
Of course this is for price of additional coding and debugging.
> Our current build box is Win2003, but we've had a plan to migrate over to CentOS. A performance regression of that magnitude could cause us to reconsider.
Perfomance difference indeed can take place, moreover I must admit
that moving between platforms is not quite seamless even if you use
Java. I spent one working day just making sources (~ 1200 classes ) to
be compilable on Linux.
For me, the build time is a concern only when I need to build the
whole system. That happens only when I modify the base class of the
RPC return type (so that I can have only one set of interfaces to
handle all modules, and 3 classes/interfaces per module because I need
a literal class name for the service class); and common elements used
by all the modules are modified[1].
For day-to-day compilation for development, I have Ant targets that
compile only one module, or a set of related modules. So, in general,
it takes me 1 to 2 minutes to compile the newly modified module. And
if only the server side has been modified, then, of course, it would
take about 15 seconds to compile the server side. And building for
production is again not an issue.
The common things that I do with the module compilation targets are
compiling the Java classes and the bundling of the war file. And I
keep the previously compiled modules intact. If their classes have not
been changed, I don't need to compile them again.
So, not really a problem in almost all cases. I tend to compile the
whole thing probably fewer than five times a day.
What baffled me was the speed difference between Windows and Linux. On
the other hand, I don't have enough machines to do benchmarks and no
inclination to find out why the difference between the operating
systems myself. I have the machines that I have; I will deal with
that. But it is intriguing to know whether it runs faster on Solaris,
as I expect JDK to be more optimized on that OS.
And of course, when I compile on Windows, GWT compiler takes more or
less 100% CPU. And the only activity I can have during compilation is
to read Groklaw and Slashdot. Hence the attempt to use my Linux
machines to compile (all my other machines are Linux machines).
Khun Yee
[1] It would be nice to be able to have multiple modules on the same
page. That would save some of the compilation time for modules with
common elements. I tried it on 1.4, and it did not work (alpha
substitution does not cross module boundary?). I have yet to try it on
1.5 Does it work on 1.5?
On Aug 1, 4:27 pm, Maxim <maxim...@gmail.com> wrote:
> On Aug 1, 7:22 pm, Adam Malter <amal...@illegalcheese.com> wrote:
> >Does anybody have any experiences with compile speed differences between 1.4 and 1.5?
> Affirmative, 1.5 ~ 20% slower then 1.4, though we do not use 1.5 in
> production yet, just made some investigation attempts.
> > dozen additional modules planned, and maybe translation into 3-4
> > languages, I'm worried GWT could end up being the majority of our
> > build process.
> Same to us (http://www.triniforce.com/pk.html). Slow compilation was
> one of the reason why we decided not to use standart GWT i18n
> approach. We keep dictionaries in database, it gives the following
> obvious advantages:
> 1) Only one compilation
> 2) Customer is able to add/modify localization ( our app is
> redistributable one ).
> Of course this is for price of additional coding and debugging.
> > Our current build box is Win2003, but we've had a plan to migrate over to CentOS. A performance regression of that magnitude could cause us to reconsider.
> Perfomance difference indeed can take place, moreover I must admit
> that moving between platforms is not quite seamless even if you use
> Java. I spent one working day just making sources (~ 1200 classes ) to
> be compilable on Linux.
To tell you the truth, I knew I was going to move away from Hibernate,
sooner or later. Nothing against Hibernate, I was just uneasy about
JPA in general, about my ability to use JPA effectively, and the
amount of time it would take me to tune it correctly. So, anything
that is not easy to move away from, I did not use.
I like Hibernate, especially since its caching (EHCache) and
connection pooling (c3p0) work. I have some issues with OpenJPA
caching and connection pooling. In any case, there is a huge
refactoring coming for me, if the traffic of the site gets to a
certain level. And it will have something to do with database access.
Just the nature of the beast.
Khun Yee
On Aug 1, 1:56 pm, Dale <Dale.Cooper...@gmail.com> wrote:
> ad #2: While you were using Hibernate, did you try using using
> Hibernate Criteria API? That should allow you to do queries in Java,
> and the would be changed during refactoring.
On Aug 2, 5:47 pm, Khun Yee Fung <khunyee.f...@gmail.com> wrote:
>So, in general, it takes me 1 to 2 minutes to compile the newly modified module.
You are right, if system is spited into dozen modules then in normal
circumstances compilation time it is not a problem. But if you have
fewer modules and you are fighting with browsers incompatibility - the
problem raises. Unfortunately appearance in hosted mode is not 100%
trusty ...
I used the hosted mode extensively in the beginning of my development
for my GWT projects. But once I started to have a database and
multiple modules, the hosted mode takes a while to start up (I am
eagerly awaiting the removal of @gwt.typeArgs support, that seems to
be the main reason with the long start-up time, or so I read/
listened). The refresh button seems to take longer to start up some of
my modules than simply re-run the module in many situations, and
sometimes it would not even come up properly. And I need to wire the
module correctly to add session support, by using a filter just for
the hosted mode (so I have two web.xml files, one for the real tomcat
server, and one for hosted mode). So, tons to do to get hosted mode
working for a module for me. But hey, my situation is just weird, and
I am totally happy to be able to debug at all in Java mode. I could
not imagine how much time I saved by using GWT just for that one thing
alone.
And you are also right in saying the appearance in hosted mode is not
the same as in the browsers themselves. But I don't use the hosted
mode to test/debug appearances and layouts. I tried testing the
appearances and layouts in the individual browsers.
Khun Yee
On Aug 2, 10:19 am, Maxim <maxim...@gmail.com> wrote:
> On Aug 2, 5:47 pm, Khun Yee Fung <khunyee.f...@gmail.com> wrote:
> >So, in general, it takes me 1 to 2 minutes to compile the newly modified module.
> You are right, if system is spited into dozen modules then in normal
> circumstances compilation time it is not a problem. But if you have
> fewer modules and you are fighting with browsers incompatibility - the
> problem raises. Unfortunately appearance in hosted mode is not 100%
> trusty ...
I've been looking at your site, and I'm sure a lot of hard work has gone into it. But there is room for improvement. Don't read on if you have a thin skin, I'm going to be honest.
No way to remember logon so you get timed out if you go to make a cup of coffee, you have to retype your email and password from scratch (autocomplete, autofill and remembering passwords are not catered for). It's only a job application system, it's not a bank account, you lose all the information you were typing in, and, more to the point, I'm the only person in the house, so who are you saving me from?
Top level menu items are reselectable
Top level menu items don't indicate selection
One of the top level menu items (policies) is different in appearance and in a different place in the layout.
Secondary level menu items block top level menu items and won't go away without a click somewhere on the page.
Headers are the same colour as menu items
Some selected buttons are the same colour as menu items
Some unselected buttons are identical to input labels
Text boxes and list boxes are identical to header lines
Many of the features are very cryptic ("Visibility J A C E" for example)
Tooltips sometimes hang around for ever and just won't go away
Tooltips cover one another and get stuck on-screen while blocking buttons.
Button mouse-over appearance a) appears when you go to a new page sometimes b) doesn't always get removed
Some titles are styled the same as some of the buttons
Some pages are not at all self explanatory, e.g. this page (in full)
------------------------------ INVITATIONS Invitations There are no invitations (c) Mivanti Systems Inc. 2008 ------------------------------
What are peoiple supposed to make of that?
Action buttons (e.g. Add Resume) are right over on the RH side of the screen while all information and the other buttons (apart from 'Help) are right over on the LH side
Location defaults to "AB Canada" i.e. you didn't bother to set up 'Please enter your...' list items.
Although there is a theme (i.e. there is one colour) there is still no standardised approach (e.g. some buttons have links, some don't some are blue, some are white and either way, they look like other elements on the page).
It is not obvious how to use the pages that appear
It is not easy to use even when you realise what you are supposed to do
Options are strange (why would a job applicant want to add a 'good to have' skill on a CV?)
Functionality is weird - you can save an unusable query for example, and you can try to use it. But if you do, you get something like "Please enter at least one location and one skill/technology" but there is no way to enter the skill, no indication how to do it (unless you happen to try clicking the blue, undecorated query name, and if you didn't enter a query name, there is absolutely no way to edit the query).
Compared to what can be done these days, it has a very 80's, very claustrophobic, bent-coathanger-string-and-glue feel about it. E.g. in preferences, click to edit password (you get shown three textboxes), then click the top edit button (to edit preferences), and you get told "Concurrent editing - Something else is being edited." and disallowed to do it. Why? What's the problem?
Why do I have to enter a city to do a search? What if I'm willing to travel/relocate?
Why can't I limit my searches to, say I.T?
Why do I need to add my contact info before I can add a resumé?
Why do I have to write my resumé from scratch instead of being able to upload it?
What is the point of multiple resumés whn there is only ever one version of any of the sections allowed?
How does the one I wrote from scratch get integrated with the stuff I enter in the data entry pages?
Because you use different module, you lose (without warning) anything you are entering if you navigate away within your site.
There are other things, but I'll leave it at that - I never managed to find a job, so I didn''t get any further than this, and I didn't look at the employer side.
All in all, it looks naff, it's difficult (sometimes impossible) to understand how to do what you want to do, and the way of doing it could be improved.
Now I know that is *really* harsh, but if your site is going to be a success, you just *have* to get a better look, a consistent interface, test the thing, and above all, make it easy to use.
Oh, don't worry, I don't have a thick skin, but I can take criticisms.
I learnt that from writing a book (I have not checked lately, but you
might still find my out-of-print book on Amazon) a few years back. The
comments from the anonymous reviewers during the publication process
were much harsher than you. Actually, the non-anonymous reviewers were
not very kind either. As long as the criticisms are constructive, I am
all ears.
Can't reply right away, as I need to digest what you said. However, I
thank you very much for the comments. And thanks for going through the
site.
Khun Yee
On Aug 2, 12:26 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> I've been looking at your site, and I'm sure a lot of hard work has gone
> into it. But there is room for improvement. Don't read on if you have a thin
> skin, I'm going to be honest.
> No way to remember logon so you get timed out if you go to make a cup of
> coffee, you have to retype your email and password from scratch
> (autocomplete, autofill and remembering passwords are not catered for). It's
> only a job application system, it's not a bank account, you lose all the
> information you were typing in, and, more to the point, I'm the only person
> in the house, so who are you saving me from?
> Top level menu items are reselectable
> Top level menu items don't indicate selection
> One of the top level menu items (policies) is different in appearance and in
> a different place in the layout.
> Secondary level menu items block top level menu items and won't go away
> without a click somewhere on the page.
> Headers are the same colour as menu items
> Some selected buttons are the same colour as menu items
> Some unselected buttons are identical to input labels
> Text boxes and list boxes are identical to header lines
> Many of the features are very cryptic ("Visibility J A C E" for example)
> Tooltips sometimes hang around for ever and just won't go away
> Tooltips cover one another and get stuck on-screen while blocking buttons.
> Button mouse-over appearance a) appears when you go to a new page sometimes
> b) doesn't always get removed
> Some titles are styled the same as some of the buttons
> Some pages are not at all self explanatory, e.g. this page (in full)
> ------------------------------
> INVITATIONS
> Invitations
> There are no invitations
> (c) Mivanti Systems Inc. 2008
> ------------------------------
> What are peoiple supposed to make of that?
> Action buttons (e.g. Add Resume) are right over on the RH side of the screen
> while all information and the other buttons (apart from 'Help) are right
> over on the LH side
> Location defaults to "AB Canada" i.e. you didn't bother to set up 'Please
> enter your...' list items.
> Although there is a theme (i.e. there is one colour) there is still no
> standardised approach (e.g. some buttons have links, some don't some are
> blue, some are white and either way, they look like other elements on the
> page).
> It is not obvious how to use the pages that appear
> It is not easy to use even when you realise what you are supposed to do
> Options are strange (why would a job applicant want to add a 'good to have'
> skill on a CV?)
> Functionality is weird - you can save an unusable query for example, and you
> can try to use it. But if you do, you get something like "Please enter at
> least one location and one skill/technology" but there is no way to enter
> the skill, no indication how to do it (unless you happen to try clicking the
> blue, undecorated query name, and if you didn't enter a query name, there is
> absolutely no way to edit the query).
> Compared to what can be done these days, it has a very 80's, very
> claustrophobic, bent-coathanger-string-and-glue feel about it. E.g. in
> preferences, click to edit password (you get shown three textboxes), then
> click the top edit button (to edit preferences), and you get told
> "Concurrent editing - Something else is being edited." and disallowed to do
> it. Why? What's the problem?
> Why do I have to enter a city to do a search? What if I'm willing to
> travel/relocate?
> Why can't I limit my searches to, say I.T?
> Why do I need to add my contact info before I can add a resumé?
> Why do I have to write my resumé from scratch instead of being able to
> upload it?
> What is the point of multiple resumés whn there is only ever one version of
> any of the sections allowed?
> How does the one I wrote from scratch get integrated with the stuff I enter
> in the data entry pages?
> Because you use different module, you lose (without warning) anything you
> are entering if you navigate away within your site.
> There are other things, but I'll leave it at that - I never managed to find
> a job, so I didn''t get any further than this, and I didn't look at the
> employer side.
> All in all, it looks naff, it's difficult (sometimes impossible) to
> understand how to do what you want to do, and the way of doing it could be
> improved.
> Now I know that is *really* harsh, but if your site is going to be a
> success, you just *have* to get a better look, a consistent interface, test
> the thing, and above all, make it easy to use.
There is a parameter in profile: Display timezone: EST5EDT.
Why do you use it in your application ? We keep all the "times" in
Java long datatype, as it is returned by currentTimeMillis(), so far
it's been enough ...
This might not be the case in their instance, but I'm keeping track of the user's timezone because the created on and last edited timestamps that come from the uploaded documents in my app have to be adjusted back to server time via the user's timezone settings. I'm using pytz on the server side Django code.
For timestamps created on the server, I can see where it doesn't really matter. But if you're handling dates from user-uploaded data (that comes from the metadata of the user's documents--a time that might not have any correlation to the uploaded time), I thought it best to keep track of the user's actual timezone.
> what I mean - we do not user timezone on server side, server always > keeps GMT time and time is always rendered by the client using browser > settings.
This may work fine as long as the client and the server are in the
same timezone. When that is not the case, there is a need to know what
timezone is in the user's intent on the client side.
For example, suppose your server is in Boston (UTC-5:00) and your
client is in Bucharest (UTC+2:00). Your application has something to
do with setting alarms that go off at particular times, and your
Romanian user wants one such alarm to trigger at 1330 on 04 August
2008 in Bucharest time (=0630 on 04 Aug 2008 in Boston). She chooses
this setting in the browser and clicks "Save" or whatever which causes
this setting to be persisted on your server. The scheduling software
(maybe something like OpenSymphony Quartz) runs on your server and it
needs to run the alarm at 6:30 in the morning.
How will it know this without knowing both what timezone it's in, and
what timezone the client/user meant to use?
Since java.util.Calendar and the timezone related classes are not
emulated yet (as of GWT 1.4), the only way to get this information
seems to be to ask the user herself to tell you what timezone she's
in, which is what Khun's application is possibly doing? Just a guess.
I am working on an application that has a need as I described above,
and for now it appears that the best we can do is ask the user to
select the timezone that they intend to set times in. It needn't be
terribly painful from a usability perspective, we'd do it once per
user and save it somewhere on the server so that every time the user
sends a timestamp, we know what offsets to compute etc.
Cheers
Ravi
On Aug 4, 1:33 am, Maxim <maxim...@gmail.com> wrote:
> what I mean - we do not user timezone on server side, server always
> keeps GMT time and time is always rendered by the client using browser
> settings.
On Aug 4, 10:12 am, Ravi M <mund...@gmail.com> wrote:
> For example, suppose your server is in Boston (UTC-5:00) and your
> client is in Bucharest (UTC+2:00). Your application has something to
> do with setting alarms that go off at particular times, and your
> Romanian user wants one such alarm to trigger at 1330 on 04 August
> 2008 in Bucharest time (=0630 on 04 Aug 2008 in Boston). She chooses
> this setting in the browser and clicks "Save" or whatever which causes
> this setting to be persisted on your server. The scheduling software
> (maybe something like OpenSymphony Quartz) runs on your server and it
> needs to run the alarm at 6:30 in the morning.
> How will it know this without knowing both what timezone it's in, and
> what timezone the client/user meant to use?
If user enters local datetime in local string form then you can get
UTC time using:
> We put our GWT-based job site (http://www.careercommons.com) in
> production on Monday. This is a summary of my experience coding the
> whole thing in GWT. Not sure how useful this is for other people, but
> here it goes:
> Some statistics:
> ------------------------
> 1. It has about 900 classes, including all the interface classes, data
> transfer classes, etc. Not a big system for a team, but not a small
> system for two people.
> 2. We have about 17 GWT modules, as one module would take too long to
> load for this kind of application, in our opinion. It takes about 18
> minutes to compile on my Windows machine, and 1 minute longer on my
> newer and much faster Linux machine, which baffles me no ends. Why is
> JDK faster on Windows? I am curious about the speed of compiling GWT
> on a Solaris machine now.
> 3. It took six months to code. It was mostly done by me, with a friend
> helping here and there. And it was my decision to use GWT. And I can
> honestly say that without GWT, it would have taken a lot longer than 6
> months, and the result would be much worse.
> 4. We use OpenOffice as the backend to generate Microsoft Word and PDF
> documents. So, we have to create ODT documents on the fly. We have to
> convert some data from HTML entered by the user into the RichTextArea
> widget. The HTML to ODT capability is quite limited right now, but
> will be improved as time goes on.
> 5. We use Tomcat 6.0.16 on the server side. As a production system, it
> has its problems. But after using Tomcat for the last 8 years, we sort
> of know what to expect and what to avoid.
> 6. We use postgres 8.3.3. as the database. In our pre-production
> period, we were patching the database from deployment to deployment to
> figure out the character of the system (every system reacts
> differently in production, and we wanted to learn that character
> before putting the system in production), and PLPerl is really good in
> handling data migration on the fly. Underpowered (try passing arrays
> in as parameters), that is for sure, but easy to handle.
> Lessons learnt
> ------------------------
> Now, these are lessons learnt by me coding this application. They
> might not apply to your situations. And they are really common sense.
> If you don't agree with them, I am all ears.
> 1. Can't reuse data transfer classes. Initially, we had general
> purpose data transfer classes between the database and the browser.
> Then we found out that we are transferring way too much information,
> and data security was getting scary. So, mid-way, we decided to have
> data-transfer classes that are tailored for particular remote methods.
> Both approaches have their disadvantages, of course, but I am happier
> now as I don't have to worry as much about data being leaked to the
> wrong side.
> 2. (Non-GWT) JPA is godsend in 90% of what we need to do with a
> database. For the other 10%, it is a drag. We use Hibernate first and
> then OpenJPA, the performance for some operations is still not good
> enough for me. JPA is doing too much sometimes (fetching stuff not
> needed), and too little in other times (not fetching stuff that is
> needed almost right away). But no system can read the programmer's
> mind, so I am extremely grateful to be able to use JPA for the 90%,
> and I have no problem coding by hand the other 10%. The only thing is
> that refactoring is made harder by JPA, as the queries are in
> strings.
> It would be nice to have a tool that allows programmers to code in
> Java for the queries, to make refactoring of the entity classes
> easier. But then that will need a GWT-like compiler to make it
> possible to write queries in Java, so that people can develop and
> debug in the Java mode, and then compiled into JDBC or JPA queries
> strings for a "production-mode". Sounds like an interesting project to
> me.
> 3. GWT 1.5 is easier to handle than GWT1.4. The system was in GWT1.4,
> and I moved it to GWT1.5 to anticipate the next version of GWT. But we
> could not stay with 1.4, as the generics and annotations are simply
> too valuable for refactoring. The lesson learnt is that even though we
> don't create our own generics, just as a compilation checking tool and
> its ability to facilitate refactoring for GWT, it is worth it.
> 4. Test the browsers. Don't assume everything will work in the same
> way. We did have to avoid some browser problems, like one time we were
> causing Opera to crash consistently over some HTML produced by MS
> Word. That is not a GWT issue, of course, it is an Opera issue (it
> should not crash when fed with that HTML), and our issue (we should
> not feed Opera HTML that it is going to choke on). And the other time,
> when we crashed IE with the PushButton widget; this is a GWT issue, as
> it should not crash IE, and it is IE's issue, as it should not crash,
> period. But compared to what we would have to handle hand-coding
> JavaScript, these are minor issues.
> The other thing is, if you have a lot of information to display, the
> browsers don't display them in the same way. For instance, Firefox
> would display information when it comes, IE would display only after
> all the information has arrived, etc. So, a progress widget is easy to
> code for Firefox, but much tougher for IE.
> Other thoughts
> ---------------------
> We are not usability experts, and we are not graphic designers either.
> But because of the interactivity allowed by JavaScript (via GWT), we
> wanted to build a system that is clean, and made the editing
> operations in-place, so that the user's attention does not have to
> switch to a new page, and then back, whenever they want to do
> something. Instead, they will look at the same widgets when
> information is displayed, and when they want to change the information
> being displayed. I think we accomplished that.
> For the site, we aimed to make the UI as clutter-free as possible, and
> make the different operations available as cleanly as possible. I
> think we succeeded in those two goals as well. But see for yourself,
> as the site is free for everyone. Obviously, we have just started, and
> we have not started to talk to companies and recruiters yet, so there
> are no job postings right now. But you can enter information, and see
> how the information is displayed, edited, etc.
> If you did try the site, please let us know what you think of it. We
> value your suggestions, criticisms, and comments very much.
> Obviously, whether the site is going to be successful really does not
> depend on what toolkit we used to code it.
What you say seems to make sense, Maxim. I had never taken a close
look at DateTimeFormat before, thanks for the tip. Aren't there
possibly a few corner cases where this approach might lead to errors?
It would be pretty rare, I suppose, but because of timing issues it
could be that you got the time on the client at say 13:59:59.500 (i.e.
a few milliseconds before the switch into the next hour) and so your
"hour" reading was 13. Suppose at the same time the server time is
07:59.59.500, so the real time difference is 13 minus 7 = 6 hours. Now
suppose that a second elapsed between the client sending the hour and
the server receiving it. Time on the server is now 08:00:00.500 and
the "hour" on the server is "8". The time difference is now computed
as 13 minus 8 = 5 hours which would be an error.
Is there a way to get around this, or am I missing something?
Thanks
Ravi
PS Apologies if this should be in a different thread/topic!
On Aug 4, 12:50 pm, Maxim <maxim...@gmail.com> wrote:
> On Aug 4, 10:12 am, Ravi M <mund...@gmail.com> wrote:
> > For example, suppose your server is in Boston (UTC-5:00) and your
> > client is in Bucharest (UTC+2:00). Your application has something to
> > do with setting alarms that go off at particular times, and your
> > Romanian user wants one such alarm to trigger at 1330 on 04 August
> > 2008 in Bucharest time (=0630 on 04 Aug 2008 in Boston). She chooses
> > this setting in the browser and clicks "Save" or whatever which causes
> > this setting to be persisted on your server. The scheduling software
> > (maybe something like OpenSymphony Quartz) runs on your server and it
> > needs to run the alarm at 6:30 in the morning.
> > How will it know this without knowing both what timezone it's in, and
> > what timezone the client/user meant to use?
> If user enters local datetime in local string form then you can get
> UTC time using:
> This code returns local clients hours, knowing server UTC hours you
> can do whatever you want, e.g. set value for "timezone" field in user
> profiler :)
> Now suppose that a second elapsed between the client sending the hour and
> the server receiving it. Time on the server is now 08:00:00.500 and
> the "hour" on the server is "8". The time difference is now computed
> as 13 minus 8 = 5 hours which would be an error.
> Is there a way to get around this, or am I missing something?
This particular problem can be solved sending timestamp with known UTC
hour from server to client and getting local hour on the client, this
way there is no gap.
But actually it is not enough just to have hour value - year and day
should also be compared to get the difference. I'm not sure that it is
most srtaightforward way though, may be there is more elegant
solution, kind of javascript function ...
|
