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.
