PLANET RUBY ON RAILS

Rails 3.2.1 is out, with some fixes and doc improvements. Please check the CHANGELOGs gist for details.

So we didn’t quite make the December release date as we intended, but hey, why break a good tradition and start hitting release targets now! In any case, your patience has been worldly rewarded young grasshopper: Rails 3.2 is done, baked, tested, and ready to roll!

I’ve been running on 3-2-stable for a few months working on Basecamp Next and it’s been a real treat. The new faster dev mode in particular is a major step up over 3.1.

Do remember that this is the last intended release series that’s going to support Ruby 1.8.7. The master git branch for Rails is now targeting Rails 4.0, which will require Ruby 1.9.3 and above. So now is a great time to start the work on getting your app ready for the current version of Ruby. Let’s not hang around old versions forever and a Sunday like those Python guys :).

There’s a v3.2.0 tag on Github and we of course we still have the 3-2-stable branch as well. You can see all the glorious details of everything that was changed in our CHANGELOG compilation.

For documentation, we have the 3.2 release notes with upgrade instructions, both the API docs and the guides have been generated for 3.2 as well, and there’s a brand new 3.2-compatible version of Agile Web Development with Rails. A smörgåsbord indeed!

If you can’t be bothered with the full release notes, here’s a reprint of a few feature highlights from when we did the first release candidate:

Faster dev mode & routing

The most noticeable new feature is that development mode got a ton and a half faster. Inspired by Active Reload, we now only reload classes from files you’ve actually changed. The difference is dramatic on a larger application.

Route recognition also got a bunch faster thanks to the new Journey engine and we made linking much faster as well (especially apparent when you’re having 100+ links on a single page).

Explain queries

We’ve added a quick and easy way to explain quieries generated by ARel. In the console, you can run something like puts Person.active.limit(5).explain and you’ll get the query ARel produces explained (so you can easily see whether its using the right indexes). There’s even a default threshold in development mode where if a query takes more than half a second to run, it’s automatically explained inline—how about that!

Tagged logger

When you’re running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. Enter the TaggedLogging wrapper. It works like this:

Logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
Logger.tagged("BCX") { Logger.info "Stuff" } # Logs "[BCX] Stuff" 
Logger.tagged("BCX") do
  Logger.tagged("Jason") do
    Logger.info "Stuff" # Logs "\[BCX\] \[Jason\] Stuff" 
  end
end

Active Record Store

Key/value stores are great, but it’s not always you want to go the whole honking way just for a little variable-key action. Enter the Active Record Store:

class User < ActiveRecord::Base
  store :settings, accessors: [ :color, :homepage ]
end

u = User.new(color: 'black', homepage: '37signals.com')
u.color                          # Accessor stored attribute
u.settings[:country] = 'Denmark' # Any attribute, even if not specified with an accessor

Over the last year and a half, I have worked with a small group of students and staff to create an excellent online learning community at Mendicant University. Unfortunately, because Mendicant is something that we’re intentionally scaling at a very slow pace, we won’t directly reach as many people as we’d like to any time soon.

In this post, I’ve collected some of the things that I think contribute to making Mendicant University a great place to learn. I’d love to see these ideas integrated into more local and online groups, so that we can create a lot more great places for programmers to learn and grow.

Emphasize the personal goals and interests of your group

Getting a small group together to discuss the currently trending topics in the tech community while ignoring what is going on within your community is a tremendously waste of effort. It is much more effective to focus on the things that relate to the projects your community members are actively working on, as well as the challenges they face in their daily work.

Rather that having talks or study sessions on topics of general interest, it is more effective to figure out some concrete problems that members of your group need to solve, and then use your combined resources to help identify the right learning materials or people to talk to in order to get past the obstacles in your way.

While there are probably a lot of ways to do this, one interesting approach might be to have folks announce what they’re working on and what topics they’re interested in at the beginning of each meeting and then group together those with common interests. For an online group, you can use something like a wiki or periodic mailing list roundups to achieve similar results.

Practice formal code reviews

Rather than just talking in the abstract about ideas or strategies, it is best to actually sit down with editors open and code in front of you ready to review. A lot can be learned just through the process of explaining your code to someone else, and it is impossible to overstate the value of trying to teach others, even about tiny things like idioms or conventions.

If a particular bit of code would be too gnarly to review effectively, it can still be productive to hammer out a simplified example that illustrates the core concept you’re trying to study. The more concrete you can make your discussion, the more likely it is that you’ll get more directly valuable information while interacting with others.

Prefer evidence based arguments

Arguments based on authority (“So and so said…”) and arguments based on popularity (“Everyone does this…”) are very common in programming communities, but ultimately distract and divide more than they enlighten. Fortunately, there is a more productive way to have a discussion about code.

The most important thing for any discussion about different approachs to solving a given problem is to establish a clear context. Without context, it’s unclear whether a hammer or a bulldozer is the right tool for the job. With a context established, all discussion can refer back to it as a basis for determining whether a given approach is suitable or not.

From there, it’s mostly a matter of weighing tradeoffs between different approaches. For example, you might say something like “Sqlite is convenient to use because it doesn’t require you to run a database server, but because you’re going to be working with GIS data, you will probably want to work with PostgreSQL because PostGIS provides a ton of useful functionality there”. This statement is not bulletproof, but it will lead to a much better conversation than “Sqlite sucks, use PostgreSQL”.

Sometimes, you will want to express things that are purely personal preferences, and that’s okay. But when you do so, it helps to point out that you’re not trying to have a reasoned argument but instead just sharing your gut feeling. This will help avoid religious arguments in most cases.

Seek purposeful ways of practicing and studying

Every day you will find some new recommendation for what the next revolutionary way to learn how to code is. You’ll also discover that some new topic of interest is the one that every just needs to learn and talk about RIGHT NOW. Of course, this false sense of importance and urgency is nothing more than smoke and mirrors, and if you get caught up in it you’ll spend more time chasing your tail than you do building useful stuff.

Whenever possible, use a goal based, hands-on approach to learning new things. Try out new ideas and technology on low-risk projects that might end up being useful to you later if possible. If you do spend some time on deliberate practice as opposed to practicing-while-working, make sure that it’s to address a specific need or problem you’ve encountered. For example: a code kata might be just the right tool for learning the syntax of a new language or trying out learning new tricks in your text editor, but it’s a bad idea to practice code katas just waiting for serindipitous learning. Happy accidents do happen, but you shouldn’t rely on luck as a way to move you forward.

While this particular point is more focused on individual practice than it is on practicing in a group, the same set of goals should be present in any group activities you engage in. Whenever possible, break into focus groups as needed to avoid forcing several members to practice/study something only remotely interesting or relevant to them. Our available time and attention is a precious resource, and should be spent wisely.

It’s worth noting that this advice is NOT meant to be taken as a push to focus only on narrow and practical goals. Deep studying of theory or classical topics can be very useful and is particularly suitable for group activities. It’s just essential to tie this back in some way to a deep and personal goal rather than just a vague intellectual interest.

Create a good balance between socializing and getting stuff done

Without room for socializing, it will be hard for any group to develop a common culture and a shared set of interests. However, I’ve seen far too many users group “hackfests” turn into water cooler discussions, and if the social norms are established to encourage this sort of behavior, there will be no chance for the values of deep practice to set in.

For in-person gatherings, it might make sense to have either a working session followed by some social event, or separate nights for social and working sessions. Online, similar separations can be made by having some activities designed for work and others for casual socialization. You don’t need to be a fascist about enforcing this dividing line, but setting some clear expectations go a long way.

Establish a culture of participation and sharing

Your group should be defined by what its members do, not just what they talk about. Do what you can to highlight the contributions of your members, and favor activities that involve active collaboration rather than ones that require one person to do the bulk of the work while everyone else passively consumes information.

For in-person gatherings, I like things like lightning talks and hackfests, as long as they are mostly focused on what group members are working on, as opposed to just repeating something that someone else said or did. I also think that group discussions can be very effective as long as some structure and decent moderation is provided.

