Pages

Sunday, August 11, 2013

9 Months Later...Web Development using RoR.

Web development that doesn't hurt

Its been 9 months since my last post but my adventures in web development never stopped. Well, that's not %100 true. Life/work constantly got in the way but despite the many interruptions and pauses, I've managed to  continue with my web development efforts. However, I have strayed a long way from the application development stack which I explored leading up to my last post.

Initially, I thought that I would only stray temporarily. After the arduous work of developing the  database-backed, J2EE-based, web-service integrated server and deploying the whole stack into the production amazon run-time environment, I hoped that adding more functionality by building on this foundation would be easy. I was wrong. The first challenge I hoped to address was User Interface. GWT proved too unwieldy for making fluid, responsive UIs. So, I searched for better Web UI frameworks. That search led me, inescapably, to the unholy trinity of of Web browser programming technologies:
  • HTML
  • CSS
  • Javascript
Initially, I was highy skeptical of these technologies because, in my mind, they were so 1990's. After all the browser compatibility wars of the 90's and 2,000's, I thought that for sure these technologies had given way to sexy new platform-independent technologies. Well, it turns out that these are the sexy new platform independent technologies. Much has been written about the browser vs native OS vs virtual OS  (like Java's JVM) software development approaches. So, I'm not going to rehash those arguments here. But the bottom-line for me was that as long as browser based web development was going to be a significant part of my software development interest, I had no choice but to dig into the HTML-CSS-Javascript trifecta. Though these technologies are considered client-side technologies...more specifically: browser-based client-side technologies, they have a heavy impact on the server-side technologies used to serve them up. And that's why a plethora of specialized server-side technologies  tailor-made precisely for developing browser applications have cropped up all over the web development scene. These Server-side technologies leverage php, python, ruby, javascript and other interpreted languages coupled with server frameworks like Laravel, Sinatra and Rails, for the sole purpose of making it easier to create dynamic HTML, CSS, Javascript content for browsers to serve-up rich/fluid UI experiences. After several weeks of floundering on my way to  discovering the deceptively simple assertions made thus far in this post, I landed on Ruby on Rails for my web application server-side framework. After many hours reading up on web application frameworks, watching developer conference talks, sheepishly trying php, ruby, javascript, jquery, html, css code snippets, Ruby on Rails stuck with me. One very big reason why RoR stuck was Michael Hartl's most excellent, absolutely awesome Ruby on Rails Tutorial which he has made public at no-charge on the web as a written tutorial. It's also available as an ebook or ebook+video package at very reasonable prices. His tutorial is amazing. The title says "Ruby on Rails Tutorial" but its actually a speedy study of a sizable chunk of modern web application technologies, tools and best practices. As the name implies, this includes RoR but the tutorial covers much more. From generally applicable Client-Server concepts like Model View Controller (MVC) architecture , RESTful application design, Source Control Management using Git and Github, Test Driven Development (TDD) to Web/Browser-specific concepts like HTML, CSS, Javascript, Ajax and much more, all covered in a very pragmatic, hand's-on, engaging way which never gets too heavy despite the sizable depth and breadth of the material...and that is how RoR stuck with me and how I stuck with RoR.

But despite the awesome RoR resources, and huge swathe of web application development capability that I've gotten since finishing Hartl's tutorial (several times) and creating several demo apps of my own, the ability to realize a fully functioning Minimum Viable Product (MVP) continues to remain just outside my grasp. The adventure continues.