[This podcast is sponsored by New Relic. To track and optimize your application performance, go to rubyrogues.com/newrelic]
[This podcast is also sponsored by railsthemes.com. Have an app only could love? Check out railsthemes.com. They are also giving us some pretty cool swag at RailsConf so find them, get some and thank them for sponsoring Ruby Rogues.]
EVAN:
Hello. Good morning. Everybody take their seats and shut your piehole. Good morning. Are we all disappointed as this is the last day of amazing RailsConf? I know I am, although my feet aren’t. So we’re going to have some announcements before we can get off to the Ruby Rogues panel, which if you’ve seen those guys, I can’t find them. So if anybody could just tell them that they need to be on stage like now, that would be great. So I think David Black has an announcement and then after we do that, we’ve got a couple of things I think you’re going to like and then we’ll get started with the panel. So David…
DAVID:
Good morning. I’m David Black. I’m one of the directors of Ruby Central and therefore, in a sense, one of the organizers of this event. I will say that from my perspective, helping to organize this event has involved a little work and a lot of just watching in awe as other people did an incredible job of putting it together and we’ve (I hope) drawn your attention to some of those people and shown them our gratitude. There’s a couple that I believe we haven’t yet mentioned who are among the heavy hitters behind this conference. One of them is Ben Scofield, who unfortunately could not attend the conference but is your program chair and if you liked the program, you might show your appreciation to Ben for his work on that.
Alright. Also, could you please everybody send a Tweet to Ben, seriously. It’s “@bscofield”. Do we have exact wording?
CHUCK:
I miss you.
DAVID:
I miss you. Wish you were here. So we’ll spam him with Tweets. The other person I wanted to acknowledge is none other than your host, Evan Phoenix, who has not only emceed everything but has also really, in a very good and benevolent sense has been kind of pulling the strings around the conference the whole time and keeping things together and has just done a great job. So thank you Evan.
EVAN:
Thanks David. So we’ll have printed schedules available. They are being printed right now so they’ll be outside. If you’re looking at the schedule online, there is a slight switcheroo, which is actually on the printed one just so that I’m telling everybody so that you know. The first talks that we’re in H and J have been switched so Yehuda is actually going to be in Salon H, just so that when you’re looking at your schedule, you know that if you want to see his talk. It’s actually going to be in this first half rather than in J, which is in the back quarter.
1:
30 on your schedule, so be sure not to wander off. Be sure to stay for those. They’re going to be awesome. They’re going to be amazing. I can’t wait for them. So we have two great announcements that I want to make before I hand it over to the panel and I need Grace from Spiceworks to come up here and give me a hand with that.
So in the past, we’ve sort of put together RailsConf, not at the last minute, but you know sort of six months ahead of time. We decided we should start a really good tradition and that tradition we’re starting right now is we’re going to announce next year’s RailsConf at this year’s RailsConf.
So I’m going to actually… this is embarrassing. Yeah, so I don’t have the exact dates on me. Isn’t that funny? But I’m happy to announce that, (and I’ll check on the dates and I’ll let you know right at the end of the panel), but it’s going to be May in Portland, Oregon.
Is it going to be two weeks? Yeah, you’re going to have them for two weeks. It’s actually going to be a commune. Oh yeah, it’s in two weeks. So the CFP opens now. It’s going to close in an hour. No. No.
Embarrassingly, we’ve actually been moving the dates around because it’s a year ahead of time so that’s why I don’t have the exact dates in my head. I’d rather tell you a rough date range rather than give you the exact wrong dates and then have to go back so…
CHAD:
(April 29th to May 2nd).
EVAN:
So it’s April 29th to May 2nd. So those are the dates. Thank you Chad, my right-hand man. So additionally, the first person to get a ticket is going to be decided right now. So Spiceworks has raffled all of your names off and is going to give away a ticket to that next year’s RailsConf right now. So I’ll turn it over to Grace right now.
GRACE:
Thank you. I’m kind of a lot shorter than you are. So thank you all so much for stopping by the booth and just coming over to learn a little bit more about us. I was really hoping we’re going to get a much sexier like ”Emmy-type” award looking thing going on here but it’s just an envelope, point being we want to give away a ticket to next year’s RailsConf to Stephen, I’m hoping I’m saying this right, “Zeiler”?, “Zeeler”? are you here? Woo hoo!
I think we’re going to try to do the same thing again next year, so just stay tuned and stop by our booth next year. We’ll be there for sure. Thank you guys! Have a great conference!
EVAN:
Congratulations buddy. And so without further ado, because I know they’re going to eat up the entire time and more. I’m going to over to the Ruby Rogues podcast.
JOSH:
Are we on? We’re also doing a raffle. The first prize is a day pair programming with David Brady. Second prize, two days pair programming with David Brady.. *laughter*
DAVID:
You can buy your way out.
JAMES:
Enter music.
DAVID:
You had a music.
JAMES:
Yeah, it doesn’t seem to work for me.
DAVID:
Forward button not the play button.
CHUCK:
Hey everybody and welcome to Episode 52 of the Ruby Rogues podcast. That’s right. We’ve been doing this for a year. This week on our panel we have Avdi Grimm.
AVDI:
Hello, hello!
CHUCK:
We also have David Brady.
DAVID:
Hello!
CHUCK:
Josh Susser.
JOSH:
Hey everybody!
CHUCK:
James Edward Gray.
JAMES:
Hey guys!
CHUCK:
And I’m Charles Max Wood from teachmetocode.com and this week, we’re going to be talking about what Rails developer should care about. Now, we’re going to do something a little bit differently, where each going to take a few minutes and talk about what we think Rails developer should care about and then we will start the panel discussion and start answering your questions.
So, is James first? Alright.
JAMES:
Okay. So this was Josh’s idea for what we should do for a topic and when he was explaining it to me, he’s all, “You know, just tell them what you think is the most important thing that they should care about and I said, “Well, that’s easy.” So I’m done. Any questions?
*laughter*
I’m just kidding. One of the cool things about doing a podcast all the time is, you know, we learn so much from each other. I bring guests to them that, you know, I want to talk to and learn from and they do the same. Avdi brought Dan Kubb on the show. So I really learned a lot from that episode and this was one of my favorite quotes on Ruby Rogues ever, “All codes is experimental”. And Dan Kubb really talks a lot about this and how he does little experiments with himself, you know, trying things out over a period of time and then grades it. “Well that was successful,” or “Nope, that was terrible,” you know, and learned to improve that way. And there are lots of reasons to do that. You should go listen to the episode for what many other reasons are, but I want to talk to you about a different one. Another reason I think experimentation is so important. I want to tell you a story of how something gets invented, something you’ll all know.
So you guys know that Sputnik went up like 1957 (I think) and it’s up in the sky traveling around. (Oops I didn’t do that very well. This clicker is really in the wrong way. There we go.) So Sputnik goes up in like 1957 and is traveling around the sky and then these two guys, the one on the left is Guier, he is a mathematician, and the one on the right is Weiffenbach, he’s a physicist. They started listening to and recording Sputnik, you know the beep beep beep beep sounds and they can hear variations in the sounds, so they decided to use “Sheldon” (from The Big Bang Theory). No I’m just kidding. They used the Doppler Effect, (which is what Sheldon is dressed as). You like that costume?
They used the Doppler Effect to determine the speed that Sputnik is moving around, right, by the variations they can hear in the sound. Then they used the slope of the Doppler effect to determine the distance Sputnik is from their known location on the ground, right? Then, they put all those numbers into their fancy new UNIVAC that takes up like a room in their building and put some numbers. And doing that, they basically reversed engineer Sputnik’s path through the sky, right?
Then their boss, McClure, he’s the third guy in the middle on that picture at the top. He says, “You guys have found an unknown location in space using a known location on the ground. Could you do the opposite, because I have these nuclear submarines and in order to land a nuke in the right spot, it’s kind of helpful to know where my sub is in the middle of the ocean, right? So could we put up a bunch of satellites and using their known location in space, could we find an unknown location on the ground so we could target nukes?”
And then, it progresses on and a president 30 years later opens this system up as a great platform everybody can build on and grow and expand, right? What is this I’m telling you about? What is it?
Shout it out.
AUDIENCE:
(GPS!)
JAMES:
Right. This gives us GPS, which now we all have on our cell phones, right? This is invention. This is how it happens, right? Guys noodling around, ideas moving into other ideas and stuff like that. So, I think that’s why it’s an important part of our culture and we do that well. But let me tell you one other story.
There is a guy that has Asperger Syndrome and he writes about his challenges with that disability. Him and his wife have this system for keeping track of his inability to learn social cues and so basically, you know, they’re driving on the road, he’s listening to the radio or they both are. She is singing along and he changes the radio, right, and then she’s like, “Seriously?” You know, “I’m singing,” and they have this system and he writes it down in what he calls “The Journal of Best Practices,” “Do not change radio while wife is singing along” Us programmers could learn from this, right? We could get better with our social skills, and it’s really good. He uses his obsession to basically invent empathy which he doesn’t really have, right? And he is able to control it and that’s a good story but it can go too far.
For example, one night, you know, they’ve ordered out, they have leftovers in the fridge, and she comes home from work thinking, “Oh, crab ring sounds great. I’m going to have some,” and it turns out he ate all of it, right? So she opens the fridge and she’s rolling her eyes and chewing them out, and she says, “You ate all the crab ring?” And he’s all, “Uh oh,” you know, “I’ve screwed up again,” and he’s getting his journal and going to make the best practice, and she’s all, “No, no. This is normal, you know. You’re allowed to eat all the best stuff in the fridge and I’m allowed to roll my eyes and mock you and that’s just part of being married and its normal,” and she actually says this great thing to him about what that means and it’s this, ----- right? Okay.
For the podcast, it says, “Here’s your new best practice; not everything is the best practice,” right? And that’s kind of part of this whole experimentation thing. I was kind of talking about where I think we want to go. So I started with Firefly and I'm going to end with Firefly because nobody says it better than Mal. He said, “Try to see passed what she is and on to what she can be,” and when Zoe asked, “What’s that Sir?” He said, “Freedom, is what.” I just know he’s talking about Ruby there, don’t you?
Alright. Who’s next?
AVDI:
Let’s talk about introspection. I visited Hashrocket last week for a week of pairing and sharing knowledge. It was an amazing experience, but I found myself wondering as I often do these days why me? Why would they invite me here? I mean, I’m not the biggest Rails expert in the world. I am far from a prolific open-source contributor. And when I’ve asked people, you know, about this, I get answers like this, something like, “You don’t just have an idea, you speak up, you give a name to it, and you’ll explain why,” and this makes me think of Kent Beck and the process he described for writing “Smalltalk Best Practice Patterns” where he says, “I wouldn’t type a character if I didn’t know what pattern I was following and doing. I write five characters and then I go write a pattern, then I write one more character, and I go write another pattern,” and this is an extreme form of deliberate mindful coding.
Now, if there are four words which sum up the polar opposite of mindful coding, I think they’re “shut up and code”. I think in some context, this can be acceptable, in the context of a team, a project under a deadline. It can reasonable to say this, but I think in the context of online discussions of software development, it’s just pure poison. Because, when I think about online discussions of software development, I think about wiki-wiki, 35,000 pages (and counting) of people like Ward Cunningham, Kent Beck, Martin Fowler, and many others openly discussing programming minutia since 1995.
You can get a pretty broad programming education just from reading wiki wiki. I know. I did. And all
I can think of when I think about wiki wiki is, “Thank goodness they didn’t shut up and code.” Here’s Kent Beck again, “The pattern is a decision an expert makes over and over”. Pattern hatching is the process of giving names to the things that we do everyday. So I want to encourage you to do this. I want to encourage you to give names to the decisions you make. And a great way to do this is to write code (of course), think about the process of writing the code, reflect on that process, explain that process to someone else and explain not just what you did, not just how you did it, but why you did it, why you made the choices that you made. And this can be in the form of talking to your pair partner. They can be in the form of writing a blog article, and I think this process of introspection will make you a better programmer and a better communicator. And I think that’s why introspection is something that the Rails developer should care about.
CHUCK:
So while he’s switching, I did notice that a few people wore some funny hats other than us.
JAMES:
Stand up if you have a good hat.
CHUCK:
Stand up if you have a cool hat on. I’ve seen one over here.
JAMES:
That’s awesome. Sweet.
DAVID:
Alright so. Is this on? They just know I’m loud so I’ve turned it down. Ok cool. So I want to have Rails career anti-patterns. How many people are willing to admit that they are fresh off of another programming? I got PHP boat but it could be Java or DotNet. Everybody, show of hands. How many of you are willing to admit that you’re kind of new to Rails, you’re coming from another language or from no other language? We’ve got a few hands out there. So these comments are directed directly to you but they are also valuable to those of us who feel that we’ve been around the block a few times. Being fresh off the PHP boat is not an actual anti-pattern so if you are, welcome.
What is an anti-pattern is trying to program Fortran and Ruby or Java or DotNet or PHP, Python, C++? Five years ago, all the Java guys were coming in to Ruby and they were dragging in their dependency injection. All the DotNet guys were coming in and they’re dragging in their delegators and all the three Haskell guys were coming in and they’re dragging in function pointers and all this stuff. And the promise is they’re programming knowledge to Ruby with their brain in read-only mode, and I did this with C++. I had a very good fortune. (I’ve told the story on the podcast so I’m going to abbreviate really quickly).
I had a very good fortune of writing a very long C++ program in Ruby and I did it for the Ruby Quiz which was curated by a guy named James Edward Gray II, which with the name like the “II”, you know, when he could just be Jr., you know what you’re in for, and boy was I in for it and boy did I deserve it. And what James really hammered home for me very publicly on rubyquiz.com in fact, is he took a 200-to 300-line program that I had written and shortened it about 50 lines of idiomatic Ruby. And what he taught me is that Ruby is not I call it as a --- language. That’s just a great word, but block oriented, lexically-scoped language. PHP, C#, Java, you know, Python, C++, these are block-oriented, lexically-scoped languages. Lisp is not. Ruby is not. So you can’t just learn where the semicolons and braces go and think that you’re good. You can’t just take what you’ve learned on those languages and go.
So what I’m saying is learn Ruby. This is a key anti-pattern that I see, not just among Rails programmers but among Ruby programmers in general. You have to learn Ruby like it’s a whole new language because it really. really is. Because it’s got parts in there from SmallTalk, it’s got parts in there from Lisp and unless you know those languages fluently, you need to treat Ruby like it’s its own language.
The second thing you need to know is that next anti-pattern is, not knowing that JavaScript is CRAP. Alright. Languages surprisingly are well cocked up for a one-week ---- but it’s the environment. As you move from one browser to the next, you have no idea how much stack size you have, you have no idea how much heap space there is until your program stops working. In fact when Mozilla makes an upgrade, they recently, recently (okay like a year and a half ago), they had a stack size of like 40,000 and then they changed the stack size to 8,000. And all these functional programs that used a lot of recursions stopped working. There was no way to find out about this except that all of a sudden you were getting bug reports from your users that JavaScript is not working.
So remember, JavaScript is crap. Forgetting this is a career anti-pattern. The next anti-pattern is not knowing JavaScript, because it’s everywhere and you are going to need it, which leads to my third point which is not knowing CoffeeScript because CoffeeScript writes better JavaScript than you do. Okay. Letting Rails do the object orientation for you. I don’t have time for this rant. We did a whole show on this and then we did a whole another show about it. Seriously, kids don’t do this. Rails gives you all these great generators, all these great things. I love all these people that say, “Oh I get object orientation and top down and then its messages and it’s da, da, da, da, da” and then they sit down and the first thing they do is Rails generate model.
Okay, next slide. Not joining the community is a key, key, key anti-pattern. I see this especially among the PHP programmers specifically not just like there’s an archetype, where we go off alone. The DotNet guys kind of generally get the idea of when you’d be going out the curves but I hope all of you are going back home to your local Ruby user groups and talking about what you learned at RailsConf. Get in to the community, learn what you can. What I’m saying is learn and then turn around and teach. That’s absolutely the key.
Last to our anti-pattern. There may be commercials when you’re really good, they call you what? Nobody knows this. This is awesome. Okay. So from 1893 to 1986, the answer to this ad jingle was “Cracker Jack”. Then from 1986 to 2005, if you were a C++ programmer, when you’re really, really good, they called you a “guru”. Now from 2005 to 2010, they called you a “rock star”. Now you noticed these time periods are shortening and they’re shortening exponentially. From 2010 to 2011, you were a “ninja”.
*laughter*
From March 1st of 2012 to March 1st of 2012, actually from March 5th 2012 backwards in time to March 1st, people found out on March 5th that this word had come in to an existence and they found out about it by finding out that people were really pissed off about it. You do not want to be a programmer. Okay. There’s something about Rails or Ruby programmers that quickly tarnishes any label we put on them and that’s because of arrogance, okay. Don’t be a douchebag guys. It’s all I can say. Don’t get cocky head and that’s my entire presentation.
JOSH:
Okay. Good morning RailsConf. It’s good to be back. It’s been a few years since I’ve been here. So I got to apologize for the hat. I really wanted to wear a hat that brought some of the character of San Francisco with me, but I couldn’t fit it in my luggage. So, sorry about that. This morning, I want to talk about the important quality of prudence, which I think is important to all developers especially Rails developers. So, what is prudence? Well, let’s start with the definition. Prudence is the quality of being prudent. That’s not very helpful.
DAVID:
Someone called for a thoughtology?
JOSH:
Let’s push the stack. So being prudent is acting with or showing care and thought for the future. So I’m very concerned about the future. It’s where we’re going to spend the rest of our lives. More importantly, it’s where our code is going to spend the rest of its life. And has anyone who has been around can tell you way more than half of the cost of code is incurred after you write it, its maintaining it, fixing bugs, adding new features, supporting it to new platforms, all that stuff. So prudence is a very important quality in developers. Now, DHH started us off Monday morning talking about fear of progress and why we should all fear Rails Fork. So he said that old guys like me are afraid of change and I can call myself an old guy because I’ve been programming since before David was born.
DAVID:
No you weren’t.
JOSH:
I was.
DAVID:
You --- 1971.
JOSH:
Absolutely. He was born 75.
DAVID:
Oh different David.
JOSH:
Yeah. Shut up. That’s other David, David Hansson. So he said loss aversion is the pillar of conservatism. And then the next day, Aaron came along and told us that experienced developers have a lower tolerance for technical depth. So well, I think both of these were valid perspectives at times. They didn’t really ring through to me for my experiences being a Rails developer. My experience is I have a limited budget for risk in my projects and so do you, whether you realize it or not. So what is risk? In daily life, risk is whether or not you’re going to succeed. If you’re walking across the street, do you get to the other side or get hit by a bus?
In programming, unless you’re trying to solve the halting problem, you can pretty much do anything you attempt given enough time and coffee. So what it comes down to for me is, I hate having other people spend my risk budget for me. So when the asset pipeline was introduced in Rails, somebody else was spending my risk budget for me. I had no idea how long it would take me to do stuff in Rails because the asset pipeline kept jumping in there and extending my schedule unexpectedly.
On the other hand, Bundler was a huge risk production for me because it took all of that insanity about Gem version clashes and just made it go away. So the little bit of effort that I’ve to put in to creating a Gem file completely got rid of that amount of unexpected risk for me. Okay. So no talk is complete without an inspirational quote.
Now, Gustave Flaubert who wrote “Madame Bovary,” which I haven’t read despite the that said, “Be regular and orderly in your life like a bourgeois, so that you may be violently original in your work.” And this is pretty much my philosophy of how to write a Rails application. I want everything to be simple, understandable, predictable, and reliable in general, so that when I get to the point where I need to do something extreme, I have a solid foundation to work on. You know, it’s pretty easy to stand balancing on one foot unless you are on a roller coaster, on a boat, in a rainstorm.
JAMES:
I don’t find either one very easy.
*laughter*
JOSH:
Okay, point taken. So I think I had some other stuff to say but I’m probably over time. So we’ll just move on. Alright. Thanks guys.
CHUCK:
I’m going to try and make this quick. When we were talking, I don’t remember who said it but somebody pointed out that Living Social was like this whale in the ocean and they were kind of slurping up all of the krill developers out there. Every time I think about that, it brings to mind a specific scene from Finding Nemo where they’re talking to the whale and then the Krill swim by, “Oh look, Krill. Swim away!” Anyway, so it really is a valid thing. I mean, how many of you work for a company out there that is looking for Rails developers? Just raise your hand.
JAMES:
Most of the room by far.
CHUCK:
Yeah. Most of the room, right? So is it safe to say that there aren’t enough Rails developers for all of the companies that want them? So I’m from Utah and I had this idea.
*laughter*
You know, where do we get more Rails developers? We all know that languages are religion, right? So let’s go find us some converts. And as I thought about it, I thought about there are kind of two different areas that we can go to find people to come in to our space. *laughter*
JAMES:
That’s because he is also from Utah.
CHUCK:
Yeah. David is also from Utah. So anyway, we need to have these wins in specific places. One is we need to convince developers to try Ruby and try Rails. The other area is we need to convince companies to adopt Ruby and adopt Rails. And so my thought is, and if you know anything about me you’ll also know that I’m a huge soccer fan, (I’ll get to that in a minute). But anyway, as we’re doing this, as we’re moving ahead, we don’t want to slow down and wait for these people to come up to speed. I think DHH had a valid point in that we want to keep, progressing, and so somebody gets out in front of us and says, “Wait stop, what about the new people?” I don’t think that’s the responsibility of the framework or the language.
But at the same time, we need to be able to put this ball out in front of them so that they can score. We need to be there for the assist and I think it’s the community’s responsibility to reach out and make sure that the new developers that are coming in have this opportunity to learn Rails and to pick it up and to really run with it. And we also need to make it easier for companies to have big wins with Rails and so how do we do that? Well, we have to make a kind of a grass roots thing, right? The companies aren’t just going to pick up Rails because it’s out there. So we need developers who are going to go out there and convince the companies that they work for that they need to be using Rails. So how do we get in with these developers? I mean, the newer developers, you know, we have a bunch of things that will help them pick things up. We have Hungry Academy, Code Academy, Code School, RailsCasts, you know, make it very accessible for people who are just learning this stuff to kind of pick it up.
But, I think we need to kind of take this a step further. We need to go out and find those people who were in the hidden religions like Java and DotNet and convince them to at least give it a try. And they also have a lot of the things that we kind of take for granted. So I don’t know how many of you are familiar with some of these websites. ShowMeDo is a place where you can get a lot of information about Python. You know, interestingly enough, they have a whole bunch of content on Ruby and Rails, and I think they have the first 15 episodes of RailsCasts and they have a couple of videos done by DHH. They’re all from 2007 so they’re not up to date. I’m actually working with Pluralsight to get them a Ruby and a Rails course. They’re DotNet training website. JPassion is for Java developers. I went and looked at the O’Reilly School of Technology because they offer online courses in just about every technology except Ruby.
I think it’s really interesting that, you know, we haven’t reached out to these others places and tried to solve this problem where we have way more jobs for Ruby developers than we have people. And the reason this is important is not just so that, we can have our pick of jobs or so that we need to maintain this momentum. We’ve had this awesome momentum for 10 years with Ruby on Rails and it’s being adopted by more and more companies and it would be a real shame for these companies to abandon Rails because they can’t find developers. It would also be really nice for some of these companies that you work for, to be able to find the resources that you need so they can move ahead in the ways that they need to. I think it’s a really, really important thing for us as a community to reach out to these other areas.
We’re not trying to convince them that Rails is better, we are just trying to convince them to try it, and once they try it, then what happens is they find people and they’ll try it for the same reason that Dave Thomas kind of brought Ruby to us. You know, because he says try a new language every year (which is something that everybody should be doing) but he also just tried it out because it was this interesting language from Japan and here we are now. And then as they try it, then they’ll take it back to the company, they’ll do some skunkworks projects, they’ll find ways of implementing it within their company, and pretty soon, these companies will go so you built that in a week and it solves this major issue for us and that’s how we get in the door. That’s how we make the difference, and as we have more adoption from both companies and programmers, then we begin to not only have interesting conversations about where they’re coming from, but we begin to solve this problem where we don’t have enough people. And we also solve the problem of having more companies that will train developers that they’re hiring in Ruby and Rails.
So that’s pretty much all I have to say about that. And one thing that we want to do is we want to open up a community where we can talk to some of our listeners. It’s also a nice way we decided for people to support the podcast. And so what we’re talking about is, we’re going to open up a mailing list that’s just going to be a Google group. It’s going to be a closed group. It’s going to cost $10 per year, (which is kind of your way of helping us out and covering some of the costs of the podcast), but at the same time, you know, we want to open up the discussion a little bit more about some of the things that we’re talking about and see what your opinions are.
So if you go to parlay.rubyrogues.com, just put your email address in. It’d nice if you click some of the shared links afterward but you don’t have to. As soon as we have this ready for you to sign up, then we’ll let you know. So that’s what we’ve got going on, but anyway, I just want you, if you have friends that do DotNet or Java or anything else, reach out to them, and also reach out to us through parlay.rubyrogues.com. Thanks.
JOSH:
So we’re technically out of time but because we got started late, we’re going to go I guess another 15 minutes or so, so we have time for questions.
JAMES:
We have the hats. They’re going to have to drag us off stage.
CHUCK:
They’re going to raise this and make it into plank.
DAVID:
You’ve got time for questions.
EVAN:
The mic is up here. I have the mic so come up here and ask a great question. I’ll kick things off since no one else is.
JOSH:
We’ll we do have questions from online but why you don’t give it first.
EVAN:
Well then you better start lining up now because there’s going to be a big long line in a sec so get up and run up here.
JAMES:
I’ll go ahead and hit the first question we saw online. Ryan Bates wanted Josh Susser to define supercalifragilisticexpialidocious.
JOSH:
Okay, supercalifragilisticexpialidocious is atoning for educability through delicate beauty.
JAMES:
He’s so had to look it up.
JOSH:
Yeah, it’s amazing what you can learn on Wikipedia.
EVAN:
Can we get a definition for Wikipedia?
JOSH:
No. Okay, so the other, let’s see… Tender Love’s beard, how can it be tamed? I don’t know. I don’t have experience with beards. Anyone else?
AVDI:
Yeah. We just have to contract that out to ----.
JAMES:
Yeah.
JOSH:
This was a really interesting question we got from Paul Swaggerty. He said, “Some of the comments made the other night at the Keynote by Rich Hickey I found very interesting regarding simplicity. However, some of his comments seemed to violate core principles of good OO design. Specifically, there didn’t seem to be much information hiding going on and it seemed like there would be a lot of passing around clumps of variables void of dry functionality to handle the keys and values being passed around. Am I wrong? Can the two perspectives be reconciled?”
JAMES:
No you’re not wrong. Next.
*laughter*
DAVID:
Alright. No more questions. We’re just going to take the rest of our time.
JOSH:
I have a strong opinion about this. So Rich was talking about functional programming. He wasn’t talking about object-oriented programming. The two are very different approaches. Functional programming is valid in a lot of areas. My personal philosophy is that, object-oriented programming is much better at modeling the kind of problems that we have to solve for the kind of tasks we’re doing. So I’m a much bigger fan of object-oriented programming. I think functional programming got started in the ‘50s and it still hasn’t become a big success, so I sort of stopped waiting. *laughter*
CHUCK:
I’ve decided that I’m going to define a Hash that has like 5,000 keys and pass it to my methods to see how that works.
DAVID:
I have no problem with OO and FP. I just monkey patch to Hash to have the methods I want.
JOSH:
That’s called JavaScript.
JAMES:
One of the problems with what I think Rich Hickey was saying is he made a false assumption there. He said, “We should use this thing because it’s the simplest thing possible.” Okay. That’s true. That thing is simple, but if you take a simple thing, plus a simple thing, plus a simple, thing plus a simple thing, you’re not guaranteed to get a simple thing on the other side, right? That could be complex, right?
JOSH:
Okay. Let’s take some questions from our adoring fans.
1:
Hello. Hi guys. So I wanted to play a quick game with you all. I’m going to ask a question and I want you all to give good advice at the beginning and then horrible advice at the end.
JAMES:
So backwards from what we usually do?
*laughter*
1:
So all these going to give reasonable advice and James, you have to give horrible advice.
JAMES:
Okay.
1:
And you get progressively worse as you go down the line. What’s a good way to use instance.exec? What’s a good way to use instance exec? The meta-programming.
AVDI:
Oh boy. What’s a good way to use instance exec? To set up a context for a DSL that doesn’t require an explicit receiver.
JOSH:
Good answer.
1:
With Ruby Mine?
*laughter*
JOSH:
And I need like half good half bad advice.
1:
Yes.
JAMES:
Right. Right.
JOSH:
Oh instance exec, you should use it to insert methods into other instances so you can use it to do a def method.
DAVID:
Mostly bad.
JAMES:
Semi-bad.
CHUCK:
Semi-bad. I’m trying to figure out where that is so.
1:
Go ahead and go all terrible.
JAMES:
All terrible?
CHUCK:
Yeah. The only thing that comes to mind when he said DSL, I was thinking what’s the worse DSL in the world and that’s XML so I don’t know.
JAMES:
It’s right, XML
DAVID:
Right XML.
JAMES:
So and then I have to give totally bad advice for using instance exec? Maybe just instance exec like Rails’ API and put it all in one namespace, you know, and make it easy for us to get everything.
Less typing.
JOSH:
Terrible. Very well done.
DAVID:
I actually worked on a project where we stored lambdas in the database as strings.
*laughter*
I think that may qualify as a horrible answer to that question.
AVDI:
I can one up you guys. Instance exec’ing whatever you get back from a user input field.
JAMES:
Yes.
CHUCK:
Yes.
JOSH:
Nice one. Excellent. Thank you Avdi. Thank you.
AVDI:
Just teach the users Ruby and you won’t have to do nearly as much work. *laughter*
2:
Hi guys. So thanks by the way for bringing up the idea of being a missionary. I think we need to probably go one step further and say it’s not just that we don’t have enough Rails devs so we don’t have enough devs, right? So my good friend back home who works at Living Social Mike Gehard, he takes upon himself to volunteer maybe an hour out of every week or maybe more I’m not sure exactly what his policy is to teach new devs like from scratch just to grow them. And my question to you guys is how as a community can we start to do that more?
CHUCK:
So I’ve got a few thoughts on this. I mean we did talk to Jeff Casimir, I don’t know if he’s here, about Hungry Academy.
JOSH:
But Steve Klabnik is.
JAMES:
Yes.
CHUCK:
Well that’s right. I’m never going to leave that down am I? So anyway, I’ve also talked to a few other people that have been involved in community programs like this. I know that there are programs that teach kids, which I think is really cool. And I think honestly that that is one of the best things that we can do just because we expose the kids to programming and then they realized that it’s something that they can do and something that they may be interested in. So, we can kind of reach out to them that way. I also talked to a woman by the name of Heather Payne. She lives in Toronto and she runs a program called Ladies Learning Code and they just organized like every few months they have a weekend that people come to and learn how to program different things. I think there’s a lot that can go on there.
I think the other thing is that we can also just be more open as companies and allow people to come in and see what we do and really I think the big thing is just kind of opening that spark up and saying, “Look, this is something that you can pick up,” because a lot of people think programming is hard and good programming is hard. I’m not saying that it’s not, but if people realized that a lot of the basic stuff is relatively simple and that’s something that they can learn to do, then from there you can kind of move on to, “Okay now here’s the next level,” you know. Here’s the point where you can actually contribute value and then you can move in to, “Okay, here’s how you, become the guru, ninja, expert programmer, or whatever.”
JOSH:
Okay. I guess something a little more practical to say. You’re being so impractical, Chuck.
CHUCK:
It’s a gift.
JOSH:
Sarah Mei, are you around this morning? So I got to put in Sarah, stand up so people can see you. So Sarah has been doing amazing work with RailsBridge doing outreach training new developers, some of whom have never developed before. It’s primarily focused on bringing women into the Rails development community but if you’re a guy and you a bring a woman with you, you can come to their classes.
CHUCK:
I’m still developing.
JOSH:
So very practically, one thing you can do to expand the developer pool is go volunteer for RailsBridge and help teach their free classes. So go talk to Sarah about that.
DAVID:
The only thing I found is get away from the programming waterholes. Go find other waterholes or watering holes where other people are congregating outside of the programming field. So if there’s a launch of event near you or if there’s a startup weekend or something that’s a few degrees out of the programming niche, you will find people there who have lots of great business ideas who don’t know how to program and these people love it when programmers walk in the door and you can make converts very quickly.
JAMES:
I’ve had that experience too like, you know, be involved with some group stock club at one point and stuff like that and just bringing the tiniest bit of technology giving them a wiki, you know, for example like changes their whole world, you know.
WOMAN:
When is the Rails community going to be half women?
*laughter*
JOSH:
Go talk to Sarah.
WOMAN:
I already did.
*laughter*
JAMES:
Chuck is converting.
CHUCK:
I’m still developing.
JOSH:
No I don’t want to make lie to that. I think diversity in the community is a really important topic and, you know, I do what I can to support that. I really do what I know to do right now. I’m totally open to new ideas if you have suggestions. I want to hear them but basically, I just try and treat everyone in the community with respect and give them the opportunities that they merit.
CHUCK:
Yeah I think being respectful and things like that is kind of the baseline of what you can do though. I think things like RailsBridge really kind of get it. They don’t really kind of get. They really get it and we need to be involved. So somebody this morning said that, you know, the guys just have to be polite and then the women are responsible for bringing the women. To a certain degree I think that’s true because women tend to look for people that are like them and, you know, they’re more apt to be involved if there’s a woman there. But that doesn’t mean that we can’t reach out to them too. And for some of them, someone like them is just somebody who’s friendly. So really, not just being polite and not just being abrasive isn’t enough. I think we really do need to reach out and be the kind of people that they look at and say, “I want to be involved in this community and I can learn from them.”
JAMES:
It is really important like we interviewed Angela Harms on the podcast recently. Did you guys listen to that episode? Right. Everybody keeps telling us that’s like one of their favorite episodes. They choose one of the best guest we ever had, you know. It’s really great which definitely be pushing that forward in any way you can. So we’re doing what we know to do and if you know of other things, please let us know because we’re interested in that.
EVAN:
I’m going to use my mic power to expand on this for a second. How many in this room got started in programming in lets say, high school or earlier? Raise your hand. So I definitely think that we should do whatever we can to get as many diversified people into the community as we can of all genders. But the problem is that, a big problem and a big thing if we always try to just sort of do the top people, the people who are already be in programming, we’re going to really limit ourselves. So that’s why I think like KidsRuby is really the most important thing we can do. Because just imagine if all of the people, you know, like if there was like code camp for 8-year-old girls that kind of thing as much as there being like more focused on like, “How do get, you know, like young boys into programming?” That is what it ends up being so I think that’s something to think about.
2:
So you cautioned against bringing baggage from other languages to Ruby. But, what are some good examples of cross pollination between languages?
JAMES:
I think Ruby has a lot of that, right? I mean, let’s see… New languages do we use everyday? HTML, JavaScript, Ruby, CoffeeScript? I mean, just that Bash, right? We use Bash all the time. Any RVM users here? I think Ruby does a pretty good job of using languages for their different strengths, right? Even companies like Twitter, they grow up in Ruby and then kind of move on to other things because their scale gets to the point where it just demands it, you know, as something faster and more efficient. A lot of times they still use Ruby for the parts Ruby is good at and try to replace back end services with something that moves a little faster and stuff, right? I feel like we do a pretty good job with that but I think the point I would stress is that we should try to keep everything, you know, in roles it’s great at. You know, if Node can build a better server for whatever our particular needs are, then let’s use some Node, you know, or whatever.
JOSH:
I think what is pretty good at bringing in stuff inspired by other programming languages, Rack was brought in from, what is it called? The Python. There’s a Python.
JAMES:
Yeah it’s Python.
JOSH:
What was it? Yeah, right. WSGI. So Rack was based on that model. There’s a number of pieces of technology in the Ruby ecosystem that came right from Python inspiration or, you know, something is right from Java. The language itself is pretty much a blending of SmallTalk and Lisp with a little Perl thrown in. So it’s kind of the ultimate Polyglot language and a lot of Perl.
JAMES:
Yeah.
SARAH:
Hi.
JOSH:
Hi Sarah.
CHUCK:
She’s going to set it straight.
SARAH:
I’m Sarah Mei.
CHUCK:
Thank you.
SARAH:
I wanted to just make a quick comment and so the first thing I want to say is that, I’m trying to get more women into the Ruby community. The reason I’m doing that is because I think the men in the Ruby community are awesome. I wouldn’t be doing this if I thought that I was bringing them in to like a hostile irritating environment. So that’s the first thing.
The second thing is that the workshops really have two goals in mind, and the first one is to get people interested in Ruby. We get about half people who are already developers but in a different language and about half people that are totally new.
The other thing is equally important is that we draw volunteers (mostly men) from the local community and we want to get them to know the people who are taking the classes because if you know someone at a Ruby event, you’re more likely to go to it even if that person is a man. It doesn’t have to be a woman, right?
So we have two sort of equally important things that we’re trying to do to bring these two communities together and you can help by just coming in and being a TA and you don’t have to be an expert but I just wanted to say that and thank you for giving me this forum.
JAMES:
Sarah, we have a question for you. When will you be coming on the podcast?
CHUCK:
Yes. I was going to say what do you with your Wednesday mornings?
SARAH:
Sign me up. Tell me when.
CHUCK:
Alright. Will do.
EVAN:
Okay. So we started a little late so I’m kind of letting this run late. So we got one last question which I’m sure is going to be a really easy question. It’s not going to be controversial in any way, shape, or form, and since it’s going to be so easy, I’m going to ask you to try and limit your response just so that we can kind of move on. Okay. Thanks.
JOSH:
You can ask.
3:
So there was a comment earlier about how like functional programming is sort of hasn’t really succeeded since like the 1950s. And yet at the same time part of it is like people gets so hung up about trying to do things in object-oriented program but if you really think about it, the languages that object-oriented programming are like Java, Eiffel, Smalltalk, and while we use a lot of Smalltalk features, the fact of the matter is why should we be concerned about object-oriented paradigm?
Shouldn’t we be concerned about like Ruby paradigm or the Rails paradigm?
DAVID:
Wow, we’re going to go overtime.
CHUCK:
So this has come up a little bit. I don’t know if it’s ever come up on the show but, you know, we have talked a little bit about the balance between the functional parts of Ruby and the OO parts of Ruby and the strengths of both. I think there is some validity to that where; yeah we need to think about what pieces really, lend themselves well to the problems we’re solving.
AVDI:
So I’ve been thinking a lot lately about why objects matter since I’ve been writing about it a lot and this is the best answer I’ve come up with yet. So I’ll make a strong assertion which is that, all sufficiently large and successful systems evolve into object-oriented systems. I’ll back that up just by saying if you look, you know, I don’t have slides for this right now, if you look at the architectural diagram of any large successful system which usually becomes multiple systems, maybe on different physical machines maybe different processes but usually large, complex systems become something that on a broad architectural diagram looks like boxes with arrows in between them which indicate well-defined protocols in between these cells of a system.
Alan Kay described his original idea of object-oriented programming as cells sending each other messages. That is the way that we as humans, think about our large complex systems just sort of naturally in order to keep ourselves from going insane. I think the question is not so much, you know, why care about object-oriented systems. It’s more there merit in reflecting that sort of “cellular structure” down at the lower level as well as at the higher level where it’s always going to emerge? And my answer to that is yes.
DAVID:
Just a second when you said good functional programming and good object-oriented programming have the similar quality of keeping things isolated, keeping things encapsulated in functional parameter. We call this immutability and distributability in object oriented, we tend to call it information hiding and encapsulation.
I would actually say that Ruby does have a way with this which is the Ruby is very fluid and very flexible and so if you want to attack something from more of an FP approach, sure why not, whip out the map, whip out the inject and use it and then the next problem that you have to solve, you need a lot of state dragged around. Okay, well this behavior is going to be best described by an object and Ruby switches gears very, very seamlessly between these two.
JOSH:
JavaScript has that same co-FP and OO quality that Ruby does. I think Ruby does a much better job of having the two co-exist, the two paradigms contend a lot more.
AVDI:
I’ll also say this like if you read growing object-oriented systems guided by extremely long book titles.
*laughter*
One of the things that they talk about is that a mix of these paradigms tends to emerge in good object-oriented systems where the internals of the methods are very functional and very side effect free and then the higher level design is dominated by the OO paradigm.
JOSH:
Okay. I guess we’re done.
EVAN:
Okay guys, I think we’re going to close it there. Let’s give the Ruby Rogues Podcast panel a big round of applause.
JOSH:
Thank you. Bye RailsConf. We love you.
EVAN:
You’re dismissed.
JAMES:
Okay. Dismissed.
EVAN:
So we have another quick keynote from Cookpad that we’re going to do in just a second. You can come on up. But first I have a couple of announcements to also make since I’ve got even more of you now because it’s the third day and everybody sort of trickles in late. We still got a ton of Tshirts out there. So here’s what I’m going to do for you guys. Go grab a T-shirt. Go grab a T-shirt for your friend, your spouse, take some back for your company, that’s fine, but as you take those, think about you getting a credit from KidsRuby when you take a T-shirt. And that what I want all of you to do is when you take those T-shirts, think about going back and saying, “I took a T-shirt, you know what, these T-shirts are worth $10 maybe for a couple of them.” I’m going to give that money back to KidsRuby, right?
So that way, you are sort of giving back for some free stuff that we’re giving out. So go pick those T-shirts up and think about that and the other thing is that so yesterday I announced that the dates and location for RubyConf and, of course, because this is how things go, Matt said that he was unfortunately unable to make those dates. So because we’re doing it so much ahead of time, we moved the dates for him. So the new dates for RubyConf, which are going to posted probably later this week on the RubyConf website, it’s now November 1st to the 3rd. So it’s just basically a week later so that way we can have Matt there which I know everybody will be upset if we had RubyConf without Matt. So I think that’s a pretty good reason to do it.
And so now, just to keep things moving along. I’ll turn it over to Miles from Cookpad. Actually, he’s going to plug in so I’m going to entertain you for a moment. So everybody has had a good RailsConf I hope. Who here has felt like this is maybe the best RailsConf they’ve been to? Certainly maybe food wise, can I hear a round of applause for that food? Oh my goodness. And I like to say a lot of people came up to me and said like, “You did such a good job on the food.” I’d like to say like, “Oh yeah, it’s all me on the food.” The reality is like I’m up here. I’m your happy emcee but that was all Ben Scofield and Prakash and Leah Sibler. So if you see them, be sure to tell them how much you loved all the food and all the facilities that they put together because it really has been amazing and I certainly couldn’t have done any of these, I mean like I said, I’m just sort of the smiling face of this wonderful group that I’m so happy I got to work with so. And with that, I’ll turn it over to Miles.
MILES:
Thanks a lot, Evan. So hey. Yeah, my name is Miles Woodroffe. I’m an engineer at Cookpad and I just want to talk to you for a few minutes about Cookpad and why we’re here sponsoring RailsConf. You can probably tell I’m pretty nervous and a little bit like the Keynote presenter yesterday. I’d like to take a minute and think and pause and think what would Erin do so. Okay. I think I’m good.
What is Cookpad. Cookpad is probably the biggest Rails site that you never heard of. We have about 15 million unique users and half a billion page views a month and in Japan where the trusted source for 50% of women in their 20s and 30s to find recipes for their families. The company was founded in 1997 and we had an IPO in 2009 pretty soon after we moved to Rails. We have 100 employees and 40 engineers who are working with Rails from seven different countries around the world. So I just want to talk a little bit about the Cookpad mission.
And we all know that cooking with friends and family really just makes you smile, and if everyone starts using Cookpad and shares their experiences around cooking, we think we can really enrich people’s lives. Our mission is simply to improve people’s lives through cooking, and that’s something that’s actually happened in Japan and is part of daily life. Like I mentioned, it seems crazy to me that about 50% of all women in their 20s and 30s in Japan are using Cookpad regularly. So if you’ve ever been to Tokyo or seen Lost in Translation, you might know how to in Shibuya and we could probably assume that these people who are heading home to happily use Cookpad and find a recipe.
By searching Cookpad, anyone can find a recipe and enjoying new and interesting meals and we want to inspire people to enjoy cooking more and use technology to help them share and find interesting recipes. And going forward, we want to bring this to the rest of the world so that everybody can enjoy cooking more and simply, we want to inspire people to cook and make the world a better place.
So why sponsor RailsConf? It’s basically you guys in the Rails community had given so much to so many people and Cookpad has been a great beneficiary of that and we really wanted to help support this conference and get it rolling and it’s been an amazing experience to be involved with. We’d been using Rails for about four years like I mentioned and we love the Rails framework and thanks to Rails. I truly believe we’ve been able to fast iterate really quickly and provide great features for our users which then help us provide a better service so it’s a true win-win.
11:
30 in one of those corners that I advised you to go to. It’s going to be really good about our extension framework. We also host a meet up group every month in Tokyo, TOKYO Rails, so if anyone is ever in Tokyo, come and give us a shout. It’s a lot of fun. So I just want to leave you with some food for thought and what I really personally love about Rails is that the focus is on creating value for its users and those values are us. It’s me and you guys using the framework. It works really hard to get out of our way and solve real problems for us and improve our daily lives and similarly, that’s kind of methodology of Cookpad.
We want to build services for people that can really solve a problem and improve their daily lives. So my takeaway is this, take this amazing framework that we all love and we’re all here to celebrate and take the amazing skills and motivation you’ll have and try and solve real problems for people that can really improve their daily lives and talk to the underserved people in technology like your family, friends, people who sat in front on Mac books like me and half the audience, and really talk to them and see what problems you can solve for them and we can really make the world a better place. So once again, just thank you to the whole Rails community and everybody here. It’s been a blast. We’ve really had a lot of fun. Special thanks also to Leah and Ben who I dealt with organizing this amazing job and everyone else who’s working on RailsConf. Thank you.
EVAN:
So thanks a lot to Cookpad and to all the sponsors again for making this such a great RailsConf. So the schedule now is that we’re going to do a quick break while they put up their walls again. There are paper schedules and they’ve printed out schedule right here so you can see what you want to see later today and coffee and such like that. So, we’ll see you in about 20 minutes in the different breakout rooms. Thanks.