Friday, 11 August 2017

I Dare You Not To Fall In Love

On the best part of using Ruby on Rails for software development, thus spake its creator David Hansson:
You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter. Just look at some code. I dare you not to fall in love.[1]
Well, this is my exact opinion of Ruby, my most favourite programming language but I couldn't have articulated it any better than Hansson.

Beauty, simplicity and aesthetics were not the main considerations in choosing Rails for my current project. I am part of a SMB that's into industrial manufacturing and services, in which the IT department is even smaller. So, strictly speaking, though I don't work in a startup, I work in a startup mode.

During the course of discussions on building a web application, I got a poser: can you make it at the lowest cost possible? My salary is a sunk cost, so the lowest marginal cost would be zero by developing the application myself. My incoming skill set when I joined the company was Java and Meteor, which was what the management knew. I said, yes I can, but the technology will be Ruby on Rails. Which technology I use was not a concern of the business so long as the application worked and was reasonably performant.

A full-stack programmer needs a full-stack framework, or a near-full stack framework. Meteor comes with MongoDb under the hood, so it's a full-stack framework whereas Rails does not come with a built-in database, so it's a near-full-stack framework. But if we leave the database part out, as Hansson stated, "Rails is full-stack by default. We have a pragmatic, full-stack answer that could be formulated based on that ideology that still offers amazing productivity from the second you run the rails new command."[1].

Thus I switched from a person who used to split time 80% - 20% between supervision and coding to the exact reverse: 80% of the time on software development and 20% of the time on management. I ploughed on as a full stack developer hitting at the keyboard for most part of the day, with me in the avatar of requirements gatherer, coder and tester all rolled into one. A person with 25 years experience and coding may be a rarity in my city, but I am not alone in the world.[2]

The application, an employee and customer engagement portal, is live and it could not have happened without Rails. The functionality I put in is: security layer with encrypted passwords, forgot password, role based access, authority based email notifications for approvals, paginated views, dynamically growing tables, pdf / Excel documents, bulk-emails, file uploads / downloads — all around the business logic, departmental workflows and management reports.

Along the way, I captured my learnings in applying Rails and shared them on my blog; these posts were re-published by DZone:
Title Blog Link DZone Link
Practical Rails : Adding a bootstrap theme
Steps And Commands For RoR Application Deployment On Linode Server
Applied Rails : Variable Rows For Child Records
Applied Rails : Customizable Text
Applied Rails: Bulleted Text With Prawn
Applied Rails: An Algorithmic Perspective
Applied Rails: Gems I use

If working with Ruby is the best part of using Rails, the second best part is the Ruby community. Remember, I had no architects and software engineers in my team. Online articles and forums were my only recourse if I got stuck. I always found helpful tutorials or answers to my questions. There is a certain down-to-earth and friendly attitude that I felt from the Ruby community.

No wonder the community has a value system that takes forward the full ideology of Rails enunciated in the nine pillars of The Rails Doctrine[3]:
  1. Optimize for programmer happiness
  2. Convention over Configuration
  3. The menu is omakase
  4. No one paradigm
  5. Exalt beautiful code
  6. Provide sharp knives
  7. Value integrated systems
  8. Progress over stability
  9. Push up a big tent
Alhough the bulk of my career was with large applications and teams, over the last three years, I have worked with companies and projects that can be described as startups / startup mode / small-team companies. When some asks my opinion on technology choice, I suggest as a first cut:
Stage Framework Language
Startups, mobile device focus or build MVP to get funding Meteor JavaScript
Startups without mobile device focus or early stage companies Rails Ruby
Funded projects Spring and Hibernate Java
Established companies with massive scale Polyglot Programming Java coexisting with Scala, Node.js, Python

When I look back I feel satisfied at what I could deliver. Based on my experience, it seems to me that the third row in the above table can be eliminated and the stage merged with the second. That is, enterprise application development should happen in Rails rather than Java, notwithstanding the immense appeal of Spring Boot. Of course, this is my opinion based on my experience and influenced by the local ecosystem. One thing I can say emphatically is that Rails brings high productivity with small teams, in other words, lower costs.