Nick Sieger: software engineering

Maven-proxy in ruby

Sat, 26 Nov 2005 22:57:05 GMT

Lothar Märkle has a neat little perl CGI substitute for Maven proxy. I started to use it to build up a Maven 2 repository at work for our Maven 2 builds. Only when it wasn't quite behaving as I expected, I really didn't want to brush up my perl skills to debug it. Why do that when you can spend an afternoon polishing up a ruby version?

So here's maven-proxy.rb, version 1.0 (download zip). Check it out, I think I baked in a couple extra neat features, including the ability to transparently navigate remote, uncached directories from your local repository. I also gave an example Apache configuration to let Apache serve the cached content while deferring to the CGI for the remote, uncached resources. It's licensed under an MIT-style license, so I only ask that you give me credit (or blame) for the original code :)

If you ask me, this is better than running the original maven-proxy under Tomcat...

Happy Holidays!

Microsoft, Competition and the Right Fork

Wed, 14 Sep 2005 02:43:21 GMT

So, it turned out to be a well-timed Gillmor Gang this week for me, as I started listening to it on the same day as the PDC keynotes were webcast.

It seems that Microsoft is fast approaching a fork-in-the-road. The left fork represents the illusion of continued desktop dominance fueled by Wall Street hunger for sky-high profit margins in the Windows and Office businesses, and is very much grounded in the 20th-century Microsoft. The right fork represents the future of the company, battling for market share in a Web 2.0 world, innovating both in the rich client and web application arenas, playing fair by creating and building open standards, and doing all of this in such a way that the end user comes out the winner.

So which way will they go? Where's the new revenue model in the open world of the web when your sacrifice your existing business to get there? That's the big white elephant in the room at PDC.

Microsoft, stop charging for the tools. If Avalon, Indigo, Atlas, LINQ, Max and all the other goodies being dangled in front of developers this week are to ever gain any widespread adoption, they need to be accessible to the hobbyists out there. Give away IIS. If Apache is already free, what incentive is there to run IIS? Give away SQL Server, to at least level the playing field with MySQL. Give away Visual Studio, allow companies to develop and deploy ASP.NET and Indigo applications to their heart's content. Make it possible for the hacker in the basement (i.e., me) who's taken up Ruby on Rails to try your way of building web apps.

Jon Udell tells a good story in the Gang podcast of the difference between TerraServer and Google Maps. TerraServer has been out for years, has a public API, and yet has not inspired innovation or remixing in the way that Google Maps has. The conclusion was that Microsoft has too long focused on the developer as a professional ISV. In this scenario, the ISV is just a middleman preventing and stifling user innovation because the cycle is too lengthy. By the time developers have gotten around to building and distributing apps and getting some level of user adoption, there's no where left and no reason for the user to innovate -- it's too late. Of course, user customization and innovation is what the new 21st century web is all about.

So, Microsoft, take that leap of faith, get your stuff out there, gain adoption through cool, fun, programmer-friendly, easy-to-use tools and an open platform. Compete based on speed of innovation and the ability to retain a user base through that innovation without locking them in. Choice is what builds trust.

Take the Right Fork.

Using Drools, If It Weren't For All That Bloody XML

Sat, 03 Sep 2005 04:23:31 GMT

Rule engines, at the outset, appear to be a nifty concept for making Java applications more late-bound, dynamic and configurable. Drools in particular even seems to be getting some traction as I've seen in mentioned several times over the past few weeks. But why, oh why do they insist on the angly-bracket, ugly XML syntax?

Maybe I'm just a Ruby-as-platform-for-building-DSLs convert, but doesn't this seem a whole lot more readable than that mess of XML that Drools uses?

require 'drools'
require 'daofactory'
require 'stockoffer'

class StockOffer
  def print
    p "Name: #{@name} Price: #{@price} BUY: #{@recommend_purchase}"
  end
end

class BusinessRulesSample < Drools::RuleSet
  application_data DaoFactory

  rule "XYZCorp" do |rule|
    rule.accepts StockOffer
    rule.salience = "-1"
    rule.condition {|stock| stock.name == "XYZ" }
    rule.condition {|stock| stock.recommend_purchase.nil? }
    rule.condition {|stock| stock.price > 10 }
    rule.consequence do |stock|
      stock.recommend_purchase = :no
      stock.print
    end
  end

  rule "Stock Price Not Negative" do |rule|
    rule.accepts StockOffer
    rule.condition {|stock| stock.price < 0 }
    rule.consequence do |stock|
      stock.recommend_purchase = :no
      stock.print
    end
  end

  rule "Stock Price Low Enough" do |rule|
    rule.accepts StockOffer
    rule.condition {|stock| @dao_factory.stock_dao.on_stock_list? stock.name }
    rule.condition {|stock| stock.recommend_purchase.nil? }
    rule.condition {|stock| stock.price < 100 }
    rule.consequence do |stock|
      stock.recommend_purchase = :yes
      stock.print
    end
  end
