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:
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:
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]:
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.
References:
[1] https://www.quora.com/What-makes-Rails-a-framework-worth-learning-in-2017/answer/David-Heinemeier-Hansson
[2] https://belitsoft.com/php-development-services/top-software-developers-after-40-50-and-60
[3] http://rubyonrails.org/doctrine/
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:
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]:
- 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
| 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.
References:
[1] https://www.quora.com/What-makes-Rails-a-framework-worth-learning-in-2017/answer/David-Heinemeier-Hansson
[2] https://belitsoft.com/php-development-services/top-software-developers-after-40-50-and-60
[3] http://rubyonrails.org/doctrine/
DZone republished this blog post --
ReplyDeletehttps://dzone.com/articles/i-dare-you-not-to-fall-in-love
It was really a nice post and i was really impressed by reading this Ruby on Rails Online Course
ReplyDeleteRuby on Rails Online Course Hyderabad
I Found this blog very informative and helpful to get good information. I'm very happy to share your info with us. thank you Keep Updating Us..,
ReplyDeleteBest Event Stalls Exhibition in India
Best Event Technology Services in India
Your blog post is amazing and full of knowledge, thanks for publishing your post. I want to tell you everyone that I also provide a Customize Ruby On Rails Services at a very prominent price.
ReplyDeleteGreat Blog Its Very Informative for ruby on rails course
ReplyDeleteHey!Amazing work. With full of knowledge. Our Team resolve any glitches occurring while utilizing the software. Looking for solution of Quickbooks Error 1712 Contact us +1 877 751-0742 .Our experts will assist you to fulfil your accounting needs. The solutions are accurate and time-saving.
ReplyDelete