I’m always looking for side projects that are the right mix of feasible, fun, relevant to my career, and interesting. Recently I joined Excella’s Ruby Book Club, and started a side project that is just the right mix: A silly retro game in Ruby!
The game is built on the gem gosu. Gosu does the actual C++ calls to deal with I/O and graphics, and gives you nice, pretty Ruby abstractions so you can draw rectangles and ask whether the spacebar is down. I’m having a blast so far.
When I started Ruby, I wanted to learn the language in some real depth. I asked a few coworkers, “What is the C# In Depth of Ruby?” Eventually, someone recommended Ruby Under a Microscope. This book helps me see through some Ruby magic and understand a little bit better. Scott Hanselman recently posted that some people learn from the metal up, wanting to understand CPUs and compilers, and some people learn from the glass back, making something the user can see, then tackling technical details as needed. I am definitely a metal-up learner, and Ruby Under a Microscope is definitely a metal-up book. There are almost as many code samples in Ruby bytecode as in Ruby.
Continue reading “Book Recommendation: Ruby Under a Microscope”
I’m in the middle of Ruby Under a Microscope by Pat Shaughnessy. I love the book so far, and I will certainly post a more specific review and recommendation soon, but I just noticed a real semantic difference between Ruby and C# that I wanted to blog about, because it would certainly have tripped me up if I had stumbled across it in production code. From Shaughnessy’s chapter on hash tables:
In the case of strings and arrays, Ruby actually iterates through all the characters in the string or the elements in the array and calculates a cumulative hash value (p. 183)
“That’s weird,” I thought, “I bet that means that it’s not safe to use arrays as hash table keys in Ruby. So I did an experiment:
If you, like me, have recently switched to Ruby from another language, you might be looking for some good Ruby-specific technical resources. I know when I was doing more .NET, I had my go-to podcasts, books, and blogs. I’m trying to find the same resources for Ruby.
At Ruby Retrocession, I had a great chance to ask some much more experienced Rubyists what they would recommend. I asked specifically for resources for someone who was new to Ruby but not new to programming, and who wanted to come up to speed quickly.
When I was at the Ruby Retrocession, I felt very welcome. That was great, obviously, and it’s not like I felt very unwelcome at previous conferences, but I want to talk for a second about why I felt so welcome at this Ruby event. If you organize, or even attend, tech events, making people welcome is pretty important. Making people feel extra welcome is a tool I didn’t know was missing, so I’m reporting it here in case someone else is missing it too. (Also, this post covers the “new concepts and terms” and the “impressions of the Ruby community” that I mentioned last time.)
On Saturday, I went to Ruby Retrocession, which is an unconference.
This was my first unconference, my first Ruby conference, and really my first programming event that was primarily in the open source space. That’s probably too much to go over in one post, so I’ll try to talk about the event over several posts with some logical division.
There seem to be four topics here:
I’m going to treat these topics in reverse order. There was a lot of good advice at the event, and I want to capture as much of that as I can. The book recommendations will probably be in separate posts.
One of Ruby’s strengths as a language is that it allows a great deal of metaprogramming; that is, Ruby programs can modify themselves as they execute. Testing is a common place to see metaprogramming. Recently, I’ve been using Minitest, which is a testing library for Ruby. Minitest lets you mock methods fairly easily, but the way the syntax works feels pretty magical. I don’t like magic (at least not in software), so I wanted to try to dig into this metaprogramming a bit and understand how mocks work. Note, this post is not about when, or even whether, we should mock stuff in Ruby; I just want to understand how the testing libraries accomplish mocking, and specifically how they accomplish stubbing.
I’ve been privileged these past few months to run the .NET DC User Group. This post is about my experience doing so, in case someone out there is interested in running a user group.
I inherited this user group; I didn’t start it. The two previous organizers, @TashaEv and @justcallme98 re-started and grew the community. Before they moved away, they made sure that I had all the right accounts and passwords, and a bag of swag to give away, and a few months’ of speakers lined up. This post is about what it’s like to run a Meetup. @TashaEv and @justcallme98 did the hard part of actually building up the community. Thanks! Continue reading “Running .NET DC”
Since I use Ruby at work now, and since I understand C# syntax much better than I understand Ruby syntax, I occasionally run into things that look like they should or shouldn’t work in Ruby, but surprise me by working (or not working). Today I’ll document the first of these surprises: you can’t call static methods from instance methods in Ruby.
To illustrate what I mean, I’ve made two simple examples: Continue reading “Static and Instance Methods”
The other day I was taking an Uber (though I’ve since switched to Lyft), and the driver told me that sometimes the GPS will admit that it’s lost. “Yeah,” she said, “sometimes it will say ‘GPS is lost’. Everyone thinks it’s funny when even the GPS is lost.” I realized that she was probably thinking about the message “GPS signal lost.” For me, hearing the message “GPS signal lost” is about signals. The app is telling me, “Hey! I depend on this particular type of signal, and right now I’m not receiving it.”
I heard signal as a central word in the GPS’s utterance. The way the driver spoke, though, it sounded as though what she heard when the GPS lost signal was that the GPS found the current directions too confusing. There’s a subtle type of miscommunication here: one person is automatically reading an utterance as a technical diagnosis, and the other is not inferring some piece of technical information. But both people were presented with the same exact utterance.
willmurphyscode 