 So, Arcamp, it's the birthplace of every thing and also Rosconnf is one of them. You all go to conferences and you see all those projects and you think, hey, this is a great project. I want to contribute and you might open the GitHub page and you see that maybe it takes a little longer to get into the project and you think, oh, I'm going to do this after the boat party. And that's where Rosconnf comes in. Rosconnf is a free event that provides space for people who want to go and contribute to a project. It's 100% free. The only thing we ask for is a small deposit that you get back when you attend the event. So what's the concept? We invite five Ruby open source projects and they're maintainers. Each maintainer gets about 15 minutes explaining what the project is about, how you get started, what's the workflow of the project and after all has been done, 60 attendees are there that can choose a project and talk to the maintainers and start contributing. We also already did one in Vienna. Come on. We already did one in Vienna with Exorcism, Reek, RVM, diaspora and Yaks. It was, in a word, just amazing. People contributed and Catherine Owens said, Rosconnf was brilliant, 28 pull requests from nine different people, several bug fixes, lots of great improvements to documentation, refactoring, fixes to configuration and the setup process and a commit that made Travis build much faster. So with that feedback, we thought, okay, we need to do another one and we did. Last week and in Berlin with projects like Ruby, Ruby object mapper, bundler, speaker in and panamax and again, super happy contributors and maintainers making a selfie with a selfie stick. So Zachary told us, we had a strong team with contributors from a variety of backgrounds all working on something received three patches until one bug fix, one doc patch and one new feature with one more doc patch coming soon, I couldn't be happier. One of our attendees tweeted and this is actually one of my favorite tweets, events like Rosconnf are definitely needed, that's open source in its purest form, huge thank you to the organizers and sponsors, well done and I say you're welcome because it's awesome to do these events and so we decided to announce that day again that we are doing another one in London. It's going to happen in spring 2016 because you can only do a few events a year, otherwise you burn out and when I say we, I have amazing friends, one of which you might know already and we try to provide a framework for others as well soon to do these events locally and invite contributors to their city and bring them there, help them find sponsors and if you think now, oh wow, I want to jump on and help you guys and find sponsors or go ahead and suggest a project that we should approach or try to find core contributor that is willing to come to London, then go ahead, go to our site, follow us on Twitter, sign up for our mailing list and we will welcome you with open arms and I say thank you that's it. Awesome, thank you. I was also, Roscoff fell in, it was fantastic and I managed to remove 13 lines from bundler so there's now less bundler in the world, I think that's a good thing. Next up we've got PJ, once you get up on screen, that time it will start, the mic already works, that's the beginning, am I getting there, yeah here we are, okay one second, okay, hello everybody, my name is Pieter Jan, I'm the founder of Kampadmin, we are kind of a booking.com for people who organize holidays for children, so sportcams, languagecams, whatever, today I'm not here to talk about that but I am here to talk about children, maybe some of you know Coder Dojo, it's an initiative which I joined last year, which I'm really fond of, basically we help children to get in touch with technology, more specifically programming, that they just do not use technology but it can also create it in a super super fun way and the goal of this lightning talk is to get you a little bit enthusiastic to maybe also join in a local Coder Dojo around you to help kids discover technology and so how do we do it, mostly we use scratch which is a language developed by MIT and it's, as you will see soon, in the live demo, so let's pray to the demo gods again, it's just drag and drop, I'm sorry to say compared to the Ruby game talk that was given, it's a little bit easier, it should also be because the kids are from 7 to 14 and it's really incredible what the kids, they come in in a session, so they come normally once a month, they have an idea, the boys have an idea that they want to shoot aliens, girls have also very cool ideas but it's mostly involved with ponies and stuff, but again, very cool and it's incredible what they can realize, so okay, let me quickly show you some stuff, so yeah, we're ARCAM, so I had to use a pirate of course, so here you see, sorry, a pirate in the screen and yeah, it's big enough, I hope, I will just start to drag in some blocks and it will just start living by itself, so let's create a loop, like forever do something, move for example, move, maybe not 10, but five steps, I can immediately get feedback, okay, it's already working, oh, but yeah, pirate is gone, this is maybe not a goal, let's add something new, so this is also again super simple, and you see the programs start responding immediately, just bounce, okay, nice, but I think we can do better, right, okay, so let's continue, let's maybe try to get some input from our computer, like sound, so let's change the height of the guy here, of the pirate to, okay, now I will do some tricky stuff, but it's not so complex, because I want to boost the loudness, so you see here, you see me talking, you see the loudness already very changing, maybe I want to boost a little bit, so it's here in, no, it's in sensing, and here it's loudness, so I will boost it a little bit, like times 10, and this is all not important, okay, let's try it, can you make some noise, super, but that's still not enough, of course, okay, now I have to stop talking, let's also maybe draw some stuff on the screen, this is called like a pen, you can just say pen down, and maybe to spice it up a little bit, let's change the pen color by five, okay, let's continue, I can say something, that's working cool, and now a last thing, let us try to go to other destinations, not only the Caribbean, but also other spots, so here, that was my cheat sheet, it's again in operators, when for example, what is it, no, sorry, in sensing, when loudness is bigger than, I'm not sure how loud you can scream, but let's say maybe 20, I know, if loudness, and then we're going to change the looks, which is here, should see the next backup, all right, let's see, and then maybe so that it doesn't go too quickly, events, control, wait one second, okay, so we'll shut up, and let's try to go to new destinations now, okay, I think I made my point, so if you are enthusiastic about this, can you imagine what kits are, that are 7 to 12, so get involved into Coder Dojo, and Inspired Kits to become just like us, super awesome rum drinking programmers, okay, thank you, thank you, up next we've got Sonya to talk about Ruby issues, all right, cool, so I came down here to tell you that it is the 2nd of October, it's Friday at 5 p.m., and the Ruby community has 239,560 issues, and with that I mean open issues on GitHub, so maybe that's good news, because I've been told developers like to solve issues and problems, but I don't know much about that because I'm a designer, and that all changed though, because I walked into a Rails Girls workshop earlier this year in March, and that was the first time I actually got to know the command line, and Ruby, and a lot of supportive and helpful friends who support me when learning to code. I also met my current employer, and something that has happened quite recently is that I'm going to Texas to be speaking at RubyConf, and that's just mind-blowing, so if you have a foundation or an initiative like the Rails Girls, that's something to support, but anyway, so the point really was to start learning coding, and lots of people tell me to just get on GitHub and contribute to a project that you like, but going on GitHub, I still didn't know really where to start, so I'm trying to solve the problem of finding problems first, and with that, it's an amazing gift, isn't it? I want to introduce Ruby issues, which is a mailing list that we send out twice a month, and it's a curated list of open source issues. The way we find issues is basically me and my colleagues sitting down reading GitHub and making an estimation on which is an interesting issue. What we also do is we get in touch with maintainers of popular repositories and see if they have anything that they want to promote, so in that way, we can make sure they actually respond to your pull request. So what's been happening is there's a lot of bug fixes, little zombie links that have been added to a repository. I think there's a lot of doc translations that have been happening in the Synod products, for example. Something that I try is sometimes have a theme to Ruby issues, so we send out one that was documentation only and I'm more of a dog person anyway. What I'd like to see is that to continue, but I'd love to see if somebody picks on a more elaborate or sophisticated issue as well. Another thing that happened is that two people sat down at a Eurocamp in Berlin actually and worked on an issue that we promoted on the mailing list and that's just amazing because I know when we get together at events, that's the best time to actually hack on something and that's why I'm a big massive fan of Rosconn. We should all go to London when it happens and we actually send out the last mailing list was about Rosconn. So if you want to know what issues have been tackled there, that's a good archive to look at. So I'm in a very unique position because my work here is a sponsored one that means I get money for actually sitting down and reading GitHub and I know that's a very unique kind of situation and I'm very humbled by it as well. But until we figure out how to make open source work kind of sustainable for everybody, I think it would be nice to help each other out with the software that we use every day like Bundler and the other ones. And Bundler and Bundler. All right. So on that note, I'd like to hear about your issues. I like feedback thoughts, anything like that. I'd also like to see more subscribers but more importantly, I'd like to see the number of open issues go down and since I gave this talk at Rosconn last week, there's actually a thousand more open issues on GitHub. So that's all I have to say for today. I'm donating my last minute to Annika who's coming up next. Go on. Hi. Hi, I'm Annika. I love music. That's me and my mom. And I want to show you how you can write music in just five minutes in Ruby and disclaimer. I'm super nervous. I've never done this ever before. Live music, coding. I've never done live coding. I'm not even a programmer. So thank you. So I wanted to share with you what I've been doing in the last weeks. I've been playing around with this program called Sonic Pi. It's amazing. And it's open source. You can download it. It was written to teach kids how to program and I got super hooked. So let's see that we can get started with that. I hope you can see something. Okay. So that's a program. You can just start typing stuff and the notes here have numbers and I'm going to have the volume down a little bit. Oh no. There is no sound. Yeah, the volume is on. It should work. Oh, it is. Did you hear that? That's how you write music. Okay. Maybe try again. No, it's not. But now I hear something. Hannes, should we try again? Oops. What was the timer? We did the check. We had this working. Actually, it's output headphones. That's right. Never do live coding ever. Okay. Then we're going to try with the mic. Maybe you can... It's here. Okay. So you can do stuff like this. I'm not going to explain so much anymore. So you can also have other stuff here. For example, it's all in the program. Do you hear that? Okay. Let's do a loop. This one works. Okay. So let's have even more loops. Actually, that's why lightning talks are always like a cook show. So I prepare something for you. Demo gods. So you see, I've added some more notes. I have some pauses. I have some samples. The program is actually only three samples. And we can just actually try and get this started and play around with music. So this is why I like Sonic Pi so much, because you can just get started. You can see how you can write music in just five minutes. And that was actually just the tip of the iceberg of what you can do. So what I want to say is just get the program. Follow me on Code Plus Berlin. Get started. You can make music. You can make art in five minutes. So let's go play. Thank you. Thank you, Annika. That was wonderful anyway. I need to play with that. I need to play with that. Next up, we've got Christoph again. Taking up all the lightning spots. Hi again. So it's kind of little sequel to Jason Stoke. I like to trace a lot of things in my code. And because yeah, we read far more code than we write. For instance, when you want to fix a bug or just discover some part of library like open URI in Ruby, you don't want, you know, if you look at the total of number of lines in open URI, it's like 4,000 lines. You don't want to read everything. So what you can do is to use TracePoint API that was introduced in Ruby 2.0. And I can show you quickly how does it work. So you can create a TracePoint where we'll, and you will listen to different events like here, call, line, and return. So the event line occurs when a line is executed. The call occurs when a method is called and return occurs when you return from a method. And then you can do some fancy stuff in order to build the graph of all the calls of a specific piece of code. So I show you how does it work. So here you have your specific case that you want to trace. You want to have all the calls that occurs behind that open of URL. So you trace that, and then we will print the graph. So it looks like that. And so you have a big tree of all the calls that occur behind opening URL. So now you have a path to read your code. And you can follow all those sequences to read more specific part of your code and not read everything. Another case I like to do that is when you discover a project and you try to understand why a test fails or what happens behind the hood. You can, in a gem or whatever, just trace what happens in that test. And then you run the test and you will get some insight about what's happening behind the test. So it's a really great context to read only the code that matters to your use case. And I've wrapped everything into gem which is called trace calls. So yeah, it's just the beginning. If you like it, please report feedback, bugs or whatever if you have some ideas. And yeah, I hope it would be useful for you also. Thanks. Thank you, Kristal. And now we have Joran. And I have to do the timing. Oh God. You can do your own timing from there. Yeah, I'm timing. So let's just remove the timer. And I've got all the time in the world to talk about a thing that Kristof was talking about yesterday, like a part of the Ruby Belgium thing we started. It's the first thing they started was the Ruby camp. And the first one was in the last weekend, I think, of August. And it was just 25 for some complete strangers coming together and doing a lot of stuff together, which was the main meaning about it. So we went to a little village in the balloon part near Liesge. It was a really great place except for no Wi-Fi, but okay. If you can stay in a castle like this, it's okay. You don't have Wi-Fi. So we managed to do all the things we wanted to do. So the cool thing about it was that we organized it together. So it was just a GitHub repo on GitHub. And everybody was sending pull requests on where they just how to see who was driving with who, in which room you wanted to sleep, on the menu we discussed together. And it was just all on GitHub pull requests on issues. And it was really nice to just starting to know each other upfront by looking at the suggestions everybody was making on which talks we might give and stuff like that. So if you want to see what we're all done, go to GitHub, burq-be and see what we've done. So there were burgers just to give an idea on what we've done and what we've eaten and to make you want to come the next time. So we had delicious burgers with special ruby sauce that Christophe made. So he's sharing the recipe, I think. It needs to be shared. We've got it together on different projects. So some people learned about Lotus. Some people played with React. We just helped somebody with his own personal problems in his application. And yeah, so people were helping. People were learning. We switched roles and stuff like that. So that was a very nice part. We played some really cool games like Werewolf. We played Cards Against Humanity. That's not suited for life. That's really nice but really dangerous thing to play. We had some little lightning talks. So people got to show off things and tell us what they were doing. We actually did some sports. So a couple of us went running together. So if you like running, we found some beautiful place to run for an hour. And we played badminton, volleyball, just enjoy the sun. It's rare in Belgium. So if we can, we need to go outside. We cooked together. So you can see we did a lot of things together. That was the main reason that it was made awesome. We watched screen costs together. So join us next time. This was the small group that was participating this time. We just had a lot of fun. And if I go to brog.be, I see a lot of awesome faces that once joined up as part of our Belgian community. So hopefully I can see a lot of these faces on the next one. Yes, winter is coming. So there's already somebody working on the next one. So if you want to know about it, just join the Slack, join GitHub, follow us on Twitter. And maybe there is some little surprise like this next time again. So I hope that the people from Belgium now know that this exists and join next time. And if you're not from Belgium, you're welcome as well. Or you're welcome to create a Ruby camp in your country, in your local city. Just make people excited about joining together for a weekend, go together, learn from each other and become better programmers and make some new friends like I did. Thank you. Thank you. That looked like a lot of fun. And next up, just plugging in right now, we have Sebastian. So my name is Sebastian. I'm a sender dot on Twitter and this talk very much is a result of yesterday evening, some conversations I had and probably a few Belgian beers. And so I want to talk about three things and I will start with architecture actually. So when coming back from dinner, I was talking with Rachel, who gives a talk later on about architecture of buildings, not about software. And we were talking about that architecture when we passed by this church. That's Santh Nicholas. It's about a five minute walk in this direction over here. Now is that good architecture? Is that a good design? And I think we all agree the answer is easy. It's certainly not. As at least not if you are the one who pays the bills for heating this. They have like 25, 30 meters high walls and a huge window, certainly a single glass, and we'll have an enormous bill every end of the month. So looking at it from this perspective, it's certainly not a good design. And we might ask, why is it that way? And of course, I'm teasing this a bit. So when this church was built, nobody cared about energy efficiency. That is back from the time of Gothic architecture and the whole language of Gothic architecture is meant to show you that you're really small, compared to God, compared to the church, compared to everything else out there. And that's the huge walls that you see, the huge domes, the big windows. So that's all communicating you're small. And if you go inside there, you immediately feel like a half a meter smaller because everything is so big and the light is coming from all sides. And this, well, you understand that this spaghetti month or God actually is a very powerful guy, apparently. So from that perspective, of course, it's good design, because that was what it's meant to communicate. Now we get a bit more serious. We go to toilets, or more specifically down into the basement to the sinks. And some people might have had the same experience like I yesterday, when in the morning I want to wash my hands down there and there's no water coming. And I tried finding the sensor, trying to find buttons, pushing the water tap and no success. So that was rather frustrating. I was really getting angry and thought, well, that's a really bad design. I can't even get the water flowing here. Of course, sooner or later, we all found this button on the floor where you can step on and then the water starts. And later in the evening in this restaurant, we had a similar setup. So again, a button in the floor. And now I'm comfortable with that. I know how it works. And apparently that's in Belgium, that's very popular. So I didn't see this in any other country. But here it seems to be normal. And if you think about why is it this way, of course, it's obvious because it has a lot of advantages. You don't have to touch anything. You don't need any electronics. It's very easy. It's mechanic. Probably doesn't break as often as other things, at least not as often as sensors and electronic. And at least if you've been to R-Camp once, then in all of Belgium, you can finally wash your head. So once you understand the concept and you used it, it's actually a pretty good design and probably superior to most of the stuff that we have in airports or things like this. Which brings me to the third part, talking about Ruby code. And you've all seen this snippet of code. It's from the presentation yesterday morning, or more specifically from the Aspect Support Library. And if I would find that code in my code base, I would probably stop and think, oh, that looks really complicated, considering that it's just taking a method from an object. And I just hope that at that point I would stop and think, well, why is it that way? We've all seen yesterday in this talk that there are very good reasons that this code is exactly the way it is. And probably it's the easiest solution considering they have a lot of edge cases, a lot of different libraries to support. And that's the main point I'm heading for. So when I see legacy code or when I look at code somebody else wrote, or I wrote last year, and I think, no, that's really ugly. I wish I would stop more often and think about, well, why is it this way? Or to put it in different words, in what context was this the right solution? Because there probably was a context when this was the simplest and the best solution. And this will help us make much better decisions. And I want to end with a quote from Jerry Weinberg, who wrote a lot of really cool books, The Rule of Three. If you haven't thought of three possibilities of three possible solutions, you haven't thought enough. Thanks. Great lesson there. Thank you. And now for our last lightning talk of the session. We've got Jason back up. Thank you all for letting me come talk to you for a moment or two more. Maybe five minutes. I'll see here. All right. Can everybody read that relatively well? Yeah? All right. So I am a contributor on the Shoes project. Shoes is a GUI library for Ruby. And I've given some presentations about it in more depth. If you want to go look those up and find out more about it. But what I wanted to do today was I wanted to show you a Shoes application being written from scratch right here in five minutes or less. And what I want you to do is I want you to imagine the possibilities of what you could do with this with a child or with a beginner, somebody new to programming. I'm so excited to see Gosu in scratch and the things you can do there. Shoes is another great tool that you can use to teach people programming. So I've got a little launcher application here. Let me see. So when I hit my button here, it's going to run my code that I've got over here because it's running on JRuby so it's a little slow. So the simplest possible Shoes app, we're going to give it a width and we're going to give it a height. All right. And we run it. And it works. There's another window. Okay. That's not actually all that I've got. There's a few more things that we can do. So we can use a variety of different shapes. So we're going to draw an oval and we give it the left and the top, the coordinate system from Gosu is the same with the upper left corner being zero, zero. And we're going to say that that's 150 and 150. And we're going to fill it with blue. All right. So that doesn't look much like a rocket ship yet. And that's what I want to make. I want to make a rocket ship. So we're going to carry on from there. Let's make a rectangle. We're going to put the left at 150. So it matches there. The top I think will be at 100. We'll make it 150 wide. So it'll be a third of our thing. And then give it some height and we'll fill it with white. Not quite on. That should have been 150. Much better. That's starting to look a little more like a rocket. Yeah. Yes. Okay. All right. Okay. Rockets have some decoration sometimes. There's a little bit of a stripe, right? You've seen that on some of them. So let's give it a little bit there. We'll fill that with black. All right. Nope. Wrong. Oh, 400. Let's put that at 400. Make it 75 wide and 50 tall. Yeah. That looks a little bit more like it. All right. Let's give it some fins. So we're going to start from 100. We're going to put that at about 500. And we'll make it 250 wide and 50 tall. And we're going to make those fins red. Make them nice and flashy. All right. But this is kind of cool. Static drawing is a great way to go with kids building up different shapes that you can do things. But that's not as interesting as it could be. We want to make some things move. We want some animation. So what we're going to say is that every 10th of a second, let's add another rectangle. And we're going to mix this up. We're going to use Ruby's randomization to give us some interest in how this is going to get drawn. So we're going to say random from 150 to 300 for the placement. So it'll be at a different spot across there. We'll start right at the bottom of the rocket, which is at 550. And then we're going to make those a little bit of variation in the width. And for the height, we'll have a little more variation. We'll go from 50 to maybe 250. And then we'll fill those with red and then also make the outline red. And now we start getting a little bit of motion there, right? Okay. That's not as dramatic as it could be. Let's change up the color. Let's get some orange, yellow, and pink. We'll sample those. And let's replace our red with color there. All right. Okay. Looking a little better. And let's get that faster. And let's do more lines. All right. Now that looks more like a rocket ship to me. All right. So imagine sitting down with a kid. They want to draw a picture. You figure out how to break it down. It teaches them algorithmic thought. You teach them coordinates. You teach them math. This is an awesome tool for you to be able to do it. And I hope you'll help out pick up shoes and try it. Thank you. Thank you very much, Jason. Thank you. In fact, to all of our speakers in this Lightning Talk session, let's give them one more round of applause.