Aaron Feng

Even though Shoechicken is a Rails application, currently it has no plans for any user interface. It will only expose web services for external clients to consume. In the web services world, you have two camps: SOAP or Representational State Transfer. With that said, we had to make a decision as to which style of web services we will provide: SOAP, REST or both.

One big advantage of using SOAP is the code generation tools that are available in various languages. It works extremely well when you control both sides. However, it can get a little more hairy when you do not have the luxury of a homogenous environment.

On the other hand, REST is very simple. It just uses the old, trusty standard HTTP to transport requests without wrapping it. All the client need to consume a service is a way to send HTTP requests and parse XML.

We want to keep Shoechicken as simple as possible. I feel REST style of web services will be easier to implement and easier for clients to consume with fewer interoperability issues.

During the day I work on a distributed financial system that provides SOAP style web services. It would be fun to learn what is on the other side of the fence. That is one of the main reasons I went with REST for Shoechicken.

Currently on Shoechicken we have three team members. Each one of us lives in a different city. Not everyone is on the same time zone, and our schedule is slightly different. It can be difficult to gather everyone together to have a discussion around Shoechicken.

At first we tried to use instant messaging, it is very light weight, so we can type to each other whenever as long as we are online. However, most IM software is targeted for one-on-one chatting, and it does not save the history in a central location for later consumption. We eventually moved to Campfire, since it has everything we wanted and still kept it simple. It allows multiple people to chat at the same time and saves the transcripts. However, since everyone is on a different schedule, we still had a hard time getting people into Campfire around the same time.

We eventually went back to the old trusty email. I was really surprised email actually worked better for us. I was avoiding using email because I prefer real-time communication over delayed.

Part of the reason email worked well for us so far is because we are still in the very beginning of the project. Everyone tends to have lots of little questions about various parts of the system. It is hard to get across lots of unorganized information via chat style of communication. The screen tends to scroll fairly quickly, and the conversations are often lost. Especially when you have multiple people chatting at the same time.

In general I am not a big fan of delayed communication. I feel it divides up the team and often takes longer to get a response. But in this case, we are all working on Sheochicken as a side project, so some delay is not a problem.

At one time we thought shoechicken could possibly do the Netflix competition. With a closer examination, there are some major differences on how shoechicken provides recommendation compared to Netflix. James Horsley wrote a good post on it. That is a good news to everyone else, the money is still available!

p.s. The link to James' blog was broken in the last feed, it has been fixed.

In the previous post I mentiond that I will be working on a side project called shoechicken. I was invited by my friend,James Horsley, to work on the project.

Background:

James Horsley and Mike Wootten (He has not setup his blog yet) started the project on Source Forge in 2005. The first implementation of the project was written in Java. They also wrote a paper on the concept of shoechicken with the assistance of a professor at University of West Florida that specializes in artificial intelligence. The paper was presented at the International Society for Computers and Their Applications in 2006. If you are interested, the paper can be found here.

What is Shoechicken?

As posted on shoechicken's website...

Shoechicken is an intelligent system for rating RSS and Atom news content based on user preferences. The system builds a user profile implicitly by observing user interactions with news content. Shoechicken rates incoming content based on user preferences, and adapts to both long term and short term changes in preferences. The system is interoperable such that it can supply rated content for use by any news aggregator.

Where is Shoechicken going?

Instead of continuing the implementation in Java, we are going try to do it in Ruby using Rails. This also means we will be starting from the ground up. Why Ruby? None of us have done much in Ruby so this gives us an opportunity to learn a new language. Oh yeah, this application is meant to conquer the world ;)