So Many Curricula

Suggestotron is the flagship RailsBridge curriculum. Although somewhat difficult to say aloud, it is the springboard for all RailsBridge intro to Rails classes, whether the students are total “Ruby Nubys” or professional Java developers wanting to learn more about this Rails thing. For the uninitiated, Suggestotron walks you step-by-step through building (and deploying to Heroku) a little topic-voting app: anyone can submit topics with descriptions, see them listed on a page, and vote them up. Kind of like a very, very lightweight Digg, as my first teacher said, back in the days when people talked about Digg like it was a thing.

Three years later, Suggestotron is still being used heavily and has been tweaked and given love and attention by a lot of different people. Since all the RailsBridge curricula are open source, you can fork it and submit a pull request if you see something that could be improved.

(Although not a curriculum, we also pour our hearts and souls into our step-by-step Installfest instructions, which cover all major operating systems and include contingency instructions for when things don’t go perfectly. Technologies installed or set up include: Ruby, Rails, Git, a bunch of gems, Heroku SSL keys, a text editor, and other OS-specific things, like RVM and Windows terminal config stuff. The Installfest instructions are quite the labor of love.)

In February 2012, for logistical reasons, there wasn’t a workshop planned. According to legend, a core member of the RailsBridge team, Steven! Ragnarök, thought it was high time to teach people a little bit more about front-end development and all the HTML-writing that Rails was saving them from. A friend of a friend of RailsBridge (and fantastic frontend dev), Ryan Richards, whipped up a curriculum and lead the first front end workshop. For the next front end workshop a scant two months later, another amazing frontend dev, Emily Nakashima, powered by caffeine and a looming workshop date, morphed Ryan’s original presentations into a web-based curriculum that could be used by students at every level. People were so excited. This was something they’d been wanting to learn, and now we were RailsBridge-i-fying frontend development. Success!

At this point in the story, we have two RailsBridge curricula (in addition to the slide decks we’d had covering Ruby for Beginners and Ruby for Programmers). Even more curricula were discussed in depth on the workshop organizer’s mailing list, and Carina Zona decided to make a full-day Ruby-only workshop a reality. We held that workshop on August 24 & 25, 2012 and had an awesome time digging into Ruby.

The most recent addition to the stable is what is currently being called the Intermediate Rails curriculum, and was written by Travis Grathwell and me. It’s a decidedly *not* step-by-step walk through building a Rails app: it presents features that need to be completed, then gives the student online resources, hints, and discussion topics that the teacher should consider covering. In it, you build a message board — something of a souped-up Suggestotron, with comments on the posts pages. One of the authors of that curriculum (me) made a writeup of the curriculum-writing process and how the first workshop went — you can check it out here.

And since there is so, so much more to learn, there is another curriculum in the works: Michele Titolo is – right now – writing an iOS curriculum! It is going to be awesome.

With all these things, and more on the horizon, it was high time that an index with all the different curricula existed. Thankfully, one was born on Tuesday, November 19, 2012. Check it out, and feel very encouraged to make pull requests, start your own workshops, write your own curriculum, and share your accomplishments with us (by commenting here, joining and posting to the workshop mailing list, or any other way you think would be fun).

Oh, you do want to write a curriculum? Here are just a few ideas for things we’d love to teach and learn:

  • Test-Driven Development
  • Terminal / Shell Superpowers
  • How Computers Work (Physically)
  • Networking And Its Joys
  • All About Browsers
  • Git: In Depth!
  • How To Be All Agile ’n Stuff

Want to talk about this on Twitter? Hit me up — I’m @lilliealbert.


So Many Curricula

Making a New Rails Curriculum

(Hi! I’m Lillie Chilen, and I do meta-organizing for RailsBridge SF, which means that I work with Rachel Myers to find organizers and venues for our monthly workshops here. This is a post I wrote on my blog and thought you might like!)

On a Sunday afternoon about a month ago, Travis Grathwell said he thought we should build a message board. So we sat on our couch and worked the rest of the day; him making suggestions for what I might do next, me remembering what rails is. I wanted it to be pretty, so after I had an empty app and had installed Devise (the authentication gem that Travis wanted to use), I added a rails-friendly version of Bootstrap. Since I didn’t know how any of these things worked already (and Travis knew generally, but didn’t know the specific commands to type in) we just read through the documentation and troubleshot as necessary.

