Sunday, December 17, 2006

Generalization and Specialization

I have been reading "My Job Went to India... (and all I got was this lousy book)" by Chad Fowler. I'm still in the middle of it, but a couple of sections really resonated and I wanted to jot some thoughts down while they were fresh in my mind. It is probably worth mentioning for those not familiar with the book that it is not really a criticism of India or of outsourcing in general, but rather, a pragmatic discussion of how to survive in the midst of the current trend to outsource technical work. Fowler presents his thoughts on what a person can do to keep their job domestic when so many positions are leaving the country.

A couple of his ideas are contradictory, yet complimentary. He argues that a developer should decide to be a generalist or a specialist. He compares the specialist to an assembly line worker on a mass production line. The generalist, on the other hand, is the proverbial "Jack of All Trades, Master of None". I like that Fowler tries to dispel the negative connotation surrounding this label. In Fowler's opinion, either path can lead to better protection of your job.

The generalist is able to pick up the odds and ends and minutiae left behind in the wake of layoffs or outsourcing. He argues that it is important for the generalist to understand to some level the product at both a business and technical level. At the product level, understand the customer needs and business case for the product. At the technical level, not only should you understand the code used to realize the product, but also the architecture, test strategy, and deployment process. The generalist should also be careful not to fixate on specific technologies, e.g., code versus database, Java versus C#, etc.

A specialist can make his or her self safe in a different way. This is accomplished by understanding an area of technology to a depth that qualifies this person as a guru. By doing so, the developer becomes the indispensable resource of last resort, turned to when the really hard technical issue crops up that the rest of the team can't resolve. Fowler is quick to point out that this is a difficult state to attain. One example he uses is an interview question, "How would you write a program, in pure Java, that would crash the JVM?" He argues that unless you understand the internal workings of the JVM (which would include the threading model, memory management, and instruction generation), you aren't a Java specialist.

As an aside, I don't consider myself to be a Java specialist, but my first thought was to exhaust memory, but I am sure there are faster ways to crash the JVM.

While he didn't come right out and say it, I got the feeling that Fowler sees generalization versus specialization as an either/or proposition and that he maybe leans a bit towards favoring generalization. While I concur that generalization is a better survival strategy, I think there is room in the generalist’s repertoire for some degree of specialization. In my mind, a melding of the two ideas is very compelling.

I consider myself to be a generalist. I am a degreed electrical engineer. I have experience with digital electronics. I spent the first four years of my career coding in assembly for an embedded real-time system. I also wrote real-time firmware in C and C++. I have written graphical applications for Windows and the original MacOS. I am currently developing middleware apps in Java. I also have experience with scripting languages such as PERL, TCL, and Bash. I wrote some SQL and am currently learning the Hibernate ORM utility. Next up is Groovy. The list of things to learn is very long and is growing faster than there is time in the day.

I don't mention this to toot my own horn, but to support my hypothesis that I am a generalist. But I am also a specialist, albeit what I will term an opportunistic, short term specialist. Invariably, during certain stages of a project, I wind up learning something to a detail that meets Fowler's definition of a specialist. The area of the specialty varies from project to project and because of this variability, the half-life of my "specialist" qualification is short in duration (on the order of 1-2 years). For example, in the mid-90's, while working in the test and measurement industry, I became an expert on the IEEE 488.2 and SCPI command sets for instrument command and control. I knew the vagaries of the standards and what requirements needed the most work in the code. Ten years later, the details escape me, but at the time, when a question was raised about these protocols, folks came to me. The same has occurred in other industries, including understanding drug interaction for IV compounding, VME and VXI bus protocols, ISDN signaling (LAPD and Q.921), and currently, I am immersing myself in the agile methodology, SCRUM. In the spirit of "use it or lose it", when I move on to other projects, the details get fuzzy, but I always try to adopt at least one topic to focus on and embrace in a detailed sense.

The side-benefit of this strategy is that even when the details fade, much of what I learn can still be applied in a general fashion. Which supports my initial statement that I am a generalist. In summary, as a generalist, sometime specialist, I can attest to Fowler's thesis that developers who adopt these strategies maximize their chances of staying gainfully employed. It has worked for me.

Sunday, December 03, 2006

The Open Source Community... Loony or Enlightened?

