054 RR Coding Exercises, Quizzes, and Katas

The panelists talk about coding exercises, quizzes, and katas.

Show Notes

The panelists talk about coding exercises, quizzes, and katas.

Transcript


CHUCK:

Dave, from the way you are describing your regular day, I'm just glad that Skype doesn’t transmit smell. *laughter*

JOSH:

I'm always glad of that.

[This episode is sponsored by Railsthemes.com. Have a website that only your mother could love? Then you need a theme! Go to Railsthemes.com and sign up for an early access and when they release, you will be able to check out and use their themes on your Rails app.]

[This podcast is sponsored by New Relic. To track and optimize your application performance, go to Rubyrogues.com/newrelic.]

CHUCK:

Hey everybody and welcome to Episode 54 of the Ruby Rogues Podcast. This week on our panel we have Avdi Grimm.

AVDI:

Hello from Pennsylvania!

CHUCK:

We have David Brady.

DAVE:

Good morning! Anybody who did not bring their programming gear will program in their pants or skirts.

CHUCK:

Oh geez. We also have James Edward Gray II.

JAMES:

I'm still puzzling over what David Brady just said.

DAVE:

I completely screwed that up, yeah.

JAMES:

I'm glad. I'm allowed to be on the show today by Josh because I do not live in North Carolina and I use spaces instead of tabs.

CHUCK:

Okay. And we also have Josh Susser.

JOSH:

Yeah. Hi from Pennsylvania by way of San Francisco.

CHUCK:

Okay. *laughter*

JOSH:

Did that work? I don’t know. But I figured after David’s fumble, I can get away with it.

DAVE:

This is going to be like the “blooper episode”.

JAMES:

He derailed the show at the introduction.

CHUCK:

Yeah, the last ten minutes is going to be bleep and then Josh talking and then bleep and then it’s going to be Dave talking. Well I'm Charles Max Wood from teachmetocode.com and this week we are talking about coding exercises, quizzes, katas, what have you.

JAMES:

I wish I knew something about that.

CHUCK:

I know, me too. Of course all it really you is somebody like David coming and yelling at you

DAVE:

Repeatedly.

JAMES:

Can I tell my favorite David story if it’s related?

CHUCK:

Yeah I guess you can.

DAVE:

I wanna know what your favorite David story is anyway.

JOSH:

Does it has something to do with a 300-line C program written in Ruby?

JAMES:

Yup, it does. So basically David and I had not met yet. We both showed up in Lone Star Ruby Conf and he finds my wife and asked to meet me (which is a whole other funny story, but that one’s for her to tell). And when he comes up to me, he starts the conversation with, “You probably don’t remember me. But, a while ago, I posted this solution to The Ruby Quiz, which you just tore apart line by line as C written in Ruby or whatever.” and I'm thinking, “Great. This guy is going to knife me at a conference.”

DAVE:

He was visibly recoiling.

CHUCK:

You know how the force field upgrade on your wheelchair?

JAMES:

I didn't know I’d run into hostile people.

DAVE:

I didn't realize I was coming on too strong until I realize that you are literally flinching back.

JAMES:

I was like, “I'm sorry man, your code was amazing.”

DAVE:

Well you have to tell the rest of the story, which is the next thing I said which was, “And it’s the best thing anyone’s ever done for me”.

JAMES:

Yeah, that's true. That's what he said next.

JOSH:

I thought this was going to the direction of the pair programming hygiene conversation. *laughter*

CHUCK:

I love you like a brother, but you make my eyes water. Yeah that's a conversation to have.

JAMES:

Okay, so what is all this “code exercises” stuff for?

CHUCK:

I can tell you how this topic got into the list because I actually got an email from somebody that has, what is it? Rubeque or something Ruby.

JAMES:

Oh yeah, the new Ruby. I know what you are talking about. I think we all got the same email about the new Ruby challenge site kind of thing.

CHUCK:

Yeah and he was saying, “What do you think?” and I said, “I love my listeners and I will go spend a couple of minutes looking at it, but I don’t know if I can give you an honest opinion because I am very busy.” But anyway I also told him to put it into the list, (the topic) so we could bring it up. And so he did and then he rallied a whole bunch of people to come and vote for it. I think other people just wanted to hear it anyway. So that's how it got into the list. I think it is an interesting topic because we talked a lot about becoming better at what we do and then practice is a good idea.

JAMES:

So yeah, that's why you do it, right? It’s practice thing. So let’s talk about that. I mean what practice tactics do you use? Let’s go around the table on that.

CHUCK:

All right. We are going to make Josh start.

AVDI:

I'm trying to imagine a table. *laughter*

JOSH:

Yeah, first challenge, create your own virtual playing field. So I'm kind of terrible when it comes to code kata, things like that. I can be the proof by counter example. So what I run into something new that I wanna learn, I always try and play around with it in the context of building something real or something useful. And that's kind of counter to the whole idea of doing kata to stay in shape etc. I don’t know, I think wearing my old fur hat, I can say, I spent the last couple of decades doing all that kind of stuff so I’ve gotten to the point where I don’t need to do that stuff as frequently as I did when I was younger. I do remember a time in my career and in my development my days as developer that I would noodle around with things just for the hell of a lot more. I seem to have lost patience from that. Maybe this conversation will get me reinvigorated for that. So, I’m your challenge guys.

CHUCK:

I think I heard Josh say “practice makes perfect and I’m nearly there.”

JAMES:

That's what I thought! Yeah, “I'm so good I don’t need it.”

JOSH:

I love that you guys get me.

DAVE:

I was reminded of the scene from Karate Kid where they are walking through the airport and there was picture of the guy breaking the giant log in half. Ralph turns to Mr. Miyagi and says, “Can you do that?” and he says, “Don’t know. Never been attacked by a tree.” *laughter*

JOSH:

I am not the Mr. Miyagi of this group! *laughter*

JAMES:

So, David obviously we know that you have, (at least in the past) once before I ran you off on the Ruby Quiz.

DAVE:

So I just love to play. We learn by playing. We talk about how children learn by playing, well guess what, adults do too. And I think programmers are just one of the few groups who are lucky enough to have figured it out, that the way you learn and grow is by playing with things. And I would consider what Josh does, to still be this kind of code kata. And I think maybe Uncle Bob will probably disagree with me, because the kata is “to do this pointless thing as though it had a point” and I don’t like that definition of a Kata. In fact, I'm going to stop using the word “kata”, coding exercise. My favorite way to learn something new is to convince my employer that we need to deploy it, because then I get to play around with it and I get to have that “panicked, giving all night hack session trying to make it work so we can ship it.”

JOSH:

Plus you get paid for it.

DAVE:

And you get paid for it! It’s like you are getting paid to go to school instead of playing the other way around.

CHUCK:

Yeah you don’t get paid for those all night hack sessions because you are on salary.

DAVE:

No, that's true.

JAMES:

Josh, even for start-up, you don’t get paid either right?

JOSH:

Well I get paid as much for that as I do for everything else that I do.

DAVE:

So anyway, I did the Ruby Quiz because I was really struggling with Ruby when I first got into it. I remember talking with James about the Ruby Quiz and James you said, “these are the things that you should be able to do in about an hour” and I was like, “No, this take me 6 to 8 hours every single time.” And I remember James you being startled, like “No, this should not take you that long.” and I might have the ordering. I'm like “time machine out of order” because it was when you rewrote that program for me in the Idiomatic Ruby that I started to realize why these things are taking me 6 to 8 hours, because I was not doing it the right way. So the thing about coding exercises is play with things. If you in yourself in the state of play, then you can be at work, you can be doing a code cut or you can be noodling around, you can be trying to ship something critical and it counts towards what I consider to be coding exercise. I get some stuff I wanna talk about the show, about deliberately, consciously, screwing around. I found that people become aware of this idea of you should be playing and having fun. Some of the best career advice that I have ever gotten very early on was, a programmer turned to me and said, “Dude, if you are not having fun, you are doing it wrong”. And that's my approach to coding example and katas and everything.

CHUCK:

What about you James? I mean you ran Ruby Quiz. Do you still do the katas and exercises and stuff?

JAMES:

So I definitely am getting older like Josh (though I'm not as old as Josh).

JOSH:

Well nobody is. Right?

JAMES:

I do, do them less. I will admit that I don’t do them as often as I once did. I do them though. For me, a lot of the times, it’s just playing around. I’ll see something new Ruby motion or whatever and then I just wanna play with that. I do try to do something fairly pointless. I do try to do something like, you know, isn’t something I'll do in my job or something like that because I do them all the time in my job and so I get a lot of practice with that but I don’t get lots of practice firing up DRb servers and using them for strange purposes or building iPhone apps or things like that. So I try to do those things because I find that, in messing around those things, I get more new ideas which is what I'm trying to get out of it. So then when I come back and am doing my work, I have new ideas and in my head about things I can try or whatever. And my favorite problems are the one where I read it, and I'm like that is so easy. I have ten minutes. And you know like 3 hours later, I'm sitting there trying to solve that problem. Those are my favorites, where I just get sucked in and not realize that the problem actually had teeth.

JOSH:

James, you know what my favorite playing field to do that sort of exercises is Ruby on Rails Open Source, the project itself.

JAMES:

Oh yeah.

JOSH:

If you want a good time, just dive into the routing code.

JAMES:

Yeah that is actually a really great point because I wrote an article recently where I did patch Rails to fix something that bugged me. And I thought, “Oh this is going to be easy. I know exactly where it is.” and all that. I went in there and try to find a test for it and everything and that was like half a day.

JOSH:

When I'm bored and I wanna do a pointless exercise, I try and hack with the migration code in Ruby on Rails.

CHUCK:

Exercise of futility right there.

JOSH:

Yeah, thank you.

DAVE:

If you are not having fun, you are doing it wrong.

JAMES:

I do agree with David a lot about the “having fun” thing. Like to me, programming is hard. I mean, I don’t know about you guys but I struggle like sometimes and you have a great mind-set for it that you are solving problems and you are taking this challenges and you are tackling things and having fun. So I mean, seriously, how many people have to practice their job? I mean, if you re cashier at 7-11 you don’t go home that night and take money from your family for dinner.

CHUCK:

That's good idea!

JAMES:

Well maybe you should but you know, how many people have to practice their jobs because it needs so many ideas? But the problem is, with programming, you can get neck deep and get overwhelmed, right? And we’re always trying to minimize that with all the practices we do right? Taking baby steps through test-driven development or practicing things through code and stuff. We are always trying to prepare ourselves for that moment where in over our head.

JOSH:

Well I think that there are other creative professions where people do something similar. I think writers are always noodling around ideas and my artist friends are always sketching.

CHUCK:

Musicians and stuff. They do the same thing right?

JAMES:

I agree and even scientists, right? If you look at scientists like a lot of the times, they are famous for their big break through like Charles Darwin’s famous book “The Origin of the Species”. But if you go back and read his notes before Origin of Species, he had all the pieces for evolution actually for a couple of years before that. He just hadn’t put them all together yet. So in all his noodling around, he eventually has his big break. So I think that is true and that is just like what we are doing; preparing, rehearsing, getting ready for performance time which is production code.

CHUCK:

So Avdi what kind of code practice or code exercises do you do?

AVDI:

So I've been thinking about this because I don’t do a lot of sort of deliberate practice on my own. But something that I found is that, when I'm teaching somebody else, it can turn into kind of a kata for myself as well. I was recently visiting another consultancy to work with them and pair with them and share knowledge and stuff. I found myself sitting down with people and going through refactorings in kind of the classic, pedantic fashion where we would try to keep basically do one single thing at a time and trying to keep the test passing at all times make sure that copy the text instead of cutting the text, so that there's a little bit of duplication in the middle of refactoring. But it means that you don’t lose your place or get into a state where it’s not working. These are all the steps that you will find if you look at all the Ruby Refactoring book and look at the extract method or whatever. But there are steps that I often cut corners on, but when I was showing somebody else how to do that the classic way for the first time, I realize I was sort of walking myself through it as well. So I think that's for me that's maybe the biggest thing that I do is that I work with other people. I also do open source pairing sessions, where I just do remote pairing on someone on some project and if they haven’t done something like that before, I’ll walk them through it. It really helps me remind myself of these disciplines.

JAMES:

That's actually kind of like an “aha” moment for me when I realizes that the whole point of the refactoring is that at every step the code is not broken. I went like years not realizing that, not getting that.

CHUCK:

One thing that I want to observe a little bit about you Avdi is that it seems like when you are writing a book, you do a lot of experimentation too to figure out what's there and whatever it is that you are writing about is capable of.

AVDI:

That's true. I guess for me, writing both blog post and books it’s definitely a discipline in itself because I do try to have a little working code in them.

JOSH:

Okay so here is something that I've been thinking about since I admitted that I don’t do much in the way of quizzes and kata; i think what it is, it’s a matter of what captures my attention. Usually, I actually played around with the Ruby Quiz for a while when it was running. But I don’t think I ever got to a point where I got a solution that I felt was good enough to submit. I would just like look at it and say, “Oh, this look like kind of an interesting problem but I don’t really feel compelled to put the amount of effort into it to get a good solution”. But I realized when I'm doing something on a real application, I have a lot of interest in exploring this phase and figuring things out and actually trying things out. I tweeted a couple of days ago, I'm trying to take on Dan Kubb's treating all code as experimental and I really liked the presentation that James did at Rails Conf or on our session there about experimentation being really important. So I have been doing that code more intentionally and experiment that I'm doing right now is around getting rid of all my constants declaration in my Ruby classes and replacing them with methods that return the constant value. The point of that is to make testing easier because sometimes you wanna be changing these things and it’s much harder to deal with replacing a constant definition in a temporary way, within just one test case. But stubbing out the method that returns “constant” is much easier. So I’m trying that experiment in my code and it feels to me the same way that approaching something like Ruby Quiz or code kata is. I'm trying something out, it’s something that is not going to kill my application if its screws up, but it’s definitely making a stretch to take on some approach into doing something in a consistent way.

JAMES:

Kind of go to, right because now constants are subject to inheritance, so you can actually sub class or override or something.

JOSH:

Yeah so I'm looking forward to writing this up because I'm actually learning a fair amount from this experiment. I think that the motivation of trying to tackle a real problem in something that just landed in front of my face while I was in the midst of doing my job. I find that really engaging in a way that I don’t find just doing some intellectual problem solving that somebody put up in the website or passed around in an email.

CHUCK:

I wanna jump in here (I haven’t talked about what I do for practice, but) that's essentially what I do a lot of is I find some projects that I really want to see through and then I start working on it. That's why I started writing an orm was because it was an interesting project, something that I wanted to get done and it actually does something. I mean, at the end if you can connect to Cassandra and write and pull data and write other cool stuff that you may want to do with that data then that works out. I've also been building a website that’s just kind of a personal project, hopefully I’ll have it launched within the next few weeks but basically, that's what I do just to kind of practice and noodle around and stuff. Because it’s my own project, It’s not a client project and not something that I get paid for, I don’t feel like I am in the same constraints to just stick to what I know. If I go off to a rat hole on one of my client projects, if it pays off in a big way, then I don’t mind getting paid for it. But if I'm just doing something because I'm curios on their project, I don’t feel like that’s fair to do that on their time, so doing my own project kind of opens that up. I haven’t actually done any of the exercises of quizzes or katas for a while with the possible exception of the last code retreat that I went to.

JAMES:

So there’s an interesting dichotomy here about some of us are talking about how we like to do real things and some of us are talking about how we don’t. When I’m doing not real things, one of the things I like to do is the “International Conference on Functional Programming” has contest every year. This year I think it’s on the middle of July.

JOSH:

I think you picked that for one of your picks one day.

JAMES:

Right yeah. I picked it on the past and its 72 hour programming contest and they usually publish the spec and it’s generally like 12 to 20 pages of whatever you are building. It varies every year of what it is. It’s run by some universities. Lots of hackers compete and even though the name says for functional programming, they are really cool they let you use whatever you want so I typically play in Ruby or whatever. But the challenge is 72 usually involves some intense algorithms or whatever and I’ll tell you that every year when I do that, I use a whole bunch of things that I never ever use in my day job, like intense algorithm programming, figuring out how to speed things up and stuff like that. A lot of times in my spare times I play around game servers because I love games and someday I hope to be running things on the internet and be wildly rich that way. (That's my lifelong dream by the way). So, I play with game servers and stuff like that so I know server technology really well. So anyways I’ll find that In my job, I basically never lose that. But once in a while, it will come down to something and I would be like, hey I know how to do this because recently we have this API that was terrible and you had to send these requests in chunks. So like 500 requests so it turned out that they changed the API and now if one of the requests is bad (and it was hard to tell what made it bad), then it would just throw away the entire packet. So you lost 500 requests right? But the thing with the black box, it wouldn’t tell you what was bad, it wouldn’t tell you it was going the other way. So, I wrote a binary search algorithm that just fired the whole set and through the way I cut it in half and kept doing that in requests so that I could find the bad entries. Sometimes having those skills does come in handy. But I’ll admit, It’s not very often.

DAVE:

For me it comes down to like having rusty shave in your back pocket. It’s like why would you wanna learn these horrible programming techniques and I’m like “Well, you know, if its three o’clock in the morning and you are trapped in the blind alley, which some really nasty code, do you wanna have a back pocket or do you wanna be barehanded?” And those kind of horrible things are actually really useful at times. Josh talked about prudence in his Rails Conf talk and I think there's a little bit less pressure to be prudent. You are allowed to fail, you are allowed do something just stupid and wrong when you are playing with code. And I guess you maybe have to distinguish between “play” and the concept of “perfect practice” where like I'm going to write code to day and I'm going to do everything relentlessly test driven and it’s going to be refactored and we are going to refactor. And that is more a perfect practice when you are trying to do a very specific set of things to build and have it. And then there is like exploration world, just still try these new concepts. So we may wanna distinguish between these two concepts.

JAMES:

Yeah that is a good point. Every now and then I’ll be like, “I have this idea for this most brilliant library.” and I will sit down and write it and then I get to live the 90% complete mark and I realize that one of my opening premises is horribly flawed.

JOSH:

Okay so David, you keep saying the concept of “play”.

DAVE:

Yeah.

JOSH:

In your discussion here. We all do pair programming to some extent to another. I’ve been thinking about how I do the equivalent of quizzes and katas and things like that, playful exploration of learning code in a pairing context. And that’s actually something that I do a fair amount. I’ll be on a project and something will come up and will be like, “Oh we wanna be able to upload user photos.” “Oh let’s use paper clips.” “Oh there is this other thing that we could try out. Let’s go check that out.” And then we’ll invest time and usually we time box it and say, “oh let’s give ourselves a half hour to check this out and see if we wanna use it in our project” or let’s get it in an hour or half a day depending on how complicated that is. And we’ll just create a branch and sit down and play around with the code and at the end of the time, we would decide if we wanna keep working on it and throw away the branch or what have you. That is often the way I approach it rather than going and doing that on my own solo time, because I tend to think of my learning process around software and new technologies in that context. And playing for me is a very social thing.

DAVE:

Yeah so basically, I just realized what you might be saying is Agile has a term for “play” that is acceptable to our managers and that is like “timeboxed spike iteration”.

JOSH:

That's a mouthful.

DAVE:

Yeah but you can’t say “play” because your manager doesn’t wanna hear you playing around.

JOSH:

Oh I’ve told that to my manager. I said, “We are playing around with this new library”.

JAMES:

You guys, you say “we’re compiling” right? *laughter*

JOSH:

Yeah cross out, insert, run in integration tests.

CHUCK:

Yeah another recent and but not necessarily as valid one is the bundle install that used to take forever.

JAMES:

Yeah but now they are getting that so much faster.

CHUCK:

I know.

JOSH:

How else will we find time for light saber duels?

JAMES:

You know, both Josh and Avdi kind of hit on this pairing. And Avdi kind of talked about how he likes to play around when he is teaching. It is a really important to learn that you do learn so much when you teach other people. I can’t over state that. I ran Ruby Quiz for three years, which was basically a learn from and teach each other experiment for three years and the amount of Ruby I learned in that time is staggering. Every week I had to read through the solutions that people sent it. Figure them out enough so I can decide whether I like to talk about them or not. Just doing that, especially where every now and then, people would write a bit of code that took me a while to really get my head around. When I did, it was a major aha moment and then I wanted to try to present that in a way that people are reading the summary will get that aha moment and that's very difficult. But I’ve just learned a phenomenal amount of Ruby doing that. So I have to agree like teaching is an amazingly good one.

CHUCK:

So I wanna go on two different questions here, one real quick, what other coding exercise quiz, kata websites out there that give you a set of quizzes or exercises to do? We talk about Ruby Quiz, I've done Project Euler .

DAVE:

There's “Ruby Koans” which is spelled ko-ans and I've been saying “Ko-ans” but I guess its “Koans”. But if you say “koans” people are going to type c-o-n-e-s.

JAMES:

I thought it was ko-ans.

DAVE:

Anyway its K-O-A-N-S.

JOSH:

I'm from Pittsburgh so we call it koANS.

DAVE: koANS and there is Puzzle Node.

JAMES:

These are all really different. Like you really should really play around a problem off of each of them. For example, the one he just mentioned Puzzle Node, is kind of neat and they give you the inputs basically like we are going to shove this data into your program and then we expect to get this output. So you can actually check it but then when you submit your code and they actually hit it with a different input. Or no, you don’t submit your code, they give you an input and a matching output so you can like run that through and check. Then they give you a second input without the matching output and you take that output, you put it in and you get basically a thumbs up or a thumbs down. It’s kind of good and bad. Its good in that it gives you input and you can run it through. The bad part is the thumbs up thumbs down isn’t always super helpful. You know like when you get on 10 pages of data and it’s like no. But I will say that it made me do some creative things. There is like a chess problem on there (which is actually kind of dozy and takes a lot longer than you think), but you have to do all these chess moves and your validating these moves. And so when I got the thumbs down from the site, the error was like, okay, I've given out a gazillion moves, I have no idea which one of the two I'm getting wrong. So I actually built a visualizer so that I could show myself all the moves and trying to chess player its nothing for me to scan through it and say “right”, “right”, “right”, “wrong”.

JOSH:

Okay, so I have a very nonstandard quiz that I like and that is NPR Sunday Puzzle.

CHUCK:

Oh I love that! They have a podcast that you can listen to and

JOSH:

Yeah years and years I would listen to that every Sunday morning and I would hear the problems and a lot of the problems where things that you could solve with very clever programming (or even not so clever programming). And for a while I was solving them in Smalltalk, because it was such a great language for adhoc stuff like that. But then I started doing them in Ruby for a while and I think that kind of puzzle where it’s much more freeform and it’s not about, “oh here is the muscle I want you to work on. It’s now you have to fight three guys with a sword, figure out how you are going to do that”. And so maybe that would be like a cool Ruby Quiz site evolution of throwing people word problems or puzzles that have no constraints on how you are going to approach it in programming.
Just like, here is the puzzle, write some code to come up with the solution.

DAVE:

So, I bought a book of grade school logic puzzles.

JOSH:

It’s like syllogisms or something?

DAVE:

No it’s like a three inch by three inch book. It’s a little tiny one. Each one there is a logic puzzle or a math puzzle or like a word search, that kind of thing. And I bought it with the explicit goal of solving every single problem in the book with the program, even if I could solve it in my head by just looking at it. The very first problem was like a word association problem and I'm like, “oh great I have to conquer the entire field of natural language processing in order to solve this problem”. So the book is still on the shelf and I haven’t done very many of the problems. But I do that. When I'm flying at san Francisco and I'm playing home, I would occasionally open on the Sundays page or the Sudoku or the logic or math problem, I will sometimes try to figure out a way to grapple with that in code. I think it’s fantastic. Pick a real problem and try and solve it no matter how contrived the real problem is.

CHUCK:

I never really thought about approaching some of the problems that way. I mean, I'm a huge fan of the NPR Sunday Puzzle but it never occurred to me personally to write a program that will solve it for me.

JOSH:

It was great, on the Mac, (I don’t know how many people aware of this or not) but there is a file that contains every word in Webster’s dictionary.

CHUCK:

Really?

JOSH:

Yeah it’s just sitting there in like “/usr/share/dict/words”. Some clever person got that into Unix years go and it’s there. So there is a whole bunch of, there is word problems that you can solve just by clever graphing and little Ruby code.

JAMES:

I'm actually been reading a book in the past, and there’s like clues in the book about what's going on and I knew enough information to solve the problem but I couldn’t do it in my head and I sat down and wrote a Ruby program to do it.

DAVE:

There is an iOS game called “Bookworm”. Oh no, it’s a web game called Bookworm. It’s on bookworm two and bookworm three now, but I actually wrote a program to basically I would key in all of the letters that I had on the board and it would go find (in book worm you just get points for the longest word that you can spell) so it would take the anagram and go through the dictionary on the computer and find the longest possible word. Lisa and I are both playing Bookworm side by side and she’d be puzzling through and counting letters and I would sit there and I would come back and I would key in “metallurgy” and score like 15,000 points or like “zymurgist” and another 15,000 points and she says, “how the hell are you doing that? I let the computer do the work.

CHUCK:

That's amazing.

JAMES:

That’s so sad.

DAVE:

So I believe that cheating at games is an entire. . . I believe its meta gaming.

JAMES:

Cheat to win! Cheat to win!

DAVE:

Cheat to win. That's right. So those are fun. So I have a question and I actually wanna tell this one after the listeners because I think we would be short changing them if we end this podcast without throwing out some kind of challenge or a question. What do you guys think about like the pointlessly stupid ones like the way you are given the constraint, like writing a Ruby quine? We probably will have people look at “Qlobe”, which is the most beautiful quine ever written. But what do you think about coding challenges where like, write some code that fits into a single tweet and there is no constraints, you can do anything you want with it. Just what's the most interesting thing that you can do in that amount of space? What do you guys think about those? Are they esoteric or do they have any value? What do you think?

JAMES:

My opinion is that they do have value. I came from Perl’s culture before Ruby’s and of course Perl guys are obsessed with “golf” whereas Ruby guys tend to hate golf which is kind of interesting thing.

DAVE:

Can you define “golf” for the two listeners that don’t know what it means?

JAMES:

Sure, it’s the process of solving a problem in the shortest strokes, where the “strokes” in this context is keystrokes right? Like for example, Ruby has all those horrible global variables but those are great for golfing because they are short right? You've got like I think “$>” is stdOut. So you can do that without typing “stdOud”. So things like that force you to learn the intricacies of the language in my opinion and that's why I think it’s valuable. Or turning some feature off, solve this problem but don’t use that feature. There's typically used to solve that problem and you can kind of get an idea of all the work that that feature is doing for you, which you appreciate and understand that process better in my opinion.

CHUCK:

That or it makes you bend you mind around different feature in the language or library that you are using and that may come in handy later on solving a different problem.

JAMES:

I'm not sure how often the knowledge comes in handy, but it’s there in my brain. Someday to be unleashed.

JOSH:

There is two sides to coding; one is writing code, the other is reading code. And it seems like a lot of the stretching with your limits that one does in this sort of “pointless adventures” just makes you more familiar with other things. So when you are reading code, you might have better understanding of things.

JAMES:

Yeah, I mean like I can read pretty much anything in Ruby because I've moped around the most horrible parts of it. *laughter* If you go through the encoding engine and come out the other side alive, you are set. But it’s about that and kind of in a sad way is that most of these features you don’t use because they do impair readability so bad right? And usually that is the number one goal, to keep everything readable and understandable. But there circumstances where you just can’t get around something or readability is important but in this one case where we need to go that much faster, something like that. You get good knowing when to obey the rules and you get great knowing when to break the rules.

DAVE:

I think the inject when you can hash inject and then you have an inject function, that return and you don’t have to write that horrible inject statement.

JAMES:

I don’t do inject in Ruby anymore as of like 1.9 you have each with object and that one will carry an object for it without forcing you to do something gross with returning value.

DAVE:

Yeah which is fantastic, but for like a year or two, in Ruby 1.8, that was slowly gaining ground as an idiom and its horrible! It’s really hard to read until you play around with it and you go, “Okay, I get what is going on. That makes sense.”

JOSH:

Back in the day when I was misguided enough to give people programming quizzes in the midst of interviews, one of my killer interview questions was “take all of the enumerable ect methods, collect, inject, select, reject and re-implement them in terms of inject instead of each."

JAMES:

Holy crap that is awful!

JOSH:

It is. Everyone is one liner and but there is like two or three ways to do it and I would just do it to watch and see what people came up with.

JAMES:

That is awesome. I'm so doing that now. Now what Josh said with that being bad though, if you wanna learn around (and actually I've used this multiple times in teaching Ruby and it is a major light bulb moment for the students usually), I usually have them figure out age in terms of “while” and then I’ll let them have each once they have it and then I have them figure out the rest of the iterators. I show them the iterator but I make them write it using just each and once you have done that a few times, you will realize there's patterns that whenever you set some variables to an empty array and each over a set and return the resulting array that’s map, that is or something like that. So, what happens is that you learn that they are just patterns and then when you are looking around in code, you see that array assignment that each and that return of the array and I'm like oh, I got to replace.

CHUCK:

So one other thing I wanna get into here is we talked about some of the interesting things that you learn about the language or framework or library that you are using while doing one of these exercises or quizzes or katas or just, you know goofing around with this stuff. I'm wondering too though, if there is more value in just the practice of solving problems, not necessarily gaining knowledge of the system out of the quizzes and katas but actually just the practice of going through and figuring out how to approach and tackle problems.

JAMES:

It absolutely is valuable because it’s a confidence builder thing. Let’s face it, in the beginning, when you are first learning the language or something, that's the horrible time right? Because how do you get that? Well you have to have about 600 times with the compiler telling you are an idiot. And there is no short cut no matter how smart you are. I mean maybe after you have picked up like 10 languages, the 11th one you go down with only needing the compiler telling you are an idiot 400 times or something, still that's it right? That's the whole new way to learn syntax. And so when you are practicing and some other context, all those sessions they count toward that limit that you are building up. It really matters, it’s the practice, the context, the working through the problems and when you see the real problems, you are not like, “Oh, my god, I have no idea what to do.” And you are like, “Oh, that's just like the game I was playing with like last week.”

CHUCK:

Speaking of games, we did have somebody bring up board games on Twitter and asked about how that relates to programming.

JAMES:

And I didn't even have to pay that guy to ask.

AVDI:

Yeah it’s just incredibly important to do this kind of practice. The way I think about it is if you are getting started like a wood worker (my grandfather was a woodworker. I used to try to learn some stuff from him) and when you first start out, the stuff that you make is terrible and you wind up throwing a lot of pieces away. I used to make cuts on the jigsaw and were just awful and you can barely tell what they were. In that trade, nobody says, “this took me four hours to get right. It’s a completely impractical thing to do” or “I spend all week trying to get to learn these cuts right. It’s a totally inefficient thing to do and we shouldn't do it.” And yet I see that, I hear that a lot in software when I would hear somebody say something like, “Well I tried TDD, but it took me forever to get anything done. So I tried it for a whole week and it took me forever to get anything done. So it’s just not practical, it’s not efficient. You’re wasting time if you are doing that. It’s not necessarily TDD, I hear this about al lot of things. It might be pair programming, it might be any number of just merciless refactoring or something. Nobody would accept that in any other craft because it’s just expected that some of these skills, if you watch a master at work, they do this things and they do them really fast. They do them good and they do them fast but they do that because they do that because they have practices over and over and over for a really long time. If you read about some technique, or some practice, or some discipline, you cannot expect your initial triad or your initial week try to be indicative of how efficient that is going to be down the road.

JAMES:

You know I wanna mention one more thing before we get into the picks. I was just reading a blog post on David’s blog and it talks about how he like fractals and every time he’s played with them he get lost and then like 20 years later, he figures out how to write programs that draw them and stuff like that. And that reminds me of like eternal problems. Programming is full of eternal problems like that problem you are wanting to have some I have one that I ran into in a very young age and I wanted to try and solve it and I try and my programming skills were just not getting up and kept trying and trying over the years and eventually I get to the point where I can solve that problem, but I still to this day I hate the solutions that I have come up with for that problem. So I keep trying. To this day, I still play with that from time to time. I haven’t done that in while but probably will but I sit down every once in a while and try to solve that problem and I'm still searching for the solution for that problem. And it’s weird how that you can run into things like that where you try to get it one way and maybe you can do it or maybe it’s not very good or maybe you can’t even do it, but you keep working at it, try to get past it.

DAVE:

That’s really interesting because there is a problem (I talked to about this in Mountain West Ruby
Conf) that I solved in Basic years and years ago and then I solved it moved I moved on to Visual Basic, I solved it in that language and then I moved on to Perl and I solved it in Perl and I moved on to Python but at this time I have ported or I did it in C and then I moved on to Perl and that by the time I moved on the Python, I had solved it in a procedural imperative way 4 or 5 times over a decade. And I could not solve it in object oriented way in Python. I ended up doing that in Ruby about two years ago and I could not do it so I gave up. I quit trying. And I said, “I’m going to do this object oriented” and I couldn’t and I say okay, “I’m going to ship it no matter what”. So I wrote it in this procedural fashion and then it was the most horrible Ruby code I’ve ever written and I actually showed it off in the conference because I wanted to talk about the fact that you can actually refactor really, really awful code. Yeah so I just wanna second, coming back to these problems, you don’t like you answers to them, you don’t like your approach to them. Playing with things gives you knew tools and new insights in a way to come back around to a problem for a completely different angle.

CHUCK:

Alright we really need to get into the picks, I think we been at an hour right now. We tend to do this right? You know every so often it’s like, okay by the time we are done with picks, it will be an hour twenty minute episode.

JOSH:

And our listeners hate it. They always complain that we go too long.

CHUCK:

They always complain that I cut the conversation off.

JOSH:

Chuck, let me introduce you to the concept of “sarcasm”. *laughter*

CHUCK:

Oh man, I must be tired.

JOSH:

So I can start with picks. I’ll volunteer. I actually have one that is relevant to our interests and this is a language polyglot Hello World Quiz that I ran into this week (a couple of people were tweeting about it.)

JAMES:

I only got 18.

JOSH:

Oh you beat me! Like I’ve never done anything with C#. I don’t know. So basically, this is a cute little thing on InfoWorld where they implemented Hello World in 20 different languages and the challenge is to recognize which language the program is implemented in.

DAVE:

Oh wow.

JOSH:

Yeah, and you get to pick from four. So that’s a fun little thing and some people were getting 20. I got like 14.

JAMES:

I use C# because of Tough Coder. I used to do that. Do you guys know that?

JOSH:

No.

JAMES:

Tough Coder is kind of neat if you are into programming contest. The minus is their restriction on languages back when I used to do, I think Java, C# and something else. So I would solve them in Java or VB I think. Anyways, the fun part about Top Coder is they give you a problem, they give you like x number and you solve it and then you solve it then they give you x number of minutes to go read other people solutions and if you can figure out the input to put into other guy’s solution that breaks it you came out and you get points. *laughter*

JOSH:

It’s like Thunder ***.

JAMES:

Right it is. You got to try to figure out what breaks the other guy’s code. It was awesome.

JOSH:

Okay. So I have one other real quick pick here and that’s the thing that I just mentioned, my programming challenge about doing enumerable as inject instead of the way that I wrote that in I think 2007. So it’s my five year old simplistic coding style Ruby. It’s evolved a bit since then but it’s definitely a good starting at looking at how insane this idea is.

CHUCK:

Nice. Avdi what are your picks?

AVDI:

I’m going to engage in a little bit of shameless self-promotion today.

CHUCK: Good.

AVDI:

Some listeners may know I run a site called “wideteams.com” it’s a blog and a podcast where it’s basically just all about working remotely, working in geographically dispersed teams. Mostly software teams although it’s not explicitly limited to software teams. I’ve been interviewing people on the podcast for that for a long time but for the past few months it’s kind of been on hiatus because I just run out of time, but now I have a new assistant who’s been helping me out and taking on more and more of that. So it is back up and running and a new episode is up and this one is actually particularly cool. It’s an interview Joseph Moore of Pivotal Labs.

JOSH:

Yey Joe! Joe is the first I paired with when I worked there.

AVDI:

Oh very cool! So yeah, its actually from a few months ago. I haven’t had time to publish it but it’s all about remote pair programming, because he’s remote from the rest of the pivots. But just like the others, spend all day, every day pairing. So we basically have a long conversation about all the issues and challenges and tips and tricks for remotely pairing. So I think that will be of interest to listeners. It is at wideteams .com, check it out tell your friends. I’m going to get it back on to a podcast per week schedule.

JOSH:

I think in the past I did a pick for Joe’s website about remote pair programming, which is amazingly enough called “remote pair programming”.

AVDI:

That’s right. I saw that recently.

JOSH:

He’s very good at remote pairing. It’s like pairing with Joe remote, is better than pairing with a lot people side by side.

CHUCK:

Any other picks Avdi?

AVDI:

No.

CHUCK:

Okay, James what are your picks?

JAMES:

So, I’ve got a few this time first of all there’s this kind of silly Twitter account that Peter Cooper I think is running, Code Wisdom is the account on Twitter. It has some awesome quotes in it for picking things up. I mean some of them are really useful like, links to different things about C or stuff like that and they are actually programming but I think more I just like the quotes in anything like “Programming is the art form that fights back.” *laughter*

JOSH:

Obviously someone has never encountered the art form of kitten arranging. *laughter*

DAVE:

Those are bonsai cats right? *laughter*

JAMES:

But it’s just kind of a fun account. So that was awesome and then I wanna to pick a couple of just classes that I think are cool. I haven’t actually taken this one by Marc André, but I have taken this other one which is how to build really cool programming languages from scratch. This one is called “Owning Rails” and I bring it up because it’s coming up. It’s going to be at the end of this month and then he basically in this one goes through and teaches you how Rails work by basically showing you how to rebuild Rails on a small scale of course. It’s like 2 day class you’ll just do some of it. But going through and rebuilding and that kind of playing around by the way is another great way to learn things of just you know, but I don’t know about you guys but for me it’s always I see some code and I’m like, yeah, I'm going to change that to like three lines. And then two days later I’m still trying to figure out why I can’t rewrite that code. So this is a class for Marc André. He’s a really good teacher. It’s just like two mornings for four hours straight they are really intense. So I think that is cool. Another thing that is cool is, I saw Mike Clark when I was at Rails Conf and he told me I need to come check out is new online Ruby course which he is right. It’s really cool. They have this online course you can take through Prag Studio. You watch these videos and they run for like ten minutes or thirty minutes or whatever. They cover a topic and they are very conversational with Mike and they show you some stuff and they are working on an app and learning these things. And then there is these exercises that you can do on the side, with hints and solutions and stuff like that to figure this out. So I gave this course to my programming student and have them working through it and he’s really enjoyed it and got a lot out of it. He said he is really liked how the example that they are working on isn’t what you are working on like in the workbooks. It’s kind of annoying when they work on something and they build on the hard parts and you are like, okay just fill in this one line or whatever. But there is actually separate stuff that you are working the exercises and applying that if you really like that about it. Even though we’ve been working on Ruby for a while he’s picked up quite a few things from just going through this. And like the references, like whenever it will them to go read something, he will actually go and do that. And that is really rounded out as knowledge. So anyways it’s a cool way to pick up Ruby knowledge if you are on your immediate level or lower, that’s probably a good place to go. Those are my picks.

CHUCK:

I’ll go ahead and go next I’m saving Dave for last and you’ll see why in a minute. So one of my favourite coding practice things that anyone did (and David is actually going to have to provide me with the link because I don’t know it.) but basically, there were a couple of guys at the URUG, that is the Utah Ruby Users Group, that we all got together and we were talking and later on they actually went and broke Ruby Koans by patching Ruby so that the Koans would pass.

DAVE:

Without changing the koans at all.

CHUCK:

Yeah, without changing the tests. Because it’s basically like you go in and you fill the blanks on the tests.

DAVE:

But if you monkey patch test units so that assert always returns true no matter what its given, that would make about 80% of koans pass.

CHUCK:

So was there a repository where people can go in?

DAVE:

I think so and if there isn’t, I would make one exist by the time this show goes up.

CHUCK:

Alright, cool. I just thought the idea was kind of fun because you attack it from the other end. You know, instead of solving the problems, you change the parameters of the problem.

DAVE:

It’s the Kirk maneuver for the Kobayashi Maru.

CHUCK:

So yeah effectively you are cheating but it’s an interesting exercise in cheating intelligently, I guess.

DAVE:

It’s surprisingly hard because just because assert true only get you 80%. That last 20% there is some assert that take blocks and you’ve got to figure out how to hijack that block.

CHUCK:

Did you guys get 100%?

DAVE:

Yeah. We got at 200%.

CHUCK:

All right. So the other pick that I have is TextExpander (I may have picked this before) but every time I try something new, like for example adding people to the Ruby or the Ruby Rogues parlay list, when I send you that email that says that you are in, I actually have to send you intro email and I can’t set a default one that will just send to everybody. So I actually just put it in the TextExpander and it fires it off. So I really am happy with TextExpander just for saving you that amount of that I don’t have to reinvent the letter everytime. I just tell people we really appreciate you signing up, (which is true) I mean I’ve bee writing the same thing anyway. So we get them in and get things going there. I did by the way get the Ruby Rogues parlay thing on the side bar on Ruby rogues.com, so if you wanna go sign up you can go to it there and I’m going to be emailing the people who signed up the launch page here within the next day or two and letting them know that they can go sign up there. And then I’ll be redirecting the launch page over to a landing page, so that people can see exactly what we what we are hoping to provide with the Ruby Rogues Parlay.

JAMES:

Well discuss on their pretty soon what book we are going to read next, so definitely hop on there and you can join in the discussion and have some say in the book review.

CHUCK:

Right, because right now we are reading “Working with Unix Processes” by Jessie Storimer. We are going to be reviewing that within the next month.

JOSH:

And if you want us to ask certain questions with Jessie on the show, this is great place to get those questions rolling. People haven’t been good at tweeting us questions I guess but maybe this is a way to get a little more activity around that, so that our conversations with the office can be a little bit more directed by our listeners.

CHUCK:

Alright so Dave, it’s your turn.

DAVE:

Okay so I don’t actually have a pick today, but I mentioned during the show that it would be a crime for us to finish this episode without giving some kind of exercise to the listeners.

JOSH:

David, I thought your pick was going to be the SFMTA clipper card. Talk about programming challenge.

DAVE:

We don’t have time for that rant.Oh my gosh!

JOSH:

Sorry to derail you.

DAVE:

Yeah you completely halved my brain. Oh by the way so Chuck the Ruby Koans hack thing, if you go to my blog at heartmindcode.com and in the tag cloud, click on “stupid”. The first post is donkey punching the Ruby Koans. And I apologize; I didn’t know that donkey punch had a different meaning. When I wrote I thought it was a funny word. It turns out it has another meaning and I decided to just leave the egg on my face. JOSH: As long as it’s just on your face, you are okay.

DAVE:

Yeah exactly. Or on the back of my head; one or the two. So anyway, heartmindcode.com, click on stupid in the first thing that comes up is “Donkeypunching Ruby Koans”. My pick for the listeners is I’m announcing the first ever Ruby Rogues programming challenge! And for this one, (I’m assuming there may be more. I think it will be really cool.) Here is the rules the Ruby rogues, the regular panellist, us five are not eligible.

CHUCK:

We may participate but we don’t get awarded for winning

DAVE:

Right. We are having the frantically putting together, so should we have a contest? should there be a price? So here’s the contest, the contest is write something cool that fits in a single tweet. Its completely free form, it is Ruby Golf, it should be in Ruby and it is golfing contest so it has to fit in 140 characters. You get extra points if it is a coherent tweet that your followers can understand. So what that means is the Ruby code should obviously be Ruby code or you get extra points if you have enough characters left over to type ruby-e” and all of the code and then finish with the close quote. Somebody can just copy your tweet, paste it into a prompt and actually get to operate the program. As an example of this, on heart mine code, if you click on the tag cloud, if you click on twitter, the first thing that will come out (and this will probably change because I will be participating in this) but at the time of this recording, there’s a link that comes up in the tag cloud “Twitterable Mandelbrot”. I wrote code to generate the Mandelbrot set on your screen in dash and it fits in the single tweet. And wants really interesting thing is that I got it down to 134 characters so it was enough to fit into a single tweet. Some people that followed me and came back with optimizations and by the time it was all said and done, we had a code in the Mandelbrot set in 118 characters. That’s also on my blog under “Twitterable Mandelbrot II: The Mandelbrottening”. So these are two examples of Ruby Golf tweets. So the next problem that we have of course is how do we find about this, how do you submit your entry is after you post this tweet, link a tweet to that tweet send it to @Rubyrogues. Give us a link to (it can be a bit.ly link or t.co link) to your tweet and hash tag it.
What should the hash tags be? #roguesconstest?

CHUCK:

Yeah or #roguesgolf.

DAVE:

Okay so the hash tag is #roguesgolf all one word. And I don’t think Twitter cares about case and you can lower case it. So that is how you submit your entry. I will be submitting a new entry for this mainly because I wrote this about two years ago and then I never blogged in and so I need to write a blog about this. I actually wrote a retrace that actually fits in a single tweet and so I will be submitting this as an example.

JAMES:

That is awesome.

DAVE:

It is. It’s a shaded sphere and in bashed and in text shaded text. I have to write a blog post about it to show you all of the shortcuts I took. Like I used the fact that if you use normalize vectors then, you can use the fact that you don’t have to work in square space. You don’t have to have to square a number, because the square of 1 is 1. And that saves you four characters each time you need to square a number. So that is my pick. That is the Rogues Golf, write some Ruby code, tweet it and have it do something cool. The judging criteria is, if its short and its cool, we’ll vote on it and well give the person, tell them Chuck, what do they win?

CHUCK:

So if you are the one that we pick, then you let me know which book you want off of pragprog.com, it could be any book in their library, any book that they have.

JAMES:

So definitely go for the most expensive one because Chuck’s buying.

DAVE:

Yeah does Donald Knuth have his anthology in there?

JAMES:

If they have anthology that just includes all of pragprog.com, go for that.

CHUCK:

So anyway any book you want, you get the electronic and paper version.

DAVE:

Chuck I’m going to suggest an additionally price, we should also have the winner on the show as guest rogue.

CHUCK:

Fair enough.

JAMES:

That sounds great.

DAVE:

Yeah it can be anything that you want. As long as it runs and does something cool. It can be useful or useless. Oh I do have another quick pick that is the “QLobe” and that is the coolest Ruby quine ever. So bonus points in your Ruby tweet if you can figure out how to fit a quine into a Ruby tweet. Qlobe and that is the most beautiful quine ever written and I will put a link to the show notes.mamememo.blogspot.comis the guy’s blog but there’s link in the show notes. to the it’s a quine. It’s just a code that outputs its own source code when you run it, but embed it in the middle of the source code is a globe of the earth and each time you run it, the globe turns. So it’s actually 8 quines in one. You can basically do Ruby and then just block the code and it outputs the next rotation of the earth and so you type that in Ruby again and it rotates again, you type that in Ruby, and it runs again. It’s amazing.

JAMES:

It’s insanely awesome.

CHUCK:

Alright well this is definitely going to be a little bit longer episode. I just wanna thank everyone for sticking with us and I’m trying to decide on the programming challenge, lets you have two weeks.
So anytime within the next two weeks, from when the episode is actually posted and available.

DAVE:

Okay so we will talk about the winner in two and a half weeks, because we record on Wednesdays but the show goes up on like Friday and Saturdays. Do we wanna just give them to the end of May?

CHUCK:

Sure. Let’s do that, you have until the end of May and we will announce that winner on June.

DAVE:

Fantastic.

CHUCK:

Alright well a few other quick announcements, go got the book club book if you get workingwithunixprocesses.com and click on the buy link, use the code “BOOKCLUB” and you save $5 on the book. Were also working on finalizing things. We are going to be talking to Laurent Sansonetti about Ruby Motion next week which is the iOS Ruby that he released. We are also lining things up with the guys with Ruby Central and of course for our bool club with Jessie Storimer. So keep an ear up for those episodes and other than that, go to rubyrogues.com and sign up for the Ruby Parlay over in the side bar and we’ll talk to you all next week.

DAVE:

Fantastic.

JAMES:

Bye.

JOSH:

So long!

Album Art
054 RR Coding Exercises, Quizzes, and Katas
0:00
1:13:45
Playback Speed: