Developing a Ruby on Rails web app from scratch
You don’t have to be a magician to develop web apps. With tools like Ruby on Rails and an established Scrum process, programmers can craft quality applications. In this article I’ll try to outline our development process for non-technical product owners.
Before the project starts, we communicate with the client to learn about the general product vision. We use Scrum for all of our projects. It’s a process focused on communication and delivering incremental updates. At EL Passion, we offer coaching and guidance to clients who have little or no experience with Scrum.
Choosing technologies for your web app
Depending on the characteristics of the project, we’ll choose the technology stack to build on top of. For data storage, a relational database like PostgreSQL is usually your best bet. Some projects may benefit from taking a different approach — like document-oriented mongoDB (for analytical tools) or graph-structured Neo4J (e.g. when you need social profiles with focus on connections between people).
You can divide a web application in two parts: front-end and back-end. Front-end is the presentation layer for your data — the user interface. The back-end is for processing and making the data available for the front-end. Another architectural decision that should be made is whether to use Ruby on Rails for both front and back-end or split it in two separate applications. So far we’ve had good experience using Grape for building powerful API back-ends. For the front-end part we would normally use AngularJS or EmberJS. They empower us to create smooth user experience without trading off development speed.
Our project starts by picking a single feature (e.g. user registration and sign-in) to develop within the first work cycle. We create a task board and divide the feature into many simple tasks. The smaller the tasks, the easier it is for the developers to divide the work inside the team.
Testing, Implementation and Test-Driven Development
After putting all this information together, the team is ready to build the feature. Often, writing an automated test comes before implementation of the feature, which is a foundation for programming technique called Test-Driven Development. A simple example is updating the user profile. At the beginning, developers write an automated macro that visits the user profile page, fills in the user profile form, and checks if there are no errors after submitting the form and if user data actually changed. First, this macro fails because the feature of updating user profile is not yet programmed. Only after coding the feature, the macro succeeds. Then the developers can improve their code and repeat the process.
Doing test-first forces you to make sure you know what you need to write before implementing it. This leaves less room for design flaws and ensures better code reuse. When you alter existing code, having tests for former features prevents regressions. There are many reasons in favour of writing tests and ultimately more tests means better codebase.
In the implementation stage we organize the agenda so that no two developers work on the same feature at the same time. When it’s impossible, we divide the problematic task further or utilize pair programming. It’s when two people share the same computer and work on one piece of code simultaneously which aids exchanging knowledge and assuring the code quality. After the feature is implemented, developers click through the application themselves to check the outcome of their work. It’s more motivating than outsourcing quality assurance to external testers.
Merging changes and deployment
Implementation is followed by committing and pushing the changes to revision control system. It keeps track of revision history for the whole life of the project. Before the changeset is deployed on the server, it’s reviewed by other developers.
Code review helps us guarantee code quality and it’s a great tool for self-improvement. The code isn’t merged until all comments and issues are resolved. When it’s finally merged, we deploy the new revision to a staging server, where the client can test the feature. Communication with the client is important during the whole process, so any issues can be addressed immediately.
After the feature is implemented and reviewed by both team and client, corrections are made. When the client accepts it, it’s deployed to production. The team is ready to work on the next feature and the cycle starts over again.
