Thursday, December 24, 2009

Helping Others for Fun and Profit

Perhaps, like me, you've found yourself saying:
  • I want to write a program but I can't think of any real-world problem to solve*.
  • I want to be able to show a prospective employer some of my code but my previous employers own all of the code I've written and they would not let me show it to others.
  • I want to learn how to gather requirements and more effectively convert them into code but I can't talk with our customers.
I think I've stumbled upon a way of meeting these desires.
  1. Find a friend, relative, or charity who has a problem that can be solved by software.
  2. Offer to write some software to solve their problem. If they refuse, jump to step 1 with someone else. I would recommend that you offer to do the work pro bono publico.
  3. Sign any non-disclosure agreements that might apply but stress that you will own the code you produce. After all, you want to be able to show the code to prospective employers.
  4. Sit down with them and gather requirements.
  5. Write the software as professionally as you know how in an iterative fashion seeking their input whenever it's needed (while respecting their time and schedules). Keep in mind that one of the goals of writing the software is to maintain the friendship. Buggy code may strain the friendship or even destroy it if the bug is serious enough.
  6. Make sure that you protect yourself by releasing yourself from all liability just in case you have a litigious friend.
  7. Deliver the software, the source code, and unit tests, and let them know that you'll be available to modify it if their needs change.
If you find that your friend is taking advantage of you, you may have to set some boundaries to protect the friendship.

By the way, the profit I was referring to in the title of this article is not necessarily monetary profit, but it definitely is personal and professional profit.

NOTICE: I am not responsible for any friends you may lose, family members who disown you, or charitable organizations who publicly defame you or sue after you follow these steps.

* Perhaps that's why there are so many ray tracers and sudoku solvers.

Resisting the Urge To Refactor

I'm working on the main Controller (as in the C in MVC) of a GUI application and trying to design the Controller along the lines of "The Humble Dialog" [PDF] by Michael Feathers. Some of the Controller's methods make repeated calls to the View object. For example:

view.clearAuctionEvents();
view.enableUpdateDatabaseButton(false);
view.displayErrorMessage("Could not download email messages.");

My first instinct was to follow the Refactoring advice of Fowler and Beck and move these three calls into a new method on the View. Then it struck me that it's actually desirable for the Controller to be so pedantic with the View. After all, I'm trying to "humiliate" the view as "The Humble Dialog" article puts it by stripping it of any logic or behavior.

So sometimes it's okay not to refactor.

Saturday, December 5, 2009

Rapid Web Service Construction with Groovy

I'm reading Thomas Erl's book, "Principles of Service Design" and, when he discusses contracts, they're usually codified in WSDL and XSD. So I've been trying to find a way to quickly throw together Web Services that use WSDL and XSD so that I can play with some of the book's concepts.

Failed Attempts

I thought that Ruby would be the answer. I first tried SOAP4R but found that it could not generate WSDL from service methods and types. Since I don't want to generate WSDL files yet, this was a deal-breaker.

I then tried Ruby's ActionWebService but the generator script was not installed correctly so it wouldn't work.

Success

I then stumbled upon Groovy's WSServer library (installation instructions). Groovy is a dynamic language that runs on the JVM. I installed the Groovy support for Eclipse and had created a fully working web service in minutes. I fired up the Web Service from within Eclipse and then switched over to Microsoft Visual Studio and imported the Service Reference and called my service code from C#. It was so easy.

I then thought I'd try a web service call that would return a complex type (e.g. a Person object). This made the Web Service crash with a stack overflow.

It took me hours to find the solution. The following links helped a lot:

Basic Service - This page showed how to create a simple Web Service.

Using the Aegis Mapping - This showed me that I needed to create a mapping XML element for the Person class that ignored the 'metaClass' property of my Person object. My guess is that the stack overflow was caused by navigating a very deep or even cyclic object graph during the serialization process.

Aegis Binding - This link told me where to put the mapping XML element.

Now I can create Web Services very quickly just to try things out. And they run on any platform Groovy runs.

Have you found a better way to quickly develop Web Services? I'd love to hear about what you've found!