Article  |  Development

5 Questions to Ask Your Ruby on Rails Support Team

13 Dec 2019

5 Questions to Ask Your Ruby on Rails Support Team

There are all sorts of situations that result in a company looking for a support team to maintain a Ruby on Rails application. We often hear from companies who had a freelancer, contractor, or single employee build an application for them, who have since moved on to other projects. Or a company has previously partnered with another agency that has shifted to other

Regardless of what situation resulted in your search for a new support team, you’re here now, and you need to find the best team to manage your application. What questions can you ask to make sure you’re partnering up with a team that you can trust?

We’ve put together some interview questions that any team experienced in support and maintenance of a Rails application should be able to answer. Here are some things to ask when considering a Rails support team.

What’s the longest they’ve maintained the same Ruby on Rails application?

If you’re in the market for a support team, you might be looking for someone to partner with for the long haul. It takes time and money to onboard a new development team – they have to learn about how your application is structured, get to know its quirks, and understand how it interacts with your business.

There are a lot of agencies that specialize in quick in-and-out fixes rather than long-term partnerships. We never hesitate to point potential clients their direction if they need short-term help, as that’s not the type of work we like to do.

If you’re looking for someone to maintain your app for a year or more, and a team’s longest partnership is a few months, you might want to ask further questions or continue your search.

At the time of this article (December 2019) our longest client partnership is over 12 years.

What service do they use to monitor application performance?

Development firms responsible for Ruby on Rails applications should rely on performance monitoring tools for your app. You might ask them for more details, too.

For example, ask them what metrics, specifically, do they keep a close eye on?

There’s a lot more to keeping an application well-oiled than fast page speed. They should be able to speak to performance with some experience. What areas of your project do they believe might have issues to keep an eye on?

We’re longtime customers of New Relic for this purpose.

The most common performance issues that we see in projects that we inherit are:

  • Slow database queries
  • Search indexes
  • A lack of caching
  • Missing database indexes
  • Slow AJAX requests
  • Slow page rendering on key pages

Ask them how often they check on these. Is this a high priority for their dev team? Do they get alerted when performance metrics cross thresholds? What examples can they provide of application performance improvement?

How do they prioritize upgrades with other maintenance?

Version upgrades for Ruby and Rails are necessary parts of support and maintenance for Rails applications. But it can be difficult to prioritize them within the workflow of regular support and feature requests for a live application. Version upgrades cost time and money to perform, but they aren’t necessarily noticeable for your end-users to see results from.

However, they’re extremely important for the health of your app. Whenever a Rails application gets behind several major versions, it stops receiving security patches from the team that maintains Rails itself. That means if a security vulnerability is discovered on an outdated application, the responsibility for fixing it falls solely on the development team maintaining that app.

It’s a lot of avoidable responsibility – especially when personal or credit card data is involved in an application.

We plan ahead to schedule these upgrades with our clients when possible. When Rails is planning a new major version, they usually announce several months in advance when they plan to release the version, and what older versions are no longer supported. We then put this on our clients’ radars if it will be a major upgrade. This allows them to budget for the time needed to perform the upgrade. As with most types of maintenance, if you do a little at a time, it doesn’t have to be a huge project all at once. When possible, we’ll upgrade to the newer minor versions of Rails between doing major upgrades.

Can I speak with a few past/current partners who are similar to my project?

It’s always helpful to speak with a developer’s past or previous partners for a first-hand account of how they work and communicate. It’s even more helpful if they have a reference who is similar to you. This could mean a similar industry, type of application, or

Ideally, they’ll have a few people to direct you to without doing too much digging. If they have trouble identifying someone that they have worked with that will recommend them, you might have uncovered a red flag.

What service do they use for Continuous Integration?

If the team is mature, they will have Continuous Integration (CI) in their workflow. This is a form of automated quality assurance on your source code.

In a mature development cycle, the following should happen:

For each significant change that a developer makes to the source code, the CI server will attempt to run an automated test suite. If the tests no longer pass successfully, the team is notified that a possible bug was introduced.

