I attended two sessions Thursday and both were great. First I attended ‘Demystifying Spring Security in Grails’ by Burt Beckwith. Burt created a few applications with differing security styles using Spring Security. He is a really good presenter who has an obvious understanding of, and passion for, the Groovy/Grails ecosystem. He gave me several additional things to consider when writing applications that use Groovy and Grails.

My final session was ‘Design Patterns in Java and Groovy’ with Venkat Subramaniam. What a session. Venkat is such a great presenter that it’s hard to do him justice in a blog post. He really has a lot of fun and makes the audience have a lot of fun, too. Not only was it really entertaining, but the content was great, too. He spent the session time discussion many of our favorite Java patterns and how they would be implemented in Groovy. It was really nice to see how the code was reduced a significant amount into really concise, expressive statements. I would recommend this session to anyone who has a chance to see it.

All in all, I am very pleased with SpringOne 2GX. It was a great conference. The speakers were great. The content was great. I look forward to attending again.

The first session I attended was ‘Extreme Web Productivity with Spring Roo’ with Stefan Schmidt. I am really interested in Roo. Stefan dived in to some of the web side functionality that Roo offers and I have to say it is pretty compelling.

The next session I attending was ‘RESTing Easy with Grails’ with Andrew Glover. This was a really good session. I liked seeing how Andrew’s take on REST with grails contrasted with his partner at Thirstyhead, Scott Davis.

I then attended ‘Advanced Gorm’ by Burt Beckwith. Wow. What an eye opener. Burt showed how very simple ‘tutorial following’ style of development can get you into some trouble if you don’t understand whats happening under the covers. I took away a few things that I’m going to checkout when I get back to the office to make sure we are doing the best way.

My final two sessions were about plug in development with Graeme Rocher. These were just what I needed to fill a gap I thought existed in Grails – reuse. I knew about the plugin ecosystem, but hadn’t equated it with high level reuse scenarios inside of our company. He explained in detail how plugins work and went on to demo creating a couple of twitter plugins. It was a great session.

Today is the last day and I have a few sessions lined up.

My first session of the day was ‘Clustering a Grails Application for Scalability and Availability’ by Burt Beckwith. This was a good session. It was geared towards Tomcat and MySQL which we are not using, but I still managed to get some good nuggets of information that will, no doubt, prove useful in our Grails endeavors.

My next session was ‘RESTful Grails’ with Scott Davis. I’ve seen several of Scott’s presentations and he never disappoints. He is an energetic and entertaining presenter who is really dynamic and has a great passion for the topics on which he speaks. He laid out some really great stats on RESTful APIs at Google, Amazon, and ebay that really speak to how REST is taking over. I’ll leave it to him to detail the stats.

Lunch was great. NFJS has some killer meals and today was no exception. We had some good lunch conversations with others who seemed to work for organizations very similar to the one we work for. I’ve found that most of the people I’ve talked to work for organizations in really similar Spring/Groovy/Grails adoption modes to ours. It’s nice to know we’re not alone in our discovery and struggles.

After lunch I hit the ‘Whats new in SpringSource Tool Suite’ session. This was a good session. The speaker, Christian Dupuis, talked a lot about STS’s integration with Spring 3.0 and the capabilities STS will have as far as code completion and validation.

After much anticipation I got introduced to Spring Roo in the ‘Introducing Spring Roo: Extreme Productivity in 10 Minutes’ session by Ben Alex. He did a great job giving a high level overview of Spring Roo and setting up the follow up session that will give a more in-depth view of Spring Roo. I have to say that Spring Roo is impressive. I like the loose parallels with Grails without the runtime penalties (although I’m a Grails guy). He explained how it makes sense how they both fit in the landscape without really competing. I can say that I will definitely look to use Roo on future projects where we can’t/don’t use Grails. I’ll be doing some playing around with Roo over the next few weeks.

The last session I attended today was ‘Grails for the Enterprise’ by Robert Fischer. This was billed as an introduction to Grails, which I didn’t need, but I went anyways. And I’m glad I did. Robert gave an overview of the case for Grails with some emphasis on the parts/plugins he knew well because he had either created or contributed to them. When the open questions part of the session came, Robert did a 5 minute demo on creating a plugin that, if there wasn’t already enough reason, made the whole session worthwhile for me. It was a great session for me… the kind where you get an answer to a question or two that almost makes the cost of attending the conference worth it.

