Here's what we're going to do, because we only did five minute lists here.

I'm going to do something on the fly right now. If you're on this list, and you can do it in one minute, and you don't get to use the computer, is there anyone for which that is true? Really?

You all need a computer? You all need five minutes? You don't want to just tell me about your awesome idea in 45 seconds? Really? All right, all right, because you get to go right now. So if you're down here, this is what I'm saying. If you're down here, right, and you want to go right now, and you could do it in a minute, you can do it.

Yeah, well, Koby, you're a special exception, so you can come up here, yeah. Koby, everyone.

All right, sorry about that, that was my grace. Real quick, I just wanted to announce February 6th, 7th, and 8th, Los Angeles Ruby Conference in LA. March 6th and 7th is Ruby on Ls in Bend. CFPs for both are open now.

Bend is in Oregon, so up in the Pacific Northwest. How many people have been to Ruby on Ls that are in the audience right now? All right, so we've got a decent number of alumni. Hold your hands again. Talk to these folks. Ask them if it's worth going, and then we'll see you in Bend in March.

Other than that, all the videos for RubyConf are being recorded. They'll all be up on Confreaks coming out during the month of November. Follow Confreaks on Twitter, and that's all I've got. And now I'm gonna try not to fall off the stage. Thank you.

Yeah, absolutely. Hey, I'm Josh. I don't know if you guys heard of the Ruby Hangout. I announced it last year before we started. Now we've done 12. We've had Aaron Patterson, Zach, Chad Fowler, a bunch of other people on it.

Go to Twitter, it's at Ruby Hangout. The next one's gonna be in December. I don't have the person lined up just yet, but I think it's gonna be awesome. Check it out, we record once a month. It's an online meet up. You can go face to face, have a meet up, that's great. If you can't get out and meet people, or you live in the middle of nowhere,

or whatever, you can do this online using Google Hangout. That's what we do, it's a meet up for everybody. So, add Ruby Hangout on Twitter. Thanks. Thank you. Okay, so here's your chance. I've indicated these are 30 minute blocks. So this is half an hour, one hour, hour and a half, two hours.

So this is the danger zone. So if you're in the danger zone, this is your opportunity. If you can do it in one minute. Really, we have no takers. I had people who said they wanted to do it. Okay, come on up. If there's anyone else, this is the last call.

I need you to come up here right now, because we're gonna go, we're burning daylight here. Hey everyone, my name is Evan Macnick, and if you don't know, I am the new maintainer of the Rails installer project, which is Windows and OS 10 versions of Rails installer.

Engine Yard kind of just finished supporting RVM, so therefore we also finished supporting Michael Pappas, who is working on the OS 10 version. So we're kind of at a point where we need a little help from the community. So if you've used Rails installer, if you know what Rails installer is, if you've ever tried Rails installer, please go onto railsinstaller.org, and help us out.

We could use some help with the website. Also, both versions of Rails installer, we really need your help, so that's it. Okay, thank you. Okay, hurry, tick, tick, tick. Hi guys, I'm Brandon Valentine from Nashville, Tennessee. I just wanted to take a couple of minutes.

Raise your hand if you actually have a computer science degree in this room. All right, put them down. Raise your hand if you taught yourself how to program, somebody else taught you, you have a mentor to thank. All right, so raise your hand if in your town there is some sort of software academy, starter league, that kind of thing.

All right, put your hands down if the thing in your town is for profit. All right, so I'm gonna tell you about something really cool that's happening in Nashville right now. For the last year and a half, there's a thing called the Nashville Software School. It is, as far as I know, the only non-profit software academy going in the United States right now.

We have a mission to give a hand up to people who don't have the privilege that we have all had to make it into this career. So we have a program, six months of intense training, that costs the student $1,000 up front. We also provide them a stipend throughout the program

so they can afford to continue with their training. At the end of it, we have an excellent graduation rate. We place people directly into jobs working as professional software developers. And it's going really well. But we need your help. We have a little bit of a cash flow problem with our non-profit. And if you go to nashvillesoftwareschool.com slash support,

you can help us build the operating capital we need to keep this program going so that people who don't have the privilege that we all have to be here and take a weekend off in the middle of November to fly to Miami Beach can find their way into our career. So thank you. Thanks Brandon.

Okay, here's how we're gonna do this. I'm gonna announce the current one and the person who's on deck. If you're not on deck, when your time comes up, you're skipped. So that's just, I'm not gonna fuck around. So, okay, so Prem, you're next. Tom, you're up. Oh, okay, yeah, that's fine. You got one?

Go for it. Sorry guys, last one. My name's Todd Pearson. I'm one of the co-creators of Influx DB. Influx is an open source time series and events database written in Go. We just released it this past week and we had libraries for JavaScript and Ruby and we've already had contributions for Python libraries,

Node.js library, command line interface. So the community response has been great. What I'd like for you guys is just come find me if you have anything that you'd like to see get added, future requests, library questions, anything that you wanna contribute. We'd love to get as much feedback as possible so that we build something that helps as many people as possible.

We are planning to have clustering support ready in December and a production ready release in January. So if you guys are interested or if you have anything you wanna talk to me about, come find me. Thank you. Thank you very much. Any other ones? Ones going once? Okay, we're good. Tom, you're up. Wait, are you a one? Are you a good Tom?

Oh, oh, I like it. Look at this, we got a pair of fools up here. What's up guys? I'm Tom Lehman, one of the co-founders of Rap Genius. I'm also the CTO and today I'm gonna talk to you guys about hyperlayers. Whoosh! A new hope for caching personalized content.

All right, so caching is a pretty big meme, huh? You guys feel me? Give it up for caching. Makes your app fast, it's great. Here is an example of a template you might wanna cache. The Rap Genius song page. And if you're using a modern caching technique, which I'm sure you guys all call generational caching, you're gonna deal with cache expiration by just having this cleverly constructed cache key.

So you throw the song updated at in the cache key, you don't have to worry about expiring the cache manually. So generational caching, it's great, but it's not so great when the page has a lot of personalized per user content. So in this example, we're putting an edit link on the song page only for users who have permission to edit that song. And so this messes up that caching situation

we had before because you can't share cache versions of the song page between users. So now you need to have two versions of the cache and those need to be different based on whether the edit link is there. So what do you do? Well, a naive solution is just to add, a naive solution is just to add the per user permission to the cache key.

So in this case, we put whether the current user can edit the song right there in the cache key and this will give correct results, but it limits the effectiveness of caching. And this just gets worse and worse as you start to put more and more user specific stuff in the cache key and before long, you're totally hosed, caching is broken. So obviously this naive approach is not gonna work,

how do you fix it? Well, there are a couple approaches. One approach advocated by DHH at last year's RailsConf is basically client side customization. So you send each client the same rendered HTML and thereby allow each client to share the same cache key and cache version, but then on page load, you go in with JavaScript and you basically remove all the stuff the client isn't permissioned to see.

And so this isn't a great technique. For one thing, you've got this JavaScript that's going in and doing all this like minutia and that's a little bit complicated, but on a more fundamental level, you are giving each client the same rendered HTML. And so this is fine if there's just an edit link in there that a client might not wanna see, but it's not fine if there's truly confidential data. So you can't, if you have a user's email address,

you can't remove that client side with JavaScript, you just can't send it over the wire to the user at all. So that's a little messed up, not so great. Another solution to this, which was also presented at RailsConf in response to DHH's is this idea of client side templating, which you guys have probably heard of. This is YCAT's solution to this problem. And so this simplifies the JavaScript considerably

and gives you a nice looking template. But the problem here is that now the client has to know all it needs to know to answer any permission question about a template. So in this context, the client has to know current user can edit the song and that might depend on a bunch of different things. So making your client smart enough to know all this permission stuff is complicated and so I don't like this solution either. So the good solution, which I like,

what I'm talking about today is hyperlayers. And this is hyperlayers. So the idea behind hyperlayers is it splits up your app's rendering into two passes or layers. In the first pass, which is illustrated by these arrows on the screen here, you take the ERB template on the left and render it to the ERB template on the right.

And what we've done is we've rendered to HTML all of the non-user specific content. So the song's title is now rendered as Hey There Delilah. The song's process lyrics are the lyrics. This is my favorite song. And all of the non-user specific content in general is rendered to HTML. But the user specific content, in particular this edit link,

which we've wrapped in this hyperlayer do block, is rendered instead to customization instructions, which is, in this case, ERB. So we render the ERB template on the left into the ERB template on the right, and then we cache the ERB template on the right. Now, when the client requests the webpage, we pull that rightmost ERB template out of the cache,

and that ERB template is pretty cooked, almost mostly filled in with actual data. The only thing that remains is the user customization part. So we evaluate the remainder of the ERB, customize it for that user, and set it down the wire. And so the beauty here is that, again, all users share the same cache key and cache version. Cache key is the simple one, again, at the bottom.

So it's super performant from a cache perspective, and all users only get exactly the data they are permissioned to see. So that is hyperlayers, the best way to have effectively cached per user customized content. Now, hyperlayers is very important. One thing is more important than hyperlayers today, and that is the rap genius RubyConf party. So if you guys are down to party, give it up.

