I Dare You Not to Fall In Love
I Dare You Not to Fall In Love
Read on to see why one developer fell in love with Ruby on Rails while learning it on the go, and the situations in which he believes it's best used.
Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
On the best parts 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. 
Well, this is my exact opinion of Ruby, my most favorite 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 an 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 start-up mode.
During the course of discussions on building a web application, I got a question: 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 management knew. I said, yes I can, but the technology will be Ruby on Rails. Which technology I used was not a concern of the business as 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 my time was spent on software development and 20% of my time was spent on management. I plowed on as a full stack developer, typing away at my keyboard for the most of the day, playing the roles 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, a forgot password function, 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:
If working with Ruby is the best part of using Rails, the second best part is the Ruby community. Remember, I had no architects or software engineers on 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
- Optimize for programmer happiness.
- Convention over Configuration.
- The menu is omakase.
- No one paradigm.
- Exalt beautiful code.
- Provide sharp knives.
- Value integrated systems.
- Progress over stability.
- Push up a big tent.
|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 with 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.
Published at DZone with permission of Mahboob Hussain , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.