Chipmark: a great idea for a college class

As an alumni of the University of Minnesota Computer Science Department, I receive a bi-annual newsletter from the Department called SoundByte.

The Spring/Summer 2006 issue had an interesting article about an innovative two semester-long class taught by popular professor John Riedl.

The students who sign up for this class spend 30 weeks working on Chipmark, an open source knockoff. The cool thing about this is that they spend a long time working together on a real project, that runs on a real server, with real users. They also have to deal with legacy code, because each class builds on the previous class's work.

Here's some snippets from the article:

Do you want to learn how to really build software ... and get Upper Division CSci credits at the same time? Are you tired of 1-2 week assignments that just get thrown away when you finish them? Do you want to ge evaluated on your ability to build software, rather than your ability to memorize facts for a test? Then consider this class: working together with 10-12 focused students for 30 weeks over two semesters to deliver a useful open source software product to the world!
So read the first paragraph in an email invitation from Prof. John Riedl to Computer Science undergraduates. He wanted to give students the opportunity to participate in an unique class, gaining valuable experience building software in a way that isn't possible in a conventional classroom setting....
This project class isn't like other classes. Instead of attending lectures and coding textbook programs every few weeks, the Chipmark team meets twice a week to discuss progress and work together in the same room. The project has different areas of responsibility such as team lead, release manager, and user interface manager. This means that everyone has an area of responsibility and an opportunity for leadership....
UMN Computer Science majors learn how to program in Java in the second course they take. Chipmark team members apply their Java skills, but they also learn how much more there is to a software project than just writing code. They work with a wide range of industry standard tools including Ant (to build the software), CVS (for change management), Javascript and C++ (for browser extensions), Tomcat and MySQL(to run the Chipmark server), and MRTG (to monitor server status).

I think this is really cool. One of my constant complaints about my education is that the importance of source control was never addressed -- not even in my software engineering class (where, like the Chipmark project, our code was turned over to the next year's class -- sorry about the XML sit ups, guys!)

This class addresses that, and more. I wish I'd had the opportunity to take a class like that. I think it would have made me a better software developer, sooner.

— October 5, 2006

Ajax and REST

Bill Higgins: Ajax and REST, Part 1: Advantages of the Ajax/REST architectural style for immersive Web applications.

Good introduction on some of the benefits of REST, primarily caching and lower memory usage on the server side.


Brian Repko: Ain't gettin' no rest with REST.


Benjamin Carlyle: Common REST Questions

See also: Benjamin's REST Tutorial

I think this discussion illustrates the biggest problem with REST: it's hard to understand. Conceptually, REST is pretty easy. Use the HTTP verbs. Post some XML. But when you start doing more complicated things than creating a new record, there's a lot of disagreement about the "right way" to do it.

I mean, listen to this: "That is not to say that REST can't do transactions. Just POST to a transaction factory resource, perform several POSTS to the transaction that was created, then DELETE (roll-back) or POST a commit marker to the transaction."


I get what Benjamin's saying here, but it's not easy...

Maybe the real problem is that SOAP was too easy. It hid the complexity of what was really going on, but the abstraction was too leaky. Network calls are not like method calls. REST tries to rectify that, but it puts more of the burden on the developer to do it right.

— October 5, 2006