 So, yeah, so thanks for the kind introduction, Bruce. And, yeah, Mexico City was a very nice time and it was really nice to see how quickly Elixir has been spreading over the last three years. As we've used Elixir Bleacher Report for about three years in October. And so this is a talk basically, as Bruce alluded to, about how we've adopted Elixir and how we've done it at scale. And there's only so much you can do. I'll try to get as much as I can in 40 minutes. But there's some areas that I won't be able to focus on that are equally important, such as documentation, how to properly test your applications, and how to deploy them as well. And the nice thing is that if we can do this at scale, then that means that anyone can do it at pretty much any size, especially if you're a smaller company, you can apply these same rules to whatever you wanna do. So we're gonna focus on four areas. The first is the business case. And unless you're developing things by yourself, you have to convince someone else, including yourself, I guess, to develop with Elixir. Why would you do this? If you're a bigger company, Bleach Report is a moderately-sized company and we're owned by Turner. So there was a lot of convincing that had to be done. The second is consistent code. When you, again, unless you're developing by yourself and even if you are, you need to have a holistic application design, and this includes how do you do code reviews, how do you make sure that these standards stay consistent across the apps. And when you're learning a new language, this is all the more critical and all the more important because if you don't do that, you end up having a lot more tech debt, which you would incur anyway, but at an increased rate when you're doing it with a new language. And this is perhaps the most interesting part is to have the realized benefits. How has Elixir worked out for us? How has Phoenix worked out for us? What do we still need to improve? And what can we do going forward? And finally, developer happiness. I mean, most of us are developers in here and most of us wanna be happy and most of us wanna be happy when we're developing. So this is a survey of what we're doing at work and how our developers feel about it. And we actually have four other developers over here from Bleacher Report. So don't take my word for it. So we'll start with the business case. For us, it was sort of a perfect storm. We had, these are some stats to show the level of traffic that we have. And it's an older platform. We were transitioning away from the old platform, which is eight years of tech debt. So we started with Rails 1.0 and I was saying 10 years ago, it was more of a web-first and then we moved to mobile with the advent of the iPhone. This was when we, sorry, moving from web-first to mobile-first meant that traffic came in a different way. We had, in Silicon Valley, you stayed at a company for maybe a year or two. So we had a lot of lost domain knowledge and we had this labyrinth monolith that was full of all these dark corners that no one really knew what to do with. And finally, unpredictable traffic spikes. Since we're a media company, that means that when breaking news happened, we had to be the first to deliver the news, whether it's through notifications or any other manner. Ruby didn't handle that in a very good way, to say the least. And so we ended up having to scale up and scale down and so before big events, we would have to plan like, okay, so how do we handle this or how do we handle that? For instance, when Kevin Durant moved to the Warriors, it was a big deal. Traffic spiked four times in five minutes. And this was on the Elixir platform, which was good because we were able to handle it. Had we done this on Ruby, it would have probably crashed. And why do we choose Elixir? Everyone knows, I guess in here, the concurrency, parallelism, high availability, distributed stuff. But the nice thing about Elixir, so we evaluated other things, we evaluated Go and Node, and in my own personal research, I've used Clojure and Scala. But the nice thing about Elixir is that it looks like Ruby, which means that it's easily approachable. So you say this is a function definition. I know how to do this. If you look at Erlang syntax, it's a bit more esoteric. And so I think one of the great things that Jose did was to say, here's this great language, Erlang, it has this battle-tested VM, and now we're going to put this very familiar, very approachable syntax on top of it. And for whatever reason, functional programming has a reputation for being difficult, for being hard to understand, for being something clunky, something academic. But by giving this nice facelift with the Ruby syntax, it made it very easy for people to come and say, okay, I can get started with this pretty quickly. And, but I think, you know, we talk about, we happen to be a Rails shop, we've been using Rails, I was a Rails developer for five, five or six years before this. This is really a paradigm shift. And I think the nice way to illustrate this is with the observer. So for those who don't know, I'll show some graphical images of this as we go. But another nice thing to mention, like having the enclosure in Scala in the past or attempting to do Scala, Scala was quite difficult, never could get my head around it really. But, so in this, this is the IEX prompt, and the observer is an Erlang tool that's been around for a long time. And it's so easy to call Erlang from Elixir. You just colon observer.start. And I think this is perhaps the intention that Jose had in mind. I feel like the relationship between closure, Scala, and the JVM is much, much more clunky. But Erlang fits like a glove, or Elixir fits like a glove over Erlang. So it's a seamless integration. So this is one of the screens of the observer. You can run this with any mixed application. And you can see here in the upper left-hand corner that there's the cores here, the logical CPUs. So it's really a shift between single-threaded and multi-threaded. And the way that the Erlang VM is designed is such a way for a multi-core world that you can take advantage of all of these different cores. And this is a second shot. And this is all built-in information. It's incredibly useful. Oops, this is all built-in information that's incredibly useful. You can see there on the lower left that there's the eight cores. And you can see each of the, what's happening in all of them. And you can see that it fluctuates up to about 80%. And what I'm doing here is really to stress test my local machine. I'm taking production data and I'm seeding my local machine with all the production data. And it's really easy to do this because of the fact that you can spread out these over these eight cores. And you get a lot of other built-in information right there on the bottom as well, items, processes. And all this is very easily available, continuing with that. This is the processes table. This is a visual representation of things that other people have been talking about over the last couple of days. And it's really also a nice way to benchmark your app and define any bottlenecks because you can see the message queue. If the message queue gets stuck, you can easily see what's happening and find ways to debug it. And then last year at Elixir Conf EU, Lance gave a talk about Phoenix not being your application. And this is a visual representation of that. You can see that this is one of our, this is our first Elixir application. And you can see all of the left on, all the applications on the left. And you can see that Phoenix is listed alongside Elixir, which is listed alongside Exometer, listed alongside Cowboy, and AIM, QP, and so on and so forth. And then the graphic on the right shows the processes and all of that stuff. And it's really nice and very helpful way to visualize OTP and to understand how these things all relate together. And so now we'll come to consistent code. This is probably the most important thing about adopting Elixir other than, once you're assuming that you understand the language, when you try to train other people with the language, this is where you have to focus. And I think that Jose and Chris and have done a great job in really pushing documentation. You have XDoc, which makes beautiful documentation on Hex. It makes it very easy to immediately see what's going on. And when Jose introduced Gen Stage, there's a slide on his presentation that said that there are 1,100 lines of documentation and 1,000 lines of code. And I think this is crucial to understand that this is one of the ways to adopt Elixir. So going back to Stefan's talk, while it is harder to set up Phoenix than it is to set up Rails, you at least have the documentation available to make it to hopefully fill in these gaps. And it's actually, I joined Bleacher Report because I was interested in Elixir. That was my primary motivation for going there and all the challenges that are associated with the sports platform and the size that we have. And we had this one app and there's some issues with it. Like it was a Rails app and it kept falling over with under load. And I was like, oh, this looks like a relatively simple app. And I ended up rewriting it at Elixir in a couple of days and it outperformed the Rails app and we still use it in production now and we keep adding onto it and we keep refactoring as we go along. But it said to me, I can do this. This is, while this is different, at least I can move forward and we have a demonstrable small chunk that we moved over to Elixir and it's working really well. And incidentally, it was the last time I really wrote Rails code. I think in the last two years of Bleacher Report I've written maybe 300 lines of code of Rails code, of Ruby code, which is really surprising because I really like Ruby. I really, you know, I have a lot of respect for the Ruby and Rails community because of all the things that they did, but now I have no real reason to write Ruby or Rails code anymore. And that, you know, two years ago I would have thought that would have been unthinkable. So now that we have this, no, so now that we're adopting this new language, this new framework, how do you teach other developers? It's one thing to teach yourself how to write Rails, right, Elixir and Phoenix code, but how do you train other people? And when we started about two and a half years ago, there weren't really any guidelines, even in fact, the Phoenix 0.5 slash dev, the one of the GitHub guidelines was do whatever you want, basically. Like, we do whatever feels natural, which is a pretty laissez-faire attitude towards running a production system. And, but somehow, you know, we tried it. And we sort of developed our own internal guides, how do we do this, how do we do that? And a lot of it was exploratory. And at the time, there were three or four of us writing Elixir and we bounced ideas off each other. But now we have Crado, which I think is a really, really helpful tool to make your code superficially consistent. I think that Crado is best used as, not as an analyzer, but just as a way to standardize things that you would miss normally in a code review. And it's also a good way to make sure that the code reviews focus on the logic and the application rather than, oh, you have a parentheses that's one space here, this indentation here. So I don't really like, I rely on Crado as sort of a gatekeeper for style, not as for substantive things, but it's still incredibly useful. And here's, like, this is the kind of information that I would want to have with Crado. And this is also really nice because a new developer can do this by themselves. They can say, okay, I'll run Mix Crado, I get these errors, and then you can drill down them. And you can actually go Mix Crado and go into the file itself and it'll give you a nice detailed rationale for why it's done. Like, for the longest time, a lot of our modules had no module doc tags. And part of this was because maybe we didn't, maybe some of the developers didn't know this was important or whatnot, but then you can see this, oh, I don't have the module doc tag, you drill it down into it, and then you can see exactly why the module doc tag is important and what its function is, which is really, really useful. And I saw something on Twitter the other day that was talking about how Crado was too, they didn't like their defaults. They didn't wanna deal with all of the defaults for Crado, so here's, you can change whatever you want. So say the only thing you care about is line length, the only thing you care about is, maybe you believe that the max nesting should be more than three, you can adjust all of these here. So you can make it, you can really use this Crado.exe file to set the standard for your entire organization's Elixir projects. And I think it's really, really nice to have this out of the way because all of these little things like module doc tags or doc tags or what have you, they're not really code-reviewable in the same sense. Code reviews are really, really important to me because this is, I think you can have an organization without code reviews, but I don't know why you would want to. It took me a long time to come to this conclusion, but the code review process is essentially an editorial process where we are programmers, but we essentially are software writers and the code reviewer is the editor. So the code reviewer will review your code like an editor. Like there's, you know, in the past there would have been no, it wouldn't have been possible to publish a newspaper or whatnot without the code review in place, but now it's so easy to publish blog posts or to write code and ship it. There's no real cost to skip the editorial process, but you lose out a lot, especially when adopting a new language. And I think that the tone of the Elixir community has done a really, really remarkable job with Jose and Chris in the sense that when you look at, you know, when people submit code reviews or pull requests, they, even if the pull request isn't accepted or even if the code is bad, Jose will take the time to write out this is why this is bad or this is why this is good. And I think that sets the tone. And so the, because in the past and other communities, the, it's been a lot harsher when with, if you write, if you submit a pull request that's not good, then you'll be really, really criticized. And it's really, really, it's detrimental to the community and detrimental to people wanting to learn the language. And so when, at Leach Report, when a new developer is learning Elixir, what we do is we do generally in-person code reviews. So you sit down, you go through the code, and it makes it a lot easier because it's a back and forth exchange. Of course you can use GitHub to write comments on pull requests, but a lot of context gets lost in comments with when you don't see the person face to face. And before the code review process, what we ask the new developer to do is to say, okay, so, you know, use a programming Elixir book, use a programming Phoenix book, get enough to where you can understand the code or here's some old Ruby code, you see the context, now write that in Elixir. So it ends up generally happening is that they write more Ruby-ish Elixir, which is okay because it works. And we also ask that you write tests, of course, so that you, so that we do refactor the code, you can be sure that the code will still work once it's been refactored. And we use a library called xcoveralls, it's just, you can print out test coverage and these kind of things, and it really helps to give us confidence when we do the code reviews that this person has done their due diligence to write tests that will cover what they need to cover. So here's an example of some code that was submitted a while ago by a newer developer. And basically what it does is it takes a URL shortener, shortened URL and it does something with it. And this works fine, there's nothing, I mean it's not bad necessarily, but it's a really nice teachable moment I think. So you can rewrite it something like this. So instead of doing the case statement, you can break things out into different functions and each function does one thing and you get to introduce the pipe operator, which people tend to really like, you get to introduce the attribute so you can put these things up, that you can give it a more semantic name and then you can handle things with private functions below that do different things. But I think it really explains how functional programming is modules and functions and if you are able to break down what functions do into simpler and simpler concepts then it makes the code that much more readable and that much better. And it also gives the developers the confidence that they're moving forward in the right direction. And this is something refactoring often, this is something that since I came to Bleacher Report, it's something that's been really important to me personally and to everyone in the organization. As I mentioned before with all of the eight years of tech debt, we didn't pay down our tech debt in the way that we should. And so we were paying the price for it, which is one of the reasons why we were investigating Elixir in the first place. And we adopted Phoenix at 0.5, Elixir had reached 1.0 but there was still a lot of changes on the Phoenix side and we ended up getting behind in a couple of versions and at this point there were breaking changes and doing whatever you feel, when the guidelines say do whatever you feel like, there are gonna be changes and there are gonna be breaking because it was pre 1.0 anyway. So we realized that since we're learning the language since the framework is changing so quickly that we need to have regular sprints or regular refactoring in all of our sprints. And in addition to that, having this mentality of refactoring often means that when, you know, when Phoenix 1.3 comes out, you have these ideas, these new concepts, you have time to say, okay, how do we evaluate this? How do we look at our app? How does this make us reconsider our infrastructure and so on? This is the first Elixir app that we wrote and this is the editions in deletions graph with some divisions. And I think it illustrates pretty clearly how much we've refactored throughout the course of the app's life cycle. In the original, the exploratory part was when we decided, okay, this is a proof of concept, let's see if we can do it, if Phoenix will do what it says it does and Elixir will do what it says it does. And then there was a break in the definition point where the product was like, oh, we have, this might be the answer to the problems that we were having, let's reevaluate how we need to do this. Let's set up, you know, set up the stories and all these things. And then the next four steps, the next four stages are when we released the production and we were adding features and then the refactor part, I think is the most interesting part because this was about a year or so after we started using Phoenix and Elixir at work, more people had started developing Elixir and this was sort of the moment when we realized, oh, you know, we should move away from this MVC pattern, we shouldn't think of modules as models in the rails or in the traditional MVC sense and to start thinking about modules as groups of loosely related functions and this transformed the way that we talked about our data transformation and data modeling. So instead of having, you know, say we have lots of different content types, we have an article, you have a video, you have Instagram posts and so on and so forth. Instead of thinking about them as distinct models in the database, let's think about all of these things, all of these different content types have common fields. So using embedded schema or using change sets, we were able to simplify our data models. So we just basically have three, we have one content type that has one content table, one content item table and then one metadata table. So it's related in a way that simplified our code base a lot and you can see this on the right side of the refactor part where we took almost all of the code that we done in the first chunk there and removed it. And at that point, the code base, I think was smaller than it had been since the beginning of the release phase. So it was a real win on our side to say, okay, we've been able to have this app that does more than we thought it would do, that has less code than it did when we first released it. And it's just, it's just an amazing feature of what happened when we started to understand how Phoenix and Elixir worked well together. And this also brings me to another point when I happened to be listening to Elixir found earlier this week and Dave Thomas was the guest and he put a really nice phrase that there was something that the concept that I was sort of mulling about in the back of my head but he called production prototyping, which is essentially what we're doing here. We have an idea, let's deploy it. This seems to work. Let's try something a little bit different and so on. And I think since we've been using Phoenix and Elixir for such a long time, I feel like, you can sort of see from a wider angle into a more finely focused point, which is I feel like what Phoenix is doing, especially with moving things with the stuff that Chris talked about with Phoenix 1.3. And we're sort of following that behind. Because we refactor often, because we understand the things we're gonna change, because we know that our understanding of how things work are going to change, we have to be ready to make these changes in production and so on. And this really opens up to the fact that we learn on the job that there's time that, and our product organization and the management really have bought into this to understand that in order for us to succeed with this, we need to be flexible enough to refactor and move on together. And it's worked out really, really well for us. And then monitoring is essential for any production application. And this was something that we struggled with about in the beginning because as a Rails shop, we used a New Relic, I think we're probably in the first 10 customers of New Relic. So, no New Relic, so what are we gonna do? We have, there are many other options. Elixir wrapper around Exometer, which is a monitoring tool. There's Static, Static's, which a coworker John just found last week that we're going to evaluate since we used Zatadog and StatsD. And then Pluglogger Jason is a library that he wrote that was really helpful in debugging some issues that we had in production. One of the most interesting bugs that we had in production that was really difficult to track down and we probably wouldn't have found without being able to monitor was that I think that it's fixed and hacking now, but if you have a high amount of traffic, the workers would get confused in the pool. So, you make a request and then it would take like 45, 50 seconds to come back and we were, I was like waking up in the middle of the night, I can't figure this out, what's going on? This is unbelievable, especially because we were putting timeouts of three seconds and it was still taking 50 seconds and we couldn't figure it out. And eventually it turns out that under high load, the workers get lost and there's a comment by Eric about he'd had the same problem with Hex with Hackney and so we disabled the pool and rely on Phoenix's to take care of it and the problem went away and then everything was back to normal. But this is just one example of having proper monitoring that we wouldn't have been able to catch had we not had this in place. And this is, I mean, this is some of the stuff that we use for monitoring. I mean, we have all sorts of metrics that we do, but it's nice. So on the top, the Erlang run queue, this is nice because with Exometer, you're able to expose the inner workings of the beam so you can project that onto whatever monitoring dashboard you use. And then CPU utilization as well. And with the CPU utilization is another interesting bit because with Rails, the problem that we had was that eventually the CPU would go up to 100 so we scale up, add another server and so on and so forth. And this is obviously unsustainable. But with Erlang and Elixir, it was hovering around two to 3% and I was convinced that we were doing the measuring wrong. There has to be a problem though. How is this? We're running all of our traffic on this and it's only 3%. And then before we released our code into production for the first time, we had Erlang solutions come by and they evaluated our code which was nice for one because we had their expert opinion to evaluate how we were doing. And two, they're like, oh, you're doing a good job which is nice because we had more confidence in what we were doing. But they're like, oh yeah, that's just not, the CPU utilization might not be the best metric to use for monitoring Elixir and Erlang. So these kind of things, you have to be flexible to understand that things are gonna change and your understanding of things will change over time. And so now that we have these things in place, let's talk about the realized benefits. There are a lot of things that we can talk about and you can talk to my coworkers in the back there. They will be happy to tell you about the things that they've enjoyed with Elixir and Phoenix. But this traffic-resistant response times is incredibly important. As I mentioned in the beginning, since we're a media company, we wanna be the fastest, we wanna deliver the content the fastest. No matter the size of the audience, as long as we're the fastest, that's sort of the bottom line because if you have ESPN, you have Bleacher Report and some other sports app, if you're ESPN or other sports app, notifications are consistently quicker, you're obviously gonna go there first. So here's last week's traffic. This is a standard for us peaks and valleys as people wake up and go to sleep. We have offices in the UK as well, but most of our traffic is from the States. And this is a 95th percentile. I don't know if you can see that on the left, but it's in milliseconds. On the left, it's at the very top, it's 300, 200, 100. And this is pretty standard. So our 95th percentile hovers between 100 and 150 milliseconds for all of our traffic. And it's step admissions in this talk, sub one second is good, so we're there. We still have to, I think there's still room for improvement to get under 100 milliseconds because there are some limitations that we have with our deployment process, but it takes time to do these things. And we also use Fastly as a CDN. The Fastly hit time is approximately 0.02 milliseconds and the hit rate is around 60 seconds. So figure out what gap is there between the Fastly protected end points and then the non-cached end points. And what makes unique last week was that it was a Super Bowl. This is not our biggest traffic night of the year, but it's one of the biggest nights. And in years past, as I mentioned before, we, oops, in years past, as I mentioned before, we had to scale up and prepare these things. And the last Super Bowl, there was nothing. No one, there was no meeting, there was nothing to scale up. Nothing happened at all. It was like a normal day. It was a testament to how far we've come with Elixir and Phoenix and a testament to Phoenix and Elixir as a language and a framework. So now that we have this, now that we have this platform, how do we stress test it? How do we know that at this point, this is going to succeed? So we have X amount of normal users. We have X amount of, this is our maximum. How do we know how much traffic we can handle? So we built these internal tools to ghost traffic from production to sort of a testing production environment. And then we can multiply that. And we were able to get eight times our normal traffic on our same number of instances without any additional cashing or these kind of things. And it started to fall over because of the database connection. It wasn't Elixir or Phoenix thing, the database was the issue. As I mentioned earlier, because of some of our deployment issues and things that we need to improve on in that regard, we also tested it with ETS tables and we were able to get to 10 times traffic before we started to see any issues and we just stopped there because at that point we realized that that wasn't a viable option but in the future we'll come back to that and we'll see how much more traffic we can get out of that. So that's a really nice thing to say when we deploy something into production, well we can, with reasonable certainty, say that we can support eight times the traffic which would be a dream for the product team and for the management team to say, okay, we can still handle eight times traffic and it really makes it a future proof for us as a company. And then further from that, we were able to reduce complexity by removing third-party integrations. We used to use Redis a lot, none of us are Redis experts so we just, you know, maybe this is right or maybe this is wrong and we were able to jettison these third-party integrations that were costing us a lot of money and by jettising these third-party applications and other tools, we're able to become experts in one thing which is, you know, Erlang and Elixir and it makes it a lot easier to say, okay, so instead of needing to know about the X number of things, I need to know about one thing, it makes it a lot easier and it focuses your skillset. As I mentioned earlier, tangible savings. We saved a ton of money on servers. We're still sort of fine-tuning how we use them as we understand how the beam works and these kind of things. We're able to jettison a third-party integration service that we were paying a lot of money for and it's kind of a funny story so when one of our developers went to break the news to this third-party that we're not going to use their service anymore and we were paying them a lot of money and he explained, well, you know, we're doing this with Elixir and Phoenix and now we don't need to use you anymore and all the response to this is, well, why isn't everyone else doing this? So it's a good point, why not? And we have a much more reliable platform now. As I mentioned, as I alluded to earlier, we were able to do Super Bowl Sunday without any incidents, without even bothering to check it. The NFL draft is our biggest night of the year consistently for whatever reason people really want to know when their players are drafted. I'm not sure, well, I'm not a sports person but they like it. So we rely heavily on push notifications to send out alerts for people to come into the app and check these things and in three hours we sent 225 million push notifications which is quite a lot and our push notification system, the actual thing that pushes out the notifications is running on two instances and one is for redundancy. So this is, I mean, it's a really, really nice demonstrable win and this was one of the times when both the customers who use our app were sending more app reviews like this is amazing, like Bleacher Report is always the fastest. I don't know how they do it but something changed and also the people who program the content streams, like if you follow the 49ers or I don't know the Texans or whomever, they also were like, as soon as I clicked the mouse button to send the alert my phone buzzes with the alert and before it would take, we had to do all this weird caching and these dedubing and Ruby's not the greatest at that. So it would take, if you say you sent a push notification to all NFL subscribers, which I think it's about, I think we have about 10 million, it would take up to five minutes and now as soon as you press the button within a few milliseconds you start sending them out and then it finishes significantly, I mean, I think it finishes probably in under a second or two. So it's a huge win for us. And then relatively future proof, what this means is that we've designed, as we've come to understand how Ecto and Phoenix and works and how data modeling works in a functional programming language and how we started to move away from these hard concepts of modeling like a cat as opposed to like Chris mentioned earlier, not to use a cat analogy, but a user and a registered user. We've been able to model our data in a very generic way so that if Bleach Report decided to move away from sports and onto some other topic, politics or regional cuisine, on the back end, we wouldn't really have to change anything. We would be able to say, okay, this is, so now that we're talking about politics instead of we still have the same concept, we still have a YouTube article, we still have a video, Facebook posts, all of these things. It's made our platform much more agnostic. So decoupling the data from the models has made it really, really nice for us to be confident that five, 10 years from now, maybe we'll still be running the same platform, especially given the fact that it would be, I'm pretty confident that if our CEO said, now we have eight times the traffic that we had and we're still running the same platform, everyone's happy. And then at that point, we would be able to move into other platforms, other challenges. And to this point, now that we have this stable platform, instead of being like, how do we support this? How do we do this? Now the question is, what do we do with this now? How can we push this to new limits? What are these new product ideas? And suddenly, for the longest time, the engineering group was sort of the holdup for the product. They wanted to add all these different content types. And then we redesigned the system and now what used to take a couple of three days, now a new Elixir developer can add a new content type within a few hours, which is really good for them as well, because it's the confidence, hey, here's now in the app, I see this type that I added and so on. And it gives us time. And for the first time in a while, I think product is like, okay, so you gave us all the, you over delivered all of these things. So now what do we do with them? So they're sort of figuring out the strategy of how to use these new tools as well. And finally, developer happiness. Don't take my word from it again, ask my colleagues. But when I first started Bleacher Report, we have, everyone goes on, we use Opsgene, we go on call about once a week per month. We have offices in London, as I mentioned. So if someone had an alert or if the site went down or if there was some problem with the internal tools, you would get woken up in the middle of the night. So the first few times I was on call, it was a nightmare, I would dread it, I'd carry the laptop with me all the time because there would be something that would go wrong. And now the last few times I've been on call, there hasn't been any issues. Or if there are, I mean, there have been a few small things, but it's usually during working hours and it's significantly better than it was. To the point that now, the last time I got woken up in the middle of the night was a developer and a content programmer in London complaining that their hotel wifi was down and what could I do to fix that? You know, it's, sorry, you're on your own. And it's, there's a real sense of accomplishment too. It's, you know, instead of, it's not fun to fight fires all the time. It's not fun to go into work and fight fires. It's fun to go into work and develop new stuff. And this is what we all do now. Everyone is working on new projects, whether that's taking out functionality from the old Rails monolith and moving into Phoenix and Elixir or whether that's having the option to make something new and push the limits of our platform. It's really exciting. So you're actually writing code and not just saying, okay, let's add these, you know, X number of instances to AWS. And right now, I guess now everyone for the past six months or so, everyone is an Elixir developer at Bleacher Report, which has been a really nice accomplishment for us. And everyone's pretty happy with it. You know, when you learn a new language with anything else, whatever skill you, you know, guitar, drums, whatever, there's ups and downs, you know. I'm doing this really well and then you hit a roadblock and how do you get past that roadblock? But once those roadblocks are overcome, everyone's really, really happy and it speaks to the design of the language and it speaks to the design of the framework as well as the community and how they have put forth the effort to make documentation in first class and a citizen and all these kind of things. And I think that everyone is really, really happy and even, you know, to Stefan's point how, you know, ramping up is slightly more difficult but I think it's also more rewarding because you're like, with the Rails thing, I mean, I remember when I first started doing Rails, I made the Rails blog and I was like, now what? Like, what do I do with this? But Phoenix gives you the tools to say, this is like, by breaking things into chunks and components and modules, it makes the development process more interesting and more engaging and I'm sure that as we go along, it will be that much better. Okay, and any questions?