end

Goodbye OSCON

Sat, 06 Aug 2005 21:27:27 GMT

What a whirlwind week at OSCON! I'm still spinning and trying to catch up on sleep the day after getting back home from my first O'Reilly conference experience.

For me, the main themes this week were Java, Ruby, Ajax/Remote scripting and Subversion. I have some skeleton outline notes from several more talks that I'll put online shortly at my OPML blog. I'm still too overwhelmed to form these into fully coherent thoughts, and each could easily generate multiple blog postings.

Off the top of my head, here are a few random thoughts that were floating through my head this week:

If you want to meet the best hackers in the world, come to OSCON. Open source programmers are the most passionate of their kind, and where there's passion there's intelligence, community and great ideas.
If you want to hire the best hackers in the world, come to OSCON. The networking opportunities are absolutely incredible -- I was blown away. Now actually convincing a hacker to come work for you is a different story. It would help if your business had some kind of open source strategy, so that the hacker can continue to participate in the community and give back what he or she works on at your company. Non-open-sourcers will find it unreal, but it is possible to contribute to an open source community and still receive a lot of business ROI from the exchange. Paul Graham is quite possibly the most articulate speaker you could find on this subject. I was at his What Business Can Learn From Open Source keynote and it immediately struck me as great fodder for discussion at the cube farms back at work.
Damian Conway is an evil genius. And his arch nemesis may be Danny O'Brien.
As I mentioned it was my first time at OSCON, and I was really surprised to find the whole OSCON community extremely friendly and receptive. I never sensed any elitist attitudes (not that there probably aren't any here or there) and never felt like an outsider. To me, it's important that the community retain this sense of welcoming and open-ness so that we can further the cause and be better positioned to promote change for good in the world.
Ruby is a super cool language, but it's not a panacea. There is still lots of room for growth in the language. During Matz's talk he mentioned that he wants to implement a sealing feature of some kind so that some Ruby code could be locked down or scoped to a single file only (unlike the current implementation where you can change any class, anywhere, on the fly). Ruby still seems a year or two away from fuller adoption in the enterprise, although that's not going to stop me from trying to use it.
Likewise, Java's not dead either. The same players in the Java open source community are around and are still committed to the language. However, the politics can tend to get a bit more ugly.
Subversion is ready for primetime and I can't wait to roll it out at work.

Like I said, my head is still reeling and my blood still pumping after a high-octane week. I'm looking forward to stepping up my involvment in the open source community and I hope to maintain contact with all the folks I had the pleasure of meeting during the conference. Cheers!

Ruby on rails trials on OS X

Wed, 25 May 2005 04:35:58 GMT

Finally sitting down play with rails on OS X. I had previously built Ruby 1.8.2 from source and installed into /usr/bin on top of OS X's default ruby -- seemed to work fine. Now, just upgraded to Tiger last weekend, got as far as creating a new rails model, when I got a nifty little error:

Access denied for user: 'root@localhost' (Using password: YES)

Seems that Tiger broke ruby for more folks than just me.

Whiz-bang-crash, several packages later...

fix-ruby-tiger.sh from above
download, build and install fastcgi
download and install MySQL 4.1.12 from an OSX binary package
download, build and install mod_fastcgi (apxs works!)
install mysql gem (gem install mysql -- --with-mysql-include=/usr/local/mysql/include --with-mysql-lib=/usr/local/mysql/lib)

So far, so good, but haven't reached the kicker yet...what amazes me though through this whole process is how transparent it all is. It's happening on a Mac, but it's all good ol' FOSS that configure && make && make install's as good as on any other box (except XP :).

A java webservice toolkit (and it's name does not begin with A)

Thu, 07 Apr 2005 16:22:28 GMT

Just recently started work on a project which requires the use of WS-Security. I was initially skeptical about the whole WS-* stack in general, especially with the REST/SOAP debate that's so hot recently. My own design philosophy favors simplicity anyway, and just trying to follow the WS-* specs makes me dizzy.

So imagine my surprise when I stumble across Sun's webservices stack! Why didn't I think to look to the gatekeeper of Java? Because it didn't come from Apache or the the Codehaus? (Hani would laugh at that one.) I had been using trusty Axis for well over a year now, but WSS4J is lagging behind and doesn't even have any downloadable release out. Worse, I'd be forced to upgrade to the yet-to-be-released Axis 1.2? Thank you Sun, no thanks, Apache.

Oh, and what's this? Sun and Microsoft are playing well with each other? We'll see shortly just how true that is.

Holub's axiom

Thu, 24 Mar 2005 04:56:13 GMT

From an old javaworld article I ran across from Allen Holub:

...maintainability is inversely proportionate to the amount of data that moves between objects.

Increasing coverage and refactorability in legacy code

Sat, 19 Mar 2005 04:01:44 GMT

It's been over a month since I said I'd write more about Increasing coverage and refactorability for code with no unit tests, so here's my shot.

So here's the scenario: You're faced with trying to improve a large body of existing code with few to zero unit tests. The code itself is fairly monolithic, has a high degree of coupling, and maybe has an abuse of singletons, static registries or factories and too much "new" operator on large service components that make it really difficult to test a single class at a time.

To make matters worse, methods are large, the business logic isn't clear, the original requirements that drove the code (if any) aren't available. It's a tangled mess! Do you Have This (Anti-) Pattern?

So all I have is a hypothesis and some intuition, but here's the general sequence of actions that, if taken, may go some of the way toward solving the problem of increasing coverage and making it easier to refactor legacy code. The central tool in your toolbox for making this happen is none other than FIT.

What you're using FIT for in this case is for a higher-level testing tool to get some coverage for business cases that you may be able to discover, hopefully by finding and talking to a business expert. Using FIT allows you to automate the tests and get faster feedback than you would having to manually click through interfaces in your application.

Start to write a FIT test page that covers an aspect of the code you're targeting for increased coverage.
Start writing the FIT fixtures that will enable you to run the test. (If you're suffering from another anti-pattern of having too much application logic inside your MVC layer, you'll find that if you're writing action fixtures, during this stage you may have to duplicate large chunks of application logic that you have to cut and paste from models and/or controllers. Add another item to your list to clean up later.)
Run the test(s).
If possible, use a coverage tool such as Clover to see how much coverage you were able to buy with your tests. Now you have a concrete metric for what code you may be able to refactor.
Refactor mercilessly on the code within the coverage zone, treading lightly on code that is not covered.
Re-run the tests to make sure you haven't changed any behavior.
Once you've refactored a reasonably small, unit-testable component out of the quagmire, write a unit test for it. You still want a unit test to cover your code in the long run as this will allow you to develop and improve the code even more quickly than you can with FIT.
Repeat the entire cycle to spread out and cover other areas.

I haven't yet had an opportunity to put this to practice myself, but I'd be interested to hear if anyone else has tried something similar. If you have, drop a comment!

Postel, for my own posterity

Thu, 10 Mar 2005 03:28:21 GMT

Carlos recently again referenced Postel's Law, which basically goes,

Be liberal in what you accept, and conservative in what you send.

I have probably heard this somewhere before, but anyway just wanted to jot it down for reference.

But as the query results show, there was quite a storm in the blogosphere around Postel's law a little over a year ago. It appeared to be no more than a squabble about how liberal is "liberal". (Reminds me of Clinton: "...depends upon what the meaning of 'is' is...")

My personal view is that you should only bend over far enough and with enough common sense to fill in the blanks. XML well-formed-ness has been a known quantity for some time; I still have a hard time seeing the argument why anyone would want to be so liberal as to accept non-well-formed XML. Sure, it happened with early HTML and the web, but was HTML that well defined during the early days of the web?

Freemind and WSDL

Wed, 02 Mar 2005 04:31:13 GMT

I'm experimenting more and more with Freemind as a visualization tool. This time with WSDL. I've taken the Amazon Web Services WSDL and applied this XSL transform to produce the following Freemind map:

(Browseable applet coming soon I hope, but for now here's a screenshot)

Evolutionary database applications

Sat, 26 Feb 2005 04:43:58 GMT

Brian had a comment for clarification on Quote and database evolution that I thought I'd take the time to clarify. I said:

It's intriguing to me that the application I've worked on for going on four years as well as my own perception of what has worked well over that timeframe has followed a pretty similar evolution as what Brian describes in his rant about databases.

...to which Brian asked:

In terms of what you did with it, or level of frustration at building things around the problem instead of solving problem?

I'd have to say what we did with it. I'm feeling the need to tell a story here, bear with me...

I feel like the application has turned out well from a technical standpoint precisely because we were in a position early on to build on the database without making it the focal point of the application. This is in contrast to some of the other applications in production at our company. One of the older applications is written almost entirely in PL/SQL, so there was an obvious database focus there and the development culture that sprung up around it was such that, for a while, the DBAs were king and the programmers had to answer to them.

It seems like a fluke that our app turned out the way it is. There were a lot of factors that played into this over time, many of them cultural/non-technical. Fortunately, early on we somehow had the leeway to build away for the database. Because we were almost starting greenfield, we didn't have to initially deal too much with the DBAs, since they were occupied with maintaining the production databases.

The app wasn't exactly greenfield because we were building off a newly-acquired codebase, but it still needed plenty of work. The codebase had a horrible proprietary persistence mechansim that included an infamous "magic container" table called MHASHTABLE that held all associative relationships for every object in the system (!). Because this would obviously not scale for a consumer-facing hosted commerce engine that had to be capable of serving tens of thousands of transactions per day (think of the rate of growth of that table!), we had to rip it all out and re-do the persistence layer. Basically anything we might come up with would probably be better than this beast, so perhaps we were left to just do our thing.

Our architect at the time was following persistence technologies trying to get an idea of what direction to go in, and JDO as a standard was just coming out (0.9 in the fall of 2001). The only viable alternatives were expensive, proprietary tools like TopLink. After some brief prototyping, we decided to build our own SQL JDO implementation.

One of the loose requirements that the DBAs did give is that they needed to be able to have control over the queries. They thought that they would get some sort of set of configuration files containing query templates that they could tweak to their hearts' content. Instead, we gave them JDO, with fetch groups and dynamic SQL generation. After they saw how well it worked, they didn't bother to complain about the lesser amount of control they got. The SQL, though dynamic, was predictable, uniform, and based upon primary keys or indexable "pseudo" foreign keys. (Pseudo- because we actually have no foreign key constraints at all on our tables for better insert performance and so we don't have to worry about proper ordering of deletes. Once, when giving an overview of our JDO-based persistence to a new DBA, her mind was blown away at that fact -- it apparently went against everything she learned about building databases!)

We were able to build the JDO implementation in an evolutionary way to match the growing, changing needs of the application. As a result, we don't quite have a full-featured, to-spec implementation, but we don't need it. There are quirks in the way we do things like complex subqueries or inheritance (I had no prior background in O/R mapping and basically learned on the fly), but we've got enough features (most of JDOQL, bytecode enhancement) to give an approximation of transparent persistence. In all my experience as a developer the amount of transparency we were able to create with our JDO implementation is probably one of the slicker things that I've had a hand in building. It was transparent enough to allow the rest of the development team to not have to worry about how to persist their objects, to have to remember what the proper way is to close a JDBC connection; but opaque enough so that we could performance tune it to our needs. There were some tough times when develpers would encounter a bug in the JDO engine that they'd have no idea what was going on, but today the codebase is so stable that it's hardly an issue.

(As a brief aside I still don't think I'd advocate building your own persistence engine, especially today with all the open source options available, but for us it was the right thing to do at the time and we were able to make it work well for us.)

So, with that long yarn I don't know if I completely answered your question Brian, but the main takeaway for me is that I've seen both sides of the fence, but I much prefer the side that I'm on with the database only playing a supporting role in the functioning of our app.

There's a thread in my mind somewhere here about the crucial importance of being able to do evolutionary application development (as opposed to big-bang or in-a-vacuum development) in which environment of course the database (and the "DeeBeeAies") must play well, but I'll leave that thought for another day.

The Java Platform

Fri, 25 Feb 2005 02:46:16 GMT

RMH is writing a book about the "Java Platform". It's not just any book, and I applaud him for taking the particular step of saying it's not a for-profit venture and it's not going to be a traditionally organized, TOC'd and outlined book. (Although he may as well just collect blog posts about the java platform for a period of time and collect them together and say "This is Java".)

One thing in particular in his preface struck me -- the mention of J2ME and J2EE not being long on the world. I think this is sensible; more and more people are finding great ways of innovating on the core JVM and language platform itself, the Groovies and AspectJs and CGLIBs and Picocontainers of the world are all based on the core J2SE platform. J2EE is just Sun's officially sanctioned way of building enterprise applications. Beyond perhaps .war and web.xml files, there's really not much else in J2EE that will have a long life in the Java world (although any BEA-er, JBossian, Oracle-ite or IBMian appserver vendor would like to tell you otherwise).

As for J2ME, it will simply be obsoleted by its bigger brother. At some point mobile device technology will mature enough to be able to host the full J2SE stack and we won't have to worry about obfuscating and re-jarring class files and developing in a completely different way than we would for standard Java applications.

Agile or Fragile?

Thu, 24 Feb 2005 03:10:57 GMT

Another nice podcast from IT Conversations. I'm about 2/3 the way through this long podcast but already I definitely agree that it's well worth the 4 star rating.

Scott blends metaphors well when talking about software development and tools. Would you do software development with only one vendor's toolset? That's like using only one brand of tools in your toolbox. I think Paul Graham in his Great Hackers talk mentioned how the best hackers have a passion for great tools. A good hacker/developer/however-you-wish-to-be-called is particular about using the correct tool for the job, and is passionate about trying new tools and acquiring them for his or her personal development toolbox.

Another interesting discussion is around the idea of how would you build a project team? With generalists or specialists?

With generalists, no one has sharp enough skills to actually implement requirements.
With specialists, each person has their own domain-specific language and artifacts need to be handed off between different members of the team. Pretty soon you're tracking deliverables and maintaining way more documentation than necessary.

Of course the solution is to bring on folks that feel comfortable in multiple disciplines. Ambler calls these "generalized specialists". Since everyone on the team has at least a solid baseline in software development processes, a common (ubiquitous to use Eric Evans' term) language can sprout forth easily. Of course these folks will generally be more experienced and sharper all around (and be more expensive), but you get what you pay for. So as always, the philosophy of hire the best is manifested in some shape or form.

Freemind and OPML take 2

Wed, 23 Feb 2005 03:46:17 GMT

A follow-up on FreeMind and OPML -- so the impending 0.8 release is chock full of new goodies including a MM-to-OPML XSL file and an export option that allows you to apply an arbitrary XSLT. Nice work guys, but I still think that the UI should somehow auto-detect all transform files available (both in the distro plus the user's freemind directory) and create menu options for each in the Export submenu instead of forcing the user to select the transform...maybe the next iteration?

Quote and database evolution

Wed, 23 Feb 2005 03:34:21 GMT

Today's quote courtesy of Brian McCallister:

If you are worried about correct behavior, write tests.

If you are worried about integration, expose an integration API via messaging or SOAP.

If you are worried about your job, produce useful software.

It's intriguing to me that the application I've worked on for going on four years as well as my own perception of what has worked well over that timeframe has followed a pretty similar evolution as what Brian describes in his rant about databases.

Thanks for the astute and honest observations, dude.

FreeMind and OPML

Fri, 18 Feb 2005 05:25:34 GMT

I just discovered FreeMind, and am all jittery with excitement about a new tool to try out and see if it fits the way my brain works. All early signs point to yes...

It seems that since FreeMind is at its core a fancy graphical outliner that it should support OPML natively. The only answer given is :

It should be easy to create conversion XSLT between FreeMind and OPML.

These guys have created a great program with a solid UI and decent usability, yet they don't understand how big a benefit interop with growing standards like OPML would give them? At least give me built-in "Import from OPML" and "Export to OPML" commands so that non-techie users don't have to a) write an XSL transform; b) write scripts to run it on their .mm files just to get to OPML. At best FreeMind is a nice toy program right now; if it groked OPML it suddenly jumps into a whole new class of eminently useful applications. Imagine being able to import the Podcast directory (OPML) into FreeMind!

Users GOOD

Wed, 16 Feb 2005 15:25:18 GMT

Another quote of the day:

If you want to do something that's going to change the world, build software that people want to use instead of software that managers want to buy.

Brought to you by the indefatigable JWZ.

RESTless applications

Wed, 16 Feb 2005 02:30:39 GMT

An article that looks to be worth reading -- I've also posted over to del.icio.us...

One of the things I frequently criticize SOAP and XML-RPC for is doing everything through POST. Of the many problems with doing everything through POST, the biggest is that there are things that could be better done through GET. Well, the Amazon Queue Service does everything through GET, and no, that's not a good thing. Let's take a look.

Agile Manifesto

Tue, 15 Feb 2005 03:41:40 GMT

A quote for today:

Continuous attention to technical excellence and good design enhances agility.

That pretty much summarizes the attitude I try to take to work every day...

Oracle does not grok transparency

Fri, 11 Feb 2005 15:55:58 GMT

Oracle just does not get it! Any java programmer who has written code against an Oracle database knows about the dreaded CLOB issue -- string values over 4000 characters cannot be stored using PreparedStatement.setString; instead you're forced to bind to Oracle's proprietary oracle.sql.CLOB class. In the new 10g release, Oracle claims to have rectified the issue, but in actuality all they've done is up the limit to 32765, unless you set a "SetBigStringTryClob=true" property in the connection or data source. When you're Oracle, you don't have to play by the rules, apparently...

Increasing coverage and refactorability for code with no unit tests

Fri, 11 Feb 2005 05:02:47 GMT

Note to self: I have some new ideas about improving test coverage and refactorability for a legacy codebase with few existing unit tests where writing tests is extremely hard due to high coupling. Hopefully more to come on this soon...

Backspacing over unicode characters

Tue, 08 Feb 2005 03:41:14 GMT

Does your browser backspace correctly? Follow the title link and page down a bit and try it out. Interesting how easy it is for folks to not get this right -- even the demigods over at Firefox.

The post itself is a little Microsoft-centric (as it's from an MS employee), but contains a good bit of info.

Maven alternate test suites

Thu, 04 Nov 2004 22:50:28 GMT

A common complaint of Maven's integrated testing plugin is that it only allows you to define a single test suite. I figured out a way to implement alternate test suites by tweaking the project configuration and adding a little extra jelly script. It would be nice if this was a standard feature of Maven, but at least the amount of extra jelly required is minimal.

In my case, I wanted an acceptance testing suite that contained all the integrated components tested as a whole.

I put the acceptance tests in ${project.home}/src/acceptance-test (instead of the Maven standard ${project.home}/src/test).
I set the property maven.test.search.classdir=true in project.properties.
I set the include pattern for tests in project.xml as **/*Test.*. This is because setting maven.test.search.classdir=true requires Maven to search for tests by class, not by source file. Doing this allows Maven to find the unit tests in the unit test output directory and the acceptance tests in the acceptance test output directory.

I put the following jelly code in maven.xml. If you wish, you can keep it in a separate file (say acceptance-test.xml) and import it in your main maven.xml with a

<j:import inherit="true"
       file="${basedir}/acceptance-test.xml" />

import statement.

<?xml version="1.0"?>
<project xmlns:j="jelly:core"
         xmlns:maven="jelly:maven"
         xmlns:u="jelly:util" 
         xmlns:define="jelly:define"
         xmlns:ant="jelly:ant">

    <goal name="acceptance:init">
        <j:set var="maven.test.dest" value="${maven.build.dir}/acc-test-classes" />
        <j:set var="maven.test.reportsDirectory" value="${maven.build.dir}/acc-test-reports" />
        <j:set var="maven.test.searchdir" value="${maven.src.dir}/acceptance-test" />
        <ant:path id="maven.test.compile.src.set">
            <ant:pathelement location="${maven.test.searchdir}" />
        </ant:path>
    </goal>

    <goal name="acceptance:compile">
        <attainGoal name="acceptance:init" />
        <attainGoal name="test:compile" />
    </goal>

    <goal name="acceptance:test">
        <attainGoal name="acceptance:init" />
        <attainGoal name="test:test" />
    </goal>

    <goal name="acceptance:single">
        <attainGoal name="acceptance:init" />
        <attainGoal name="test:single" />
    </goal>

</project>

Web acceptance testing

Thu, 04 Nov 2004 17:26:48 GMT

A critical part of XP is automated acceptance testing, whether through the Story-test driven development of using FIT and fixtures or through some other mechansim. A whole crop of functional web testing frameworks exist of various quality:

Recently I came across an interesting approach that combines Latka with Apache JMeter's proxy record functionality and uses Maven to record a Latka script. Yeah, I know, maven, latka and jelly, the bane of a java open source, but it could be a quick way to get some web acceptance testing going.

Story-test driven development

Wed, 27 Oct 2004 05:11:24 GMT

Attended a talk last night about Story-Test-Driven Development. More to come on this as I need a little while to digest, and to research FIT frameworks. I must say that the idea of having provable tests that tell you exactly when the business needs are satisfied could be immensely useful in any situation, not just XP environments.

Links to follow: