The funny thing about that is, this particular cuddliness of Rails has seemed to split the Rails camp into two groups of people. Yes I know, generalization is bad, but it’s convenient. In one corner, we have the hardcore developers who know the entire framework inside and out. These are the ones that can break Rails down into it’s actual and somewhat separable components. They know and understand how ActiveRecord (M) is separate from ActionPack (VC), which is separate from ActionMailer, which is separate from ActiveSupport, etc. They see both the forest and the individual trees that make the forest possible. The other corner of developers couldn’t care less. They’re using Rails as an all-in-one packaged deal. Like (some of) the old MFC developers of yore, they couldn’t tell how things work under the hood, they just care that it does.

Having said all that, in the spirit of “experienced-based” teasing out of great ideas, I think Rails has gotten to the point where it’s interesting to take a look at some of the concepts from which it is comprised and acknowledge them each individually. It’s time to not just look at the largest common denominator, but each reasonably sized denominator as well. I’ll skip the obvious cookie-cutter cliche ones like MVC and ActiveRecord. I’m going for the more underrated things.

Granted, I haven’t put much thought into this. This post is just a result of me thinking: “These ideas would and should work anywhere and everywhere”. Here’s my top 5:

5) Unit-testing and testing in general. I guess this falls under “cliche”, but the fact that Rails comes with testing ready out of the box speaks worlds of how important it is to all software projects. This is a should have/must have for any project

4) Mongrel (included in Rails 2.x I believe). It’s not this particular piece of software that I like, it’s what it represents. It screams “acknowledge your entire stack”. Mongrel was written to address the specific performance issues with Rails apps, but every project should have its Mongrel – its underlying engine that makes it run and run fast.

3) DB Abstraction/Migrations. MySQL, Oracle, SQLite, PostgreSQL, WhoTheHellCaresSQL. They should all be made to behave the same. Yes, I run SQLite on development and test, but MySQL on production. As long as I keep in mind the performance characteristics (see #4), who cares which DB is running?

2) Development, Test, and Production environments. Every project has some variation of these three environments. Every project should formalize that fact! Make it configurable in a YAML file! The fact that Rails comes with this out of the box makes development so, so easy.

1) Documentation. ‘Nuff said. If you don’t document it, it never happened.

While I am quite happy to leave it at that in describing OOP to novices, that explanation itself never suffices for me. The above explanation does not explain interfaces, abstract classes, and class hierarchies. The explanation leaves no room to think about proper design of interfaces, object relationships, and above-all, separation of concerns, which are all fundamental concepts in OOP.

In truth, I believe the answer lies in the fact that we’re not so attached to Objects as we are to Types. For example, if we take time to the most basic of expressions, like:

x * y

We might infer that we are working with integer or float types. In fact, this is basic type inference operating in the human brain. However, taking an expression like:

"Hello" * "World"

We might be much less inclined to give a proper explanation for what this might do. This is because we understand string types don’t naturally implement multiplication.

From the most basic examples like this, we come to understand that we don’t rely on values so much as we rely on behavorial contracts. Even at the most basic primitive types, we understand the types that implement ‘+’ and the types that implement ‘*’. Extending this to the higher level objects, we come across the most elegant way to describe our logic in programming statements.

By thinking about types, from the simplest Printers to design-pattern favorites like Factories, we can reason about our code in a way that lends itself well to implicit understanding. We can also reason about our code not necessarily from the point of view of the object (which is just an instance, just a “value”) but the interface for which that object implements. And because we reason about interfaces, we are really reasoning about complex types – a concept that is much more universal and broad than objects.

So really, when we talk about object-oriented programming, we’re basically presenting a misnomer for type-oriented programming, which is a much stronger and older concept than objects. While this explanation might seem trivial to those not necessarily curious about the details, to me, it helps classify and generalize concepts which may seem to be pure convenience (Objects) to concepts that are more universal (Types).

• Download the latest apache src from http://www.apache.org. In my case it was version 2.2.4
• Extract the src to a directory where you keep all your src files, cd to that directory

