I don’t always agree with Mr. Yegge, but this is a great presentation/script on Dynamic Languages with some very interesting ideas and discussion topics.

One point that he never actually got to, but one that I think is worth more discussion - how do you maintain a million-line codebase w/out static types?

My answer is that with a good dynamic language, you have some seriously elegant features and patterns that allow you to keep the size of your codebase small.  Essentially, you don’t maintain a million-line codebase - because it doesn’t take a million lines to write your application.

Which fits in with some of the agile concepts as well - if you are building a project in an agile style, the constant refactoring and removal of technical debt will keep the application smaller and lighter.  The unit tests ensure a clean level of separation of concerns, the DRY and YAGNI principles reduce bloat.

Mastering the art of command line jujitsu is something every developer (regardless of OS) should strive for. While OS UIs are becoming more and more slick and helpful tools are abundant, possessing the ability to drop into a console and efficiently knock something out (find . -iname *.java | xargs egrep -i “todo” anyone?) has come in handy, for me at least, on more than one occasion.

For instance, every modern IDE now has a plug-in that facilitates working with Subversion– in fact, when I made the switch to Subversion from CVS a fews years back, I initially failed to even learn the Subversion commands– my favorite tools did it all for me graphically! Yet, in some cases I found myself distrusting the implementations these tools provided– for instance, one of my favorite CVS commands was cvs -nq update, which effectively tells you what’s changed in your local sandbox as compared to the tip of the CVS repository. This, of course, is handy in figuring out what you plan on committing; hence, I would run this command before a cvs commit so as to filter out unneeded changes.

This developmental cadence of making changes and checking them against the tip (and consequently committing them) is actually common among SCM systems– the cadence has three steps:

• updating a local sandbox to reflect what is in a repository
• understanding what has changed locally
• committing local changes into a repository

With Subversion, these three steps can be achieved via the command line with three commands:

• svn update
• svn diff
• svn commit

The svn update command takes any changes in a Subversion repository and pushes down to a local sandbox. For instance, if more than one person is making changes and committing those changes into a repository, when another person runs the svn update command, those changes will be literally downloaded into that person’s sandbox.

Using the update command is as easy as opening up a console and typing:

tty:~/dev/projects/easyb/ yts$ svn update

If there are changes in the repository, you should see some scrolling text like so:

U    maven-plugins/maven-easyb-plugin/src/main/java/org/easyb/maven/StoryReportMojo.java
U    maven-plugins/maven-easyb-plugin/src/site/apt/usage.apt
U    maven-plugins/maven-easyb-plugin/src/it/story-report-location-test/pom.xml
U    maven-plugins/maven-easyb-plugin/src/it/site-examples-test/pom.xml
U    intellij-plugins/easyb-plugin/easyb-plugin.iws
U    intellij-plugins/easyb-plugin/src/main/java/org/easyb/plugin/ui/EasybPresenter.java
U    intellij-plugins/easyb-plugin/pom.xml
Updated to revision 329.

Note, the U means updated– there are other characters for new files added, merged, in conflict, etc. What’s key here is that by running the update command, your local sandbox is in sync with what’s on the server. Running this command often often means you’ll probably avoid conflicts too!

After you’ve made some local changes, it’s often times helpful to capture what those changes were– if you’ve been working for any length of time or working with more than one file, you’ll most likely find the diff command indispensable.

Like the update command, diff can be run via the command line like so:

tty:~/dev/projects/easyb/ yts$ svn diff

This command will compare what’s in the repository with what’s in a local sandbox; what’s more, it’ll report on the exact changes as follows:

Index: behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story
===================================================================
--- behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story        (revision 322)
+++ behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story        (working copy)
@@ -4,7 +4,7 @@
 description "this story is fleshing out fixture logic for scenarios"

-each "some description" , {
+every "some description" , {
     given "a value", {
         value = 12
     }
Index: src/groovy/org/disco/easyb/StoryBinding.groovy
===================================================================
--- src/groovy/org/disco/easyb/StoryBinding.groovy      (revision 322)
+++ src/groovy/org/disco/easyb/StoryBinding.groovy      (working copy)
@@ -102,7 +102,7 @@
       listener.describeStep(description)
     }

-    binding.each = {  description = "", closure = {} ->
+    binding.every = {  description = "", closure = {} ->
         beforeScenario = closure
     }
     return binding

As you can see in the text above, the local code (labeled as “working copy”) has changed the each call with every, which appears in revision 322 of the repository.

Once you’ve reviewed these changes and are happy with what you’ve got, you can then proceed to push these changes into the repository via the svn commit command– of course, this assumes you’ve run a local build and it passed successfully, right?

tty:~/dev/projects/easyb/ yts$ svn commit -m "updated dsl to use every instead of each"

Note that the commit command can take a flag (-m) that enables you to specify a comment. You should see some text indicating the changes are being pushed into the repository.

Sending        easyb/behavior/groovy/org/disco/bdd/prototype/FixtureFeature.story
Sending        easyb/src/groovy/org/disco/easyb/StoryBinding.groovy
Transmitting file data ..
Committed revision 325.

Note how these changes increment the revision number in Subversion– this is key as all commands allow you to work with various revisions (via flags); hence, by knowing a particular revision, you can logically branch if needed.

These three Subversion commands will come in handy if you aren’t already using them; hence, learn them now! Indeed, for becoming one with the command line is the path to enlightenment.

We had a proxy problem with Selenium RC today. The site-under-test is behind a proxy, and has the same domain name as the production site (let’s call it shop.mystore.com). Normally, developers set their proxy server in their browser, which then causes requests for shop.mystore.com to go to the proxy server which then sends the request to the developer site-under-test, instead of going to the production site.

We want to set up Selenium so the developers can created automated tests around visiting the site-under-test.

Selenium does have the ability to do a “double proxy”, using system properties:

java -Dhttp.proxyHost=proxy.server.com -Dhttp.proxyPort=3128 -jar selenium-server.jar

But it turns out, unfortunately, that this doesn’t seem to work in practice. After some investigation of my own, I discovered that the proxy configuration file (proxy.pac) in Selenium is not generated properly.  My own tests, and a timely visit to this discussion of the proxy chaining issue, it appears that there’s a simple workaround:

java -Dhttp.proxyHost=proxy.server.com -Dhttp.proxyPort=3128 -jar selenium-server.jar -avoidProxy

Setting -avoidProxy causes the proxy configuration (proxy.pac) to work properly, sending the selenium requests to the developer site-under-test.

The ThoughtWorks Anthology by ThoughtWorks is a collection of essays which covers a broad range of problems facing IT industry and developers in particular throughout the software development life cycle. You’ll find tons of pragmatic advice to improve the efficiency of your development efforts.

In this book, you’ll find essays on varied topics like refactoring build files, testing for enterprise applications, single click software release and many more.

This book well justifies its addition to the prestigious ranks of Pragmatic Bookshelf. It is well taken and timely, some of the material covered is just mind blowing. This is the real book you need if you are using TDD or planning to, an absolute must-read on the subject.

The book is aimed at several different audiences. The book’s coverage of its subject matter is exhaustive and obviously expert.

Highly Recommended. Stay tuned for a detailed chapter wise review.

This was discovered with Clover 2.2.1

We have a build.xml file with the following pseudo-flow:

• clover-setup
• // this causes all future compilations to use the clover compiler to instrument the files.
• compile
• javac _all_source_
• test_A
• javac _unit_test_source_ // yes, this is a subset of all source
• junit _unit_tests_
• 
  
• test_B
• javac _unit_test_source_ // yes, this is a subset of all source, and redundant with test_A
• junit _integration_tests_
• clover-report
• NO DATA!
  

By inserting < clover-log / > at the end of test_A and test_B, I figured out what was going on.

1. after test_A, we have a nice coverage level
2. but at the end of test_B, we have been reset back to 0

My hypothesis is that there is a bug in Clover that causes it to:

a) wipe out all of the coverage data thus far when new code is compiled.

b) prevent new code from updating the coverage database.

And sure enough, by removing the javac compilation step from test_B, we have an accurate combined coverage report.

Moral of the story:

1. Do all of your compiling before you run any of your automated tests
2. < clover-log / > is your friend.

Jim York, a long time Stelligent friend, a Certified Scrum Trainer and lean and agile coach, is conducting a Certified ScrumMaster class May 5-6 in Vienna, VA.

Learn the essentials of working as ScrumMasters, Product Owners, and Scrum team members in this highly-interactive 2-day class. Jim creates an energized learning environment where participants engage in discussion, hands-on simulations, and role play to explore the nuances of Scrum in action. More than an intellectual exercise, Jim challenges attendees to connect Scrum practices to their underlying guiding principles. This class provides what you can’t get from a book — guided experiential learning in realistic scenarios.

Sign up today as space is limited!

Calling all blokes and sheilas– this year’s Asia-Pacific CITCON will be in Melbourne, Australia on June 27th & 28th– registration is now open so claim your spot before space runs out (space is limited to the first 150 tall poppies, surfies, and all around dags)!

If you dream about CI, yabber about TDD, live for BDD, or constantly think about automated deployments, then the Continuous Integration and Testing Conference is a ripper of a time, mates! The conference is free and is run as an OpenSpaces event, so there’s no reason not come. Remember, space is limited so sign up now!

Let’s say you have a fairly complicated build structure, with multiple batch files that fire off different aspects of the build (even if, at the end of the day, they just call ant).

And let’s assume that for various historical reasons, these batch files encapsulate their environment variables using SETLOCAL and ENDLOCAL.

At first glance, this is a pretty cool way to scope out your environment variables. But then, you find out that Hudson determines if a build has succeeded or failed by looking at the %ERRORLEVEL% environment variable. If it is not 0, the build has failed.

Uh oh. Your build is failing, but the moment ENDLOCAL is called, %ERRORLEVEL% is set back to its previous value, which, most likely, will be 0.

Given this situation, how do you get the %ERRORLEVEL% back up to Hudson? Well, don’t call ENDLOCAL. Instead use:

EXIT %ERRORLEVEL%

at the end of your batch file. This works because there’s an implicit ENDLOCAL at the end of your batch file, and EXIT will return the ERRORLEVEL as the exit value.

So you want to build a set of automated tests using Selenium against your webapp. I’m going to assume you have already figured out how to launch your app and set the database into a known state.

Now, you want to write some tests that mimic visiting the website and interacting with the UI in various ways.

I’ve been playing with Selenium quite a bit recently, and I’ve assembled a short list of things that will hopefully make other people’s lives easier.

Building your Tests : Navigation

• Use Selenium IDE (Firefox Plugin) to develop the navigation flow for you. The last thing you want to be doing is debugging your navigation steps in your test case so you can get to the target. With Selenium IDE, you get your app running, and record the clicks and actions you take to get to your destination.
• When you finish recording, you can export your test as a java program, or in several other languages. Take advantage of this!
• To click on a link - if you assume you have a link like: < a xhref=" Your Text Here < / a > you can get the Selenium browser object to activate the link by issuing browser.click(”Your Text Here“);

Building your Tests: Validating Results

Selenium has XPath support, and XPath is a very powerful tool for processing HTML. But the syntax of XPath is quite arcane, and I spent waaaaaay too much time trying to decipher what was wrong with my XPath query.

• Use XPath Checker (firefox plugin) - go to the results page, and control-click to bring up the XPath Checker browser. Then you can experiment with various XPath expressions until you get the one that works for your particular page and content.
• To find if text appears anywhere on the page (also known as the quick-and-dirty method) - use assertTrue(browser.isTextPresent(”Your Text Here“));
• To find if text appears in a specific sub-location, the easiest way I have found is:
• assertEquals(”Text“, browser.getText(”//table[@id=’whatever’]//tr[2]/td[1]”));
• Selenium is smart about pulling all of the text out of a set of cells, subtags, whatever, so even if that text was nested inside a div, a span and a link, it would still find it.

Running Your Tests

• You can’t use Selenium inside your tests unless the Selenium RC Server is running - launch it before you start your tests, like you would Cargo, your database, etc.
• It’s a proxy, so you have to make sure that the port you use in your code (default: 4444) is the same as the port that Selenium server is running on.

Hopefully this will help some future person get up to speed faster.

Wednesday, April 16th: 3:00pm – 4:00pm ET

Are you seeking to improve the development practices of your organization? Has your team adopted a continuous integration strategy? Are you looking for the best tool to manage your builds? If so, this webinar hosted by Paul Duvall, author of the Jolt award-winning book on Continuous Integration, needs to be penciled into your calendar.

Entitled, “Continuous Integration: Improving Software Quality and Reducing Risk,” the webinar will tackle key topics and practices in the areas of continuous database integration, testing, inspection, deployment and feedback.

If you’re a lead engineer, architect, or development manager striving for greater confidence in your software product, you should tune in to find out more about how CI helps reduce key project risks such as late defect discovery, low-quality software, lack of visibility, and lack of deployable software. Additional topics on the discussion table include:

• How to use CI leveraging a combination of CI, build, test and inspection tools
• How to make integration a “non-event” on your software development projects
• How to reduce the amount of repetitive processes you perform when building your software
• Effective practices and techniques for using CI with your teams

Registration is required for this event and available at: https://www1.gotomeeting.com/register/656993026?Portal=www.gotomeeting.com