This is a caching themed party. So you should show up dressed as your favorite caching concept, a sweeper, or a, you know, a generit. And so it's gonna be at this address, bit.ly slash RubyConf dash party. We're gonna be installing hyperlayers on anyone's app.

You just come check it out. There's a pool. It's gonna be great. Hit me up, show me love. Tom at rapgenius.com, 305-281-0228. Five minutes on the dot. Rap Genius out, peace! All right, hello. My name is Prem, whoa, whoa, whoa, hold on.

My name is Prem, you might know me as Sikashu. I work for Thoughtbot. We have so many open source gems, such as Paperclip, Factory Girl. But today I'm gonna talk about Appraisal. So I know you probably publish a gem, right?

That probably be fully tested. But can you be sure that they are working with the older version of this dependency? Probably not. So, like, hold on. Actually, hold on. Yes.

So, like, if you create a gem right now, you probably have a gem spec, say, sorry, you probably make it support for Rails 4. But then if you gem actually edge a while, you probably have to have support for 3.2 as well. Then, well, 3.1, or maybe 3.0.

So, I mean, for example, for our Paperclip gem, we actually have a dependency like this because Paperclip is so old. Then once in a while, people install Paperclip

and just coming at us like your gem doesn't work. Sad face. So that actually means that even, like, if you test your gem against the latest version, it doesn't mean that it works with the previous version. I actually have some slide about similar, but I'm not going to get into Rails and similar

after yesterday. Nevermind. So we need to test with the multiple version. So how? Well, use Appraisal. You can set multiple version of dependency in one place, merge them, and Appraisal will generate a gem file for you

when you run the test, it's actually set up the environment for you. So, for example, in your application, well, in your gem file, you probably have something like this, or you can also use gemspec as well,

and then you create a new file called Appraisal, have these guys in, and the other thing you need to set up is just adding Appraisal to your rake file. Then you can run rake, Appraisal gem files that will generate the gem files for you.

You can run Appraisal install, that will install all the dependencies. And when you want to run the test, you just run rake Appraisal test. So appending Appraisal to all of your rake tasks. And yeah, if you want to test with a specific version, just give the version name there.

So just for a recap, so Appraisal allows you to set the dependency in one place, generate the sub-gem files for you, install multiple version of dependency for you, and it tells Bundler what version of dependency you want to test against. So if you have a gem,

you probably set up the CI using Travis CI's. It's actually pretty simple. You just put this into your .travis.yaml, and that's pretty much it. You just push your gem, and it'll be something like this. For Paperclip, we have this,

and you can see that we have multiple gem files tested, and they're all green, so happy. So yeah, this actually shows that your gem are working with the older version of its dependency.

So if you want to try it out right now, yeah, just go to RubyGems. Well, do gem install, Appraisal. I put the Appraisal pre here because we are going to release 1.0 soon, which takes out the rake task dependency, so you can just call Appraisal.

I have a slide up on my speaker deck that outline the new features, but if you're interested, you should go check it out. So remember, if you have a gem, test it against multiple version of its dependency by using Appraisal. Thank you.

Okay, hello, everyone. My name is Richard Schneeman, and my talk is entitled Programming Programmers. So today, I want to introduce you to Rafael. So this is a glorious picture of Rafael, and he happens to be the number five committer in Rails slash Rails.

Currently something like 2,209 commits, which is incredible. I'm sure he's probably like a beast, and is like, I don't know, is double that by now since I copied that. So Rafael looks at a ton of issues in addition to contributing a lot to Rails, like absolutely so many issues.

It's mind-boggling. Like, I mean, I can comment on something at any hour of the day, and he'll be there. So unfortunately, though, Rafael has a problem. He has to sleep every once in a while. And also, unfortunately, Rails issues don't have to sleep. So just really quick, raise your hand

if you have ever used open source. Okay, some people do not raise their hand. Man, what are you doing here? All right, what about contributed to open source? All right, okay, that's looking pretty good. What about contributed to open source 2,209 times?

Okay, yeah, all right. Okay, so what if there was a way to, at the same time, supercharge your programming skills, and I hate the term giving back to open source,

because I am super selfish, and I like giving forwards to future me. So, you know, and we want to release your inner Rafael. What if there was a way to do this? So I discovered a secret API. Well, first of all, I discovered that,

number one, programmers are humans. Yeah, pretty surprising. I also discovered that there is an API into the human mind that managers have figured out how to manipulate. You might know it as email. So a way to condition yourself into being a better programmer

is a little program I wrote called Code Triage. All right, some of you have heard of this before, and that's probably good, because I released it at Denver RubyConf in a similar lightning talk. So since then, we've got about 3,000 developers,

almost 1,000 projects, and I'd also like to, it was officially given as the reason of John Rowe getting RSpec commit access. So, yeah, that's a thing. If you're unfamiliar with Code Triage, essentially, all of those things

that Rafael has to do with those 700 frickin' issues, most of them you can do. Most of them you can look and see, like, oh, is this a bug? Oh, can I reproduce this? What versions of Rails are you using? Oh, it looks like no one has commented on this issue in the last two years. Can we please close this? So these are all things you can do,

and so Code Triage will send you one issue from your chosen repository per day. It's very lightweight, especially if you've not contributed to Rack or Rails or Ruby or whatever your favorite library is. It's a very lightweight way to get involved there. So sign up today, codetriage.com,

and yeah, thank you all very much for attending the lightning talk. Thank you very much. How are you, Adi? Today I'm talking about how to make Perfume Dance. My name is Nari.

I'm a CRuby committer, and I'm a creator of bitmap marking, CC, in CRuby 2.0. Today's topic is about Perfume. Perfume is a famous pop girl group in Japan.

There are many fans of Perfume in Japan. Perfume has started a very interesting project. This project's code name is Perfume Dev. They uploaded motion capture data of their dance to GitHub.

The URL is here. This motion data is free to use, so we can create some movies and so on with this motion data. And many creators in the world created some works. This movie shows a part of works by many creators.

When I know this project, I thought it's a very interesting project. So I thought I want to make Perfume Dance with Ruby. So I started to hack. I use Ruby SDL, and the motion data format is bboo.h.

We can pass this format with bboo.h gem. And hacking is done. This is my first prototype of dancing Perfume.

You know, there's a bug. I found wrong matrix calculation and fix it, done. And this is my second prototype of dancing Perfume. Thank you.

I made it, but I was not satisfied because there is an unfavorable line of code. This is wrong. I usually say, hey, you should not disable this C,

but I did it. I'm so sorry. Okay. Why does this program need to disable this C? The motion data is big, and the motion data translates to read-only objects in Ruby heap after parsing. These objects can cause high DC pressure.

DC must scan these motion data objects each time. So, as a result, GC forced to interrupt their dancing. So, I want to show this issue.

This one, you can see they stopped dancing. They feel real stopped the world now. This interrupts their dance. They cannot dance mostly.

This is the best GC stop the world demo I've ever seen. Okay. But in Ruby 2.1, Koichi-san introduced Generational GC to Ruby. This is called Argent GC. This feature saves their dance.

These motion data are read-only, and they are long-life objects. And Argent GC also needs to scan these at first, but Argent GC can assume these are long-life objects. After that, Argent GC scans these objects sometimes.

Okay, I want to prove my thought.

Yes. They can dance smoothly with Ruby 2.1. What a great. What a great.

Is this the official RubyConf dance now? Conclusion, Argent GC is cool, and Koichi-san is also cool. Ruby 2.1 will be great. And you should not, you should not use GC this year, go.

Thank you. My name is Allison, and I'm going to be talking about mentoring from a newbie's perspective. So first, a little bit about myself. So I'm a Rails Girls DC organiser, I'm a newbie, I'm a super-motivated learner.

I love the Ruby community. I am a mentor and a mentee, and I'm a first-time lightning talker. So I've been learning to code for about a year, and through my journey, there have been a ton of people who have really helped me learn,

have been really, really amazing. And everybody's had really good intentions, but some people I've learned from really effectively, and others not as much. That's okay. So here are some of my main tips for being an effective mentor. So first, when I started learning,

I didn't even know what questions to ask. So people would come up to me, and they'd be like, oh, what do you need help with? What are you working on? What are your questions? And I'd be like, I'm okay, thanks. And it's really because I just didn't know what to ask, and sometimes when I asked a question, every word that came out of the person's mouth sounded like a completely foreign language. So I really appreciated when mentors encouraged me

to be relentlessly curious. So to ask questions, and continue asking questions, and continue asking questions, and if they were answering a question, and I didn't understand a word that they were saying, ask that question in the middle of their answer. So second, don't go down the rabbit hole. So I feel like there's this tendency sometimes, I've seen it before in meetups in different places,

where somebody asks a question, and there's a desire to really answer the question, give additional resources, articles, blogs, and also talk about how it relates to everything else involved with Ruby and Rails and whatnot. So that's great, except that at some point, I have no idea what you're talking about,

and I feel like I'm never gonna actually be able to code. So just keep it concise, answer the question, make sure that the person hasn't completely lost you. So third, understand if you're not understood. And so I think that this one is challenging. There are times where somebody has tried to explain something to me over and over and over again,

rephrased it a million times, and I just am not understanding it, and then somebody else comes up and says it, and I'm like, oh, yeah, now I get it. And that's, you know, it's not you, it's just the different people learn in different ways. So I would say make it okay for the person that you're mentoring to say, are you understanding what I'm saying? Or, you know, hey, how would you explain this

