Jaime Iniesta

RbMU, a better way to learn Ruby

"The students on this list have all shown they can ship clean code under tight deadlines while maintaining a balance between learning new things and getting things done."

When I read this at the Ruby Mendicant University alumni list, I knew that the core skills course that the RbMU was offering was something to try. Something different and focused on the reality of learning to code and working for the industry.

"Shipping clean code, under tight deadlines, learning new things and getting things done". That's the way!

Despite having a good amount of experience on Ruby coding, I knew a course like this would be worthwhile to strengthen my Ruby roots. Also, being a Ruby/Rails/Agile teacher myself, I was interested in knowing other ways of teaching development skills.

The Core Skills Course

The main course that is being offered right now at the RbMU is called the "core skills course", an intense three week course that takes you through several important topic areas every Ruby developer should be comfortable on. During these 3 weeks, you get to work on 4 assignments and a personal project, that are finally released as open source at the end of the course. You also work with your fellow students to review their code, so on an average course you may end up working on your 5 projects and reading code for some other 20 or 30 projects.

The entrance exam

The core skills course is aimed at intermediate Ruby coders, and the seats are limited, so to be accepted you have to pass an entrance exam. When I joined the RbMU, the entrance exam consisted on developing a Ruby script to parse a CSV with the availabilities of students in order to find the optimal starting time for weekly meetings:

Now, new students apply for RbMU admission through http://puzzlenode.com, an in-house app that lets you choose between a set of problems and submit your solution.

No lessons, straight to practice

After passing the entrance exam, I signed up for a session and waited a pair of months or so to start. I chose the last session available at the time, in order to have some time to finish my client projects and reserve a big part of my agenda exclusively for the course.

When it finally came the time and we started, I was suprised to see there were no formal lessons at all. I had expected the typical course layout where you attend some classes and then you have some homework to do, but instead of that, we were given coding assignments. No lessons at all, just start coding, and then we'll have something real to talk about! 

This makes such a big difference. It's OK to read a Ruby book to get the basics, but to really learn things, you have to need to solve a problem. So, we were given our assignments, we had some real programming problems to solve, and we had to do our best at solving them, with the cleanest code possible and learning just the things we really needed to learn.

Time pressure is your friend

The next thing that surprised me was that we were given strict checkpoints. In total, we had 3 weeks to finish the course, but you had to pass through partial deliveries in the form of 4 checkpoints. If you didn't get the work that needed to be done at every checkpoint, it meant that you were expulsed from the course. That pressure component really worked for me. It makes you focus on what's really important to be done and ignore the rest.

It looks, though, that for some of the other students it didn't work so well. Out of 8 students that started the March session, only 2 of us could make it to the final checkpoint. I guess they underestimated the effort it would take to finish the course. It was really a lot of work: in my case I dedicated 24 hours per week, although this may vary for each student. It looks like on average, it takes around 20 hours per week.

What did the assignments look like?

Every core skills course session is different and each one has different assignments. In general, each session features an exercise on each of the following topics:
  • Modeling complex business logic
  • Integration with third party software libraries and/or web services
  • Practical application of high level software design principles
  • Contribution to community projects
What's nice is that you're given an assignment in the form of a general problem, but it's up to each student to propose what exactly they want to work on. It's not the teacher who puts homework on you, it's you who propose what you would like to build. This is a real motivation booster and makes you really engaged.

