Building an RIA through Collaborative Design and Prototyping : Preamble

We're in the midst of building an interesting Rich Internet Application for educational assessment using Flex. We've had a lot of success with our process thus far, so I thought it would be helpful to document it as a means of discussing it and maybe improving it for our next project.

One of the great aspects of this particular project is that we've done the design collaboratively with an interdisciplinary team, including technologists, instructional designers, and even a faculty member or two.

Here's a pic of our screen designs and the application state diagram:

Rubricator Application States

I'll break this down into detail in upcoming posts.

Next up: Iterative design.

Unit Testing and Subversion - Where should I put the test classes?

I'm starting a strong push to institute Unit Testing in a relatively new project; I figure it will be easier to really get into the habits in a new project from the start, rather than trying to steer some of our ancient existing projects in that direction right away. But I've hit a snag... where should I keep the test classes?

We've been using Subversion to manage our project files since shortly after I started here... getting us into source control was one of my first imperatives. So our code is laid out nicely in folders:


Project A
|____ src
|____ lib
|____ docs
|____ db

Project B
|____ src
|____ lib
|____ docs
|____ db

In the src folder, I have things organized in packages like


src/edu.psu.ist.project-a.component-a
src/edu.psu.ist.project-a.component-b

So where do I put the test cases? I could put them in a test package at the root of the project:


src/edu.psu.ist.project-a.test.component-a
src/edu.psu.ist.project-a.test.component-b

But what I'm really leaning toward is mirroring the main folder structure of the package in a test package in the root of the repository, at the same level as the src folder:


src/edu.psu.ist.project-a.component-a
src/edu.psu.ist.project-a.component-b
test/testComponent-a
test/testComponent-b

My thinking is that the classes in the test package would not get deployed with my actual project code, so they shouldn't be in the real source package tree. But I'm still not sure.

Advice for jumping into Java Web Services?

So I've landed on a new project. We've been asked to port a well-studied scientific algorithm into a Web Service, hoping to link the calculated results into a networked client for visualization (likely Google Earth).

Now, porting the algorithm (from MATLAB) should be relatively straightforward. What I'm unsure about is where to start building the Web Service! I've previously just used ColdFusion for anything that needed to serve a data feed (like sending RSS or feeding a Flash or Flex app), but the requirements from the contracting agency really point to something more portable like Java, Python or Ruby. Since I'm most familiar with Java, and there have been a few articles here and there on Java Web Services, that seemed to be a likely path.

I've read about SOAP, REST, and XML-RPC, and the Apache Axis library. Then I found Axis2, and heard about CXF from a colleague. Can anyone offer any advice as to where to start? Does anyone even build Web Services by hand anymore?

Oh, and Barry... I know I still owe you those 8 things you asked about.

A day of software best practices

Dating back to my days as a consultant in the waning hours of the dotcom era, there were two truths I came to view as fundamental:

1) Once you get to a certain point in your development as a programmer, the actual functioning of software ceases to be a mystery. The only mystery that remains is what to do next. You can pretty much build anything you can imagine, but how do you choose *what* to build next?

2) You can only do so much as an individual developer. To create something really meaningful, you need to work with a team. The whole is *truly* greater than the some of its parts.

These two beliefs fuel my interest in the software development process - tools, methodologies, processes and practices - particularly those that deal with development teams and collaboration. I'm always on the lookout for ideas that will help me choose my next project, and help me go about building it through collaboration and teamwork with my colleagues.

To that end, when I heard about the Software Best Practices Conference, I was intrigued. The title is actually a bit misleading... it's more of a roadshow, with different speakers scheduled to be at different cities on different days.

I went ahead and registered for the Pittsburgh conference, which takes place tomorrow. I'm going to try to summarize some of the more interesting ideas here throughout the day.

If the conference lives up to my imagination, I may see about attending some of the dates in other cities... several of the upcoming conference dates are in cities within a reasonable driving distance.

BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner