 Yeah, I'm Nick, I'm a technical evangelist at Microsoft. You may be wondering, what's this Microsoft guy doing here? Like, ooh, audience. Evil. Rest assured, I have no slides. Purity demos. So what am I doing here? I wanna give you a quick demo on Azure or Azure or whatever way you wanna pronounce it. It's basically our public cloud platform. So you know cloud computing? It's about having this anytime, anywhere access to this massive amounts of computing resources. Anytime you want a server, you want a million servers, you can get them instantly, at least that's the promise. Cloud computing, all of a sudden, you think about what virtual machines, right? We can do that. So what you see here is basically our Azure management portal. It's basically a portal anywhere accessible to any browser, not purely IE. So, rest assured. So we can create virtual machines, just do new, and we can do a quick create. This is a lightning session, so we're gonna go fast. So we give it a name, an old pirate tradition. We're gonna give it the ARRVM name, and lo and behold, what you're seeing here is Windows Server, but also we've got Linux, we've got Suze, we've got Ubuntu, we've got OpenLogic. So Linux running in Microsoft's data centers. Woo, talk about open. So we give it our password, our secret admin password, zooming out a bit, and then we can choose where do we wanna have this virtual machine running? It can be in the US, it could be in Europe, it could be in Asia, whatever, you have full control. So let's deploy one in Northern Europe, which in Microsoft terms is Amsterdam. So we're going to spin that up, and in about three to four minutes, we'll have a Linux box running within Azure on Microsoft's virtual machine environment supported by Microsoft, all for you. So just a matter of minutes, you have a Linux box, you can deploy your Ruby stuff on there, install your gems, whatever you want. You're up and running in a matter of minutes. Of course, you're a dev or a web dev. What do you wanna do? You wanna fiddle with servers, you wanna develop, I guess it's a pretty easy choice. You wanna develop, you wanna write Ruby or Rails or Ruby on Rails. So you wanna get going and developing. So you don't wanna spin up virtual machines, even if it takes just a few minutes to spin up a virtual machine, you need to configure it. You need to install web servers on it, whatever you name it, you need to configure that stuff before you can actually start developing. So what do we have for that? We basically have platform as a service. We're providing with a platform, a platform where you write code and you deploy your code on that platform. So how do we do that? Web developers, well, we're going to create a website. Again, pretty straightforward, clicking the new button and that website. We got a couple of ready-made application frameworks available for you. So you can spin up either just an empty slot for pushing your code in or you can just go and pick one, pick one application framework that exists and just install it. So let's be, again, somewhat open, not go for ASP.net, but maybe we can go for a Node.js empty site. Let's click Next. Give it a URL, any name. ARR web. We'll again deploy it in Northern Europe. Click on the big check mark and our website is being provisioned. I have one minute and six seconds. That site should be up and running, available to you to browse from your mobile phones or from your Mac machines before this talk ends. I solemnly swear. So it's creating right now. Well, that one is spinning up. Let me switch to, and there it is. It's up and running. You can browse to that one. Just ARR web, azurewebsites.net and you should be hitting that website. So talk about lightning deployment. So what can we do with that? So we now have a fully functioning website in there. Well, if all of you guys are hitting my website, maybe it's going to have, it's going to be struggling to hit all that load, to manage all that load. What we can do is we can basically scale that machine up into, for example, four machines or maybe six or 10 or maybe a hundred if we want to. Or we can just do it dynamically based on CPU. So we've got average CPU going beyond 80%. Well, we'll add a machine. It's going below 60% or taking away a machine. That's basically the power of cloud. Having that scalability available to you, developing rather than configuring servers and dealing with infrastructure. There you go. Where are my slides? Cool, thanks. Okay, and this talk is about half an hour. So let's see how it fits in five minutes. Hey, we are the code pattern ones. We are a Rails Code summer of code team of 2014. And this is our last day of our summer of code. And we want to talk about that. Yeah, this is us. I'm Ute and also Nerdcape on the web and I'm studying computer science. And I'm also a Rails Code spoiler organizer. My name is Magda, Magda from Twitter. I also Rails Code, a Berlin organizer, background in stakeholders and cultures at least. Yeah. So first we talked shortly about what the sum of Rails Code summer of code is. So it's a global fellowship program that aims at bringing more diversity into open source. It's the first thing and second is helping newcomers like us to get into programming field and helping to develop skills, not only technical ones, but other sorts like software during the project that we develop. Well, so this year, second edition of this program, it's 10 teams that have been chosen to work on an open source project for three months and we are paid to do that, which is really cool. And this is possible thanks to community actually, so thanks to you. So there are sponsors and there are individual donations. So for the next year, what you can remember to do is to, first of all, spread the word about it. Second of all, you can become a sponsor or a donator or you can become a coach. Or a coaching company. Yeah. And why this program is important. So basically, well, it's helped us a lot. We had a lot of fun, we learned a lot, and we did produce something that you can use. And we talk about it in a second. So this is our team behind us. We had two coaching companies. It's Askera from Berlin and also Fiber. And we had a lot of coaches that supported us in the last three months. And yeah, thanks. Anna is here. Anna, thank you. And yeah, and this is our project. Atarou, last week we released the first version on RubyGems, so you can download it. You can use it and you can give us contributions or issues, bug reports. Yeah, please do it. I mean, like the second release is on the way. Yeah. So, well, yeah. So what Atarou does, what it is. It's a documentation testing tool that reads your markdown files if it's written in GitHub-flavored markdown. And it has the code samples in these files. And yeah, you can run it from command line or from Travis. Yeah, we did plain Ruby and there's a lot of magic in there. We used something that you don't use like evil evil. And yeah, it's a lot of interesting things happening there. And so, Anna talked about Anima, like this gem, and actually what happened was that it was gemmed that we used to test Atarou against. And there was a bug that Atarou found. So you can see it really works. Yeah. And what's next? We are looking for a job, an internship, or junior developer, something like that. And we are keen on learning. And yeah, help us find a job and may the force be with you. And you can see through the code part advance or on GitHub the code part advance. And yeah, look at our code and say something to it. Thanks a lot. All right, I want to talk about a little gem we made. It's called Tabulator 2. It's for, it's to create actual index pages for lazy people. We, that is, there are three colleagues of mine, amongst them is Florian, who had done a lot of work on this. We are from Germany. And we brought you sauerkraut. By the way, she looks a little bit like the cat, doesn't she? Well, but anyway. What we are talking about is index pages. So the pretty normal index page, as you see it on the scaffold or whatever, is very much what you see on the left. It's just iterating. You're slim for brevity, but in principle, A-erbis looks just the same. You are iterating over the elements of what you want to show. And yeah, you are outputting the actual table. So if you're producing a index page like that, your product manager may come in and say, yeah, this is great. Just quickly add pagination, filtering, sorting, batch actions, and then you can go home. Probably this is the situation where you just decide to quit your job, one or the other way. This is strange because, well, everything in Active Record is so simple nowadays, even adequate, partly. For forms, simple form is so simple. All this routing is so simple. Everything is simple. But these tables are still somewhat annoying. Why? Well, it turns out that it's quite a hassle to put all the pieces together. There's nothing complicated about it, but it's so many different pieces, so yeah. But now we have Tabulator 2. We just have a quick look. What does a Tabulator index page look like? The index page itself is really just a table for customer, for example. The controller is just a tabulator for customer. And you have one additional file, which is the customer Tabulator data file, which just inherits from Tabulator data. And you're writing in the names of the columns you want to use in your table. You can specify how to search in the table, and you can get a lot of different options, I omitted most of them, but there are quite a lot of them. And this is what this table looks like now. So there's nothing else. There's no markup in the application itself. It's really just from the gem. And I'll just quickly switch to a live demo, probably. Oh yeah, this is cool. I have to turn around, this works quite well, I guess. So yeah, this is it. You have sorting, you have filtering, specified. I want to filter by first and last name, so Aaron and Gark, or Gark or whatever, are both met. You can do, well, actual filtering, for example, you can filter by balance from, well, whatever, minus 100 to 100, and so on. So this is all for free. No code required at all. No further code required. I'll just find the cursor. Here we go. Yeah. So what else is there? All the data is fetched via Ajax. So there's a lot of Ajax requests going on there. Just pages that you have seen already are being cached normally. You can specify special SQL for filtering and sorting and so on to prevent the N plus one case. You can even prevent the two N squared plus seven N case. By default, tables are stateful. So if you leave the index page in comeback later, you will be on the same page, same filtering. This is done with client-side storage. You can use infinite scrolling if you so wish. There are shortcuts for action buttons. I use that in the live demo, very simple. You can use it for static tables without Ajax. For example, if you know there will be only 10 or five or whatever items that you're about to list, you can use these. There is support for batch actions like you select a couple of rows and say delete or activate or whatever. And there's really a lot more. The documentation is well, sufficient. Just very briefly, how does it work? It can really just give a very rough concept, but you see, this is all the components. The renderer, there's another on the right for the details just if you care, just have a look. Now, developing with Stabilizer 2 is pretty fun because, yeah, you're buff, so this is it then. So, hi, I'm Greg, you already know me, and I am a nomadic programmer. Within the next five minutes, I want to share with you three lessons that I learned over the last nine months. Last nine months that I was constantly traveling, living in hostels and rented flats, and working as a freelance Ruby developer. So, the first lesson is about burnout, but to learn it, we need to go back in time. More than a year ago, I had a really nice job in a startup with really cool team that I could learn a lot, a lot. But suddenly, I stopped enjoying my work. And like, what do you do when you stop enjoying your work? Of course, you push harder, and when you see that it doesn't work, you push even harder. And then in the end, there's burnout. So, I was totally burned out. I didn't know what to do with myself. I didn't want to be developer anymore. I didn't want to do any programming anymore. And it led me to a conclusion that burnout totally sucks. Like, you shouldn't get burnout. It's much easier. And I truly believe it's much better to prevent it than recover from it. So, instead of pushing harder, you should take a break. You should go for a holiday. You should maybe, I don't know, you should try to do something else, get some hobby, whatever. Just do not allow yourself to get into a position that you're burned out. And what this situation led me to was something totally extreme. So, I quit my job. I bought the ticket to the farthest place on Earth, which, if you are in the middle of Europe, is New Zealand. I took my backpack and I just went there with basically no plan and no idea what I'm gonna do. So, then I left the plane in New Zealand and I said, okay, I'm in New Zealand. They've got Kiwis here. And, okay, let's see what I will do. I had just hostile booked for two nights. And then I learned a lot about fighting my fears. So, today we had really cool presentation about this impostor syndrome and about thinking that you can't do some things. And I learned a lot about it. I learned that if you leave your comfort zone and leave it far, far away, you're open to new ideas. You're open to fighting your fears. So, I am a man of many fears. And all of us are. All of you are scared of something. We just don't talk about it because we live in this culture that requires us to be strong and not to show our fears. One of my fears is that if I'm in a skyscraper, oh, a skyscraper. If I'm on a fifth floor on the balcony, I'm so afraid that I'll hold this rail because I'm afraid that I will fall. And if I swim and I'm swimming and everything is fine and then at some point, I think, hmm, let's see how deep it is. And when I realized that I cannot touch the ground with my feet, I panic. I suddenly panic. So these are my fears. And my fear was also like living somewhere far away from home. But step by step, I started fighting that. And today is day number 276 of my travel. I stayed in like, I don't know, 70 different places. All the time I'm changing places and I'm changing what I do. And I started fighting my fears. I jumped from this cliff and I took diving, scuba diving lessons and it led me to conclusion that I can do everything. Really, it's the first step that you make that opens to you lots of different possibilities. I did things I would never thought of doing if I stayed at home. Lesson number three, it's about working in the middle of nowhere. So as I started recovering, I started taking some small contracts and working as a freelancer. In the beginning, I was afraid that it will limit flexibility of my travel, you know, because I have to work, so I need the internet connection. And this photo was taken in the middle of Taiwan in the hostel where I had no hot water, where no one spoke English, only Chinese, and there was no Wi-Fi. But there was 3G coverage. So I was saved and for just $20, I had unlimited data for a whole month. So I was in this hostel with cold water, but I had TV series, so hey, I could work. So this taught me that I can work anywhere. I need internet connection, but it doesn't have to be fast. I just can download documentation and use it offline. And that's basically it. I can work anywhere I want. If you're curious and if you're interested in the topic or if you're traveling and you want to share your stories with me, I would be really happy to talk to all of you about traveling or working and being a nomadic programmer because this is something that all of you can do and it's super exciting. Thank you for listening. Enjoy the rest of the conference. Do you know what is it? Great, for those who don't know, it's Commodore 64, a computer, 8-bit computer that is not produced for 20 years. It has some great games, but I want to convince you today, I love Commodore 64, it was first computer I programmed on and I want to convince you that it's fun to program Commodore 64 right now and it's easier than ever before. So let's jump straight into assembly language. So here I have some listing of the code that I'll explain a bit later. If I compile it, no, this is the finished version. So if I compile this, then we have two top lines of code are animating and basically here's how it works. This is the main subroutine. First it fills the top line with letters, then there are two color cycle functions. The first one cycles colors in the first line, the second one is second line, then we add some delay and we jump back to this loop. Let me enlarge it, but that's not what I want to show you today. So let's first, let's remove this call from here and in the color cycle two, instead of returning from subroutine, let's jump into something called interrupt address. Then we will, in the main routine, we will hack this, so we will set the interrupt, don't worry, then we, so we take the address of color cycle method, we put this into something called interrupt vector, we have to do it byte by byte because that's the size of the register in Commodore 64. Then we return from interrupt and for now it should work as before. Okay, that works. But let me show you some magic. If we're, instead of looping in here, like jumping back to the loop, let's return from subroutine. So this is the last thing that we do in our program. So it will actually return from our program. If we compile it, now we see that the first line here is not animating anymore, but the second line still does and actually it runs in the background and it's 8-bit computer machine. So that's something that when I first discovered, make me fall in love with Commodore. And yeah, if that doesn't convince you, I don't know what would. Yeah, so if you want to know in detail how does it work exactly, follow this link, jump C64R, there is a like five, six minute video that shows in the detail what's happening there or just talk to me after lightning talks. Thanks. All right, I wanna talk to you about MySQL strict mode, which is something that I ran into as we were upgrading our Rails 3 application to Rails 4 at Harvest where I work with TJ. So MySQL strict mode or just one of the reason why Belgium beers have to be so strong. If you don't believe me, let's create a table as you do. There's nothing fancy about this table. It's a table of people. We each have a name, age, and a Boolean tracking whether they're a speaker, maybe at a conference. That defaults to false because most of us aren't the speakers, right? The query is okay, zeros are affected, all is good. Now, I do have to tell you, this is not a rainbow table, it's just a regular table, but still it will work for us. So let's insert some data into this table. We insert a person who has an age and we signify whether they're a speaker or not. And when we try to insert people that are missing either an age or a speaker, we get an error from the database. Totally regular, totally boring, totally everyday stuff. Let's convince ourselves Alice is 24 and she is a speaker at the conference. What happens if we try to update this data? We realize that we mistakenly gave Alice two years more than she is, so we just update her age and everything is fine. Then, for whatever reason, we try to set the age to null and we told our table this shouldn't happen and this is a database, but it doesn't complain, it says query okay, I changed the row for you. Then we try to do the same for a speaker and we just get query okay, even though we've explicitly said this field cannot be null and we've given it a default value. So what the hell? Alice now has age of zero and is not a speaker and we try to insert invalid values. So let's make this better. There's this thing called SQL mode in MySQL and one of the modes is strict all tables and that really means behave like any sane normal RDBMS would. So if you do this and you attempt the queries before, just like you expect, you'll get reasonable error messages and your updates will not invalidate your data because you took so much care to structure it properly. So how does this work in Ruby? Well, the SQL library has a mode, it has an option called SQL mode and it doesn't give you a default. Active record three, however, knows nothing about MySQL, the MySQL adapter in active record three. So you have to ensure that query that I gave you by yourself and you can do it either for the session, which means the current connection or globally, which will apply to any new connections that you create from then on. And active record four has an option which is called strict and it defaults to true. So if you're upgrading your application from three to four and all of a sudden you get a bunch of errors like this, that might be why. Great, we've solved the problem. But we're Ruby-ish here and we're always on the cutting edge. So I wanna give you a brief update on something I knew that I've been working on, which is how this applies to the newly announced pooling. And you know, pool record allows you to freely object space dump, which Aaron thankfully introduced us to today in my pool. So that is good. You can also use the Poo Tracer pile, the equivalent of gem in this new language and to track how many poos you allocate. But whatever you do, please measure, measure, measure your food. Thank you. So wake me up before you go-go. Let's talk about asynchronous processing for fun times. So my friends and I have this problem where we're like, hey, let's play some games and they're like, yeah, totally, let's do it. We hop on a team speak, and then we get on there and like, so what do we wanna play? And we all use Steam and we're like, all right. We start listing off the games we have in our libraries and we're like, I don't wanna play company heroes right now. And then we're like, you know what? Why don't we like look into using Steam and actually like solving this problem ourselves? So what we can do is we can use a REST, like we can use REST Client and NoCo Geary, pull down the page from Steam and then do some parsing. What's really cool is doing this is blocking IO and blocking IO is really awesome. It's really fast, especially whenever I wanna download hundreds of files. So you know, we have a bit of a problem here. It takes a little while to download. Is there maybe something we can do to improve this little bit? So we could use plain old Ruby threads or we could use celluloid. If we really wanted to go pretty extreme, we could use like a backgrounding system like Sidekick or Sucker Punch. But what if we could take something that is in this really neat little language that's come out and is like super popular and really awesome called Go. Go has this thing called, like they use this idea called Communicating Sequential Processes, which is in one thread, I do a bunch of stuff and then I tell another thread that, hey, here's some data and like you can work with this, but the problem is how do we get that data from our first thread over to the second thread? So we can do that using something called GoRoutines and channels. They are basically, a GoRoutine is another thread. Depending on the implementation, it might actually be a real thread or it's like a Go thread if you're using Go. And then the next thing is a channel which provides a pipeline where you can communicate between two threads. Similar to the Unicorn thing that was talked about yesterday, think of it, it's kind of like a pipe where you're pushing data onto it, but what's cool about a channel is you can control how many messages you can send on it at a time. And some Go programmer, I don't know, he's like apparently a big deal, said share information by communicating, not sharing state. So let's do that, but we wanna do it in Ruby, Ilya Grigorik a number of years ago wrote this gem called Agent, which you can include in your library and it does a bunch of fancy stuff and it gives you some extensions in the kernel that allow you to write code that looks like something you'd see in a language like Go. So first off, we wanna use channels. So what we're gonna do is we're gonna create that channel. Because we haven't specified the length, it's going to be an unbuffered channel. So I can push one message on it and then I'll block. So we'll go through all of our pages, fetch those pages and write them to that channel. Until someone reads from that channel that will be a blocking operation. And then in our extraction, we receive from the channel, we get two things back, we get the content of the channel and then whether the channel has any more data for us. If we're done, we just leave otherwise, we go in, create the document, extract it and do something with that data. The way we use GoRoutines in Agent is it's you just say go with a block. So I have my channel, I say go, do download pages and then go extract. And the nice thing about using GoRoutines is it allows you to write code that looks very sequential but it's actually asynchronous. So now that we've gone and done this, I'm able to download like my 200 games from Steam, extract the information because the Steam API doesn't let me know whether a game is multiplayer or not and then say, hey guys, these are the games I can play and then we decide to play Company of Heroes anyway. So thank you. My name's Chris Saunders and if you'd like, if you go to Bitly Steamy Gaming, you can see the application we've built and talk to me after if you'd like to see the code. It looks kinda nasty but it was a really fun little project. Thank you. When I first gave this talk, it was an hour. I'm not gonna put it in five minutes and I still don't know what the title should be. First I called it Hexagonal Rails. I had some issues in the reception. Then I changed the API driven development which was somewhat more friendly. Then I mentioned not the Rails way which some people might find problematic as well and then I kinda settled on the name command and query classes, not separation. But all in all, actually I'm just trying to attempt to get the highest amount of slides per second here. But really, really, it's an idea I've been working on for a few years and I'd like to know what you're thinking and at this point I have a bit of an imposter syndrome problem. So why this idea? I've been working for six years on the same thing. It's kinda like a big HTML monolith. It has lacking specs because I used to think I was an awesome developer who didn't need those. So regression's all over the place. New requirements come along. We need to build an API which there's less chances for you to then go and change that. We wanted to actually know what this app was doing, specifically the old code and overall have less regressions. Oh, should I start over? Okay, so I'll continue. So I had an idea. Let the API drive new development. Some rules in there. Future-focused, built how the application is going to be in the future, not how it is now or at least pretend it's like that. One endpoint has to be one class that encapsulates behavior and spec those. Then reuse those classes in the old controllers so we get our coverage up. Rinse and repeat until the entire application has been rewritten. Yeah. Yeah, correct, Ben. What does it look like? First, we have commands. Commands have a very clear name. Creates comment command. It's a pattern, yay. We do some BDD because there's an actor in there. It's cool. Here, it's in an old controller. There's a whole bunch of measures around there which is trying to build some HTML, but it fits, it works. And this is how a command looks like implemented. It does some validation if the call is correct. It does some authorization against the legacy authorization system, and it runs a bunch of actions in sequence. An action basically has to accept a context. The call on that, fun, fun. This is a somewhat more detailed one. There's more in there. Fun. Actions, yeah. Actions are a unit of change. They either change the context or change the system. They should be reusable, ideally, and be independent of any other actions. Queries, they look like this in the controller. They look very, very similar. They just don't change anything. This is how the base class of queries look like. It's a template pattern. It validates the query, again, sets up a runner, and then the runner runs the query. It's transparent. Why do we use runners? We both talk to Active Record and Elastics Thinking Sphinx and pretty soon Elastic Search to replace thinking Sphinx without the controllers or anything else having to change their behavior. And that's about it. If you'd like to talk about these ideas, I'm open for it. That was 31 slides, and I still have a minute, so I can take a picture. I said I would do that. Smile. Yeah, my talk is called Building Ruby User Group, but the increase suggested weaving a rug, which I think sounds better. So basically, my talk is about how to build a user group or beat Ruby, beat any other, and why you should do it. We're in Belgium now. Those of you not from here think this is a pretty small country. It's 30,000 square kilometers or like 11,000 squared freedom. There's 11 million people there, but I come from Slovenia, which is even smaller. We are like 20,000 square kilometers or like 7,000 squared freedom. There are just two million of us. And like in case you're wondering of our logo, like in the stack, you can see the three peak, which is sort of like a national symbol. So this is repeated in the Ruby symbol, which is our logo. So yeah, moving on. Belgium is known for beer. We're known for wine. Belgium is known for waffles. We're known for something called Gibbanyza, which is like very cool stuff. They're known for weird stuff. We're known for weird stuff as well. So as you can see by my t-shirt, last year I got scholarship for RailsConf. I went to Portland to get some freedom to go. It was awesome. There are many user groups. Like the community was very vibrant, very welcoming. They were really nice. And then I came home and there was no user group. And I only knew a couple of other Ruby developers and I was like, oh, there's probably just like three of us or something. I don't know. And I'm in Portland. They have great coffee. So then I was talking with some other Ruby developers and we had a group on Facebook and I started there. And I said, okay, let's start a proper Ruby user group. How hard can it be? Famous less words. I went to meetup.com, registered a user group and set up, let's go for a drink. It was December, so we went for a blue wine. But it was like, in general, I expected totally when this would start to having 15 people. I think that's like for a country, two million people for a town with 300,000. That was more than enough. And I only knew like three other Ruby developers. And then like the actual meetup started, I think what's important is a venue. We had some trial and errors here. And like also talks, we had some trial and errors here because you have some very, very boring talks and you can't convince them to stop. They're just like, they're going, they're going and going, so. But this is the most important part. Like when you're picking a venue, pick one that has no tables for the after party. Because what happens if there's an after party, people sit down with the people they already know. And they talk with the people they already know so like there are no actual community happens because you don't get to meet new people. But if you don't have any tables, people move around or like just have like standing tables, like they are here, that's cool. You move around, you meet new people when you get comfortable, when you get like drunk enough, like I am now. It's awesome. And currently, like when I was writing this, we had like 62 members, which is, wow, I never expected this. Usually we have like 20 to 30 per meetup, which is also awesome. And yes, we had the Ruby Burgers. There's one today. You should go, well, if you registered. One cool thing about having a Ruby user group is sponsors. You just write to them. Like these are our sponsors, but they are like more, most of them, like all of them have a special page for a Ruby user group where you can like general user groups where you can write, like we have a user group, we are that and that members, like they are interested in sponsoring us. And like the big ones, Informit, A-Press and O'Reilly, they're gonna send you free books for review. They're gonna give you a discount to all your members, like 50% discount. JetBrains gives us like at each meetup we have, we raffle one RubyMind license. So that's pretty cool. That drives up the attention as well. And Pluricides gives us some licenses and stuff. But the point is like there are sponsors willing to give you free stuff. You just have to email them. We also have Stickers, which is basically like meetup.com has like a fee and there are some other expenses with the group and all that. And we were like selling them for one euro and that turned out pretty cool. Like as you see, people have them everywhere, even on the mug. Sticker move apparently is like dishwasher safe. Anyway, no country is small enough. No city is small enough. Even two people is better than one. Start a group, format is irrelevant, whether you have a hack night, whether you have a proper talks, whatever. Someone has to do it, so be it you. I'm gonna put slides up, don't copy this. Slides are gonna be up. If you wanna find me, this is me on Twitter. This is RubySlovenia on Twitter. Find me for Stickers, I have many. And my time is just about to run out.