The course was laid out in a novel way – as a scrum project itself! As Product Owners we were asked to compose User Stories capturing what we hoped to learn from the course, and at the end of each “iteration” within the two-day course, were asked to re-prioritize these, knowing time was tight and we may not get to all topics. This helped us to have hands-on experience with Story creation and re-prioritization, with the added bonus of us each being personally invested in the outcome instead of it being a theoretical scenario.

One of the topics I was interested in was how to adapt the scrum process for a Product Owner that is not only not on site, but is overseas and in a different time zone. At 2Paths, one of our larger projects that was recently completed involved a client overseas. This project was very successful, and we accredited much of its success to our client’s buy-in and participation to our scrum process. We had, however, modified the traditional scrum process to accommodate our client’s schedule and time availability. Because they were quite busy with other projects, and due to the large time difference, the client didn’t attend our daily scrum as is recommended. Instead we had weekly phone check-ins which augmented our regular email communication to discuss issues as needed.

I was hoping in the course to see if there would be a more recommended way for this sort of Product Owner to be involved in a project, and how we could try to more closely follow the traditional scrum process. However, the course was more geared towards an internal Product Owner. This type of Product Owner would be a lot more hands on, would physically attend the daily scrum, and spend time sitting within the dev team to facilitate clearer communication. It also seemed that many of the other course attendees had similar project roles where the Product Owner was in-house. From what I could gather, I think we handled our process as well as we could given the circumstances.

The course was well organized, and the two presenters Bryan Stallings and Skip Angel were quite knowledgeable and helpful. We had many good group discussions and participants actively participated, sharing their own war stories. I’d recommend this course for other ScrumMasters wanting to get a better sense of what is required by a Product Owner, and how they fit into the scrum process.

After sifting through some of the more flaky and new-agey aspects of the book (such as the suggestion to carry wishing wand and courage stick icons around in your pocket for empowerment), I found some good solid concepts laid out in the book that would be useful for any Project Leader. Some of these included taking the “Zeroeth Step”, response filters and being understood.

Strider talks of laying a good foundation, especially on a personal level, for any new project. He calls this taking the “Zeroeth Step”. This is taking time to reflect on a new project, considering both your own needs and the needs of others, and understanding the context of your project. Without honouring your own needs within the context of the project, you can become disconnected and less effectual, and thus your project could suffer.

Response filters was another interesting topic, in regards to dealing with difficult people. This flips the situation around where it is not the “difficult” person that causes a difficult situation, but instead your own personal response filters. Basically, “difficult” is your own interpretation, and a response filter is the way you react to certain types of people. By becoming aware of your response filters, you can start to change how you respond. Sure, easier said than done, but with work this can be possible.

Being understood is key to successful Project Leadership. Without clear communication your project becomes susceptible to failure. Strider talks of the five levels of communication: cliché, information, opinions, feelings, and total truth. Communicating at the “total truth” level is not always easy to do, as it can leave you feeling vulnerable. An example of communicating the total truth in the context of a project is, say, admitting to not being able to meet a critical, yet impossible to meet deadline. Ultimately, admitting this feels like failure, but alternate solutions can be brainstormed as soon as this is apparent instead of hiding this fact and then failing even more miserably when the deadline is missed.  The closer you get to communicating at the highest level, or total truth, the more effectual your project becomes.

I highly recommend this book, albeit with caveats to take some of the aforementioned flaky portions with a grain of salt. Then again, if carrying a wishing wand icon in your pocket makes you feel like a stronger Project Leader, then all the power to you!

Because the OECD already had a mature system with a soap interface to query data, we not only didn’t want to reinvent the wheel, but we also didn’t want our solution to be intrusive or impose changes to the legacy system.

When coming up with our design, we strived to keep a clear delineation between the legacy system and the new application via an abstraction layer. We made use of the existing legacy heavyweight soap API and wrapped it with a lightweight restful API. This way we were able to create a stand-alone API sitting on top of the legacy system with loose coupling between the two. We were able to create our solution without interfering with the existing infrastructure.

Of course, integration even in this loose-coupled way was not without pain points. Because we did not have any control over the underlying legacy soap service implementation, the solution was tricky to optimize. Fortunately, we were able to identify some areas of concern early in the process and work with the OECD to fix these issues.

Another important element of legacy system integration is the need to closely communicate with the legacy system maintainers to coordinate rollout of any legacy changes. Because our application was mostly designed to be independent of the legacy system, this did not greatly affect our project. However, an in-person visit to the OECD headquarters for a meeting with the legacy system maintainers to get buy-in for our project was invaluable for opening the flows of communication in this regard.

Legacy system integration can be challenging, but by prioritizing loose-coupling between the systems and maintaining good communication between all parties, legacy system integration can be attained very successfully!

We recently had the pleasure of working on a project with the OECD, a large international non-profit organization based in Paris. This was a year-long project with a team of five to seven developers to create a user-friendly web-based query wizard interface to the OECD’s Development data. The OECD had an existing legacy application allowing users access to their data, but it required expert knowledge of the underlying datasets in order to access the information. The query wizard was to hide this complexity from the user and to provide one unified view to the various Development datasets.

An integral part of SCRUM is that there is one Product Owner that is available and vested in the SCRUM process. As the OECD is a large organization based overseas and a nine-hour time difference, this was seemingly going to be difficult.

The OECD Development Co-operation Directorate presented two excellent Product Owners – one representing the technical side and one representing the business side – who provided a unified front to the OECD’s vision and user requirements. 2Paths decided upon a two- week iteration schedule. Because of the nine-hour time difference and the busy schedules of the OECD employees, we decided upon a schedule of weekly video-assisted teleconferences with the OECD team, the third-party funders, and the 2Paths project team. We conducted bi-weekly iteration reviews, alternated with bi-weekly checkins in lieu of face-to-face stand-up meetings.

In addition to the weekly teleconferences, we established a good email rapport with the Product Owners, and corresponded via email throughout the iteration to clarify any outstanding issues or requirements. This process worked well for the most part, as the Product Owners were very decisive; they knew what they wanted or decided fairly quickly what they wanted. We also kept a well-organized Wiki site to hold all relevant information and documentation surrounding the project to which the OECD had access. This assisted in coordinating work and kept information in a known central location. We at 2Paths took care not to bombard the OECD with technical terms, keeping the language appropriate to their technical savviness.

Occasionally the time zone difference was a hindrance to our process as this necessitated a twenty-four hour turnaround in email responses, which sometimes was not quick enough for our liking. However, for any critical issues that needed to be resolved, we were mostly able to set up impromptu after-hours calls to the OECD to sort them out on the spot.

Having a team of two Product Owners instead of just one Product Owner also didn’t end up presenting any problems. They seamlessly provided one unified voice to represent the OECD. They were careful to come to agreement amongst themselves before presenting any decision on any issue to 2Paths.

The OECD admitted that if they had their choice, they would have preferred to have a 2Paths developer on-site in Paris throughout the life of the project (I would have volunteered!), but in general the teleconferences and email discussions were sufficient to get through any issues that arose. It was helpful that 2Paths representatives were on-site in Paris both for the initial requirements- gathering phase, and for the final project handover at the end of the project. The OECD Product Owners were also able to meet with 2Paths in person in Seattle mid-project.

When embarking on this project, we were unsure of how receptive the OECD would be to our agile processes, as traditionally large organizations can be more inert and resistant to change. We were very pleasantly surprised as the OECD embraced our processes wholeheartedly. They were very glowing about our “refreshing” agile process, and how they could quickly and often see tangible results of our development. They felt they got value from their ability to have constant input into the evolution of the software. They were use to having longer rollout times due to heavier weight processes in-house, so were very impressed by the progress each iteration.

The OECD also got some extra fringe benefits. Through our software development process, the OECD was able to identify and work on areas in their own process that had room for improvement.

Another key to the success of this project was that the two chosen Project Owners were very knowledgeable of their business and their requirements. 2Paths spent a good chunk of time working with them at the start of the project to establish a good solid high-level design of the product. There was also up-front time invested into the User Design of the application, and 2Paths with the aid of sub-contractors DesignStamp, came up with detailed user personas. Feedback revealed that OECD found this process extremely useful.

Take aways for 2Paths from this project were that it IS possible to work in an agile way with large organizations, especially when knowledgeable and open- minded Product Owners are chosen to represent the organization. Providing tangible results early and often to generate feedback can be a refreshing change for employees working in a large organization. Instead of arrogantly preaching the Agile software development process, being sensitive to the way that large organizations work and working WITH them as a team will ensure buy-in and aid in the success of the project.

We had downloaded and installed the debian package grails_1.0.4-1_all.deb from the GRAILS site, configured the GRAILS_HOME environment variable for our build target, and attempted to build it. We got this error:
Grails ended with a non null return code: 127
After some digging, it turns out that the debian package installs GRAILS but puts the actual executable in /usr/bin instead of just a symlink from the GRAILS_HOME. The Maven GRAILS plugin appears to be calling grails using the GRAILS_HOME path. Making a symlink to the grails executable in the bin dir of the GRAILS_HOME fixed this problem (although the symlink really more correctly belongs in the /usr/bin dir).

Trying to build again we came across a different problem, where the GRAILS version was showing up as null, causing build errors. After some googling I found this useful post, and re-installed GRAILS with the updated grails_1.0.4-2_all.deb package, repeating the steps for the GRAILS executable. Now we’re all up and running in Hudson! I hope this might alleviate some pain for anyone trying to troubleshoot this problem.

Enter LiquiBase, an open source database-agnostic tool for tracking, managing and applying database changes. We recently worked on a small Grails project and decided to give this tool a try and I was duly impressed.

LiquiBase functionality is built around a main changelog.xml file containing changesets representing incremental database changes to be applied to a database. LiquiBase manages which changesets have been run through a DATABASECHANGELOG table it creates in each database.

We used the grails plugin which gave us most of the full LiquiBase functionality, albeit a little less than mature. There were a couple of gotchas and bugs with the plugin, but nothing we couldn’t work around.

LiquiBase buys us the ability to store database change in source control, easily sync databases in multi-environments in an automated and controlled fashion, tag database states upon iteration-end releases, auto-generate rollback sql to tagged states, diff databases, and much more.

LiquiBase-ifying Your Application

With your database in a known state, you can use the grails plugin to create your changelog.xml. First you need to install the grails LiquiBase plugin:
grails install-plugin liquibase
Once installed simply run this from the root of your grails app:
grails generate-changelog grails-app/changelog.xml

This will generate the changelog.xml from your development database (specified in DataSource.groovy) and write it to the path specified in the command. grails-app/changelog.xml is the default path where the grails plugin will be expecting the changelog to be. If you need to read from a different database environment like staging for example, just add the -Dgrails.env=staging option to the command.

To propagate this changelog to other databases (say, test), run
grails -Dgrails.env=test migrate. This runs all the sql necessary to upate the database to match the changelog. Any new changes from here on will be appended as new changesets, and can be migrated with the same command as above. You can also use the migrate-sql command instead if want to generate the sql and run it yourself. Most LiquiBase commands come in tuples: one to generate the sql for you and one to just run the sql directly against your database.

If you’re integrating LiquiBase mid-project and already have all your databases set up, you’ll need to run sql against them to update the LiquiBase DATABASECHANGELOG table to show all the changes as run. First, make sure that the databases are all in sync. To do this, you can use the handy LiquiBase diff tool. Unfortunately, the grails plugin for this diff tool is not very robust and will only diff your development database against your test database – the plugin has those two environments hard-coded. You can either mess with your DataSource.groovy db environments to do the diff setting the two dbs in question to dev and test temporarily, or install LiquiBase itself and run the diff passing the db parameters to the diff command. Using the grails plugin you would run:
grails db-diff which will spit to the screen any differences as changesets to be applied. Strangely, there is no documentation for this command in the LiquiBase Grails plugin page.