to an additional mentor? They might just be able to use different words or get through more effectively. Fourth, the dreaded answer to what should I read? So this question comes up, again, in learning meetups all the time on forums, and somebody says, hey, what should I read? And then everyone just throws out a ton of authors

and books and everything, and you have this like mile-long list that you then have to Google, but you have no idea what to read, in what order, why you should be reading it. So something that I find really helpful is giving direction. So what books should you read first? Where should you read these books in your learning journey? Why, and when I'm reading books,

what should I really be making sure to focus on to learn from for that particular book? Five is don't put your fingers on my keyboard. So this one I find is really, really challenging in working with more experienced developers. Unless you're pair programming,

it's really effective, and I know that it's painful sometimes to have to say, okay, capital this, then space, then, but I find that you have to be really, really patient, but I know that I've learned better when somebody has literally told me every letter to type in, and other people has as well.

So again, takes a lot of patience, but I think it's more effective. And finally, help celebrate the small stuff and motivate to do the big stuff. So when I was first learning, everything to me was amazing, and I assumed that it was really not a big deal to everybody else, because everybody else knew a lot more than I did.

So it really helped me to be with an amazing community of people that helped me celebrate that small stuff, and to realize that those small things were actually big things. And then building on that, they encouraged me to do big stuff. So give the talk at a local Ruby group, give this lightning talk today, and so celebrate the small stuff,

and motivate to do even bigger things. That's it, thanks so much. Whoo! So hey everyone, I want to talk about graphs and hamsters. My name is Lucas, but the hamsters are more important. So if you've ever seen a hamster eat something,

you see real joy. So a hamster really enjoys eating stuff, and yeah, this picture just makes me happy. So if you imagine you are a hamster, and you're not living in a cage, but you're living in the wild, so you have certain caves, and they are connected with tunnels, and then you can travel along those tunnels,

and yeah, put food into them. So imagine you are this hamster, and you collected grains and nuts in your different caves, and you build up tunnel network between all those caves. Then you can walk between them, and maybe eat something, and be happy again.

So what our task now is, is the hamster, it should count how much grain, and how much nuts it has, so it knows if it can survive the winter, because it has enough to eat. So, but the hamster, it's just a hamster,

its brain is not very big, so it can only remember the way back to its home cave, if he goes at most two caves. But it can remember which caves it already has visited. So if it starts up there,

it knows it has zero grains and zero nuts, and then it can travel, and just count in every cave how much grain is in there, and then just add it up. But it can't visit this cave, because it's too far away, and it wouldn't find the way back. So it will go here, and then there,

and then there, and then there, and then there, and then it has counted all of its grains and nuts. And this is the result, so it has 13 grains and 13 nuts. This hamster's kind of creepy, I think, but it's a hamster, so it's still cute. So the hamster is a visitor,

so if you want to implement it, there's something called traversals. And this is a very natural way to implement something like that. So I work in a free and open source project called ArangoDB, and it supports both documents and graphs, and it has an awesome query language,

but also has support for simple queries. It has real transactions, which are a lot, because it's a NoSQL database, that's not normal, I think. It has master-slave replication, an extensible API, embedded V8, and it's efficient and performant. So what you can do with ArangoDB is model such a thing like a hamster,

because hamsters are awesome. And this is done via the REST API. So what you can see here is the configuration of the traversal of this hamster. So you say, where should it start? So there's a vertex where the hamster lives, and then you can say, give certain details.

It's a lightning talk, so I won't go into everything. And then you can just give some JavaScript code and tell it what to do at every single cave. And this way, it would count the same way that it did in the example before. And you can see that it will see if,

it will remember all the notes it's visited because of this global uniqueness. So ArangoDB has some additional features for graphs. It has a really cool graphical graph explorer that a friend of mine implemented that you can see in the admin interface, and then you can explore the entire graph.

The query language has support for graphs, but if you want more, you can use those iterators that I just showed you. And it has a lot of built-in algorithms like shortest path and centrality measurements. And it's also compatible with Ruby, so I wrote a little adapter called ShikavaCore. It's a low-level driver.

You can find it on GitHub as well as the database, and of course, also on RubyGems. And Guacamole, it's an ODM with Rails support that we just shipped today, so you can check it out and yeah, get a look on GitHub. Thank you.

All right. How many people here don't know what this means? All right, it was gonna be a really short talk otherwise, if everybody already knew. All right, so Minaswan, this is one of the fundamental tenets of the Ruby community. And what it stands for is mass is nice,

and so we are nice. I think it's really important we constantly keep repeating this and keep it going as more people come into the Ruby community. And it kind of goes through waves. I feel like a lot of people will talk about it,

and then it'll kind of go away. But there's more to it than just being friendly and treating people well and that sort of thing. And I think if we embrace this, we can really keep Ruby awesome, and we can move on to just make Ruby awesomer, including the whole community around it.

And part of that is going into the way we treat people and the way we write the code. So I just wanted to point out real quick, we can write some nice code. And I'm not sure that that's entirely intuitive. So part of this is giving forward to my future self.

The semantic versioning, let's write code that behaves well with other people. Let's make it so it's intuitive how things work. Let's do things that write good git commit messages. This is very important to your future self and to the people that are trying to collaborate with you.

Put things in namespaces, that sort of thing. I think we can embrace this and just keep things going forward. And overall, let's just make sure that we maintain this tenant that goes back to the early days of the RubyLang mailing list. And we want to just keep going.

And when you see people that aren't acting accordingly, just tell them minutes one and keep going with it. Thank you. Okay, I have 50 slides in five minutes. So that's six seconds a slide. So this is a short talk about software compatibility.

And software compatibility is important because if you want to upgrade one of your dependencies, whether that be an operating system, a programming language, or a gem, you need to know whether it's compatible with the version you're currently using. So let's talk about semantic versioning. What does it mean for a version to be semantic?

A semantic version conveys information about the meaning of the code. The version isn't just some arbitrary number. It actually tells you something. And specifically, it tells you what changed. And it tells you what didn't change. So another way to say that is semantic versioning is a statement

about software's compatibility with the previous version or previous versions of that software. So a semantic version has three places for numbers. In this case, represented by X, Y, and Z. For those who speak British, that's X, Y, and Z. Note, you can't tell whether a version is semantic

just by looking at it. So Ruby and Rails both have version numbers in this form, but neither adheres to semantic versioning. So what you should do is you should document that you're using semantic versioning in a readme or some other obvious place where people can find it.

So this is an example version number, and each digit means something different, right? The X, Y, and Z all have a different meaning. When the developer increments the least significant digit, the three in this case, basically they're making a statement about a promise, actually, about the compatibility.

And they're saying that this version is fully compatible with the previous version. And it's even more precise than that. It's not just compatible. It's that there's no interface changes, right? No changes to the public interface. These are often called patch releases and include things like bug fixes, performance improvements, and security patches.

And in the words of Janet Jackson, you want this, right? When a developer ships a new patch release, you should upgrade. The risks are typically low and the rewards are high. So now let's talk about the second digit in SemVer. Unlike patch releases, minor updates allow interface changes,

but they only allow positive deltas. So new methods can be added, but old methods can't be removed or changed in an incompatible way. So again, just like patch releases, these are compatible. There can be public API changes, but only positive additions to the public API. And the developer promises there's no breaking changes.

Typically minor releases are used for adding new features. And I don't actually know if Latoya Jackson said this, but it sort of goes with the theme. You might want this, right? It's new features. It's not breaking anything. So in general, the risk of upgrading is pretty low. And there's no good reason not to upgrade.

You get new features, which you may want to use. So the most significant digit, when that's incremented, it indicates that there's an existing change. And just to be clear, like this version should only be incremented when there is a breaking change. If there's not a breaking change, then you can just keep incrementing that minor version number, right?

These numbers can go above nine. You can have 1.10 or 1.11, right? Goes to 11. So when the significant digit changes, that's like a significant statement that this version is incompatible. Some behavior that was existing was either changed or removed. And that basically there's interface changes.

And this is in the immortal worlds of Michael Jackson. Basically you'll have to change your code, right? If something is incompatible, that means you have to do something to make it work with the system that you're upgrading. So maybe you get a new feature, but you don't get it for free

the way that you do in a patch release or a minor release. So 1.0.0 is a significant release. This also has semantic meaning in semantic versioning. Basically this defines your public API. So before version 1.0, you can do whatever you want. You can make breaking changes.

There's no guarantees and no promises. But once you release version 1.0, what you're saying is this is a stable API. I will not change it until version two is released. And when you release version two, it's sort of another way of saying,

can we do that again? Sorry. So yeah, basically it means that you designed your API and you're like, okay, it's 1.0. I'm locking it down, it's solid. And then you realize that maybe you hadn't thought through the problem all the way or modeled it correctly or whatever. And so yeah, so then maybe that happens again.

And so maybe it even happens one more time, right? So the software, there's sort of this formula

that I've come up with for stability of a package, which is you take the major version number and divide it by the amount of time since version 1.0.0 was released. And it's basically saying, how often does this library break its public API? How often do you, as the user of this library,

