Wed, 10 Oct 07
Posted in Java, Dynamic Languages, GWT, YUI at 4:52 pm by moore
After about a year of working with GWT, it seems to me like there are two places where it is really useful as a technology:
Quickly building relatively sophisticated user interfaces for entire web based applications. An intranet ‘client-server’ type application, like a timesheet, would be a perfect fit. If you use Java on the server side, domain objects can even be shared. Building small widgets that have anything beyond the simplest logic. This is the best way to integrate GWT into an existing application–add small bits of functionality that improve the user experience. You can use GWT to manage, reuse and package this logic.
However, what GWT is best for is not the limiting factor for GWT; rather, if you aren’t a Java developer, GWT just doesn’t make sense. (I’m ignoring the fact that if a user doesn’t have JavaScript enabled, GWT doesn’t make sense, since this is a failing of almost all the Web 2.0 rich user interface toolkits).
For me, being a Java developer and a fan of Eclipse, GWT is a natural fit for a number of reasons. The Java object serialization support, the use of an IDE to code Javascript, the JRE emulation, and the event driven user interface model all make it extremely comfortable to develop in the language. If you’re already coding the server side in Java, GWT is one less language to learn (until you need to do something that isn’t provided for in the emulation libraries, or you need to use a Java 1.5 feature, or a bug leaks up through the abstraction; of course, these problems will never happen).
While I don’t have deep knowledge with other toolkits (I’ve worked slightly with the Yahoo! User Inteface Library and have toyed with Dojo), it seems to me that many many folks can get by using them; there’s no tie to Java.
If someone was going to ask me whether or not they should use GWT, I’d boil it down to the following questions:
Are your developers familiar with Java? (If ‘no’, don’t use GWT.) Are your developers familiar with JavaScript? (If ‘yes’, consider not using GWT.) Are you integrating with an existing app? (If ‘yes’, GWT might be a good fit.) If so, are you planning to ‘web 2.0′-ify the existing application, or add widgets to enhance existing functionality? (If planning to ‘web 2.0′-ify existing functionality, don’t use GWT.)
On a final note, I don’t want to bag on GWT too much. GWT has improved tremendously over the past year or so, and I’m very glad to have used it. I think it’s quite cool tech, and I think it has really improved the user experience on my client’s site.
Thank you, Google, for releasing GWT and making it available for me to use.
Permalink
Thu, 13 Sep 07
Posted in Dynamic Languages, Web Applications at 9:51 am by moore
I recently was debugging the dreated “Operation Aborted” error, which was appearing in both IE6 and IE7. (Incidentally, Joel has written a great delineation of the three parts of software: design, development and debugging.) I usually do development in FF and then test in IE. But this bug is specific to IE, which made debugging harder. I was using IE6, looking at the error message and trying to find the line numbers it referenced. Pretty miserable. The fact that I was dealing with external code (Google Analytics, Google Website Optimizer) made it all the more fun!
I was testing at work, and feeling a bit frustrated. I found a reference to the Microsoft Script Debugger, but wasn’t able to find it separate from Microsoft Office.
I went home and tested on IE7, and saw the same error. I thought I’d try to find the debugger for IE7. It was easier than I thought–all you have to do is go to ‘Tools’, then ‘Internet Options…’, click the Advanced tab and uncheck ‘Disable Script Debugging (Internet Explorer)’. Then, when you visit a page with a javascript error, it asks you if you want to debug it. Fantastic!
As far as I know, that was a vanilla install of IE7. I’m thrilled they’re shipping a debugger, as it will make developing for them just a little bit easier.
Update: I was incorrect, I think that you need to install the script debugger separately. Link below.
Technorati Tags: ie7, javascript debugger
Permalink
Tue, 15 May 07
Posted in Java, Dynamic Languages, PHP at 11:10 pm by moore
Have you ever had a project written primarily in PHP, but there were some java systems that you wanted to connect to? Perhaps there was a third party library or a java API that you really want (or are required) to use, but PHP had been chosen for other reasons.
The php java bridge is your solution. The documentation is good, and the performance is pretty darn good (if you’re looking for benchmarks, search for ‘How fast is it?’). You can use the bridge over sockets, a xml based protocol via servlets, or over a mono application. The mailing list is active, and it looks like the primary developer actually answers questions on said list (as of May 2007).
I’ve always been a bit hesitant regarding cross language programming: “Great, now I get to debug in two languages that communicate via sockets! Yahoo!”. But for a certain set of circumstances, using this bridge can be the right answer.
Technorati Tags: php, java, cross-language programming, php java bridge
Permalink
Tue, 12 Sep 06
Posted in Books, Programming, Dynamic Languages, Google Maps at 8:04 pm by moore
Seven months ago, I wrote about Google Maps Gotchas. I mentioned Scott Davis’ Google Maps API Pragmatic Friday article, published by the Pragmatic Programmer folks. Well, a few things have happened since then. In April, Google released version two of their maps API (though they still haven’t set a date when version one will no longer be supported), Scott revised his article and I spent a tax deductible $8.50 to give it a read. What you’ll find below is my take on his article.
The good: first, the ordering was easy, and I received my custom PDF (complete with “Prepared Exclusively for Daniel Scott Moore” as a footer on every page) in less than 20 minutes. Scott explains in a very easy to understand fashion how to create a map. He also covers each of the API’s javascript objects and how to use them. In particular, I thought the list of events and objects that fire them (in the ‘Events’ chapter) was a good reference. Now, Google provides a class reference, but Scott’s are a bit easier to understand here’s a comparison, for the Gmarker class:
Google API:
A GMarker marks a position on the map. It implements the GOverlay interface andthus is added to the map using the GMap2.addOverlay() method.A marker object has a point, which is the geographical position where the marker is anchored on the map, and an icon. If the icon is not set in the constructor, the default icon G_DEFAULT_ICON is used.
After it is added to a map, the info window of that map can be opened through the marker. The marker object will fire mouse events and infowindow events.
Davis’ Book:
In the Core Objects section, we introduced the GLatLng. A GLatLng stores a Latitude / Longitude coordinate, but it doesn’t offer you a way to visualize it on a map. A GMarker is the way to add GLatLngs GMarker to the map for display purposes. The GMarker constructor takes a GLatLng as the only required argument.Once we have the marker, we need to tell the map to display it; map.addOverlay(myMarker) should do the trick. (Objects that you superimpose over the map are called Overlays.) You can remove the Overlays marker using map.removeOverlay(myMarker). To remove all overlays, use map.clearOverlays( ).
var myPoint = new GLatLng(38.898748, -77.037684);
var myMarker = new GMarker(myPoint);
map.addOverlay(myMarker);
Theoretically a map can support an unlimited number of markers, but anecdotal evidence suggests that performance starts to slow down significantly after a hundred or so markers. (File under, “Doc, it hurts when I do this.”)
I liked the real world examples–the fact that you could click through and see the code Scott was writing about in action on his website is a real plus. In addition, he builds a decently complex example in Chapter 7 where the user can add and delete cities. He also gives a good warning about examples that use Gmap, rather than Gmap2.
However, there were some issues. Scott’s coverage of the upgrade to version two of the API is, unfortunately, rather spotty. In his blog, the June release of that feature, and the April revision of the book). He also doesn’t cover GDownloadURL, a convenience method for XMLHttpRequest processing, or the GUnload methods. I’ll freely admit that the maps API is a moving target, and some of the omissions above may be due to that.
However, there are other problems. Though billed as a beginner book, he omits what I consider to be one of the fundamental challenges of Google Maps development–the performance obstacles large numbers of database driven markers (other than the comment mentioned above in the GMarker reference). In addition, he doesn’t cover design options, nor cross browser issues (like the transparent PNG in IE issue).
In the last chapter, he mentions good examples of mapping websites, but Scott omits references to useful websites–something that even dead tree books do. In particular, he doesn’t mention mapki.com (a wiki full of useful user provided data) nor the Google Maps group (which some users consider a primary differentiator between Google and Yahoo Maps).
One final gripe is that the 75 pages of content that I expected were really only 45–text only filled about 60% of the column width. I expect that in articles I read for free on the web, but in books that I pay for, I like a bit higher content to page ratio.
In short, this ebook is a good choice for the first time Google Maps builder. This is due to the tutorial nature of much of the book, the examples, and the explanation of typical good javascript code, such as using anonymous functions for the event handlers. It is not entirely adequate in covering version 2 of the API, possibly due to API changes, and it ignored some of the more complex aspects of the API.
If you’re looking for a folksy introduction to Google Maps api, it’s worth the $8.50 to have a coherent guide. If you’ve muddled through one google maps project, piecing together things from the API docs and various blogs, it becomes less worthwhile. But if you want some kind of discussion about complex Google Maps issues this document is not the right place to look.
Technorati Tags: Scott Davis, Google Maps, Pragmatic Fridays
Permalink
Fri, 08 Sep 06
Posted in Programming, Dynamic Languages, Databases at 10:18 am by moore
Here’s my new theory about scripting languages: everybody loves SQL (or, more likely, the data SQL makes accessible), so every scripting language evolves until it can access an RDBMS, whether it’s JavaScript, or Movable Type’s template language or server side includes.
(See also the history of SQL.)
Technorati Tags: SQL, javascript, scripting languages
Permalink