Online, similar results can be achieved by focusing on code reviews and discussions of specific articles or questions about how to solve a given problem.

Both online and in personal, work on and discussion of open source software goes a long way. Doing everything you can to encourage your members to share their work publicly will make a huge difference and create a positive form of social pressure to actively share. Of course, not everyone will have time to run their own projects or contribute large patches to other projects. But as soon as you hear someone complain about a bug or problem that they haven’t reported yet, that’s the time to sit down and show them how to write a minimal reproducing example and file a ticket. Sometimes a few minutes of guidance is all it takes to transform someone who does little more than complain on twitter to an active contributor to open source projects.

Practice social awareness and take care not to exclude marginalized groups

Many technical groups (both online and local) fail at breaking away from some pretty embarrassing social norms. While we may not feel this way as individuals, as a group we are consistently guilty of tolerating exclusionary behavior that would not be tolerated in most other social settings. Remember that while the bulk of programmers who attend technical events are heterosexual upper-middle class white males in their 20s and 30s, there is a whole world of folks who are just as passionate and capable of achieving great things technically but do not fit that stereotype.

This does not mean being excessively politically correct or losing your sense of humor. It does mean that if you would not make a certain joke or statement in front of a more diverse group of people, you might want to avoid saying it to your programmer buddies. It also means that you should check your cultural assumptions about others at the door, and focus instead on what people can do rather than what makes them different from you.

Most of the advice I’ve given in this article will naturally create an environment that is more inviting to a broader-based community than the one we’re currently serving, but I wanted to call out this issue in particular as being one that is too important to ignore. Organizers of communities need to specifically keep these issues in mind, as they are the ones that have the best chance at setting expectations for what is expected of group members.

People work and learn best in an environment in which they feel safe, welcome, and appreciated. If each member in your group values that sort of environment, you’ll end up achieving more as a group than you would in a group where some folks feel marginalized or unappreciated.

Questions?

I care a lot about these ideas, and would love to help spread them beyond the digital walls of Mendicant University and out into the world. If you want to start up your own group based on these ideas or want some help incorporating them into a group you’re currently organizing, I’d be happy to help. You can leave a comment here, or you can even catch up with me over Skype. Send an email to gregory.t.brown@gmail.com with your availability in UTC time and I will be happy to meet with you.

I love making beef jerky. I started making jerky by using Alton Brown’s recipe, but I found his jerky making apparatus to be lacking in a few key areas, so I put together my own jerky making setup. I use a modified food dehydrator for making my jerky. I prefer using a food dehydrator because it’s easy to clean, efficient at circulating air, and easily adjustable to accommodate larger or smaller batches of meat. Jerky is supposed to be air dried with no heat. Drying with no heat required modification of my dehydrator. I would like to share my modification process with you!

Getting started

I use a Nesco American Harvest dehydrator. I found mine on sale for about $50, but it looks like the going rate on Amazon is about $65.

I like this dryer because the fan is on top, it’s easy to clean, and you can buy and use extra trays. I think it goes up to 10 or 15 trays, but I only have 8.

Step 1: Remove the top nob

In order to disconnect the heating element, we must remove the plastic bar that goes across the top of the fan. The first step is to remove the knob:

Just pull the knob straight up, and it should come off:

Step 2: Disconnect the bar

Flip the lid over. There should be four screws outside the ring. Remove just those four screws:

Flip the lid back over, and you should be able to remove the center plastic bar with the Nesco logo on it:

Step 3: Disconnect the heater

These two leads go to the potentiometer that controls the heater:

Disconnect one. The circuit will open, and the heater disabled:

I taped mine down with electrical tape:

That’s it!

Just follow the steps backwards to reassemble your dryer. The electrically inclined may want to enhance their dryer with a switch. I (on the other hand) am lazy. I bought a second dryer so that I could make jerky and do normal food dehydrating at the same time.

You can see more pictures of the process here. I plan to write a follow up post where I actually make jerky. Yum!