00:00:11.880
I'm going to talk today about LittleBigPlanet. I might mention a couple of other things, but mostly it's just going to be about LittleBigPlanet. Before we do that, though, I should probably introduce myself. There are really only a couple of things you need to know: I wrote the TextMate book for the Pragmatic Programmers, and my name is James Edward Gray II.
00:00:19.720
Just ask your friends to point me out in the hallway, and come up to me to talk about TextMate. I love that! So, again, I'm James Edward Gray II. I have written a few books for the Pragmatic Programmers, including the one on TextMate. I've done quite a bit with Ruby's standard library documentation and patches as well. I wrote a couple of libraries: FasterCSV, which is now the standard CSV library in Ruby 1.9, and HighLine, along with Greg Brown. Additionally, I created and ran the Ruby Quiz for three years.
00:00:41.800
You have to be really careful about what you put on slides like this. Just so you know, I always put my history with the Ruby Quiz on the slides because that was the first thing I did, and I figured that was what people knew me for. Then, a guy approached me in Austin last year and said, 'You probably don’t remember me, but you utterly destroyed one of my Ruby Quiz submissions a few years ago.' So, that's not good. All right, I promised to talk about LittleBigPlanet, so let's get to that.
00:01:16.320
For those of you who don't know, this is Media Molecule's hit platformer for the PlayStation 3. It's called LittleBigPlanet, and it features your standard platforming gameplay—plenty of running, jumping, and destroying little bad guys. What makes it really interesting, though, is that the levels included with the game are more like an introduction to the real exercise, which is making your own levels. As you progress through the game, you collect all the items used in the levels, such as rotating platforms and stone pillars.
00:02:14.560
You'll collect things like little sushi bag guys and other elements, and then you can incorporate them into your own levels. People create levels for everything—Mario, Zelda, Metal Gear Solid, Pirates of the Caribbean, you name it. This vibrant community of levels is something that everyone can play and explore. I mentioned that you can create anything, and I mean it. You get all kinds of materials in various shapes, and you have tools to edit those into what you want. You have brains, wheels, legs for locomotion, and eyes for tracking, allowing you to create little monsters.
00:02:47.680
You also get pistons and twisting bolts that can be used to make complex machinery. The cool thing about this is that all these levels are published online, allowing you to explore them and see how they were created. I like to go play everyone’s levels and figure out how they achieved certain effects. I love reading everyone’s code; I think we should all do that. In fact, I believe that reading code is essential. It’s my opinion based on the Dreyfus model of skill acquisition.
00:03:46.920
The model outlines the five stages of learning, and everyone in this room is somewhere on that spectrum concerning Ruby. Each stage defines what you know and what you need at that stage to progress. If you're interested, 'Pragmatic Thinking and Learning' is a fantastic book on the subject. The critical point is that I think people should read a lot of code, especially at the expert level. You should be reading more than you write. Even if you debate the specifics in the hallway, ask yourself if you're reading enough code. I don't believe many people are.
00:05:00.639
So, why is reading code so important? There are many reasons. David Black always likes to say that you should read the Ruby standard library to learn how Rubyists write code. The 90-some libraries that ship with Ruby were written by experts, so you can learn how they accomplish their tasks. Additionally, you practice breaking down code, which is something you'll always need to do, whether it's during pair programming or debugging someone's library.
00:05:27.360
You learn where you can and can't rely on things through understanding code. Many people believe you must only look at good code, but that’s not necessarily true; examining bad code is beneficial too. For example, in the standard library, there are undoubtedly both good and bad examples. I think the pathname library is a great example of good interface design while the CGI library is the opposite, which is why we now have Rack.
00:06:05.479
In our industry, we constantly need to generate ideas. I wake up every day and joke with my wife that I have to be smart again. But seriously, we need to be innovative. Seeing other people's ideas and thinking about how to incorporate them into our work is essential.
00:06:30.679
Let’s get back to LittleBigPlanet. One of the reasons it is so successful is everything is tied together. The main character, Sackboy, is a funny little puppet with zippers that you can pose and control the expressions of, fitting him perfectly into the world of levels that people create. There are libraries, too, such as RestClient, which interacts with web services. It's similar to Active Resource but much simpler; you just call methods without needing to build classes for it.
00:07:02.480
RestClient is well-written code. By saying it’s well-written, I don't mean it’s bug-free; I've forked it and fixed bugs on GitHub. I just mean that it's structured well enough that I can find and fix bugs. It includes several neat features worth discussing. If you've never seen RestClient, here’s a simple example. I’m using the wordier interface here to read my tweets from Twitter. It takes two lines: the first line defines the resource to interact with, providing a name and password, while the second line specifies the action.
00:08:59.070
In the case of posting to Twitter, only one line changes, which is why I prefer the wordier interface for reusability. This is what RestClient looks like in practice, and I want to show you some additional insights into its workings. Let's delve a little deeper. First, you’ll notice this is a lot of code, and while I hope you can't read all of it, that’s not the point.
00:09:29.800
Even from the structure, you can tell it’s clean code. The lines aren't excessively long, avoiding ridiculous chaining, and they make good use of whitespace. I’m highlighting how the interaction occurs so that you can see the request and response processing. Although there are some less aesthetically pleasing parts, the quality of the overall code shines through.
00:10:14.080
RestClient also provides a fully-featured shell that can act as a curl replacement, allowing you to interact with web services directly. In this shell, you can provide the action you want to execute along with the URL, name, and password. It will return your tweets. Additionally, you can use it as an interactive shell, starting it up with a URL and name to play around with web services.
00:10:53.760
The interface does change slightly when using the shell, but it enhances ease of use, and the shell can log interactions in pure Ruby, creating executable code for you as you play around—though it won’t handle sensitive information. It's really a neat trick we don't utilize enough.
00:11:30.640
Now, shifting back to LittleBigPlanet, when I first came to it, I wanted to create Towers of Hanoi. My first attempt was mostly a bust, as I tried to model a wooden puzzle and ended up with difficulties due to certain obstacles. But over time, I redesigned and eventually published my final version to the LittleBigPlanet servers, which fit much better into the game’s aesthetic and structure. This flexibility and adaptability resonate throughout the various libraries I’ve worked on.
00:12:31.079
Take, for example, FasterCSV. I wrote it quite some time ago, and it has some important design points worth discussing. I've never spoken about it in public because I assumed CSV was as boring to others as it was to me. However, while reviewing Greg Brown's upcoming Ruby best practices book, I discovered many cool examples were pulled from it. The important aspect of FasterCSV is its clever data structures that allow you to access columns by name without breaking when columns are added or removed.
00:13:59.400
This design decision allows for a more stable codebase and enhances usability, especially with the multilingualization considerations taken into account when redesigning it to be the new standard library. When handling large datasets, we often need to ensure quick processing, which is why we develop strategies to handle encodings efficiently. I created helper methods for encoding strings while parsing, allowing us to maintain speed and accuracy throughout the process.
00:14:42.280
The new CSV library was the first significant implementation of multilingualization techniques, and funnily enough, I believe I also found and fixed several bugs as I developed it. We often encounter big data dumps from various sources, like databases or Excel sheets, which necessitates efficient parsing strategies to maintain performance without excessive penalties.
00:15:49.679
To optimize the process, you need to identify your data's encoding as you read it—whether it’s an IO or string. By defining simple helper methods for string encoding and regular expressions, I ensured that the data parsing remained coherent. The rest of the parser was built around these helper methods, making it efficient and fluent.
00:16:41.799
When looking at LittleBigPlanet levels, I often find examples of creativity and complexity. One level I found early on even featured a calculator. They provided a jetpack to explore the machinery behind the design, which was a valuable experience for understanding how to create complex machinery in LittleBigPlanet. I've learned a lot from experimenting with various Ruby libraries, such as BJ Slaving and Terminator, which have also been instrumental in my learning journey.
00:18:10.040
Why are these libraries important? In my current job, I need to build complex multi-processing software. These libraries have taught me about threading, forking, signals, and other fundamental concepts. I want to showcase how Terminator works because it's quite interesting and straightforward to follow. For those unfamiliar, it’s a replacement for Ruby’s standard timeout library, which poses problems in certain environments.
00:19:41.639
Terminator has a clean interface, and the real magic happens within a method where you can signal specific processes. The code essentially enables easy signaling while providing robust operation without the issues commonly experienced with alternatives. After explaining Terminator, I encourage those interested to explore BJ Slaving and Slave, two libraries that emphasize the beauty of Ruby's capabilities as well.
00:20:50.960
In conclusion, I encourage you all to delve into different codebases. Reading other people's code expands your horizons and improves your understanding. However, be mindful of potential pitfalls in code reading, especially within the dynamic nature of Ruby. Having a systematic plan will help you avoid frustration as you engage with the code. Develop a goal for your exploration, whether it’s unpacking gems or examining version control repositories. Use your familiar environments for comfort, seeking out methods hidden in core extensions. Pay attention to test cases since they reveal intended usage, and explore classes using IRB to get hands-on experience.
00:24:51.960
That's all the tips I have to share today. I'm happy to take a couple of questions while the next speaker sets up.
00:25:08.640
Any questions? No questions? All right, see you!