Once your database are in sync, run
grails changelog-sync-sql with the appropriate -Dgrails.env switch to generate the sql to update the DATABASECHANGELOG table, then run the sql in your database.

LiquiBase and Continuous Integration

We use Hudson at 2Paths for our CI, and have added the simple grails -Dgrails.env=test migrate command as part of our build process to migrate the test database upon every checkin. This ensures that the test db is always the most up-to-date.

Rolling LiquiBase into our Dev Process

We’ve adopted on a trial basis the following process for database change management as part of our agile software development, taking into consideration Grails development (which uses hibernate) which can auto-generates schemas based on domain objects:

1. Generate changelog from initial schema and commit to svn
2. Rollout schema to other databases by migrating from changelog
1. if the schema already exists and it needs “LiquiBase-ifying”, generate changelog-sync-sql and run it
3. Add every schema change via new changeset from hereon in by generating changelogs via grails db-diff
1. add / change domain objects in project
2. set hiberante ddl mode to update
3. start app and grails will automatically update the db
4. generate new changelogs using db-diff (against the test db)
5. append changelogs to changelog.xml
6. run grails changelog-sync-sql to generate the sql that will mark all these new changes as ran on your db, then run the sql
7. checkin changes. this will be applied to test
4. provide explicit rollback sql for any custom sql
5. tag each iteration end with a “tagDatabase” changelog in the changelog.xml

Gotchas

We ran into some gotchas with LiquiBase. One of the first things we started doing before fully understanding how LiquiBase worked was to update existing changesets when changing the schema. LiquiBase generates checksums for each changeset to ensure they don’t change, and altering existing changelogs will cause future migrations to fail. Even though LiquiBase gives you some tools to get around this, it’s generally a better practice to just add a new changeset for every database change. There is a good blog on the LiquiBase site explaining how to deal with changing changesets.

Another gotcha is that the rollback-sql command won’t magically generate rollback scripts for hand-coded sql (obviously!) You must to generate your own rollback sql for these custom sql tags, otherwise not only will you not get rollback sql for those particular changesets, but the rollback functionality won’t spit out sql for any other changeset either until you do.

Tagging was a little fussy as well. The command line grails tag can only tag a given state once – future tags will overwrite the earlier ones unless you’re at a different changeset. I found it better to add a tag changeset explicitly in the changelog.xml. The Grails plugin for tagging also seems to be problematic with spaces in the tag name. We decided to just use underscores as a convention.

We also ran across some broken functionality:

• The grails generate-changelog command generates some extraneous information that breaks sql for data type numeric(19,0) if that type has auto-increment on. It generates this in the changelog:
  <column autoIncrement=”true” name=”id” type=”numeric()(19,0)”> (notice the extra empty brackets). We needed to manually remove these to get it to work.
• The grails rollback-to-date-sql command writes to a file with the datestamp instead of to console like the other rollbacks do, even though the docs say it writes to STDOUT (rollback-count-sql also has issues, but rollback-sql for tags works just fine). The code for these plugin commands doesn’t seem to do the right thing with the args. Time permitting, we may provide a patch for this.
• db-doc generation doesn’t work with large amount of columns in a table because it uses the table description including column names for the html file name. Too many db columns make the file names too long.

Moving Forward

Although there’s a bit of grumbling amongst the developers here that using LiquiBase with the above process is a little onerous, it buys us a lot more certainty for knowing what state our databases are in, making sure changes are in source control, and knowing what updates have or haven’t been run. It’s a whole lot easier than hand-coding a bunch of sql, and easily accommodates the possibility of migrating to other DBMS’s in the future without having to re-write DBMS-specific sql. There’s even talk of trying to go a step or two further to automate even more of the process so a developer doesn’t have to think about generating changesets upon changing of a grails domain model. We’ll see how that goes.

After some discussion of whether we should start development on the database or application first, we decided to tackle the database first. We had started out by re-designing the database to allow for some sorely-needed normalization of some relationships. We came up with a new normalized schema through a mixture of requirements gathering with the client and reverse-engineering the legacy database. We focussed on areas where we could generalize and abstract out relationships and left the details for last. With our new schema, we then worked on migrating the legacy data into the new schema to ensure everything was accommodated.

