Planet Ruby on Rails Feed

Free Help

Mon, 30 Jan 2012 13:00:00 +0000

Sigh. Here I’m going to sound like one of those celebrities. But I thought I should lay down some ground rules, so here goes.

Yesterday, I received a 1,063 word email from a non-profit organisataion asking me for advice on whether or not they should use Rails or Django for their new project. They begin with:

We found your answers and profile on Stack Overflow. We’re reaching out to you because we’d like your advice on a new nonprofit project, name, and the language/app framework we should use to develop it.

We have a fairly small budget to build the framework and to do betas of the first seven sites, so itÃ¢Â?Â?s crucial we pick the right framework. We are trying to choose between Django and Rails, and we want to make the right choice.

Quite obviously, my answer is going to be heavily biased in one direction. I’m sure you can guess which one.

Before yesterday, I’d never even heard of this charity, nor spoken to the person who sent me the email. Basically, up until this point, we’ve done nothing for each other. Their questions obtusely relate to Rails, and definitely doesn’t relate to what I get paid to work on.

So I read the email anyway. It explains what the charity does and what they’d like their new platform to do. Then at the bottom, they ask if I could “take a look at the high-level requirements” and link me to a Google Docs Spreadsheet. Inside this spreadsheet, there’s 32 very wordy questions, like this one:

We need the front ends and backends to run fast. Many of the backend pages will have fairly intensive reports drawing on lots of data from user pages, such as nonprofits being able to run reports of total donations over periods of time, recent donations, etc. We think speed is a top priority.

Each question, by my estimates, would take one hundred to five hundred words to answer adequately. So at a minimum, around 3,200 words of mine to answer their questions. This is from a complete stranger in a private conversation between myself and them. Do you know what other situation this happens in usually?

Oh yeah, paid consulting. But there’s nothing in the email that indicates that I will get anything more than a warm and fuzzy feeling from answering it.

Like I said before, this is not related to anything that I do. This is extra work. It’s in a private conversation, so my answers won’t benefit anybody else. If this question pops up again, chances are that I will have to answer it again, and that’s not cool.

These kinds of emails are basically a three-times-a-week deal, and I’m over it. While I enjoy helping people for free, I will only do so in a public forum where other people can benefit from the answers. If you want to contact me privately, then I will ask for some sort of reward for it, because very few people are going to benefit from it.

These kinds of questions have no regard for my time, and all I get from them is a feeling of being used for my talents. Kind of like a whore, just without the money changing hands thing.

No more.

Rails 3.2.1 has been released

Thu, 26 Jan 2012 23:32:00 +0000

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

Rails 3.2.0: Faster dev mode & routing, explain queries, tagged logger, store

Fri, 20 Jan 2012 17:22:00 +0000

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

Kicking ass together: How to improve coding skills as a group

Mon, 16 Jan 2012 18:00:00 +0000

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.

Can has payday?

Mon, 16 Jan 2012 13:00:00 +0000

You may know, if you’re a frequent reader of this blog, that I am moving to Melbourne soon. How soon? This weekend soon.

In order to move, I’m going to pack as many of My Things as I can into My Car and then Drive to Melbourne. Simple.

When I get to Melbourne, I am going to unpack My Things from My Car and put them in My Apartment. But I don’t own enough Things. When I get to my Apartment I will need to buy more Things.

For instance, I will need to buy a saucepan that will become My Saucepan. I may even buy multiple saucepans. I will need to buy a fridge that will be My Fridge. Oh there are so many things that will be Mine.

But to buy all these things, I am going to be relying on a certain batch of money. See, moving out wasn’t something I planned on doing this soon and so I didn’t save up enough of My Money to buy more things to be My Things. That was My Mistake, and I know better now.

This little batch of money happens to be payment for My Book, which is owed to me by My Publisher. I have an email here from the 5th of January that asks to confirm the royalty split between myself and My Co-Author, to which I replied almost 30 minutes later.

There’s another email from Yehuda saying that he should get the money from the copies that were sold before I joined the project, and another shortly after with me agreeing to this. These emails are on the 6th of January.

There is an email on the 6th of January again, from My Publisher’s Acquisitions Guy that simply states ”I’ll confirm the count before Ryan joined. Should be pretty easy”.

Clearly this was not the case, as by the 11th I still had not received My Money that I would dearly like for My Things. I send another email on the 11th asking “Hey all, how goes the movement on this? I’m moving into a new place on the 23rd and would love to spend the money on some furniture :)”.

Yes, I put a smiley face there. It’s something I do.

Again on the 11th, Yehuda replies with “Sorry, what works for me. Whatever Michael says the count is fine with me.”. Okay, so that’s now an agreement from all parties and an explicit statement that I would like My Money in the not too distant future.

Thanks to the Internet and modern banking systems, it shouldn’t be that difficult.

It is now the 17th January, 12 days since the initial email. 6 days since the confirmation. I am sure, by now, everyone is back from the New Years holidays. And yet… there’s still no money. There’s not even an update saying that My Money is on its way.

While you may think that waiting simply 6 days for a chunk of money is simply being impatient (and you’d be right), the way I see it is that I’ve been waiting since the middle of September when My Book was published.

The lack of an update makes me sad. I would really like My Money so I can spend it on more Things to make them become My Things, even going as far as to furnish My Apartment.

But don’t worry, I have money. It’s just not My Money. It belongs to Mr Taxman. And if that money isn’t there when Mr Taxman comes around, then Mr Taxman would not be happy and it’ll all be a self-perpetuating cycle of unhappiness. This money that belongs to Mr Taxman is kept away from My Money so that I don’t touch it. It’s The Golden Rule. I don’t like to break The Golden Rules.

I just really hope that it doesn’t turn into something like this. Then we’re all fucked.