Aaron Feng

In less than two months I managed to get a kernel panic on my Mac. Generally kernel panic occurs on UNIX like operating systems when it encounters an error it cannot recover from. It is similar to the blue screen of death on Windows. My MacBook has been intermittently shutting it's self off when I tilt it. It was annoying, but it turned right back on when I pressed the power button. However, last week kernel panic happened when I tried to turn it back on. No matter how many times I tried to reboot the machine, I received the same kernel panic screen. I contacted Apple, and they could not diagnose the problem over the phone, so they told me to drop the laptop off at an Apple service center.

I left my Mac at the Apple service center for two days, and they could not find any hardware related problems. They basically told me I had to pay them money to reinstall the OS in order to fix it. I decided to get the MaBbook back because I can handle the reinstall myself. Since no hardware problems were found, I had to pay 48 bucks to the Apple service center for a diagnose fee. Apparently this is standard at an Apple service center, but not at an Apple retail store, I later found out.

After I got home, I decided to boot up my MacBook. To my surprise, the kernel panic went away. At this point, I was still not convinced it was a software related issue because the laptop still shuts it's self off if I tilt it the wrong way. I called Apple back, and complained about the 48 bucks that I wasted. As reimbursement, they sent me an Airport Express. Since my MacBook is still shutting off on its own, I will have to take it back soon. Next time I will tale it to an Apple store, not a service center.

This is why I'm hot. Yup, that's my baby.

A couple of days ago I was poking around Park Place source code and I saw something resembling the following syntax:

# ... is some arbitrary string in this case
class A < B '...'
 # ...
end

I am no Ruby expert, in fact, I have written very little Ruby code so far. However, the code above looked really odd to me. It looks like class A is inheriting from class B, and class B is taking some arbitrary string as an argument.

Well, after closer inspection I was completely wrong on what B is. B is not a class at all, in fact, it is a method under cover.

def B str
 # do something with str variable here
end

'...' is some argument to the B method, which makes a lot of sense, but how can class A inherit from a method? If you try the code above, whatever is in method B will execute, but you will get an error when class A is trying to inherit from B. The reason is simple, class A is expecting to inherit from a class not a method. To prevent the error, you need to somehow construct a class in method B.

def B str
 # do something with str variable here
 Class.new
end

Ruby automatically returns the last line as the return value. In this case, you will not get the error anymore.

The first question one should ask is, why would anyone want to do this? The code I showed above is a very simple version of the real code that appeared in Park Place. In Park Place it creates a new class and adds methods to the class based on the input. This is powerful because it allows one to hide the base class since it does not actually exist. On top of that, using this technique one can write code that writes code. Ruby on Rails uses similar techniques to achieve all the magic.

Park Place is an Amazon S3 clone in Ruby minus the SOAP support. It is amazing how little amount of code is required to achieve what S3 does.

Another interesting aspect of Park Place is that it uses Camping microframework. Camping is similar to Rails in the sense that it is a web framework that utilize the MVC design pattern. It is small web framework that weighs less than 4k! It is described as "a little white blood cell in the vein of Rails" on [Camping's][camp] wiki. You can see all the code in the framework in one page of your browser.

You can actually migrate from Camping to Rails fairly easily. That got me thinking, maybe [Shoechicken][shoechicken] should use Camping instead of Rails to start with. We can then migrate to Rails as the need arises.

Since Shoechicken will provide RESTful web services, it is only natural to check out some existing web services that are already in the wild. One of the most well known web services that provides a REST API is the Amazon Simple Storage Service (Amazon S3).

S3 provides web services that allow a subscriber to store and retrieve data. The subscriber is charged based on bandwidth and storage used. It is especially important for Amazon to validate your identity so you do not get falsely charged from unauthorized requests. Most important of all, you do not want your data to be compromised.

How does S3 validate your identity? When you sign up for S3 you will receive two keys: Access Key ID and Secret Access Key ID. Access Key ID is included in every request and before you put your request on the wire, you sign the header with your Secret Access Key ID. Of course, no one knows your Secret Access Key besides you and Amazon. This is fairly interesting because you can allow access to others by constructing the request for them.

Maybe we can do something similar to S3 in Shoechicken when the user wants to retrieve recommendations for his or her feeds.

For more information about S3 please refer to the official documentation.

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 ;)

I bought a new laptop recently, why not a new blog? I have been thinking about hosting it myself, so I figured this would a good time for the switch. One of the primary reasons for the move is because I will be working on a side project called Shoechicken. Shoechicken is an AI learning agent. I will talk more about the concept of Shoechicken in the next post. The focus of this blog will be mostly an archive of my Shoechicken journey. The project will be a distributed Rails project, so I will also document my Ruby and Rails experiences. I have never worked on a Ruby project before, so this will be good learning experience.