After getting things set up, we were ready to actually make something useful — a post. I was a little bit rusty on the old MVC and what those things meant, but we played Follow the Error Message and got the models, views, and controllers set up. It got a little crazier when we added commenting (nested resources, anyone?), but by the end of the day I had a fun little app and Travis had posted on my LillieBoard message board with a topic of “Lillie is a doof”. I commented that that was not accurate.

Since we wanted to make a new Rails curriculum that was a bit closer to what it’s like to program IRL, we set out a series of four challenges:

  • Install Devise and make a static home page
  • Add Bootstrap
  • Add posts functionality
  • Add commenting

Each step had a series of requirements (i.e. “The user should be able to create a post with a title, author, date published, and content.”), as well as topics that teachers and students would probably want to discuss, links to topical resources, and some hints.

We did a little bit of beta testing with the gracious and supersmart Michelle Glauser during a RailsBridge workshop at GitHub. We found more pieces that needed clarification and decided to break up the beginning slides a bit more, so the “Make a static home page” came before “Install Devise” — having a home page before having authentication made it a lot easier to see what was going on.

I decided to organize a workshop to give this new curriculum a shot, and the fantastic VP of Engineering at VerticalResponse was totally behind sponsoring and hosting. So while testing and improving the curriculum, I got to plan foodstuffs and send many, many emails. Once the workshop was definitely happening, we tried to improve the curriculum as much as possible. We ended up splitting up the steps even more, and Travis made some sweet mockups using Balsamiq. I didn’t expect students to get through to the end, but I did figure they’d get to the point of being able to create a post.

Turns out it was kind of hard! By the time we had lunch, one class had just finished adding Devise to their app. But that class also spent a time in the morning reviewing CRUD and other concepts, so that once they were actually coding they had a better idea of what was going on. Another class sort of dissolved around 3:30pm, which was concerning, but the teacher himself said that he didn’t really stop them, and the students felt like they should just work on it at home, if they weren’t going to be told what to do. This seemed like the exception, though, as a lot of the classes were still working hard at 4:15pm when I started haranguing them to pack up for the day.

After we wrapped, we had a damn lively teacher’s retro — a lot of opinions on improvements for the curriculum as well as for sorting students to make sure they were in the correct class. On the registration survey, I had described each curriculum and let students choose between doing to intro Rails curriculum at one of two levels (Beginner or Advanced Beginner) or doing the brand-new Intermediate curriculum. In retrospect, some of the students doing the new curriculum weren’t quite ready for it, and probably should have done the intro curriculum again.

The plan now is to add more resources to this new curriculum and some concepts review for the teachers to teach before people dive into their apps. One comment I heard a few times was that people had spent too much time with Bootstrap and just wanted to get to rails, so I’m planning on making an optional cheat sheet with step-by-step instructions for anyone that wants a styled app but quickly. Another suggestion was grouping people by topics for the intermediate curriculum — perhaps the “let’s really get into databases” group, and the “make it really pretty” group, and the “dive into devise” group.

As many things as I want to improve, I’m really happy about how the workshop turned out. The general feedback I’ve heard is that the new curriculum really helps cement concepts for people who mostly get rails, but haven’t yet gotten a chance to apply what they learned from the intro curriculum. And I got to learn a ton, too! Now I just need to get someone to write my dream regex curriculum with me…

Making a New Rails Curriculum

Looking ahead to 2013

We’re organizing a next round of RailsBridge workshops, for January, February and March of 2013! You can make more workshops happen!

1. If you have space to host a workshop, and they’re able to host in in the first part of the year, let us know!

Send us intros to the best person to talk for planning an event there, which may be a recruiter, an event coordinator or a facilities manager. Workshops are much smoother if we’re talking to the right person at the venue.

2. If you want to organize a workshop, either for the first time or the third time, let us know!

Workshops work best when both organizers are responsive to email and able to meet in real life before the workshop at least once. If you know times when you won’t be available, let us know up front and we’ll schedule the workshop around that. And if you have a coorganizer in mind, tell us that too!

3. If you’ve organized several workshops and are ready for the next challenge, tell us you’re ready to start mentoring organizers.

It’s especially useful for first time organizers to have a dedicated question-answer-er who is encouraging and very responsive to email. It’s also wonderful when mentors can be an extra pair of hands at the workshop itself, so if there are any dates you’re not available, let us know up front.