We’ve recently been using Solano and Bitbucket Pipelines for continuous integration on client projects.

We’ve had many projects come our way where the automated tests have been failing for months (in some cases, 2+ years) and the client doesn’t even know about the situation. Quite often, this was because nobody was responsible for keeping an eye on it.

We believe that when you hire a Ruby on Rails support team to handle your application, keeping up with automated testing should be part of their responsibility. This is a major quality check for your Rails app and important for your application’s longterm health.

Bringing in a new support team to handle your Rails application will never be perfect. There will be bumps in the road and uncertainties along the way. But asking these questions when you’re talking with potential partners will help you gauge how different teams work.

Continue Reading

Article  |  Development

Now What? Thoughts from a Planet Argon Intern

27 Nov 2019

Now What? Thoughts from a Planet Argon Intern


The leaves have almost all fallen off the trees as I look out the windows onto Vancouver Avenue, Thanksgiving is only a couple days away and with it marks the end of my internship here at Planet Argon. I’m sitting here reflecting on the past six months, a time I’ve come to dub the prologue of my programming career, a time that will, without a doubt, shape the course of my life moving forward.

Back in May, I took the plunge and joined Epicodus’ Ruby on Rails and React bootcamp, a twenty-seven-week course that took us through the foundations of web design leading into intermediate Javascript, followed by Ruby on Rails and SQL databases, and finishing off with React and Redux. It was a whirlwind of an experience and I’ve never studied that hard for anything in my life, but I would dare to say it’s been one of the best choices I’ve made so far.

Now, there are a few coding bootcamps in Portland, but the one thing that really makes Epicodus stand out is that they match you with a company to intern at for the final five weeks of the program. It was something I had looked forward to from the start and after falling in love with Ruby and the Rails framework, I knew that Planet Argon was where I wanted to end up for mine. After a week-long process of interviewing with various companies and another few days spent pacing anxiously, we got our pairings.

There it was, Planet Argon, and I couldn’t have been more excited! The following Monday I began and it turned out to be everything I had hoped for. I won’t go into too much detail on the time here, that’s something other interns have written about (you can use the shiny new search bar I built during my five-week internship to check out those stories). I will say though, I was really impressed with how they just let us dive right into projects and made us feel like we were a part of the team. I am forever grateful for the guidance and advice I’ve received while here and it has definitely been the highlight of the Epicodus experience.

So that brings us back here, looking out that window from the office I’ve come to call home for the last five weeks and I find myself asking, now what? I imagine it’s a question most of my peers from class are asking themselves as well. We’ve been released into the wild to apply these skills we’ve learned, but are we ready? Where do we go from here? How do we convince someone to pay us for this newly acquired skill set?

In an attempt to quell some of these anxieties for myself, I sat down with the founder of Planet Argon, Robby Russell, for some advice. What was intended to be a simple Q and A session for this post turned into a wonderful hour and a half conversation, much of which is beyond the scope of this post.

I’ve instead taken his words of wisdom along with advice from the tech community at large and distilled them into some key points that I think will be beneficial to myself, and hopefully, anyone in my shoes moving forward. I've found the best way to solidify your own understanding is by teaching others, which brings us to our first talking point.

A-B-L, Always be learning

It’s no secret that the tech field is constantly evolving, and it’s our job as programmers to keep evolving along with it, or risk being left in the dust. Maybe that’s a little dramatic, but it goes without saying that if you can stay up with what’s going on with the most popular languages and frameworks, your value to current and/or potential employers is going to increase exponentially.

We live in a very fortunate time, where most of the information in the world is sitting in my pocket at this very moment. Youtube, Udemy, Lynda, Reddit, and Stack Overflow are just a few of the amazing resources we have access to as developers to learn and share with each other. Don’t just stop at what will directly benefit the work you are trying to do professionally, maybe you are interested in learning some Python to mess around with some machine learning or perhaps you want to learn some C# or 3D modeling to make a video game.

