I had the good fortune of attending eRubycon a few weekends ago and I can honestly say that I've never seen more value in a conference. My previous rant on how NFJS is letting the level of their speakers slip was only more evident in the 3 days spent at eRubycon. Neal Ford, Stu Halloway, Joe O'Brien, Jim Weirich, Charles Nutter and many others contributed valuable sessions that left me wishing the conference went on for a few more days.
The great thing about eRubycon was that it very rarely focused on what is typically the gateway drug in adopting Ruby, the Ruby on Rails framework. Rails is a multitude of patterns and practices that are worthwhile regardless of your current language, but it sometimes overshadows the true core of "beautiful code", Ruby.
The conference left me wanting to learn more about Ruby and to generally spend more of my time at work adopting Ruby. The challenge I (and many others have) is to do this while still meeting client requirements. Brian Sam-Bodden gave a great visual representation of how a Java project can incrementally adopt Ruby as a build language, scripting language, and testing framework. I missed half his presentation as I was so focused on pulling in buildr and some other utilities into my current project.
I think the two biggest topics covered though were essence vs ceremony and testing your application versus testing your framework. Stu Halloway gave a great keynote on essence vs ceremony and while his Java examples were typically very dated, his points remained true. Java (and C# by extension) force you to type crap that is just clutter or ceremony. The less ceremony in our applications, the easier they are to test, maintain, and actually produce on time. I don't recall who initially mentioned the difference between testing your framework and testing your application, but it was a point that haunted me all weekend. It's a very gray line typically between the two and one that can drastically impact a project schedule. Unfortunately, there is no easy answer to this one, so be sure to be cognizant of it when writing your unit, functional, and integration tests.
In summary, eRubycon far exceeded my expectations for a conference under $300. Speakers, content, hallway discussions, and after hours scotch induced discussions were all way above what I had hoped. Keep it up Joe, I'll see you there next year.
Showing posts with label conference. Show all posts
Showing posts with label conference. Show all posts
Saturday, August 16, 2008
Sunday, July 27, 2008
NFJS - Day 3
Spring Talks by Keith Donald
Spring has largely been my focus for the last few years so I was happy to see one of the Spring Source crew stepping up at NFJS. Keith Donald is the lead of almost all Spring web related technologies and he tends to give a very down to earth, code centric presentation so I devoted all of my final day to his talks.
Someone in the audience asked Keith if he missed the common XML file that shows exactly how all your beans are wired when you move to annotation driven POJOs and that question is an important one. I've recently become much more comfortable with developing Spring applications due to the Spring Facet in IntelliJ. Moving to annotations tends to make me question exactly which resource or component is plumbed in to fill a dependency. Keith mentioned that an emerging best practice is to use annotations for self describing application dependencies, XML for infrastructure concerns. He also gave a soft sell for Spring IDE to show a nice dependency graph regardless of annotations or XML.
Spring 2.5 is downright giddy with it's extensive use of annotations and it didn't really dawn on me until Keith's talk that it might be the better way to go in some scenarios. I've traditionally balked a little bit at the extensive use of annotations as it feels very invasive to the code at hand, especially when the annotations are Spring specific. More importantly, swapping out facilities for testing purposes is not trivial when you are doing component scanning and autowiring with annotations. I think Keith articulates an appropriate scenario for use though. Swapping out mock classes via XML is not a benefit that is needed as much for application dependencies as it is one that is needed for infrastructure (data access, email service, file reader, etc...). Go nuts with annotations at the app level, but use a good editor and keep the XML where it belongs for infrastructure pieces.
Keith spent a good amount of time in all of his talks using an IDE focused on Spring MVC controllers. The thing that stood out to me was how Spring web controllers are truly just POJOWAs now (I know that's not a term that will stick but a distinction needs to be made between POJOs and POJOs with annotations). This means that you will rarely see HttpServletRequest or ModelAndView type classes in these POJOs. What's the benefit here? You don't have to waste many of your test cycles mocking up the container objects. Wanna test your login method on the controller? Send in a User object and a String password and then validate whether you are getting a success or error redirect back. Very simple, and anything that we can do to lower the barrier of entry to good testing is well worth it.
Keith demonstrated another key change in coding Spring apps is the impact that Rails has had on the Spring community. The focus has shifted in Spring 2.5 to more sensible defaults and a true convention over configuration model. Controllers in Spring web apps now mimic Rails controllers in URL and request parameter resolution. Additionally, there are a set of special parameter types that are automagically injected. An arg of type Principal will be supplied by the container if the user is already logged in. Very cool.
One final note on the Spring web side. Why do we have another javascript framework? If you have improvements to make to DOJO, please just contribute them to DOJO. Don't create an abstraction layer over DOJO that does what you need. We have finally whittled the .js framework comparison down to a handful in my mind (prototype/scriptaculous, dojo, jquery, yui, and ext). Don't lead us back in the other direction.
Conference conclusion
NFJS again provided some immediate exposure to worthy technologies and processes. I was able to touch base with a lot of people in the Java community that I hadn't seen in some time and I feel like I have more tools in my belt than when the conference started. A special note to the organizers though. If the prices go up again next year while the number of conferences goes up as well, then you won't see me there for the first time in 4 years. It was evident to me this year that the conference is not the value that it was 2 and 3 years ago. If the trend continues, I'd rather spend my training dollars on codemash, erubycon, and books.
Spring has largely been my focus for the last few years so I was happy to see one of the Spring Source crew stepping up at NFJS. Keith Donald is the lead of almost all Spring web related technologies and he tends to give a very down to earth, code centric presentation so I devoted all of my final day to his talks.
Someone in the audience asked Keith if he missed the common XML file that shows exactly how all your beans are wired when you move to annotation driven POJOs and that question is an important one. I've recently become much more comfortable with developing Spring applications due to the Spring Facet in IntelliJ. Moving to annotations tends to make me question exactly which resource or component is plumbed in to fill a dependency. Keith mentioned that an emerging best practice is to use annotations for self describing application dependencies, XML for infrastructure concerns. He also gave a soft sell for Spring IDE to show a nice dependency graph regardless of annotations or XML.
Spring 2.5 is downright giddy with it's extensive use of annotations and it didn't really dawn on me until Keith's talk that it might be the better way to go in some scenarios. I've traditionally balked a little bit at the extensive use of annotations as it feels very invasive to the code at hand, especially when the annotations are Spring specific. More importantly, swapping out facilities for testing purposes is not trivial when you are doing component scanning and autowiring with annotations. I think Keith articulates an appropriate scenario for use though. Swapping out mock classes via XML is not a benefit that is needed as much for application dependencies as it is one that is needed for infrastructure (data access, email service, file reader, etc...). Go nuts with annotations at the app level, but use a good editor and keep the XML where it belongs for infrastructure pieces.
Keith spent a good amount of time in all of his talks using an IDE focused on Spring MVC controllers. The thing that stood out to me was how Spring web controllers are truly just POJOWAs now (I know that's not a term that will stick but a distinction needs to be made between POJOs and POJOs with annotations). This means that you will rarely see HttpServletRequest or ModelAndView type classes in these POJOs. What's the benefit here? You don't have to waste many of your test cycles mocking up the container objects. Wanna test your login method on the controller? Send in a User object and a String password and then validate whether you are getting a success or error redirect back. Very simple, and anything that we can do to lower the barrier of entry to good testing is well worth it.
Keith demonstrated another key change in coding Spring apps is the impact that Rails has had on the Spring community. The focus has shifted in Spring 2.5 to more sensible defaults and a true convention over configuration model. Controllers in Spring web apps now mimic Rails controllers in URL and request parameter resolution. Additionally, there are a set of special parameter types that are automagically injected. An arg of type Principal will be supplied by the container if the user is already logged in. Very cool.
One final note on the Spring web side. Why do we have another javascript framework? If you have improvements to make to DOJO, please just contribute them to DOJO. Don't create an abstraction layer over DOJO that does what you need. We have finally whittled the .js framework comparison down to a handful in my mind (prototype/scriptaculous, dojo, jquery, yui, and ext). Don't lead us back in the other direction.
Conference conclusion
NFJS again provided some immediate exposure to worthy technologies and processes. I was able to touch base with a lot of people in the Java community that I hadn't seen in some time and I feel like I have more tools in my belt than when the conference started. A special note to the organizers though. If the prices go up again next year while the number of conferences goes up as well, then you won't see me there for the first time in 4 years. It was evident to me this year that the conference is not the value that it was 2 and 3 years ago. If the trend continues, I'd rather spend my training dollars on codemash, erubycon, and books.
Saturday, July 26, 2008
NFJS - Day 2
Stu Halloway's Refactoring Javascript was a topic I did not expect to see at NFJS this year, but I walked away truly impressed. Stu presented a totally different mindset on developing, testing and refactoring javascript code. The gist of it is to use a mock browser that will allow you to run tests against your javascript code in an automated environment. Here is the mock browser but it is still in a beta state so expect to have to bend it to your will. Stu made extensive use of JSSpec for writing BDD specs against an existing javascript framework (livepipe). It was truly telling in the presentation that the first hour was spent trying to get a solid safety net of tests up and passing before we even began thinking about refactoring. Stuart accurately identified this as the norm when refactoring legacy code and it lines up directly with my experience as well. Refactoring can't be done w/o that safety net. When we finally did get around to refactoring, Stuart boiled it down to four areas:
Extract and Shorten
- If your method does more than one thing it does too much
- Keep method size to around 5 - 7 lines
Reduce Clutter
- Nix out of scope variables
- Keep the effort to duplicate a method greater than the effort to understand it
Choose Good Names
- Probably the most difficult of the refactorings
- Definitely the refactoring most in need of pair programming
Use Existing Libraries
- If you are typing document.getElementById then punch yourself first and download prototype.js second.
The talk was extremely hands on and valuable and made me wish I had a bucket of crappy javascript to go back to on Monday. Other things mentioned included another mock browser env: Crosscheck. Stu also mentioned a lack of code coverage tools for Javascript, but I found one during his talk. One last thing, he mentioned a very important refactoring anti pattern. Mirror methods (get and set on cookie) used in each others tests. If you are testing the get method on a cookie object don't explicitly use the mirror method (set). Instead, roll it by hand as a bug in code shared by these methods could offset each other in the test execution.
The second talk I went to was Stu's GIT talk. I've been looking into GIT for a little while and Stu gave a good gentle intro into it by basically walking through scenarios at a command prompt for 90 minutes. That format doesn't necessarily translate to a blog so here are some highlights:
- When using GIT, think less in terms of verbs
- GIT is not SVN++
- It's crazy fast. Branching and tagging for instance are instantaneous
- The entire source history is in every copy of the repo
- It doesn't store deltas, it stores the begin and end and calculates the deltas.
- You are forced to tell git what you are committing. It's not tracking it like SVN
- GIT encourages agility. You may not know what makes a package/release/hunk of functionality until sometime in the future. Additionally, you can stash your current task deliverables, go do something else, and come back to them later.
- Bisecting allows you to do a binary search through releases of code to identify the release that caused a bug. Kick ass.
Metaprogramming in Groovy by Brian Sam-Bodden was the third session I attended. BSB did a good job of going over the major metaprogramming techniques in Groovy. Additionally he had enough examples of Groovy code with TextMate that forced my hand to download it and see if it will cure what ails me with IntelliJ in dealing with Rails and Grails. Stream of conscience notes on metaprogramming with Groovy:
- Much simpler than using dynamic proxies in Java
- Similar to ruby it allows on the fly evaluation of code via evaluate
- Duck typing like ruby with respondsTo
- See yesterday's bits on methodMissing and invokeMethod
- obj."$methodToCall"() is valid Groovy code that will try to call the contents of methodToCall as a method on obj. In my opinion that code is utterly disgusting.
Also, the inevitable Ruby v Groovy topic came up as it did at lunch with me and a few others. There still seem to be zealots on both sides and I wish for the life of me they would just shut up.
My 2 cents are this. Use whatever makes most sense for your environment and team. At my consulting company, that is Ruby b/c I have a lot of .NET fellas that I would like to roll into and out of projects whether it is deployed on MRI, JVM, or DLR. The differences at my admittedly noob perspective are few and far between with the two languages. If it was a room full of Java developers, Groovy might make more sense because it is an easier transition for Java heads. I don't care what you choose for your environment, just quit bitching about the other side.
EJB3 Testing by Joseph Nusairat was my final session of the day. Joseph covered a wealth of testing frameworks in a very code centric presentation. The session was very interactive and covered some cool mocking techniques outside of the realm of EJB3, like dealing with mocking static methods. My attention span was slipping this late in the day, but here is a set of highlights:
- Easymock provides the typical set expectations, record and playback functionality. It is still probably the most proven, well documented, and easy to learn of the mock frameworks.
- JMockIt is a relatively new player with some cool support for AOP and Hibernate. Please notice the IT at the end of the name. JMock is a different framework. Unlike EasyMock and JMock, JMockIt is a very small and straightforward API that can be used to test methods w/o dynamic proxies or cglib.
- EJB3Unit has some very cool facilities. It provides an in memory database out of the box (HSQLDB), uses CSV files for populating the data and provides mocks of almost everything that you would need in an EJB 3 bean. If you have to use EJB3, this framework seems like a valid contender.
- Embedded JBoss is the last one covered and it seems like a good fit for mocking out an entire container when necessary and using JBoss.
- Mocking for unit testing, other tools still necessary for integration and functional tests.
I'm tired. See you tomorrow.
Extract and Shorten
- If your method does more than one thing it does too much
- Keep method size to around 5 - 7 lines
Reduce Clutter
- Nix out of scope variables
- Keep the effort to duplicate a method greater than the effort to understand it
Choose Good Names
- Probably the most difficult of the refactorings
- Definitely the refactoring most in need of pair programming
Use Existing Libraries
- If you are typing document.getElementById then punch yourself first and download prototype.js second.
The talk was extremely hands on and valuable and made me wish I had a bucket of crappy javascript to go back to on Monday. Other things mentioned included another mock browser env: Crosscheck. Stu also mentioned a lack of code coverage tools for Javascript, but I found one during his talk. One last thing, he mentioned a very important refactoring anti pattern. Mirror methods (get and set on cookie) used in each others tests. If you are testing the get method on a cookie object don't explicitly use the mirror method (set). Instead, roll it by hand as a bug in code shared by these methods could offset each other in the test execution.
The second talk I went to was Stu's GIT talk. I've been looking into GIT for a little while and Stu gave a good gentle intro into it by basically walking through scenarios at a command prompt for 90 minutes. That format doesn't necessarily translate to a blog so here are some highlights:
- When using GIT, think less in terms of verbs
- GIT is not SVN++
- It's crazy fast. Branching and tagging for instance are instantaneous
- The entire source history is in every copy of the repo
- It doesn't store deltas, it stores the begin and end and calculates the deltas.
- You are forced to tell git what you are committing. It's not tracking it like SVN
- GIT encourages agility. You may not know what makes a package/release/hunk of functionality until sometime in the future. Additionally, you can stash your current task deliverables, go do something else, and come back to them later.
- Bisecting allows you to do a binary search through releases of code to identify the release that caused a bug. Kick ass.
Metaprogramming in Groovy by Brian Sam-Bodden was the third session I attended. BSB did a good job of going over the major metaprogramming techniques in Groovy. Additionally he had enough examples of Groovy code with TextMate that forced my hand to download it and see if it will cure what ails me with IntelliJ in dealing with Rails and Grails. Stream of conscience notes on metaprogramming with Groovy:
- Much simpler than using dynamic proxies in Java
- Similar to ruby it allows on the fly evaluation of code via evaluate
- Duck typing like ruby with respondsTo
- See yesterday's bits on methodMissing and invokeMethod
- obj."$methodToCall"() is valid Groovy code that will try to call the contents of methodToCall as a method on obj. In my opinion that code is utterly disgusting.
Also, the inevitable Ruby v Groovy topic came up as it did at lunch with me and a few others. There still seem to be zealots on both sides and I wish for the life of me they would just shut up.
My 2 cents are this. Use whatever makes most sense for your environment and team. At my consulting company, that is Ruby b/c I have a lot of .NET fellas that I would like to roll into and out of projects whether it is deployed on MRI, JVM, or DLR. The differences at my admittedly noob perspective are few and far between with the two languages. If it was a room full of Java developers, Groovy might make more sense because it is an easier transition for Java heads. I don't care what you choose for your environment, just quit bitching about the other side.
EJB3 Testing by Joseph Nusairat was my final session of the day. Joseph covered a wealth of testing frameworks in a very code centric presentation. The session was very interactive and covered some cool mocking techniques outside of the realm of EJB3, like dealing with mocking static methods. My attention span was slipping this late in the day, but here is a set of highlights:
- Easymock provides the typical set expectations, record and playback functionality. It is still probably the most proven, well documented, and easy to learn of the mock frameworks.
- JMockIt is a relatively new player with some cool support for AOP and Hibernate. Please notice the IT at the end of the name. JMock is a different framework. Unlike EasyMock and JMock, JMockIt is a very small and straightforward API that can be used to test methods w/o dynamic proxies or cglib.
- EJB3Unit has some very cool facilities. It provides an in memory database out of the box (HSQLDB), uses CSV files for populating the data and provides mocks of almost everything that you would need in an EJB 3 bean. If you have to use EJB3, this framework seems like a valid contender.
- Embedded JBoss is the last one covered and it seems like a good fit for mocking out an entire container when necessary and using JBoss.
- Mocking for unit testing, other tools still necessary for integration and functional tests.
I'm tired. See you tomorrow.
Friday, July 25, 2008
NFJS - Day 1
PreConf Arrived at NFJS. 2 cents before the conference gets started. Having the conference in two places like Phoenix and Columbus on the same weekend is diluting the talent (and the costs have gone up). Phoenix wound up with a few of my favorite speakers on the planet: Neal Ford, Venkat Subramaniam, and Ted Neward. Please don't get me wrong, listening to Stu Halloway, Scott Davis, and Keith Donald among others still makes for an excellent conference. However, in previous years, having to choose between Justin Ghetland, Stu Halloway, Dave Thomas, or Ted Neward all in the same time slot was a nice problem to have. If NFJS is to keep it's mantra as a value driven conference with A+ speakers then it needs to keep it's shows to 1 city per weekend.
Scott Davis - Groovy the Blue/Red Pill
Scott Davis has a presentation style that is really conducive to learning new technologies. He speaks at a very measured pace with a number of pauses, yet still with a passion that gets users excited. His first two talks were Groovy, how it is similar to Java and then how it breaks the mold.
Groovy - The Blue Pill covered the language at a high level and how it is seamlessly integrated with Java. I spent a good portion of this talk weighing whether that is a good or bad thing. I as a 10 year Java veteran have developed a very Java centric mind and it continues to bite me in the arse. When anonymous inner classes become natural for you in a programming environment, you have issues. Ruby seems to allow me to make a clean break from this mold. Groovy is a step up, but not in the same sense. That being said, I think it's seamless integration with Java make it an easier sell to management types. Hopefully the JRuby guys can keep up. Stream of conscience thoughts on the talk:
- GStrings while oddly named are very elegant
- Mixing in Groovy based unit tests is a no brainer for ease of adoption and powerful mocking
- Triple quotes surrounding XML blocks makes you ignore quotes and newlines (Cool for XML)
- Groovy converts all checked exceptions to unchecked exceptions
- Powerful scripting: s.class.methods.each{println it}
Groovy - The Red Pill covered some of the more interesting pieces of meta-programming in Groovy. Here is where the obvious Ruby influence shows up in Groovy. The ExpandoMetaClass accommodates closures in a syntax that is less intuitive then blocks in Ruby to me. It's called ExpandoMetaClass though so bonus points there. The keyword delegate can be used to access the thing within EMC. Overloading operators is limited to a specific set and done in a manner that is less than intuitive (implement putAt(b,c) for a to get a[b]=c). Groovy also provides methodMissing and invokeMethod to get peeps closer to Ruby like syntax. My conclusion after this session was I'll use Ruby wherever I can, then Groovy, and finally Java.
Scott Davis did such a nice job presenting the first two Groovy talks, I stuck around for his Grails for Struts Losers talk. That wasn't the exact title, but I think I captured the gist of it. This was a gentle intro to Grails and managed to show it's benefits quite nicely over existing Java web frameworks (struts in this case). The framework is very clearly alot of the concepts of Rails that work well in a Java/Groovy centric environment. I spent the session trying to get Grails up and running in my environment and stumbled into an issue that clearly articulated Grails v Rails. I left parens off a method call and it blew up. WTF? Basically it was trying to find a property of that name instead of finding a method. Luckily, I had a Grails book co-author next to me to help troubleshoot. For those of you keeping track at home, Rails 1, Grails 0.
Scott Davis - Groovy the Blue/Red Pill
Scott Davis has a presentation style that is really conducive to learning new technologies. He speaks at a very measured pace with a number of pauses, yet still with a passion that gets users excited. His first two talks were Groovy, how it is similar to Java and then how it breaks the mold.
Groovy - The Blue Pill covered the language at a high level and how it is seamlessly integrated with Java. I spent a good portion of this talk weighing whether that is a good or bad thing. I as a 10 year Java veteran have developed a very Java centric mind and it continues to bite me in the arse. When anonymous inner classes become natural for you in a programming environment, you have issues. Ruby seems to allow me to make a clean break from this mold. Groovy is a step up, but not in the same sense. That being said, I think it's seamless integration with Java make it an easier sell to management types. Hopefully the JRuby guys can keep up. Stream of conscience thoughts on the talk:
- GStrings while oddly named are very elegant
- Mixing in Groovy based unit tests is a no brainer for ease of adoption and powerful mocking
- Triple quotes surrounding XML blocks makes you ignore quotes and newlines (Cool for XML)
- Groovy converts all checked exceptions to unchecked exceptions
- Powerful scripting: s.class.methods.each{println it}
Groovy - The Red Pill covered some of the more interesting pieces of meta-programming in Groovy. Here is where the obvious Ruby influence shows up in Groovy. The ExpandoMetaClass accommodates closures in a syntax that is less intuitive then blocks in Ruby to me. It's called ExpandoMetaClass though so bonus points there. The keyword delegate can be used to access the thing within EMC. Overloading operators is limited to a specific set and done in a manner that is less than intuitive (implement putAt(b,c) for a to get a[b]=c). Groovy also provides methodMissing and invokeMethod to get peeps closer to Ruby like syntax. My conclusion after this session was I'll use Ruby wherever I can, then Groovy, and finally Java.
Scott Davis did such a nice job presenting the first two Groovy talks, I stuck around for his Grails for Struts Losers talk. That wasn't the exact title, but I think I captured the gist of it. This was a gentle intro to Grails and managed to show it's benefits quite nicely over existing Java web frameworks (struts in this case). The framework is very clearly alot of the concepts of Rails that work well in a Java/Groovy centric environment. I spent the session trying to get Grails up and running in my environment and stumbled into an issue that clearly articulated Grails v Rails. I left parens off a method call and it blew up. WTF? Basically it was trying to find a property of that name instead of finding a method. Luckily, I had a Grails book co-author next to me to help troubleshoot. For those of you keeping track at home, Rails 1, Grails 0.
Monday, July 21, 2008
Tech Ridden Month
I have 3 different blog posts in the making right now and I unfortunately don't see myself having enough time to complete them in the next month. A wide variety of activities are chewing up almost all of my free time, but most of it is tech related. Here's a look at my schedule:
7/22 - Speaking about Spring at the Cincinnati Java User's Group
7/25 - 7/27 - Attending NoFluffJustStuff in Columbus
7/31 - 8/4 - Vacationing with wife in Cabo San Lucas (WOOHOO!)
8/15 - 8/17 - Attending eRubycon in Columbus
I'm extremely excited about all of these opportunities but it will nonetheless continue my procrastination of blogging. Please sit tight and check back in mid August for more content on Spring, Ruby, IntelliJ, and IT Leadership.
7/22 - Speaking about Spring at the Cincinnati Java User's Group
7/25 - 7/27 - Attending NoFluffJustStuff in Columbus
7/31 - 8/4 - Vacationing with wife in Cabo San Lucas (WOOHOO!)
8/15 - 8/17 - Attending eRubycon in Columbus
I'm extremely excited about all of these opportunities but it will nonetheless continue my procrastination of blogging. Please sit tight and check back in mid August for more content on Spring, Ruby, IntelliJ, and IT Leadership.
Thursday, January 24, 2008
Code Mash Recap
Codemash came and went over a week ago but I've been hoarding my free time so the blog has gone by the way side. I must say that codemash is as unique a conference as you can find and the organizers do a superb job of providing valuable content and access to bright people. The speakers I saw were very good overall and made you question how the conference is not pummeled with only charging $200 or less.
The highlight for me had to be speaking with Jim Weirich on a couple of occasions about Ruby and his work at EdgeCase. He's the man behind Rake, XmlBuilder, FlexMock, and other pieces to the Ruby puzzle I'm sure I'm forgetting. He was extremely down to earth and very practical about using the appropriate language for the job. He's like DHH with his passion for Ruby and Rails, but without the arrogance.
Additionally, I was reminded why I really enjoy working with the people I do at QSI. We sent no less than 30 people there, had a couple of speaker/organizers, had the most rocking booth of all the vendors, and most importantly had great discussions about software over beer every night there. At least 5 people made comments to me about their desire to learn Ruby and/or Rails. We'll hopefully capitalize on this passion by forming a 12 step program to get us familiar with Ruby (first and foremost) and then Rails. I'll keep the blog updated through the journey to beautiful code...
The highlight for me had to be speaking with Jim Weirich on a couple of occasions about Ruby and his work at EdgeCase. He's the man behind Rake, XmlBuilder, FlexMock, and other pieces to the Ruby puzzle I'm sure I'm forgetting. He was extremely down to earth and very practical about using the appropriate language for the job. He's like DHH with his passion for Ruby and Rails, but without the arrogance.
Additionally, I was reminded why I really enjoy working with the people I do at QSI. We sent no less than 30 people there, had a couple of speaker/organizers, had the most rocking booth of all the vendors, and most importantly had great discussions about software over beer every night there. At least 5 people made comments to me about their desire to learn Ruby and/or Rails. We'll hopefully capitalize on this passion by forming a 12 step program to get us familiar with Ruby (first and foremost) and then Rails. I'll keep the blog updated through the journey to beautiful code...
Saturday, December 15, 2007
The Spring Experience - Day 4
Day 4 started much like Day 3 with another good presentation from Ben Alex regarding Spring Security. This session focused on the enhancements provided in Spring Security 2:
The second session I hit was RESTful web services in Spring by Arjen Poutsma. This session was a combination introduction to REST (Representational State Transfer) and highlight of facilities coming soon for developing clients and providers of these web services. It was great to see how similar the EndPoints Arjen displayed were to the Controller classes shown by Keith Donald earlier in the week in the RESTful web sites talk. Despite the number of disparate people working on these separate Spring based sub-projects, they are all adhering to a few common designs that make it very easy for a Spring developer to become productive in each of the environments.
OSGi was next up, presented by Adrian Colyer and Costin Leau. OSGi will provide Java application developers with a facility for deploying and managing separate versions of the same subsystems or libraries. The examples shown were somewhat contrived, but the concepts of OSGi are extremely powerful and immediately useful in at least two of the last three Java clients I've worked at. If you've ever found yourself trying to juggle version collision of components in your application, be sure to investigate OSGi.
Final talk of the conference for me was Spring Batch Internals by David Syer and Lucas Ward. They covered a plethora of the common issues facing batch processing systems and the solutions provided to these issues by Spring Batch. Batch processing seems to be the red headed step child of software development. Continually neglected while SOA and AJAX based applications win all of the adoration of the parents. Regardless, it is still a significant portion of the software projects out there and there are a wealth of common patterns that can be pulled up a level into a framework like Spring Batch. I'd go into more detail on it but I am seriously exhausted and my head hurts from the amount of information presented at this conference.
In a nutshell, the content at this conference was great and the majority of the speakers were very good. Only downside was that I didn't win an iPhone.
- Annotation driven security that allows a developer to specify required roles directly above a method declaration
- User management API for creating users and default implementations for JDBC and LDAP backed stores
- Hierarchical roles. UPDATE_ALL implicitly grants you UPDATE_CUSTOMER, UPDATE_ORDER, etc...
- Many other features like NTLM support, Portlet Security integration, and Automatic login page generaton
The second session I hit was RESTful web services in Spring by Arjen Poutsma. This session was a combination introduction to REST (Representational State Transfer) and highlight of facilities coming soon for developing clients and providers of these web services. It was great to see how similar the EndPoints Arjen displayed were to the Controller classes shown by Keith Donald earlier in the week in the RESTful web sites talk. Despite the number of disparate people working on these separate Spring based sub-projects, they are all adhering to a few common designs that make it very easy for a Spring developer to become productive in each of the environments.
OSGi was next up, presented by Adrian Colyer and Costin Leau. OSGi will provide Java application developers with a facility for deploying and managing separate versions of the same subsystems or libraries. The examples shown were somewhat contrived, but the concepts of OSGi are extremely powerful and immediately useful in at least two of the last three Java clients I've worked at. If you've ever found yourself trying to juggle version collision of components in your application, be sure to investigate OSGi.
Final talk of the conference for me was Spring Batch Internals by David Syer and Lucas Ward. They covered a plethora of the common issues facing batch processing systems and the solutions provided to these issues by Spring Batch. Batch processing seems to be the red headed step child of software development. Continually neglected while SOA and AJAX based applications win all of the adoration of the parents. Regardless, it is still a significant portion of the software projects out there and there are a wealth of common patterns that can be pulled up a level into a framework like Spring Batch. I'd go into more detail on it but I am seriously exhausted and my head hurts from the amount of information presented at this conference.
In a nutshell, the content at this conference was great and the majority of the speakers were very good. Only downside was that I didn't win an iPhone.
Friday, December 14, 2007
The Spring Experience - Day 3
Started off day three with Spring Security directly from it's creator, Ben Alex. The session provided a good intro to Spring Security but I felt bad for Ben as he got peppered with 4011 questions during the talk. Even with all of the tangents, Ben did a good job of presenting the core benefits of Spring Security. An example of it's power is to have a configuration that intercepts a method, say getEbayItemListing() and checks to see before execution if the user is authorized to perform this action. This can be a complex check that even validates if the current requester is actually seller of the item (instance level authorization). Then upon method completion, the after advice will mask the minimum sale amount by nulling it out on the object if the requester is not the original seller. With this being performed at the method level, it doesn't matter if the request comes from a website, web service, or other Java program. Very powerful.
Rob Harrop gave a talk on concurrency in Java that was very in depth coverage of the Java 5 concurrency objects. There was a ton of info in that session that I'll not cover here other than to say if you are developing in a multi-threaded environment in Java 5, please review the docs in the java.util.concurrency package.
The third session I attended was from one of my favorite tech speakers Venkat Subramaniam. Venkat covered Spring's facilities for integrating dynamic language objects like Ruby and Groovy classes into your Java framework as plain beans. I had no idea that this facility existed and as with most things Spring, it is accomplished very painlessly with a little configuration. A great use case for this is on the fly loading of dynamic processing logic (like rules) without stopping your application or server. Want some small dynamic rules processing without dealing with a full blown rules engine like JRules or JBoss rules? Here's your answer (and you don't need to wait for your company to deploy Java6). The second half of his talk covered using the GroovyObjectCustomizer object from Spring to implement a DSL. This also seemed relatively simple, but it was surprising how much more complex it was to implement in straight Java versus Groovy. I still prefer Ruby though.
The final talk before 500 pasty, flabby geeks descended upon the Hollywood, FL beach was Spring Web Services by Arjen Poutsma. I didn't gather a ton of info out of this session but a couple of nuggets were useful. The speaker advocated the opposite approach of XFire. Basically that you should start with the contract and work back towards mapping to your domain which I think makes sense in all but some of the more trivial cases. Additionally it seems that once you get the gist of Spring and the annotations provided in 2.5, moving from Spring MVC and WebFlow to something like Spring WebServices is rather trivial.
Time to hammock up!
Rob Harrop gave a talk on concurrency in Java that was very in depth coverage of the Java 5 concurrency objects. There was a ton of info in that session that I'll not cover here other than to say if you are developing in a multi-threaded environment in Java 5, please review the docs in the java.util.concurrency package.
The third session I attended was from one of my favorite tech speakers Venkat Subramaniam. Venkat covered Spring's facilities for integrating dynamic language objects like Ruby and Groovy classes into your Java framework as plain beans. I had no idea that this facility existed and as with most things Spring, it is accomplished very painlessly with a little configuration. A great use case for this is on the fly loading of dynamic processing logic (like rules) without stopping your application or server. Want some small dynamic rules processing without dealing with a full blown rules engine like JRules or JBoss rules? Here's your answer (and you don't need to wait for your company to deploy Java6). The second half of his talk covered using the GroovyObjectCustomizer object from Spring to implement a DSL. This also seemed relatively simple, but it was surprising how much more complex it was to implement in straight Java versus Groovy. I still prefer Ruby though.
The final talk before 500 pasty, flabby geeks descended upon the Hollywood, FL beach was Spring Web Services by Arjen Poutsma. I didn't gather a ton of info out of this session but a couple of nuggets were useful. The speaker advocated the opposite approach of XFire. Basically that you should start with the contract and work back towards mapping to your domain which I think makes sense in all but some of the more trivial cases. Additionally it seems that once you get the gist of Spring and the annotations provided in 2.5, moving from Spring MVC and WebFlow to something like Spring WebServices is rather trivial.
Time to hammock up!
The Spring Experience - Day 2
I focused on web framework related sessions today and came away with a wealth of knowledge and a long list of technologies to investigate further. Keith Donald gave a presentation on full stack web frameworks that was very interesting. He gave a very unbiased perspective on how frameworks like Grails, Rails, Django and others excel and lag with respect to about 10 criteria that comprise a "full stack" web framework (AJAX, REST, data binding, security, testability, etc...). He offered that Spring really doesn't have a full stack web framework, but instead acts as a foundation for them (Grails being built on top of it for instance). That is changing however as Spring MVC and WebFlow are adapting and integrating with some other technologies to really provide a complete offering.
I attended a few other sessions that focused on REST with Spring, AJAX offerings, JSF and WebFlow based apps, and Reasonable Server Faces. They all provided ton of information outside of my traditional area of expertise (middleware and persistence).
I think the most striking thing that I realized in these sessions though was how much of a huge step up in productivity there is in Spring 2.5. Annotations seem like a much better fit for metadata and being able to tell the container to only autowire a few certain dependencies right at their declaration point is immensely useful. Spring Security (formerly ACEGI) has gone from around a minimum of 150 lines of configuration to about 15 for the simplest cases by making use of these constructs. Spring 2.5 maintains backwards compatibility as well, so run, don't walk to the download if you haven't already.
I attended a few other sessions that focused on REST with Spring, AJAX offerings, JSF and WebFlow based apps, and Reasonable Server Faces. They all provided ton of information outside of my traditional area of expertise (middleware and persistence).
I think the most striking thing that I realized in these sessions though was how much of a huge step up in productivity there is in Spring 2.5. Annotations seem like a much better fit for metadata and being able to tell the container to only autowire a few certain dependencies right at their declaration point is immensely useful. Spring Security (formerly ACEGI) has gone from around a minimum of 150 lines of configuration to about 15 for the simplest cases by making use of these constructs. Spring 2.5 maintains backwards compatibility as well, so run, don't walk to the download if you haven't already.
Thursday, December 13, 2007
The Spring Experience - Day 1
Day one of TSE was just registration, dinner, and a keynote by Rod Johnson but it was a great evening for a couple reasons.
Rod's keynote focused on the changing of the guard and disruption for the Java EE landscape. Most notably, his contention was that the committee driven process that we have now is largely failing. EJB 3.0 being just the latest example. OpenSource is a much more dynamic and user driven process that nearly immediately produces software and frameworks that a lot of users need. The committees by contrast are steered by people who try to sell application servers and move at the pace of a Columbus driver in a 1/2 inch of snow (aka very s l o w l y). I think his point here was right on and I think it might signal a very polar divide between users and committee.
Additionally, the conference passed out Rod Johnson bobblehead dolls complete with the pose from this book cover:
Classic!
Rod's keynote focused on the changing of the guard and disruption for the Java EE landscape. Most notably, his contention was that the committee driven process that we have now is largely failing. EJB 3.0 being just the latest example. OpenSource is a much more dynamic and user driven process that nearly immediately produces software and frameworks that a lot of users need. The committees by contrast are steered by people who try to sell application servers and move at the pace of a Columbus driver in a 1/2 inch of snow (aka very s l o w l y). I think his point here was right on and I think it might signal a very polar divide between users and committee.
Additionally, the conference passed out Rod Johnson bobblehead dolls complete with the pose from this book cover:
Classic!
Subscribe to:
Posts (Atom)