Using our new schema we began application development with Grails. We began having difficulties where the application was changing rapidly, necessitating corresponding changes in the schema and data migration script. We were having a disconnect between the schema changes and the application changes. It was at this point that I attended Marc’s session.

The main point that he drove home which we already knew too well was that Database refactoring is expensive. Databases have no source code, databases resist change, databases need to be coordinated with corresponding applications, and teams usually have many databases to coordinate (ie: dev, staging, production). Marc stressed the first point of there being no source code as one of the major problems. Database creation and maintenance are usually done as ‘patch scripts’.

Enter LiquiBase. Marc neglected to mention this very handy library that we decided to try out with our new project. LiquiBase is DBMS-agnostic and allows us to manage database change much more cleanly than ever before. I haven’t fully explored all of the LiquiBase functionality yet but so far am very pleased with what I have explored. There is a LiquiBase Grails plugin and also a LiquiBase IntelliJ Idea plugin that we’ve been using.

Back to Marc’s presentation. Because we’re already convinced that Database refactoring is very expensive, he made a case to do Big Picture database modeling up-front, most importantly capturing all the areas where generalizations and abstractions can be made. It is much more expensive to refactor something specific into something general than to refactor something general into something specific. Adding objects rarely if ever affects existing functionality, but removing them usually does.

Start by modeling the entities and relationships only. Don’t worry about the attributes or details – these can be fleshed out during implementation.

Marc had some Dogmas to impart:

• Use subtypes: they’re great for recording extra knowledge about a logical model
• Hate NULLs: allow no optional relationships. This usually requires using a linked entity which may seem uglier but makes a whole lot more sense
• Allow no implied participants in transactions

And then there was Pragma:

• Don’t invent when you can copy
• Use standard models. He highly recommended Len Silverston’s Data Model Resource Books which we also refer to here at 2Paths
• Reuse models when you can

So far in the presentation, it didn’t seem like we were in an “Agile” session, but finally Marc roped us back into the subject at hand. Just because we’ve done up front design doesn’t mean we have to implement everything at once. Using the up front design we can do iterative development. We don’t need to have the up front model be 100% correct – we can do iterative refinement to it as the project progresses.

For an agile implementation, revisit and refine the model at the start of each iteration. Make explicit documented decisions on each of the design decisions that are made so that down the road it’s known why certain decisions were made.

In summary, Marc reiterated that because databases are so expensive to refactor, it’s important to get as much right the first go around as possible. Getting it right first will make agile development and subsequent refactors much easier. Design for change by generalizing and abstracting relationships.

Relating Marc’s advice back to our project, I realized that we hadn’t done too badly with our process after all. We had made generalizations and abstractions where we could, getting the Big Picture logical design done up front. We then began application development based only on the stories included in the current iteration. The problems we were having in syncing the application to the database were mainly mapping to physical design issues, and not logical design issues.

In hindsight, it may have been easier if we took the logical model that we had designed and implemented this in Grails first and seen what schema Grails produced from that model. We could then have tweaked this schema and associated mappings to be the physical implementation we wanted, instead of producing the physical model in the database first.

When we had started the process of our up front design we had had many discussions about whether this was the right thing to do, and if it was really agile. It was good to have confirmation that others have thought of this too and that it IS okay to do Big Picture up front design. This will hopefully save us some pain and suffering in the future. Hopefully we’ve made our future database refactoring less expensive.

Scrum is an iterative, incremental, Agile process for developing any product or managing any work. It is a project management process, but certainly not a methodology as that would be too heavy. The key to Scrum is having self-managed teams. A ScrumMaster is the person in a project team that is responsible for Scrum values and practices within the team.

At 2Paths we live and breath the Agile Manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.*”

*www.agilemanifesto.org

