CAT | No Fluff Just Stuff
Whew this session was a tough one for me to decide on what to go to. As I had previously mentioned, Ted Neward was giving a presentation on Scala this session. Jeff Brown had a session on using Groovy for builds. Nathaniel Schutta is presenting part two of Designing for Ajax, which would cover “advanced ajax” concepts including offline Ajax apps with Google Gears.
When it came down to it, I had to flip a coin to decide whether to go to a session on Scala or a session on Ajax… and Designing for Ajax won. Luckily I did convince a few friends to attend the Scala session though, so at least I played a small part in accelerate it’s exposure.
A lot of the session was dojo/prototype based, but very pleasing. Demos were given for achieving “in-place editing“, using Lightbox, and others. Google Gears was also covered briefly using the dojo offline toolkit… although I wish I could have seen a little more of it, but only because I have only scratched the surface of Googe Gears already and wanted to see more.
What Made Me Smile
A lot of developers these days, and even many book authors, will cop out and focus on programmatic aspects and ignore good, structural html… often opting to leave a bunch of crap invalid html on the page and passing a bad practice on to others. Nathaniel’s html was very structurally clean and made sense, using label tags for labels (with
for attributes). People learning from his examples will possibly construct better html too.
What I Got Out Of It
As an aside, I’m amused that all of Ted Neward’s sessions begin with “The Busy Java Developers Guide To…”, I guess that’s because us Java developers are always busy since we over-complicate everything.
Anyhow, the session started with Ted’s usual wit and humor, and then moved on to exploring the tools available for hacking the JDK. The first one delved into? JConsole. I had previously gotten a glimpse of JConsole at Ken Sipe’s session on Spring and JMX to manage and view MBeans… here I got to see in depth all of the possibilities JConsole provides… how did I miss it? Had I been sleeping the past couple years (the short answer to that is yes)?
Did you know you can grab a snapshot of the java heap? Change runtime configuration while the application is running? It’s almost scary when you think of all the possibilities and extremes you could go to with it. It’s really cool that you can use OQL to query the heap for different objects and get all kinds of information on their state at the time the snapshot was taken.
Unfortunately my laptop battery is about to die, so I’ll follow up this post later.
Michael started the presentation off with giving us a rundown of hosting/startup options throughout the years, breaking down the costs of each approach. He basically grouped them into four categories:
|Capital / Hosting||Labor||Lead Time||Break-even Revenue|
|Classic Hosting||$5 – 6M||$4 – 8M||12 – 18 months||$370K per month|
|Self-Service Hosting||$10,000/month||$3 – 4M||6 – 9 months||$370K per month|
|Virtual Private Server||$10,000/month||$100k – 1M||1 – 4 months||$33K per month|
|Cloud Computing||$1,000/month||$5 – 80K||1 day||$370K per month|
Right away he had something new that kind of blew my mind…. EC2. The idea was to harness the processing power available to you from cloud computing for your site and gave an example of how to quickly create your own server image.
With this done, he walked us through a very small GWT application and an associated ANT build script for it, then deployed it and we could even go view it at the provided url (I had this on here earlier, but removed the link since it was only up for the presentation). All up and working in 15 minutes. In only 10 more minutes he also setup Nagios .
I thought it was just really cool how fast you could get a site up and running and the amount of configurability that you had with EC2. You could install virtually anything on it and do anything… it was just like your own linux server. Also great was that you could take advantage of clustering with minimal hassle and fees. It just really blew my mind what you could do… my friends and myself just felt like getting out of there, getting an EC2 account, and start coding right away… it seems like Michael has that effect.
Today I decided to be a bit pickier with the sessions I attended. I was going to go to Scott Davis’ presentation on Real World JSON, but decided against it since I already use JSON extensively and know how to serve it up from the serverside (as well as tools to nicely serialize/unserialize domain objects as JSON). Ditto on Ted Neward’s presentation on annotations… we’ve been using them a bit for runtime level behavior. So I decided to attend Alex Miller‘s session on Design Patterns Reconsidered. Good choice.
Basically he covered four well known patterns: Singleton, Template Method, Visitor, and Proxy, looking at their pitfalls and possible ways to avoid those pitfalls. The first pattern explored was singleton.
Singleton in my opinion was a good pattern to start with… its the easiest and most widely used, which why its an easy target for abuse. The biggest problem? Singleton introduces a hidden coupling in the way it’s used. How am I supposed to test this class if it uses a Singleton somewhere that hits the database? ARGHHHHH!!!!!
The solution Alex presented was interesting… extract an interface from your Singleton and specify the user of the Singleton as a “Victim” and provide access to the Singleton via Dependency Injection using the interface. He tied this up by using Guice to show how effortless it can be. But his final comment on it? Just don’t use Singleton. Might have been a joke, but that’s something I agree with… 90% of the time when you use Singleton it’s only because you cant figure out a better way to get access to a resource throughout your application and you soon find yourself bitten by the choice of using it later.
I’ll post more on Template Method and Visitor later… but overall it was a very good presentation and drives the point that we really need to question how we use Design Patterns… we need to identify and get around the pitfalls that can arise when we use them.
Basically I went to this session since the last one from Ken Sipe was pretty good. As I came here though, I had no idea what the heck JMX is. Thankfully the first part of the presentation covered what JMX is, since of course you need to know what it is in order to even think about leveraging it in Spring.
So what is it? JMX was defined in JSR-3 (recognized need early and very mature) and defines monitoring services with notification services. It’s also a core part of JDK 5. There’s an evolution of JMX through multiple JSRs defining good things such as remote APIs, JVM monitoring and management, Deployment API, etc. There’s a lot out there on it… essentially JMX is just an API that provides gauges that allow you to just monitor all kinds of things going on your server/application.
Creating an MBean is pretty straightforward… create an interface that ends with “MBean” (However, with JMX 1.2 you don’t need to have the name end with MBean) that defines a set of methods for the publicly exposed API and a concrete implementation of the interface. Then you just register it with an MBean server (“just” … it can be slightly involved). The example given was a bean that reports number of active threads, free memory, and totaly memory. MBeans are commonly viewed from an administration console.
Types of MBeans:
- Dynamic MBeans
- Any MBean that is dynamic
- Model MBeans
- Extends ModelMBean interface, which extends the Dynamic MBean. It provides a generic template for managing resources and is very dynamic.
- Open MBeans
- Dynamic MBean which follows specific rules. These rules help promote interoperability.
The first half pretty much covered everything related to JMX and MBeans, but what I took away from it is you can use JMX to create monitoring services and notification services for your applications (Ken was able to setup SMS and Jabber notifications). This interests me… there was some weird and cryptic MBean menu in Cruise Control I had no idea what it was before. Now I know. And now I can do some very nifty stuff with it.
Where Does Spring Come In?
Spring takes away the pain of creating/registering MBeans. Although it’s hard for me to describe the difference, the first examples of “the old way” of creating/registering MBeans looked slightly complex and convoluted… the Spring way allows you to just any object (you don’t need an interface to implement) and make it an MBean as well as some “automatic” detection schemes.
Overall, nifty stuff. Uses? I might find use in this by writing some MBeans to allow me to get SMS messages when VERY bad things happen in my next JEE application.
Now this is a session that by just glancing at the title and the slides I know it’s going to be good. My co-worker Phil HATES Spring mainly because he hates XML files (at least from what I’ve noticed from his knee jerk reaction when he sees an XML configuration file). So, I’m ready to learn something about Spring 2.5!
The presentation has started off exceedingly good… Ken Sipe started the session by finding out what the need of the audience as he began the presentation. With a quick overview of the frustrations of Spring 2 (autowiring feeling too “magical”, long XML, required injections), what’s going away, and what started, Ken began moving towards the meat of the presentation: Annotations.
Spring 2.5 has a ot of annotation support, both for it’s own annotations as well as JSR-250 javax annotations, EJB annotations, and many more. Of interest is the
@Repository annotation, which indicates a class functions as a repository and proxies it, converting any checked exceptions to unchecked exceptions.
There’s a new pointcut for pointcuts in Spring 2.5 that allows pointcuts for beans as well as both vertical and horizontal stack selection (i.e. accountController -> accountService ->accountDAO). These are Spring only and not for AspectJ.
He abriefly covered the Stereotype annotations that indicate “class types.” These include
@Autowired is the first one mentioned… and for good reason. This annotation, as the name implies, implements autowiring of fields, constructors, setters, or config methods. There is also a lot of fine grained control over the autowiring. The
@Qualifier annotation both qualifies a bean for autowiring and also allows for customization.
@Required marks a method as being “injection required.”
What was noticible here was the
@Resource annotation, which is used for injecting named resources (must be the Spring name, not the JNDI name). It’s also a debated whether to use
@Autowired … it’s up to the teams.
Thankfully at this point Ken stepped back and pulled up a demo making use of these annotations… pretty nifty, and it was quite interesting to see how this all glues together in a simple easy to follow application. The nice thing was that although an xml file was there, it only had 3 entries in it (a comparable example with everything in his app in Spring 2.0 would easy be a few pages of XML). The coolest thing I saw here was the autowired method names could be changed and they still got injected perfectly fine.
Spring MVC has a lot of nice annotations for configuration/specifying input/output, but I’m not into Spring MVC much… maybe I’ll come back and cover it later. Looks solid though.
The reduction of XML was covered even further… such as using
<context:component-scan/> to include/exclude classes as beans. This was covered lighty… this just helps reduce the ammount of beans you need to define. You can also jsut move some properties out of XML…
<context:property-placeholder/> is useful here… you can just specify a property file, which simpler and more concise than XML).
Spring with NO XML
You can use Java based configuration. Just marking a class as
@Configurable allows you to just use the class for getting beans. Also, you can write your own parser that uses something besides XML to define configuration. This isn’t new though… its been around for Spring 2.0.
Auto-Discovery is where the meat is… you can set up a scanner that simply scans your packages and refreshes the context with the beans that currently exist. NIFTY!
All in all it was a very informative and fun presentation… I think I may attend the next session with the same presenter.
So, I chickened out of attending the Spring + JPA + Hibernate session… party because I know how to use it a little and partly due to the knowledge there would be strong pushback since we had previously used Hibernate at work. With that in mind, I decided to attend Developing Rich Internet Appications with Richard Monson Haefel.
The beginning was a little boring… but only because I wasn’t learning anything new… but I am sure it was interesting for those who were completely new to rich internet applications and wanted an overview of what was availble. I did learn one thing interesting though… JAWS, the java based screen reader for blind people has the capability to read applets and flash (specifically, Flex) applications. Something interesting to note when it comes to accessibility and section 508 compliance… although I still refrain from Flex due to the “plugin problem” … but it may be useful if developing a rich application that transcends the basic web technologies (video comes to mind).
A little interest was picked up midway when he introduced Silverlight and XUL. Silverlight has became interesting with Nokia’s announcement of supporting Silverlight on SymbianOS so it will definitely see some more market penetration in the future. I was very pleased he mentioned XUL… not too many people are aware of the application framework built into firefox. It seems like some have almost forgotten completely about XUL.
Curl was new to me… I had heard of curl before, as cURL. I almost hate the framework already for making me confused why a library for fetching content from remote URLs on linux is being presented as an RIA. But I’ll give it a look.
The presentation ended with a comparison of the different RIA available, the pros/cons and things to consider when choosing which is best for your application.
What I’d Like to Have Seen More Of?
I would have liked to see a lot more demos of “AJAX” toolkits…. I wanted to feel awed again like I did the first time I saw ExtJS or Script.aculo.us. I wanted to stand amazed at what was being shown to me. I didn’t get that feeling… for me it felt like 2005 all over again.
The first day of NFJS (especially the first sessions) is usually geared towards people who haven’t heard of these technologies… in fact there were a lot of people in the presentaton that asked lots of questions and probably got a lot out of it. For someone developing AJAX applications since 2004 it was kind of a poor choice (unless you took a prolonged break and didn’t know what is out there now).