<corruptmemory>

Like the MacBook Air, Apple’s newest object for those who are technology and rationally challenged to spend their cash on, the iPad, is merely a packaged series of errors and mis-judgement doomed to failure.  Wait, I take that back, in a reality where people are actually capable of reasoning about the value and utility products offered by companies the iPad would never see the light of day, but we do not live in such a reality.  Instead, we live in a reality where, ironically, a company that produced one of the best TV commercials ever, the infamous 1984 commercial, has itself become the “big brother” of the book “1984″, mixed with the depressing cynicism of H.L. Menken.

As for the 1984 aspect of Apple it all boils down to DRM (a.k.a. digital rights/restrictions management), and a completely walled off garden in the form of the “App Store”.  I will not belabor this aspect of the new iPad as the Free Software Foundation has already done that for me and then some.  Instead, I want to concentrate on a number of assertions made by Steve Jobs during the iPad unveiling event.  In particular, Jobs made a claim that a “new product area” would need to be better than both the smart phone (iPhone) and laptops (well, clearly he means Apple’s laptops) in some “key areas”.  Those “key areas” are:

• Browsing
• Email
• Photos
• Video
• Music
• Games
• eBooks

I’m not making this list up, you can watch the video yourself and at about the 7:59 mark you will see this list up on the big screen.

So, as you might guess, Jobs’ final claim is that the iPad is better at doing the above “key tasks” than both a smart phone and a laptop.  Let’s examine these claims a bit more in detail shall we?

Browsing

Frankly, it is a no-brainer to show that the iPad (and the iPhone for that matter) is not better at browsing, or providing a browsing “experience” than a typical laptop, hell I’ll put up any Netbook against the iPad any day for browsing experience.  Some bullets:

• No flash support
• One page open at any time
• No rollover-effects (because no mouse), like accessing menu items
• Cut/copy/paste still a severe pain-in-the-ass
• Browser does not have plugin support (like FireFox or Chrome)

For many Apple product drones the problems associated with the above issues have already been erased from their awareness.  For those that still retain their full reasoning capacity it’s like using a browser circa 1997.

Email

Oh come on now, seriously?  The iPad is better than a laptop for email?  On a laptop you can choose to use Web mail or from a wide variety of email clients with various combinations of ease-of-use and power.  But of course, email clients need to be able to run the the background to fetch mail.  Something that Apple outlaws (wrongly) on the iPad as well as the iPhone.  Then there is the on-screen keyboard, you know, the one without a dedicated number row.  Sucks I guess if your say, an accountant, and put lots of numbers in your messages.

Photos

Um, there is more to the world than looking at your photos forever.  At a starting price of ~$500 makes for one really expensive digital frame.  Also, what about integration with on-line photo services, like Flickr, Picasa, or on-line print providers?  Again, the iPad is far worse than a laptop for anything related to photos.  If your idea is that smushing around photos with your fingers offsets everything you lose on a laptop (or even a Netbook) then please, seek professional help.  Oh yeah, you can run the Gimp on even the lowliest netbook, so you can even (really) edit your photos, unlike the iPad.

Video

What goes for photos goes for videos.  Oh yeah, you can also really edit video on a laptop, and if you have a Mac you can get iDVD and go to town.

Music

Absolutely no better than the iPhone and clearly limited compared to any laptop or netbook.

Games

I really got angry when the issue of games came up, are the employees at Apple merely delusional to think that playing games on the iPad is better than playing games on a laptop, or are they merely slimbags for bold-face lying to people about what computers can really do?  Even if the horrid joke of doubling up the resolution of iPhone games wasn’t bad enough, do they think that even the best possible game imaginable for the iPad could even compete with say, World of Warcraft?

eBooks

Granted, this is the only “experience” that may lend itself to the iPad’s form-factor, but the iPad is considerably more expensive than a Kindle, not even in the same league for battery life or weight.  Further, many eBooks are used in conjunction with work, not merely pleasure reading.  For instance, books about programming are really useful where you can cut-n-paste examples into a code editor.

Conclusion

Compared to a laptop and most netbooks, the iPad does not live up to a single claim made by Jobs during the unveiling event, and offers only a bigger screen, more CPU horsepower, and storage over the iPhone.  It leaves off an integrated camera, microphone, audio jack, a multi-tasking UI, open application development that goes beyond the App Store, the lack of USB or even built-in flash media slots means you cannot even get photos on the thing without buying one form of lock-in (remember lock-in is a euphemism for money to business, and no, you don’t have to give into lock-in, don’t buy products that coerce you to work their way as opposed to them working your way, that is a friendly device, the iPad is not friendly) cable or another.  Or by copying/downloading photos from another source via a network or bluetooth. The iPad is an iDud.

Now, all this said, and given the reality that I described at the beginning of this article, I still expect the iPad to be financially at least a moderate success.  Why?  Because Apple has been fertilizing the public for years now with their attractive, but dumbed-down products, and the consuming public seems to be eager for more dumbing down because look at how pretty everything is.

Being one of the more prominent computer geeks in my extended family I get a lot of requests for “tech support”.  Recently, I replaced a hard drive for my father’s PC and recovered his XP partition from his old drive (dd is just a wonderful tool).  After getting the disk image restored on another drive and fortunately getting the new drive to boot up and run a chkdsk, I managed to get the machine booted with a minimal loss of data – the computer was merciful this time.  Once booted I took the opportunity to do some much needed house-cleaning: updated FireFox to 3.5, installed Google Chrome so my Dad can play around with it, updated flash and OpenOffice, updated to IE 8 (blech, but needed if going to minimize security problems and to access Windows Update), finally I started Windows Update.  For me, since this has become somewhat routine I understand all the jargon that gets thrown at me during all these crazy uninstall/update marathons, but it is amazing how intractably and irreducibly obtuse computers are for the average person.  The average person thinks of computers like a TV – turn it on and choose a channel and everything just works from there.  But computers, like life, are a sublime combination of possibility, power, wonder, frustration, and heartbreak – computers don’t work like the TV, there is no program schedule to tell you what’s up next.  Every time I have to jump into XP, or Vista, or even OS X to do computer surgery I’m constantly reminded as to how intimidating these devices must be to the average person.

A little while back, when I was first getting stuff together to get this site up and running I wrote about my adventures setting up an ActionTec MI424WR that I had gotten from Verizon as part of a FiOS package using OpenWRT.  Although it was a hacky solution it worked reasonably well.  Well, my two-year contract ended in January and now being February the router just had to take revenge on me for leaving Verizon and killed itself.  That just sucks.  Among other things it took my web site (this one ;-) ) offline.  So after some digging I came upon the Buffalo WHR-HP-G54 as a replacement.  It seemed to have good support with OpenWRT, so I gave it a shot.  Bottom line: great little box.  I’m not using it for wireless, but it has a radio “booster” for extra range.  Right now my house is saturated with WiFi and wired to the nines, but I needed a nice router I could rebuild my Internet access on.  I installed the latest Kamikaze image on it.  After toying around with the Web UI I quickly found out that the firewall config system was still not up to snuff.  It kept exposing router ports to the the Internet, not what I had in mind, but simply rebuilding the firewall with the original script from my earlier blog post and things just clicked.

Back in business baby.  Now I have a reason to finish my accumulating list of articles.

Tags: Internet, Maintenance

Still, a work in progress, but the main part of the site (outside of the blog) is now running within a heavily hacked version of gitit, a wiki engine written in Haskell. Since I’ve been learning about Haskell recently what better way to play than on the Web site? Seriously John MacFarlane is brilliant! Not to mention the HAppS folks as well.

Haskell is a wondrous language, and definitely the hardest one I’ve decided to learn in quite a while. I played around with Haskell and SML/NJ many many years ago (1991-1994 time-frame), and I really liked what I saw. Recently, though I’ve been thinking hard about programming and languages again, especially building large systems easily, and purely functional languages figure prominently in my thinking at the moment.

Tags: Haskell, Maintenance, Software Engineering/Programming

In response to Scale Later.

Problem statement

Building Internet applications is what I do (among other things, of course), I’ve been doing that since something like 1995. I’ve worked in numerous technologies and frameworks from bare-bones C/C++ to Rails and various Java frameworks (with many things in between), and I can say without a doubt: I always have a scaling problem.

In every Internet application I have built I have continuously been hit with the “scaling problem”, let me be more specific about what I mean about the “scaling problem”.

An application that can “scale” is one that can support the needs of 1 user up the needs of a very large number of concurrent users by following a relatively easy to implement recipe to deploy machine resources (CPUs, networking, storage, etc.) to support the concurrent user load you are interested in. The “scaling problem” is defined in terms of two parts then:

• How does one build an application that can intrinsically scale?
• Given an application that can intrinsically scale, what are the desirable properties properties of the “relatively easy to implement recipe” for deploying machine resources to support your desired concurrent use levels?

Furthermore, by very large number of concurrent users I do not mean tens or hundreds of concurrent users, I mean thousands or more. Please keep in mind that concurrent users is the important element here. Having an application with say a million signed up users but only 50 active or concurrent users is far less interesting to me in terms of building applications than say an application that has 5000 signed up users with 1000 or more using the application concurrently. If your expected number of concurrent users is probably going to be on the order of ~50, basically, forever, regardless of the number of “signups” then I would say that 37signals’ perspective is appropriate, and your long-term problems are going to be related to managing your data store. Such a scenario may be what happens with an internal application used within an organization. The interesting thing is that over time a lot of “internal” application and data have been given hooks to the “outside” world (a.k.a. the general Internet), many of these “internal” applications are not able to meet the challenge of higher concurrent user levels without significant and costly re-engineering.

What should the solution look like?

Firstly, I’m going to give a lot of credit where credit is due: Ruby on Rails succeeds completely in one area: building “old-fashioned” monolithic applications with a single RDBMS behind it, is, generally speaking, very easy. There are a number of other frameworks that have sprung up in the wake of Rails that refine or expand approaches made popular by Rails, which is a good thing. The problem with Rails (and basically ALL other frameworks) is that going beyond the limits of the assumed application model becomes progressively harder and more unwieldy. Many of the “niceties” the framework offered cease to be applicable.

So, to start off what I would like to propose is that we need a “solution” to the “scaling problem” that is as easy to develop with as Rails but does not become significantly more difficult to work with as one tries to scale up. Furthermore, the solution needs to be run-time efficient, as well as intrinsically be fault-tolerant.

Yes, I know it’s a lot to swallow in one go, but I think that it is entirely possible to solve this problem.

But how?

Start at the language level

My thinking starts with designing a computer language that implicitly assumes a run-time environment that is not confined to a single process or even the same machine: a distributed run-time environment. Now, many of you are going to shout Erlang!, or maybe Distributed Haskell, or Distributed Ruby, or maybe even Swarm. The ideas behind Swarm are probably the closest thing to what I have in mind, but Erlang and Distributed Haskell, while fantastically useful in their own right, are not what I have in mind. Why? Erlang and Distributed Haskell/Ruby, provide powerful tools (in the case of Erlang and D-Haskell language-based tools, DRb is a library) for abstracting the notion of communicating processes, but leave the notion of communicating processes as an explicit concept – I’m looking for a language/runtime that implicitly encapsulates the distributed run-time. Swarm starts to do that.

Literally, code that looks like (using Lisp-ish here):

(let ((x (some-func-1 ...))
      (y (some-func-2 ...)))
  ...)

could have the functions some-func-1 and some-func-2 run on the same or different machines or processes, the run-time decides what should be done, I should not have to care when I don’t want to care. The corollary to this is that when I do care where these functions run I should be able to say so. My thinking right now is that the specification of where a function gets run is metadata that can be supplied with the function definition/declaration, and/or in a separate specification file. This specification needs to both support a dynamic declarative representation of the rules that govern how to decide where a piece of code runs (i.e. it is an extensible domain specific language, or DSL)

From the above discussion it should be clear that the run-time will need to transparently ship both code and data around between process and machine boundaries. Erlang has a particularly good implementation of data marshaling, and Lisp’s “code as data” mentality clearly fits in here as well, but of course the language need not be Lisp-ish. Another characteristic that should be clear is that the runtime needs to efficiently support dynamic code loading/compilation because a freshly provisioned node or processes will have no code loaded into it and will get code as the distributed run-time decides how to use compute nodes. To some extent Hadoop does a lot of this, but as with most Java projects there is simply waaaay too much feeding the framework for my tastes and node provisioning is a chore, that said, Hadoop is rather amazing.

It is also clear from above that I want the ability to add nodes easily. Erlang’s approach to provisioning compute resources seems like a plausible way to start — it should be possible to start the language run-time on a machine (or multiple times on the same machine) and simply specify some key identification/security parameters, and how to join a run-time cluster.

Big problems to solve

From what has been stated so-far nothing has been said about how the run-time would utilize nodes. Clearly this is a non-trivial problem, and in general, there may be no “best way”. To some extent this is where the distribution rule DSL mentioned above comes into play. The DrDSL must not be a toy, it needs to be able to extensively probe the run-time, both locally and elsewhere to make decisions. For instance, perhaps the rule for some function says to run that function on the same machine where a resource is “local”, such as a file, or maybe a scanner or printer. Here’s an example (again, Lisp-ish):

[[ <process-file-1> requires <file> as local file ]]
(define (process-file-1 file ...)
   ...)

Where [[ and ]] indicate the DrDSL code that is used by the run-time to decide where to run the code instance of process-file-1. Furthermore, in a large deployment it may be that for any particular resource, such as a file, there may be more than one copy. This brings us to the issue of fault-tolerance.

In building big, it is useful to follow the sample of Google with their approach to map/reduce. In particular, my preference is a lot of cheap commodity hardware that is prone to failure. And failure should be automatically dealt with. So for example, let’s assume the process file code as listed above. Let’s say that we have three nodes, N1, N2, and N3, with the file foo.dat. Node N1 is chosen by the run-time to execute an instance of process-file-1. Mid-way through the computation node N1 becomes unavailable, the run-time should simply select from nodes N2 and N3 and re-start the computation.

Clearly, I’m glossing over huge issues such as transactional integrity (what if process-file-1 has some side-effect that was partially realized? How do we restart process-file-1 on another node cleanly?), but I’m fairly certain that such problems can be resolved as well (I’m not implying that these problems can be solved easily, mind you, there are a number of graduate theses that could be applied to addressing this problem).

So, where are we?

From the above discussion it should begin to become clear that if we has such a system we could write our code for distributed application easily more-or-less as if we were writing our code for a single machine/process. Agreed, it seems a bit “pie-in-the-sky” like, but I feel that something like the above is both needed and inevitable. Mayhaps I should start working on it?

Tags: Distributed Computing, Fun, Internet, Software Engineering/Programming, Web

Been a while.

Fortunately, for good reason: I do have some freelance work that I’m cranking on, all thanks to Andy Parsons. Anyway, cranking away on Rails while Andy pounds out (and drinks) the Java.

“What?” you say: “you’re doing a Rails project with all that purty purty Ruby code why do stuff in a blech language like Java?!” Well, because we do need parts of our system to have both higher intrinsic performance capability and to naively scale with available processors to pick up the thread load.

When the Ruby folks get serious about threading and performance (hint: dump YARV and hit up Parrot) we can revisit this conversation.

I have a number of posts in queue, hopefully I get them out soon.

Tags: Fun, Hacking, Java, Programming, Rails, Ruby, Software Engineering/Programming, Web

Google is open-sourcing technology to enable secure execution of native code through browsers. This has long been the holy grail. Yes, JavaScript is cool, but you can’t write a video codec in it, or implement a relational DB efficiently, and it’s not multi-threaded. There are examples of the absolute wrong way to do this, so let’s hope that the engine of open-source development continues to demonstrate it’s superiority.

Tags: Google, Internet, Software Engineering/Programming, Web

Well, in looking for gainful employment one of the places I applied to was Google. Honestly, I have no way to gauging my chances, but I guess I’d be better off assuming I’m a long shot. With this in mind I came across a really good blog: good coders code, great reuse. In addition to some really excellent posts Mr. Krumins also interviewed for Google and wrote about it here: My Job Interview at Google.

It’s a great write-up, and his prep for it has inspired me to break out some of my algorithms books (including my first edition of the fantastic Introduction to Algorithms ;-) ) and check out the online classes from MIT. The “Introduction to Algorithms” class material can be found found here.

Web programming can rot the brain: there is so much more than SQL and constructing snippets of HTML strings. Time to get back into shape.

Tags: Google, Software Engineering/Programming

It has been a while since I updated the blog, apologies to all you loyal readers: been doing some Merb hacking on the site, and finally got a version of my resume up, now I’m sure to get a job! ;-)

Anywho, I do have some essays/entries lined up:

• A Merb tutorial/HOW-TO — No joke I got a hit from a Google search (Woo hoo! Google knows I exist!) looking for a Merb tutorial, and I have none! I can’t let that stand!
• An essay on Web development and ideas on how to build big
• I have been following a lot of the work that Jonathan Haidt has been publishing recently, and looking at the criticisms that Sam Harris has been making of that work. I have a number of opinions to share in this subject. In the mean time check out Jon Haidt’s web site and the Moral Foundations site, really good stuff.

Sorry for the radio silence. Looking for work that doesn’t suck, and hacking code for this site take their toll on my attentions. Fun on its way!

Tags: Ethics/Morality, Hacking, HOW-TO, Maintenance, Software Engineering/Programming

Some people know me as the retired “Chief Pain-in-the-Ass” (a.k.a. “Director of Platform Architecture”) of DigitalRailroad (warning: previous link may not work too much longer!) (DRR). Not quite sure how much weight should be placed in that title as the primary applications that ran DRR merely grew rather than being “architected”. Oh, don’t get me wrong, there were parts of DRR’s software that had a lot of careful design and thought put into them, but the core apps were basically monolithic ASP.NET applications that started out with a particular structure and simply grew that structure over time.

Eventually it became clear to all that something had to change.

Sometime in the last two years I finally made a successful case to not only do something about the code base that was crushing the life out of the development team (especially me), but to finally get off of the Microsoft platform and migrate to GNU/Linux. I vigorously argued for a complete rewrite in some new framework, but lost that argument. Instead, it was agreed that we would eventually get everything off of ASP.NET but it had to be done incrementally.

What should we use?

The first thing at that point was to decide on some framework to work with. I wanted to avoid a compile+deploy system so I wasn’t considering Java-based solution at the time (more on this in another post). The shortlist basically consisted of:

• Ruby on Rails
• PHP+<something that made developing with php not suck>
• Perl+<some wicked-cool toolset to make perl Web development nice>

Yes, some will say that I should have considered Python and a framework like Django or Twisted, but seriously, I’m just not a Python fan, I can code in it, but I get no joy out of it (yes, I know it’s good enough for Google ;-) ).

After some testing, and a lot of discussion Rails was the winner. Now, I had been doing a lot of work in Rails the prior year and change. I had been showing off mockups of DRR in Rails since something like version 0.10 of Rails, but in all that I had learned a fair amount about what does and does not work well in Ruby and Rails.

Rails? What worries?

There were, and are, a lot of things to like about Rails, and frankly, I am rather happy that David Heinemeier Hansson (a.k.a. DHH) got inspired to use Ruby the way he did. Ruby is really a pretty language, and Rails is a pretty framework, but both have their demons.

Firstly, Ruby is slow. Yeah, yeah, I’ve read all over the place that I shouldn’t obsess over Ruby performance: “it’s almost never Ruby’s fault the your application runs slowly: focus on the DB.” Except that that bit of advice is complete bullshit. Ruby is slow and exhibits it slowness in painful ways, i.e. when you’ve done something to waken the Ruby slowness demon you will know it right away, it is not bashful. Like what for instance? How about looping over something with conditional code in it, such as:

def do_something(args)
  result = []
  args.each do |i|
    if i < 0
      result << "Less than zero"
    elsif i == 0
      result << "Zero"
    elsif i == 1
      result << "One"
    else
      result << "Greater than one"
    end
  end
  result
end

Now, the above is a bit contrived, I agree, but it shows the basic nature of the beast: if your code is chock full of executable statements as opposed to things that map directly to a C-call (like working with a Hashtable) you run the risk of your code being very slow. Much of this problem is being addressed in Ruby 1.9.x with the YARV VM¹, but in Ruby 1.8.x innocuous day-to-day programming can become your worst nightmare. The solution, in general, is to re-design your code to eliminate the use of intrinsic Ruby statements and structure your code in a way that almost exclusively uses constructs that are directly implemented in C (i.e. native). This performance feature ;-) of Ruby periodically makes an appearance resulting in lost development time appeasing the Ruby performance gods². Then there are all sorts of performance problems that arise from garbage collection activity, but I won’t go into details on that (lucky you).

What about Rails? Well, Rails has it’s own performance issues (not the speediest of frameworks, but not horrible either), but more importantly, Rails had (at the time) a tendency of being a memory hog and potentially unstable³, furthermore, deploying Rails apps was not fun using FCGI. Fortunately, the FCGI problem was solved with Mongrel⁴, but memory and stability were still a concern. Also, one of the painful lessons we learned with the ASP.NET site is that monolithic applications suck-ass in all directions: we wanted our “new” system to be modular, so we could update parts of the site easily, as well as scale-out apps individually instead of having one big app scaled to meet the performance needs of the slowest part. So, how would Rails help with that? Well, it didn’t out of the box. There were also a number of wacky things DRR was doing with URLs that simply did not play nice with Rails either.

Arguing with Rails

DHH says Rails is “opinionated software”⁵, so when you have to change something about Rails, I call it arguing with Rails;-). I had a number of fundamental arguments with Rails, the two most devilish were:

1. Getting Rails to work with and generate the URLs that DRR used on the site
2. Making it easy to build what appeared to be a single application to the outside world as a discreet set of Rails instances. ⁶

On our site there were 1 or 2 ways to address a particular photographer’s archive. If you did not have a custom domain for your archive then your URLs looked like this:

 http://www.digitalrailroad.net/<archive name>/...

If you had a custom domain (a.k.a. “domain pointed”) for your archive then either of the following URLs would work, but preference was given to the one using your custom domain:

 http://<custom domain>/...
     - OR -
 http://www.digitalrailroad.net/<archive name>/...

Now, for various reasons, including the fact that in a development environment you didn’t want to keep having to edit your /etc/hosts files it was necessary for Rails to intrinsically be able to deal with and generate both kinds of URLs using Rails’ built-in routing mechanism. In order to accomplish this I created the DRR Rails plugin⁷. This plugin monkey-patched Rails’ routing guts to transparently deal with the DRR urls, and to boot it made available all sorts of wonderful data about the archive the user “was in”.

The other problem of making it easy to build DRR as a set of Rails instances was solved with a number of additions to the DRR Rails plugin. The plugin enabled an easy way to package a shared collection of routes and route files in the plugin itself. It also effectively implemented a namespace mechanism (I called them grouped routes) that allowed URLs to be generated to any route (using named routes only, then again, naked route generation has been shunned for quite some time now) but only recognize routes for the current application instance. This approach promoted a lot of DRY⁸ code and made it possible to work on and develop isolated parts of the DRR application. The whole approach I called the “micro-apps” way to build a site.

The above approach worked really well⁹, and it resulted in achieving the sought-after goals: componentized development, and performance and process isolation. Slowly but surely we could replace the old ASP.NET application.

Towards the end of DRR I began working on a port of the plugin to Rails 2.x. Since the plugin is a lot of monkey-patching of Rails core I knew there was no way it would just work in Rails 2.x. Probably 1-2 weeks of concerted effort and it would have been done. Rails 2.x did also promise performance improvements.

Hey, didn’t you mention something about Merb in the title?

Yes, yes I did. The tie in to Merb is that Merb has a more hacker friendly approach to building things than Rails IMAO. In particular, because of Merb “slices” Merb has a clean and robust implementation of URL namespaces and application componentization that would have worked very nicely at DRR, also the Merb routing mechanism is nicely pluggable meaning a lot less (perhaps even no) monkey-patching! This would have been a real productivity boost had I had it early on. Alas, at the time I was doing all of this Merb was barely a glimmer in someone’s eye, but it seems clear that the Merb folks have intelligently learned from Rails’ history. Furthermore, the Merb folks take performance very seriously and have done wonders to achieve high performance with a powerful framework that runs in a fraction of the footprint of a typical Rails app. In fact, Merb has shown up on this site as it runs all of the non-blog content (not much at the moment, but I “have plans”).

Expect to see more on Merb in the future. For now, if you are considering a Ruby Web+ framework Merb should rank prominently on your “short-list”.

1. Why the Ruby folks will not use the Parrot VM is still beyond me. [↩]
2. Frankly, I think that the Ruby folks are risking losing control of the Ruby language. All that is necessary is for one viable alternative implementation, other than “Matz’s Ruby Implementation” (MRI) to have good performance and have a decent debugging environment and MRI will be threatened with extinction. Just my opinion. [↩]
3. DHH even mentions numerous app restarts on their various 37signals sites [↩]
4. Thank you Zed [↩]
5. This approach to software lead to one of my favorite slides of all time! [↩]
6. All tied together with some Apache rewrite and proxy magic. [↩]
7. This plugin did a lot more than what is mentioned here. I do plan on breaking apart the plugin and releasing individual components as Rails plugins. Stay tuned. [↩]
8. Don’t Repeat Yourself [↩]
9. There was some getting used to this approach. [↩]

Tags: Fun, GNU/Linux, Hacking, Merb, Programming, Rails, Ruby, Web