 All right, so good morning, everybody. As we're in our introduction, my name is Patrick Peake. I'm the Chief Technology Officer for Browser Media. And with me today is Paul Berry, who is one of our senior engineers. So today, we're going to be talking a little bit about who we are, what we did with our product transition. And as by way of background, Browser Media, we are sort of an interactive agency based in Bethesda, Maryland. The sort of Cliff Notes version of my talk today is we build websites for clients. We built a commercial Java content management system to sort of assist this process. But over time, the market changes, different forces. So we're rebuilding it as an open source Rails project. So some of the questions I hope to answer for you by the end of this talk is, why bother building a content management system in the first place? More importantly, why rebuild it in Rails? What do you even use a content management system for? What purpose is there? And then sort of what problems does Rails as a platform solve for our CMS? So I want to start out with a story. So this is the story of your client. He wants a website that looks good, doesn't cost him a bundle of money. He's not up to date necessarily, so we asked for it in Fortran. But he'll settle for Rails, right? He's a businessman. He's not particularly technical. But he has a reasonably clear idea about how to make a buck on the web. So you sit down with him, you identify the requirements, you deploy the site, it looks great, it launches fine, everything is good with the world, right? So that's the end of the story, sure. Well, not really. As we know, launching a site is not the end of the story. What this here is actually a picture of Microsoft Word with every single toolbar turned on that you possibly can. So the moral of the story here is simplicity doesn't last, right? You know how, we all know how this goes. You build an application and you add features at the request of the client. And over time, slowly but surely, it gets more and more complex. Your simple site is no longer simple. You have to add a new UI for your client so that his editor can change the homepage. Then you have to add a permissions management system so that when the sales guy goes in and makes changes, the sales guy doesn't break like the marketing guy's pages. Then you need to train that, you need to train a new intern to use the UI to start and get a little more complicated. Then said intern goes in and deletes half the homepage. So you have to go in and restore from tape backups. You've lost 24 hours worth of work so the client says, hey, build me some sort of versioning system so that this doesn't happen again. So kind of at the end of the day, you've basically spent a lot of billable client hours to build what is essentially a custom content management system. And then at the end of the day, the client asks for documentation, right? And you don't have any because it's all custom. So this is kind of a problem that a lot of web shops face is you need these tools to allow you to build websites for your clients that look professional and get the job done, right? And so browser media, we're not, unlike a lot of the other companies, we're not 37 signals and we're not trying to do services to become a product company. We're trying to make the product, we're trying to make the services thing work, right? We're not in business of selling licenses necessarily. But we do need a content management system to allow our users to manage their own sites once we're done with them and we turn them over to them. So the real goal here is targeting it on the sort of non-technical users, right? Like the folks that aren't necessarily programmers themselves, but they need to be able to do stuff on a daily basis. So the real goal is the sort of separation of concerns, right? We have the sort of complete soup to nuts web design process. We've got information architects who are doing the wireframes and the site maps. You know, we have graphic designers are doing layouts and Photoshop comps. We have the developers who are doing the sort of HTML and CSS stuff. And finally we have programmers to do the sort of interactive widgets that go onto these sites. But at the end of the day, you kind of have to get this out and the client has to actually run the site themselves. So I'll kind of roll back to like 2003 when we were starting to face sort of an increased demand for content management systems. You know, our clients in a lot of cases that come to us with a need for very heavy content, very heavy content sites, right? Think of like 5,000 to 10,000 documents that they just have to keep organized in some way, shape, or form. And in a lot of cases, these are folks that are in the market for commercial CMS, right? They might go out and buy Red Dot or Ectron or some, you know, some $50,000 license product. And at the time when we started, there really wasn't a lot of open source choices, right? They were fairly unusable. They were pretty baffling and just overwhelming to end clients when you put it in front of them. So what we decided to do was build our own Java solution. And you know, this allowed us to design the CMS around the sort of processes that we have. And at the end of the day, you know, we was really all about, hey, we need to complete projects on time, on budget, get it to the client. And over time, the clients that we've deployed it for have been pretty happy, right? We have probably maybe 50, 60 clients that have been using it. You know, it's pretty easy to work with. And more importantly, us as an organization, we've kind of learned a lot about how content management works, how clients use it, what they ask for. And more importantly, how to support them when they have questions. So we built our own. Well, then you have other kinds of projects, right? Sometimes a client comes to you and they just want a Rails application, you know? And we tend to build these custom applications on Rails more lately, just mainly for the productivity benefits that a lot of people in this room are probably very familiar with. You know, Rails really helps with the quick starts. You've got a small project, you need to get it up and running fast and out the door. But inevitably over time, clients ask for these sort of content management-like features. And really honestly, rebuilding a CMS from scratch is a very expensive endeavor. You know, projects end up with their own set of bugs, their own training and support costs, and adding that polish that each client really wants is really almost too expensive to do for each client. They just, you know, they end up paying to refine the UI. Plus it's a little bit difficult to reuse code between projects because everything's just a little bit different. So the next thing I want to do is talk a little bit about the CMS marketplace. So overwhelming is a really good word for both this picture and for the marketplace. There is probably in the neighborhood of around 2,000 to 3,000 content management systems out there. And the market evolves pretty rapidly and it could be about the most fragmented ever. There's really no dominant player. Even a company like Microsoft has had like three different content management systems in the last five years. They don't even know what they're doing really there. One thing's for sure though is it certainly keeps consultants employed, just purely making sense for a client of what they pick, how they do it. There's a lot of money to be made there, just even sifting through it. And for a long time, commercial tools really dominated the space pretty well, even especially in the sort of mid-market range between like 25,000 to $50,000 for a license. But really they focused very much on the traditional content heavy sites. But over time, what's happened is the open source projects have really matured. Names like Drupal and Joomla and WordPress are probably familiar to a lot of folks in the audience here. But these particular systems weren't even on like the professional CMS watch radar screen in like circa 2006. So just a few years ago, these products weren't even marrying an invention for large-scale commercial products or large-scale websites. But they've sort of come along recently. And increasingly, clients that come to us are looking for more sort of web 2.0 or social sites that don't really fit well with the traditional sort of static CMS type of content. And that's something that Rails as a framework does better. So, Roz Media, we're a small company. We've got this proprietary commercial CMS. And so we're kind of getting it from both ends, right? We've got growing interest in our clients for open source solutions. But at the same time, we have this commercial CMS and we've got more established commercial players at the other side. And it's really hard to compete with free, obviously, especially when you're sort of at the low price point. So where does that leave us as a company? And I'll give you a hint in this picture, we are not the Venus Flytrap. So we have a couple of options, right? We could sort of turn ourselves into a traditional CMS vendor. We could, to all partner networks, focus on the license revenue. Or we could kind of just scrap it, go back to our roots as a peer service company and get another product. But the bottom line is we really needed to respond to the marketplace and what it was telling us. So if you can't beat them, join them, right? We decided that it's probably useful to move to an open source model. And that solves a lot of problems for us. It gives us the ability to do sort of our traditional sort of soup to nuts web design. And it also gives us the opportunity, when we're doing Rails custom development, where we need CMS injected. And we're still gonna get clients that are gonna come to us and say, I need a CMS, right? Just put one out there, you need to implement it for me. And the way a lot of web shops do this is they kind of follow one of two strategies. First one is they pick a specific CMS and sort of focus in on it and that's what they do. And you might say, you might find Drupal shops, for example, that that's all they do. The other way they do it is they come at it from sort of a product agnostic approach, where they'll sort of work with a client to pick the best CMS for them. And really what that means is they know three CMSs and they pick the one most likely to get the sale. So obviously if we're gonna go into the open source realm, it's worth looking at what the other products in that category are. So the first one I'll talk about is Drupal. So who here is not familiar with Drupal? Has not heard of Drupal? Okay, so pretty much most people are familiar with this. So in any case, Drupal is a very popular PHP-based content management system with I think at last count like 11.5 million modules. So why not just use Drupal as a shop? Well, the first one, the obvious answer is it's not Rails. I think most people here in the audience are here because we like Rails, we think it's productive and it gets the job done. So if you wanna be a Rails shop saying, okay, well we're just gonna do websites and Drupal is probably not a productive answer. But it is worth looking at why Drupal is popular as a project, right? And the best analogy I can come up with is really, Drupal is kind of like Rails for PHP. It's this combination of an actual web framework at one sense that gives structure to how developers write their code, but it also layers on top of it sort of the CMS or UI framework that you get. And it's pretty powerful to developers to do stuff with, right? It's easy to develop a module, get a quick win, see it up and running on your website in sort of that same way that Rails developers get excited about deploying their code really quickly. Add in the fact that PHP is really approachable as a language for new developers and it runs on like every single six dollar a month web host out there and you have the making of a pretty popular project that is Drupal. So some other issues with Drupal and again I don't wanna dump on other open source projects because that's not what we're here and what we're about, but it does have a little bit of complexity and a UI issue with regard, especially with regard to non-technical clients. Last year Drupal commissioned some usability studies with the University of Baltimore in Maryland and they basically sat really like web experts, people who are web masters down in front of Drupal having never used it before and said, okay, here's some basic tasks, just try to do these. And a lot of cases they sort of failed fairly miserably. And one thing that came out of that was sort of a sample is it just lacks a WYSIWYG as sort of part of its core thing that's sort of what you see is what you get editor. And for non-technical users that are used to sitting down in Microsoft Word and that's sort of how they think about content, a WYSIWYG is essential to get content into their site. And it's completely understandable how this kind of complexity happens. Open source in general is code and programs, by programmers, for programmers. It's very hard for members of other disciplines, especially folks like UI experts and designers to contribute to an open source product. But to Drupal's credit it seems like they're really focusing on usability for the next release for Drupal 7. In particular, Acquia, which is the support, the Drupal support company run by the founder of Drupal is actually paying for and hiring usability designers to redesign Drupal 7 and then paying the programmers to implement it. So it certainly is possible to get those factors into open source software, but generally it takes a little bit of commercial pay for because again, designers just can't sit down and contribute code. So the next question is well, what about the Rails content management systems? And there are some out there, not nearly as many as PHP. It's hard to find a week that goes by that there's not a new PHP content management system released, but probably the most popular one within the Rails community is Radiant. So there's really nothing wrong with Radiant, right? It's just kind of a different product for a different target audience than what we're looking for. It's pretty simple. It's really suitable for programmers that wanna run their own sites or for small teams that wanna manage a site. So it's fine, no problems there. The really the issue is it kind of just lacks a lot of the features that we get asked for a lot of times for our clients. We very frequently see these like 20 page RFPs for content management system selections that have little tiny check boxes that say, do you have this feature? Do you have this feature? And really just kind of checking no a lot with a system like Radiant just doesn't have the bulk of modules that something like Drupal has. So what kind of features am I talking about? Those are things like permissions so that you can have like members only areas of your front page so the guests can't get into them. Things like content versioning and then just editors that help support sort of a large contributing contribution team. So the next kind of thing I wanna talk about is some of the design aspects of what we're doing with the product and why we think these are important. And the first one is excellent software is really more than just a pile of features, right? As much as I talk about those check box things you can't just add up all those check boxes and say, okay, this is the right tool. One of the reasons we built our own content management system twice now is that we want to have some control over the user experience that our users get. And so we try to bake these design principles right into the content management system. One of the things that I like one of the ideas that I like is something that Jeff Atwood from Stack Overflow Center to paraphrase him is, a feature doesn't exist until a user finds it, right? Like you can write the greatest feature in the world but if your user can't find it it's like it doesn't even exist, right? So you have to make sure that you're really thinking about that. For content management, one of those things that does really factor into that is when you're editing content the more user has to guess what that content is going to look like when it goes live the harder it is and the longer it's gonna take and the worst the end result is gonna be. And that's more than just sort of a WYSIWYG editor. That's really all about matching the mental model of how a user thinks about a site not necessarily understanding things like databases and stuff like that and matching it to how the CMS interface actually works. And the goal there is to really force not force your users to think like a computer. So this is where I sort of plead for the plight of your poor user, right? You know, users want control over the system they don't necessarily want the complexity. And the best way I think to think about this is programmers are a different breed than sort of the average user, right? A programmer they sit down in front of a program and they think to themselves, I want to understand how this works and how things are going. Users on the other hand, they don't want to understand how it works. They just want it to work and they want it to not make them feel stupid. They want control, but they don't want to be overwhelmed. And I give a number of examples, but the biggest one that's sort of most obvious for web management, web content management systems, users don't understand HTML and don't force them to do that because it will fail. They expect a WYSIWYG even if they can't spell it. You know, they understand Excel and the concept of a single table but as soon as you need to introduce a database and there's two tables and there's a join there, you've lost them. You know, so really it's all about having user be able to accomplish their tasks and get their job done. Otherwise the system's kind of a failure. So one of the things that some usability folks like Alan Cooper talks a lot about is the idea of ejector seats. And that's kind of what this highlights here. You know, some functions in your program are really necessary, but they're also kind of dangerous. For example, if you're an F-16 pilot, you really need an ejector seat because sometimes stuff just goes really wrong and you need to use it. However, when you're changing radio frequencies to talk to a different pilot, you don't want to accidentally trigger the ejector seat when you're doing that, right? So the ejector seat's in a little locked thing over here that you can't accidentally get to. You know, so you don't want to be able to casually trigger your very powerful features. And that's kind of what this really, really terribly designed keyboard kind of illustrates. You know, don't put your power button right next to the probably the most hit key on your keyboard, right? Because users are gonna turn their computer off all the time. You know, so the bottom line is don't design interfaces that let your users hang themselves. And the other thing to understand too about humans and the relationship with computers is it's not based on logic, right? These overly complex UIs that lead to bad user experiences really kind of comes down to users will treat software like it's a person. However illogical that sounds. You know, they trust it until it gives them a reason not to. You know, when it gives them very correct but highly technical and not helpful answers they think it's rude and they're gonna get mad at it and then they're gonna stop using your software. So the next thing I want to kind of do is run through what the stack of a CMS is, you know, kind of some of the architectures that come along with that. So really what is a CMS except it's the UI you probably needed to build for your client anyway. You know, you have frameworks like Rails and they're very opinionated about some things like ORM, MVC, you know, web services but they don't really provide any opinions on the user interface at all. And that's totally cool when you're using Rails to build your own site for yourself or for one specific client. But when you're in the business of client web design you end up doing the same thing over and over and over again, right? If I built 10 Rails sites last year I probably built 10 CRUD interfaces to edit stories or articles and probably 10 more user admin interfaces. So the goal of a content management system is to provide sort of a standardized UI for all those common cases. And creating reusable interfaces is pretty hard but if you've got a common architecture it's very easy for Paul to build an events module and because it kind of shares some of the same UI architecture it's more likely that I can just plug it into my project. So we're gonna talk first about kind of the two architectures that govern content management systems in general and this is kind of the market, the CMS marketplace is its own little beast and it kind of classifies these things this way. So the first one is static websites, right? Traditionally, think of like a new site, right? In a lot of cases the goal of a new site is to produce quick content very quickly, keep it organized, but once it's sort of out there in the wild it's essentially static, right? It's not changing over time. And in the CMS world they call this the baking model. The idea is that it takes a while to bake the content but once it's out there it's completely good to go. You know, the idea is that you have an interface that takes the content dynamically, stores it in a database and then it pushes like static HTML files out so that some other server can handle them. That might be Apache. And why do they do this, right? Well, the most obvious reason is performance. You know, nothing scales faster than static HTML. And it's almost more important nowadays when you've got these services like Amazon S3 and other cloud computing where you can buy like infinite scaling for static resources. So that architecture is really important. The trouble is there's a downside to it and that's doing dynamic or social websites are really hard with a content management system like this. So the second architecture is what they call frying, right? And this is where you have content that's stored in a database, a request comes in, the CMS sort of dynamically assembles the HTML and sends it off to the client and it's personalized right for them, right? And this should sound pretty familiar because this is just Rails, right? This is how Rails and every other web framework tends to work. And the good part of this is you have sort of complete unlimited freedom to do whatever custom stuff you want, right? The bad side is if you want your site to scale you probably need some form of caching to go along with it. And caching is really a pretty complex problem to get right. You know, and ideally you want a content management system that can support both models depending on what the site's construction is, right? If I have a very static site it'd be nice to be able to use the same interface to administer that so I'm not learning two different systems. So some of the features that like, you know, what makes a content management system different than just, you know, sort of a database-backed website built on top of Rails? Well, you know, one thing they do share is the idea that really it's all about organizing the content, right? At all life cycles, you know, even when it's on its way out to the dump. Really, and there's two pieces to that. One is there's the UI that the user see to actually add, edit and delete their content and then there's this sort of, there's also typically a programmatic API that's kind of layered over that to, you know, to let programmers interact with the repository. And so the way we handle that in browser CMS is we've got a layer of this active record and there's kind of a layer over that which provides the sort of essential services and then there's, you know, a UI. And that's actually pretty common for some other web frameworks like Django has sort of a built-in, you know, crud interface so you don't have to necessarily build your own. So then the next thing is sort of these services that you wrap around the content repository, right? And that includes a lot of things, especially search, you know, the ability to find content that you wanna edit as well as publishing. And that publishing gets really much more important when you deal with larger websites and publishing teams. You know, you need to be able to review the content before it's live. Content needs to kind of just hang out in unfinished state and then go live when someone says it's ready to go. So if you can read the top up there, design is coloring in my wireframes. This is kind of a joke because my designers would kill me for this because this is absolutely not an understatement of what design is, right? But for the idea of how it works with content management systems it's actually fairly appropriate, right? We have very smart designers that wanna do high impact designs and they wanna put their design out there and let users work within that. But at the same time, you know, you don't want them to be able to easily destroy their webpage, right? And giving them access to one giant HTML file with lots of intricate HTML is a good way to do that. So the approach we take is sort of like a coloring book or wireframe model where there's certain areas of the template that are off limits to be edited and others that they can. And the idea really here is to separate the content itself from the presentation. So this is sorry, this is the obligatory LOL cap photo. But I should kind of talk about permissions, you know, really what it comes down to it. Permissions are essential to any web application as most people are probably familiar with. As soon as you build a feature the next feature that client asked for is, hey, can you prevent user X in my organization from actually using that feature? So you need to build a permissions model. And with a content management you have kind of two classifications of users. You've got your front end public users and these include like your members or your clients, stuff like that. And then the general public, you need to be able to say, okay, members can do these things, the public can do these things, as well as the staff. And this is the very traditional idea of editors and you might have publishers and you might have administrators. And the CMS needs a way in the UI to allow clients to configure all those things. And then that adds an idea of workflow or task management which is, you know, if I'm editing a page, you know, Paul maybe needs to review it. So I need to like pass it over him and then that sort of workflow is there. In a lot of cases, workflow is really overbought in the content management arena, but you can keep it pretty simple and get the job done. So users, you know, sometimes users just need their old school content, right? And this is where we get into the idea of versioning where, you know, you need to see the history of, what is the history of this content all the way back to its inception, right? What did this look like two updates ago? You know, who changed what and when and then, oh, I need to revert this page, you know, to this version here because something was made, even if the content on that page is kind of shared across three separate pages. And then finally we get to like these, the very advanced features that come along with a CMS, right? And this is the stuff that, the really highly polished stuff that you don't necessarily get a chance to do for every client. And these include things like dynamic form builders that let clients that, again, don't know HTML build their own forms that interact with databases and email, sending emails. My personal favorite is the idea of in-context editing where to find content on your site to edit, you can kind of browse around, find the content exactly where it is, click on it, make the edit all without kind of leaving that paradigm, right? And that's a big step over, big step up over having to sort of an admin interface that, you know, is sort of abstracted from the actual content itself. And then you have the very standard things like URL management, you know, being able to change the URL of a particular page to exactly what you want. And that's important for a couple of reasons. SEO is one, obviously, but sometimes just having a human readable URL that your marketing guy can send out turns out to be pretty important. And then you have things like locking, which is, you know, both optimistic locking, which is sort of how SVN or other CMS or other source control systems work where, you know, changes are merged. So if two people are working on a page, it kind of handles the updates of one person commits before the other. Or the other alternative model is the sort of check-in or check-out process, which is familiar to anybody that's probably used like Microsoft Word on a shared drive. So that's it for me. I'm gonna turn it over to Paul now who's going to talk about why we decided to go with Rails over Java. Okay. Yeah, so now that Patrick started giving you the background as to why we wanted to build our own CMS and what features we'd like to support in our own CMS, I'm gonna cover what it is about, what there is in the Rails framework that we can take advantage of in building this. So first off is compared to Java, what one thing that Ruby has is a very clear, expressive, and powerful syntax. And this is just an example of some random bits of Ruby code that you probably can decipher. And there's lots of things going on in here. You see that some of the things like everything is an object, you have blocks, you have literal syntax for hashes and for arrays and regular expressions. And for anyone who's programmed in Java and then programmed in Ruby, you sort of appreciate all these little things as they add up. You can't say, oh, I can put a method on an integer and that makes my whole application so much better, but if you have thousands of those little things, they really just end up adding up. The other thing is that when you look at not having these things in the Java world, you end up with a lot of problems that you have to solve. And these are some of the things that if you, for anyone who is a Java developer and has done any of this stuff, you recognize some of these things and I won't really go into all the details of what they all are, but what I can say is after you've built things in Ruby and then you look back at some of the stuff that you've done in Java, you realize we didn't do any of this in Ruby on Rails. There aren't equivalents of these things, but they were really necessary when you were doing it in Java. And I think the reason you look at is what I just showed in the previous slide is that Ruby just as a language itself sort of solves a lot of these problems for you. And the list is bigger than this, just these few if you really take the time to go through it. So just to categorize what we're doing with browser CMS a little bit to set up my next point of how Rails can help you out, I just wanna show the layers of things that you have when you're talking about building a end product of a web application. You start at the lowest layer with the language which is obviously like Java or Ruby or PHP. And then above that you have libraries which all languages have for interfacing with databases and things like that. And then you usually have some sort of framework which Rails fills that role. And there are lots of frameworks in the Java world that also fill that role. And then above that you have a platform. Now you might not have that. If you're just building a website, you're not really gonna have a platform. You're just gonna build your product on Rails. But sometimes you do want a platform which is giving you all these sort of higher level features that Patrick just described. Some things that I would consider to be a platform would be something like Drupal, something like Plone if you're familiar with that. A lot of content management systems really are a platform. But most of them are built on frameworks that you will use as a developer when you're working on that platform. So what framework that's built on is important. And so one of the problems we have in the Java world when we talk about frameworks and then you talk about building platforms on frameworks is there are a lot of frameworks in Java. The biggest reason why this is a disadvantage for what we're doing for trying to build a platform is you have two choices of how you can deal with this problem in the Java world. And one choice is you can pick one or a few of them to put together and say this is gonna be our framework for our app and this is what we're gonna use. That's not the greatest choice because that really limits the size of the community that you're able to attract. If you pick web work, you're gonna have somebody in the Java world who's gonna be like, I wanna build it on tapestry or I wanna use JSF instead and hibernate versus iBash. And the list just goes on and on. There's an infinite set of possibilities. So really, a lot of people will say, oh, we built our website in Java but what does that really mean? You may or may not be familiar with the underlying framework that you're talking about. Whereas when someone says we built a website in Rails, if you're a Ruby programmer, you get it. It's Rails and there really is a lot of adoption of Rails as a framework within our community. The other idea that you could do is say, well, what we'll do is we'll just support all of them or the ones that are important and we'll have it be configurable to be like, oh yeah, you can go ahead and use tapestry or Wicked or Stripes or Web Work or whatever underneath it. And what that leads to is something like this. And for Java developers who might be familiar with this, this comes from the AppFuse project, which is a project that sort of tries to give you a baseline to get started with an app. Pretty much, it's pretty similar to what Rails would do and gives you all these options for picking and choosing all the card of what frameworks you wanna put together. And what you see on the right is actually the command that you run to fire that up, to start your projects. What that is, is that. So you can see there's a lot of complexity that leads to, and that's just the hello world of getting started. If we tried to do that with a whole complex content management system, it would just be so much overhead of trying to support all these frameworks. So having a consensus in the community around frameworks is a big deal when you're trying to build a platform. Won't this same thing happen to Ruby? Like just over time we'll get more of these frameworks and then we'll have a whole bunch of them to choose from. And I think the answer is no for two reasons. One is there just is more collaboration between these frameworks. And I think this is obvious most recently with the idea of the Rails merger to the biggest web frameworks within the community. Just decided we're gonna bring those together. And as you heard DHH and you heard to talk about, the reason why is you realize that we're doing a lot of the things the same way. And that's part of the, what you get out of Ruby is that there really isn't, there aren't a lot of different ways to solve the problem. There are some, there are some different architectures that you could use, but when you go back to Java, again you're trying to solve problems that the language sort of puts in front of you, so that's why you have this multitude. So I just don't think we'll see this need to have to branch out into more and more web frameworks. Bottom line is in the Ruby community you can build a web app on Rails and your developers in the community are gonna be familiar with that and want to use Rails and be familiar with the conventions that are in Rails. And so one of those conventions obviously is convention over configuration. This was talked a lot about when Rails was first hitting the scene, you don't hear people talk about it too much anymore, but it's still there and it's still a big part of what we do almost inherently as Rails developers on a daily basis. So this is something we can leverage when building the content management system as we build things that use the concept of convention over configuration, it'll be familiar to you as a Rails developer. You're like, this makes sense to me. This is how I figured this would have worked. You can try this in Java, but since it's not as much of a convention obviously, you're going to have, your developers will be less familiar with that. So convention over configuration is a feature that we can take advantage of. Another one is static code generation. You could do in any programming language and it's just the concept of having some program or script or something that you can run that will generate boilerplate code for you. This is very useful in certain situations. We use it in Rails, we use it to start up the project. We use it to build components within the project. And here's just an example of a couple generate commands that I haven't even explained what these generators do, but you get probably as a Rails developer sort of guess what they'll do and I'll explain it a little more as we go on. But the idea is that this concept of using static code generation in this way, you are familiar with. Again, we can leverage that in building browser CMS. We give you these generators and you will know what to do with them. Closely related to that is the concept of dynamic code generation, which normally goes under the name of metaprogramming. But I like to think of it as dynamic code generation because that's really what you're doing. It's very similar to static code generation. The only difference is you're generating it at runtime. So here we are again, a little snippet of code. I haven't really explained what it does, but because you're Rails developers, you can sort of guess in general what's going on here. Static code generation you can do in almost any language, including Java, although it's just not done to the degree that it is in Rails as conventionally, but dynamic code generation is harder in languages like that. Ruby gives you better tools for doing dynamic code generation, so it makes it easier to do and makes it commonly used and familiar. So there's another feature that we're able to leverage. Just to sort of cover some of the things that I want to rehearse, you have a clear expressive and powerful syntax. You have a framework consensus within the community. You have convention over configuration as a feature that we can leverage that you're familiar with, as well as static code generation and dynamic code generation. And so now I'd like to just give you a quick demo of sort of how you would use, how these features get used in browser CMS so you can see how we're able to use Rails to make that happen. So we're gonna get started with our project and our project is actually gonna be a website that you're all probably pretty familiar with. And this is pretty standard, right? We're just gonna create a Rails app. All we're gonna tell it is you need the browser CMS gem. You're gonna add the routes in there. Then you're gonna run a generator, which brings in some static assets and things like that. Run your migrations and start your server and you're ready to go. So with browser CMS, again, we're trying to leverage the underlying framework here so this is as familiar as possible. There's no extra weird fanciness. It's things you're already used to to get started. So once you get started, you get a website like this. So this is a website that you've all seen and this is what the public users see when they go to this website. What you wanna be able to do with the content management system though is edit the content within this application. So in order to do that, we'll log in to browser CMS. And now what we see once you log in is that same homepage of our website, but it's wrapped with the tools that browser CMS gives you. At the top of the page, you have a toolbar. I know it's hard to read all of the little bits, but I'll just cover some of it. And what it is basically telling you is that you're looking at a page and this page is using the main template. A template is just a Rails layout. We have done very little layering on top of that. The only thing that we have added is that what you see in the main body of the page is where you would normally just have a yield statement in a Rails layout, we have just what we call a container, which is when the page is being viewed to the end user is nothing but a yield statement. It just yields whatever goes in that container. But when we're editing the page, it gives us a chance to sort of wrap that area up and let the user know that the designer of this template has told you this is a place where you can put stuff. So what we have on this page is just, if we scroll down a little, a couple of HTML blocks. And what we do is we put content blocks in the containers in browser CMS. That's the terminology we use for it. An HTML block is just a type of content block. A content block is really just a model that knows how to render itself when it's put onto a page. And there are ways to edit the data that goes in those models. So a HTML block is sort of the simplest block. All it really has is a name and a WYSIWYG editor. And so if you go to edit one of those blocks, you'd see something like this, which just says, hey, you're editing the homepage intro and here's a WYSIWYG editor to edit that. And that's all I really need to build the homepage of the AccessConf website. But then when you go to look at some of the other pages, maybe like the speakers page, for example, you start to see like patterns in the content. And if we just gave you HTML blocks in a WYSIWYG editor, we're really not doing a whole lot for you. You could do that with other tools and it would be pretty permanent. But what we want to be able to do is have structured content so that users can just say, I just want to add a speaker. They don't really want to even, even though the WYSIWYG is a high level thing, they don't want to go in and say, I want to underline the title and I'm going to put the image on the right. They don't want to even deal with all of that. They just want to say, I want to add a speaker. And so that's where the concept of these structured content blocks come in. And you can create your own, just like an HTML block comes with browser CMS. We give you tools to build your own. And so here's where static code generation comes in. We have a content block generator. The content block that we're creating is going to be called a speaker. It's going to have a name field that's a string and it has two more fields, an image and a bio. And we just added a little bit on top of the way the generators work to give the CMS more information about what you want the admin interface to look like once it gets built. So the data type of an attachment in HTML look odd in this generator, but all that's doing is letting the generator know when I generate the form for you for this thing, you want this to be an attachment, meaning like a file upload and bio, you want to have a WYSIWYG editor for it. And so once you run that, you get the part of the system that will let you list those. And so we're looking at our content library, which is where you can look at all the content blocks in the system. And here's a list of them. If we select one of them, we get that form and it lets us change the name and image in the bio for each speaker. So once we have that set up, we can just drop those speaker blocks right onto the page. So the headers we're just doing with HTML blocks in this example, and then we're just dropping speakers in in the exact word we want them in on this page. And that's how you could build a page like that. So look at all the code I'm not writing. So that we were able to leverage these generators to give you that whole nice looking form and interface. And there are a lot of features wrapped around that like versioning and all kinds of stuff that you get for free. Obviously you don't have to use the generators, but it really is a good way to get you started and you can get their content set up in the system with very little effort. So the last page I want to show you an example of is the schedule page. Now we could take the same approach that we took on the last page with this and say, I'll make a talk content block for each date, time, and I'll put them on the page where they go. But that gets really tedious really quickly. In this case, not only do you want to just be able to enter in a talk and say, hey, it's at this time and here's the title of it, you also want to be able to say, I just want to add it and not even have to go update the pages. And when we want to do that, we have one more special content block that we call a portlet, which is just a content block that instead of really being there for data is really there just so you can render other data on the screen. And so we have generators for that as well. And you just tell it, you want a portlet, the schedule portlet. It's going to spit out code like this, which is just basically a standard model, although we just put it in the portlets directory. And it just has one method that we call in context, which this ends up being what gets passed as the locals into the partial. Because you can think of a portlet, it's sort of like a partial and actually it's really more like a mer part is exactly almost what it is because you have this little bit of code that runs to sort of set up the data and then it's just going to render some template. Obviously the content, what's in the content method you had to write, that doesn't get generated. So sort of like insert your code here kind of a thing. And then using convention over configuration, we just say, okay, we're going to render this template, which obviously you could override, but that's just where they go. And then you have some template like this, which is just ERB and there's nothing really extra fancy in here. And so the idea is again, this is stuff you're already familiar with, you're able to build out a page that does what you want. And so when you drop this portlet on a page, what you get is our schedule and you can see now it's just one big block. So this kind of content, if you were to go into the system and just add more talks or change the times or whatever, it just automatically gets updated. So that's pretty much it for browser CMS and how we're able to sort of leverage some of the features in Rails to build that. Next up for us with browser CMS we're actually getting to the point where we can actually release the code. Like we did say it's going to be open source, we're going to have it up on GitHub. We're still finishing some stuff up, we're not ready to do that yet. We'd hope to have it ready for this weekend, but we're almost there. So it should be soon, probably March. And everyone here will be able to check out browser CMS, use it on your own projects, contribute back to the community. Right now you can go to browsercms.org and we just have a simple link to a Google group so you can sign up and just get information about browser CMS if you're interested and obviously you'll see more info there as the code is released to the public. So that's it. Do we have any questions? What's it gonna be on GitHub? We don't have a date for sure yet, but as soon as we're ready to release it to the public it will be, we're still working out like what the licensing will be and finishing some things up, but it's pretty close. It's very functional right now. So soon is the best answer I can give for now. In there, question? Will it include tests? Yes, lots of tests. And they all pass, which is even better. And you'll get to see them. Any other questions? Java related, Rails related, browser CMS? Okay, thanks a lot.