Any coding is going to make you a better programmer in general so get out there and keep learning, stay engaged, and stay curious.

Seeking mentorship

A big piece of the puzzle that I was looking to put in place from my talk with Robby was in regards to seeking mentorship. Now that I’m done with school and the internship, I wasn’t exactly sure how to go about finding someone to mentor me. Having someone to bounce ideas off of, tell you when your code sucks, or help with understanding more abstract concepts is important as you grow as a developer. In school, we had teachers who are paid to be in that role, and here at Planet Argon it was made clear that our coworkers were there to help.

But what if you end up at a job where that mindset isn’t a part of the culture or end up working remotely or freelance, what then?!

Well hopefully if you are working in an office, as a junior especially, you are made to feel comfortable asking questions and making mistakes. For those not in that position or on their own, it is important to get out there and stay engaged with the community, attend meetups, attend conferences, find people you respect and ask for a coffee date.

If you show an interest in what others are doing, you’re bound to find someone to reciprocate that and take the time to check out what you are doing and helping where they can.

One thing that really stuck with me from this part of my conversation with Robby was when he said that he recommends new developers seek the opportunity to be mentors themselves sooner rather than later. It’s something I hadn’t thought about in that way before, but it makes a lot of sense. Have you heard of the “protégé effect”? It's a psychological phenomenon where teaching others helps a person retain the information better. If you are able to break down a complicated subject and teach someone else about it then that will just solidify your own understanding of the material better.

So get there and help others, you’ll be helping yourself in the process.

Contributing to open source

The one thing that Epicodus didn’t prepare me for was jumping into giant codebases that I had no familiarity with. Sure, I have over a hundred projects in my Github, but I built those from the ground up, and even the largest ones are minuscule compared to the ones I was exposed to in my first few days at Planet Argon.

I felt like a fish out of water and this was by far the biggest hurdle I had to overcome in my time here. One way that I think this transition could be made more fluid is to expose students by way of open source contribution.

Contributing to open source projects was something I heard countless times from various speakers in school, but how to start going about this was not something that was discussed. This was one of the things I made sure to ask Robby about and what I got from his advice on the topic is to just get in and start doing it. It’s okay to start small, your first contribution doesn’t have to, and probably won’t be, some giant app breaking bug.

A simple google search for open source projects will return plenty of results to get you started. I’ve been poking around in this README on Github that has some good projects that are sorted by language, find one that interests you and get started.

First off, clone the project and get it running on your local machine. Was there something missing or out of date in the documentation about that process? Add it to the README and submit a pull request for it and BOOM you’re a contributor to open source! Check out the issues tab for that project, maybe there is something you’ve seen come up before that you can help out with. Some projects even tag issues with things like "beginner-friendly" or "good first issue”.

So what are you waiting for? Get out there and start helping the community and you’ll not only become a better coder but it’s a great talking point on your resume.

So, Now What?

I’m not even sure if I answered the questions that got me started on this post, but I do feel more confident moving forward. I have built a solid foundation and I feel like if I pursue the things I’ve mentioned here, then I’ll continue on a trajectory that’ll make me an asset to any company that I end up at.

Planet Argon lays out the core values of a great developer as one who is proactive, curious, dependable, delightful, and versatile. I think that if nothing else, if you keep those five traits in mind as you continue your journey and strive to be the best developer you can be, then you can make it happen. I can’t wait to see where this next chapter takes me.

Continue Reading

Article  |  Development

What are Common Traits of Maintainable Software?

12 Sep 2019

What are Common Traits of Maintainable Software?

A few months ago, we launched the Maintainable Software Podcast. On Maintainable, host Robby Russell discusses with guests how to overcome issues that are often associated with technical debt and legacy code. We have since released over 20 episodes of Maintainable and have heard from over 20 wonderful guests with unique perspectives.

Continue Reading

Browse Articles…

Sign up for our newsletter

Receive a selection of our favorite articles from our blog and around the web straight to your inbox.

Have a project that needs help?

New Call-to-action