Lesson 1: Knowing When to Build vs Dig.

This is the first post in a multi-part series on things we explored while “Revamping the Ruby Central Conference Websites”.

• Lesson 1: Knowing When to Build vs Dig ⬅︎
• Lesson 2: Averting Monkey Patches with a Custom CMS
• Lesson 3: Braving Mad Science with Tailwind
• Lesson 4: Planning HTTP/Proxy Caching for the Spottiest Internet
• Lesson 5: Hosting Multiple Websites and Domains without Collision
• Lesson 6: Theming and Templating Against Future Tech Debt

Recently we were tasked with creating a website generator for the signature conferences hosted by Ruby Central, namely RailsConf and RubyConf. These conferences have played a major role in shaping and supporting the Ruby and Rails community. It therefore felt like a great privilege to build a tool to support both the organizers and attendees of these events.

In the past, the conference websites were one-off websites largely consisting of static html with well-crafted designs and unique branding inspired by the location. A primary goal was to showcase the creativity and design awareness and aesthetics of the Ruby community.

However, building, deploying, maintaining and archiving these custom websites meant costly and burdensome overhead. Moreover, starting from scratch twice a year was limiting the ability to implement dynamic features to improve the conference experience for everyone involved. The challenge was to create a new approach that would balance the need for creative expression with improving the functionality and longevity of the conference websites.

After weighing various options, including building a separate app and possibly using other popular front end javascript heavy frameworks, we decided to go with augmenting CFP app. As the familiar and trusted tool already being used to manage proposals for the website conference events, building onto CFP app had many advantages.

Firstly, CFP app is a battle tested open source Rails app, well-crafted and maintained by contributors from the community. Since all aspects of these event websites are going to be visible to Ruby and Rails developers, from the code to the actual web interface at conferences, it seems appropriate and desirable for it to be written in Ruby. We are also hoping that regular attendees can now easily contribute PRs to enhance their own conference experiences. Perhaps the new websites will also become a feature that other conference events using CFP app might try out thereby increasing the appeal and use of the codebase generally.

It was also just a really practical data driven decision. CFP app contains much of the dynamic data being used to populate the program and schedule pages for the event websites and could be easily augmented to include anything else that might be missing like sponsors. Basic modeling including users and authentication and admin interfaces are already in place and gave us a big head start so we could focus more on the core functionality we were concerned with. Similarly, the deployment and hosting of the website was already figured out and would also likely save on costs in the long run.

We would also be modeling the Majestic Monolith pattern increasingly embraced by the Rails community. Our experience has confirmed that for small teams and projects the longer you can keep related concerns self-contained in one repository the better. While there are always trade-offs, like the complexity of having to manage more resources within the same code and UI, the agility gains from keeping everything housed under one roof usually pays off.

Essentially, we decided to follow the wisdom that has guided the Ruby and Rails community to success in the first place. Why waste time reinventing the wheel when you can instead focus on the creative new features you are really tasked with. Stand on the shoulders of giants when possible and be grateful for the advantages they provide you. Hopefully you will find some new ways to push the edges further and give back to those that came before you and pay it forward to those to come.

In future posts in this series we will share some of the technical solutions we came up with while building a website generator for Ruby Central conferences. Ironically, in the next post we will look at how we built a custom CMS rather than integrating with existing third party tools. It turns out that sometimes it pays to build something from scratch…go figure.

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.