Implementing Rails 3.1...

Talks

Rod Cope

1 talk

Implementing Rails 3.1...

by Rod Cope

The video titled 'Implementing Rails 3.1, Backbone.js, CoffeeScript, jQuery, Sass, and CouchDB on EC2' features Rod Cope, CTO of Open Logic, at the Rocky Mountain Ruby 2011 event. Cope discusses the challenges and successes his team encountered while developing a new cloud-based product utilizing several contemporary technologies within a tight timeframe of just two months.

Key Points:

Introduction to Open Logic: Cope outlines his background in software development and introduces Open Logic, a company focusing on assisting enterprises with open source projects and policies, hosting vast collections of open source packages.
Project Overview: The project involved creating the Open Logic Cloud Swing, which aimed to help clients swiftly kickstart their cloud environments with customizable stacks.
Team Structure and Management: To tackle the project effectively, Cope's team divided their efforts between new development and maintaining existing products. They allowed team members to self-select their roles, leading to a balanced approach.
Adapting to New Technologies: The team utilized a range of new technologies, including Rails 3.1, CoffeeScript, CouchDB, and Backbone.js, which required them to conduct just-in-time learning to address challenges associated with these tools.
Agile Practices: The team refined their Agile methodology from an entirely story-based approach to a more feature-focused strategy, which suited their workflow better and allowed for structured progress updates.
DevOps Segmentation: Establishing a dedicated DevOps team helped streamline essential tasks like SSL certification and deployment automation, allowing developers to concentrate on feature development.
Technology Insights: Cope provides insights into specific tools, explaining the advantages of Rails 3.1's Asset Pipeline and page streaming, as well as the learning curves presented by CouchDB’s document-based data management.
Performance Evaluation: The video discusses several technologies' performance, detailing initial issues encountered and how they were ultimately resolved. Cope emphasizes the importance of making informed technology choices, particularly regarding database selection, weighing speed against stability.

Conclusions and Takeaways:

The experience illustrates the importance of adaptability, efficient team dynamics, and careful management of project timelines amid employing new technologies.
While the cloud services facilitated rapid deployment and testing, the challenges of consistent service delivery were notable.
The session concludes with an invitation for questions, specifically about technology integrations and experiences shared during the project, emphasizing a collaborative approach to learning in tech development.

Overall, Cope’s presentation serves as a valuable case study for developers looking to navigate the complexities of modern web application development using cloud technologies and open source stacks.

00:00:09.559 I crammed as many acronyms, words, and project names as I could in the title. I could have added some more, but I would have had to make the font smaller. So, we're going to talk about Rails 3.1 and everything we could cram into it.

00:00:15.599 All right, we're going to start with a quick little introduction on me and the open logic background—where we needed Rails and what kind of problems we solved. I'll explain how we went about it and then discuss each of those technologies, how they work, and their limitations.

00:00:27.679 We'll wrap up with some final thoughts and save some time for questions. Okay, I'm the CTO and founder of Open Logic. I've been in software a long time, working at large companies, small companies, and startups. Right now, I'm actually writing a book titled 'Cloud Computing in Action: Innovating with Open Source' for Manning.

00:00:44.039 If you want to get access to the early release, there's a code there for a 40% discount. A brief background about Open Logic: we primarily assist large companies with getting up to speed with open source policies, training, SLA support, and 24/7 production governance. We provide scanning solutions and serve as a one-stop shop for open source needs. We have a free site, ox.openlogic.com, with over 350,000 open source packages available for search and exploration. Additionally, we certify over 650 packages, making it easier for customers to download them and get support from us—all at no cost. We currently serve a couple hundred enterprise customers.

00:01:31.040 Now, let’s discuss why we needed all of these technologies. A couple of years ago, we decided to create a new product in the cloud, just like many others. We called it Open Logic Cloud Swing, and it was released in beta last month. We're having a beta 2 launch this coming Monday.

00:02:04.039 The idea is to get people up and running very quickly in a cloud of their choice with the stack they prefer, implemented just the way they want it. The components that are underlined represent the features we implemented in the first beta. I needed to build this quickly. By quickly, I mean I created a prototype late last year, and we aimed to rewrite it from the ground up, going from zero to production in just two months using all those technologies we had yet to use.

00:02:50.000 Some of the challenges during this process included a lot of excitement around the prototype I wrote. We won the Cloud Connect competition in March at the Cloud Connect conference, which brought us a lot of attention. We have many Fortune 500 customers we've worked with over the past six or seven years who were interested in our cloud offerings. As a result, marketing and sales were eager to sell the product even before we wrote our first line of production code!

00:03:45.000 This presented the usual problems associated with a quick prototype. Our existing SaaS products had been in production for four years, utilizing Rails 2.3.1, jQuery, Redis, and MySQL, but we hadn’t worked in the cloud yet using Amazon or Rackspace. Consequently, the technologies were quite new for us. We had to balance maintaining our existing products and satisfying our current customers who expected us to continue adding features. Moreover, we needed to juggle everything with a small team.

00:04:54.000 Our approach was to partition the team. We decided to allocate some time to separate the new development from maintaining the legacy products. We believed it was too challenging to manage everything in one large bucket of stories using an Agile, Scrum-based approach. We needed to isolate our efforts to ensure we made progress on both the new and existing projects.

00:05:31.000 To facilitate this, we split the team and decided to let the team members choose their paths. Initially, we were nervous about how this would work—whether management would have to dictate roles or if we could let the team self-select. Luckily, the latter worked perfectly, and team members self-selected as we had hoped. Some indicated they didn’t want to abandon the legacy products, while others were eager to dive into the cloud, even if they needed to learn as they went.

00:06:49.000 We jumped in with both feet and conducted just-in-time research on each technology we used. I typically scout ahead for the team to identify potential pitfalls and obstacles for the development effort. This approach helped circumvent many bumps along the way, preserving our collective time and effort.

00:07:43.000 We committed to exploring emerging technologies including Rails, CoffeeScript, CouchDB, the Asset Pipeline, and security practices, particularly encryption for data at rest and in transit.

00:08:00.000 We were fine-tuning our Agile processes as we learned from GitHub’s methods. We shifted from being entirely story-based to being more feature set-based. Instead of pushing a product numerous times each day, focusing on more cohesive progress every week helped create manageable chunks.

00:09:22.880 Another crucial element was segmenting devops tasks. A significant amount of work in products of this nature is not always directly visible to the end user. We established a small devops team to handle DNS setup, email dispatching, SSL certificates, and production deployment automation, enabling the rest of the team to concentrate on feature development.

00:10:39.640 Now, let's talk about the technologies we used. A quick poll: who here has already used Rails 3.1? What about Rails 3.2? How many have used CoffeeScript? CouchDB? And jQuery? It's clear that many are familiar with these technologies, which is great!

00:11:34.360 Rails 3.1 introduced some exciting new features, such as page streaming, which allows for loading JavaScript and CSS before fully rendering each page. The Asset Pipeline greatly simplifies pre-compiling Sass stylesheets and CoffeeScript into usable formats for pushing into content distribution networks like CloudFront.

00:12:50.000 However, I encountered some issues, particularly with Rack cache configuration and conditional GET support. The inclusion of Engines in Rails 3.1 also brought back valuable capabilities that had been removed earlier. Libraries like Sass, jQuery, and CoffeeScript have been bundled by default, which signaled great news since we were already committed to those technologies in Rails 3.0.

00:14:29.000 We opted for Backbone.js as well, which serves as a lightweight client-side MVC that can enhance complex UIs by harmonizing the front-end and back-end communication effectively.

00:15:36.560 CoffeeScript, too, offered a modern syntax to streamline JavaScript code, although some team members were skeptical about its usage. Not every developer embraced it immediately, opting instead to use JavaScript when straightforward functionality was needed.

00:16:43.600 While CouchDB served as an effective, document-based database, its unique features and operational methods required adjustments from traditional relational database models, which added complexity to data modeling and management tasks.

00:17:45.560 In terms of overall performance and reliability, we rated the various technologies using pros and cons lists and acknowledged some significant initial stumbling blocks and the learning curve that led to various triumphs.

00:19:02.600 Post-implementation, we utilized Devise for authentication, while still having to tinker with CouchDB integration aspects and submit patches to the community for enhancements. Lastly, we also explored tools like Factory Girl and Machinist for testing purposes.

00:20:10.480 To summarize, utilizing EC2 and Rackspace effectively allowed for rapid server provisioning for environment testing, yet some operations' irregularities persisted. Expecting hiccups in service consistency is essential.

00:21:35.680 In conclusion, our experience is often characterized by tight deadlines and immense pressure, compounded by numerous shifting technologies and big plans. Cloud services tremendously accelerated us towards our goals.

00:22:56.640 If there's any time left, I'm happy to take a few questions. If anyone is curious about topics such as Compass support for Rails 3.1 or MongoDB versus CouchDB, I am more than eager to help clarify.

00:30:07.000 The real challenge remains in making informed decisions regarding the choice of databases, weighing speed versus stability.

00:30:31.000 That said, thanks for your attention, and I'm thrilled to have shared my experiences with you.

Rocky Mountain Ruby 2011