 Hi, everyone. So when Jamie asked me to do the talk, I was kind of in between the two different topics. One was why Ember sucks for beginners, and the second one was the Peepstack. So I'm talking about Phoenix and Elixir together. And I kind of went between the two for a while, and I decided on this one, so I hope it's all OK. So I was trying to think of a name for the Peepstack. And I thought if I started with the P, start that you'd probably all laugh or heap with Heroku in there, or Pepe-stack, maybe. But some guy called Justin on the internet already named it for me, so I didn't really need to bother. I just kind of followed his article on Medium, and he'd already written it for me. So if you don't know already, the Peepstack is Phoenix, Elixir, Ember, and Postgres. Is anyone using Phoenix or Elixir? Oh, just a few, OK. I've been using it for about four, five weeks. I'm not an expert on this, but I thought I'd present what I've kind of been learning. So I'm going to talk about how I started my startup. And to begin with, it didn't use three of the four of these. It was actually something that was very common. So if I'd kept using this stack, I would probably not be here tonight. I'd probably be at Backbone London, not Ember London. So I started off on the Rails, Ruby, Backbone, and Postgres stack. And the reason for that is I kind of knew that, and I was very comfortable with that. So I run a site called Superhide. It's not quite launched yet. Basically what I'm trying to do is something that you guys would probably already know, but I'm trying to make coding a lot easier for beginners. So you guys probably already know quite a lot about this. But basically I'm trying to build a site that looks like this. I'm not allowed to actually show this online because I don't own that photo. So the idea is for beginners, they can't get online very easily. They don't really know what they're doing. There's going to be lessons as part of this, but I'm showing you how I got a site very easily online. There's a preview there. And then you publish an instant site online in about 20 seconds. So I started off in January on this stack, Rails, Ruby, Backbone, Postgres. But I very quickly found out that Backbone sucks for particularly complex data models. So I went to see a certain guy that you might recognize. Now, I heard that this guy, Jamie White, seems to love Ember. So I went to see him at the pair sessions with AssociatesD. Now, if you don't know about whether Associates pair sessions look into it, it's really, really good. If you want to chat about anything, they're really, really good and really nice people to talk to. So very quickly I changed. I put in Ember instead of Backbone. Initially, I started on Ember Rails. I kind of started to get a really big project structure. I had everything in one big, big folder. And I got more and more difficult as I brought people into freelance. So very quickly I changed to Ember CLI. But in a passage of time, starting about six weeks ago, maybe, I met this guy, Steve Graham. And there's a little cat. I've got another little cat break. And he's running a site called Teller. Now, the idea behind Teller is basically APIs for banks. And he showed me what he was doing. This isn't live yet. And he kind of went in the office for me, sat down, and showed me what he was doing. And I was like, holy moly, how did you do this? I thought he was doing it locally in non-test data. But he was actually using the real version of the site that actually got real data from bank APIs. So I was instantly jealous of what he was doing. I was then looking at my Rails app, being, oh, this is really slow. This sucks. So it's starting to get really, really big. So Rails app has pusher, it has a ton of gems in there. Basically, it's become this big monolith of a site. So I kind of did the risk. I was kind of looking at this app thinking, do I have time to change this stuff? I've got some investor meetings. And I've got a school to do pretty soon. It's about six weeks away. Do I have time to do this? Shall I spend weekends actually learning this thing? But then I kind of thought of it in this way. Am I allowed to swear? OK. Do I have time to make myself really fucking good? And I thought, yes, of course I do. And it's good for the user. We talked about performance on the front end. And this is going into the back end. Now, I put my site on Heroku. And I was clicking around, and it was pretty slow to actually update. And as soon as I started changing over to Elixir and Ember, I suddenly got these speed increases five to 10 times the speed that I previously got. And because I was already used to Ruby on Rails, it wasn't that hard to actually change over. So I switched very quickly. Now, if you don't know about Phoenix, phoenixframework.org, really, really good site. Kind of goes into a lot more detail. And again, it does save productive, reliable, fast, which is very, very true. And if you're a podcast fan, as I am, as you probably tell by my t-shirt, there's a good thing on the change log. It's a really, really good kind of hour, hour and a half kind of interview with Brian from DotGuard about how they bettered their company on Elixir and Ember. So you probably know all the Ember stuff, but a lot of things to do with Elixir in there as well. If you look at the DotGuard site as well, it's really, really quick. I showed it to someone the other day. And they were like, is that real? How did they do that? And that's the kind of magic that 10 years ago, people were the same with Rails. So it's the same kind of thing today. Now, if you don't know what they are, Elixir is basically a kind of similar language to Ruby and Python in the same way that Phoenix is built on top of Elixir. Rails is built on top of Ruby. Django is built on top of Python. But it's a different kind of beast altogether. So why did I want to use Elixir? So these are some of the main reasons that I went with Elixir. The concurrency model is really, really good. I'll kind of talk about some of the examples in a bit. It's really scalable. Again, it's really, really fast. It's built on top of the Erlang, which has a huge history. And also you can use a lot of the libraries from Erlang in Elixir. Nelsos Mix, which is a very good kind of rake slash bundler kind of tool, that makes it really, really easy. And Y Phoenix, for me, it was very Rails influenced. The guys who made Phoenix came from a Rails background, but it also had this stuff where the web sockets were built in. There's a great team behind it, and it's really, really quick. There is some downsides though. So because this is quite a new thing, and it's kind of starting to get a bit trendy in the last maybe six months, there's still a very small community, which does mean there's less tools for people to use. I would also say that it's a little bit uglier code than Ruby. It's just personal preference. I like Ruby's very, very simple code. And occasionally Phoenix documentation's a little bit sucky, but that can always be worked on it. Three months time, it might be really, really good. So this is a kind of example that I'm using Atom, and I know that I might get kicked out because I'm using Atom, but you can kind of see the kind of very similar structure to Rails. So instead of the app folder, we have a web folder, and in there we have things like controllers, views and templates as well. We've got router in there. We've got a kind of mix file, which is a little bit like bundler and gem files in there as well. So it's very, very similar to how Rails is set up because it comes from that background. So I'm gonna talk a bit about my favorite bits of Elixir and Phoenix together. So one bit that I kind of got a bit confused with at first, and I was like, what is going on is pipes. So Elixir has these things called pipes. Now this is actually taken from some code that I've written on the site that I'm building right now. So in Phoenix, I've got a change set, which is the change to the database. I wanna generate a password for my user. I wanna generate an API key, and I wanna put it in a database. Now this kind of pipe with the little kind of angle bracket might look a bit confusing at first, but the way it kind of works is you take the first element and you put it as a first argument as on the next line, and then you do that again, and you do that again. So this kind of code at the bottom is exactly the same as the one at the top, just a little bit cleaner. And the more you do it, the more your code gets really, really clean, really, really quick because you can see the processes that you're going through over and over again. Now Pat Machina Guards is one of my favorite things, actually, so this is another example for my code. I'm using this case of a user login using username and password. Now, if I was to do this in some like Rails, I'd probably have a lot of if statements, a lot of else clauses in here as well, but with this it's actually Pat Machina. So this bit up here returns back these kind of bits back. So if this is fine, it returns back a user with okay, but occasionally it does lots of different things. So in this case, I know there's an error and it says no user, so it's definitely gonna do a certain thing. If it's a bad password, it does a different thing. If it doesn't hit any of these errors at the start, no user and bad password, it does something else, but that's a variable that I can pass through and deal with in a different way. And if it's none of that, then I can set another variable to handle in a different way altogether. So it's quite, it's really useful for testing as well because you can put a lot of different things in it, see if it works, see if it doesn't fail in different ways. It also has, you can use same function and again, but use these things called Guards. Now, this bit over here is the guard. So this is part of the same bit of code. It's just, we handle it in two different ways, depending on what's coming in, the kind of functional programming aspects of it. So in this case, our params are just zero, there's nothing in the map, so basically there's no object in there, it's just an empty map. We handle it in a different way than it would do if it does have parameters below. So this stops this kind of big if and else clause is you're handling things in a different way which makes it a lot easier to test. Now, this is never example of exactly the same thing. We're using different arguments in different ways. So for instance, this bit of code is actually doing two things. It's finding the project and the file name to serve back to the user. So at the top, if there isn't a project, the project's nil, just return nil. Now, I wanna handle my very particular file type in a certain way. So for any project using this underscore, we're using sup-hi.js and we're handling it in a different way than the other things below it. Now, if I'm on the root of a page, then my file name is gonna be blank. So I'm gonna set that to be recursive. So this recursively goes into the bottom function. So we're saying in this bottom case, handle any file name in any different project. Yeah, yeah. We're allowed to redefine the module. Exactly, yeah. Yeah, so it palm matches it in that way. So yeah, it kind of goes through the code. This will all be on one page itself. We also have channels which are built directly into Phoenix. So this is an example that I made of a Slack group. So we're gonna join a particular channel on Slack and it's gonna return back to our front end saying okay. And then whenever we wanna push a message back and forth, we can say this is our message that we're sending back. Here's our body that's going in and this is a socket that it deals with. And we can then pass it, we can broadcast it back to our front end. And if you can do this at any point in any controller or even models as well, you just set on your endpoint a broadcast saying the topic, the event and the message that you wanna send back to your users. So it's also particularly easy to deploy to Heroku. Now, it's not a default. You have to set it as a build pack, but it's very easy. There's very good instructions on there. And it's actually, you just add a build pack, you deploy and it's on Heroku. So, when I was saying earlier that I needed it for a deadline, the reason why I was doing this school called Super High School, basically I was giving out free coding lessons to 15 people. And this started last night, so there's me teaching 15 people on Super High. I needed it to be ready. And one thing that one of the students said was he was kind of unfounded, like how did you do that thing? Now, he's not a developer, he's an illustrator. So he was getting confused, like how did you do that thing where it was really, really quick? And it goes back to that performance thing that we were talking about earlier, like it feels like magic. And in a way, it kind of went back to when I saw Stevie's teller, I was kind of going like, holy moly, now my students have the same envy as I did when I saw Steve's site. So I really think that Phoenix is going to be the next big thing. If you want to build APIs, if you want to build any kind of site, Phoenix is really, really fast and built on top of Elixir, it's really, really good. So thank you very much. Any questions? Yes. So the API wasn't particularly huge. Most of it's on the front ends because it's all kind of user interface and kind of making it simpler. So in terms of the models, there was about six or seven different models, different controllers handling that way. It took around two weeks to switch everything over, including some tests. So it was pretty quick. I mean, I was doing it over the weekends as well because there's a bit of panics and kind of like shits, any touch you get, things done. And in test frameworks. Yeah. So the one built into Phoenix is called XTest. It's very similar to how Minitest works in Rails. It's very easy to pick up. And it's the same kind of thing of the guys obviously coming from a Ruby background they want to use pretty much the same tools to make it a lot easier. It's also a lot quicker to do tests as well because of the concurrency model. Anyone else? Yeah. I'm going to talk a little bit about what is the kind of overall goals of Elixir? I know it's just a mere idea. Yeah. Is it meant to be a scripting language? Is it what's ideally usable? So the reason that I switched over is because the way that I'm actually making things that are very kind of interactive and a lot of kind of messages going back and forth because I'm basically building a code editor but with a lot of the things built for beginners. So there's things like autosave. So for every two seconds, it's going to save a file. So I want it to be really, really quick and do a lot of background processes. So if I was to do a normal kind of content site, I probably wouldn't use it. I'd probably use something very simple and just get it online very quick. But for something where it's like hard APIs and lots of requests going over and over again. And I only dealt with two dinos on Heroku last night and it held up perfectly fine. We did image upload. And we had 15 people at exactly the same time of loading like 10 megabytes of content. And it handled it perfectly well, like no slowdown. People just was like, oh, it's finished already. And I was like, that's right. But it's that kind of speed that people were actually really surprised about. They thought it was doing something that it actually wasn't. It was just the speed of it and the kind of the way that it's written, really. Do you use as any of the scripting libraries? Yeah, yeah, exactly, yeah. Elixir's way easy to write than something like Erlang. I've kind of looked at Erlang libraries because of having to implement a few things. But I look at Erlang and I'm a bit like, oh my god, I don't know what any of this means. So Elixir's a lot better for me just because I'm from a Ruby background. I heard an interview with Jesse Lee. He talked about it in terms of almost like a Lisp, where then it's built on this kind of powerful macro system and this idea of treating CODAS data. And it allows things like Phoenix's Roozer DSL to be built but still compiled to something like utterly on the metal on the VM. I think it's, I don't know, scripting language is necessarily what he was going for. I think friendly language is definitely what he was going for. Yeah. I think it's having a heavy weight VM behind it. I'm going to pack a matching of kind of a way. Yeah, I mean, it's a lot easier to see the flow from the start and the end from where your data is coming from. There's none of the kind of Rails magic that goes on and things disappear and come back. So I've always find it a little bit kind of like easy to see what's happening throughout the whole process from request to response. Yeah. Great. Did you not just think about it in a threading or process model or did it with like, say you're a hierarchy, I don't use a hierarchy, so say it was a box with eight cores, would it just use all of them? I don't know enough about it to, no, I mean, what I've done at the moment is there's a background task that whenever you upload an image, it just handles it in the background. So it's a very easy thing to just add. Do you have to specify threads or processes? Yeah, it basically spawns a task which is kind of very similar. Yeah, yeah, and it's because it's built in, there's no kind of like rescue kind of things or psychics or yeah, so it's a lot easier to just be like, okay, this needs to do this. Off it goes. Can you treat this on the presentation? Yeah, yeah, of course, yeah, yeah. I was actually just on that and was reading a bit about being the Erlang virtual machine last night and from what I gather, I'm definitely gonna get this completely wrong. I think in Erlang, Erlang processes, they call them, they don't map onto operating system threads. So what it does is when being booted, it will spawn up a thread for each core and have them running constantly and then distributing processes between these operating system threads, but you never see them. You're always dealing with these very lightweight, I suspect the Erlang processes might be able to even live on a different box and that's, you know, yeah. I think you can do distributed code. I know, I don't think you can have a mention service. Yeah. When you spawn a task, it's a task that's BAD. Yep. You receive it. It's the same thing that's with codes. Yeah. So depending on the first number, you know which one thing is running, which node is running, the number is in the machine, the number is the process. Yeah, you can basically spin it off and then receive it when it's done in the end and kind of handle it that way. Any other questions? Is there an elixir made up? I don't know, actually. I'm so new to it that I'm kind of like, I just give this brand new thing. Yeah, so a couple of months ago. Yeah, it's really good, though. Like, I've kind of been playing, well, not really even playing with it, I've been kind of using it in production for the last six weeks and it's just how it really, really well and really quick development as well. That's what I was kind of surprised about. I thought I'm gonna learn this new language and get stuck really, really quick, but it wasn't quite like that at all. Yeah. Yeah, so Phoenix has got websockets built in. There's like a JavaScript library that you can include, but I've kind of ignored that and just used the Ember side of it instead of just kind of connected directly to the web socket. There is like an Ember web socket kind of add-on that you can use, you just connect and it just does the same thing that you do with the Phoenix kind of library in the same way. So yeah, it's really easy to actually integrate with Ember so that's a great part of it. Anyone else? Yes. Is it good? It's pretty good. Steve taught today, didn't he? Yeah, yeah. Sure enough, Steve. Oh, cool, I'll go to that next one then. Anyone else got a question? How's the Postgres adapter? It's okay. Issues in Ecto, which is kind of, so it's kind of a spin out. It's not as integrated as something like Ruby would be where you would do like product.all for instance. You kind of have to do like repo.all, get products and then that kind of thing. So it's a little bit of a kind of twist on that. So it's a bit more like old school RRM rather than a Railsy kind of one. But it works quite fine. There's not much documentation on it though, that's the problem. So I've kind of had to really delve deep into docs to kind of like work things out. I think that's the problem because it's all brand new and there's a lot of people working to make things a lot better and things change very quickly. So in the time that I've been doing Phoenix, it's been 0.13 and it's already on 0.16 already. It's just like very quick in six weeks. So I think they kind of need to slow it down or do bigger releases maybe. Don't know. Anyone else? Yes. Do you use any code to be honest? Pardon? Do you use any code? No, I've not really, I don't know too much about it to be honest. Still quite new to it. Yeah. But very quick one. Is it still changing before the first thing? I think it hit 1.0 quite recently. So I think it's- So it's not remaining? Oh really? Yeah. It's fairly stable. Phoenix is changing a bit more than Elixir is. But yeah, it's not changed since I've started working on it. Yeah. Have you encountered, have you worked with other people who know you? So I'm doing the start-up on my own at the moment. So it's kind of like, I can do what I want. But I imagine the problem is with I'm trying to hide people pretty soon, not yet. So it's a kind of hard sell. It's like, come and learn this brand new thing. And what do I say on the job? I've a developer who's doing new stuff. Yeah. But I mean, it's kind of something that was a bit like, do I change this? Because it'll be a lot more difficult to hire. But on the opposite hand, I kind of think that the people who are good developers will be more attracted to do something new and try some new things. So it's a tricky one really. Do you ever find that there's a library that requires massive amounts of their knowledge? There's only one that I'm really dealing with, which is one which kind of transfers things to Amazon web services. And apart from that, it's actually really easy to integrate, to be honest. Like, it's a little bit of a different syntax. And you kind of have to translate things a little bit. But it's generally OK. So I've done it fairly straightforward. And it works. So yeah. Cool? Thank you very much. Thank you very much.