need to make changes because the API wasn't quite right in version one or two or three? Okay, so now you understand semantic versioning, but so what? Why is this useful? So the thing that makes semantic versioning useful is that you can use it to correctly specify dependencies.

There's a great blog post about this by Yehuda Katz called Using Greater Than or Equal To Considered Harmful in the Context of Specifying Dependencies. I would encourage you to read the whole blog post. It's a great blog post, but it has a TLDR as the first line, which basically says, use this instead.

Don't use greater than or equal to, use this. What is this? This is the pessimistic version constraint, and it works like this. So if you say, pessimistic version constraint 1.2.3, that's the same thing as saying, greater than or equal to 1.2.3, but less than 1.3. So basically, you knock off the last specified digit

and make that an x, basically. So it's like 1.2.x, where x is greater than three. And you can do the same thing with two digits of precision as well. So saying, pessimistic version constraint 1.2 is the same thing as saying, greater than or equal to 1.2, less than 2.0. And that's typically the one that you wanna use when you're specifying a dependency

that is above, on a gem that uses semantic versioning and is above version 1.0. So not everyone does this. I've gone to the trouble of removing the names from this page because Matt's is nice, and so I'm trying to be nice,

and I wouldn't wanna publicly shame the gem that... Burn! So this is a very popular gem with more than a million downloads, or almost a million downloads. And basically, it uses greater than or equal to everywhere. And this is really a bad thing to do because it's basically saying

that all future versions of this library will be compatible with this library. And by definition, if they are using semantic versioning, then they will not be compatible. When there is a new major version, that will break compatibility, by definition. So please do not do this. It will cause a bunch of problems for your users.

Please use semantic versioning. Please specify your dependencies correctly. Thank you. Hello, everyone. I'm Michael Hartl, and I'm here to tell you about Polytechnic, an ebook typesetting system for technical authors.

Some of you may know me as the author of the Ruby on Rails tutorial, or maybe as the author of the TAO Manifesto, and what you may not know is that both of these were made using the prototype of Polytechnic, and the production version of Polytechnic is currently in private beta, and I'll have a little bit to tell you about at the end if you're interested in getting involved.

So a Polytechnic is distributed as a Ruby gem under the MIT license, and it gives you a command line client. Make that font bigger. So it's actually not important for them to, well, I can, it's not that important. I can try it. So, because I'll be telling them. But anyway, so it comes with a command line client

called poly, and so what we're gonna do now is make a new book with poly new. So let's make a new little book called RubyConf. And so that generated a file skeleton, so it's a book, it's sort of a book skeleton, and I've got a prep script here,

just to save a little time. And one of the things that Polytechnic comes with is a server called polyserver, or polys for short, that builds the template that we just made, and it serves it as HTML on localhost 4000. So let's take a look at that. So this is the template that just got generated.

And let's take a look at the source of this. And I've got some demo material. All right, so let's just get it set up. Okay, so this is the first chapter of the template document that got generated, but I'm just gonna delete the stuff

because we don't need it. So you can see that the server actually just refreshed the document automatically and when I saved. So now I'm gonna put in a new title for the chapter. It's a Polytechnic demo, and you can see that it's got a couple of references there, a section on inheritance, a section on the golden ratio. Those are labels, though,

so you can see sec colon inheritance. It's in red because it hasn't been defined yet. So I'm going to paste in the section on inheritance. You can see it changes to section 1.1, covers inheritance. That's a linked cross-reference. And you can see there are a couple of blocks of code there with full syntax highlighting. But it's really nice, especially in a longer document, to be able to refer to your code by some sort of label.

So I'm gonna paste this in here, and you can see listing code colon word shows an example of inheritance in Ruby. And now I'm gonna put in a code listing environment that comes as part of the Polytechnic system.

So here we go. I'm gonna cut that and put it in. And now you can see listing 1.1 shows an example of Ruby inheritance. So you can see that Polytechnic is really good at source code, but it does a lot of other things, too. Here's the second section on the golden ratio. So we can see here that we've got a figure with a numbered caption,

and that's a golden rectangle there. If you do some analysis and some algebra, you can derive a numerical result for the numerical value for the golden ratio. And so you can see here that Polytechnic supports the linked cross reference for the figure, centered math, inline math, numbered equations with linked cross references.

All right, so our document is coming together now. Let's build some ebooks. I'm typing polybuild here. This is building EPUB, Moby, and PDF from the same source. The input source we've been looking at is called Polytech. It's a strict subset of the LaTeX typesetting language. Polytechnic also supports markdown as input and includes a markdown to Polytech converter

so you can switch to Polytech if you want to. All right, so let's take a look at the ebook that got generated. All right, so here is the PDF, and you can see that there's the cover that, of course, you can change before publishing anything. And here is the first chapter of Polytechnic demo, and we see links, linked cross references,

syntax highlighted source code, math, figure, and so on. And let's take a look at the Moby document. Again, we see the same thing, linked cross references, syntax highlighted source code, figure, and math. So these files are on my computer,

so I can do whatever I want with them. I can sell them, I can give them away. But one of the things I learned in the Rails tutorials how nice it is to be able to publish very quickly and easily. So Polytechnic comes with one final thing called Polypublish, which publishes to a website that we're developing, that my co-founders and I are developing as part of Polytechnic, called Softcover. So that's uploading, but just to save time,

I'm going to show you that this is the live website. It's softcover.io. And so you can see that this is the book online. It's the HTML. There's also PDF, EPUB, and Moby. Softcover's design is a general system for selling digital goods, so you can upload screencasts, make multiple bundles with multiple pricing tiers. So if you're interested in learning more about Polytechnic

or Softcover, go to softcover.io and put your email address in, and you'll get an invitation to the private beta. Thank you. Very nice. Also, be sure to check out the TAO manifesto. Okay, so, kind of the status of Ruby Langorg.

So my name is Hiroshi Wada. So I'm a Ruby committer. So my Twitter and GitHub account, and HSVT. This is my GitHub profile, so my main work is OSS contributions. So I'm Rudolf Ruby Langorg.

I'll introduce current status of Ruby Langorg. So first, www.RubyLangorg. www.RubyLangorg is hosted by GitHub now. We can fix content in Ruby Langorg easily. If you discover a type and a wrong sentence,

please open each issue and send pull requests. We can merge it and deploy a production stage in Ruby Lang. I introduced Ruby Langorg in Red Root RubyConf, Singapore,

at the spring of this year. We got our beta lab translations in six months, and some of the translations are out of date. We need more contributions. Please join us. Next is, I prepared a HTTPS protocol in Ruby Langorg.

This SSL certification is provided by GlobalSign open source program. They provided us with wildcard certifications, so thanks to GlobalSign.

Next, bugs Ruby Langorg. It is official issue tracking in Ruby development using Redline. So bugs Ruby Langorg is running with dedicated server now, and it uses Ruby 1.8 and Rails 2.3.

It's too bad. They are already end of life. So I hope to use Ruby 2.0 and the latest version of Redline. Now we fork Redline on GitHub, and bugs Ruby Langorg

uses original programming of Redline. I think it's their compatibility for Rails 3, but current status is pending. Next host is our docs Ruby Langorg. Docs Ruby Langorg provides only Japanese documentation of Ruby.

Its name is Rurima. Rurima stands for Ruby reference manual. Docs Ruby Langorg provides English documentation now. This document prepared by Zach. Thank you for Zach.

And Herock provides our resources of www and bugs and docs and more. We are migrating our content to Herock from dedicated server. After migrations, we plan to add CDN.

Thanks Herock. And next server is cache Ruby Langorg. These hosts are providing official Ruby packages. We have the recent program. This host's location is Japan.

So USA and Europe is too far from these hosts. So I negotiated it firstly and prepared CDN. You can get Ruby packages with pretty fast in USA and Europe. These are same hosts.

Above host is FTP Ruby Langorg. That cache Ruby Langorg enables CDN. You can see this 10 times faster with CDN. Don't use FTP. Please use cache FTP Ruby Langorg. Thanks to Fastly.

Please tweet. Thanks Fastly. And finally, we opened the redesign contest of Ruby Langorg. We have a lot of submissions. I'll introduce them in order of submissions.

First, designs. Second. Third. Four. Five. Six. So we are going to select one design in Ruby World Conference at November 21.

Stay tuned. Thanks. I'm pleased. I have opportunities for the presentation by introducing Ruby Smargin. So I'd like to begin by asking you a question. Do you know Ruby Smargin?

Oh, thank you. Ruby Smargin is the most popular web magazine in Japan that posts important information about Ruby. Now it's nine years old and it has 44 plus seven issues, 597 articles,

but most of them are Japanese. The website is http://magazine.ruby.net and I am one of the members of Ruby Smargin editor's team. I've edited many articles posted on Ruby Smargin

and I posted some articles to Ruby Smargin. For example, Fiber for Beginners, Which Do You Like Map or Collect, and Euroco 2013 Conference Report. But these articles are written in Japanese.

If you want to read, please use Google Translate. So Ruby Smargin's major content, for example, Ruby Interviews. A memorable first interview is Matt-san and interviewer is Koichi-san.

Regional Ruby Conference Reports, we have many, many regional Ruby Conference in Japan. And introducing library, which you made it,

