Database Migrations: Fail when database is out of date

The latest release of the Carbon Five Database Migration maven plugin supports a new goal: check. The check goal fails the build if the database isn’t up to date. That is, if there are pending migrations the plugin produces a clear message explaining that the database is out of date and lists the pending migrations. Run mvn test and see something like this:

[INFO] ------------------------------------------------------------------------
[INFO] Building Gearlist - Data Access
[INFO]    task-segment: [test]
[INFO] ------------------------------------------------------------------------
[INFO] [db-migration:check {execution: default}]
[INFO] Checking jdbc:mysql://localhost/gearlist_test using migrations at src/main/db/migrations/.
[INFO] Loaded JDBC driver: com.mysql.jdbc.Driver
[WARNING] There are 2 pending migrations: 
 
    20100116010256_audit_tracking.sql
    20100121052539_add_daily_reports.sql
 
    Execute db-migration:migrate to apply pending migrations.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] There are 2 pending migrations, migrate your db and try again.

It’s very easy to include the check goal in your build lifecycle if you’re already using the db-migration-maven-plugin.

...
<build>
    <plugins>
        <plugin>
            <groupId>com.carbonfive.db-support</groupId>
            <artifactId>db-migration-maven-plugin</artifactId>
            <version>0.9.9-m2</version>
            <executions>
                <execution>
                    <phase>validate</phase>
                    <goals>
                        <goal>check</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <url>jdbc:mysql://${db.host}/${db.name}</url>
                <username>${db.username}</username>
                <password>${db.password}</password>
            </configuration>
        </plugin>
    </plugins>
</build>

Check out the project home for additional documentation and details. There’s also a simple, complete example application showing off this configuration.

Enjoy!
Christian