When signing up for the ScrumMaster course I had expectations of learning “New Great Things” that I could bring back to 2Paths to implement to augment our current Scrum and Agile practices. It was refreshing to instead have it confirmed that at 2Paths we’re actually pretty much already following the Scrum process to a T.

Scrum Roles

There are three roles in play in Scrum: the Team, the ScrumMaster, and the Product Owner.

The Team

The team is usually around 5-9 self-managed people who are responsible for the actual work to implement product functionality. Team members are accountable to the team, not to a manager.

The ScrumMaster

The ScrumMaster is responsible for Scrum values and practices in the team. The ScrumMaster is a “Process Manager”, not a “Project Manager”. They establish key scrum meetings, protect the team from interruptions, and facilitate removal of any blockages facing the team.

A ScrumMaster should be a good facilitator, be open-minded, tactful, and deal well with conflict.

The Product Owner

The Product Owner is usually the Client, but could also be internal to a company. They are responsible for the Product backlog, establish and promote the vision of product, and are responsible for the ROI by prioritizing work. Scrum dictates that this should be only one person.

The Scrum Lifecycle

The Scrum Lifecycle of a project differs widely from traditional software development lifecycles in that work is done in fixed time-boxed iterations, or “Sprints”, yet the scope of work done in the project is variable.

Scrum Planning

In this phase, high-level requirements are gathered and compiled into User Stories. A User Story is a requirement formulated as one or two sentences in the everyday language of a user. The deliverable from this phase is the Product Backlog (list of User Stories), which is owned and prioritized by the Product Owner. The Product Owner can re-prioritize items in the product backlog at any time.

Sprint Planning Pt. 1 (selection)

The highest priority User Stories from the product backlog are chosen for inclusion in the current Sprint Backlog. The Product Owner cannot re-prioritize items inside the Sprint Backlog, only items in the Product Backlog.

Spring Planning Pt. 2 (decomposition)

User Stories from the Sprint Backlog are decomposed into tasks and the team will negotiate estimates for each of these tasks.

Daily Scrum

This is a daily standup meeting for the project team, facilitated by the ScrumMaster. The daily scrum should take no more than 15 minutes. In the daily scrum three simple questions are asked of each team member:

1. What did you work on yesterday?
2. What will you work on today?
3. Are you stuck?

The team will then look at the Sprint burndown chart – a graph showing how much estimated time is remaining in the Sprint. Daily re-estimation of task effort is also key to Scrum.

The goal of the daily scrum is to ensure good communication between team members and to ensure all team members have the information and tools they need to carry out their work. The ScrumMaster is responsible for facilitating removal of any roadblocks facing the team or team members.

Sprint Review

In the Sprint review, the team demonstrates the work completed in the Sprint to the Product Owner and other stakeholders. A main idea behind Scrum is to show results soon and show results often.

Potential Deployment

At this point stakeholders decide if they want the latest Sprint results deployed.

Sprint Retrospective

At the end of each Sprint, the team members and Product Owner have a meeting to reflect on the pluses (what went well) and deltas (suggested changes or improvements) of the Sprint. The deltas will be recorded as actionables for future Sprints, and deltas from the previous Sprint will be reviewed. The Sprint Lifecycle restarts from here to Sprint Planning of the next Sprint.

Scrum à la 2Paths

We at 2Paths were already pretty much following the above scrum process to a T, although we had been letting a couple aspects slip. We had started neglecting the Iteration-end Team Retrospectives, which we’ve since resurrected. These sessions have been invaluable for constructive feedback in the way we do things, and helping us strive to constantly improve.

We had also been a little slack in the daily scrums in terms of team members giving full descriptive details of their current and future tasks. The team was getting use to answering their daily questions in extremely general terms which was not very useful to other team members, and ultimately to the team itself. We’re trying to change this so that team members’ daily input has enough detail to be constructive to the scrum process. As usual it comes down to team cohesion and productivity hinging on good communication.

In the course I learned a couple of other ideas that we’ve since implemented at 2Paths, such as drafting a Team Charter. The team sits down at a brainstorming session to draft a list of rules to which each team member needs to adhere. These are rules made by the team for the team to foster a cohesive, communicating, and respectful atmosphere. These rules can span any topic from personal conduct to philosophy to technical considerations.

