Repeat after me, "Sissies use GUIs. Sissies use GUIs. Sissies use GUIs."
Okay, now that we have that covered here is the command I continue to forget when trying to burn an iso onto a CD from my macbook pro.
hdiutil burn ~/Downloads/ubuntu-8.10-desktop-i386.iso
Beats fumbling around with Finder any day.
Sunday, December 14, 2008
Tuesday, December 9, 2008
Howdy Parnter!
I'm pleased to announce that Quick Solutions, Inc. is now a certified Systems Integration Partner with SpringSource.
The Spring framework is the standard for Java development. SpringSource has built upon that momentum with a keen vision in developing products and services that benefit enterprise customers using Spring. Whether it is the OSGi enabled dm Server, an instrumented version of the Spring offering with a common monitoring application, or a support model that bests Oracle, IBM, or JBoss, the future of Java development is a very clearly dominated by Spring and SpringSource.
Quick Solutions is driven by providing software based solutions to our customer's problems. We strive to do this in a manner that passes the most value on to our clients. Partnering with SpringSource will allow us to clearly articulate and demonstrate the value that their products generate within Enterprise Java development. We look forward to working closely with Rod and the gang in 2009 and beyond.
Stay tuned for some more information on making best use of the products in the SpringSource umbrella.
The Spring framework is the standard for Java development. SpringSource has built upon that momentum with a keen vision in developing products and services that benefit enterprise customers using Spring. Whether it is the OSGi enabled dm Server, an instrumented version of the Spring offering with a common monitoring application, or a support model that bests Oracle, IBM, or JBoss, the future of Java development is a very clearly dominated by Spring and SpringSource.
Quick Solutions is driven by providing software based solutions to our customer's problems. We strive to do this in a manner that passes the most value on to our clients. Partnering with SpringSource will allow us to clearly articulate and demonstrate the value that their products generate within Enterprise Java development. We look forward to working closely with Rod and the gang in 2009 and beyond.
Stay tuned for some more information on making best use of the products in the SpringSource umbrella.
Tuesday, October 14, 2008
Thank You SchemaSpy
I love open source contributors. These people are the geeks who bypass reality shows, online gaming, and time with their families so that they can bring you something that will make your life better. They get nothing in return but a "atta boy/girl" and a pat on the back.
I am taking it upon myself to give thanks to a few of these open source contributors over the coming months. I am a typically just a taker when it comes to open source, but I would like to at least let the givers know, that I appreciate their hard work and commitment.
The first shout out goes to the kind contributors of SchemaSpy. SchemaSpy allows you to generate a web based ERD of an entire database, that is easily navigated by clicking on images throughout the web application. It's a simple jar file that can be downloaded and executed on any platform that has java installed. It supports a wide variety of databases and produces a ton of information in an easy to digest medium. The first thing you'll be presented is the table listing:
This view gives you all of the tables in the system, the number of rows in each table, and a number of other tables directly related via foreign key to this table.
When you click on one of the table names you are presented with the more specific table view:
The top level of information is like a describe of the table, but checking some of the boxes will allow you to see navigable parent and child rows for each of the columns.If you click on the images in the mini-ERD at the bottom of the page, it will navigate to the appropriate tables. Also note that you can expand the mini-ERD to 2 degrees of relationships.
These features in and of themselves are enough reason to automatically document your database with this tool, but another really applicable portion of the tool is the ability to identify anomalies within the database. Clicking on that tab provides you with this view:
Here you'll see a number of bad database smells very quickly. Unleash a DBA worth their weight on this page and you'll have some table alterations done very quickly.
I honestly see no reason to not use SchemaSpy on any project that we have. It is extremely easy to use, can be integrated into a build, and provides better reference documentation on the database than the vast majority of projects I've worked on. Well done SchemaSpy crew, and a sincere THANKS!
I am taking it upon myself to give thanks to a few of these open source contributors over the coming months. I am a typically just a taker when it comes to open source, but I would like to at least let the givers know, that I appreciate their hard work and commitment.
The first shout out goes to the kind contributors of SchemaSpy. SchemaSpy allows you to generate a web based ERD of an entire database, that is easily navigated by clicking on images throughout the web application. It's a simple jar file that can be downloaded and executed on any platform that has java installed. It supports a wide variety of databases and produces a ton of information in an easy to digest medium. The first thing you'll be presented is the table listing:
This view gives you all of the tables in the system, the number of rows in each table, and a number of other tables directly related via foreign key to this table.
When you click on one of the table names you are presented with the more specific table view:
The top level of information is like a describe of the table, but checking some of the boxes will allow you to see navigable parent and child rows for each of the columns.If you click on the images in the mini-ERD at the bottom of the page, it will navigate to the appropriate tables. Also note that you can expand the mini-ERD to 2 degrees of relationships.
These features in and of themselves are enough reason to automatically document your database with this tool, but another really applicable portion of the tool is the ability to identify anomalies within the database. Clicking on that tab provides you with this view:
Here you'll see a number of bad database smells very quickly. Unleash a DBA worth their weight on this page and you'll have some table alterations done very quickly.
I honestly see no reason to not use SchemaSpy on any project that we have. It is extremely easy to use, can be integrated into a build, and provides better reference documentation on the database than the vast majority of projects I've worked on. Well done SchemaSpy crew, and a sincere THANKS!
Saturday, October 11, 2008
Book Review: The Productive Programmer
When I heard that Neal Ford was releasing a book on programmer productivity, I anxiously went to Amazon to pre-order it. Problem was that it was almost two years ago and Neal's busy schedule has kept him from finishing it for quite some time. Now that it is finally out and I've read through it (twice actually), I would highly recommend it to anyone doing software development on a daily basis.
I've seen Neal speak at a number of conferences like Codemash, NoFluffJustStuff, and eRubycon, and I've always walked away with something that will improve me as a software developer. The reason is fairly simple, Neal is at his core a developer, and more than many other speakers, he understands the problems and challenges that face developers.
The The Productive Programmer is really two smaller books slammed together.
The first part is focused on tools and techniques that help you work. I actually re-read the book a couple of times because I did a horrible job of keeping track of the utilities and power toys that I wanted to download my first time through. The second time I went through it I started putting post-its on the pages where I wanted to remember a command or download a utility that made sense. The book was littered with post its by the end of it. Neal provides a number of utilities and techniques for both Mac and Windows platforms that will allow you to work more efficiently in your day to day environment. *nix environments are notably absent here, but the command line advice provided for Macs, are obviously equally useful across any *nix distro.
The second part of the book is largely focused on how you build software. A large majority of Neal's talks at conferences carry this common theme. Neal is adept at identifying and explaining principles and patterns of development that yield the best results. Metaprogramming, TDD, Fluent Interfaces, Polyglot programming and many other topics are covered in an easy to digest manner that harkens back to the bible of software development: The Pragmatic Programmer. Neal is able to provide concrete examples throughout the book, based on his vast experience in consulting through the years.
The productive programmer is easy to read, full of valuable information, and applicable to junior developers and seasoned veterans alike. Again, I would highly recommend it to anyone developing software on a daily basis.
Monday, October 6, 2008
Looking for Smart People
I tend to mention my company, Quick Solutions, very little in order to keep some sense of journalistic integrity with this blog. Unfortunately, I'm not a journalist so I'm going to skip the pretense for at least one post.
I started working at Quick Solutions 5 years ago this month for the sole reason that I was largely unchallenged in my daily job. My thinking at the time was consulting would expose me to a variety of businesses, technologies, and projects. I was fortunate enough to prove my commitment to the company and demonstrate a sufficient breadth of knowledge that I was offered an opportunity to work within the solutions group. At the time I thought that the only difference was the type of work (project versus role based consulting).
I quickly realized however that there was something else about the group that was different. This group was choc-ful-o-geeks. And I mean that in the most sincere way possible. Conversations within the group revolved around continuous integration offerings, Java and .NET trade offs, best practices for SOA, and dynamic language use instead of the typical bitching about a lack of requirements and rehashing of the previous night's reality show. The group was filled not necessarily with Mensa members, but instead with very bright software engineers who cared about their craft. Egos are checked at the door and you could be sure that every person in the door shared a passion and ability to learn that tends to permeate good software developers.
Our company has grown throughout the years and even in a downturn of the economy, we are in dire need of people who meet the above description. If you like working with smart, passionate people please drop me a line. We are always looking to bring people in who show a passion for technology, an ability to learn, and a nack for solving problems. Additionally, if your specialty is Java development, I can give you your choice of 3 different, exciting projects, right now.
If you think you meet these criteria and are interested in working with more people of your ilk, email me at tkaufman at quicksolutions.com.
I started working at Quick Solutions 5 years ago this month for the sole reason that I was largely unchallenged in my daily job. My thinking at the time was consulting would expose me to a variety of businesses, technologies, and projects. I was fortunate enough to prove my commitment to the company and demonstrate a sufficient breadth of knowledge that I was offered an opportunity to work within the solutions group. At the time I thought that the only difference was the type of work (project versus role based consulting).
I quickly realized however that there was something else about the group that was different. This group was choc-ful-o-geeks. And I mean that in the most sincere way possible. Conversations within the group revolved around continuous integration offerings, Java and .NET trade offs, best practices for SOA, and dynamic language use instead of the typical bitching about a lack of requirements and rehashing of the previous night's reality show. The group was filled not necessarily with Mensa members, but instead with very bright software engineers who cared about their craft. Egos are checked at the door and you could be sure that every person in the door shared a passion and ability to learn that tends to permeate good software developers.
Our company has grown throughout the years and even in a downturn of the economy, we are in dire need of people who meet the above description. If you like working with smart, passionate people please drop me a line. We are always looking to bring people in who show a passion for technology, an ability to learn, and a nack for solving problems. Additionally, if your specialty is Java development, I can give you your choice of 3 different, exciting projects, right now.
If you think you meet these criteria and are interested in working with more people of your ilk, email me at tkaufman at quicksolutions.com.
Friday, September 19, 2008
Clustered Scheduling with Spring and Quartz
I initially cut my teeth as a Java programmer writing some batch JDBC programs to update various sets of data. We were deployed in a Unix environment so we traditionally wrapped all of the JDBC programs in a bash shell script and kicked that thing off via a Cron entry. This environment was successful for the most part but there were issues. If our batch machine was taken offline due to upgrades, failed disk, or coffee spill then our batch process just did not run. If we wanted it to run after the fact we had to create another 1 time cron entry to kick the thing off. This typically took about 2 hours because the first hour and a half was spent with me trying to decrypt the cron syntax (minutes first or seconds? need a question mark here but star there? comma or dash between my minutes?).
Fast forward to 2008 and I have just completed a week long adventure with a coworker finally getting Spring and Quartz up and running to kick off some batch programs in a clustered environment. Failover is automatic, ad hoc runs are possible, and I still wind up spending an hour and a half each time I have to add a cron entry. I thought I would post some code snippets with explanation so that you kind reader, could maybe trim this process down to about a day.
1.) Download Spring 2.5.5 and only use the Quartz 1.6.1 RC1 jar that is bundled within the lib directory of it. DO NOT USE A PREVIOUS VERSION OF QUARTZ.
2.) Execute your appropriate database script. They can be found in the quartz distro under the docs\dbTables subdirectory. Make sure that indexes are setup as outlined here.
3.) Wrap a batch processing service with some form of Quartz. Here's the wrapper we used:
With that wrapper, you can execute any batch processor that is wired up in Spring, that implements the homegrown IBatchProcessor interface (which typically only has some variant of an execute or invoke method). You don't need to manage the dependencies of those batch processes as they themselves are just beans defined a Spring app context somewhere. Additionally, the base class jumps through the various contexts that you must navigate to get a properly wired bean from the Spring factory.
4.) Configure the Job Detail in your Spring app context with an xml snippet resembling this:
This definition creates an instance of GenericQuartzJob (which fulfills the contract required by JobDetailBean), and plugs in the bean name of a batch processor defined somewhere else in the app context with all of it's necessary dependencies.
5.) Configure the Trigger in your Spring app context. A simple cron based version would look like this:
And yes, it did take me an hour and a half to get that cron syntax working correctly. Some habits die hard.
6.) Configure the SchedulerFactoryBean
That configuration while lengthy does a few very important things. Let's go through them. The applicationContextSchedulerContextKey property will ensure that the app context is available to all of those instances of the GenericQuartzJob wrappers. The dataSource and transaction manager are necessary in order to ensure that the database is updated in a safe manner (many server instances may be updating the database at once). Their bean definitions are pretty much typical for Spring, checkout the Spring reference docs if you need more info there. OverwriteExistingJobs will make sure that every time the scheduler is started it will use the list of triggers found internally to overwrite any existing ones that may have been changed in the database. AutoStartup makes sense, but I'm not entirely sure it's necessary.
The quartz properties can be maintained in a separate file, but I prefer they are inline with the scheduler definition. They are all pretty much self explanatory, and explained in greater detail, but nested deeply in the Quartz docs.
Hopefully this article will advance you to the point of configuring a clustered, database backed, scheduling system within hours instead of days. This configuration will get you a set of spring enabled batch processes that have dependencies wired as normal, with the added benefit that their schedule is persisted and fault tolerant across nodes in the cluster. This also leaves the door open for a couple of methods of doing ad hoc runs of the jobs. We'll cover that in a part 2 article shortly.
Fast forward to 2008 and I have just completed a week long adventure with a coworker finally getting Spring and Quartz up and running to kick off some batch programs in a clustered environment. Failover is automatic, ad hoc runs are possible, and I still wind up spending an hour and a half each time I have to add a cron entry. I thought I would post some code snippets with explanation so that you kind reader, could maybe trim this process down to about a day.
1.) Download Spring 2.5.5 and only use the Quartz 1.6.1 RC1 jar that is bundled within the lib directory of it. DO NOT USE A PREVIOUS VERSION OF QUARTZ.
2.) Execute your appropriate database script. They can be found in the quartz distro under the docs\dbTables subdirectory. Make sure that indexes are setup as outlined here.
3.) Wrap a batch processing service with some form of Quartz. Here's the wrapper we used:
public class GenericQuartzJob extends QuartzJobBean
{
protected Logger logger = new Logger(getClass(), Constants.LOGGER_APP_NAME);
private String batchProcessorName;
public String getBatchProcessorName() {
return batchProcessorName;
}
public void setBatchProcessorName(String name) {
this.batchProcessorName = name;
}
protected void executeInternal(JobExecutionContext jobCtx) throws JobExecutionException
{
try {
SchedulerContext schedCtx = jobCtx.getScheduler().getContext();
ApplicationContext appCtx =
(ApplicationContext) schedCtx.get("applicationContext");
IBatchProcessor proc = (IBatchProcessor) appCtx.getBean(batchProcessorName);
proc.invoke();
}
catch (Exception ex) {
logger.error("Unable to complete execution of " + batchProcessorName, ex);
throw new JobExecutionException("Unable to execute batch job: " + batchProcessorName, ex);
}
}
}
With that wrapper, you can execute any batch processor that is wired up in Spring, that implements the homegrown IBatchProcessor interface (which typically only has some variant of an execute or invoke method). You don't need to manage the dependencies of those batch processes as they themselves are just beans defined a Spring app context somewhere. Additionally, the base class jumps through the various contexts that you must navigate to get a properly wired bean from the Spring factory.
4.) Configure the Job Detail in your Spring app context with an xml snippet resembling this:
<bean id="someJobDetail" class="org.springframework.scheduling.quartz.JobDetailBean">
<property name="jobClass" value="com.some-company.batch.GenericQuartzJob" />
<property name="jobDataAsMap">
<map>
<entry key="batchProcessorName" value="SomeJobBean" />
</map>
</property>
</bean>
This definition creates an instance of GenericQuartzJob (which fulfills the contract required by JobDetailBean), and plugs in the bean name of a batch processor defined somewhere else in the app context with all of it's necessary dependencies.
5.) Configure the Trigger in your Spring app context. A simple cron based version would look like this:
<bean id="someCronTrigger" class="org.springframework.scheduling.quartz.CronTriggerBean">
<property name="jobDetail" ref="someJobDetail" />
<!-- Cron expression runs at 1am and 1pm -->
<property name="cronExpression" value="0 0 1,13 * * ?"/>
</bean>
And yes, it did take me an hour and a half to get that cron syntax working correctly. Some habits die hard.
6.) Configure the SchedulerFactoryBean
<bean id="scheduler" class="org.springframework.scheduling.quartz.SchedulerFactoryBean" lazy-init="false">
<property name="applicationContextSchedulerContextKey" value="applicationContext" />
<property name="dataSource" ref="qtzTxDataSource"/>
<property name="transactionManager" ref="transactionManager"/>
<property name="overwriteExistingJobs" value="true"/>
<property name="autoStartup" value="true" />
<property name="triggers">
<list>
<ref bean="someCronTrigger" />
</list>
</property>
<property name="quartzProperties">
<props>
<prop key="org.quartz.scheduler.instanceName">SomeBatchScheduler</prop>
<prop key="org.quartz.scheduler.instanceId">AUTO</prop>
<prop key="org.quartz.jobStore.misfireThreshold">60000</prop>
<prop key="org.quartz.jobStore.class">org.quartz.impl.jdbcjobstore.JobStoreTX</prop>
<prop key="org.quartz.jobStore.driverDelegateClass">org.quartz.impl.jdbcjobstore.oracle.weblogic.WebLogicOracleDelegate</prop>
<prop key="org.quartz.jobStore.tablePrefix">qrtz_</prop>
<prop key="org.quartz.jobStore.isClustered">true</prop>
<prop key="org.quartz.threadPool.class">org.quartz.simpl.SimpleThreadPool</prop>
<prop key="org.quartz.threadPool.threadCount">25</prop>
<prop key="org.quartz.threadPool.threadPriority">5</prop>
</props>
</property>
</bean>
That configuration while lengthy does a few very important things. Let's go through them. The applicationContextSchedulerContextKey property will ensure that the app context is available to all of those instances of the GenericQuartzJob wrappers. The dataSource and transaction manager are necessary in order to ensure that the database is updated in a safe manner (many server instances may be updating the database at once). Their bean definitions are pretty much typical for Spring, checkout the Spring reference docs if you need more info there. OverwriteExistingJobs will make sure that every time the scheduler is started it will use the list of triggers found internally to overwrite any existing ones that may have been changed in the database. AutoStartup makes sense, but I'm not entirely sure it's necessary.
The quartz properties can be maintained in a separate file, but I prefer they are inline with the scheduler definition. They are all pretty much self explanatory, and explained in greater detail, but nested deeply in the Quartz docs.
Hopefully this article will advance you to the point of configuring a clustered, database backed, scheduling system within hours instead of days. This configuration will get you a set of spring enabled batch processes that have dependencies wired as normal, with the added benefit that their schedule is persisted and fault tolerant across nodes in the cluster. This also leaves the door open for a couple of methods of doing ad hoc runs of the jobs. We'll cover that in a part 2 article shortly.
Saturday, August 16, 2008
eRubycon 2008 - Severely Belated Wrap Up
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.
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.
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.
Tuesday, June 10, 2008
Ruby Integration with Spring
I recently gave a presentation at COJUG on ten facilities in Spring that you may not know much about. I saved my favorite for the last. Dynamic Language integration. This facility has been around since Spring's 2.0 release, but has been mired in the relative obscurity of Chapter 24 of their docs.
While many IT managers might be hesitant to adopt a language like Groovy or Ruby for their production environment due to misconceptions about performance, security, or what have you. The management types should have very little concern with testing code making extensive use of dynamic languages. If Ruby or Groovy provides a lower barrier of entry for complex testing or mocking, why not make use of it?
Spring provides the typical DI goodness of abstracting away the underlying implementation and allowing the developer to switch from mock to production code without changing client code. In the case of Ruby backed implementations, JRuby provides the hooks to allow the .rb file to be recognized as an implementation of the Java interface.
Here's a simple interface implemented in Java with which I've created a Java and a JRuby implementation.
A JRuby based implementation of this only has a few tricks like including the library and calling a method to include the class
Finally, with the spring integration facilities, a few lines of xml locates the file and plumbs in the implementation. Client code accesses the Java interface, none the wiser to the Ruby implementation.
There are a couple of gotchas to keep in mind with JRuby/Groovy Spring integration:
- JRuby 1.1 is not supported until Spring Framework 3.0, use JRuby 1.0
- Model code after what I have above, not what is in the Spring reference docs. At last check the docs were somewhat confusing in the use of include versus include_class
- AOP can be used to wrap the dynamic beans just as if they were POJOs. The one big caveat here is to make sure they are implementing an interface. Class based proxies will not work
Spring's support for dynamic language beans is pretty powerful in it's simplicity. The uses of this technology are much farther reaching than just mock scenarios, though. JRuby or Groovy files can be polled and reloaded without compilation or server restarts. This can be immensely useful for dynamic portions of applications like lightweight rules, environment configuration, validation, or even web site navigation.
Hope this helps get you started with integrating dynamic languages into your Java code. Please leave a comment with your scenario if you are using or planning on using dynamic languages integrated with Spring.
While many IT managers might be hesitant to adopt a language like Groovy or Ruby for their production environment due to misconceptions about performance, security, or what have you. The management types should have very little concern with testing code making extensive use of dynamic languages. If Ruby or Groovy provides a lower barrier of entry for complex testing or mocking, why not make use of it?
Spring provides the typical DI goodness of abstracting away the underlying implementation and allowing the developer to switch from mock to production code without changing client code. In the case of Ruby backed implementations, JRuby provides the hooks to allow the .rb file to be recognized as an implementation of the Java interface.
Here's a simple interface implemented in Java with which I've created a Java and a JRuby implementation.
A JRuby based implementation of this only has a few tricks like including the library and calling a method to include the class
Finally, with the spring integration facilities, a few lines of xml locates the file and plumbs in the implementation. Client code accesses the Java interface, none the wiser to the Ruby implementation.
There are a couple of gotchas to keep in mind with JRuby/Groovy Spring integration:
- JRuby 1.1 is not supported until Spring Framework 3.0, use JRuby 1.0
- Model code after what I have above, not what is in the Spring reference docs. At last check the docs were somewhat confusing in the use of include versus include_class
- AOP can be used to wrap the dynamic beans just as if they were POJOs. The one big caveat here is to make sure they are implementing an interface. Class based proxies will not work
Spring's support for dynamic language beans is pretty powerful in it's simplicity. The uses of this technology are much farther reaching than just mock scenarios, though. JRuby or Groovy files can be polled and reloaded without compilation or server restarts. This can be immensely useful for dynamic portions of applications like lightweight rules, environment configuration, validation, or even web site navigation.
Hope this helps get you started with integrating dynamic languages into your Java code. Please leave a comment with your scenario if you are using or planning on using dynamic languages integrated with Spring.
Monday, June 9, 2008
Software Development Meme
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
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
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.
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...
Wednesday, January 2, 2008
CodeMash Coming Up
I was fortunate enough last year to attend CodeMash in it's inaugural event. I can say without a doubt that it is the most unique conference I've had the pleasure of attending. I'm somewhat odd in that I code daily in .NET and Java and usually play with Ruby in the wee hours of the evenings. CodeMash is the only conference I know of where I can go to sessions for all of these topics and still learn about other topics like Python, Groovy, Android, etc...
The speakers aren't just slobs off the street either. Neal Ford, Jim Weirich, Bruce Eckel, and many others will present at CodeMash this year. Always cool to go to a session of someone whose book you have on your shelf. Being able to see speakers of this caliber for less than $200 does not happen often.
I'm always up for a beer after the sessions, so let me know if you'll be attending. I'll get Mark Blankenship to buy us a round.
Oh, and did I mention it's at a waterpark? That's right, 2 conferences within a month for me where I get to hammock up!
The speakers aren't just slobs off the street either. Neal Ford, Jim Weirich, Bruce Eckel, and many others will present at CodeMash this year. Always cool to go to a session of someone whose book you have on your shelf. Being able to see speakers of this caliber for less than $200 does not happen often.
I'm always up for a beer after the sessions, so let me know if you'll be attending. I'll get Mark Blankenship to buy us a round.
Oh, and did I mention it's at a waterpark? That's right, 2 conferences within a month for me where I get to hammock up!
Subscribe to:
Posts (Atom)