./configure –prefix=/usr/local/apache2 –enable-so –enable-mods-shared=most
make
make install

• Replace /usr/local/apache2 with the directory you’d like apache to be installed in. I named mine apache2. The above command will build apache2.

cd /usr/sbin
sudo mv httpd httpd.apache1.back
sudo ln –s /usr/local/apache/bin/httpd httpd
sudo mv apxs apxs.apache1.back
sudo ln –s /usr/local/apache/bin/apxs apxs
sudo mv apachectl apachectl.apache1.back
sudo ln –s /usr/local/apache/bin/apachectl apachectl

• httpd (the binary for apache) version 1.3 is installed in /usr/sbin/. You can see the version by typing “httpd -v” in the command line. Replace this (after backing it up) with a symlink to our new apache2 httpd binary. This should also be done for apachectl and apxs.
• At this point. apache2 is already running on your system, but the conf files are not quite ready. Add the following to your httpd.conf (found under /usr/local/apache2/conf). The PidFile is where the Personal Web Sharing manager looks to see if an apache instance is running.

PidFile "/private/var/run/httpd.pid"

• You should also add the following to enable user directories.

<IfModule mod_userdir.c>
UserDir Sites
</IfModule>
Include /private/etc/httpd/users/*.conf

• At this point, you are all set. Try toggling the Personal Web Sharing on and off. The next steps you might want to take (optionally) is to add MultiView support and change your DocumentRoot. These can all be done in the httpd.conf file. You might also want to uncomment the line that includes support for http://localhost/manual/
• You can also find the previous 1.3 conf file at /private/etc/httpd. Notice how much more verbose this conf file is compared to the apache2 conf file. This is because most of the additional conf settings can be includes via conf/extra directory.

Unfortunately, another requirement is that the client must deal with Unicode perfectly. After all, in today’s international world, it’s just plain wrong to implement anything with purely 8-bit ASCII in mind. Specifically, in this implementation, the plaintext is encoded in utf-8, then encrypted in AES, followed by an encoding to base64. The web client is of course then responsible for receiving that base64 blob out of the XMLSocket and attempt to display the original plaintext properly.

It sounds easy enough, but the shopping for various open source parts took me longer than expected. In light of that, I’ve decided to document the various implementations I found useful.

The first step is to take that base64 blob and convert it to something useful. In C, we’d want to tear it down to 8-bit bytes in order to feed it to our AES implementation. Unfortunately, in JavaScript the notion of a byte is “nicely” abstracted away, so we’ll have to deal with strings. Using webtoolkits Base64 and Utf8 implementations, we can convert the blob to a garbled ASCII string. (i.e. 5Lit5paH -> 中文 -> [some unreadable 6-byte string] ). We can then feed this string into this Rijndael implementation. We’re now left with another string, which we can decode to JavaScripts internal Unicode representation. Voila!

The key to the particular Rijndael implementation I’ve chosen is that it has a well documented approach to dealing with bytes in JavaScript. In particular, it converts any ASCII string to its byte representation as an array of integers (i.e. “Hello” -> [104, 101, 108, 108, 111]) and then operates on those “bytes” following the AES algorithm. While this is slow, it is clearer than other implementations I’ve found.

Now that I am done fibbing, I’ll jump straight to my beef. The problem with abstractions is that they naturally take a multitude of forms, because not everyone can agree on how to abstract away simple mechanisms into higher level concepts. What usually ends up happening is as the levels of abstraction stack higher, the path to a simple task becomes simpler, but we lose sight of the overall picture.

If I take the first level of abstraction as assembly code/machine code, which abstracts away physical CPU instructions into some binary representation, I can argue that this first level of abstraction is as simple as anyone will ever get. It’s just add, subtract, multiple, and maybe a divide here and there. Add in some reads and writes and you’ve got yourself the basic LEGOs of every modern day system.

Our problems start here. The next logical progression is to complain that we need higher order constructs to be more expressive and more elegant in our approach to problems. This gives rise to higher level languages like C. Our complaints continue until we finally reach the pinnacle of general expressiveness, a strongly-typed, polymorphic, object-oriented, virtualized language (like Java) having lost all direct connection to those loveable adds, subtracts, multiplies, and divides.

Next we grow unhappy with how the general approach has become so … general… so we develop languages made for specific tasks. Out pops the glut of scripting languages, PHP, PERL, Ruby, JavaScript, VBScript, Python, and [insert your language du jour here]. We live with this lack of generality because we say things like, “Oh, but PHP makes it easier for you to do [Task A] and, oh, PERL is so much easier for [Task B],” all while sounding totally knowledgeable.

Don’t get me wrong. I like choices, but sometimes I think there is just too much emphasis placed on being “politically correct” in choosing the weapons of war.

Exhibit A. I’m building a web site to track financial portfolios in real time. This project entails (from back to front) interacting with several web services exposing interfaces via WSDL/SOAP then wrapping that functionality along with some peripheral necessities into another WSDL web service that manages entire portfolios made up of sets of stock symbols. Next this web service must have a client that can translate and expose these features as an HTTP service. The HTTP/HTML documents generated are then rendered in the end-user’s browser where we would like to have all the snazzy web 2.0 goodies to provide a GUI. That’s the at-a-glance high-bit description of the problem.

Now let’s count the alphabets in our soup (again from back to front). We’ve got WSDL, so I’ll choose to use a specific implementation of XQuery (mxquery by Donald Kossman et al.) to query the web services of interest, process the XML, and spit out more functionality in the web service extensions provided by mxquery. So far I feel good because I’ve tackled a 2 front problem using 1 (non-standard) technology. Next I need a SOAP client, since browsers don’t have direct SOAP functionality. I’ll choose PHP to do this for me since, again, I tackle two fronts with one language – SOAPClient on one end of PHP and bad-ass HTTP functionality on the other end. Afterall, PHP is the Hypertext Preprocessor. Next we need to 2.0 goodness so we’ve got to have AJAX running, making HTTP GET/POST requests to my PHP. Lastly, we’ll need CSS to make sure this whole ordeal doesn’t look like something from circa 1990.

Depending on how you count, you’ll get a total of 4 to 6 technologies/concepts in that quick little sketch. Although it might seem like it while reading through that grocery list of implementation decisions, the choices for what technologies and languages to utilize at what step are not easy decisions. Remember, you want to be able to say, “X makes Y easy to do.”

The problem? That was great and all for an individual project at such a small scale, but imagine having to build companies on these evolving technologies. You want to stay nibble, so you want to utilize all the newest technologies. “X makes Y easy to do.” But, you also want to have a go-to move that you can hang your hat on, because, frankly, the only way you’ll ever be flexible enough to utilize the perfect technology X to solve Y in the real world is if you churn through employees at a high rate. This doesn’t sound like a good solution.

Speaking of XQuery, it officially became a W3C recommendation less than 3 weeks ago. I don’t want to pick on XQuery, because I honestly love some of the decisions they made with the specification – it’s almost as flawless as a commitee decision can be, but it is fresh on my mind, and it was what brought up my angst. XQuery, like all computer science, is an abstraction. It’s an abstraction built to handle the very specific task of wrangling the wild world of XML and taming it in elegance. PHP was an abstraction, an abstraction to wrestle and tackle the evolving problems in an evolving world of HTTP. JavaScript was an abstraction, likewise, to provide the richness to the browser. See where I am going?

No? Okay. Well, I never was a convincing person. The problem here is that these technologies are here to provide the layer of abstraction that is the essence of progress in this field. However, in doing so at such specific means, they diffract our efforts to generalize lower level problems into higher level solutions. Because as we tackle the problems we want to solve, we inevitably take on a whole host of specific solutions and are forced to piece them together. As I said before, this is essentially correct and great. Who doesn’t like to have rectangular LEGOs to make walls and square LEGOs to make floors? The problem arises when you’ve got a work force thats used to using square LEGOs all their lives and are now looking at rectangular LEGOs in that odd manner. Don’t believe me? Try talking to SQL folks about XQuery.