I attended the Lightweight Java seminar with a colleague last week. The seminar was hosted by Virtuas. Virtuas is a services company specializing in open source software. Their stated mission is to assist their clients in becoming self-sufficient users of open-source software. More on this is a minute, but first a quick overview of the seminar itself, which was composed of four talks.

The first talk covered the Java Persistence Architecture, or JPA, which is part of EJB3. A simple description of JPA is annotation support for persistent objects. The JPA is defined in JSR 220 and represents an attempt to simplify J2EE. Since I'm not an "enterprisey" guy, I can't discuss how well it addresses this need. I do have some experience with JPA, as it is implemented in Hibernate. I will be giving a talk of my own on JPA use with Hibernate in January at the Boulder JUG. I will be focusing on the use of annotations in Hibernate without the use of XML configuration, so definately an anti-enterprise spin. I will post the preso after the JUG. At this talk, the speaker had a great example of persistence using a snake object that eats rabbit objects. Call me twisted, but I liked it!

The second talk covered Spring 2.0. Spring, in keeping with the "lightweight" theme of the seminar, provides a lightweight container environment that simplifies the use of other open source components including Hibernate, AOP, web services, LDAP, ACEGI security, an MVC controller, and more. Of course, "simple" is relative. In the case of Spring, this means that while you write less code, you substitute large XML configuration files. Anymore, every time I am told "less code through configuration", I feel like I am at a timeshare sales presentation. Caveat emptor! Even with the configuration overhead, I do think that Spring brings a lot to the table. It is definitely on the list of things to get up to speed on.

The third talk covered AJAX and JSF along with the DOJO library (word of advice, 4.0 is buggy, us 3.1 for now). These are tools that make some great web interfaces. Added to the list.

Finally, a talk on the AppFuse 2.0 framework. This framework ties all of the other pieces together when developing web apps. Since I don't do much web development at this point, some of the talk was lost on me. Probably the biggest take from the talk is that Maven is getting bigger and is now on the LOTTD (yeah, it's a long list).

Prior to the seminar, we weren't sure what to expect. We halfway expected to be subjected to a non-stop flood of markitecture. On top of that, the weather was really crappy. We really debated attending. Fortunately, we decided to go. It was definitely worth braving the weather. When we first arrived, we found that we were getting an amazing "goodie bag", which included three great technical books (on Java, Spring, and Eclipse) and a nice day-planner. The goodies were courtesy of SourceBeat. Want to impress a geek? Give them tech books! And it just got better from there. After a very short (less than 10 minutes) introduction of the company, they jumped right into the presos. Not only no markitecture, Virtuas took the soft sell to the extreme... almost a no sell? The great goodies, excellent talks, and lack of sales pressure all contributed to the inspiration of this blogs title. Can a company, which depends upon revenue from consulting on products that are free, be successful when using a marketing tool such as this seminar? I hope so.

As a way to say thanks, I started thinking about what I could do to help them. I'm not really in a position right now where I need their help, but I will keep them in mind for future issues. In the meantime, I am hoping that by blogging about them, I can help is some small way to get the word out about this enlightened (as opposed to loony) company.

Monday, May 15, 2006


Presented by Stuart Halloway, Relevance, LLC

ACEGI is a generalized authentication and authorization system for Java, with specific hooks built-in for the Spring Framework. Since my experience with such systems is light, my ability to cover what was presented will be correspondingly basic.

The name ACEGI is not an acronym. It is derived by using the first 5 odd letters of the alphabet. Like most Spring-based services, ACEGI relies heavily on XML-configuration files. It is built using the Inversion of Control pattern and with dependency injection, it is possible to modify behaviors of the security system. One key example pointed out by Stuart in the talk was that JAAS security library, which (if I remember correctly) is part of the Java standard, can be used as the authentication server instead of the default service provided by the ACEGI distro.

The key components of an ACEGI based system include:

  • Authentication

  • Authentication Manager

  • Access Decision Manager

  • Secure Object Interceptor

  • Run As Manager

  • After Invocation Manager