and job offer, for example, the Nintendo employment examination, Nintendo Code puzzle. It's fun, so please try it.

Is the laptop not working again?

And this is a access ranking of Ruby's magazine contents. If you happen to be interested in Japanese Ruby users' interest, please refer the ranking at this URL.

And some English articles are translated to Japanese. For example, Ruby Jemis and blah, blah, blah. And a few articles which we want any news about known Japanese people to read translated Japanese to English.

For example, Ruby 2.0 reads special articles introducing to Ruby 2.0. And introducing Ruby Dev translation is introduction of Ruby Dev mailing list translation project. So why don't you post to Ruby's magazine?

We are waiting for your post. We want more English content, more regional Ruby conference reports from any countries, more job offers from any countries, introducing your own library. So please send email to magazine.ruby.org

if you want to post. Thank you. Cool, so I want to talk a little bit about what I have learned in the last three weeks by interviewing a bunch of Rubyists. Let me first make sure this works. Let me first introduce myself. My name is Andrew Harvey.

I run RoRoSID, which is the Sydney Ruby and Rails meetup. We meet monthly. I also help run Development Hub and am an organizer of Rails Girls Sydney. We're actually, let me spook it, Australia has four simultaneous Rails Girls running next weekend in Sydney, Perth, Melbourne, and Brisbane.

Those cities might not mean anything to you, but that's okay. As of two weeks ago, we launched multifaceted.io. It is a blog very much like rubiest.net. It is designed to pull in content. We're building content by talking to

some really interesting people about interesting things focused around Ruby and around Rubyists. But this week, there has been the Hub. How many of you have actually been to the Hub? Can I suggest, ask, that maybe some more

might want to have a look? It's got a stream of all the Twitter feed and Instagram and whatever else you kids are using these days. It's got a planner down the side, including some talk previews. If you're still struggling to work out which talks you're interested in going to, we've been interviewing a lot of the speakers, and that's where I get to what I learned

from talking to a bunch of Rubyists. I think I ended up talking to 18 or 19 different Rubyists before I got on a plane here, and then I've talked to even more. And I learned some things about Ruby and Rubyists, but first I need to make an apology. There are some speakers that I interviewed that I have not yet either been able to post

their interview or the write-up of it, because that's currently, multifaceted has been around for a week, and that's how many words I've written. 8,430, and I can't type any faster. But what I learned about Ruby is, as Rubyists, we love the syntax. We love the expressiveness, the conciseness,

and the simplicity of the syntax. We also love the people. Matt's is nice, so we are nice. And that has radiated throughout the community. I actually think there's a little bit of technological determinism going in there as well,

where a very human-oriented language, a language which is designed for humans, has brought in humans that care about humans. We do actually care about performance. That's one, I also love that gif. I could, yeah, I don't even know. We actually do care about performance. There is a huge number of talks this weekend

that have been about concurrent Ruby, about garbage collection, about making Ruby perform better, and I think one of the reasons that we actually care about performance is that we want to widen the tent. We want to increase the number and the diversity of people who come in and use Ruby, and especially those that might be

in performance-sensitive areas, like science and other things like that. We want to be better. One thing I've learned about Rubyists is we're constantly learning and constantly getting better at what we do. You hear a lot of Rubyists talk about their development as crafts, and they extend themselves as crafts people.

We also want to help others get better. The number of people who have mentored me or someone else that I know is just amazing. The number of people who will come alongside you, whether it's on IRC, on a forum, or in real life, is just fantastic,

and we want to change the world. That's the one amazing thing. I've used a range of programming languages and been involved in different communities, but never have I found one where a changing the world is actually on the list of things to do, and that's something I find unique to Rubyists, and I don't think we should lose that,

but we are also a pretty odd bunch. Last night, you should check out the hot tub, because last night, there was the most bizarre thing of, 20-odd programmers sitting there, people with cigars and bourbon in a hot tub in Miami.

I never expected that of software developers, and I have 20 seconds left in which I'm going to say thank you, and say check out the hub. If you haven't submitted your talk notes, you should totally do that. I've got 23 pull requests, and I'm stoked. I want more. Thank you very much. Thank you. Okay, let me talk about my examination

on Ruby standard rollers, thread safe, and process safe. My name is Naoto Seo. My Twitter and GitHub account is S-O-N-O-T-S, like Sonot. I'm working as an engineer at DNA Japan, and I recently became as a committer member of Friendly. How many people know Friendly here?

Oh, a few. Okay, let me explain about Friendly. Friendly can be used for real-time pipelining of long streams, and we can write many plugins using Ruby, so using Friendly, we can collect log from many web application servers,

and data processing, and posting to some routing systems, such as Nynos or Zabbix, and we can store such long data into data store like MongoDB. There are several log management to compare to be the Fluentd, like C-long-energy, Splunk, Scribe-d, Flume-energy,

long-stash, and the Friendly. Friendly have a functionality that we can write Ruby plugin, and it supports the gem. Long-stash also supports Ruby plugin, but it doesn't support the gem, so we have to pre-request the long-stash case. So, Fluentd is very nice tool, so try that.

Try and check it out, but today's talk is about Ruby's logger. So, we needed the logger, which works safely in merge process environment, especially for Friendly, so I examined Ruby's logger. So, I examined four things.

First thing is it will not be mixture in merge threads, and second is same thing in merge process case, and third is does long rotation work safely in merge threads, and fourth is same thing in merge process case. So, I wrote a test code like this. I use a parallel gem, and using parallel gem,

I, in first thread, I wrote 5,000 A characters in long, and in second thread, 5,000 B characters in long. I repeated these things 10,000 times, and looking into the long file, and I found there is no mixture, like AB or BA,

so it looked fine, and I also checked the Ruby logger source code, and it was taking mutex synchronize to be thread safe, so it looked okay, and second, same thing in merge process case. In using Ruby, using parallel gem, changing the option in threads to in process it,

we can test the same thing in merge process case, and I looked at the long files, and there is no mixture, but looking at the source code, it was curious for me. It was not taking anything for merge process safe,

but seeing the man page of the system code, like to function itself is saying it is atomic, so it will not be, it will not be mixture as long, so it should be okay. Third thing is does long rotation work

exactly in merge thread? And Ruby logger has options, just edge, and using that, Ruby logger can do long rotation. I tested that, and it looked okay, but in the case of merge process, it is error, so it was bad. Why? I looked at the source code. It was taking mutex, but mutex works only for thread safe.

It doesn't work for merge process case, so we fixed for friendly. We used a flock to be for inter-process locking, and I through request this thing to Ruby too,

and it was merged, so it is a little bit. 2.1.0. So conclusion is Ruby logger was not safe in merge process, but it is safe now, so you can try this in Ruby track, and I also created the process gem

named process safe logger, so you can try this without waiting Ruby 2.1 if you want to try immediately, and do not forget to enter it. This is very cool tool, so please try and check it out. Thank you. Thank you.

All right, hi. Go ahead. Let me introduce myself first. I am Gautam Rege, and I am the co-founder of George Software. It's an Indian-based company which works exclusively in Ruby on Rails. We have something special in our company. The last line, we are actually associated with a company called Tech Vision,

which has four blind Rubyists, and we've been teaching them Ruby for the past couple of years, but the question always pops up. There are all these excellent efforts which are going on, and kudos to everyone here, but how many of y'all, if I may ask,

have actually worked with visually impaired or blind Rubyists? I'm really proud of you. Really proud of a couple of you guys here, but why? Are we afraid that they need workplace safety? Are we afraid that they need special equipment?

Maybe we have to learn Braille? Let me show you a video of, this is Nitin. He's working right there with a standard keyboard. It's attached to a wireless computer. There's nothing special about the keyboard, and he's got a headset,

and he's listening to the screen. The laptop's far away from him. Believe it or not, he doesn't even care if the display's on or not, right? He's started a real server, and these guys work just like this. There's been a time when I've gone to their office,

and it's pitch dark, and I'm like, guys, is there no electricity here? He says, why? Well, what they're using is a screen reader called JAWS. There are other tools like Orca on Linux, and Mac has its built-in accessibility,

but if you think I'm on a philanthropy trip here trying to say that we should help these poor guys, I'm not. I'm here to tell you guys how big a disadvantage it is for us to be sighted. These guys have a huge advantage.

Being blind not only makes the other senses really, really alert, they're very eager and motivated, but more importantly, they can read faster than us. That screen reader works at about 80% of what we can read,

so if it's all gibberish to us, but if you open a Wikipedia page, and they have probably read it 20 times faster than what we can read, so by the time you read one paragraph, the whole page, and they probably know it better than us. They have one other advantage.

This morning, Katie was talking about people who've not come on stage, and should come on stage and just talk. These guys have no stage fright. If you're standing in front of so many people, they don't really care. It can be empty, but they know what they have to talk about. In fact, I'm embarrassed that I need a presentation. These guys can sit and talk for an hour.

It was interesting when I spoke to one of them, and I said, hey, can you just tell me your story? And he says, yeah, for how much time? Five minutes, 10 minutes, one hour, when? Now, these guys know it. Because of their senses are so well-developed, it's a natural advantage for them to learn programming. Well, Ruby has actually helped them,