Look forward to hearing from all of you and seeing all the great work you’ll do in 2013!

– Rachel Myers & Lillie Chilen, SF Meta-Organizers

Looking ahead to 2013

From BugMash to Core Contributor: an Interview with Santiago Pastorino

by Jen Lindner

Santiago Pastorino (@spastorino) is a core contributor to Ruby on Rails. (Read in spanish)

Can you tell us a little about your background, and how well you knew Rails when you first participated in a BugMash?
My name is Santiago Pastorino and I am from Montevideo, Uruguay. I received my degree in Computer Engineering in Uruguay. It’s a 5 year program that’s very similar to a BS in Computer Science in the US.
I worked with Java with a local company for two years while I finished up my degree. After completing the degree my partner José and I decided to start WyeWorks. It was at this time that we started to get much more interested in dynamic languages and their frameworks, like Ruby on Rails and Python/Django.

We considered which language and framework to use for our first consulting job and since we preferred Ruby and José had previously worked with Ruby, we decided it would be best to start with Ruby on Rails.

We never regretted the decision. 🙂

This was midway through 2008, and it was at the start of 2010 that I participated in the BugMash. I had little experience and in that year and a half I didn’t program very much because we had to take care of the business as well.

So my experience was very limited.

What drew you to it? Had you ever built or worked on a framework before?

I never built or contributed to any frameworks before contributing to Ruby on Rails. But with Ruby on Rails we had various reasons to do so. Since it was the framework we worked with every day, it had to shine. Our business is to sell high quality consulting and development by the hour. Contributing is the best way to position ourselves as experts with the tool.

Do you remember any of the bugs you fixed that day? How challenging did they seem to you as a newcomer?

At the time, Ruby 1.9 was on the rise. Ruby 1.9.1 had already been released and Rails was starting to support it. There were a few failing tests with Ruby 1.9 and I believe I fixed three, some partly shared with others who were also participating. It was very challenging at the time because I didn’t have the necessary understanding to do many things.

Where did you find help?

Many people from BugMash helped me during the event, among others, the organizers like Sam Elliott. After the BugMash, the other members of the core team, most importantly Yehuda Katz, José Valim, and Jeremy Kemper helped me very much to contribute.

What did you find most satisfying about the experience? And why did you continue working on tickets afterwards?

I especially always liked to understand in depth how things work. To contribute to a tool you have to understand how it works. It seems to me the best way: research and naturally you later find ways to make improvements.

I kept building on what I said earlier: at WyeWorks we are committed to development on the framework. It’s part of our business, it’s a way to support the work that so many people have done, and it’s truly our passion.

Do you think you’ve learned more about the philosophy behind Rails by running its tests and fixing issues than you have by just using it?

More than running and fixing tests, generally both using the framework as much as contributing to it add up to knowledge and add up to better understanding the philosophy behind Rails. The perspectives that you get as user and as collaborator with the framework are different.

Is there any advice you’d like to give to people who might want to participate an in open source project?

My recommendation is simple. One has to dedicate time to try to understand why things work. Everyone who has contributed has dedicated a lot of time. No one is born with the knowledge.

Besides, by luck, the people who contribute to Rails are very friendly, something that lamentably doesn’t happen on other projects. This is very good because as you start to contribute there are many people willing to talk to you and help.

From BugMash to Core Contributor: an Interview with Santiago Pastorino

De BugMash a Core Contributor: Entrevista a Santiago Pastorino

por Jen Lindner

De BugMash a Core Contributor: Entrevista a Santiago Pastorino  (@spastorino)  (Lee en inglés)

Q. Cuentanos un poco de tu formación, que tanto sabias de Rails cuando primero participaste en un BugMash?
A. Mi nombre es Santiago Pastorino y soy de Montevideo, Uruguay. Estudié en Uruguay y me recibí de Ingeniero en Computación. Es una carrera de 5 años que es bastante similar al BS in Computer Science de Estados Unidos. Trabaje con Java en una empresa local durante 2 años mientras estaba terminando la carrera. Luego de terminar la carrera decidimos con mi socio José arrancar WyeWorks. En ese momento nos empezamos a interesar bastante más por los lenguajes dinámicos y los frameworks estilo Ruby on Rails y Django. Estuvimos discutiendo con qué lenguaje y con qué framework hacer nuestro primer trabajo de consultoría y debido a que nos gustaba más Ruby que Python y que José ya había trabajado con Ruby anteriormente, nos decidimos que lo mejor era empezar con Ruby on Rails. Nunca nos arrepentimos de la decisión :). Eso fue a mediados del 2008, y fue a principios del 2010 que participé en el BugMash. Mi experiencia era muy poca y en ese año y medio no había programado demasiado porque teníamos que dedicarnos bastante a la empresa también. Así que mi experiencia era bastante limitada.

Q. Que te atrajo? Habías anteriormente construido o contribuido a otro framework?
A. No construí ni contribuí a otros frameworks antes de contribuir a Ruby on Rails. Pero con Ruby on Rails tenemos varias razones para hacerlo. Es el framework con el que trabajamos todos los días, tiene que brillar. Nuestro negocio es vender horas de consultoría y desarrollo de alta calidad. Contribuir es la mejor manera de posicionarnos como expertos en la herramienta.

Q. Te acuerdas de algunos de los bugs que arreglaste ese día? Que tan desafiante te parecieron como principiante?
A. En ese momento Ruby 1.9 estaba surgiendo, Ruby 1.9.1 ya había sido liberado y Rails estaba empezando a soportarlo. Habían varios tests fallando con Ruby 1.9 creo que arreglé 3 algunos medio compartidos con otras personas que estaban participando. Fue bastante desafiante en ese momento porque no tenía el conocimiento necesario para hacer muchísimas cosas.

Q. Donde encontraste ayuda?
A. Muchas personas del BugMash me ayudaron durante ese evento, entre otros los organizadores como Sam Elliott. Luego del BugMash los otros miembros del core team fundamentalmente Yehuda Katz, José Valim, y Jeremy Kemper me ayudaron mucho a contribuir. A mi particularmente siempre me gustó entender a fondo como funcionan las cosas. Para contribuir a una herramienta tenés que entender como funciona. Me parece que es la mejor manera, investigás y luego naturalmente encontrás mejoras. Yo continué trabajando luego por lo que decía anteriormente, en WyeWorks estamos comprometidos con el desarrollo del framework. Es parte de nuestro negocio, es una forma de apoyar el trabajo que tanta gente ha hecho y ademas porque realmente nos apasiona :).

Q. Crees que haz aprendido más sobre la filosofía detrás de Rails corriendo las pruebas y arreglándolas que solo usándolo?
A. Más que por correr los tests y arreglarlos en general tanto usar el framework como contribuir suman al conocimiento y suman a entender mejor la filosofía detrás de Rails. La perspectiva que tenés como usuario y como colaborador del framework son diferentes.

Q. Tienes algún concejo que quisieras darle a quienes quieran contribuir a un proyecto de open source?
A. Mi recomendación es sencilla, hay que dedicarle tiempo e intentar entender como funcionan las cosas. Todas las personas que colaboran han dedicado muchísimo tiempo y nadie nace sabiendo. Por suerte ademas las personas que contribuyen a Rails son muy amistosas cosa que lamentablemente no pasa en todos los proyectos. Eso está muy bueno porque empezás a contribuir y hay mucha gente dispuesta a discutir contigo y a ayudarte.

De BugMash a Core Contributor: Entrevista a Santiago Pastorino

Five RailsBridge Workshops for November 2012!

by Mary F. Jenn

We’re kicking off November here in San Francisco with a workshop starting this evening, November 2 at Github, followed by an Intermediate Level workshop on November 16 and 17.

RailsBridge Boston is holding their second workshop in 3 months on November 9! It looks like this event is full, but look forward to more workshops in this vibrant and enthusiastic community. As always, if you’re in the Boston area and would like to volunteer or sponsor, your support is welcome. Congratulations Boston!

The Denver/Boulder Rails community is holding their second workshop Since October! Go Denver! Register as an attendee or volunteer here!

Up in Canada, a fledgling RailsBridge community is launching their first workshop the weekend of November 30! If you’re interested in volunteering or attending, please sign up here. Go Victoria, BC!

Are you in Atlanta the weekend of November 16 & 17? Be sure to check out #BlackGirlsHack! They’re holding their first hackathon as a fundraiser for BlackGirlsCode that weekend and are seeking more signups! Sign up here>> ! Could you sponsor? Please support these groups that teach girls of all colors how to program!

For more event details, please check the calendar.

Five RailsBridge Workshops for November 2012!