RailsBridge: when WiFi decides whether you stay or leave

It only took a little bit of WiFi to make a difference between a productive workshop experience, and a waste of time. The workshop was RailsBridge, a free Ruby on Rails workshop for beginners. I have been dabbling in Rails for a while now, but there is only so much you can do in those minutes before sleep, when you are finally done with the day's work, and finally think you can sneak a smidge of time for your pet project -- only to find yourself faceplanting in the keyboard. So I went to a RailsBridge to learn "proper" Ruby on Rails development, complete with things like unit tests, that I tend to skip if I have just 15 minutes in the evening to learn a new framework.

RailsBridge was part of Lone Star Ruby Conf 2013 in Austin, TX, and it was lead by the main instructor, Sarah Mei (founder of RailsBridge workshops), and many coaches. The students were divided into groups of approximately 4-6 people. The process of dividing ourselves was interesting, and worth a paragraph, but since it was nonessential to the workshop, I put it at the bottom.

Among the RailsBridge students half or more were women, so it wasn't surprising that I ended up in a group with two other women. Much sooner than I would have liked I became the only one -- indeed, the only person in the group. The culprit was the same one that disrupted many a conference by its presence, the same one that is often cursed for not allowing us to be in the moment and actually pay attention to the speaker: internet connectivity. This time it disrupted the workshop by its absence. As it turns out, you can't really create even a skeleton Ruby on Rails application (not if you're a beginner) without internet connectivity. Creating an app a standard way requires installing a bunch of Ruby gems via Bundler from the internet. This is true even if you already have those gems on your computer, having created other Rails applications earlier. The instructors told me that it would be very tricky to copy those gems from one application to another. Because dependencies.

RailsBridge student Rachel (left), and Sarah Mei, half-hidden behind another student, at RailsBridge in July of 2013 in Austin, TX. More pictures from RailsBridge can be found in my photo gallery.

And WiFi didn't work at Lone Star Ruby Conf, at least not on the RailsBridge day. As a result, many people could not even create a simplest application. One of the women in my group left right away. Another group did not even attempt to create a Rails app: instead, its coach gave the group an impromptu lecture on the basics of web development: a little bit about Javascript, CSS, and HTML. A good thing if you are completely new to web development, but not so good if you came here for advanced knowledge.

On a rare moment when WiFi held fast for entire minute, I was able to download some Ruby gems on the fifth try. And so finally I and the other person in my group created a skeleton Rails app. The other person was, like me, not a novice programmer: she was the founder and the only developer of BeerGram, a startup that is developing an app that lets you buy another person a beer at participating bars. Though she is an iPhone developer, she was curious to learn about Ruby on Rails and understand its potential for her startup.

Due to those difficulties, during the workshop we didn't get much further than creation of a very basic out-of-the-box Rails app. While I myself have created more complex apps in the past, there was one good nugget I learned: debugging from Rails console. You start the console in the shell, and it's a command-line interface to your application. You can instantiate your app's objects and call Active Record query methods on them. That makes debugging much easier, because debugging the backend via your application's web interface can be cumbersome.

After lunch I remained the only person in the group, so I had the instructor all to myself. He asked what else I wanted to learn, so I asked him how I should approach some problems with my personal Rails projects.

Left to right: unidentified woman, Andrea, James Gray (instructor of our group), and two teaching assistants from Maker Square at RailsBridge in July of 2013 in Austin, TX. More pictures from RailsBridge can be found in my photo gallery.

My specific problem was that the list page of my application was passing around too many parameters in every link, and every redirect_to call. To display only the records with timestamps that fell in a certain range, my application used select_datetime helper. Those parameters were the datetime components (year, month, day, hour, minute, second) for starting date, and the same for the ending date: that's 12 parameters already. I have lots of links in my page, such as page number links and table header links (for sorting), and each of those links needs to pass all these parameters in the query string of the GET request. Plus, Rails uses redirect_to to redirect to index page after deletion of record(s). When redirecting, it needs to pass all those parameters again! I got annoyed by this clunkiness, especially since it reminded me of the days I wrote bleeding-edge (ahem) CGI applications in Perl, in the glorious 1999 before the crash of the dot-com boom. Passing bunches of parameters from page to page was what we did. I thought there should be a better way in 2013.

What made simplification easier is that select_datetime parameters already were being passed around as two hashes: params[:start_] was a hash of parameters generated by the select_datetime widget that represents starting time, and params[:end_] was a hash of parameters generated by the select_datetime widget that represents ending time. Each hash has 6 elements. So when I wanted to pass those starting and ending times to link_to or redirect_to, I could just pass them like this:

In other words, parameters in Rails can be "wrapped" in hashes (and, apparently, also in arrays). In yet other words, the values of the params hash (where all the parameters are stored) can be hashes and arrays. It's not an obscure fact -- it is clearly spelled out in the Rails documentation -- but it took an instructor to point that out to me. Sometimes you get so absorbed in getting things done, that you don't even stumble upon the right piece of documentation until later. That's especially true when you are new to a programming language or framework, and your learning is going off in several directions: for example, maybe you've been trying to figure out routes so much that you neglected to explore an easier way to pass parameters. So it takes a workshop instructor to suggest this to you. James Gray, the instructor, also suggested another option, to store parameters in Session.

On a completely different note: it appears that the food served at lunch at Lone Star Ruby Conf was made from the flesh of overeaters. But not all of it! You could also get some sandwiches (by special request only) made of lean people. Don't believe me? Here is a picture!

Glutton-free (yes, glutton!) sandwiches served at RailsBridge in July of 2013 in Austin, TX. More pictures from RailsBridge can be found in my photo gallery.

And now, on sorting developers into study groups. As I said, half or more of RailsBridge students were women. It's been noted that male and female developers differ in how they rate their skills, so beginner-intermediate-advanced sorting may not work. Sarah Mei gave anecdotal evidence of that. She used to ask her students which of them were already programmers. A lot of women didn't raise their hands; some might say outright "I am not a programmer". When Sarah asked one of those women, "so what do you do with the computer?", the woman answered: "I just use it for email." Then later in the conversation she casually said: "Back when I used to program..." Oh, so you used to program, Sarah asked. It turned out that the woman had a computer science degree and worked as a professional developer until 2 years ago.

So, asking people to divide themselves into groups by experience wouldn't work very well, because many women underestimate or downplay their experience.

So Sarah Mei suggested a different way for people to divide themselves into groups. Starting with herself, she asked people to tell some personal fact about themselves, and then everybody who shared the same experience or biographical fact were to join that person, while everyone else had to go to the other side of the room. For example, she asked everyone who did not program the computer until after they were 18 years old, to join her. That was quite a few people. Then another guy asked everyone who wasn't born in the United States to join him -- and that turned out to be about 1/3 of the attendees. Then someone else started a group for everyone who currently or in the past programmed in C-derived languages, such as C, C++, C#, or Objective C. Another person started a group for everyone who was primarily an HTML/CSS developer. However, I can't say I understood the purpose of this exercise, other than it was an introvert-friendly "getting-to-know-you" introductory game: everybody could find out some facts about one another, and no one has to say a word. The downside was that you had to have a very good memory to keep track of which circles your classmates joined. But this wasn't much of a sorting exercise: with every revealed factoid the class divided themselves into 2 groups, so you couldn't form a larger number of groups based on it. Maybe it could have worked differently if with every subsequent question each group split into two: one that said "yes" to this question, and another that said "no". But then after just 3 questions we would have had more groups than there were coaches.

Eventually Sarah Mei put a stop to this exercise and divided the people into roughly similar size groups based on some arbitrarily picked criteria. I ended up in the C-based language programmers' group. The HTML/CSS developers ended up in their own group. I don't know what other groups were based on.