After all of the sessions, dinner was served and a keynote ensued. After the keynote speech, another reception took place where I got to mingle with some more good folks.

It was definitely a great conference day. I’m looking forward to tomorrow.

Rod talked about the @Configuration annotation in Spring 3.0 that I think is awesome. Basically we can use annotations to specify a configuration class that can also use normal injection to load its dependencies and properties. Should make for much more flexible Spring config and less XML Hell.

Rod introduced Spring Integration and Blaze DS (Spring/Flex integration) and had a few SpringSource guys do a demo. It went over pretty well.

Graeme Rocher took the stage to talk about Grails. This was my favorite part. Graeme did a demo of the Grails support in the upcoming (Wednesday) STS release which showed some awesome Grails integration. I will definitely find out about debugger support while I’m here as that is my big Grails hangup right now. He also mentioned Intellij Community Edition, which I had no ‘idea’ about. I will definitely be checking into it. He also talked about the Grails community… high points being that there are over 300 plugins. He joked with an Apple-like “…there’s a plugin for that”.

Rod made an announcement about SpringSource TC Server Developer Edition which is 100% Tomcat, is Spring aware, and offers the Spring insight dashboard.

We were then treated to some STS integration with tools that have evolved from the Hyperic acquisition. They offer awesome looking performance evaluation capabilities. They are hoping to be available by year end.

Finally Rod talked about the VMWare acquisition. Obviously he thinks and hopes it leads to greater things for Spring, Groovy, and Grails in the future, in particular to cloud computing.

All in all, I am really excited to attend the sessions I have chosen so far and am looking forward to being immersed in the Spring and 2GX universe for the next 3 days.

First, I really wish I could have gone to a session by Venkat Subramanian. He was one of the speakers I looked forward to seeing the most. But for one reason or another, each time he was doing a session I had enough reason to go to another session. Luckily my manager attended one of his sessions and gave me the details. My manager felt that it was a great session and agreed that Venkat is a fabulous speaker. He said he was laughing out loud at one point about a joke Venkat made that got a point across perfectly.

Second, Im super happy to have gone to all of Neal Ford’s sessions. The guy is a quote machine. He so clearly conveys his points that it is no wonder he is held in such high opinion in the industry. I also had a good chat with him about some ideas I had for our organization to adapt Use Cases to User Stories.

Third, I have a new interest in Fitness testing and Behavior-Driven Design. Thanks to Andrew Glover for his time after the session, I see a huge potential for BDD to grow into something big for design and testing over the next couple of year. I think its a little ways out, though.

Fourth… Continuous Integration is simply a must. I have skirted implementing it because, frankly, I was a consultant that dealt more on the integration side than the development side for so long that it didn’t seem to fit. Now as the lead technical person in a software development unit it is obvious that I can’t just talk about it anymore and actually need to make it happen no matter how much work it takes (Thanks to Jared Richardson for teaching me about technical debt).

Fifth and finally, attending conferences as good as this will empassion anyone with even the slightest interest in doing software development the ‘right way’ to go the agile route. I would recommend this conference highly to anyone. I have also have a new found interest in the other ‘No fluff just stuff’ conferences and really hope to get the rest of my team members to attend one soon.

Scott Davis delivered on refactoring to testability and mocking. A couple of topics I hold near and dear to my heart, but still wanted to see them presented by someone who can do it right.
I got to have a conversation with Neal Ford about some agile adoption strategies I have been contemplating. He gave me some good ideas so I’m excited to give them a try.

All in all it was a great day.

More to come when I get some rest in…

All in all it was a good day. I attended 5 sessions and had some great conversations in between. There was only one session I wish I would have opted out of. It wasn’t really bad, but it wasn’t really about the kind of thing I was looking for. In the interest of not griping, I’ll keep that one to myself.

I attended 3 sessions by Neal Ford, the Meme Wrangler (‘Real World Agile’, ‘Pragmatic XP’, and ‘Test Driven Design’). I have to be honest… I have listened to several podcasts in which he was a participant, watched a video or two that he was in, and read many of his blog posts. I liked them all and had high expectations. He delivered. As I’ve said in previous blog posts, I’m not easily enamored with ‘experts’. But he gets his ideas across in a very clear and concise way. He’s doesn’t come across as preaching and he lays out his arguments very well. I would not hesitate to recommend him to anyone who wants to learn about topics like SD agility, dynamic languages, and his ‘polyglot’ programmer topics.

I was also very interested in the ‘Real World Test Driven Design’ session by Scott Davis.

It was a good session, but unfortunately for my rating of it, I had just attended Neal Ford’s ‘Test Driven Design’ session. It’s not that Scott Davis’s session was bad at all… it was just a lot of the same info. I would have no problem recommending it to anyone.

I got a lot of good info from all of the sessions today. I’m already sold on the NFJS conferences. There is something awesome about not having corporate sponsorship at a dev conference. No vendors trying to shove a product down your throat hidden in a free T-shirt, no sessions that end up being a 45 minute sales pitch. Its a great concept.

I plan on more blogging on the sessions, but I’m not going to spew the notes on them. Most of the speakers have the session slides publicly available on their websites so I’ll just link to them.

Until tomorrow….

Hope to see you there. If you see me, say hi!

Cue dreamy effect and go back in time…

About 3 years ago, we bought a product as the basis for our learning management system. The learning system coordinator didn’t want the users accessing it directly (having to learn a whole new UI) so we wrote a few custom portlets to browse the catalog and track your progress using the APIs of the product. The APIs seemed kinda clunky, but they worked.

Fast forward back to this morning

After trying all of our known ‘fixes’ to take care of the problem without success I had to dig. I found some funniness in the logs. Our app was getting a java.rmi.RemoteException from the web service when trying to execute the API calls. Basically the error message was zero help. We had made no changes to the code. We had not updated the product in any way. So why is this happening? We determined is was definitely an API issue only – we could use the out of the box client and do all functions just fine. We called in a support ticket to the vendor. Luckily, they could tell us that the exception we were seeing would only be thrown in a scenario where we were providing either a null value or a zero length string as a parameter to the API method call. I knew that we hadn’t changed any of the code or the product for a looooong time so I was confident that we would prove to the support tech that she was wrong and we were sending in a value so I added some logging statements to the app and redeployed it.

Shock and dismay

Immediately, the logs proved that we were sending in a null value.

“What the #$%!! This has worked for 6 months with no changes. The only thing we did was change the logging level 2 days ago from DEBUG to ERROR and that should have no affect on this kind of thing. Its worked since then… right?”

Never trust other people

Just to be sure, I checked with the originator of the error (the guy who gets the calls when something is wrong or a change is needed – and a good all around guy):

Me: “Hey… this has been working OK since Monday, right?”.

Him: “Yeah. It was fine yesterday”.

…another 15 minutes pass trying to figure out how it could have ever worked since we’re passing a null value as a parameter.

Finally I came out of my funk and decided I just had to fix it with what I know now rather than trying to figure out what changed.

The realization – Not crazy, just stupid

As I looked into what the problem was, I found that a value for an attribute that we get from calling a utility library was null rather than a value pertaining to the logged in user. “How could this be null? Its been working forever!”. I seriously thought logic was not prevailing, that something had gone awry in not one, but three servers and was conspiring to make me insane. After another 5 minutes, I found that there was a VERY KEY line of code inside of an if block where the condition was ‘logger.isDebugEnabled’. So changing the log level from DEBUG to ERROR caused a major issue in the program since it skipped that key line of code.

Uhhhhhh

Immediately I tried to understand why it took me so long to figure out the problem. I reckoned if I’d have known right after the change that something was wrong I could have easily tracked it to the logging issue (and still kicked myself in the arse for such a silly bug). But since I heard from someone that it just broke ‘this morning’ I went on a wild goose chase.

This bug, had ‘slept’ for nearly 3 years without notice since the logging level was left at DEBUG on the QA and production servers.

Lessons learned

- Test with your production logging level
- Systems that aren’t mission critical can have an issue for a good long time before someone actually complains about it
- Dont trust what anyone else says when it comes to observation of a software problem (This is why when you call support for any product you start at step 1, even though you are a seasoned computer person and dont need to get instructions on what alt-ctrl-delete means – apparently they’ve already learned the lesson I learned AGAIN today)
- Accept that some bugs are just plain silly and no matter how experienced you are, you can create them.