Erector views – undefined method `default_url_options’

I’m posting this because it took me too long to figure this out. Hope it saves someone else some trouble. If you want to use named route helpers to generate urls in your erector widgets you need to include ActionController::UrlWriter in your class, like so:


class Views::Layouts::BasicPage < Erector::Widgets::Page
include ActionController::UrlWriter
...
end

Automatically deploying to Engine Yard Cloud

I’m working on a application which is deployed to Engine Yard’s Cloud infrastructure and I wanted to automatically redeploy the application whenever our tests passed on our continuous integration server.

Engine Yard will eventually allow us to push a branch to our cloud environment from git (ie “git push engineyard master”) but until that is available the best option seems to be to trigger a github post receive hook directly.

To that end I rewrote an existing script to trigger post receive hooks as a rake task; http://gist.github.com/271433
Continue reading ‘Automatically deploying to Engine Yard Cloud’

Recipe for Simple Agile Retrospectives

After my talk at the Commonwealth Club last week our good friend Darren from Stimulant followed up with me to get a summary of the simple agile retrospective technique I described.

I thought I’d just send him to Google but a search for agile retrospective returned descriptions that seemed too heavy weight for the small, skilled, agile-literate teams we employ at Carbon Five.

There is certainly a lot of valuable information and insight out there I and definitely suggest doing some reading to understand the fundamentals and options for running retrospectives. However, since we want to do retrospectives often, we need a practice that doesn’t take much time or effort.

Here’s a recipe we are using these days. You can do this in 30 minutes. I actually did this with our architect for a home renovation project I am working on. Great things came out of it. I think it might have blown their minds.

Setup

Get alll team members in a room with a few stickies each.

You’re here to talk about an iteration, project, or other unit… with the goal of improving the next time around.

Thoughts: 5-10 min

Smiley face on stickies with good things from the last iteration.
Frowny face with concerns, risks, fears,…
You don’t have to be exhaustive, use the time you allocate.

Cluster: 5-10 min

Create two teams.
Give the smiles to one and the frowns to the other.
Group the stickies into related clusters.

Discuss: 20 min

Identify the primary smiley clusters.
Confirm that you will continue to see these benefits, can you increase them?

Identify the primary frowny clusters and list the themes on a whiteboard.
Vote to discuss – each team member has 4 votes – put dots next to
the issues you want to discuss.
Discuss the top 3 issues – identify SMART (http://en.wikipedia.org/wiki/SMART_criteria) steps to address them.

Rinse, wash, repeat. Don’t feel you have to talk about everything. You are trying to focus on top issues. Once you address those, the next most important issues will surface for discussion.

We do this every other week with our internal team and monthly including our clients.

If you have other recipes for simple reflection, I’d love to hear them.

Fail Early and Often at the Commonwealth Club Wed Dec 9

Please join us for an Evening Program at the Commonwealth Club in San Francisco for my presentation on techniques for creating a culture of learning, quality and collaboration in your organization. I will be sharing insights including failures and lessons learned from Carbon Five’s almost 10 years of creating web-based products.

Light reception to follow. We hope you can hang out after for a glass of wine and to catch up before the holidays.

http://tickets.commonwealthclub.org/auto_choose_ga.asp?area=2&shcode=1501

Fail Early and Often: Innovative Practices for Online Development
Alon Salant, Principal, Carbon Five

Organizations today increasingly struggle to create compelling software products, web sites and social media while working with the daunting details of limited time and resources. Learn new ways of working and delivering early value with simple and easy-to-apply processes from a pioneering software development firm. Discover how agile techniques and tools have helped to sculpt new strategies and sustainable practices, leading to more success, faster turn-around and reduced expenses.

Location:
Commonwealth Club Office
585 Market Street, 2nd Floor
San Francisco, CA 94105

Telephone Reservations: (415) 597-6700

Time: 5:30 p.m. networking, 6 p.m. program, reception to follow
Cost: $8 members, $15 non-members, $7 students (with valid ID)

This is an open invitation. Please share with others.

Unit testing JavaScript with Blue Ridge

My current rails project is using Blue Ridge and the tool set it bundles together (Rhino, env.js, Screw.Unit, and Smoke) to write test driven JavaScript. The ability to write tests of my JavaScript, in JavaScript, as efficiently as I can test other languages has forced me to rethink how I structure my work and I’m writing better code because of it.

There are a couple of different options for JS testing available at this point but Blue Ridge’s plugin is the first I have seen which made writing test driven code as easy as I have come to expect while still providing all the functionality I need. In particular;

  • Running my tests in a browser is fast. Refreshing fixture pages to rerun tests is dramatically more efficient than waiting for selenium tests to cycle.
  • I can debug my tests as they run against their fixtures pages and inspect or manipulate the DOM at any point.
  • I have mock and fake objects available to test behavior and stub out dependencies.
  • My JS tests run in continuous integration, just like all the other tests.

By writing fixtures pages and tests first I am immediately using all of my code in two locations and running it against slightly different DOMs. That has pushed me to encapsulate most of my code as jQuery plugins and think carefully about how much I depend on the page’s structure. I end up with terse selectors instead of using whatever attributes are readily available and a clear configuration point for my page’s behavior as I chain together plugin calls in $(document).ready().

We’d like to see what other developers have done and share what we have learned so far so Carbon Five is hosting an open discussion of JavaScript testing in our office this week.

Topic: Javascript Testing
When: Tuesday Nov 17
6pm: arrive/network
6:30 – 8 presentation and discussion
Where: Carbon Five office: 171 2nd Street, 4th Floor

Please RSVP if you would like to attend.

Secure Email with Spring’s JavaMailServer and Gmail

Both Carbon Five and my ISP have moved email management over to Gmail.  While this has been a net improvement for me as an end user, it’s made it a bit more difficult to configure my applications to send outgoing mail.  It isn’t hard to find examples online that explain how to configure Spring’s JavaMailSender to work with Gmail.  But none of the examples I’ve found provide a configuration that can be switched between Gmail and an open SMTP server with a few reasonable external properties (an important feature in an application that needs to be deployed in varied environments).  What’s worse, the configurations tend to differ with no rational provided for the necessary parameters.  So I spent some time with the source and a debugger and came up with a simplified solution:

<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
  <property name="defaultEncoding" value="UTF-8"/>
  <property name="host" value="${mail.host}"/>
  <property name="port" value="${mail.port}"/>
  <property name="protocol" value="${mail.protocol}"/>
  <property name="username" value="${mail.username}"/>
  <property name="password" value="${mail.password}"/>
  <property name="javaMailProperties">
    <props>
      <prop key="mail.debug">${mail.debug}</prop>
      <prop key="mail.${mail.protocol}.auth">${mail.smtp-auth}</prop>
    </props>
  </property>
</bean>

The properties for an open server look something like this:

mail.host       = localhost
mail.port       = 25
mail.protocol   = smtp
mail.smtp-auth  = false
mail.username   =
mail.password   =
mail.debug      = false

And the properties for gmail look something like this:

mail.host       = smtp.gmail.com
mail.port       = 465
mail.protocol   = smtps
mail.smtp-auth  = true
mail.username   = my.email@address.com
mail.password   = mypassword
mail.debug      = true

The host, port, username, password and debug properties should be obvious.  The key is to change the protocol between ’smtp’ and ’smpts’.  The only real difference between smtp and smtps is that the later causes JavaMail’s SMTPTransport object to open an SSL socket to the server.  Gmail only accepts SSL connections on port 465.  After figuring this out, I was glad to see that Gmail was accepting my connections, but immediately frustrated to find that JavaMail was no longer attempting to authenticate before sending mail.  The trick is that JavaMail checks its transport related parameters under ‘mail.[protocol].[parameter]‘.  This appears to be an entirely undocumented feature of JavaMail.  Fortunately, we can substitute the protocol name into the parameter key as well, so our auth parameter still works with either ’smtp’ or ’smtps’.

C5 Test Support new addition: FunctionalTestRunner

We’re always looking for new ways to test our applications and we’ve been trying a few new things on our projects. One of the recent additions is a JUnit test runner designed to help make writing and running functional tests easier. In Javaland, we use Selenium and/or HtmlUnit for our functional tests. These are the tests that run against a deployed application over the wire using a real or simulated browser. Most of our functional tests work the application in the same way a real user would, testing sequences of realistic activity and often touching a number of pages. Since our functional tests use either a real browser or a simulated one, Javascript is executed and assertions made on the results. This gives us greater confidence that our app is really working, end to end.

Here’s the high-level flow that the functional test runner provides:

  1. Load fixture data from a DBUnit dataset.
  2. Download and install the application server (if necessary).
  3. Start the application server (using Cargo).
  4. Deploy the application, waiting until it’s completely started.
  5. Run one or more functional tests (using your preferred testing framework – Selenium, HTMLUnit, etc)…
    If a test dirties the database in a manner that must be reset, the test class can be marked with the @DirtiesDatabase annotation. This will reload the database fixture and optionally restart the application.
  6. Shutdown the application server.

Continue reading ‘C5 Test Support new addition: FunctionalTestRunner’

Agile Practices… visualized?

Only pure agile devotees will find it interesting… Revisiting agile methodologies, I wanted to solidify my understanding of the differences between agile, scrum, XP, etc. I went through a mini-research project of reviewing the “canonical” sources of these practices, and then built a quick visualization to clarify my understanding:

http://ndpsoftware.com/agile_methods/agile_methods.html

Hint: Try dragging around the boxes to see how practices are related to each other.

Warning: If it doesn’t draw anything interesting for you, refresh your browser… there’s a large component of “randomness” to the algorithm and it can get stuck easily.

Warning II: Don’t leave it running in your browser, as it’s somewhat sluggish Javascript… this was a demo thrown together in a couple hours.

Web Application Testing @ SDForum October 6th

Updated: Added links to presentation and source code.

I’ll be down in Palo Alto speaking about Automated Web Application Testing Tuesday October 6th. If you’re interest in getting a peek at the typical Carbon Five Java web architecture along with a variety of strategies and techniques for testing, c’mon down and join us. The session will be primarily code-driven. I’ll implement a few features along with unit, integration and functional tests and show off some of the techniques and custom tools that help keep things simple and easy during development. Some of the topics include:

  • Brief overview of our typical web architecture and tools stack
  • Differences between Unit, Integration and Functional Tests
  • Dealing with the database (schema and fixtures)
  • Where does test coverage pay off the most?
  • In-browser and out-of-browser functional testing
  • Carbon Five best practices, custom tools and techniques
  • And more…

You can find the gritty details on the SDForum site.

Doors at 6:30 and the show begins at 7:00. Hope to see you there!

Here are the artifacts from the presentation: