I am no programmer.
I’m a normal guy…Uh…I don’t know why I find myself sniffing around API documentation on my lunch break, or why I end up staring into the screen at 3:00 am with the door closed and the computer sound turned way down so my wife doesn’t hear the casts from railsenvy . I mean, maybe I learned just a little conversational Japanese from watching fan-subs , but that doesn’t make me … one of those people does it?
Dame ka na?
Ok…so sure, I DO program, but it’s just to get things my clients ask me for up and in place. They need a blog and want it mega simple? Ok…I can find a way to do that. They need a contact form? No problem. Maybe they need a page on their site to list employees pulled from a database? Sure, Can do.
But about a year ago some personnel shakeups at an agency I was contracting for landed a heap of development work in my lap when I didn’t have anything else going on. Added to this was the fact that nobody else could take these projects and they were going to breach contracts if I didn’t personally step up and take them. The clients were depending on these projects being completed and I couldn’t let them down. So I bought Agile Web Development with Rails and got by with a little help from my friends. Thus I stepped onto the platform.
Huff huff, choo choo. I am now on rails, and the train is starting to get a little scary.
Sure: Ruby on Rails the framework, in a vacuum, is fine and easy to understand, but for an average designer/developer getting a site up the “rails way” takes forever. I get the magnificent ideas behind the framework. I gleefully gush “The rails way has taught me a WHOLE LOT” about web dev. Before Ruby on Rails I fled from databases, development, and had no idea what MVC was. Rails has been great to me and I’ve really tried to make it work. I still use Rails and will continue to use it in a variety of projects, but let’s face it: I am an amateur developer who is leaving the world of DreamWeaver Templates and entering the realm of partials and views. I’ve gone from a win XP box with the Adobe Suite as my primary development platform to a fatty mac pro tower where I spend most of my time in TextMate. I love rails…in theory…But I don’t think Rails is right for me.
Only full-time expert unix aware experienced full on web-developers hard core programmers can really appreciate rails. If you don’t quite get OOP in practice, a Rails project is going to take you a long time to get things done. The same thing that makes rails so strong is what makes it impractical for development novices: in each function, each method, each class, is a college course worth of material wrapped into a deceptively simple tag. The simplicity is deceptive…and for a dabbler, it’s going to be a source of frustration.
Rails is great if you want to make a scalable web application that is updated from time to time. It is not, however, a replacement for traditional web scripting, php contact forms, static sites, and all that. Rails is not the solution I’ve been waiting for that lets me put up a client’s store-front website.
But what nobody talks about is that although it takes 15 minutes to code a blog, it takes three days to deploy it the first time.
Too many moving parts:
To use rails for your site you need to depend on these layers:
- The HTML + CSS Layer: It’s a web site after all. We all know things go wrong in html and css all the time. IE: “Ooops. That new h1 style makes the page 1000 feet tall in ie 6 for now obvious reason.”
- Rails Itself as a layer: To learn new coding paradigms and the “rails way” to do everything. Rails is like an annoying date who wants you to know what she wants and gets mad when you can’t divine her whims. In itself, this isn’t so bad, and sure it’s made me a better boy-friend to my apps by making me think in new ways, but sometimes you need a radio button to control a simple session variable for an unregistered visitor – good luck finding out how rails wants you to do it. Turns a 20 minute update into a three day research project spanning forums, newsgroups, blogs, etc.
- The gems layer: The application broke and you don’t know why? Check your code…write your tests…gaze deeply into your development naval and try to find the lint. Oh wait…there was a gem update that broke the app and you need to roll it back? Too bad the repo for the gem is gone and the internet is packed with people trying to find it.
- Plugin layer: The rails way says you don’t make your own authentication, but script/install the restful authentication plugin. What to do when the Russian mob starts making trojan gems and plugins? Sure, you can freeze the app – go ahead and run without the latest security fixes.
- The SVN layer: I’m not sure why…but I’m told that if I’m not using SVN that I’m a total loser. This adds steps to every little change and provides a new layer where things can go wrong.
- The Capistrano layer: This can be a real time eater. Almost always when you are getting set up, and then at random intervals ever after. Wow, automatic deployment is a cool idea if it wasn’t like asking for water from a rock when trying to set it up with any host.
- The *Nix layer: Familiarity with Unix. Do I need to explain why this can be a trip down the rabbit hole? Again, sure it’s educational…but time consuming.
- The host layer: Hosting rails is neither cheap nor easy. You will pay more for a host who will partially support this platform and may or may not from the goodness of their heart help you write a deployment recipe for their environment.
- The DB Layer: Mysql and such.
So given all that, when something changes with any component, module, version, dependency for any of the above…something breaks. If you are managing 50 sites on 20 different hosts, you can’t keep up.
Or when a client proposes a typical change: “Oh, I forgot to mention that the metric support we talked about was actually a new class of “metric product” that has totally different properties, but needs to be mixed in with the other products in these complex ways….is that a problem?” In order to be flexible and propose a solution, I need to be secure in my comprehension of all these things and what they are doing…then I have to know the RIGHT rails way solution to implement for this. Does this mean STI for products with two types, Metric and Imperial? How does such a change affect the dozens of finished interactions with the basic product model I already have? Sorting by imperial-first, size ASC, then Metric size ASC? How do I even do that? Is it even possible?
In a simple framework, there’s always some way to hack it together…in a framework that requires always doing everything the “right way”, that option is gone. Knowing the “right way” to solve every problem is not something I expect to have for years and years.
Compare to a static solution or simple PHP or Perl script:
- The HTML Layer
- The PHP layer
- The DB Layer
- The Host Layer.
To solve my clients problem, I make the products into subclasses manually, then write a function to sort and parse it the various ways I need it presented at a given time. It’s time consuming, and code-drudgery, but it’s faster and the time is known. Of course, you spend your time reinventing the wheel and the product is often ugly.
But there are far fewer moving parts in the old way of just coding on new functionality like the new wing of a shanty-town shack. One is beautiful and far too complicated, the other is simple and ugly. I’d rather not use EITHER solution at this point. I’ve worked in crappy PHP shopping systems coded by fly-by-night make-it-work and pray operations. I’ve worked on sophisticated rails apps with other developers through a central SVN repo where we spent more time wasting time with cap, SVN, installing crap in UNIX, coordinating gems versions, etc than we did coding the app.
All this makes me think that the web demands a different kind of framework…something we might not yet have. Is it time for a more versatile framework that can function for applications that are online and contain some static pages and inversely within websites to provide some small functionality within the domain?
Summary
- Rails requires too many moving parts to be reliable.
- Rails requires expertise that make it inaccessible for less accomplished developers.
- Rails produces clean and attractive code.
- Rails simplifies programming but complicates maintenance.
- Scripting is VERY flexible and reliable.
- Scripting is open to anyone – no matter how unlearned.
- Scripting produces ugly and disorganized code.
- Scripting limits programming but simplifies maintenance.
Proposed:
The unique nature of web work requires a “Scripting Framework” that can also scale to be used as an application framework? Ruby on Wheels? Perl on a Pogo-stick?
To ask what people like me need and what types of environments are truly versatile in website of any stripe, I’ll be exploring this subject in my next post: “What is a website and what is an application?”