Mark Blankenship posted his own personal history of software development and charged a few of us with posting the same. Here's my background:
How old were you when you started programming?
I remember my first official "programming" class was my sophomore year in high school so roughly age 15. I was officially playing around with a Commodore 64 as early as age 8 though. While that was mostly gaming, the memory and file models puzzled and intrigued me back then. My cousin and I would waste hours playing Mission Impossible on the C64 though. That tended to get in the way of any real programming back in the day, establishing a pattern of gaming over real work that plagues me still.
How did you get started in programming?
My brother is 5 years older and he was already starting to see some serious need for programmers while he was off at college. I was but a young lad in high school, focused more intently on sports, girls, and parties at the time. When I took my first real course at his advice though, I was hooked. So, brotherly encouragement coupled with a strong background in math. My father is a science teacher as well so he was always giving me a slight kick in the rear to pursue any and all topics that stoked my interest.
What was your first language?
BASIC, baby! I remember sitting next to a guy in that first course who nearly had the mental capacity to bend spoons and levitate people. He scored a 35 on his ACTs and a 1520 on his SATs, no joke. He was scary smart. I believe he later became a nuclear physicist, but I'm not totally sure. Anyway, he wrote a 5 level Zork type game in that class in the first two days we were there. That opened my eyes to the power of programming. Thanks Bill!
What was the first real program you wrote?
The first open canvas program I wrote was in a computer graphics class my junior year in high school. I built a dart board type game that allowed two people to compete to see who could get the dart closest to the center. By compete I mean that you merely alternated pressing a button to throw darts and they went to random spots on the board but it was still pretty cool.
What languages have you used since you started programming?
Probably missing some but here goes:
BASIC
Pascal
Modula-2
C
C++
Java
Smalltalk
Lisp
Fortran
SQL
HTML/Javascript
Ruby
C#
ASP.NET
What was your first professional programming gig?
I hired on as a paid intern thanks again to my bro. I was told I would be working on a C/C++/SQL based project for a retail services company. Instead I was working on an S1032 database with Fortran code literally printing off reams of green bar code snippets. If that place didn't have a ping pong table on site that rolled out every day at 5pm I would've probably gone postal. That assignment nearly made me into a history major.
If you knew then what you know now, would you have started programming?
No question about it. If anything I would've been more driven to succeed in this profession and spent more of my free time learning and pushing my limits. I was largely a slacker through high school and college and it set me behind starting out in the real work force. While it did enable me to thoroughly dominate OSU's entire campus in NHL 93 on the sega genesis, it also nearly caused me to drop out, become disowned, and live life in a van down by the river. I was lucky to find my niche once again but I wonder what I would've accomplished if I would've truly applied myself.
If there is one thing you learned along the way that you would tell new developers, what would it be?
Get comfortable with change and figure out the best way for you to learn. Change comes at you at all times from all directions in this field. Requirements are never set in stone, business direction can sometimes sway with the wind, and technology will certainly never be static. While Java has been around for 14 years now, the language it is today is worlds apart from what Gosling and co pushed out to us in the form of crApplets in 1994. All of the people in this field that I want to surround myself are quick learners and very adaptive. If you can roll with the punches figure out things quickly, then you'll never cease being marketable.
What's the most fun you've ever had ... programming?
I'm not sure I've ever had a moment of euphoria while writing a piece of code, but there was one time when I solved a huge showstopper of a bug that was visible at every level of our company. We had been seeing our application lock up the server completely on a random basis for about 2 weeks. After code inspection day 10 I finally stumbled upon an infinite recursive subroutine that was nested 142 levels deep in app server that was impossible to debug. Finally getting it resolved wasn't fun as much as it was like someone moving a car that had been parked on your foot.
That being said, I think I've had fun at every programming job I've ever been in. I attribute that solely to the various people that I've worked with, though. I have yet to work at a client yet where I've woken up with an utter feeling of dread. Maybe I'm just lucky, but I can rattle off a number of people from every client I've been at who I could call right now to go grab a beer. I think the problem solving is always fun and gratifying but working with people you genuinely want to be around is priceless.
Next up:
I'm throwing the guantlet down for another group of peeps to answer these questions:
Matt Marquand
Kevin Munc
Steve Harman
Jon Kruger
Steve Horn
Showing posts with label software. Show all posts
Showing posts with label software. Show all posts
Monday, June 9, 2008
Monday, May 5, 2008
And then there were 3
Oracle has now officially acquired BEA, leaving the app server marketplace for Java EE at 3 major vendors with IBM and JBoss completing the trinity. After having personal experience with both BEA WebLogic and Oracle's Application Server, I plea to Oracle, just use BEA's app server and don't mess with it. Orion was a good product and you turned it into a trainwreck. There is no reason that an application server install should take 4 days and 300 gb of memory. JSPs shouldn't be stored in the database. Oh, and your installer should not need to install JDK 1.2 to run. Leave it alone Oracle and focus on improving your DB.
Thursday, May 1, 2008
A Polarized Community?
The news that SpringSource announced yesterday regarding their application server is not surprising but possibly very concerning to many developers in the Java landscape. We see now a very clear divide between people's perception of what is standard for Java Enterprise Development. Is the standard the open source platform that is used in a greater number of projects or is the standard the framework released by the Java Community Process? In my opinion it is very clearly the former.
I'm in the fortunate position of seeing every Java requirement that comes in to my consulting company and guess what? The number of Spring requirements far outweighs the number of EJB, let alone JSF reqs. I still see more Struts requirements than JSF and EJB reqs combined. So now, is the news that not only is there a non-standard framework, but also a non-standard application server something to be concerned with? Hell no.
How many developers have actually taken advantage of the fact that your app can be ported to different app servers with "no code change"? I've been on one project in the last 10 years that did so and guess what? We still had to change a lot of XML to make sure that stuff didn't break. Portability is a farce at the app server level and it's largely unnecessary.
So if there is no need to port my SpringAppServer application to JBoss or WebLogic or god help me WebSphere, what are the issues with adopting SpringSource Application Platform? It surely will present some amount of a learning curve. It may not be adopted by many of my clients initially who continue to write checks to IBM and BEA for inferior products that lag behind the so-called standards.
On the flip side, it will provide the ability to roll out smaller, componentized versions of your applications. It will let you keep multiple versions of the same components running on the same server. It will let you deploy your app without restarting your server. It will cost about $15k per cpu less than BEA or IBM products. Oh, and it will not force you to use JDK 1.4 or prior in order to run on the system.
Is it really a polarized community if everyone is heading in one direction?
I'm in the fortunate position of seeing every Java requirement that comes in to my consulting company and guess what? The number of Spring requirements far outweighs the number of EJB, let alone JSF reqs. I still see more Struts requirements than JSF and EJB reqs combined. So now, is the news that not only is there a non-standard framework, but also a non-standard application server something to be concerned with? Hell no.
How many developers have actually taken advantage of the fact that your app can be ported to different app servers with "no code change"? I've been on one project in the last 10 years that did so and guess what? We still had to change a lot of XML to make sure that stuff didn't break. Portability is a farce at the app server level and it's largely unnecessary.
So if there is no need to port my SpringAppServer application to JBoss or WebLogic or god help me WebSphere, what are the issues with adopting SpringSource Application Platform? It surely will present some amount of a learning curve. It may not be adopted by many of my clients initially who continue to write checks to IBM and BEA for inferior products that lag behind the so-called standards.
On the flip side, it will provide the ability to roll out smaller, componentized versions of your applications. It will let you keep multiple versions of the same components running on the same server. It will let you deploy your app without restarting your server. It will cost about $15k per cpu less than BEA or IBM products. Oh, and it will not force you to use JDK 1.4 or prior in order to run on the system.
Is it really a polarized community if everyone is heading in one direction?
Thursday, February 28, 2008
ACID Principles Applied to Testing
Sometimes you don't realize that you have built your house on a fault line. Then the tectonic plates shift and you are left in a pile of rubble wondering, WTF just happened?
I recently found myself in that very position, as it applies to testing applications. We had been focused on writing unit, integration, and functional tests and automating them for a .NET application that was really nothing more than CRUD but with some significantly complex business rules thrown in. We made some mistakes along the way though that finally came to a head earlier this week when 3 out of 3 of our builds were broken, we were running a day late in releasing an application to UAT and we had made a significant number of refactoring changes that could have very well broken 50% of our functionality, but we couldn't tell for sure. Amidst the rubble, I took a moment to reflect on what got us to that point so that I could share with you, kind reader, the err of our ways.
Our biggest mistake in writing tests was not making sure that they were Isolated. I've always been kind of a persistence geek though, so I naturally started noticing how the ACID principles of database transactions apply so well to testing. For reference, the ACID properties are Atomic, Consistent, Isolated, and Durable, see wikipedia.
Atomic - Can't be broken into smaller parts.
Good unit and integration tests should be atomic. Not so much for functional tests as they are typically the assembly of multiple atomic parts into one whole. The unit and integration tests, however, should be focused on testing one feature of any target. Nothing more, nothing less. This makes the tests cleaner, it makes uncovering causes to failures easier, and it helps to differentiate functional tests from unit and integration tests.
Consistent - Repeated execution results in the same outcome.
Consistency, or the lack thereof, typically rears it's head in the integration and functional tests and in my experience, the cause is often broken dependencies. Database integration tests mysteriously start failing because another developer went in and updated some data that your test depends on. Making integration tests consistent requires some work. Typically it involves automatically prepping a database with all of the values and foreign keys populated so that your test follows it's directed path. This can be made much easier with a framework like DBUnit in Java which preps and removes data as needed.
Isolated - Concurrent operations do not have an affect on one another.
As mentioned earlier, this one was a biggie for us. We found that any person running tests while the build was also running them, caused both to fail. This was due to some poor choices in how we were trying to cleanup after ourselves (blindly searching by a non primary key field that picked up data from other tests). The easiest solution in many instances is to use a pattern provided by the bright fellas over at Spring, and start a transaction in your setup method and then roll that puppy back in your tear down method. This allows everything running in that test to see changes made by the code (assuming it uses the same connection as your tests), but it removes the sometimes complex logic of undoing your changes by hand. Additionally, it ensures that even if the same two tests are running at the same time, each will be on a separate connection and totally unaware of the other's changes. See AbstractTransactionalContextTests in Spring.
Durable - Once successful it is permanent.
It should really take a change in business logic or interface design to get a test breaking once it's in a successful state. This goes hand in hand with the previously mentioned anti-pattern, so don't let data or systems outside of your control muck with your tests. Make your functional tests fully dependent on mocks, stubs, or dummies instead of external systems or databases. Make sure your integration tests are completely responsible for setting up all of the data that they need before running. This will lower the probability of environmental issues throwing up a false negative on your CI server.
I've made a distinction throughout this article with Unit/Functional/Integration tests. Make sure you know the difference between them and be adamant about treating them differently.
Unit tests should never interact with a database, email server, web service, or other disparate system. Unit tests should be automated and run upon every code delivery. They should be extremely fast to keep ADD developers from staring blindly out the window or surfing the net while waiting for the tests to complete.
Integration tests should never be mocking the integrated system and in many cases should only be run on a daily or semi daily basis. Unless your database or external system is being modified multiple times throughout the day, just set these to run up when the lights go off at night. If someone is actively changing your entire persistence layer, they should have the common sense to run these manually before checking in.
Functional tests should almost solely rely on mocks, dummies, or stubs instead of external dependencies and since they'll be pretty zippy if you write your mocks correctly. If they are in the "runs in less than 5 minutes" category, then run them at every check in so that the staff is well aware of any issues as soon as a delivery is made.
Keep in mind the ACID principles when testing your code. They'll hopefully keep you away from the fault lines and in the happy state of green builds.
I recently found myself in that very position, as it applies to testing applications. We had been focused on writing unit, integration, and functional tests and automating them for a .NET application that was really nothing more than CRUD but with some significantly complex business rules thrown in. We made some mistakes along the way though that finally came to a head earlier this week when 3 out of 3 of our builds were broken, we were running a day late in releasing an application to UAT and we had made a significant number of refactoring changes that could have very well broken 50% of our functionality, but we couldn't tell for sure. Amidst the rubble, I took a moment to reflect on what got us to that point so that I could share with you, kind reader, the err of our ways.
Our biggest mistake in writing tests was not making sure that they were Isolated. I've always been kind of a persistence geek though, so I naturally started noticing how the ACID principles of database transactions apply so well to testing. For reference, the ACID properties are Atomic, Consistent, Isolated, and Durable, see wikipedia.
Atomic - Can't be broken into smaller parts.
Good unit and integration tests should be atomic. Not so much for functional tests as they are typically the assembly of multiple atomic parts into one whole. The unit and integration tests, however, should be focused on testing one feature of any target. Nothing more, nothing less. This makes the tests cleaner, it makes uncovering causes to failures easier, and it helps to differentiate functional tests from unit and integration tests.
Consistent - Repeated execution results in the same outcome.
Consistency, or the lack thereof, typically rears it's head in the integration and functional tests and in my experience, the cause is often broken dependencies. Database integration tests mysteriously start failing because another developer went in and updated some data that your test depends on. Making integration tests consistent requires some work. Typically it involves automatically prepping a database with all of the values and foreign keys populated so that your test follows it's directed path. This can be made much easier with a framework like DBUnit in Java which preps and removes data as needed.
Isolated - Concurrent operations do not have an affect on one another.
As mentioned earlier, this one was a biggie for us. We found that any person running tests while the build was also running them, caused both to fail. This was due to some poor choices in how we were trying to cleanup after ourselves (blindly searching by a non primary key field that picked up data from other tests). The easiest solution in many instances is to use a pattern provided by the bright fellas over at Spring, and start a transaction in your setup method and then roll that puppy back in your tear down method. This allows everything running in that test to see changes made by the code (assuming it uses the same connection as your tests), but it removes the sometimes complex logic of undoing your changes by hand. Additionally, it ensures that even if the same two tests are running at the same time, each will be on a separate connection and totally unaware of the other's changes. See AbstractTransactionalContextTests in Spring.
Durable - Once successful it is permanent.
It should really take a change in business logic or interface design to get a test breaking once it's in a successful state. This goes hand in hand with the previously mentioned anti-pattern, so don't let data or systems outside of your control muck with your tests. Make your functional tests fully dependent on mocks, stubs, or dummies instead of external systems or databases. Make sure your integration tests are completely responsible for setting up all of the data that they need before running. This will lower the probability of environmental issues throwing up a false negative on your CI server.
I've made a distinction throughout this article with Unit/Functional/Integration tests. Make sure you know the difference between them and be adamant about treating them differently.
Unit tests should never interact with a database, email server, web service, or other disparate system. Unit tests should be automated and run upon every code delivery. They should be extremely fast to keep ADD developers from staring blindly out the window or surfing the net while waiting for the tests to complete.
Integration tests should never be mocking the integrated system and in many cases should only be run on a daily or semi daily basis. Unless your database or external system is being modified multiple times throughout the day, just set these to run up when the lights go off at night. If someone is actively changing your entire persistence layer, they should have the common sense to run these manually before checking in.
Functional tests should almost solely rely on mocks, dummies, or stubs instead of external dependencies and since they'll be pretty zippy if you write your mocks correctly. If they are in the "runs in less than 5 minutes" category, then run them at every check in so that the staff is well aware of any issues as soon as a delivery is made.
Keep in mind the ACID principles when testing your code. They'll hopefully keep you away from the fault lines and in the happy state of green builds.
Wednesday, February 6, 2008
Failing to Fail Early
A coworker and I stumbled across some weird behavior with NHibernate today that totally surprised me. I come from the Hibernate world which tends to be about a version to a version and a half ahead of NHibernate. So I'm used to going to look for excellent support for stored procedures and realizing I'm SOL.
Today though we found an issue that wasn't lack of support, but just a horrible design decision that differs between the two frameworks. In a nutshell, Session.Load was being called with an ID that didn't exist and we weren't receiving an exception. Huh? The difference between Get and Load in my mind was always, same behavior if the PK passed in exists in the database, if it doesn't Get returns null silently, and Load throws ObjectNotFoundException, violently alerting you that your PK is not what you think it is. In this case we were getting back a proxied object that would immediately throw ObjectNotFoundException whenever one of it's getter methods were called. Nice. I assumed that we were misusing the Interceptor functionality or something to cause this but a little googlage revealed this description of the ObjectNotFoundException class in the NHibernate docs:
"Thrown when ISession.Load() fails to select a row with the given primary key (identifier value). This exception might not be thrown when Load() is called, even if there was no row on the database, because Load() returns a proxy if possible..."
Come again? What use do I have for a proxied object that is just going to throw ObjectNotFoundException the moment I start accessing it? Even worse, what if I have a business method that checks a private attribute for null on this object. You shouldn't be able to do anything to this object because according to the database IT DOESN'T EXIST. When all else fails, go to the pragmatic programmers for advice and listen when they tell you to FAIL EARLY. Give me null or give me exceptions, don't fool me into thinking my row is there when it isn't.
Today though we found an issue that wasn't lack of support, but just a horrible design decision that differs between the two frameworks. In a nutshell, Session.Load was being called with an ID that didn't exist and we weren't receiving an exception. Huh? The difference between Get and Load in my mind was always, same behavior if the PK passed in exists in the database, if it doesn't Get returns null silently, and Load throws ObjectNotFoundException, violently alerting you that your PK is not what you think it is. In this case we were getting back a proxied object that would immediately throw ObjectNotFoundException whenever one of it's getter methods were called. Nice. I assumed that we were misusing the Interceptor functionality or something to cause this but a little googlage revealed this description of the ObjectNotFoundException class in the NHibernate docs:
"Thrown when ISession.Load() fails to select a row with the given primary key (identifier value). This exception might not be thrown when Load() is called, even if there was no row on the database, because Load() returns a proxy if possible..."
Come again? What use do I have for a proxied object that is just going to throw ObjectNotFoundException the moment I start accessing it? Even worse, what if I have a business method that checks a private attribute for null on this object. You shouldn't be able to do anything to this object because according to the database IT DOESN'T EXIST. When all else fails, go to the pragmatic programmers for advice and listen when they tell you to FAIL EARLY. Give me null or give me exceptions, don't fool me into thinking my row is there when it isn't.
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!
Monday, December 10, 2007
Christmas Comes Early for Spring Fanboy
Wednesday I leave balmy Ohio (currently 38 degrees with showers) for Hollywood, FL (currently 82 degrees). Weather aside, I am extremely excited as I'm going there for the Spring Experience conference. As big a fanboy as I am with Spring, I'm somewhat daunted by the sheer volume of information that will be coming at me this week. There are 70 1.5 hour sessions crammed into 3 full days and I've got more than a passing interest in attending about 50 of them.
TSE is organized by Jay Zimmerman of NoFluffJustStuff fame, so I've got high expectations. I've been to NFJS conferences the last four years and every time I come back to work re-energized and armed with a bevy of new tools and techniques that are immediately applicable to my daily work. NFJS typically brings only noted authors and thought leaders in as speakers for these conferences and this one is no different with Rod Johnson, Juergen Hoeller, Rob Harrop, Ben Alex, Ramnivas Laddad, and a slew of other Spring contributors and experts speaking at the conference.
I'm going to have the laptop with me and battery willing, I'll be able to share my impressions throughout the conference.
Time to get packing. Now where did I put the old banana hammock...
Friday, December 7, 2007
The Long and Winding Road
I've started back up on a new phase of a project and it's rekindling my hatred for extensive documentation. I'm beginning to feel that most developers are just not inherently good at writing documentation, myself especially. We're just not wired that way and I think people generally despise doing tasks that they are not good at.
In this instance maybe it's just more painful because there is no challenge involved. It's a straight migration of an existing system so there is none of the excitement involved in finding out what the business domain entails and trying to mate technologies to the problems facing the users of the system.
Luckily we're always running an Agile project at QSI, and this particular client is open to documenting only what is needed and not wasting money on anything more. Unfortunately this brings up the question, what are the bare essentials when it comes to documenting a system? In this instance specifically, what is the minimum amount of documentation needed to capture the state of an existing code base? How valuable is any documentation? It's always the first thing thrown out the door when timelines get compressed and it's typically the last thing updated after maintenance or enhancements are performed on a system.
In this instance maybe it's just more painful because there is no challenge involved. It's a straight migration of an existing system so there is none of the excitement involved in finding out what the business domain entails and trying to mate technologies to the problems facing the users of the system.
Luckily we're always running an Agile project at QSI, and this particular client is open to documenting only what is needed and not wasting money on anything more. Unfortunately this brings up the question, what are the bare essentials when it comes to documenting a system? In this instance specifically, what is the minimum amount of documentation needed to capture the state of an existing code base? How valuable is any documentation? It's always the first thing thrown out the door when timelines get compressed and it's typically the last thing updated after maintenance or enhancements are performed on a system.
Wednesday, November 21, 2007
The first of many Spring kicks arse posts
In my opinion, nothing has brought life into Java development like the Spring Framework. Enterprise development in Java 4 years ago had me scratching my head. Why do I need to implement methods in this interface when I don't declare I implement it? Why do I need Entity Beans? Which of the 8 web frameworks should I be using? Why does it take so long to go from fixing a bug to actually testing that it worked? Spring has in some way, shape, or form answered all of these questions. Well except for the 8 web frameworks one.
Spring started with a couple of developers who were as frustrated as I was with the complexity inherent in Java enterprise development. Fortunately for our community, they were and are much smarter and driven than I am and they wound up with a set of tools that simplify almost every aspect of development in a Java enterprise. I think one of the keys of Spring's success has been focusing on simplifying advanced concepts and providing extremely useful tools out of the box. This example shows how Spring has simplified Aspect Oriented Programming which was a rather radical shift for Java developers in the early days of AspectJ. Additionally it provides something that 90% of all Java projects would want out of the box. Simple entered/exited logging and performance monitoring.
This code in it's current state will provide good trace logging for any bean named *DAO or *Service. Change or add the interceptor name to PerformanceTraceInterceptor and it will provide performance metrics using the JAMon performance monitoring utility. All of this provided out of the box with Spring. Stay tuned for more Spring fanboy-ism in the future.
Spring started with a couple of developers who were as frustrated as I was with the complexity inherent in Java enterprise development. Fortunately for our community, they were and are much smarter and driven than I am and they wound up with a set of tools that simplify almost every aspect of development in a Java enterprise. I think one of the keys of Spring's success has been focusing on simplifying advanced concepts and providing extremely useful tools out of the box. This example shows how Spring has simplified Aspect Oriented Programming which was a rather radical shift for Java developers in the early days of AspectJ. Additionally it provides something that 90% of all Java projects would want out of the box. Simple entered/exited logging and performance monitoring.
This code in it's current state will provide good trace logging for any bean named *DAO or *Service. Change or add the interceptor name to PerformanceTraceInterceptor and it will provide performance metrics using the JAMon performance monitoring utility. All of this provided out of the box with Spring. Stay tuned for more Spring fanboy-ism in the future.
Tuesday, November 20, 2007
Hibernate Hijinks
I've been tasked with optimizing some slowly performing transactions in a system that has been built upon Hibernate. Yesterday I ran across an interesting situation where a single transaction was resulting in 6 separate queries to the database. This may not necessarily be bad, but when the transaction was performing as slowly as it was, we needed to take whatever means we could to speed it up. What was unique to me was that we eliminated all but 2 queries, and we eliminated each one in very different ways.
- Use the second level cache for largely read only data. There was a table that had slipped through the cracks of our investigation that will rarely be updated. A couple of configuration entries later and it will be stored in a second level cache and refreshed on a weekly basis instead of causing an extra query hundreds or thousands of times per day.
- Eagerly fetch associations that are needed every time the transaction is called. The Criteria API in Hibernate allows the user to specify the fetch mode for every association, effectively overriding the default behavior provided by the mapping file. Setting the fetch mode to Eager for this association resulted in an extra left outer join, but it eliminated an extra query per result row.
- Don't haphazardly access collections that are not needed by all of your clients. The transaction in it's previous state would call off to a dependent collection and call the size() method on it to determine how many child records were linked to the parent. This caused every child record in that collection to be loaded by Hibernate, even though very few of the clients actually needed to know the size of this collection. Adding a property to the incoming request to determine if the transaction actually needed to fetch that count and then doing it by simply executing a separate projection based query resulted in much speedier performance for all clients.
Subscribe to:
Posts (Atom)
