Code Syntax Highlighting

Here is a plug-in that formats code (Java, xml, etc) within html in a very nice way.
http://code.google.com/p/syntaxhighlighter/

This looks great. I'll be adding this functionality ASAP to handle code snippets.

Injecting a Spring Bean into a Servlet

I've done some searching on the web for how to cleanly inject a spring-managed bean into a servlet. There are a number of ways, but I believe this is the cleanest.

Assuming you have a bean, limaBean, that you want to inject into a servlet, here is the applicationContext.xml:

  <bean id="limaBean" class="com.example.LimaBeanImpl">

  <bean class="org.springframework.web.context.support.ServletContextAttributeExporter">
      <property name="attributes">
          <map>
              <entry key="limaBeanInServletContext">
                  <ref bean="limaBean">
              </ref>
          </entry></map>
      </property>
  </bean>

The ServletContextAttributeExporter takes an existing managed bean, 'limaBean', and injects it into the ServletContext under the name 'limaBeanInServletContext'.

The servlet accesses this bean like:

public class DocumentViewerServlet extends HttpServlet
{

  public void doGet(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException
  {
      LimaBean limaBean = getLimaBean();
      limaBean.doSomething();

     ...
  }

  private DocumentService getLimaBean()
  {
      ServletContext servletContext = this.getServletContext();

      return (LimaBean) servletContext
          .getAttribute("limaBeanInServletContext");
  }
}

At runtime, Spring will inject the bean and everything works.

The reason you wanted to inject the bean in the first place, though, was so that you could easily write a test that injects the bean.

Set the attribute on org.springframework.mock.web.MockServletConfig and pass that into the servlets init(ServletConfig) method.

public class VegetableServletTest extends TestCase
{
  private VegetableServlet servlet = null;
  private LimaBean fakeLimaBean = null;

  protected void setUp() throws Exception
  {
      super.setUp();

      servlet = new VegetableServlet();
      fakeLimaBean = new FakeLimaBean();

      MockServletConfig config = new MockServletConfig();
           config.getServletContext().setAttribute("limaBeanInServletContext", 
           fakeLimaBean);
   
      servlet.init(config);
   }

}

Cedric Beust vs Robert Martin

Cedric Beust recently launched a broadside attack on agile software development titled Agile People Still Don't Get It. Bob Martin returned fire today in a post strangely titled Agile People Still Don't Get It.

Cedric says that tests are not specs while Bob states that "a test is an unambiguous specification of behavior." I don't think that you can argue against the latter claim, but at the same time I don't think that a test is enough. There needs to be an agreed upon contract between the business folks and the developers as to what is going to be delivered. That contract is not going to be a unit test. I have yet to see a business person write a JUnit or TestNG test case, be able to read one or the other, or care to even try. Tests should be one means of meeting the contract.

Agile development practices are hands-down better at delivering projects on time, with lower defect rates, and with higher customer satisfaction. One of the core tenets is not to be afraid of changes in requirements. However, changes still need to be tracked. A check-in comment to the source control system and a unit test is not enough when the system has gone into production and someone claims that some feature is not working according as agreed.

This does not mean that everything has to be spec'd out before a line of code is written. Specs should evolve just like the code and tests.

I think that Martin bests Beust in the discussion of whether "If it's not testable, it's useless" is accurate.

Cedric Beust:

Software is shipped with untested parts every day, and just because it's not entirely tested doesn't mean it's bad software or that the untested parts are "useless".

Agilists just don't understand the meaning of calculated risk.

Robert Martin:

Here's the thing. If you can't test it, you don't know that it works. If you don't know that it works, then it's useless.

I feel like Beust is punting on this point and Martin is a bit too strict. There are things that are hard to test. The attempt should be made, but not at the cost of neglecting higher priority tasks.

Cedric then goes on to criticize agile developers as being smug and dishonest. I do not believe that agile developers are dishonest, but I have met a few who are very smug and I believe they, like Ruby proponents, could tone things down a notch.

Robert Martin shows real class in his summation and shows that Cedric Beust is wrong in thinking that all agile developers are rabid ideologues:

Agile is not a silver bullet. Agile is not THE ANSWER. But Agile techniques, and especially TDD, are very powerful techniques to get software written well, and to increase the level of professionalism in our industry.