The last two components are only used in special cases. A simple use case would be:

  1. User submits principle (user) and credential (password) to Authentication object

  2. The Authentication Manager populates the Authentication class with Authorities (permissions) based upon the provided Principal and Credential

  3. User invokes the desired method, which is intercepted by the Secure Object Interceptor (shades of AOP at work!)

  4. The SOI queries the Access Decision Manager regarding whether the request can proceed

  5. The ADM passes this query on to the Authentication object, which accepts or rejects the request based upon the stored security data

  6. Assuming the request was allowed, the SOI then invokes the actual method requested by the user

Because of the use of AOP, it is possible to add security to objects that were not even designed with security in mind!

Internally, the Authentication object and the Access Decision Manager use a collection of web filters that are responsible for the ultimate processing of the security requests. These filters are configured in an XML file (another example of IOC and DI use). Several examples of how these filters are used were presented in the class. This turns out to be one of the more difficult concepts in using ACEGI. It turns out that these configuration files must be carefully constructed and the order of the filters must follow explicit rules in order for the system to work correctly. Stuart is a big fan of this system and even he had harsh criticism to levy about this issue.

As mentioned earlier, a lot of the details are being elided here, mostly because of my ignorance of security. Based upon the examples shown in class however, I believe that it would be very straightforward to set up a secure system (typically web-based, but that isn’t required) using the ACEGI Security system.

Sunday, May 14, 2006

NFJS - Spring AOP

Presented by Stuart Halloway, Relevance, LLC

This seminar provided a deeper dive in to AOP with Spring. As mentioned earlier, Spring uses Dependency Injection and the IOC pattern to minimize dependencies. But sometimes, there are dependencies that are too broad to be removed using DI. In many of these instances, AOP can solve the problem. The simple (yet powerful) example Stuart provided was that of three inheritance trees:

SuperBeing SoftwareProject
^ ^ ^
| | |
| -------- |
| | |
SuperHero SuperVillain OpenSourceProject Server


Assume that each of the classes has an attribute name and we need to validate the name when it is set. Placing a name validation method in each of the four concrete classes would result in repeating the code four times. But since we understand OO concepts, we move the method into the base classes to reduce repetition. Now we only have to repeat the code three times!?! Not a great improvement. But with AOP (in Spring), we write the name validation method one time and using a Spring configuration file, attach the method to every class that needs it. This, in a nutshell, is what AOP is all about. Note that this mechanism is so powerful, we could add the name validation method to a class even if we don’t have the source code for it.

The name validation requirement in the previous example is referred to in AOP as a “cross cutting concern”. In non-AOP systems, cross cutting concerns often result in a lot of code duplication. When this code is isolated in one place with AOP, it is referred to as “advice”. The point where advice is applied in the code is called a “joinpoint”. A collection of all joinpoints for a given piece of advice is called a “pointcut”. The combination of a pointcut with its advice is called an “aspect”. Lots of new terminology, but it didn’t take long for it to make sense.

Stuart presented several examples that illustrated how aspects could be applied to a class, including method intercept, before method, after method, and throw only. The Spring framework implements AOP natively and is relatively easy to use. For higher efficiency implementations, Spring also supports AspectJ. It was mentioned that it is straightforward to start with Spring AOP and migrate to AspectJ.

It should be pointed out that the primary mechanism for implementing aspects is to modify the byte code of the class being aspected. It was interesting that Stuart offered the same advice on concerns about this that Dr. Venkat Subramaniam did at a JUG meeting a couple of months ago, which was, “Get over it!” Stuart followed this with an observation that wound up being a “Got it!” moment for me. He compared people who complain that they can’t directly see aspects in the code and therefore worry about what is being executed to similar criticisms in the past about OO and how you couldn’t see what code was being executed because of inheritance hierarchies. Not only do I remember these criticisms, I was guilty of making them early on (he admitted shamefully). So I am happy to say that I have “gotten over it” and am really looking forward to investigating AOP. I’ll probably start with the Spring version, but hope to try AspectJ soon as well.

NFJS - Introduction to Spring

Presented by Stuart Halloway, Relevance, LLC

Stuart is a consultant out of North Carolina. As you will see, I attended many sessions presented by him. He is very dynamic, very knowledgeable, and has a great sense of humor. He also covered lots of Spring topics, which helped as well.

According to Stuart, Spring is Australian for no EJB. As an aside, he said that “having a pulse is Australian for no EJB 1.x or 2.x”. Kind of puts where he is at in perspective.

