June 22, 2006

Running a GWT Servlet on a $6.99 Godaddy Account

I had some trouble yesterday getting this done. Here's what happened:

  1. I installed the jar files, both my jar file and gwt-user in /WEB-INF/lib through ftp. However tomcat loads these jar files when the server is restarted daily at 1am. This is a bit too long to wait for updates. The server does load class files immediatly. So I extracted both jars to /WEB-INF/classes.
  2. There was no need to play with a web.xml file. You can access your servlet at http://www.domainname.com/servlet/servletname, (replace domainname and servletname, not servlet).
  3. Running an HTTP GET on the servlet worked. So I ran GWT generated javascript to access the server. The RPC call failed. Debugging the javascript showed that it was a 500 Internal server error: Check the server logs for details.
  4. Checking the server logs revealed nothing. I Called godaddy a couple times, (thank god for free long distance on skype). They didn't know why the error didn't show up in the logs and the guy I spoke with the second time didn't know what a servlet was.
  5. I dug into the GWT source. The RemoteServiceServlet catchs all exceptions in the doPost method and passes them to the respondWithFailure method which adds the exception message to the tomcat log and returns the generic 500 internal error. I modified the source to return the exception and the stack.
  6. The exception was a java security restriction on java.lang.reflect and happened in ServerSerializationStream.serializeClass. In this method objects are serialized and each field is set to be accessible, that is if they are private fields they become accessible for serialization. This is what you can't do on godaddy's tomcat. The code is written such that every field's accessibility is changed whether its private or not.
  7. Changing the code so that it only sets the accessibility when the field is not accessible allows applications to get by with serializing classes with only public fields when on servers with this type of security restriction. Also, if you only serialized simple types, String, int etc. you most likely won't have this problem, although I haven't tested this.
Filed under: ajax, google, java, gwt, google web toolkit, tomcat, godaddy
June 21, 2006

gpokr moves to a better neighborhood

It's not easy getting out of the ghetto. Today gpokr is moving on up, off my home machine to a hosted account for $6.99/month.

It didn't work for a while but after digging fairly deap there were security restrictions and the GWT source had to be modified and recompiled for the hosting to work.

Filed under: google, java, poker, gwt, google web toolkit, texas holdem, tomcat
June 20, 2006

Poker in the Ghetto

Where did gpokr go today? The answer is a string of unlikely events:

  1. The gpokr server is running on my home machine because its a java servlet running on tomcat and I don't have any web server access with tomcat.
  2. Rogers, providing good home internet service, changed my IP address after years with the same one. Causing my dynamic domain redirection service no-ip to point to the wrong place.
  3. The point of dynamic redirection services are to update the ip address for a domain dynamically when it changes. But not today. Upon logging to to my no-ip account I see this message:

    2006/06/20, 09:17 AM : Updating hosts for Free and Enhanced services is temporarily disabled due to a small outage. It should be available again in the next few minutes. There is no need to resubmit your updates, they will go through as soon as this is rectified.

    A few minutes turned into several hours.

Its back up but the situation is so ghetto. Lets get gpokr out of the ghetto. Please recommend a good tomcat host. 

Filed under: Uncategorized, java, poker, gwt, google web toolkit, texas holdem, tomcat
June 19, 2006

New version of gpokr

I uploaded a new version of gpokr today with some bug fixes. Check it out…

gpokr.com

Filed under: ajax, java, poker, gwt, google web toolkit, texas holdem
June 16, 2006

Google Web Toolkit + Texas Holdem Poker = gpokr.com

I work pretty hard most of the time. Sometimes I play poker instead. Sometimes I work and play poker at the same time.

www.gpokr.com is a test of the google web toolkit. It is written completely in java. The interface is compiled down to javascript so it will work in most browsers. The backend is a java servlet running red hat on a virtual machine on my xp box. I know, ghetto. Play a hand. The demo is in alpha so it may break while I'm away, have patience and come back to check out its progress.

Filed under: ajax, google, java, poker, gwt, google web toolkit, texas holdem
June 4, 2006

Buy My Tomatoes

There's lots of great development tools coming out and a lot of interest in building services for people. There is also the "build it and they will come" mentality everywhere.

More often than not it doesn't seem to work. Fold.com has recently closed its doors because it couldn't keep up with competion. Micheal Arrington's comment on fold.com's closing has a good point about building applications:

"Well, the inevitable is starting to happen - a few new web startups are starting to close up shop as they find that building an application is a lot easier than getting users to try it out, and keep coming back" - Micheal Arrington

Innovation in development tools and techniques has a value ceiling. I had a discussion on Joshua Wehners blog this week about the excitement behind Ruby on Rails and why people should not be so excited. Micheal Arringtons point clarifies this again. Technology can get very good, allowing you to make better apps, but everyone is going to be making better apps. There are a lot of areas beyond the tool that you use that you could use to differentiate yourself from the competition to attract people and retain members.

 I've been playing around with different techniques over the  last month. On whirlpad.com, a free travel blogging service I built earlier this year, I introduced a Travel IQ test called the TQ test. It measures your travel knowledge by having you match photos of toilets from around the world to their location. With a bit of seeding this test consistently brings 1000 uniques per day. This is quite a bit more than the homepage of whirlpad.com.

The interesting thing here is that the bottleneck to creating more tests, and getting more traffic is not the technology, RoR or LAMP. They really don't matter. The important work is in the creative effort to develop the test. The travel blogging service, however, has a lot more development work than marking/PR/people-attracting work. 

Being a good developer and usuing the greatest newest technology is not enough anymore. Besides, that type of work can be easily outsourced. Just because its easy for me to grow tomatoes in my backyard doesn't mean I should start a business around it.

Filed under: Uncategorized, LAMP, Ruby on Rails, Rails, RoR, marketing, pr, seo, startup