and welcome to everybody before I go into my talk about the patterns of base camps application architecture a little announcement about an hour and 20 minutes ago we released release candidate one as well as branched for rails for Oh stable so we're really close to having four Oh done and ship and it would be awesome if everybody's here who's going to work on rails code during the next four days could try it out because that's the best way for us to figure out what's still missing or bugs or whatever else have you and we sort of have almost this pattern of putting out betas and release candidates and then we ship the final version and fifty tickets come in with obvious defaults or things that are broken so it'd be great if 400 could come out and for the first week or two at least we wouldn't have to ship an update so if you guys can help us do that that would be amazing um okay so the story of rails is in many ways intertwined with the story of Basecamp this is a screenshot of the very first version of Basecamp that we released in 2004 I started working on Basecamp in 2003 before I had any aspirations of working on rails before I had any ideas that what I was going to work on was going to turn into a framework so the whole approach with base caman and with the the creation of rails was that I was interested in an application I was interested in building something the fact that I had to build my own tools to get there was sort of secondary it certainly wasn't the the primary objective and that led to in some ways unique style of working I think that that we've really embraced as a as a community and in rails core that frameworks are not inventions they're extractions we don't sit down and try to come up with features that that we could need or would we would want we build applications things that actually have to run in the real world things that actually have to to matter to somebody not example and from there we see Oh what are the pieces that we keep using over and over again so for me that's why Basecamp is so important because just about for sure every single good feature I've put into rails have come from base camp or base camp derivative a few bad features came exactly when I thought that I could invent good frameworks it it never really worked the question we're asking ourselves is not what would someone somewhere I might want to do with rails because that sort of speculative development style we've had to work I had to work with a lot of tools that were built like that teams assembled just to make tools with influences of listening to people in various places but with the core motive to just build tools and that was what I was running away from in many ways as it came to rails I didn't want something built by somebody whose sole occupation wishes to build tools for me because those tools tended never really to match the expectations I have for real-world development so what we do instead is say I'm not gonna care about anybody else right now I'm just going to focus on building rails as the perfect framework for building Basecamp that's my mental model the side effect is that Basecamp of course is not that special most of the things that it does a same kind of things you want to do in a lot of different applications but because we attack the problems from this sort of concrete approach we get to extract something that just feels right something that feels like somebody's actually used it in anger and I mean I've sworn and cursed my fair amount at rails at certain times so I've certainly used it in anger and I've certainly changed the in anger and I find that that's really where a lot of the magic happens when I'm so annoyed that something takes four lines of code when it really just should take one that's when good stuff happens and it happens in in a sort of different way than then that example code driven development style that you often run into when people do this for a full-time living because it's very easy to make pretty examples we have lots of this in rails were for example the the standard scaffold for a long time it looked like it it was not very dry I had a lot of duplication right and people would often come to rails and they would say that's the first thing well this code your generators it's it's just for Bose I could optimize it in all these ways and a few people have tried with various gems and and what you find is yes you can make example code really pretty by making a certain set of choices those same set of choices are usually the ones that makes it horrible for actual real-world development okay so 2003 2013 I've been working on Ruby on Rails and Basecamp for 10 years now that's about a third of my life so I don't think it's any stretch to say this is this is my life's work at least up until this point and it's funny because in some ways it feels it feels so familiar when I look at rails code today it looks and feels and smells very much like the rails code I wrote 10 years ago of course it changed in a myriad of different ways and it's much much better now but the kernels and the principles are very much still the same and that's interesting to reflect on when you compare to the things that changed in 2003 this was the state of the art phone seriously flip phones was was really hot back then and it's just it's so funny because that seems so far away right they seem like flip phones I mean that's another era which it is in many ways because many parts of technology move really fast so it's it's just it's interesting that we're here today and we're still we're working with we're discussing and debating and improving a framework that's from the time of flip phones so that's sort of like the form factor of I've actually a lot of people interfacing with our applications today go through phones if we look at other parts of Technology just sort of the hardware we were on I looked up these prices yesterday I was like half a half a gigabyte cost 50 bucks now you can get 16 times as much RAM for almost half the price that's more than an order of magnitude change which is just it's one of those things is also interesting in terms of what does that change with how we approach things oftentimes people will almost lock their concept of what hardware cost and how it runs to the time they entered programming if something was scarce and expensive at the time they got into programming they'll think that that's how it's going to be forever which of course if this shows when you can get eight gigabytes for $29 how much RAM you use probably doesn't matter as much as a lot of other things which is which is funny to me because that's always been sort of Matt's back in in 1993 20 years ago 20 years ago math started working on Ruby he had to care for I didn't I should actually looked up what what Ram cost back in 93 but I'm sure it was expensive yet he sort of had the foresight to think well I don't know if he had the foresight but it turned out that the the thoughts that he were thinking about how we should make programming languages and development environments like I can make something now that okay it's gonna take more memory it's gonna be slower and it's not going to matter because those things are going to improve drastically over time what's not going to improve is programming brains they're pretty much as mush as they were back in in 93 so we need to optimize for that so that's sort of the hardware side that moves really fast okay not that I mean we know that Moore's Loren all right also funny to look at the things from 2003 Java was actually a real thing that people not ironically wrote like that this was actually well we were when rails first came out I was talking to a lot of Java programmers and and this was they were serious and it's just funny to think back about this sort of battle or whatever that that we had in the beginning and that this was the the relevant foe this was who we were trying to sort of say there's a better way to implement a lot of the good ideas that you have because that was the the second funny thing of course is that Ralph's is from 2003 and the bulk of the thinking about how to structure and and create nicely factored web applications so the types of applicants came from the Java world it's just that they were trapped inside that beast and and we have to liberated so there are still people programming Java of course the JVM lives on and it seems like that has a long and prosperous future and people are putting it to much better use than then the Java language itself using struts that was actually a serious framework at that time that we were sort of trying to convince people why this was better why XML situps and so on were not something you should have to do so it's a it's really interesting to think about all these things that changed and and how much the world of technology has changed in the in the ten years that rails has been around and I've been trying to reflect on on why that is why are we still here why didn't rails go the way of struts why wasn't it just a footnote in sort of a progression of things and where were all these other things that were supposed to come afterwards I certainly never thought when I started working on rails that I'd be here ten years later and talked to 1,500 people at a sold-out conference that's a pretty miserable suggest that's surprising I'd say in technologies just like the flip phone is not here anymore and strut thankfully is neither you should've thought that rails would have gone away right so I think the stuff that I talked about last time or last year that pioneering spirit I think is what makes the Ruby community and the rails community is unique we are willing to continue west we don't just stop when we find a comfortable resting place there's a lot of other communities that value stability far higher than we do that's not to say that stability is is bad it's just it's a trade off if you look at say the Python guys and how long they've taken to get on Python 3 they're not there yet by the way it was just still going and it's been years right how long did it take the Ruby community to move from from 1/8 to 1/9 from 190 to 200 and it wasn't because it was painless how long did it take the the rails community to move from rails one to two to three to now four again wasn't painless anytime you want to make progress like this it's going to its go to hurt but we as a community are willing to take that hurt and I think that that makes the community unique we're willing to sacrifice for progress and I think what's what's interesting about that the pioneering spirit that we're willing to continue west that we don't just stop halfway and say yeah it Kansas is good enough a lot of people just they stop in Kansas like that's just like thanks for fine I mean I have my cows and the Sun comes up in the morning great I mean although some rails people have stopped in Kansas just to be clear there are still a few people still running this is the half-life of rail to where we are right now came out in 2009 that's four years ago anyway so if you're still in Kansas keep going west California awaits you the west coast of weights your Portland I should say actually my bad so we've continued west we've gotten closer and closer to this sort of promise of the of the west coast and I think as we've gotten closer and closer to that as it's taking years and years because this again it's a painful journey it it's a perfectly legit thing to say I'm just not interested in any more progress we're stopping in Kansas and and I will go on and I will do rails two three for the next four years all people did and it wasn't like they were necessarily miserable I mean people do lead good lives in Kansas but I think that there's something more important here to keep on pressing on and not just because we keep our own interest and and and this is still interesting to go to if we just stopped as a community and said rail su3 that's our final resting place Ruby 1:8 what did we end that one eight nine one eight eight one eight nine whatever there was that's the final resting place that's what we're gonna stop right that was that's just where we're gonna Park our ambition and say that's good enough I don't think we would be here because then these things would just be be tools nothing wrong with just being a tool there's just something more inspiring about pressing on and going further about this whole notion of pressing out and going further Jo Spolsky in 2001 had this great sa good software takes ten years get used to him at the time I read that he really was funny I read that it's like what a jackass I can make something in six months that's gonna blow the doors off whatever you've been working on for ten years but I think he actually had the the long end of something you can build something that's that's that's good for you in six months and it could be good software if you want to build something that has the kind of impact on community on the programming community on the world for lack of or less grand use vision it just take a long time we've slowly but surely built this up over time and that goes both for the work that I put into base camp and it goes for the work that I put into rails these things compound slowly over time if you keep investing in them you can see the sort of progression of investment that we've had with with rails and the people who've been flowing into it an undischarged new contributors with their first commit to rails so 2004 first time I open up the court base and accept patches and let other people commit to it a few people 40 people I think have a patch going to rails in 2004 very next year big boost 280 people or whatever then we sort of had like if I don't want to call a flat face we face because this is all new people coming into to the community and starting to have something but for a long time we have sort of a steady rate of new people joining the community and then something interesting happens 2009 this small tip everybody thinks the world's going to end and everybody's getting fired and all right I understand and then after that what happens there's a massive jump and this is actually funny because this is actually so 2009 our Kansas so there's a baseline there right we keep pushing and people respond a lot of people are interested in in pushing on with us is interesting and joining the caravan and continuing on which is really just sort of interesting to see the phase that we can go through by the time 2009 I've been working on rails for six years and we've had this data steady influen then all the sudden lots of people getting interested in getting involved awesome if you look at the same did I actually know that the chart up no I did if you look at the same chart just compounding all the commuters you can see it's a little bit more of a steady client but the same pattern is there from 2009 and onwards lots of new people got involved because we kept pressing through kept pressing through the comfortable face even though the funny thing is when you do that you sort of we have the same with base camp where you shouldn't be afraid to let customers go sometimes customers are going to outgrow you they're going to think that well you you no longer represent what what they need in a project management application paint a natural reaction to a lot of people or for a lot of people is to look we can't let that happen no customer can leave lock the doors we will do whatever we can to make them happy we had that motion or at that moment in 2009 but we could have said let's just lock the doors let's just improve things for all the people who already here big enough community we're comfortable we could be self-sustaining for for a long time that'd be fine where we instead said nope we're gonna keep the doors open what that's gonna mean is that there's gonna be some people who are unhappy then people I've heard people say rails 2 3 is the best version of rails ever made which is is sort of such one of those funny nostalgic things have sort of you just lock your time zone like deities that's when music Pete and it it's it's just such a funny phenomena but it's very real and I think that's where a lot of Technology circles an ecosystem they stop and then they just stay there for the rest of life anyway we pushed on here are the stats for the last 12 months running more than 1,000 people were part of more than 8,000 commits to rails rails github repo that is amazing a thousand people working and this is just the people get commits in we have so many more people doing all sorts of other stuff around the corpus this is just the people who got to commit into into rails rails itself that is really and truly astounding and I think that that shows and validates do you approach the uncomfortable approach that we have to keep pushing and keep getting better even if it will ruffle the feathers of the people we we already have the customers the developers that are already using rails that are sort of somewhat I'm comfortable with whatever new direction we have it's also a funny match to Rodgers innovation adoption curve idea this is sort of a an inland and analysis describing how people how products are adopted so obviously for from the beginning we had a lot of innovators like people who just would use rails even though there was a lot of things that were broken or didn't do whatever in the beginning small slice of the overall market of developers okay we got the early adopters I think that's our sort of first crest and then you you sort of hit this point where you have to make the jump from early adopters to to the early minority and I think that's exactly what that point in 2009 shows us that we did make that jump we're now on on sort of the next ride up which is which is pretty cool and I think it's also interesting for me in the original reason that I got into open source the original reason that I wanted to release rails was twofold first I want to give back I had been using Ruby I'd been using Linux I've been using my sequel I'd been using a pass yet be used and all these open source projects so when I had something myself to share I felt like dude your dick if you don't release something like this that other people could could find value in when you've used all of their stuff so there's that don't be a dick and then the second part is I'm having a lot of fun doing this stuff Ruby is really a great programming language rails enables me to use Ruby to build Basecamp there's gonna be a lot of other people out there who could benefit from from Ruby's so let's get as much programming joy out there in the world and that's why this stuff is interesting because we are having a bigger impact we're we're getting more people involved with with enjoying their work and not being stuck in struts or whatever painful torture instruments of the time anyway so I think that that that's all great and it's great to see that more people be involved but you also sittin didn't have to stop and say okay what are we actually doing here what is the purpose why are we still working on this what is the improvement past who are we and and who do we want to be so I think a while back decided we want to have a big tent it should be room for a lot of different people in in the rails community jugglers magicians clowns and elephants all invited come on and and we pulled some things we did the in with rails 3 we had a influx of good new ideas from from at the time a competing framework called MERP which was sort of a good reflection of okay it can be a big tent we can have room for a lot of people in here who might not agree on everything they might not all want to build base camp but we have a general principle of general purpose that that this is where we're going and we're agreeing these things and then once we sit down and actually work on code together we realized that we share more opinions than we don't but even so even if you have a big tent and you have room for jugglers and elephants and and so forth and you're having fun you're not a ferris wheel like there's there's got to be something you're not you have to sort of define it in in some sort of or positioners say that there's limits to what this is because if you try to be everything to everyone all the time you're nothing to nobody none at the time not a great place to be second the title of this talk is patterns of base camps application architecture the whole idea of patterns is that you see a problem and there's a solution but there's a third element there's a context there's a context in which that problem arises because you can encounter the same problem in two different contexts and you're going to want two different solutions to that so what is the context what is the context of Rails of the work that I've been doing on Basecamp for me that context is dynamic hypertext documents does that mean it means that this is sort of one time to produce it's funny because when you see HTML it looks like it's such a they're books like learn HTML in four days right it seems like such a low-level thing it seems like such a simple things that you so the Beneatha's kind of thing if we are serious programmers who do serious work like all we're doing is just generating HTML that's I mean come on that's very CML monkeys right like I need something more grand well to me the grandmas is embracing this simplicity is embracing what the web is and not just the web and HTML as a delivery mechanism sort of the web and an HTML has a lot of sort of side effects that are neat in terms of software deployment that development don't have to install software you just get it from one place you could deliver a lot of different kinds of software will you just use HTML as a as a delivery mechanism but when I've been revisiting and going back through through the Basecamp code Basin and especially the work I've done with the new version of Basecamp I realized that it's deeper than that that this is not just a delivery mechanism the actual structure of HTML the approach to to the context of software development as a document is profound and that profound approach is not something we should try to escape it's something we should try to embrace so you can think about a lot of different applications that are being delivered on the web sort of on like continuum on the one end you have something that's basically a purely document document based and on the other hand you can have something that's almost like a GUI using HTML as a delivery mechanism but certainly wouldn't describe it as as a document I think if you look at that sort of continuum from document to GUI and nothing falls perfectly at either end perhaps perhaps these two I mean Wikipedia is pretty much just a collection of documents it's a pretty good map - I think my vision at least of what I'm interested in the kinds of application I'm interested in and those kinds of tools that I'm interested in building I want to build tools for a document based web that approach to software development is is quite different from from all sorts of other approaches that went before if you look at software from before the web it it looks different and I've been struggling to find a word to describe that style of applications GUI is the best I can come up with even though of course the web is a GUI too but sort of know what I mean maybe it's easier if you look at an example if you look at Google Maps for example that doesn't feel like that's a document that feels like this is usually hTML is a delivery mechanism for for the application that is provides doesn't mean it's not a great application this is a great application it just means that if what we're trying to do is optimize for a version and a vision for web applications that is more document based this is not the primary thing we should optimize for so if you're trying to write the next Google Maps maybe rails at least that's a whole package as a full stack frame work isn't the natural fit you can pick parts out and you can have a good HTTP processor and you can do all these other things that's interesting so if that's a hundred percent the camp that you're in the sort of not related to documents at all then maybe that's not it then it becomes interesting because this said a few things are either one thing or another thing completely if you look at Basecamp for example we have this calendar there that doesn't feel very much like a document doesn't feel like it fits HTML what's the section what's the header what's the paragraphs here it feels like we're using HTML as the delivery mechanism but it's a minority thing part of what we do so we sort of try to fit it in and assign and it should be possible but it's not the main thing the main thing is more stuff like this where it actually does look and feel like a document this looks and feel like something you would not have before the web this would not be like what an application looked like because this is that native development style of the web if you look at something I get up the same thing it feels like a document it feels like it's a document that's decorated with some dynamic behavior and that's great but the key part of it its essence in this being is the document itself it's not just a delivery mechanism so that's the the slice and the part of information technology that I'm interested in that these kinds of document focused applications are not a bad thing it's not something we should be trying to escape the constraints that it puts on us to develop application in this style they're liberating they're not bad we don't want to start with an empty canvas and have to draw everything up from scratch the fact that hTML is there and gives us sort of semantically relevant containers to put certain things in is a is a benefit it's it's it's great and that's where I guess the insight for me is that why is it that I was never interested in Java applets it wasn't just because like it was Java like it's horrible enough in itself but it was the notion that this was just a blank canvas you can draw whatever you want there are no limits here you don't have to fall in line to to some pre describe notion of a document or set GUI elements firfer for a document of forms and so forth you can do whatever you want I don't want to do whatever I want I want a container a base to put my ideas in that's when I find that the floor is so with that insight in mind and with the insight in mind that the web is the most successful software development platform of all human history that leads me to think that it's actually not that big of a surprise that this failed because the architects of this sort of canvas base let's use the web just as a a delivery mechanism for the same application architecture ideas that we had on the desktop they're wrong that's not the part of the whip that's interesting it's not just these accidental properties of OTC to update software because it runs on my server the things that brought the web to its prominence with with users and developers alike with the constraints was the fact that that style of interfacing with with information technology is is it's really user friendly it's very development friendly it's it's different not in a worse way and that's usually what I I had a conversation I think it's real scoff maybe seven or something and some of Microsoft guy was coming up and he was going to tell me about Silverlight and he was the pitch was I'm finally going to free you from HTML like imagine if you weren't bound by paragraphs and sections and diffs and so on imagine all the things that you could build and he genuinely believed that that was what was holding the web back the fact that it was delivered through HTML and if we could just be free from these constraints everything would take off right and it would be so much bigger when you fail him to realize that the thing that already took off what's the web and so you have to first attempt Java applets then flash same idea same idea if the web's constraints are terrible let's start with this open canvas where you can build whatever the you want and then magic is going to happen magic didn't happen and flash today I guess it's games and video players with DRM then in the universe their Silverlight same thing all the problem isn't that that it's the canvas it's that just the development is experience or whatever we should use a better language then all our problems will be solved developers will flock to it and end-users will rejoice didn't happen the web went out again HTML is still around and then I think I guess the one that that's a little more interesting a little more current is iOS and the current craze for apps which in many ways is exactly the same thing on iOS you can start with a blank canvas you can draw whatever you want what are the top downloads and all the app stores and so on game game game fart app game fart app game because the kinds of applications that we've been building for the web for the past from in my case 10 years with were being rails and in the case of the web what 20 20 years or a little more than that since HTML and and so forth came forth not those kind of things and those kinds of applications are that sign of application constraint is still relevant that's why we're still here that's why we can still build these things that's why nothing of either flash or applets or Silverlight or I think over time it'll show even iOS and native apps have topped the web off of the top top space ok so for the new version of Basecamp that have been building we took this even further even the the visual look of the application embraces the notion of the document of the page it's a series of pages stacked on top of each other it's a kind of application approach that you would not build with this sort of constrained list canvas based approach in essence we decide to embrace the document that the essence of the web and of HTML was the the truly profound part of it and the closer we could get to that the closer our application actually felt like it just was hypertext documents with links going between pages the changeful things the better off we were versus trying to embrace and deliver a more sort of GUI based approach with pains and sort of fixed elements all over the place and that that would bring us joy and happiness so this is about two years ago I've been working on base camp for eight years at that point and we say ok this was actually up for debate and this is where a lot of these sort of thoughts came from should we like try to that could we deliver a better experience with that more GUI delivered via HTML as the delivery mechanism approach could that be better and what I found was I wasn't actually interested in any of that what I was interested in was evolving that document bringing it up such that it feels like it's on par so that it feels like it's a worthy competition for that kind of GUI based a person what was really I was competing against I couldn't quite put my finger on it was it like the fidelity of the user experience is it like you can draw whatever you want no I think for large extends what people like about native solutions speed they are fast when you have to send less it's easier to make it fast so a lot of people were like well we want native stuff because we want fast stuff well then the thought goes well wait a minute instead of throwing all of this wonderful development style this document based approach this native approach to the web out just because we want speed can we get the speed without doing that and that became the focus of my work on the new version of Basecamp and that in turn became the focus of my work on rails 4 and I have sort of five patterns to go over that I used to to get that speed to to get to evolve the documents stay true to the document but bring it up to par with sort of that native approach and whether native means actually an iOS app board means a client-side JavaScript approach or something else like that same deal so the patterns defy patents are and they are sort of built in as a pyramid they build on top of each other first to make things fast especially to make things fast in a language that's not particularly fast by natural endowment you need to cache and we've had a lot of different approaches that caching over the years and they've all sucked so bad that it's sort of up there in like the last two hard things in computer science is is caching and naming things so caching why is it so hard it's so hard because you have to keep track of it with like you have to keep track of memory management when you have to keep track of how much memory you allocate and you have to release it and so forth it's C and buffer overflow and all these other wonderful things that people use to amuse themselves with it's it's not a very productive environment and it's not a very welcoming environment so to make caches work we have to cut out the complexity of maintaining them because if they stay as complex as you have to manually manage everything nobody's going to do it and the few people are going to do it or you can do it wrong so they're gonna have bugs this is also called generational caching I like to call it key based cache exploration because that actually says something about what it does anyway so in rails this is actually I think in maybe in three two we added this the notion that every single model will have a cache key that can be generated automatically and it's just based on a few things like the name of the object its ID and critically when it was last updated so that's the trick the trick is that you say you have a person object and at a given point in time that has a given key that's what you use to look up all your caches from when that person object changes the key changes you do not go back and look for all the places where that cache was used and try to figure out a way of expiring those caches that's what we used to have if people were sort of old enough to remember the sweeper which was this half way observer where you would observe model classes and then it could also expire caches it was truly I don't even know what to call it it was a truly horrible experience to try to maintain that because it felt so easy oh yeah just I mean when you save the object I just go back and touch these three things and you would always forget one of them and then the user would see expired cashes and you couldn't replicate it it was like well it works for me not a very not a very good experience so key based cash expiration really solves all of that because it takes it all the way back to the notion do you don't have to care who's basing a cash of you you don't have to keep track of all that stuff it will happen automatically as the person object evolves the cast key changes and everything that's bound on that cash key automatically expires it actually doesn't expire it just is not used again so that's the other part that we needed to make this work was memcache or something like memcache I think Redis can run this mode to where you basically say throw out all the old cashes that I have not touched in well throw out the oldest one so that automatically just works in such a way that when you update the cache key you're no longer accessing the old cashes thus they can just be automatically garbage collected thus you don't have to worry about them and you can just proceed with your merry life fantastic second part of that or actually building on top of that now that we've solved the complexity of cash expiration now that we've solved that we're not gonna have all these bugs anymore we can grow our level of ambition and that's really a good sort of comparable to to Railton in general we usually we start of solving root level issues root level problems then once we have that solution in place we build something more ambitious on top of it we solve that problem we have that in place we build something more ambitious on top of it and that's how we can end up with a framework as pleasant and advanced to use as rails because it's sort of this layered cake well next layer in the let's make go fast cake is Russian doll nested cashing now that we can rely on these individual caches to not be a pain in the ass to maintain we can build composites out of them we can nest them deeply I would never really have tried to do this with sweeper logic I mean just making a few caches was painful enough try to nest caches and inside of each other forget about it but with the problem taken care of it's it's really not a hard issue anymore we can nest these caches inside of each other and make some really tall caching stacks which have this great benefit of we only have to expire a little piece of it when you just cache the whole thing a whole page something changes and you have to throw out that entire cache well it's really expensive to recompute the entire page again and then you can cache it right that's not really what you want only a little part of your document in this document based approach changed so that's only really the price that we want to pay to recompute in reales we now have this idea of of touching so you can build these trees where a comment is inside of a post a post is inside of a project if something changes in the comment we will touch up all the way up the chain if any updates happen we will automatically bump all the updated at fields on the parent objects again we built in this automation where I just declare my hierarchy once and now I don't have to know that if I change my comment I also have to remember to change the project because that's kind of the same so the problem we had with with caching and dealing with that stuff you don't want to maintain these things you just want to deal and think about these on a one level at a time approach if you look at participate a page from from Basecamp and how this is below me it doesn't actually matter that you can't really truly see too much of it what you can see is that there's a little blue box to the bottom of the screen that represents a single to-do item that's a single cache okay every single to-do item on that list has their own individual cache that entire box that entire to-do list then has its own cache that entire section on the page all of the to-do lists have their own cache that entire page itself has its own cache we're now four levels deep into our nested Russian doll and then what happens when this one thing changes so the one to do changes in the old world the whole page throw it out recompute it again very expensive very slow new world you just bust every element above you so a single to-do item is changed we bust that cache that bus its containers buses container and buses container but to recompute those containers it does not have to recompute all the other stuff that we still have caches for so to recompute the cache of a to-do list you can reuse the caches of the other nine to do is that we're already cached you're just changing the one recomputing that and then compiling all the caches together like okay that turns out to be very fast it turns out to be very fast when you're changing things when you don't have to recompile it the whole thing again and second of all is now easy enough that you can do it without it feels like a complete pain this is how it looks in the view if you take the bottom layer the Commons partial that's cast just based off the common key because the other pain of caching was to try to figure out of course all the things that this depended on in his new world approach to it I always try to just make it sure that it just depends on one thing make sure you have your tree in line and your cache should always just refer to one model object and we'll deal with the variations in a little bit but so here we have two the cache partial that's inside then calls from inside the the post partial the cool thing of the rails for feature that we use for this for the nested caching is that what was hard about caching was both maintaining this kind of updating stuff with the models chains but what was the equally hard was what happened with the partials changed when you evolve your design how did you bust the cache to account for that when we account for that automatically in every single cash key that's used in the view we compute an empty five of that partial and included in the key so if you change the partial we will automatically along the same lines as if you touch the model bust all those keys that depend on it not only that we will bust all the keys in the Russian doll structure so if you change the Commons partial and the post partial includes Commons as part of it and in its cache that would be busted to automatically because we actually look through the template file to find render post comments and say these two things depend on each other now we have a whole dependency tree and every single partial can be changed individually and we will automatically just bust the caches that depend on that if it doesn't automatically match for example if you have your own implementation of render Commons you're not just following this default convention you can manually declare a template dependency and they'll be included in the cache and so forth okay this is all part of rails 4 it's part of an exploration I did with a plugin called cache digests that what's called yeah I think so cache digest and it falls this natural way I've been developing new features for for rails by saying well first iron will spike the pattern in Basecamp just as a plugin if it works we will extract it and move it into rails itself so the result of all this is that these are the performance stats for base camps for last week the mean response takes 27 milliseconds median 59 milliseconds and the 90th percentile 155 it's pretty fast and it's fast because we're relying on all this caching stuff and it's easier to work with because this caching stuff is no longer painful we could build more things on top of that but before we talk about that we have to do one side direction for all these caches to to so neatly is they have to be the same for most people most of the time if you're just cashing stuff for an individual user and every single user have their own cash not very useful not a whole lot of reuse you're not going to get those numbers so what we've had to do is basically identify in templates all the places where stuff is different for different users and figure out a way to deal with that well welcome JavaScript decoration to decorate our our documents so here is a timeline in Basecamp for updated events does matter you can't really see it what it does have here is it has a time says 1:05 p.m. if we cache that time it's going to be 1:05 p.m. whether you're in New York or in Portland not very helpful because it's not the same time at the same places this is generally one of those things where you would just rely on whatever the user is you would just say well event updated add to string it doesn't matter I already have the time so because I'm getting that and active record will automatically convert that time soon for me but we can't rely on this because we can't cash this because if we catch this we're cashing it in one particular uses timezone so no bueno what we have to do instead and this is really the pattern for all these cash is this we have to figure out could we describe this data in such a way that it could be converted for the individual user at the time of render so that we can reuse the caches and and not have to keep different gases or well yes we can this is the approach we use so instead of just saying output the time in the specific time zone of that current users that's currently going on right now we output a time tag that has the time in in UTC and then we have a we have a JavaScript hook that just looks for these time tax and once it sees that and converts it on the client-side into to the latest time zone or the time zone of the user works really well now you solve that problem okay or more of these problems is not none of this progress was going to come easy none of this sort of approach to it is going to come without some sort of sacrifice or change in your way of building applications but that's okay next problem so here you have a to-do list in Basecamp you have a bunch of controls edit delete move copy well not all people at all times are allowed to edit a to-do list or a comment as it is down below so how do we deal with that in the old world we will check permissions on the current user if current user can change to-do lists show these links well here's the problem again current user we can't use that so we have to figure something else out now when it comes to these things where it's just a link where the permission is actually not on the action but on presenting the action we can say okay we don't need to do that what we will just do instead is we will always show the link in the cache for everybody will see the link but what we will do is we will decorate that link with something like data visible to admin or a creator and then just as with with the time set up we will have a little piece of JavaScript that will go through look at all those links and say oh you're not an admin you're not the creator height the link again it doesn't matter in this case because well this method that it's shown in the actual document because who cares if somebody's going to do view source and see that there's a delete link I can't click it anyway because you're going to force all this stuff naturally on the controller as well so all you have to do is hide it the one area where this becomes hard to make the full nested all set up is when you can't actually show a piece of information to a user so if you have a list of notes and some of those notes are marked private and you're not supposed to be able to view source and then view that note this trick is not going to work you are gonna have to do more fine-grained caching and you can't use the nested doll SOLAS you want we have a few cases like that and Basecamp were when you're looking at cross project stuff we're pulling in topics and you don't have access to all projects so you don't have access to all topics that's we can't show you the same thing but even in those cases we can still cached individual lines and we can still just group the things that we can cache when we can and it's still a huge step forward so when you have now this speed when we brought the speed down to a mean of 27 milliseconds when most things are happening below 100 milliseconds there are now other bottlenecks that pop up and things that make the application feel not as fast as native even though the server side is actually doing things as fast as it can so you have to move on and figure out what's the next step so my approach was first I found a way with the caching to get us down to this level of speed for basic emitters like this is great then I clicked over on some clients at Embassy yep and I clicked around it's like there's still something missing here why is this faster why does it feel like the whole change of the document it's kind of slow even though I can see on my server side it's not because they're renting their any faster a lot of clients at NBC apps if you look at how long it takes them to render the JSON lots of them will spend 20 milliseconds doing that or 50 milliseconds or longer so that wasn't a problem the problem was that they get to keep a persistent process off their whole job confinement that they don't throw away between each section enter turbolinks turbolinks is a simulation of sort of a single page app like that that we will keep our natural way of building these document style apps but we're not going to throw the whole process away every time it's a little bit like PHP or CGI where there's nothing left over that's the natural way when you change a page in the browser and you're not running something like turbolinks the whole environment is thrown out just like CGI you can set up all sorts of variables poof they're gone when the request is gone just like PHP it's gone when the request has gone everything's gone there's nothing to clean up after turbo lanes turns your app into a persistent process to cut down on this speed deficit it's based on an idea called peat jacks that the guys over at github created - because they ran into the same issues they were trying to make the github interface faster and sort of ran into this issue well actually seems like there's something that takes a long time to change from page to page the pjax approach is based on the notion that if you look at page there's going to be some parts of the pace that don't really change you can look at a navigation bar at the top doesn't really change what we are going to just focus on change between links it's just the body part of it just a one walled off section and we can just change that well as I was looking at I was like this is curious to me why is it that slow to send down the navigation part of it if you're sending down the bulk of the stuff is in designated div anyway so maybe the extra navigation is what 10-15 percent of the data you're sitting down that's not the slow part the slow part and that's what led us to sort of look into well actually what's slow here is when you throw away your whole JavaScript runtime and that's an aside here but even though we're building this document style approach we have all these little JavaScript declaration bits and they actually there are a lot of code we have 10,000 lines of CoffeeScript code for for base camp maybe I don't know 3,000 of those so 2,000 dos are for that calendar that's sort of overrated Oh everything else is the decoration of decent document so there's actually a lot of JavaScript running even if we're sort of targeting this approach anyway so turbolinks just basically says that's not the problem the problem is not figuring out which little part of HTML should we send in which little part should we not send let's just sent the whole damn thing but let's keep the head let's keep the JavaScript process intact and and we don't have to recompute that ok great Steve clap Nick did some tests on this and there's some confusion about how much it's actually faster and it certainly varies depending on how fast your your underlying app in but in tests he was running it was between 20 and 70 percent speed increase I actually never ran those tests I didn't know that that was the actual speed I just ran the apps back to back with it and without it and it just felt way better with it much faster it's gonna feel faster the faster your app is so that's one of those things for if you have a really slow app it doesn't look like triple links does anything for you if you have an app that returns a response in 50 milliseconds feels like a big deal final pattern even though we have these documents and we're changing them as we pursue links one notion and one measure of speed is that things happen even if you don't have to manually do anything for them so if you look at a page like this in Basecamp it's a to-do item comments are popping in as people are making them I don't have to reload the page I don't have to reload the screen I don't have to follow something else it just pops in that feels fast so that's another sort of section of that ways what the notifications of native systems they felt like they had this live element that's part of what made them feel fast we can recreate this really easily the way I'm doing it is this approach so the the underpinnings of this is basically rjs and not rjs is in use Ruby to generate JavaScript but as in reply would fully form JavaScript replies to an action so that's what we do we break it out in in three elements we have page updates which means JavaScript updates that's going to go to both the person currently making the change and to everybody else listening on that page so we record all these JavaScript calls we basically compile a little bit of JavaScript we stick it into a queue and then we have everybody else who visits that pay listen for that queue and pull every 3 seconds here the local updates thinks you only want to do for the local client I guess you can call it so these things are not recorded not stuck into the queue like closing the forum when make a new comment it shouldn't close everybody else's form it should just pop into their stuff and here is a road update package that only goes to clients listening for this for this channel when I sort of stumbled across this pattern I was kind of amazed how little work it took because I already had all this work I had already lined out all these elements too just to do the Ajax part of it locally then the only thing I did was I started a recorder and recorded it all I ascent to all the listening clients I basically made the entire base cam app live in about four hours instead of building something else and sort of coming up with a different way of how do I track this and send the door let's just send the same to everybody that I'm sending any way for the Ajax response and it turned out to work really really well and when I first built it the attention wasn't actually to use polling it wasn't just to troll everybody who thinks that polling is an outdated mechanism that you could make I was thinking you know well I just pulled in polling for now because that's easy and then we can make it sort of some sort of live update or permanent persistent connection or something else in time well that time came and that time went and it was necessary and today this whole system is running a hundred thousand requests per minute or pulled through a couple of rainbow or six rainbow workers and and one Redis instance so this is one of those fun things that almost that kind of relates back to that chart I have for the ramp like polling sounds atrocious because it sounds very inefficient the thing is inefficiency only matters if it's expensive to solve we're terribly inefficient rails is a horribly inefficient framework it just so happens to be that in in 2003 that didn't matter in 2013 and matters 20 times less than mattered in 2003 it couldn't have worked in 1985 but so what we're not in 1985 anymore let's build stuff for the technology and capabilities we have today let's trade-off let's be wasteful in our programming cycles and memory usage as far as it doesn't matter okay so these are basically the the six patterns of the new base camp and all of these approaches are if not built into rails forth and very easy to do I'll put up all the code and we'll publish a little bit more about how we do the live update thing it's very little cold rainbow worker that does the polling is half a page of code and you just saw basically the rest of it so thank you very much this is my presentation you
