In October 2012, I left the comforts of Google in order to pursue a dream: to build a product from the ground up. Not to sell it, market it or even manage its development. Those are all roles I’d played in my 5 years at Google. This time, I wanted to build a product. So I left to learn how to code and enrolled in Dev Bootcamp, which turned out to be one of the best and most challenging experiences of my life (see my blog post). Soon after in August 2013, I was lucky enough to be offered a job at New Relic, where I started my career as a Junior Software Engineer working on a variety of small projects with some of the coolest people I’ve ever worked with.
About four months in, I was assigned a “small project”: to build the New Relic Community Forum. Of course, what we initially thought was going to be a 2 to 3-week project quickly evolved into a 5-month endeavor. I was the only developer assigned full-time to the forum, and as more and more stakeholders became involved, I had to quickly figure out how to juggle various tasks and troubleshoot problems, all while working solo on a product foreign to the rest of the company.
I’m proud to say that along with the launch of this forum — which fulfilled my dream of building a product — I’m also parting ways with the “Junior” in my title. It really is amazing what you can achieve in one year if you put your mind to it! Whether you’re just entering the role of a Junior Dev or are thinking about building your own forum, I hope you’ll find my experience below to be helpful in one capacity or another.
Getting started with Discourse
Discourse is an open-source forum platform built by Jeff Atwood and a small group of passionate, hard-working engineers distributed across the globe. We chose Discourse in part because of their mission to change the game for forum software, but also because it was easy to get started with out of the box.
Discourse is a Rails app with a Postgres database and an Ember front-end. Setting up your first Discourse instance is extremely easy. Because Discourse is open-source, all you have to do is pull down the repo, run the usual suspects when setting up a Rails app (i.e. bundle install, rake db:create, etc.) and dive into the code to start customizing. If you run into any issues along the way, there are plenty of resources and instructions on meta.discourse.org. The Discourse team has done a great job of building their own community, so you can get detailed answers to your questions, and fast — often times from Jeff and team.
After choosing Discourse, one of the first decisions we had to make when starting this project was where to host the forum. You’d think it’d be hosted on our own servers, but you’d be wrong. The #1 priority of our Site Engineering team is to keep New Relic RPM alive and running. Plus, hosting externally gives us a load of advantages, especially since we ultimately chose to host with Discourse itself.
Hosting with Discourse presented several advantages. To start, our app is hosted on the same servers as meta.discourse.org. If they go down, we go down, and I assure you that the Discourse team has no intention of Meta going down. So we feel good about uptime. We also feel good about security patches, since the Discourse team is able to deploy our app anytime they discover a security vulnerability.
To top it off, hosting with Discourse means that we have direct access to the incredible team that built the product. Since we wanted to do some pretty customized things, it was important for us to have a good relationship with the Discourse team so that we could work together to make their app more extensible (more on that below). Finally, as a Junior Dev, having access to Discourse’s talented engineers meant I could feel more confident pushing out my code.
Building the forum, one plugin at a time
Extensibility is the key to working with Discourse’s code. This was a difficult concept for me to grasp at first — I was used to working with New Relic repos where the process was to add your code directly to the app in the usual Rails directories, and that’s what I did at first. I quickly realized when trying to update my code with Discourse’s latest code that conflicts were going to be a major issue. There had to be a better way!
Discourse’s plugin directory provided the answer. The plugin directory allows you to separate your code from the core Rails app so that you can create new logic and extend existing logic without overwriting any of Discourse’s code. Discourse has included a couple plugins by default to demonstrate how useful this is. Check out the emoji plugin and the poll plugin to get a sense for how they work.
Authentication was our first major hurdle. The default authentication options for Discourse are the usual suspects like Google, Facebook and LinkedIn. But we needed to integrate our own authentication system so users of New Relic RPM or Insights could log into the forum using the same credentials. This was not something that was possible out of the box.
Thankfully, the Discourse team gave us their full support and eventually we found a way to integrate our authentication system extensibly. This also means that if you have a custom authentication system, you should be able to make it work with Discourse too (instructions here). Authentication was a great example of a project that was both beneficial to us and the greater Discourse community.
Other examples of plugins we implemented:
- I built a custom Zendesk plugin that makes API calls to Zendesk to either create a ticket or display a ticket’s status right from the topic show page if you are a forum moderator (screenshots here). This is a key component of our forum’s support structure.
- Of course, we are using New Relic to monitor our forum’s performance. Sam Saffron built a New Relic plugin a while back, and it works like a charm! In the coming weeks, we hope to contribute a second plugin that will allow developers using Discourse to tie their forum’s performance into New Relic Insights for even more visibility into how their forum is working.
- I created several background jobs via plugins that use the HipChat API to send new topic notifications to certain HipChat rooms. For example, if a new topic is created in the Java Agent category, we send a notification directly to the Java Agent room in HipChat so that the team working on that product knows to respond promptly to the new forum topic.
- While we’re not using it currently, I spent some time building a plugin that simulates the question and answer format you see on sites like StackOverflow. If you’re looking to integrate the concept of a “correct post” into your Discourse instance, check out my Solved Button plugin.
Throughout it all, I was thankful to have the expertise of New Relic software engineer David Celis to turn to, particularly for the authentication system integration. David’s made a number of amazing sites using Discourse, including a forum for goodbre.ws (currently under rewrite), a recommendation engine for beer written in Rails.
Customizing the UI
You’ll notice that our UI differs a bit from the default Discourse UI (see meta.discourse.org). We’ve integrated our own header bar, added some custom UI elements and adjusted the homepage view from the Latest view to the Categories view. Most of this is possible out of the box with Discourse. They’ve got a nifty admin panel that allows you to easily do things like choose the default homepage view, pick the colors for each of your categories and even copy/paste HTML for your custom header or a CSS stylesheet to override site-wide styles.
Here’s Discourse’s default UI:
A look at how our customizations turned out:
My experience working with Discourse was nothing but positive, and I encourage others who are looking to build a forum to give the platform a try. To wrap up, I leave you with my five key takeaways from this who experience:
- Communication is critical. We naively thought that the forum was going to be a small project, but it quickly grew in scale, as did the number of stakeholders involved. This meant that communication was absolutely critical. Which brings me to my next point…
- Sacrifice control for quality. I quickly realized that in order to deliver a high-quality product, I could not act as both the engineer and the product manager. We brought JP Gordon and Thea Lamkin on board to lead the project forward. They took over all of the stakeholder and community responsibilities, and I was left to focus on the code. This meant a much better product, happier stakeholders and a healthier community.
- The community is there for you. Typically when you’re a Junior Developer, you have all the Senior Engineers to turn to when you need help or have a question. In my case, I was one of the only engineers at New Relic using Ember, so I had to turn to folks outside the company for assistance. The Discourse Meta forum was a huge help—and it gave me a firsthand perspective of what forum users are looking for in terms of experience and functionality.
- Be a good citizen. If you’re consuming open-source, you should consider giving back to it as well. If you do, I think you’ll find that it’s highly addictive. While working on this project, I had the opportunity to contribute back to Discourse on several occasions, whether that meant answering topics on meta.discourse.org or contributing open-source code. These were my first open-source contributions, and won’t be my last.
- Live in the moment. It’s easy to get caught up in your day-to-day tasks, whether you’re an engineer, a product manager or a marketer. When you take a step back and realize what you’re actually working on in the grand scheme of things, that’s when you get those “wow” moments. I just helped build a product that will enable thousands of New Relic users and hundreds of New Relic employees to have conversations for the first time about how to make New Relic the hands-down, coolest tool for developers worldwide. I think “wow” is an appropriate way to describe that.
Now that the New Relic Community Forum is up and running, we hope you find it useful, and please do contribute if you have any suggestions!