Tag Archives: ruby

I’ve seen some discussion over the years on how to onboard new Ruby developers. What about re-onboarding “old” developers though?

I’ve been a Ruby developer for several years. I remember the bump to Rails 1.0. We used to have to hand-crank our app servers while walking uphill. You kids don’t know how good you have it. I digress while I shake my cane.

As I was saying, I’ve been in the community for a long time, but I have also been away from ruby for several months on other languages. I consider Ruby my “home” language, though, and the Ruby community is a special community that I enjoy feeling a connection with.

So how do I reorient myself? How do I stay connected with the language and the community that I am not always directly involved in?

Twitter

Local Ruby Brigade

Practice

Playing Around

Twitter

I follow a lot of developers on Twitter, as one does. Sometimes I binge add people, and sometimes I cull the list. I love the community, but I don’t love the drama. The drama sometimes eats at me, actually. The things that we get worked up about also eat at me, but sometimes we get a little caught up in the swirl.

I like seeing the evolution of the language and ideas. I like seeing other languages come into play, too. I don’t think Ruby is necessarily the best language solution for all problems, and I believe that it’s important to have a varied language toolkit at your disposal.

Local Ruby Brigade

User groups are a fantastic resource. The Dallas Ruby Brigade has always been very open and nurturing in my experience. There are monthly meetings where people give talks, and I’ve given a few over the years. There are also weekly meetups where we code and socialize. We also have an active mailing list where we discuss current events, upcoming meetings, and also ask and answer questions.

I felt safe as an inexperienced developer, and I am tremendously grateful. A local user group is a really great place to keep your chops up and get experience talking in a group setting (whether in the front or in the audience).

After a couple of years I felt like it was my turn to “give back” and get more involved, which has been very fulfilling.

Practice

Certainly you can practice the wrong things, but I find practice very valuable. Repetition helps me learn and cements ideas for me. I also learn by doing. I need a concept to have a practical application or else I just will not see it. For the past several months I have done Exercism exercises in several languages. For a while I was doing Ruby backend services, so I did Javascript exercises to keep up those chops. Then we started doing a lot of native apps, so I focused on Ruby exercises. I’ve also looked at a few katas here and there. Sometimes they’re really hard and I don’t get them. Sometimes they’re too easy and I don’t get much value out of those either. Usually they’re just right though.

Scratch An Itch (Play Around)

I’ll occasionally try to cook up a little project to work on. I can’t tell you how many times I’ve redone my blog. Not each of those has seen the light of day, and that’s ok. It’s more about the process. I usually also have a new data model in mind, which means that the data needs to be transformed. I love data, and this is a really fun exercise for me. ActiveRecord is great, but it can also be pretty limiting. Sometimes raw SQL really is the best way to express what you need to do.

Other

I also try to make it to at least one Ruby conference a year, as well as submit talks on various things. Thinking about what I might be able to shed light on or what things of value I might be able to share helps me take a critical look at my own growth and evolution.

Addendum

I realized as I was walking around thinking about doing something in Xcode that this isn’t just Ruby for me. I bounce around languages a lot based on the projects I work on. One thing that is unique to Ruby, though, is the community.

When I’m working on a Rails app that relies on live data, like a reporting app for example, I find myself constantly wanting to pull live data to my local dev database. So I made a rake task to do this:

I had the privilege of attending DCamp this past weekend. It was awesome. While doing the Game Of Life pairing sessions, one of my pair partners wanted to explore the exercise using Minitest. Neither of us had ever used it, so we moved on with RSpec and I made a note to come back to it.

I try to be discerning about bringing additional dependencies (including gems) into a project. I’ve always just used test/unit, and I prefer that syntax over the RSpec syntax. Minitest is baked into the stdlib (starting with Ruby 1.9.3), so you’ve already got everything you need. You can also write tests using either the test/unit or spec style. Win-win right? If you want more there are also additional gems that can supplement functionality. Everybody wins!!!

require 'minitest/autorun'
require_relative "../lib/meme"
describe Meme do
before do
@meme = Meme.new
end
describe "when asked about cheeseburgers" do
it "must respond positively" do
@meme.i_can_has_cheezburger?.must_equal "OHAI!"
end
end
describe "when asked about blending possibilities" do
it "won't say no" do
@meme.will_it_blend?.wont_match /^no/i
end
end
end

We experiment with a lot of things at work. Tools. Technologies. Workflows. Recently we were discussing an effective way to do native iOS development with the team. I love RubyMotion. I think it makes it faster and easier to create a native iOS app. There is a learning curve, though.

We are considering doing a project where the app is native, and written is XCode, but the guts of the app are just web views fed by a Rails app. But before we could really consider that as an option, we needed to know how it would handle mapping.

So I whipped up a quick and dirty RubyMotion app to see. I used Leaflet for the HTML version, and had the webpage be served from as a resource in the app.

Recently I’ve seen a good handful of something that I’ve never seen before in the Ruby world, and it mystifies me. I’ve been going through exercises on Exercism (http://exercism.io), and in the Ruby exercises I’ve seen several people using private attr_accessor. What?

The argument, so far, has been that it’s the same as doing it the long way so why not?

So, I am all for the use of attr accessors, and I am all for tucking implementation details away in private methods. The use of a private attr does nothing for the latter. You’ve simply added more obscure code that doesn’t tell future you or future maintainers anything about what you intended or thought might happen. If you think the implementation might change or evolve, then go ahead and write the extra 2 lines to define the method explicitly. Otherwise just use the ivar.

Now, it’s entirely possible that I’m just being grumpy old man and shaking my cane. If there is a good reason that’s come along that I haven’t picked up on yet I would love to understand it. For now, though, I’m maintaining that this is a weird antipattern.