because Ruby as a language is easy for us. I asked her to take an exercise here. Close your eyes, and try to think how you would explain to somebody what is the difference between a hash and an array. And we're all used to saying, yeah, this is the root node, and the two leaf nodes, and you can draw diagrams,

and you can show screens. But if you're talking to a blind person, and it's for the first time, if you're trying to teach them what is a hash and an array, that's not easy. And if you're trying to look at a binary search tree, and tell them why it's better, and why the level or the height of the tree is what the fastest search is, and you actually have to take embossed paper,

or you have to hold their hand, and press their fingers and tell them these are the nodes. So it's different teaching them. It's important for them to realize that user interface is important. They're blind, but they know the value of user interfaces. And that's why Ruby helps us understand,

because it hides all the abstracted abstracts all the way. So you can have a hash dot each, or some array dot each, and it's all the same code. So they can concentrate more on what they actually have to say. Coming to the problems I face are things like this, multi-line commands, exceptions and logs,

and making it all this accessible is what they're currently working on. They're actually working with Brails. This is a site that they've actually developed, and this is an accessible site.

And this is developed completely by them, where they can actually do it for the visually impaired. And you can change, these colors are not random colors, they're actually in the WCAG standards. And I implore you all to actually go to the site, and check it out, and do any efforts to help with the content management of the site. Thank you so much. Thank you.

Gant, are you here? Okay, come on up. Hello, everyone. I'll talk about anime data GIF. I'm Maki Moto, software engineer from Tokyo. My recent interest is breaking images. And so, last week I gave a lightning talk

about visual glitch. But today my talk is not glitch, but animated GIF. You all know animated GIF is this. Rolling switch, very fast.

One of the most popular ways to generate animated GIF is image magic. Use a combat command, and you can generate animated GIF. In Ruby, you use R magic.

This is a sample generating animated GIF code, and so it's sort of simple, but image magic is too large to handle. And I want to focus on animated GIF. So I created a scene for animated GIF this morning.

It is like this. If you never want to insert image magic, I created animated GIF API by CURL.

This is a simple central program, and prepare those images and kick this command. It work like it, and generate this file.

My present data history included program tick. That's it, program tick. I believe this, but more program tick usage.

In case of headless browser testing, I created this toy web page.

It may be tested by such aspect code. It may work, but not in clear, so then write such class using an image GIF.

GIF an image, and add to the test. So it generates very useful. Wrap up, this anime is almost good. This anime is easy to make,

and this anime is sometimes useful. Thank you. Okay, so a lot of people know what RubyMotion is, and a lot of people saw it maybe a year ago or awhile, and if you don't know, I'm just gonna give you a quick explanation as far as also it's really changed a lot

over the past year, and why I know is because I love Ruby. I hate Objective C. I wrote a book on it, and if you're really interested, you should come to the meetups that we do every month. We do an online meetup. Laurent gave us meetup.rubymotion.com. It's pretty nice of him.

So RubyMotion, a lot of people look at me like that when I talk about it, but if you really wanna, this is the worst definition ever, just in case you're wondering, but what I tell them, I just say it's apps the Ruby way, which basically if you've dealt with Objective C, and you've gotten that headache,

and you're ready to go ahead and slam your face into the wall, then you can just go ahead and go back and do some RubyMotion where everything actually looks and feels like Ruby. Now at first, if you've seen this a while ago, Objective C, you're gonna do button taps. This happens all the time. You're constantly tapping buttons. They're all in there. This is your average Objective C.

If you can read that, you're doing better than I do. Then you convert that over to RubyMotion, and it doesn't look any better. It actually looks like Objective C slammed into Ruby. Now it's a little bit more readable, but this is kind of where people started seeing this, and they're like, oh, this doesn't feel right.

Well, of course, with the community, started writing some gems, started getting things rocking and rolling, and then so this is with a gem that's supported by RubyMotion, and everybody here, no matter what age, should be able to read that. That's the difference. It's amazing.

Well, thank you. I just use that all the time. There's a lot more smarter people than me that wrote it. So this is a guy, Clay Alsop. He does Propeller. He said this, and I think it looks great on screen. It says less like Objective C, more like Ruby.

There's actually a Kent State University study. It says the snake casing is actually more eye-trackable. It helps everybody out. It's even better. So what's so great about it? Well, this is gonna sound kind of repetitive to y'all. Gems in the community. Makes sense. Y'all love it. Editor independence, no more Xcode crashes.

Testing, you can actually test it. Ships with MacBacon. You can just do all your testing. I do test-driven development with it. The readability, and it actually compiles down. It's not like PhoneGap. You're actually gonna get native speeds, and it adds about a megabyte, maybe two megabytes, to the file size, which is nothing, and the REPL.

If you saw all the stuff with the Pry and all the other stuff. Being able to type directly into a screen and then seeing that code happen in real time is amazing. I write all maps, basically REPL-driven. This is a horrible analogy.

RubyMotion is to Objective C as, sort of like CoffeeScript is to JavaScript. It's easier, more readable, compiles down, but not really, additionally. It includes gems, which I guess you can kind of say, if you're going with the web analogy, is jQuery plugins. And then you got your Jasmine tests, REPL.

So anyways, this analogy just goes straight to hell. But it makes a lot of sense at the same time, because nothing else is supporting that. So, in looking at the code, I have three things real quick, and I can burn through them. Hello world, tests fail outside the box because it comes with a red-green refactor mentality. Then from here, you can command click the view,

and add a label to the screen. I do this from the REPL, and it builds it just fine. Then from there, you can go ahead and select stuff, or use the tree command from sugar cube, and then it lists out all the items for you. And it's amazing, so that you can actually access and modify things in real time. If you want to see this in real,

you know, if you actually want to see me do this, I will show you. Here's the other thing. I wrote an app called Ruby Trivia. It's free, it has no ads, and it was written and it was released the day iOS 7 was released. So, if you like Ruby, which I imagine some of you do, go ahead and download Ruby Trivia. It was written completely in Ruby Motion. And so, it's got all these gems in it,

and since it was written in Ruby Motion, it needs a yo dog, because yo dog, you like your Ruby, you got it in Ruby. And there it is right there. Last thing I'm gonna show you, game development for it. There's actually a bunch of really cool games. This guy made this thing right here,

and I actually in one day made this game. If you want it, have it on my iPad. I'll happily let you play. That's me eating tacos. Thank you. Okay, hey, what's up? My name is Jed, and the title of this lightning talk

is Making Slides in Ruby. I've been working on a small project. It's called Reveal CK, and that's what I like to talk to you about. If anybody ever tries to convince you to switch to a new framework for building slides, you should probably ask them three questions, maybe four. The first one is, what do I have to do to make the slides? Like, what do I actually create?

And then the second one is, having created that, having written that, what do I get? And the third one is, how do I get it? The fourth one might be, why are you talking to me about slides? So with Reveal CK, you write something like this.

This is Haml. It is a, Reveal CK is a gem. Here's the Haml, oh, let me slide over. Here's that same thing that I was just showing you. And let me see if I can do this.

So it comes with the command line executable. I just ran it. Reveal CK generate. Okay, there we go. And now I just use the open command, and we open it up in a browser.

And this is what you got from your Haml. So that's what you put in, and it's a gem. You ran it, and now you can see what you got out. And what you got out is probably pretty familiar to you. There have been four presentations so far that have used this framework. It's an HTML presentation framework called Reveal JS.

And Reveal CK, the C and the K stand for construction and kit. So they take, what Reveal CK does is it takes Haml and it builds these things. Is anybody familiar with Reveal JS? Has anybody seen it? Awesome, cool. So what you might not have noticed is that, well, as you were watching people come up, just like the one we just did,

you get speaker mode. It works on mobile. You can swipe it on a tablet. And, oh yeah, and it's all static HTML. So if you can host stuff on a website, you can have to view stuff up, or you can push stuff up to GitHub pages, it works just well for you. And this first one, the one that I generated,

just now, that was just, if you notice the URL, it's just on my file system there. File local host. So you don't have to put it up on the web to show it to anybody. Okay, so did anybody see Matt's keynote where he was using Rabbit? So he was using a slide framework called Rabbit. And one of the things here,

it says it's built for Rubyists. You don't have to leave your editor, and you don't have to, you know, you can track your changes just as plain text in any version control system you like. So you get the same sort of stuff when you're using RevealCK or RevealJS for that matter. So that Haml file, it was like one file

when we ran RevealCK at it. RevealCK generated that thing. And Haml's cool, you can also use Slim. But they're still templating languages. So you might want to actually build slides in Ruby. And before I was done with this project, I made a little builder DSL. So you get a presentation, every time you call slide,

you get a new slide. And can anybody guess what that will do? The answer is, it will entertain my daughter.

So, you know, you can, once you start, once you graduate to actually building slides with Ruby, this one searched the web, right? It did a Google image search for a particular query, it brought back the results and built the slides. But there's no reason that couldn't have been an API,

scraped the website, pulled stuff from a database. Sky's wide open, right? Anything you can do in Ruby, you can do there. And I think that's it. Thank you very much. Thank you. Okay. Hi. This is Japanese famous phrase, converting N-click to one-click becomes a business.

Converting one-click to zero-click becomes a revolution. Otsune, 2008. No one knows this because I translate this today. Sorry. So I waste a lot of time for clicking.

