Perhaps no other medium is as malleable as software development. The platforms we build run the gamut from complex mobile apps to scalable distributed cloud services. And hey, what’s the raw material that we take advantage of to incorporate our bold and mind-blowing ideas? Bits. Which are literally… nothing. Just think about it! The most significant, rapid and life-changing revolution in human history has happened over the course of just one generation. Crafted with bits of nothing physical at all.
A software engineer can convert any new idea to reality in a day. Compare that with, for example, an automotive engineer who spends years only designing the model and takes a few years more to release the final product. Most disciplines have to deal with the physical constraints of their materials, but pure thought is what software is made out of and this is what makes it so unique.
Challenge Accepted
Although coding may appear exciting beyond belief, we all know many software engineers who are not happy with their job. This path is full of dead-ends and threats of being stuck with a single, non-perspective project for many months. It gets boring if the project you’re working on doesn’t challenge your knowledge and problem-solving skills. Many people even say that the choice of language determines the quality of the projects you will work on.
Out of the (Tool) Box
Nevertheless, the most seasoned software developers thrive well in the most challenging projects that provoke out of the box thinking and move beyond repetitive tasks. We all want to be challenged, this is how we grow as professionals. It’s not easy to set requirements or to design clear and scalable systems. It’s a huge challenge to write an efficient code, to optimize it, or debug it in a multi-threaded environment. Once again, it’s not easy, but it’s enormously rewarding. We often find such a challenge in the specific kind of projects – the rescue missions. In the article “Calls for action! Team Rescue Missions”, we discussed our perspective on how it takes to successfully conduct that kind of “intervention”.
What Is Ruby’s Hidden Strength?
The Ruby programming language is at a point of maturity that most programming languages can’t claim. Ruby is still popular despite being nearly two decades old, and it’s still a highly reliable technology and is currently in wide usage all around the world.
However, over time it’s clear that Ruby might have lost a bit of its appeal though which has resulted in a reduction of new web applications being built using it. In the last few years, many alternatives have appeared as Ruby’s competition such as JS or Python.
But, paradoxically, the fact that there are relatively fewer new businesses developed in Ruby might be an advantage for this programming language as many of the Ruby projects are about maintenance for existing systems which were created a few years ago when Ruby was on the rise. Now, some of these software projects require the kind of support that our recovery missions are specialized in. Others simply need to be maintained (or occasionally, just kept alive!). As you can see, working as a Rubyist you might just have the opportunity to be involved in a challenging type of rescue mission project and seize the opportunity to develop your problem-solving skills.
It was like that in our case. One of our clients’ projects turned out to be a huge challenge for Rubyists, so much so that it required a fairly creative code approach.
Our Ruby’s Rescue Mission Case Study
The Client
The client is an award-winning online gambling site, established in 2006, that offers comprehensive information about all aspects of gambling and unbiased advice and feedback for players.
The platform, with over 100k members and 2 million visitors each month, aims at delivering reviews on online casinos, games, tournaments and contests. It also hosts one of the largest online casino forums with over 130k registered members and hundreds of casino representatives present on the forum.
The Project’s Background
The weakest point of the whole project was the database. Everything revolved around the database and all communication with it was poorly optimized. The old version of the application was made in such a way as to ensure its relatively smooth operation, while the first real problems only appeared when it was necessary to scale the architecture or add new functionalities.
All in all, the whole system had been designed without much consideration of possible future development, and as a result, there were several flaws in the design because the previous programmers failed to consider how the application might grow in the future.
We were tasked to thoroughly rework the database to make the interaction with it clearer and easier for Ruby on Rails.
The Biggest Challenge
In fact, these two projects were running simultaneously as it was not enough to prepare a new version on the platform for the client. The new version had to be completely rewritten from scratch, while at the same time, the existing version of the site had to be kept fully operational and changed step-by-step without affecting its use.
Both of these two versions had to be properly deployed so that they were under the same domain at all times. Moreover, both versions had to keep different elements of the application operational and make them interact with each other. We also had to make sure that everything we do won’t interfere with the operation of the website and that there will be no negative consequences of the provided changes.
The thing that impressed us most about Rails was how it supported nearly all tasks that we needed to focus on such an advanced and complicated development process. Even though our client’s case was large and complex, we came across very few situations where we had to do things differently than Rails had implemented by default.
During the course of our work, there were separate databases handling the old and new versions of the application and our task was to maintain not only the application data, but also the user sessions in both versions and in real-time. Managing and synchronizing two databases in the same application was not as scary as it sounds even before Rails 6. Session sharing on the other hand required more customization. We settled on using JSON Web Tokens (JWT) stored within a custom cookie. We stored the session data in a shared Redis database so regardless of which version of the app created the session, it could be seamlessly continued on the other one.
If you’re interested in finding out more about the specificity of rescue mission projects, don’t miss out on our previous article, where we spoke about:
- What types of goals and situations are covered by rescue mission projects?
- How does it work?
- Who can be on board the rescue mission team?
- What kind of “superpowers” does it require for developers to become software hero?
- What are the all stages of a successful IT rescue mission?
