 Hello everyone. Today Jamie's very kindly invited me to talk about Emberkit, which is the first product that I've made since I quit my job about two months ago. So I was working full-time for about five years for Macmillan, a big publishing company over in Kings Cross, and I finally decided it was time to go do my own thing again. So basically this comes with a bit of a warning. This is a bit of an advertorial and I didn't actually propose this talk. Jamie did invite me to come along, so I kind of don't want to make it too spammy. Emberkit is a paid product, but hopefully I can give some information that's actually useful and talk about some of the technical stuff as well that will actually be useful. So the reason I decided to do this as my first product is that I have a bit of a problem getting stuff done. I always have loads of side projects and I've got maybe five apps where I've made kind of the main feature. So I made a chat app that was supposed to integrate with ILC and GitHub and be really cool and I made the chat. I made an ICRC server with all the cool async stuff and then it came to the time to actually put it live and do all of the account management and billing and deployment and all that kind of stuff and I kind of just kind of got bored and decided I'd work on something else instead. Then it's kind of happened a few times. So when I decided I was going to do this full time, I decided that's not really practical. I'm just going to go bankrupt if I do that. So I decided I thought, is there another way to do this? And I kind of thought maybe if I could finish an app before I started it, it would be kind of different and that obviously sounds kind of stupid. What I mean by that is I wanted to try and do all of the boring stuff that I normally get stuck on first and then only after that move on to doing the features of the app that are actually unique. So that's when I came up with the idea of Emberkit. What I wanted to do was do all the boring stuff first, make it really smooth and polished. I set a goal of being able to launch it as a product that I would sell within a month so that I had a goal, I had a finishing point and then I could move on and hopefully make some money from Emberkit whilst I was working on my new products. So I'm going to give a quick demo. So this is Tomsterkit. When Emberkit comes with three branches, it's got JavaScript branch, a CoffeeScript branch and a Tomsterkit branch. Tomsterkit is basically like a stupid demo. It has one commit showing you what you would need to do to add your app's feature to it. So what does it give you? It gives you sign up. Let's sign up for an account. So you sign up for an account and you can then create an organisation. So I guess let's call it name it after our house and then you've got your basic edit details inviting users. Let's invite the user. You can choose a role of user or admin. Invite them along. Or get an email with a link to join the site. What's going on there? I've changed the port. So you can join and sign up. There we go. If you're an admin, you can subscribe. So there are subscription plans. It uses Stripe at the moment. Something broken. I've probably broken the Stripe integration. Oh yes, I've broken the Stripe integration because I'm not on the Wi-Fi. So if I was on the Wi-Fi, if you had internet connection, I'd show you the Stripe subscriptions, but it's all pretty basic monthly plans within it. So let's go back to the present. OK, so that's kind of the basic. If you're building a very specific type of app, if you're building a monthly build software that has a service app, this is probably going to save you a lot of time. And that's kind of the app I decided I want to build. I want to build something that's like a monthly subscribed service that brings in some recurring revenue. So I kind of built it so that I could use it and hopefully it will be useful for other people too. So now I'm going to talk about some of the tech stuff that's gone into it and what it's kind of doing. So what I decided I wanted to do for Emberkit was to have a full login and log out functionality within the application. It's really easy to on log out just refresh the whole page and that solves a lot of problems. Like I've done apps before where you don't get served the Ember app at all until you log in and login is actually handled by a Rails app or whatever. And that makes things a lot easier, but I really wanted to deal with the whole thing being a single page application. If you're a single page application, you should be a single page application. Cross-site request forgery has been one of the harder things to do there. You have to... The basics of setting a cross-site request forgery token in a pre-filter is relatively simple. But one of the more complex elements of that is what happens if you have two tabs open. Initially what would happen is that in the first tab you'd click log out and you would be logged out. And because the token is dependent on the current session, the other app would still think it was logged in and would just start silently erroring every time it tried to make a request. So one of the things that you can do is to render a specific error message from the API when you detect an invalid token. In this case, I've just rendered that string invalid CSRF token. And then you reset the whole session and request a new token from the server. So this is kind of showing that as well. You... In set up controller you get from the actual session object. You request a new token and then you set it in the app and log out calls reset session, which again resets the token. There is... Actually this link should have probably been in the previous page, but there is a blog by Yaymucand who I was talking to on IRC, which kind of describes this type of session approach more in depth. One of the other things that I really wanted to do with Emberkit was kind of use Ember data as much as possible. Like I kind of treated it as a perverse challenge to not use any $.ajax calls a tool and do everything restfully. And that's kind of led... So a session is a virtual object on the server, but it's actually an Ember data model. It has an email and password attribute for logging in and it carries the token. And you can... So this is on the left hand side, you can see the session object. It's just a plain old Ruby object with some includes in it. And then you have an active model serializer, which serializes that session. And that's kind of the approach I've taken for some of the other areas of the app, which are, again... Oops. Which are, again, plain Ember data models. So a password recovery, you create a password recovery request with your email address and post to it. And then it will send you a link in the email and that will allow you to create a password request, a password reset request, which will reset your password. So it's been quite interesting to see how far you can push it just using rest. It kind of requires some thinking restfully and contorting about resource naming and resources, but it's been kind of fun. Finally I'm going to talk about testing. So the reason I'm sharing this slide is because I use Cucumber. And Cucumber is kind of a love-hate thing. Like lots of people really hate it. And I really love it. It's... The great thing I think about Cucumber is that it lets you test in a really abstract way. And I think that a lot of organisations abuse it like I've really seen at my previous job. I've seen it really abused to do unit tests effectively. And Cucumber is really slow for doing unit tests. It's a really bad idea. So if you keep it at a really high level it can really help. The reason I kind of chose to use Cucumber is I really wanted a full stack integration test. I wanted to test everything from the front end to the database. And in fact the Cucumber test actually tests the live stripe integration with the, well sorry, the test API but it actually talks to stripe. And I kind of thought if I'm selling a product that lets you build customers like I really want to be sure that it's working like I really want that to be solid. So I decided to start with this. The tests run in about two minutes and they would run in about 30 seconds if the stripe test API wasn't so slow. So I'm working on stubbing that which is easy on the server side but it's kind of harder to stub out client side calls to the strike checkout library but I think I've got a way to do that. So that's going to come soon. Emberkit also has three versions. It's got JavaScript, a coffee script and the Thomaster Kit kind of sample version I showed you. And Cucumber covers them all with exactly the same tests. Some of the step definitions might need to be slightly different in some cases but it means that you can kind of write the test once and test it against multiple implementations. So I'm planning a Ember CLI implementation soon. I thought it was really important to kind of keep it flexible so that I could not have to write all my tests again when I want a new different implementation. And Joe who's here has a great slideshow about testing Ember apps which kind of goes into the different options of full stack testing. And interestingly enough is that Joe has at the very end of her deck about what would be great would be driving full stack integration tests from the browser. I might actually be doing some work on that in the next couple of weeks and figuring out a nice approach for driving full stack integration tests from the browser which if you check out this presentation shows you're kind of not driving them from the browser kind of creates like async dependencies kind of hard and annoying and slow. So after one month I was really fortunate to be retweeted by a couple of members of the core team and got seen by loads of people made about 50 sales mostly of the educational licence so there are three licences the educational licence is 39 bucks and it lets you kind of look at the code and see if it's hopefully learn something from it there's a single site licence which lets you build a site on it and a multi site licence for agencies and stuff I've had a couple of sales of the single site and multi site but it's mostly been from people who wanted to learn which is quite good hopefully I've helped some people figure out some stuff but since in that month I've actually started using it for my own project that I wanted to work on so I think it's been a huge success really it's kind of forced me to do the boring stuff for something that's going to let me build on stuff in future and it's kind of paid for itself in a way so I'm really pleased with how it's gone so I'd like to finish off by offering a 50% off coupon to anyone who would like to use it and ask if there's any questions thanks everyone for listening yes yes yep just model.save yes so that is a problem like what happens so there is the app that I've been working on in the past couple of weeks actually has a lot more models in it than which has obviously only got the stuff that you've seen so I've been working on a way to reset the session when you log out and resetting the session including deleting everything from the store and I've actually figured out that you can use app.reset for that so that's the helper that's useful for testing it will just give you a new container with new everything in it and that's something that I'm going to integrate into Emberkit soon just basically blitzing out the whole store and log out or log in and that will kind of mitigate that ultimately though I think that you know Emberkit isn't designed and single page applications aren't designed to be secure against people looking in your console and I think that like I wouldn't rely on it being secure against people you know who have access to your browser inspector that's that's not a threat model that has been considered really and it probably wouldn't be secure even if that particular case is catered for so at the moment I haven't done so everything on the ruby side is tested in our spec but not on the client side with Ember testing that will come soon I've been meaning to do some more of that Ember is kind of hard to unit test like you can do some things and it's supposedly easy but practically it's hard so because of the container you can dependency injection you can set up tests relatively easily and mock out the things that you want to mock out but it just lends itself I find myself just writing integration tests whether not whether that's with Cucumber and doing the full stack or even if I'm writing tests in JavaScript Q unit I just find myself writing integration tests in JavaScript that stub out the API I think that it would be good to do more unit testing and make that kind of a more natural thing but at the moment I found that that's something that I'm just I just find a bit hard I do it for certain things recently I was working on a pagination component and you know that actually turned out to be relatively complex because you want to show like a window around the current page and you don't want to show like a thousand pages you want to show like one to five and then like 900 to 905 and then you want to show like the last five and I ended up unit testing that but mostly everything's really lightweight in Ember and you know there isn't there aren't really that many complex algorithms generally in what you're writing it's normally like display data here and that really lends itself to integration testing more than the unit testing I found yes so you mentioned that the puthings are in the pipeline with the stripes stub in Ember, CLI stuff is it going to be something that you continue adding to over time? Yeah I think it is really I mean it's I guess until like I make my first successful product and go and retire on an island somewhere like I think I will always be updating this to be the thing that I build on I build on like I think it's kind of it was kind of quite important to me to build something that was what I needed to use and trying to sell it is kind of a side effect for me like I wanted something you know that's kind of the goal I set myself so that I would actually do it rather than so I've released about I think I'm in version 1.0.3 now I've released a load of updates and I'm going to hopefully continue Yeah you can pull them in via sorry each version has a diff from the previous version so you can pull it in it's not ideal like I mean you'll have some merge conflicts probably and that's something that I don't know if there's a really good solution for that practically I don't know if there's a really good solution for that apart from making everything modular and then spending six months making reusable modules for everything if that has its own problems so yeah if you upgrades can be problematic but hopefully they won't be too problematic depends on your app and what you change I mean because it comes with the big test suite hopefully you'll have continued maintaining that test suite and hopefully it'll be relatively easy to find out if you've broken anything any other questions well thanks everyone for listening