I wish less effort brought more value. It is worthwhile to make habit of good behavior. If this is easy, awesome. I'm talking about application, how not to die.

My tool support this, I feel this is revolution. The tool name is Tachikoma. I'm Sanematsu, I work for All My Grasses. We offer e-commerce system based on Spree and sell IE wares in Japan.

Spree is Rails engine for e-commerce. Are there any people who know Spree? Are there any people who use Spree here?

Thank you. But Spree is not a topic in this talk, sorry. Talk topic is changeless application. Changeless application will die gradually. Matse said in PHP conference in Japan, Kentaro said this is Japanese, so.

Point is continue to respond change is a destiny of web service. Important thing is keeping upgrade continuously. This include hardware, middleware, library development method and so on.

This is all I want to say here. How not to die with Ruby application. Run bundle updates simply and easily. Tachikoma fills a gap between this. Tachikoma automatically does git clone, bundle update, git commit, and send pre-request.

Yeah, this is captured. So send pre-request. So usage is set environment value as run lake task, a bundle exit lake, tachikoma run bundle, tachikoma automatically does git clone, bundle update, git commit, and send pre-request.

This is amazing, isn't it? You only do merge pre-request off and on. A point, application will die without bundle update frequently. Almost no bundle update. You probably understand this, but no.

As a result, the application will die gradually. How about using tachikoma? Tachikoma automatically does this. Method. Tachikoma's lack of solution. Tachikoma send pre-request,

but tachikoma don't know how to get diff of gem. I use GitHub compare view. If you are interested in tachikoma, you can Google tachikoma, but tachikoma is animation character in Japan,

so you can't find my tachikoma. You can Google tachikoma Ruby. And this is, and I want your GitHub star. Okay, so repeat after me, please. Tachikoma Ruby. Tachikoma Ruby.

Thank you. Thank you. Cool. All right, my name is Michael Dvorkin. I work for Walmart Labs. I'm the author of Awesome Print Gem. Thank you.

But today I'm gonna talk about another gem I wrote. It's called Unbelievable. And it's the actual name. I show it to you in a minute, but before I want to mention that I was inspired by Yusuke Endo,

who is one of the greatest Ruby hackers out there. So let's see. So, here's some Lorem.

Random Lorem. And if you run it, obviously you'll get the syntax error. But here's a little magic. I require Unbelievable, right? Oops. And now I'm gonna run it.

Oops, Ruby. Sure. And it shows you hello RubyConf. So essentially it's a Ruby program encoded as Lorem Ipsum. Let me show you some other example.

This is how you ship your special gem, right? Okay. This looks like your typical to-do list. Or, as Matt calls it, stupid boss. So let's run it.

RubyConf. So, one more example. This is Haiku. I feel like I'm being punked by having to hold this. And it's kind of romantic if you read it, right? So let me run it.

And finally I have one more thing. It was developed at some secret government agency and when you file the Freedom of Information Act request you get back something that looks like this.

It's called secret. Top secret because otherwise you're helping terrorists and drug dealers. So let me show you some more.

Can you deal with white space? Yeah. You look amused. I bet you're wondering whether it runs with Ruby. I am wondering. It should. Okay. So let me show you Fibonacci.

So this is more complex example. So basically here's the code. And I just go through the styles. And I generate the story for the style. Then I print it.

And then at the end I go through the stories and I just eval the story. So let's see what happens. Boom. So it's a little bit more verbose but here's your haiku and lorem and secret

and your to-do list, right? That's a lot of to-dos. I hope that's not just for one Saturday. So I probably don't have time to explain, you know. It's just gonna remain a secret? Well it's up on GitHub so you can check it out. Is it encoded in unbelievable? Like it's a quine and so...

It's not but if Aaron is here I bet he's wondering maybe some parts of active record should be converted to unbelievable. So yeah, to give you a hint, I'm trapping method missing and const missing and all I care is the method name

and the length of the method name, right? And that lets me to, you know, construct the characters and eventually reconstruct the entire Ruby code. So... I think we have to leave them with that.

So here you can find me on GitHub, on Twitter. My personal website is michaelworking.net and there is one more thing. Just in case you, you know, decide to use it in production, it's a disclaimer from the README file.

Thank you guys. Thanks. Go ahead. All right. Good evening everybody. I'm Bryce Curley and I run the Miami Ruby Brigade. So the first thing I'd like to do is give a shout out to everybody else who helps or has helped organize the Miami Ruby group. Chris Saylor, Pelly Brain Guard, Ivan Acosta Rubio who's over here

and Joseph Diago who is elsewhere in the room. So two years ago, RubyConf 2011, I stood up on stage, I would say here, but it was really in New Orleans and said, do not meet at a bar, always have a presentation and only meet once a month. Ryan Davis said everything that I said

was completely wrong and he told me that they meet, he runs Seattle Ruby and they meet at a bookstore that happens to sell beer weekly and don't usually have topics. So that's what we moved the Miami group to. We meet once a week at a bar, we usually don't have a topic, we just sort of have a table

and we talk about computers and it's fantastic. It has worked out so unbelievably well for us. People show up to our meetings, attendance isn't spectacular but nobody feels I haven't gone for like months and months and months, they won't welcome me because I quit showing up. We actually don't care if you show up or not which is great, if you show up, you're wonderful.

If you don't, you're wonderful and we'll see you next time. We don't have any exclusion stuff. If you don't drink or if you're too young to drink, you're still welcome. We actually don't care about what programming languages you like. If you wanna talk about JavaScript or Python or Go, you're definitely welcome.

A few years or sort of a year after we started doing this, Nick Caronto created the OpenHack brand for the same sort of inclusive meetup. So we've been using that and we're listed on openhack.github.io. Within the last couple months, a gentleman named Teff in the United Kingdom made a group called Computer Anonymous

and from there we sort of stole a code of conduct and that's basically the entire group. We show up every Monday at 7 p.m. We'll be meeting there this Monday after RubyCon. We help people, like new people, are welcome to ask questions, work on Rails projects.

Please, we're there to help. If you're experienced and just wanna talk about work or complain about work, we want you to do that too. If you wanna help organize the meetup or come up with presentations, we'd love you to run them by us first and we can help you build out a presentation. That's all I have to talk about for this. If anybody's interested in more, find me later or you can search for my presentation notes on Twitter.

Search for RubyConf and Evernote, which I use to write my notes. And that's it, thanks. Thanks, Bryce. Thank you. How many of you have you heard about the problems of healthcare.gov? How many of you do actually know what are the issues there?

I've been working in the healthcare industry for the last two years and in my experience, the healthcare IT industry is complex because there are rules. You have to follow laws and best practices. You also have to interact with different entities

from doctors, patients, to insurance companies and governments. And you usually don't have a single product. You have to have a very complex product like healthcare.gov, which is complex in extension.

And let's face it, it's complex because the human body is complex and because it's related to money. I'm gonna give you an example about how hard it is to share medical information. And for that, I wanna give you my, I wanna talk to you about my last run last week.

I was running in the morning and my heart, I'm sorry, my chest is starting to hurt. And since my family has a long history of heart disease, I stopped and I started thinking about going to the ER or to scale an appointment with my doctor. And I will probably have to go there.

My doctor will have to take my blood pressure and he will probably recommend some blood work. And for all that, I have to have my insurance card. Don't worry, I'm fine. My heart is fine. I was just called that morning. But if you follow the flow,

it's I have to have my insurance and present it to my doctor. And then I have my insurance and go to a lab. And then if I wanted to see a specialist, my doctor will have to fax my records. Yeah, fax my records.

So there are some companies that are trying to do something to share your data electronically. And there are international standards to share your data. Most of this data is based on electronic data interchange. That's ADI. That is something like sharing files separated by pipes.

And although there are newer versions of this standard based on XML, like HL7 version three, there is no Ruby version of Excel to interact with this version of the standard.

So there are these problems to share information. And the truth is that we as a Ruby community don't have enough tools to interact with all the sets of medical records and medical data available. The other example that I wanna talk about

is if you want to interact with the hellgraph, a tool created by RoomKeeper to collect data from your phone, you can do it with a gem that was built three years ago and was last updated two years ago. And I'm not even sure it runs on Rhenius.

So my point is that there's going to be a lot of information from wearables and medical devices that generate data. And what are we gonna use? Are we gonna start using Java or Go or Node.js to interact with this data?

We need healthcare-focused gems. We need API tools. And we need to follow the standards and try to build on top of this. But especially the healthcare IT industry needs the Ruby community.

So we have two options now. One is you have to visit this address that I have here and participate in open source health IT projects. Or you can eat well, sleep well, and don't get sick so your records don't fax. Don't get faxed.

And tweet me if you have any questions. Thank you. Thank you. All right, I'm gonna try to go to Blaise through this. This is kind of my own personal journey that I've gone through this past year. The talk is learning improv for great good.

And especially how I feel by having learned a certain particular form of improv, common improv, I've become a better person. I could tell you why I got into it, but there's not enough time for it. I wish I had 24 hours for it. The form that I study is called The Herald.

And The Herald is not what you think like Whose Line Is Anyway. It's not the kind of like, there's a preset game that you were gonna play. It's a completely improvised show. It was created by Del Close. And the only thing you get from the audience is one single word.

