 As that part of the slide says, my name is Steve and this is the Webex Handler. This is actually a talk about how we took the Webex Handler from the PHP code that Cisco produced and turn it into production ready Rails code. Technically ruby stuff but we use it in a Rails app. So what is Webex? Webex is a video conferencing centre built by Cisco. It's got voice and chat and video and all that sort of normal rubbish. We use it primarily to talk, I get teachers talking to kids. It's an education business. It's technology focused. And the great thing about Webex is it punches through firewalls in schools. It's old and it's flabby. Sorry, I mean it's mature. This means it's not going to fall over. Unfortunately, all the sample code is written in PHP and the documentation is as good as useless. However, you can actually make it work. Look at this thing on the right hand side here. That's what it looks like. This is not a modern web app. So we took this code, as you can see, perfectly nice and clean as PHP is always, and we turned it into something a little bit nicer. Now that was actually quite easy. It's not that hard to convert code from one language to another. The problem is with Webex itself. They have a method for example called getRecordingLink. Now do you think getRecordingLink gets the link to the recording? Or does it get a link to a web page that opens up an iframe in another page, then sets a token to that web page, redirects itself, and then downloads the link to the file? Yes, it's the latter. So we thought we had to go through this misery, why should anyone else? So the company for which I work that developed this, we thought, yep, we'll release it, let's everyone else see what we're doing. So we write the code and then we realise we've got to release it. So we had to go through and clear out the comments. Not the profanity that you're probably expecting to be. That is the one language we all understand. But the comments that say, if you pass this information into the method, you get this output. That's fine internally, but we've got kids' details in here. Don't mind if a kid's talking to a tutor, we don't want the kid's data in there. They email their school or anything else. So we had to clear that out. We had to clear the code of little bits of junk and crap that were in there. Not that there were many. We had to clean the configuration. This was part of an app. Now it's part of a gem, so we had to move the configuration from where we had it in the settings jamming to be able to accept it in the gems through the YAML, and that's what the code looks like. Renaming things. As I said, we're about tutors and students. This is not a general approach. No one else has got an app with tutors and students necessarily. So we had to change it to attendee and host, which makes our code more complicated, but the gem easier to get. Documentation. Yeah, we had to do some of that. Normally you could just search our code base to see how to use all the various methods, but we don't ship our code base out to the rest of the world, nor do we ship our programmers out to the rest of the world to help either. So I had to write documentation and all the legal rubbish that goes with it. And we stuck it into GitHub. We used GitLab internally, so instead of creating a direct branch between GitLab and GitHub, just in case some swear words got into the code base, we took it out separately, checked it again, and then committed it back. Not big things to do, but all necessary, unfortunately. It is a fairly defined API, Cisco haven't changed it much, so all we're going to be adding is new API calls as thing go forward, and that is pretty much it. As you can see, the GitHub account is up on the top. Yes, naturally we're hiring. There's a bag of cookies, fortune cookies, which are going around. Yeah, that's something my boss made me bring on the train. Most of them, there should be some left. If you're interested, ask that, but if you're interested about me, that's the one on the right where I talk mostly about computers, technology, and all the other fun stuff that we've done with this sort of thing. I mean, one of the things that's not really in here, but I find amusing, is the fact that by having this as a Ruby gem, I can actually know for sure whether the code or the API is broken, because if the code is using PHP and the system just breaks, I have no idea if the PHP is broken or the API is broken. At least if it's in Ruby, I've got a chance of knowing where the fault lies, and the fault lies not with me. So I think that's everything. I'm probably slightly in time, because I know I speak reasonably quick. I'm 36 seconds, so I've got time for 34 seconds. I say 32 seconds of questions. So any questions you can possibly ask in the next 28 seconds, I'm able to answer. But that's only if the answer takes less than 24 seconds, because obviously that would kind of negate the idea. I've probably won that joke into the ground by now, haven't I guys? Okay, I'll leave it there. Thank you all. My name is Andrew Faraday, and I am terrified sincerely. I have spent most of my five years of Ruby development in a state of abject fear, and I'd just like to share with you today why that is and why I believe this must be a universal experience for developers. Okay, firstly, I am not a ninja. I have never been a ninja. I don't dress all in black, usually. I don't carry deadly blades, and I don't have this magic ability to sneak into a company unnoticed and leave nothing behind but well-structured, maintainable code. I get noticed. I am not a guru. Now, deliberately left an image off this, but just think briefly how obnoxious this word is. It's like asking for a code Pope, or possibly Archbishop. Archbishop of a backbone J.S. wanted. He wouldn't do it. And I am not a unicorn, okay, in the slightest. I have the wrong number of legs, the wrong number of horns, and magical powers. And because I don't have this superhuman element to me, I am afraid, terrified of exciting opportunities. Partly because this is a stranger, someone with no business talking to me, saying, get excited, this is exciting! And that is frightening. If someone said that on the bus, I would change seats, you know, probably change buses. I mean a rocket to the sun, getting bundled on a rocket fired into the sun, and really exciting, it doesn't mean I want to take that opportunity. Recruiters aside, there are reasons why I am terrified as a developer. And the first one is simple, that learning to code is hard. I'm mostly self-taught, and I started quite late. This means that I spent a lot of time looking at errors like that, or the Ruby 1.9 errors, which are much more complicated and baffling. Googling them, finding the explanations, not understanding the explanations, and not getting it. And this means, of course now I understand this better, which means that I have a comfort zone which includes these errors, includes regular procedures, things I do all the time, and so I spend very little time doing the things I'm comfortable with. Instead I spend all my time working out unexpected consequences, things that are broken when you didn't expect them to break, and everything I do is an unknown, scary zone. Comfort zone gets smaller, scary zone gets massive! And that's difficult. I now know SQL, but three years ago when I started my current job, I thought I have active record, I don't need to know it. I now know better, but there is a problem with frameworks like Rails that mean you don't have to learn stuff you need to learn. Another example, JavaScript. There was a point where I thought RJS was enough, and that's scary to admit, to be honest with you. But when you look at JavaScript examples, you get stuff that's compressed and you can't possibly read, and that's scary. And it's very hard to sort of start to get into that. And I have until very recently been very scared of RJS, which is, and always has been, ASCII vomit. Okay, so I spent a lot of time scared, and I'll admit that, fair enough. But there is solutions, okay? And the worst one is to learn everything on the job, especially when you have another solution, like some of the Rails solutions that mean you don't have to learn RJS, they may or may not be the best answers. So the way to sort of challenge this and choose the better solutions in a working environment is to work outside of it, and make something you really want to make. Now I'm going to introduce an idea to you of OSS Wednesday. You'll notice every Wednesday this year, so far. I have managed to make some commits, and I've been working on things mostly that I quite like doing, and making apps. Most recent one is something called Smith Music, which is a design-style interface, which means I need to learn RJS to work out what things are, and has an output in a musical form from the JavaScript Web Audio API, which means I've had to learn classes, but not classes in JavaScript. I still think of them as classes, but most of them are functions. Point is, you know, I'm making something I want to make, which means there is no deadline, there's nobody pushing me to do it, and I'm learning to do something. There's something awesome at the end, of course, and, you know, that's really been a drive for me to learn stuff that I don't want to learn. It's nice. So just to recap, there's no shame in being scared as a developer. We are all terrified all the time. We must be. Face your fears, actually challenge them, and learn stuff you don't want to learn. Make something you want to make. You know, it might be something artsy, it might be a little game, it might be a giant indestructible robot that can do all your stuff, right, and develop. Not just software, but develop yourself. And that's all I had to say today. Thank you very much. Give you an introduction, have an applause, and if we work, we're working. This is Xavier Riley. No, no, stop tapping. So why do you think I should work for the National Security Agency? Are you working on the cutting edge? Do you expose the kind of technology that you wouldn't see anywhere else because we've classified it? Can I see it? The question isn't, I'm trying to say the question is, why should you? Cross a bug that I cannot cope, but admire. I forget to eat. I have trouble sleeping. It's an adventure. Bugs like these consume me. Exciting, it's stimulating. And when I figure out the devious ways in which the causing the system to fail, feel, victory. So this talk is not a lecture. Hello everybody. I'm kind of upset I've got to follow that one, but here we go. So this happens. At the end of last year, during RubyConf, during his keynote, Matt's talked about adding static typing to Ruby, and in particular he talked about soft typing. And he referenced a couple of papers, including this one by Robert Cartwright and Mike Fagan. Now, I'm not going to talk about soft typing today because it's much too hard. I'm going to look at a more basic question, which is how do you read the paper? You might be thinking, this is easy, look at the words because that's how I'm reading words. And when you start doing that, it's fine, but then you start to find things like this, and then things like this, and then this, and it just gets worse and worse, and after a little while you realize you're looking at stuff, but you have no idea what's going on. Your options. Well I guess the first thing you could do here is you could just give up. You could think this is too hard, I've got better things to do, or maybe you think this is computer science, it's not for me, I'm a Ruby developer. Now that's perfectly fine, and I'm not judging you on that, it's a perfectly valid response. But maybe some of you think, you know this is maybe important, this is in the keynote, if I want to keep going, what are my options if I actually want to persevere here? So we come back to this question of how do you read the paper? I want to share some tips that I've got from my attempts to read the paper, and I hope to help you too if you're interested. The first tip I've got is don't try and read it all on one go. The paper is like 15 pages long, you might think, I'll read this in the afternoon. No, that's not going to work. It's this great quote from Michael Robert Bernstein where he says, to read a paper means to have a relationship with it over a long period of time. So be prepared to spend weeks or months or perhaps even years if you want to get the most from this paper. My second tip is learn the pronunciation. Now this is a little bit weird, but when I see something like this, my brain goes, I don't understand, and just skips over it. But if you learn to say it out loud, it actually helps you understand what's going on. Now I'm guessing you know how to pronounce A already, and the second character is a little bit weird, this thing, but you can pronounce this as implies. And then this thing at the end, well that's just the Greek letter sigma. And then we've got this cull on in here, and actually the paper explains this. It says equal and sigma is E has type sigma, so we can say has type. And now when we see something like this, we can read it out as A implies that E1 has type sigma. And we're not done yet, but we're much closer to being able to understand it. My next tip, probably the most important one, is don't try and do this on your own. Form a study group, find people who are like-minded. Get together once a week or however regularly you want to do it, and talk about the paper, talk about what you understood, and talk about the things you didn't understand. The next tip is by far the hardest one to do. This is to learn related subjects. So this paper was not created in the vacuum. There's a whole world of other research that's gone into this. Unfortunately, if you want to understand the paper, you have to understand some of these things as well. Now there are a couple of things we need to know a little bit about. You need to know a little bit of scheme or any other list. We need to know a little bit of lambda calculus if you want to read this paper. But luckily it's not very much, but a scheme, all you really need to do is be able to read an S expression, or ideally understand how conditionals work. But that's all you need to know. Lambda calculus, likewise, all you need to know is this is a function definition, and it helps if you understand the difference between free variables and bound variables. But that's all you need to know. I'm much worse. You need to know quite a lot about type inference. And in particular, the paper doesn't go into much detail. It assumes you know quite a lot about Hindley Milner type inference. Now you might see this referred to as Hindley Milner. Occasionally it's De Mas Milner. Occasionally it's De Mas Hindley Milner. Occasionally it's Pew Pew, Barney McGregor, Cuthbert Diddle Milner. And because that's not enough names, also it's algorithm W. You need to understand this quite well before you can hope to get anything out of the soft type in paper. And you think maybe this sounds a little bit daunting. And that's because it is daunting. And it is actually pretty difficult. So perhaps you're thinking, well, why bother? Well, one good reason is it will make you a better programmer. Now this is a 100% true fact that I've just totally made up. But it feels kind of true to me. I think that by learning these things you're not going to get worse as a programmer. But the better reason is that this might become part of the future of Ruby. So if you want to understand Ruby in the future, but perhaps more importantly, if you want to influence the direction it's taking, then learning how to read soft typing is going to help. But the most important reason for me is because learning is just inherently good. If you spend the time learning these things, you're going to grow as a person. So I'll tweet this link later, but I created lots of references for people who are interested in reading the paper. But thank you much for listening. OK, so hello everyone. I think it's been an exciting day today. I think the presentation that we just had was related to mainly how to read the paper. And then I think for those who are learning, I think it's good to start with an article, which is a really small piece of code. So in Hacker News there was a piece of code that actually was quite interesting. It's mainly used for companies launching their products and their companies themselves. And then it's a pre-launcher open source project so we can have a look at the code. And it's mainly used to get 100k users in one week. That was in the US in the Hacker News environment. And then we have tested here. And then I think it's a nice piece of code that I want to share with you. I was expecting that the five minutes would be good for us to have a look. So mainly what we want to create is this landing page here. So this is an example. What we want is a very snappy introduction to your products. You don't need to show what you need to show the benefits. And then you have to have these sign-up elements, which are the main function is to capture the emails. I think what we have here is really a controller, right? Which has a very limited number of actions. So the new action mainly understands where you are coming from a mobile device or a web server or a web browser from a desktop. Then we have to also take into consideration the IP address where it is coming from so that we are giving prices based on the number of referrals that each user is producing. So we need to follow the IP addresses. So that's also built in. We have also, we are handling cookies to know as well who is visiting the page. We have referral codes. That means when someone signs into the project, then you will receive an email. Through that email you can invite all the users. And then the system generates more emails to those that you are inviting. And there is a hashtag which allows you to follow all the three of users that you are inviting. So there is then a pricing schema that comes into place. So the system follows that as well. And then it sends reminders to make sure that you are actively inviting new users and it's reminding you what prices you are winning. And yes, I think there is a... We have as well, for example, linked these to MailChimp and Mandril. So actually you can make the templates through an editor. But in the one that is available online, you can basically write the code here for the HTML for different templates. It has the referral templates as well. So it's basically a nice little project that you can launch in Heroku. And it will work for you. So I think that's great. I think I'm doing it perfect on time. I think I have one more minute. But I don't know if I can answer some questions of someone. Or are we not? Then I think we can then go for lunch. Okay, thank you.