In my case, these 4 assignments were:
  • Background job processing. We were asked to build a demo app that made use of background jobs. As I already had experience with DelayedJob, I chose to work with Resque, and I built a simple Rails app that integrates with Last.fm and Flickr, so you enter the name of a music band and it fetches its albums, similar bands, and photos from Flickr, using a Resque background queue. https://github.com/jaimeiniesta/s6-e1
  • Experimenting with Ripper. Ruby has a standard library called Ripper, which aims at converting Ruby syntax into s-expressions. This library is quite obscure and has not yet been very explored, so we were asked to conduct some experiment with it. What I did was a Ruby file comparator, an script that, given two Ruby files, would convert them to their simplified structure and tell if they are the same. https://github.com/jaimeiniesta/s6-e3
  • Community Service Project. Although the web and apps of the RbMU is mainly built by Jordan Byron and Gregory Brown, it also receives a lot of contributions by its students (and anyone who wants to help, as it's open source). My humble contribution was the the alumni list filtering by year, course, and recent alumni. http://university.rubymendicant.com/alumni/recent.html
  • Challenge Project: Tower Defense Game. Greg gave us a prototype of a tower defense game, a basic but working demo where you have a board with different kinds of tiles, and pieces for towers, monsters, etc. Our goal was to study the codes and make something more solid, make it grow and add new features. New kinds of towers, monsters, maybe a nice interface. Again, we were the ones proposing what to do. The trick here, was that the code was not documented and we had to study all this code before thinking about what could be improved. We all left this one for the end as it looked so complicated, but on the last days I had a nice meeting over IRC with Ginny Hendry and we did a dissection of the code, following it and understanding how it all was working. It was a good experience. https://github.com/rmu/s6-e2
My personal project

Apart from these 4 assignments we had to work on, and the code reviews we were expected to do, we also worked on an individual project. Mine was w3clove, a site-wide markup validation tool. Give it a website and it will validate the markup of its pages on the W3C markup validator, and return you a report with the most common errors and warnings. https://rubygems.org/gems/w3clove

Alumnus, at last!

Finally, after these 3 intense weeks and after a lot of fun hours learning good Ruby practices, you're given the alumnus status and you enter the alumni network. The core skills course has ended but that's only the beginning...

Rbmu0

What's next?

Being part of the alumni network is great, but that's not the goal, it's just the beginning. You're welcome into a great community of Ruby developers that is very active building new things and learning. As I write these lines I'm attending a Software Ethics seminar, and preparing myself to be a mentor. There are also courses on other topics, book readings...

Reflections

The current education system is at a crisis and we need to re-think the way we're learning. I recommend watching the talk by Sir Ken Robinson about how school kills creativity and how we need to change our education paradigms. While these talks are oriented at the way kids are being taught, I think the same applies for standard courses and certification programs, at the university and the enterprise.

There's a better way to learn, and it's neither linear nor based on pre-packaged instructional materials for isolated individuals. As Sir Ken Robinson points out, "great learning happens in groups, and collaboration is the stuff of growth".

I'm glad that Gregory Brown started this Ruby Mendicant University, and excited to see where we as a community can take it.

There's a lot of things we can learn and build together.

 

Filed under: RbMU courses ruby

How to generate a static version of a website using nanoc and nokogiri

1004238538_1d6b6fdc5d_m

More than a year has passed since we organized EuRuKo 2009 on Barcelona, so we thought that it had come the time to shut down the Ruby on Rails web applications we used for its website (a custom registration app and a simplelog).

We wanted to maintain an archive for them, but it had to be so simple that it required zero maintenance. So we thought, hey, let's just make a static HTML version of the whole site.

Static, but not too static

After considering several techniques like activating full page caching on the rails applications and grab the generated files, or use wget on recursive mode to spider the site, none of these solutions satisfied me. Both of these solutions would do more or less what we wanted, but we would end up with hundreds of static html files that would be a nightmare to postprocess and adapt for the final static version.

So after thinking about it for a while, I reached out for my ruby toolbox, took a few of them and built a custom quick-and-dirty script standing on the shoulders of giants like nanoc and nokogiri.

What is nanoc?

"nanoc is a tool that runs on your local computer and compiles documents written in formats such as Markdown, Textile, Haml… into a static web site consisting of simple HTML files, ready for uploading to any web server".

Yeah, that's what it is. You have a folder with the content of each section, and a folder with the layouts you want to apply, using erb, just like you would do on a Ruby on Rails site. nanoc runs through all the content files and applies the layout to them, generating an output folder with all your HTML ready to upload to the server.

You're also able to define custom rules and use helpers and filters for processing the content, it's a really simple and awesome tool, perfect for this task.

So, I chose nanoc. Adapting the layout from our rails apps was a piece of cake. I had almost the same layout with its <%= yield %> line into place, and I also copied the assets (css, javascript and images). Now I just needed to define the contents of each section. But we had hundreds of them!

We need a spider robot here

Going manually through all of the sections on the original site and copypasting its contents was certainly not one of my options. I'd rather sit on a slowly rotating swordfish. 

This was a job for one of those efficient and cold-blooded spider robots. That's the plan: have a spider robot visit all the sections of the original site, and get its title and the contents of the DIV with id="content". Then tell nanoc to create an item for it. Put the grabbed content on the nanoc item, along with its title attribute. Then, once done for all the site, we would just run "nanoc compile" and the whole static site would be generated. Easy, isn't it?

Sitemaps for lazy spiders

Poor little spider robot looked at me and said "hey, it's summer here, I'm lazy, I could certainly find my way through your website but... know what? We spider robots are quite tired of doing all this over and over again! I'd too rather sit on a slowly rotating swordfish than spidering all of your links and then finding that some of them had to be excluded. Why don't you give me a little sitemap and I'll know exactly what you want me to visit?"

So I said "hey, excuse me, you're right, I wouldn't want to waste your precious robot time, let's build this sitemap you want". And I emailed Fernando Guillén, who had built the original app, and I said to him, "hey, can you build a sitemap of the site for this little grumpy spider?". And in a couple of minutes he had it ready.

Enter nokogiri

So, if you're still reading this, at this point of the story the plan is visiting a sitemap XML file with all the URLs we want to grab, and for each one of them, visit it and scrape its title and the contents of a given DIV. What could we use for this? Right! Nokogiri!

"Nokogiri (鋸) is an HTML, XML, SAX, and Reader parser. Among Nokogiri’s many features is the ability to search documents via XPath or CSS3 selectors."

Nokogiri can process XML files, as well as HTML files. It can also process a file on a server, or a local file. Perfect for the job.

The script

So I wrote this quick-and-dirty script. ("hey, stop calling me quick and dirty!" -- said the spider. But that's what it is, a quick, dirty and hairy spider robot.)

To create a new spider you need to pass it these three parameters:
  • sitemap, which can be a local XML file or a remote XML file on a server
  • root_url, which is a string indicating the original root URL 
  • extract_id, which is a string telling the id of the DOM element from where the contents should be grabbed
Then you just call its create_nanoc_items method, and the spider will go berserker, process the XML and create all the sections inside your nanoc site.

Helpers and filters

nanoc lets you use helpers, just like you're used to in a Rails application. I used two from nanoc's helpers, one to let me include partials, other to be able to use link_to, and defined a pair of them myself.

You can also use filters to process your content. I defined a custom filter to clean the grabbed HTML a bit, hiding an annoying div and rewriting some links.

Rack attack!

So I finally run the spider, it fetched the site and prepared all those nanoc items for me. Thanks! Then I just run "nanoc compile" to generate the final site, and the generated static site was there waiting peacefully on its output folder. Time to upload it to the new server!

While it would be too easy to just upload it to a normal web server, we thought it would be hackier to put it on Heroku. We love it and it's as simple as it can get. Yes, you can have static sites on Heroku too, as long as you define some basic rack configuration for its Thin web server.

I then remembered that Raúl Murciano had given a great talk (with a pair of videos available) about Rack on Conferencia Rails 2009, so I emailed him for help, and he soon came out with this config.ru file. I throwed it in, along with the gem manifesto file that Heroku asks, pushed it to the server and... boom! there it was, alive and kicking, but completely static, the new EuRuKo 2009 archive.

Interviewed on Spanish Rails podcast

Ruby on Rails has a large community of developers in Spain, which is growing day by day thanks in part to initiatives like Rails Hispano, a new Spanish podcast about Ruby on Rails.

I was invited to participate on the latest episode, where I talked about my experience as a Ruby on Rails freelance. It was a pleasure to share the mic with Fernando Guillén, Raúl Murciano and Marcelino Llano.

I'd like to see more people encouraged to try the freelance way in Spain, come on people, give yourself a chance!

Having fun with 37signals Draft

Draft, the first 37signals app for the iPad lets you draw quick sketches and wireframes, using only your fingers. It's great, you only have two inks, white and red, and an eraser. Why more?

You can also send your drawings to Campfire or by email. This is a great tool to quickly express your ideas, and I find that it's also very relaxing, just sit on the sofa and draw like a kid!

There goes my first piece of art. This is the Guy With The Curved Scrollbar Hat:

Sketch_2010-06-25_at_08

And, here's my second masterpiece, the Bloody Mosquito:

Sketch_2010-06-25_at_08
Even my 5 months old son has been able to make a great piece of abstract work. :P

Sketch_2010-06-25_at_10

If you're not on an iPad you can try a clone of this app that runs on a browser. It's really great, offers you 4 inks (although maybe with 2 is enough), but lacks an eraser (which could be easily implemented with a black ink as does 37signals).

But of course, drawing with your fingers is so much better than with a mouse. Go try Draft on an iPad!

Filed under: Wireframes fun ipad

hashtag_retweet_bot

hashtag_retweet_bot is a ruby bot that retweets all twits tagged by a certain hashtag. It's ideal for conferences, meetup groups, communities, etc.

As an example, let's say you want to retweet every twit found with the hashtag #icecream every 5 minutes (300 seconds). This ruby gem will let you do it as easily as running:

hashtag_retweet_bot icecream 300

This bot was born as a little script for the Scotland On Rails 2008 conference. We saw it in action there and as it was nice and useful, so we forked it to adapt it to our needs at the EuRuKo 2009 conference.

This year, Tomasz Stachewicz from the EuRuKo 2010 has adapted and modernized it so that it works with Bundler, OAuth, native RT and some other improvements.

We can expect the EuRuKo 2011 will go ahead and improve it for the next year :)
Filed under: euruko gems ruby twitter

The Agile Samurai

The-agile-samurai-cover
I've just finished reading The Agile Samurai (better said, the first 17 chapters that have been written as this book is still on beta), and I would like to share it with you as I think it's a nice book to read.

To be honest, I expected a bit more from a book with such a strong title, but I see that this book was intented for people who want to get a general idea of what the Agile developing world is like.

So, if you're already into Agile lands, you'll surely find it a fun book to read but it won't teach you anything you didn't already know; if you're new into Agile, it will show you a whole new land. You should definitely read it in this case.

This book covers topics like project inception, planning, creating agile teams, comunication, story cards, burn-down charts, test-driven development, and more.

Filed under: agile books
11
To Posterous, Love Metalab