And a group of people put together a three-act show about 20 minutes long. And nobody knows what the word is gonna be. Nobody knows what the game is gonna be or anything until a few seconds after they start talking.

So I did a little demo with somebody earlier, and it was the talk Raft. So like, oh, this is how we pretty much would go with the word Raft. And that would be the only thing that would come up, right? Raft. And a group of people, a team like that, all bring their own personal intuition, experience,

to the word interpretation, to the word Raft. And unfortunately, they don't all think like me. I replaced everybody's face. They don't bring their own things. So like, going back to the form, oh, they're gonna be three beats or three acts, and each act has three scenes.

And in the first beat, you gotta find the game of the scene and you need to understand each character's mental model, what it motivates, and you ask if the act is way, if this is true about them, what else is true? How Bernie pretty much reacts to everything, how he thinks.

But you have to figure out in about five seconds. So scene 1B1, we'll pretty much go like this, you know, the word is Raft, and one person will step out, doesn't know who's the other person that steps out with him, and everybody else of the team stays back, and he will say,

will you help me? I've been building this Raft for a month, and you don't give me a hand. And the other person going, yeah, but I don't really wanna get out of this island. It's so nice over here. Like, Jesus Christ, there's not enough food. I mean, like, I'm starving. Yeah, but you never look greater than this. I mean, like, you look wonderful.

And it's not, this is like a straight man, crazy man scenario. And it's not just like, then after you have to justify, no, it's not enough that the person is kind of crazy or like has a weird behavior, you have to justify. Maybe I'm the girlfriend that is trying to leave him and get the fuck off the, oh, sorry, I waited at the island.

And he doesn't want me to leave him, or maybe he has a girlfriend that left him and doesn't wanna go back to reality. And then, you know, there's a scene two, like somebody else, two different people take a different interpretation of the word Raft, and a third group does the same thing, and then we go into act two,

and we play a different version. If that's true, what else is true? How can we put, like, this mental model? Like, come on, man, run! It's a zombie apocalypse. Everybody, you know, you can, yeah, but it's okay. You know, I never really liked my brain, you know? I'm not smart. And you just play, like, you know, a game scene three and four and whatever.

Okay, that's great, but why should I care? All right, I'm gonna really have to go fast. Because we don't code in isolation. We don't work in isolation. And a computer programmer usually have, like, I'm gonna introvert, shy, they don't communicate very well, and they're kind of like, it's very hard

to get stuff out of them. And now that I am trying to hire people, they're also mildly autistic, they have, like, a superiority problem. And in general, there's a lot of empathy level. And improv is all about communication and caring about the other person. And not just listening to verbal cues, but non-verbal cues, eye contact, body language, energy level.

And most importantly, you have to understand, it's a skill that you acquire by doing it over and over, that you really have to deeply care about what the other person is saying all the time, and remember everything. And you also must relinquish control, which is very hard to do for a developer. And you must ask for permission,

which we usually don't, like grabbing the keyboard and say, oh, let me show you how to do this stuff. So it really teaches you about empathy. And it helps you understand your coworker, how they think, how you can help them, what's going on in their life, what they want, what makes them happy, and how do my action affects them. And also, yeah, time is over,

better relationship also with girlfriend, boyfriend, parents, friends, and it helps you be in the moment. Most of all, it's more to be nice. You just revert to a kid and you just have fun. It's the most fun I ever had. There you go. Thank you. Thank you.

Okay, so it's actually kind of funny this other talk was right before me because it's actually a wonderful segue into kind of more of the human aspect of software engineering. So I love Ruby. I have a small little company. It's called Polyglot Programming. I'll do a quick little whatever, sail with it. We do consulting, always looking for interesting projects. But today, wanted to talk about kind of the software skills, XP.

How many people here know what XP is? Okay, a good number. So one of the practices that I like to practice quite a bit is pair programming. How many people here have tried pair programming? Okay, quite a few.

How many people here regularly pair program? All right, well, about two years ago, went independent and we have a very small consultancy where we don't have, quite often, we don't have either budget or something else to be able to pair program all the time. And this really bugged me because it reduces the code

that I write, or not, sorry, the bugs that I put in my code, and it gives me really high quality code. And so I was thinking, what could I do? What could I, is there another way that I could get a dev pair and get that quality back in my day-to-day workflow? And so I was looking over, I saw this.

How many people here have cats? We've got a few. And I was thinking, ever since, and so my cat's name is Allie, ever since she was a kitten, she used to sleep in my laptop bag, she would sleep on top of the laptop, and she was always intrigued by electronics. And I thought, what if I substitute out a human dev pair

for a feline dev pair? And try what we call purr programming. So we've been doing, I've actually been doing this now for about two years, and I've learned a few of kind of the best practices with it, because there are patterns for effectively purr programming, as you can see here.

You need to have a very comfortable workstation for both you and your pair, comfortable chair. And we generally prefer to have just the one keyboard setup with a nice big monitor. And we've learned, I've actually learned a few things about this. First of all, how many people here have had their cats

jump onto their keyboard while they're coding? Yes, quite a few. I used to think that that was just Allie looking for attention. Nope, she's actually telling me something. She's telling me, no, it's time for you to take a break, it's your pomodoro alarm. No, you've made a really stupid mistake, don't do that.

And I've learned a few other things too. Cats actually can tell just by the cadence of the way you're typing when you're making a mistake. So when a cat looks like they're sleeping, they're actually still helping you. It's a really wonderful thing. But beyond that too, how many people, a lot of people usually think, well, okay, great, so I've got a cat that's helping me per program and they go, well, it's just like a rubber duck.

No, she drives. This was a really gnarly debugging session that we had here and she just was like, no, no, no, let me take care of it, I'm gonna fix it. And there are other advantages too. For example, there are times when I'm working on a really difficult problem and I'm trying to figure,

I'm stressed, I'm under the deadline or something else like that. And I can just reach over and start petting her. She purrs, it settles us both down. I don't know a lot of deaf pairs that would actually, where that would work very well with. Now for the people though, probably a lot of people here, how many people here have dogs?

All right, how many people out of those people, how many people, how many of you guys are more of dog people than cat people? Yes. So we've looked into that. We have a couple. Their names are Max and Ming. So far though, it just, it hasn't quite worked for us.

It hasn't, their talents don't lie in programming. Maybe they're better at project management or something like that. We're still looking for that though. We have a small subset and we've had a small sampling at this so far, so we would welcome any input on that if somebody has noticed something better with it. Do let us know. But at any rate, and of course in our household anyways, the cat rules the roasts.

We have the cat and the dogs and she rules the roasts. So at any rate, I blogged about it per programming. And there's also a website. All right, thanks. Okay, so hi everyone. Today we're here to talk to you about a game that we are currently working on called Berlin. It has nothing to do with the city.

So I'm Guillaume Marlette. I'm Christian. And you can follow us on Twitter or GitHub. We work for Shopify. This has nothing to do with it. So the game. I'll throw a couple of buzzwords at you and I don't have my speaker notes. So Berlin is an electronic web-based turn-by-turn

artificial intelligence strategy board game. I think I got them all. What this means is it's a risk game that you write in the eye for. So we have a website. Go check it out. You'll be able to replay all the games, see list of AIs, list of users,

and also find all the documentation. Currently we have 58 artificial intelligence and over 3,500 games have been played so far. There are about 80 people here, so this should go to about 130 tonight, please. So a few rules.

So okay, basically here's a map and the arrow points to a node. This is a path and this is a city. City spawns soldiers when you own them. Each turn is played in three phases. Movement phase where your AI tells the server what move it wants to perform. If two or more AIs are on a city or any node,

at the end of the turn there's a combat that occurs and after that every node that is controlled by a player spawns a soldier. So as you can see what you want is to dominate the map in order to gain more cities, to gain more soldiers,

to get more cities, to get more soldiers, and so on and so forth. So here's a quick replay of a game playing. I don't, is it your AI? I don't think so. It's way too dumb. This is probably random AIs. Yeah, those are random. But you can see what it looks like in the replay mode.

Okay, so AIs are self-hosted, so whenever a game starts the server just sends a JSON request to your AI which just then compute the moves it wanna do, then sends back a JSON response to the server.

So where does Ruby fit into this? We're gonna go really quickly. In about one minute we'll build your own random AI and maybe you can beat these two AIs. So there's a gem. It's super easy to use but the DSL is not so great. We hadn't seen Emily's talk yet. So you have to open up the.

and define the self.onTerm method because we hate you. Not true, like I, it's cool. So you get a game object in there. The game object gets a reference to the map, and the map has plenty of helper methods of which control nodes. Control nodes are the nodes that you possess and have at least one soldier on,

so you can move that soldier to another node. So we're gonna go to all the adjacent nodes, pick, well, actually shuffle them and iterate. Find a random number of soldiers that we can move and call game.addMove to move from one node

to the other x amount of soldiers. The only important thing to note here is the game.addMove, that's all you need to do in order to create an AI. So you just need to provide the node from which you're moving, the node where you want to go, and the amount of soldiers you want to move. And that's it. This will create the JSON response for you and send it back to the server as soon as the loop is completed.

So, yeah, I guess that's it. Yeah, that's it. Thanks.