Ruby on Rails by far is my favorite framework for building web applications and APIs, a habit I picked up when I was a developer at present day Orpiva. Interestingly Rails is not my first Ruby framework. My first Ruby project was based on Sinatra and my second was based on Padrino. I believe in using the right tool for the job. For web applications and APIs I find Ruby on Rails generally to be a good fit.
If you are reviewing this document, the chances are you are interested in hiring me for a new project or interested in me taking over an existing Ruby on Rails project. This describes my approach to a new Ruby on Rails project.
New Projects
Ruby on Rails is a very flexile framework that can be used to build a simple website (the likes of a fancy online brochure) or a complex Software-as-a-Service web application catering the needs of hundreds of thousands of organizations and millions of users. The chances are if you come to me (or for that matter any Ruby on Rails developer) I can give you a high quality, fast and reliable solution that is also cost effective.
But you have to understand engineering a piece of software is a process. It starts by gathering business requirements. These requirements are then analyzed and features of the final product documented. Some features are more complex than others. Some features may not be feasible to be implemented in Rails (ex: a real time chat feature where we would use a Node JS based RTC app as a service). A project plan is developed prioritizing on urgent features.
The number of developers to be involved with a project depends on the urgency of the project and also the budget. When a team is involved the throughput doesn't proportionally increase with team size. It is in my experience that jumping from one developer to a team of 3 usually only increases performance by 2X.
Existing Projects
In the case of an existing project, the approach I take for such project will depend on the approach taken by the previous team. This is the case for both project management and software tools.
In the rare case the projects code quality is unacceptably poor and could pose a threat in the future as development continues such cases will be generally rectified in an as required basis and some times ahead of time.
Next
The remainder of the document will be some what technical including code samples so that it serves the duty of "code samples" in a hiring process. It is ideally reviewed by a developer with Ruby on Rails background but I will try to keep it simple as possible for non developers.