I did check it out and I have to say that I’m impressed. It is using the rails edge and is trying out some of the REST(representational state transfer)ful stuff all the while adhering to the philosophies of CRUD(create, read, update, delete). I have wanted to look into a good example of a rails project using REST, and this code base is great for that. What’s more is that it’s not very difficult to wrap your head around all of the code of the site, due to the small code base and nice abstraction of the code.

While reading up on this new forum, I came across a post in which the writer was interested in Beast because of the marketing tag-line, written in _under 500 lines_. He goes on to raise some points on why that philosophy rubs him the wrong way, but I have different views on his points.

Obscure Code

This certainly can be the case in many instances. I have seen a chat server written in 4 lines of perl code. That thing is a horrible mess. That said, I think Beast suffers no where near the extent on that. It does make use of writing out small methods to the whole line; and being that ruby can lend itself well to being understood when read aloud, it’s not that obscure. I will say that in order to read some of these lines, you will have to be somewhat familiar with the idioms of ruby

Included Libraries

Marc makes the point of noting that just because you have written 500 lines of code, doesn’t mean that the project is 500 lines of code is you use frameworks and plugins and other libraries. Mathematically, I agree; however, there is a difference in code that is apart of your project from that code abstracted to external uses. You could also then argue that 50 lines in Java is actually more because you have to think about all of the code that was used to make all of the Java classes as well as that to make the engine but that shouldn’t matter. The only thing that really matters is the 50 lines of code that are doing what you need to get the job done.

Arbitrary Restriction

It’s true, the number of lines of code really don’t matter to a machine; but to make claims that it isn’t more useful is untrue. Part of keeping code small is that it keeps it agile. One way to keep the lines of code small in number is to not rewrite functionality. Not repeating your code keeps your edits quick and you have the ability to change functionality faster. While setting the number at 500 may be weird, trying to adhere to keeping extraneous code out is a good thing. Now if the project warrents lifting that 500 line cap and then code stays committed to the 500 limit, therefor kludging up things or doing this half-assed, then that is truly absurd.

Feature loss

I do not think that you have to lose features in order to make this work. I think the restrictions can be liberating. 500 lines of code: that means there cannot be all of the bells and whistles; not until the core code is in place. In order for the forum to work, the core functionality has to be in place, and since the 500 lines are the limit, then it means that the other pieces of scope have to wait. I’m not going to say that Marc’s situation of poorly-implemented code can (and often does) happen, but I think with Beast, they have the right approach.

Beast is shaping up to be a really nice forum, something that you can use the ground work for and build higher if need be. It’s simple and elegant and a fine example of a rails project.

Notes

Perl Chat written in 4 lines

#!/usr/local/bin/perl -- minchat: run and telnet to port 5555 - bslesins
sub p{print@_}$SIG{CHLD}=sub{wait};socket S,2,2,6;bind S,pack(Snx12,2,5555);
listen S,5;while(accept C,S){if(!fork){open(STDOUT,">&C");p"name:";$n=substr
,0,-2;$f=fork||exec"tail -f chatlog";open W,">>chatlog";select(W);$|=1;p
"[$n here]\r\n";while(){p"$n> $_";}p"[$n gone]\r\n";kill 15,$f;exit}}

The book is a publication from the fine folks at 37signals and brings to light some of their coding philosophies, such as how they do agile development. It is a cheap book and you can achieve instant gratification from purchasing it online because the book is currently only available as a PDF download. The voice of the book takes a stand and casts a very bright light in order to bring out the contrast of other methods of software development and project management. The authors like to shock you up a bit by making claims of saying “no” to your customers or saying “no” to project meetings. It’s like a cold shower for your brain, and once it has gotten its attention, it reasons with you as to why you would want to say no in certain situations and why you would want to say yes.

As a developer, the philosophies in this book are empowering. A lot of times, my projects experience some scope creep, where wouldn’t it be cool if it did this or while we are at it, let’s add that. This is fine, but as deadlines approach, you start having this juggling act you have to do where you give up one thing to make another happen, often times leading to everything being in half-assed. Getting Real’s point of view is to cut back some of the scope and make sure that the basics work. “Build half a product, not a half-ass product”. If those extras really needed to be in, they will make it in eventually, in a new iteration.

By doing this, it also allows you to focus on what is important. Adding some new sorting feature is definitely less important than making sure that the data it’s sorting is correct. And this is where a lot of the agile philosophy comes in. Start with the most basic functionality needed first, usually the HTML(hypertext markup language). The HTML is the interface for your application, and that’s everything that’s important to your users. For the first round of HTML, everything doesn’t have to be pixel perfect just yet. Once that is done, then building out the basic functionality to link everything together can be built, focusing on the main aspects of the backbone of the application. For instance, if you are doing a blog, the functionality to write the blog is more important that that of displaying the blog because you can’t display it if you can’t write it.

All in all, this was a good read and it is a fairly quick read. While there are many PDF pages, a lot of it is filled with quotes from all sorts of people. If you ignore the quotes, you could finish it in a night or two. You will do it a little injustice, as the quotes and little stories really bring home the points of the book. I am going to try to use the lesson of this book to apply this to my next software project.