We’ve also begun playing “Planning Poker”, which is an innovative way of estimating time for tasks by the team. We had formerly used a rock/paper/scissors method where on the count of three each team member put out their fingers indicating their time estimates for a task, but it’s been too easy to let other team-members’ estimates influence one’s own estimate. With planning poker we all have to chose a card representing our estimate, then all turn over our card simultaneously.

In my ScrumMaster course one of the best things I learned was how good we have it here at 2Paths. We have a lot less red tape it seems than a lot of my fellow ScrumMaster classmates which makes it a lot easier to get things done. We already have our Scrum and Agile practices in place, and have clients who have quickly become Scrum and Agile converts. Oh, and I almost forgot about the other best thing I learned – the secret ScrumMaster handshake. Who knew?!

After a quick introduction by Evangelist Scott Davis, and with hopes of winning an IPhone by the end of the weekend, I headed right into his double-bill of sessions about Groovy. The first one entitled “Groovy, the Blue Pill: Writing Next Generation Java Code in Groovy” was a good gentle introduction to neophytes like myself on Groovy basics. Now that my interest was piqued, I was eager to continue on with Scott’s next session “Groovy, The Red Pill: Metaprogramming, the Groovy Way to Blow a Buttoned-Down Java Developer’s Mind”. Never mind the Blue Pill – the Red Pill is where it’s at!

Scott’s enthusiasm for Groovy was definitely contagious, and my mind started churning, trying to think of ways to start introducing Groovy into current projects or future projects at 2Paths. An allure of Groovy is that it’s a dynamic language and can be run on the JVM. Groovy is implemented in Java, so the two languages offer seamless interoperability. Groovy compiles down to Java bytecode, so Groovy code can call Java code, and vice-versa. This would make integration into our existing infrastructure much simpler.

The Blue Pill was starting to take effect, as Scott showed us the terseness of the language. No need to labouriously write getters and setters, amongst other many nifty language shortcuts. Who needs semicolons or parentheses anymore? Because Groovy really is Java under the hood, programmers unwilling to let go of that extra baggage can continue to use it and nothing will break. We were then shown demos on how much more quickly we could bang out Unit Tests in Groovy.

In the next session, the Red Pill stuff was pretty mind-blowing. Introducing method pointers, closures, the ExpandoMetaClass. Method pointers make our code more readable and understandable by allowing us to alias methods with semantics tailored to our own business logic. Closures are an exciting and powerful inclusion in Groovy that aren’t available in Java, allowing us to pass around executable snippets of code. And last but certainly not least, there’s the ExpandoMetaClass that lets us either do a lot of really cool stuff, or get ourselves into a heap of trouble. With the ExpandoMetaClass we can intercept methods and inject methods into any Class. Scott showed us some fun examples that got us all fired up wanting to try more!

With my introduction to Groovy setting the stage for the weekend, I went on to choose more sessions on Groovy (Design Patterns, Testing, Groovy with Spring), but also attended other sessions such as Spring Configuration, Regular Expressions, and GIS for Web Developers. I found most of the other sessions mostly affirming knowledge I already had, but augmenting it with good snippets here and there that were new to me. Venkat Subramaniam was the other main Groovy Prophet, and I came home with his book “Programming Groovy” in hand, eager to start integrating Groovy at least into our testing infrastructure.

The atmosphere at NFJS was inspiring, as the speakers all had great enthusiasm for the technologies they were touting, and the audience was generally equally as keen. It felt great to be in a large conference hall amongst so many other like-minded programmers, all sharing, and getting fired up about what we do, and our seemingly unlimited potential. I fully recommend NFJS (regardless of me not winning an IPhone), and would love the opportunity to go again!

These concepts are all database-agnostic, but there are specific tools for use with Java, Hibernate, and Spring to assist in persistence strategy integration. For more information, see the wiki here:

https://dev.2paths.com/wiki/display/2pathsTECH/Persistence