I was both happy and sad that this would be the final day: Happy because I would actually get a chance to digest some of what had already been thrown at me thus far, but sad because there was so much more I knew I could learn from some of the guys giving these talks. All of them were incredibly smart and really knew their stuff...it's hard not to want to be around these kinds of people.
Gettin' Googly
First up on my list were the two consecutive sessions on the Google Web Toolkit (GWT). The sessions were headed up by David Geary, who had given the JSF talk I sat in on the previous day.
Prior to stepping into the first session, I knew what the GWT was, but had very little knowledge beyond that. For instance, I knew that it was a toolkit that allowed developers to write AJAX applications in Java, and I also knew that the Java code you wrote looked like Swing, since the goal was to create RIAs that had desktop GUI-like properties. I also knew there was some sort of compiler/translator involved in there somewhere that turned the Java code into JavaScript. Beyond those basic features I had little knowledge of the toolkit.
My biggest problem when I first heard about the GWT is that, quite frankly, I thought the entire idea sucked. For one thing, I've been working with Swing for almost 10 years now and I can't stand it. Using Swing to create AJAX code just didn't excite me that much, so I never really made an attempt to delve further into using GWT. Also the whole Java-to-JavaScript translation just didn't sit too well with me for some reason either, but I can't say for sure why that was the case.
Well...after sitting in on these two sessions, I can say with certainty that I was completely sold on the Google Web Toolkit.
First off, the fact that the GWT used a Java-to-JavaScript compiler turns out to be a huge benefit to developers. As David explained during his talk, there's no need to worry about custom-coding JavaScript to support multiple browsers, since the GWT's compiler generates code that will support all the various browser idiosyncrasies for you, saving you loads of time and avoiding the potential errors that trying to roll your own JavaScript solution would typically entail. I totally missed this point when I first learned about the GWT...silly me.
The second is that, while the code does in fact look a lot like Swing, it's not actually Swing. As was explained during the talk, the Java code really only acts as a thin wrapper around the underlying DOM, providing a much simpler way to work with the page. Yes, there are the standard listeners and events and whatnot that you'd expect had you been writing regular Swing code, but it appears to be a much more slimmed down version of Swing programming. It also doesn't prohibit you from working with existing JavaScript frameworks, as there are ways to integrate those within the Java code you write.
Another part of the Swing stuff is that...quite frankly...writing your AJAX applications using Java and Swing, rather than just the usual straight JavaScript is actually a lot easier to do. Anyone that's worked with JavaScript knows how much of a pain in the ass it can be, and despite my own massive amounts of disgust from working with Swing all these years, I realized after attending these sessions that I'd much rather be able to write my AJAX apps using something like Swing than plain JavaScript. The GWT provides a nice mechanism for this, and makes creating something like a RIA significantly easier.
Asynchronous calls are handled pretty easily, and they seem to map really well to the Java language in the way that the GWT offers. It's pretty easy to set up a call, and provide a listener for the response.
The other really mind-blowing thing about this toolkit is that it has full support for debugging your GWT code...even after you've compiled your Java code into JavaScript. David gave a demonstration of this by actually setting breakpoints in some GWT-based Java code and stepping through each line in the Java code in his IDE as the application was running on a deployed web server and had been compiled to JavaScript. This was JavaScript running in the browser, and the IDE was stepping through the Java code that it was generated from. This was a really cool feature to see in action.
This actually tackles a problem that I hadn't totally thought about when David was first talking about the GWT: Debugging JavaScript isn't terribly difficult with something like FireBug to work with, but after you compile your GWT Java code into JavaScript you'll likely lose track of which parts of your Java code are associated with what in the JavaScript. This would normally make debugging a GWT app a nightmare unless you have some way to link the two after after you've compiled the Java into JavaScript for deployment. Google has provided a very nice way to deal with this problem and the value of this feature cannot be understated.
I think web developers working in Java already can benefit the most from this toolkit, especially if they are looking to inject some kind of AJAX-style features in their web applications. Being able to keep all (or most) of your code on both the server and client as Java, and still be able to leverage AJAX is a huge benefit to a project. This is obviously where the GWT is targeted, but I got the impression from a lot of people sitting in on these sessions that they weren't really expecting GWT to be as full-features and powerful as it is, which makes me think that it's a seriously misunderstood technology.
Google should be doing a better job promoting the GWT, as I think it's a pretty significant leap in AJAX development for Java developers.
I was extremely impressed with the GWT following the these two sessions David Geary.
More Groovy
For the next talk, I decided to sit in on another Groovy session. This time, it was Jeff Brown giving a talk on Groovy's metaprogramming capabilities. Jeff had sat in on the Birds of a Feather session at the end of the previous day's festivities, and after hearing what he had to say there I thought it would be worth it to hear more of his thoughts about Groovy.
Scott Davis had covered some of Groovy's metaprogramming capabilities back on the first day of the conference, so I had a basic understanding of some of what Groovy could do in this regard. Jeff, however, when into significantly more detail in how to work with Groovy's metaprogramming features, and provided a great number of examples on how these capabilities could be leveraged in a real project.
Starting with the Expando class, Jeff went on to cover things like Closure delegates, and the ExpandoMetaClass, which is used to dynamically add behavior to the existing core Java classes.
Jeff also covered the implementation of builders for various uses -- a builder to easily construct XML based on Groovy code, for example.
One example he showed that resonated with me was the SwingBuilder. This builder class made constructing GUI widgets in Swing significantly easier, and has made me consider adopting this for my current project (provided I can make a good case for it...and maybe get a proof of concept going). Working with SwingBuilder appeared to be significantly easier than anything I've seen anyone try to implement, and I'm all for making my code simpler. Groovy really shines at this, for sure.
Jeff also covered ways that the dynamic method dispatch in Groovy can be leveraged to make more meaningful queries to a database. For example, by being able to call methods like
.findByKey("foo") directly on a class when those methods don't actually exist until runtime, and are dynamically generated based on the name of the method itself. There is some really powerful concepts here that can make a lot of Java projects easier to work with, and this is really where I started to see Groovy's capabilities shine.Between this talk and the two previous ones, I've been pretty well convinced that Groovy has a lot of potential, and I look forward to trying out some of these features for myself.
Black Hats
For the final session of the day, I attended another talk by Ken Sipe. This time he talked about Hacking...as in the breaking-into-phishing-scamming-doing-bad-things kind.
Once again this was more of a overview, and sadly there were some technical difficulties during this talk that prevented Ken from really being able to demonstrate some of the things that he was talking about (seems the internet connection for the conference was cut off prematurely). Nevertheless, it was a fun and informative talk, and what things Ken could show us were fascinating.
Ken gave lots of good bits of information during this talk. And while I'm not going to iterate everything he was talking about here, for obvious reasons (if you're smart you can probably figure them out yourself), one thing I took away from this talk was this:
We're all incredibly naive about security.
I think I finally understand why Bruce Schneier changed his point-of-view about security from that of a purely technological solution, to that of a psychological/sociological problem that cannot be easily fixed. Far too many people out there either just don't understand, refuse to acknowledge, or are overconfident in their security measures when it comes to software development. And there is definitely not enough critical analysis going on that there really should be.
The End
And with the end of this last session came the end of my time at the conference. I had a blast attending all of these talks, and learned so much in such a short time that I'm going to be spending months evaluation all of the options that have been opened up before me. I'm amazed at home much I picked up here, and I'm looking forward to attending this again next year.
Hell...I may actually try to pay my own way if I have to...
No comments:
Post a Comment