From PowerPoints to Fancy Web App

And Everything In Between

This past summer, I interned at NETSCOUT Systems, Inc., a leading provider of application and network performance management products. My time there afforded me the perfect opportunity to dig deep into the magical powers of Ruby on Rails.

The problem.

Every Monday, managers from each of NETSCOUT’s software engineering locations hold a “scrum of scrums” meeting to go over their team’s progress that week. Prior to the meetings, they would each spend an hour or so pulling data from Rally, an online agile process management software that the company uses. They would then manually generate graphs and charts in PowerPoint slides, type and format talking points or notes for the slides, send these slides to the other managers through email, and download the other managers’ slides to their machines. A lot of repeated work every week — sounds like it can be automated (D.R.Y.)!

The learning.

When my boss asked me to create a Ruby on Rails web application, I was ecstatic! And clueless. I did know enough Ruby from a Codecademy course, and I did have experience designing and building websites. But Rails? Full-stack development? Forget it. I’ve always been intimidated by anything outside of my front-end “expertise,” if you can even call it that. But, the boss said so, so time to try.

The coding.

Newly empowered with Rails, I opened terminal and typed:

rails new rally-app-prototype

The solution.

What came out of the infinite StackOverflow searches and endless frustrations was 300+ commits to GitHub and a tool that saves managers five man-hours per week. Pats self on back.

A section of the homepage with some data blacked out

The Implementation.

To actually generate the reports, I had to do quite a bit of processing. First I queried Rally’s Web Services API and Lookback API to get data about the selected iteration and release. Then I ran calculations on the retrieved data, which involved integrating legacy code that the managers had been using and writing new analysis code. This data was all saved to a database (sqlite3 for development and pg for production) as strings (ew). Processing? Done.

“That’s not that hard,” you say.
That’s what I thought too, until two hours later when I was still trying to parse the strings I was retrieving from my database.

My “refresh_chart_variables” function was filled with line after line of code that parsed different data columns in the database. I must have tried at least 10 different ways of parsing the strings until I got one of the strings to finally parse correctly. The following is a small snippet of what I had to go through to parse just two strings…

# Parse wsi_score array
@wsi_score =‘”[]‘, ‘’).split(“,”).map(&:to_i)
# Parse user story names (need "-+-" to escape all valid characters)
@story_name = @report.story_name.split('-+-", "-+-')
@story_name[0] = @story_name[0].sub('["-+-', '')
@story_name[@story_name.length-1] = @story_name[
@story_name.length-1].reverse.sub(']"-+-', '').reverse
Sample report in Presentation Mode with randomly generated data

The Pitch.

Every product needs a pitch, so naturally, my boss had me create a slide to show the benefits of switching from PowerPoints to the new web app.

Infographic detailing the benefits of using the new reporting tool

The End (not really).

A few of the managers got a chance to test the tool out during their scrum of scrums meeting the following Monday. We actually discovered a bug in the original script (which was used to generate one of the main metrics), and I was able to pinpoint and patch the issue. That was pretty satisfying (but also an arduous process of combing through hundreds of lines of code).

The End (really).

I continued making small changes here and there, never really 100% content with the final product. I’m always thinking about improving little things or adding new features, but I guess I shouldn’t focus on the tiny details too much. (Bugs, on the other hand? I’ll fix those.) Ultimately, this app was a great learning experience and a stepping stone to even bigger projects in my future. I’ve learned a lot through this process, and I’ve listed some of The Lessons at the end of this write-up.

The Failures.

Not every feature is going to be put into production, whether due to bugs, inefficiencies, or lack of necessity. Many of the ideas I had couldn’t be put into the web app, so I thought I’d share some of them here:

  • Pretty PDF exports: Sometimes managers might need to save a PDF of their report to send to colleagues (they can’t send the actual report since the web app is encrypted) or to create a backup. I tried integrating a few Ruby gems, but the PDF generation process was so slow due to the Burndown iframe and Highcharts metrics.
  • Rich text editor: When managers are editing their talking points, having a rich text editor might make their reports more organized. However, the other intern at NETSCOUT suggested that it was too “fancy” of a feature for not a lot of use. I went with allowing HTML tags instead.
  • Login-independent burndown chart: In the current version of the reporting tool, managers have to be logged in to their Rally accounts (or input their credentials to the burndown chart iframe) since I used a workaround with Rally’s APIKey to display the chart. Using the correct LoginKey method would have costed the company an extra seat on the license — not worth.

The Lessons.

Lesson 1: Always start with clean code. If you’ve using a version control system before, you know that it’s a pain in the butt to go back and edit commits from a week ago. Imagine forgetting to hide credentials from the very first commit. Trying to fix that mistake after 300+ commits? Forget it. I ended up pushing the final application (which used Rails environment variables as placeholders instead of hard coding them into the files) to the company’s GitHub, but it would’ve been nice to have the commit history there as well. Lesson learned. | software engineer, web developer, event producer, hackathon organizer, videographer. swe @google. former swe intern @lyft, @google. | software engineer, web developer, event producer, hackathon organizer, videographer. swe @google. former swe intern @lyft, @google.