About this talk
Let's demo Jonne's app he just built for EmberFest.
I wasn't supposed to talk at all. I'm actually very badly prepared. The thing is yesterday after, well you may remember them, these two people from Netflix, after that talk they looked quite smart. It was an interesting talk. I went to pitch an idea with these people and I shouldn't have done it because they liked it. They asked me "Can you not do an Lightning Talk?" I presented this idea on an Ember Meetup, it took me more than half an hour and now I have to squeeze this into five minutes, it's a bit hard, but, okay, I'll try. So, there have been many nice talks, yesterday, today. There's one thing that I've missed, one fundamental truth nobody mentioned this, I think it's my task to just complete this, for the sake of completeness, there's a fundamental law in software and software engineering that we could probably all easily agree on. Backend engineers, we have front end engineers, backend engineers are less cool, less smart, and often also ugly. I'm gonna make a point of proving this, scientifically. I have a small application here, it's really small, I admit it's not so cool, I also had to just write it this morning at breakfast, and during talks, so it's indeed not cool, but for backend engineers, this is enough. And I also had to write a backend for it, I couldn't make the point otherwise. It can't do much, it's just two models, it's an Ember application, it has Ember conferences, and it has speakers. One Ember conference has many speakers, one speaker belongs to an Ember conference. The only thing it can do is you can add a new conference, let's say London, and, was it, Ember Camp, save. There you go, you can't even add speakers. This front end talks to a Ruby on rails back ends, that I also saw this morning, it's json api rails 5 application. There's no indication of anything, it's just this. I don't even test, just because I'm a front end developer, we're serious. there you go. They all pass. So, you are also front end developers, you have seen that you are unskilled but pretend you're a backend engineer, you didn't see. So I'll come back to this, on the backend I could also run them, well actually I'm running this backend, I shouldn't interrupt it. Now I, well consider this situation we're working in a team with these people and we're gonna prove how annoying it can be to work with backend engineers. You have these tickets, and they want to-- oh, yeah, the product only wants us to refactor something to change, for example, let's go to the code. We can see what I'm doing here, this is back ends. Here are the models, so you're all familiar with this, let's take the Ember conference, for some reason they want us to rename conference name. There we go. Into, whatever, "full bar." see, I'm not prepared. All files, there we go. There's absolutely no reason to think, to fear that these tests would fail cause all the reference is to conference, "name has been replaced," and, indeed, they were all green. So that's nice, I can deploy. If I were to do this, this would happen, of course, because these lazy backend engineers, they didn't do their job. There's half of it missing, and if I would even try to add something, "Brussles," I'm form Brussles... the Beerfest. Okay, there we go. Oh it fails, oh no, it showed something. Probably didn't synchronise with the back ends. Now let's go back to these tests, let's help these backend engineers a little bit. I'll activate these tests that I skipped before, where was it? Integration, these ones. All skiff become tests, there we go. Replace all. Now, this one takes a bit longer, it shouldn't actually, but it's relying on a service that needs to come live, just a second... There we go. So, these tests have failed, if I go back to my software, and I replace all full bars again into-- conference name, okay. Place. All. Go back. There we go. So that's actually magic, somewhere outside of my project, there is something, some sort of this knowing about what the API should do. That's what actually I, the point I wanted to make. Is I actually did the application, it's also not cool or sexy, it was also written really fast, but this application, running somewhere, if you look at the URL, it's on Eurocode, knows about my model, it knows that there are Ember conferences that have cities, and conference names, that they have many speakers, and if you would go back, that speakers belong to Ember conferences, and so on. Suppose I would take this one and change. This in full bar. There we go. And we go back. It fails, because I've refactored and it was again conference names. There's, in my tests, some communication between this Eurocode app, and this small application of this morning. The thing is, there was the ID that I pitched with people from Netflix, and that then liked. I had written this, too, a while ago, I ran into this situation where, well maybe you've also had it, you want to employ something, and there's a synchronisation issue with the backend they have just not updated, or, in the rare case that they were faster, it could be the other way around, if you could integrate into your test suite, some kind of spec, like a policing service, that could require, on the front end, and on the back end, that the communication, the pay loads of your request, should be compatible, then you can safely deploy, even your continuous integration could do this, you could block deployment, if this policing service says "stop." and you may save yourself quite some time setting this up with Selenium, because that, I think, is the way that most projects do this still. And Selenium tests, I've learned to hate those, they run for more than an hour, someone even told me once, 24 hours, and they are notoriously unstable, so people write these things like "sleep for five seconds" because something was clicked too soon, you may be familiar with these situations. Now, these tests, well suppose that this service needed to convibe, of course, they run in a fraction of a second, and they do, essentially, the same, and on top of that, you can test errors, you can test any payload you want, it's all generated. I'm not going to dive into the details of it, I'm just going to tell you that it is based on a technology called Json spec, Json documents, similar to XML specifications, they are generated on the on the fly by the stool, and used in the tests, so if people there are interested, I published this on K-DOP, there's even a dockerfile for it. So we have the back end and the front end. And you can, well, it's not finished, there's still some work on it. But we're using it on a project for the moment and it's quite cool. So thank you.