n today's ever changing world, it's next to impossible to know exactly what customers would want the product to be. Every day, we see new companies coming up with new products and services but have you ever wondered why most of the companies are not able to make it? The biggest reason many businesses fail is that businesses build unwanted products. Building a product exactly the way people want is tough and that is why only half of all establishments survive five years or longer according to the 2016 statistics. This ambiguity towards what customers need can be resolved only by identifying their problems systematically very early in the Product Development Life Cycle. That literally means we need higher customer engagement well before we actually have any product or service for them. Rapid Prototyping is one of the effective ways to do just that. We build prototypes of the products and put that in the hands of the potential customers to gauge their interest into our vision and this will eventually help us build world class products with higher success rates.
Prototyping is a System Development Method in which an early approximation of the final product, called "Prototype", is built and tested well before the final product is developed. The process is reiterated multiple times to refine the prototype based on the feedback received on previous versions of the prototype.
In the startup world, there is a pretty common word called MVP, which stands for Minimum Viable Product. Let's have a look at the definition Eric Ries gives to MVP in his book The Lean Startup: "the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." In the true sense of the word, MVP is quite different from a Prototype. MVP is something which will eventually evolve into the final product, on the other hand, there is no such obligation with a Prototype. In the current paper, we will use MVP and Prototype interchangeably for the sake of simplicity.
There are multiple concerns we would need to keep in mind while building a prototype, some of the important concerns are as follows:
Money Matters: Prototype building cost should be as low as it can be, without compromising the quality required for good feedback from the stakeholders.
Speed Matters: In order to reduce the time to market, it is very important to prototype fast and to deliver the product to the stakeholders quickly. As Reid Hoffman, the founder of LinkedIn, correctly believes, "If you are not embarrassed by the first version of your product, you've launched too late." Speed really does matter and early feedback is the key to attract paid customers.
Agility Matters: The process of prototyping should be agile and it should be able to incorporate multiple iterations to refine the prototype. This is one of the keys to answer the challenges in today's uncertain world.
If you have a look at the startup technology ecosystems around you, you'll notice many startups use Ruby on Rails. Have you ever wondered why? The reason is simple: it makes web application development simple, fast and super productive. Startups need to get the Prototype into the hands of customers to get quick feedback and iterate to improve. We need a technology stack that has the ability to help us build working apps quickly and efficiently and Ruby on Rails is a full suite that fits the equation so well that you can't afford to ignore it!
Ruby is an open source, strong and dynamically-typed programming language, which has pretty high readability and elegance to it. Ruby has a decent learning curve, flat in the beginning and fun to start with. It also comes with powerful features like Meta programming. The language has a very vibrant, active and growing community of open source contributors.
Rails, a web-framework built in Ruby, is an extremely productive full-stack web application framework. It has almost everything needed for the development of database-driven web applications out of the box. These features include ORM (Object Relational Mapping), Database Schema Management, RESTful API development, scaffolding, environment management, background processing, asset pipeline, tests and real-time communication using websockets, which recently got introduced with Rails 5. Since basic features of CRUD applications can be readily generated without writing much code, Rails is very apt for rapid prototyping and MVP development. Moreover, there are tons of open source resources available, should we have more unconventional stuff to built. Rails also plays very well with agile methodologies of software development. Last but not least, extensive usage of Ruby on Rails by many successful companies (including AirBnb, BaseCamp, Github, CrunchBase, Bloomberg, Scribd and Fiverr) for their production apps makes it a pretty reliable choice.
Now, as we've provided you with a brief introduction of RoR for prototype development, it must very tempting to jump into the field to build something awesome. However, before we get our hands dirty, let us have a look at the pillars on which Ruby on Rails stands on.
Rails follows a software design paradigm called "convention over configuration", which tries to reduce the number of decisions developers have to make without losing much flexibility while developing software. For example, if we create a Rails model with the name "Blog", the corresponding table in the database to save blogs will be automatically named "blogs" without specifying any special configurations. There are two big advantages of going this way. First, it keeps the developer away from the decision fatigue, thus making development faster. Second, code written by a Rails developer is pretty understandable to any other Rails developer.
This is a very popular architectural pattern in software engineering, especially for web applications.
As seen in the diagram, our rails application will be structured in the form of Models, Controllers and Views, where each of them have their own roles and responsibilities. Models just care about data, Views just care about the presentation layer and controllers build responses using Models and renders them into Views.
Software architectures can sometimes become pretty complex to understand and it is very important to have a healthy correlation between the architecture of the software system and the business artifacts. Business artifacts can be defined in terms of systems and subsystems consisting of multiple resources. These resources can be directly declared in Rails in a single file, which will eventually map various HTTP requests to actions on these resource controllers. This helps us maintain a simple routing system which makes a lot of sense as these routes directly represent business artifacts.
This also helps up create RESTful web services in no time. REST stands for Representational State Transfer. In REST architecture, everything is treated as a resource and a REST server provides access to these resources which are requested by a REST client. Let's take a simple example of "blogs" resource and "comments" sub-resource:
resources "blogs" do
resources "comments"
endHere, we have two kinds of resource "blogs" and "comments", and it is very evident, from the code, that "comments" resources belong to "blogs" resources. Writing these three lines of code in Rails Router will actually generate about 14 routes which will facilitate all kinds of CRUD operations on "blogs" and "comments". The table below shows 7 controller actions for the resource "blog", which will be generated by specifying the resource in the routes.rb file.
Now, let's discuss about how you can use Ruby on Rails to create a rapid prototype for a simple webapp in less than an hour.
First and foremost, we'll analyze our business case and we'll try to extract our model entities that would represent our business entities. Let's take the example of a simple Customer Complaint Management System. A very high overview of the system can tell us the basics functionalities of the system. Some of the key features of the project might include:
Customers can raise complaints
Support agents can change complaint status
Customer can comment on complaints
The resource models we can extract out will be "Complaint", "Comment", "User" and "Role", since we will have two types of users - customers and support agents. Here we have a simple ER diagram to show what relationships these models will have.
This is as simple as it sounds, here we'll generate the boilerplate structure of the application using rails new:$ rails new nitpick-box
Rails generated the whole structure of the application including an app folder that contains all the application specific code (models, controllers, assets etc.), a config folder for configurations, db folder for migrations and a test folder for unit and integration tests.
In the case of a conventional web application, it is very common to have multiple resources with CRUD operations, which becomes quite repetitive in nature to facilitate CRUD APIs. Fortunately, Rails provides out of the box command line tools for auto generating models, controllers, views, assets, database migrations as well as tests for the resources we specified, the process is call "scaffolding".
$ rails generate scaffold Role name:string
$ rails generate scaffold User name:string email:string role:references
$ rails generate scaffold Compliaint title:string description:string status:string user:references
$ rails generate scaffold Comment body:string user:references complaint:referencesIn the beginnings, most of the projects have huge uncertainties attached to them. We are not usually sure about what features we'll develop in the future and can't predict very well about how the database schema should be structured. One good way to deal with this problem is to use schema-less No-SQL databases (i.e. MongoDB, Cassandra). These databases do not have too much modeling or schema designs overheads. That makes application prototyping a breeze as far as database schema is concerned. One point to note here is that No-SQL databases do not have joins and do not have transactions support and thus they are not very well suited everywhere. This decision mainly depends on the business requirements at hand. For the sake of simplicity, we'll go with the default database here, SQLite.
Rails comes bundled with an ORM (Object Relational Mapper) called ActiveRecord and we usually do not really have to deal with SQL queries on our own. ActiveRecord Migrations, which is a part of ActiveRecord, helps us develop our database schema overtime in a consistent way. We can setup our database schema using the above command, which reads migrations and apply them to our database:
$ rake db:migrate RAILS_ENV=developmentIt is also interesting to note that Rails is database agnostic. That means that, if we wish to change our DBMS (DataBase Management System) in the future, it will not require a single line change in the code. For example, with ActiveRecord, if we replace the DBMS from MySQL for an application to PostGreSQL, we will not have to make any changes in our app code. That's pretty powerful!
For the app to have basic styling, we'll use Bootstrap, a popular CSS and JS framework by Twitter. In order to add that into the app, we'll add the gem "twitter-bootstrap-rails" into our Gemfile and then execute "bundle install". The next command will include bootstrap js/css files into our project and generate our app layout.
$ rails generate bootstrap:install static
$ rails generate bootstrap:layout application fluid
$ rails generate bootstrap:themed Roles
$ rails generate bootstrap:themed Users
$ rails generate bootstrap:themed Complaints
$ rails generate bootstrap:themed CommentsAfter using the above commands, our basic application will be up and running. Run the default server which comes with Rails using the command "rails server" and check out the browser at localhost:3000. Voila! We have an app and now we can try various CRUD operations on the resources we specified like Complaints, Comments, Users and Roles.
In a nutshell, before building a fully-fledged product with tons of features (built with tons of cash investments), it is of prime importance that we build a prototype or an MVP to test the market as no one really want to build something that nobody wants. Building a prototype involves multiple challenges like building cost, speed, agility, tighter feedback loop etc. Building good prototypes or MVPs is more of a matter of art than of science.
Ruby itself focus greatly on simplicity and productivity. The Rails framework on top of it literally boosts the productivity manyfold as far as web-application development is concerned. Thus, for rapid prototyping working web-apps, Ruby on Rails can simply be called a go-to solution. It's easy to learn, fast to develop and it just works.
Ries, Eric, "The Lean Startup", Crown Publishing Group, New York, 2011;
Hoffman, Reid; Casnocha, Ben; "The Startup of You", Crown Publishing Group, New York, 2012;
by Lőrinc Pap
by Ovidiu Mățan