Spring is a framework that attempts to solve problems typically solved using J2EE, but in a more lightweight fashion. Based on what I heard over the weekend, I tend to agree. At its core, Spring is based on three core concepts. Configuration, Dependency Injection, and Aspect Oriented Programming.

Spring’s answer to configuration may be the most controversial of its features. The basics of a Spring application require minimal code, but the cost of this is large configuration files written in XML. I lost track of the number of times over the weekend a disparaging remark was made about XML. I do wonder why as much as the experts seem to dislike XML, it is still so prevalent. Anyway, if you are going to use Spring, you are going to use XML.

Dependency Injection is the mechanism that allows the details to be encoded in an XML configuration file. DI is based upon the Inversion of Control pattern. The idea is that an object doesn’t “reach out” to get other objects it needs (typically by calling new). Instead, the dependencies are “pushed to” the object from external sources. The means of this injection can be via constructor arguments or via bean-like setters. If the object is designed to depend only upon interfaces, DI can be used to modify object behavior by injecting specialized objects which implement these interfaces. And in Spring, the XML configuration files allow the injected objects to be changed without changing the code.

J2EE also uses an IOC pattern, but realizes it via context or JNDI lookups, which according to Stuart is more cumbersome. Also, evidently Spring minimizes the number of dependencies upon itself, while such dependencies are prolific in J2EE. Never having worked with J2EE, I am parroting what I heard at the seminar. I did find the explanation of Spring much easier to comprehend compared to some J2EE classes I took last year.

The final core component of Spring is Aspect Oriented Programming. If I took nothing else out the symposium, I learned that AOP rocks! I had some exposure to AOP prior to NFJS, but the message was really brought home in Stuart’s talks. I took an entire seminar on Spring and AOP, so I will cover the details in an upcoming blog. Again, the biggest downside to AOP in Spring is the massive XML burden it brings along.

During this talk, Stuart also presented examples of support services provided by Spring. He showed an example using a JDBC that showed how simple it was to connect to a database from a Spring container. He followed that up with a Hibernate example. I am really interested in Hibernate and it is dead easy to use in Spring, but for now, I plan to learn stand-alone Hibernate so that I really understand it well. After that, I will probably explore using it in Spring.

The last topic Stuart covered was Spring’s answer to security, called ACEGI. Again, I took an entire seminar on the topic, and so will reserve the details for a later blog.

NFJS - Intro

One of my goals for the year was to improve my technical skills, particularly related to Java surround technology. One of the first things I did to realize this goal was to start attending meetings of the Boulder Java User’s Group and Denver Java User’s Group. Both JUGs attract excellent speakers who cover interesting and relevant topics. If you live in the Denver area, I highly recommend attending.

While I will probably blog more on these meetings at a later date, the point today is that through these meetings, I learned of the 2006 Rocky Mountain Software Symposium, a.k.a, the No Fluff Just Stuff Tour. The symposium was held near Avaya and after looking at the seminars available, I decided I wanted to attend. The first option, obviously, was to pay for it myself. While I was willing to do so, I decided to first see if Avaya would foot the bill. The company ended up sending me along with two co-workers. SCORE!!!

It was well worth the time. I learned a lot of great stuff.

Future blogs will summarize the seminars I attended. Along the way, I will also share some of the most interesting ideas and soundbites that I took away from them.

Until then, here are some general soundbites I took away from the speakers and attendees…

  • Java is not just a language, it is a framework.

  • Who needs architects?

  • Right to left scheduling. <= One of my favorites!

  • And a bonus quote from a speaker (I wish I could remember who) at a local JUG:
    • Any project with more than 10 team members is bound to fail!

Monday, May 08, 2006

Why am I blogging...

Short answer, cuz all the cool kids are doing it!

Longer answer. I've really enjoyed reading other peoples blogs. In particular, a friend of mine writes on some interesting things. A local technical author has also peaked my interest. And while Joel On Software isn't really a blog, Joel uses it as a forum to share ideas, which I hope to do as well.

My focus will be on some kind of geeky things, but I reserve the right to stray into unfamiliar territory when the mood strikes. I probably won't be the most consistent blogger in the world, but since I won't be the most scintillating either, you won't be missing much.

First up... The No Fluff Just Stuff seminar.