Head First Ruby

[Nerio Cintron]

Thefirst project of _why's that I recall using was Camping ?

This is the first micro web framework which I know of existing.

It was a brilliant combination of Markaby (HTML markup in Ruby, also _why)

and ActiveRecord and a micro MVC pattern.

The Poignant Guide is indeed insane. It's somehow pretty similar to the "Head First..." series. Even though I like their idea it turned out that I don't like them. To my own surprise the visualisations were of no help for me, instead they were a distraction. I am a visual learner, but it seems like I need to make my own visualisations and cannot learn with these gimmicky comics.

I'm pretty sure this is not true for all other languages. Whether you agree or not - this book teaches the OO architecture of ruby in depth, which helped me a lot for designing the class hierarchy of my own applications.

All three books listed here were excellent. Having followed Sandy Matz's talks and podcasts for a while, her Practical Object Oriented Design in Ruby was close to heart. It helped instill some good OOP practices which helped beyond ruby as well. Metaprogramming Ruby was also an interesting book. It taught walking on hands (which was how metaprogramming seemed to me) in a lucid and fun way...

Learn to Program by Chris Pine is an excellent Ruby book. When I was going through Flatiron School, I didn't feel like I understood Ruby concepts very well even after finishing the Ruby lessons, and that book cleared up a lot of things for me.

How about a new one using the latest version of Ruby designed specifically for beginners and yet teaches you to be a solid object oriented programmer? packtpub.com/programming/the-ruby-...

Full Disclosure: I'm the author :)

During the height of the ALT.NET movement, I became determined to learn another language/stack outside of the current Microsoft .NET environment. At the time there was a lot of buzz around Ruby and the open, friendly and inviting culture surrounding it. I dove in head first and started reading the required texts of the stack; Why's (Poigant) Guide to Ruby, The Ruby Programming Language, The Ruby Way.

I was unsuccessful in transitioning to another language/stack full time. But I learned a ton of new concepts that I had never been exposed to in my career up to that point. Since then I have dived into node.js and Objective-C; both great fulfilling experiences as well. I firmly believe that exploring different languages and stacks is a great way to change the way you think about solving problems.

One of the great experiences I had while exploring the ruby way, was when I discovered the Ruby Koans. The koans took the playfulness of Why's guide and the details found in TRPL book and combined them into a simple learning tool that anyone could clone, run and start learning the basics of the language by putting their hands on a keyboard (the most effective way for me to learn).

I was so enamored with the Ruby Koans, that I started doing presentations with them at local Meetups and Code Camps. I would talk briefly about Ruby, explain how to install it with the koans and then invite every member of the audience up one at a time to put their hands on my keyboard and solve a step on the path.

It was great fun. The reactions from the participants was inspiring. I had people from every walk of "programming" life get their first experience with ruby at those sessions. Everybody left a ruby programmer. The most memorable case being my friend Chris Bilson's 8 year old daughter. From what I understand she still talks about that crazy guy who encouraged her to learn ruby.

Later on I discovered most of what I was teaching was based on the work of Jim Weirich, a truly inspirational figure in the community. I was lucky enough to meet him at the Software Craftsmanship conference in Chicago in 2011. He presented on the Roman Numerals Kata. Later that night he, a group of other nerds and I sat around a board game for hours and talked shop, nerdiness and other pursuits. I seriously encourage you to watch that presentation video to get a feel for the kind of guy Jim could be.

I told Jim about my koan sessions. He listened intently, said it was a great idea, that he was proud of me and that I should continue. I felt like I had won a medal that day. Those kinds of interactions really feed my fire and they are to far in between.

Sadly, Jim passed away in 2014. That loss was a huge hit to the community at large. Rest in peace, Jim. You are greatly missed. But I think the best way to honor Jim is to continue his effort to bring a love of the craft to anyone willing to learn.

So, recently I started working on an implementation of koans for C# that are appropriate for the newly released .NET Core. My goal was to create something that was just as playful and useful as the original inspiration that can be used in any setting to help a beginner get their hands on a keyboard quickly and start learning. That first interaction with a platform is crucial and should be encouraging and entertaining.

There are also many topics yet to be covered by this set of koans and that is where you come in. I have added a handful of needed topics as issues and tagged them as Up for Grabs. There are even some specifically tagged as Beginner Friendly.

If you have never contributed to an open source project, let this be your first. Take a stab at updating the AboutStrings Koan to include information about interpolation then submit it as a pull request. I promise to work with you to get your contribution into the repository and be friendly and encouraging about it. It is what Jim would have done.

If you think a topic is missing, propose it's inclusion by submitting an issue yourself. Or better yet submit the issue and an accompanying pull request with how you think the topic should be introduced. Think about beginners in your effort; be clear and informative, be concise and most of all be playful with your examples.

I loved Merb, and was excited to share it with anyone who'd listen, so when I attended RailsConf in 2008, I signed up to give a nighttime Birds of a Feather session about Merb. To be honest, I expected only a handful of people to show up, but I was too excited to let that stop me.

When the time for the session arrived, I nervously waited in the small room that the conference assigned us. Other members of the Merb community were there, and I nervously joked that maybe nobody would show up and we would just have a meeting of the core team.

That didn't last long. Minutes later, a handful of people wandered in. I haltingly tried to make some small talk as we waited, and soon realized that the people who had shown up were psyched about Merb. I was relieved. Small talk is not my strong suit, and the group's enthusiasm for Merb gave me an excuse to get lost in an animated conversation about Merb.

I looked up from my conversation after a few minutes, and noticed that the room was filling up. A few dozen people were packed into the room. I was happy that people cared. But then I noticed that people were peeking in through the door, and I walked over to the door to greet them.

I saw a line of dozens and dozens of people snaking through the hallway, trying to get in. My heart was pounding. Thinking quickly, I led the group to a larger room that had been used earlier that day for normal RailsConf sessions.

I fretted about being unprepared. About looking stupid in front of people who had invested time and energy into the project. But when I left the room that night, and finished high-fiving Merb contributors and fans who poured their hopes into this thing, I knew that our little project was resonating.

I had originally started working on Merb after a bad experience with Rails. Ruby on Rails is the reason that I became a successful programmer in the first place, but a few years later, I was running head first into limitations. Limitations that seemed pointless and unnecessary. Like the time I naively tried to use layouts and helpers in my emails, but learned that ActionMailer was a fork of a very early implementation of Rails controllers, and didn't support layouts or helpers.

I became the maintainer of Merb because I wanted to fix all that. At the time, I was still extremely grateful to Rails for bringing me in to programming. I knew that convention over configuration was a critical part of what allowed me to grow from a print designer into a web application developer. I will be eternally grateful to Rails for making me realize that I could be a programmer. But it felt like it was all starting to fall apart.

Back then, I didn't know what it would mean to use Ruby to build web applications without Ruby on Rails. But Ezra Zygmuntowicz, a co-founder of Engine Yard, did. He had a different bee in his bonnet: he wanted a Ruby web framework that was much faster than Ruby on Rails, which had a (deserved) reputation for being quite poky. Ezra had put together Merb, named after Mongrel + ERB, the components in the original Merb stack.

Even though I was interested in building a more modular web framework and Ezra was interested in building a faster web framework, Ezra invited my help enthusiastically. I remember walking into the Engine Yard offices on South Park, worried that I didn't have the first clue about how to build a web framework. I worried that I wasn't ready to help lead Merb's development. I worried that I was an imposter. I worried incessantly.

But a few minutes after walking into the Engine Yard offices on my first day, I was neck deep into brainstorming with Ezra. He never wasted a second thought on the question of whether I was ready. Getting right down to business with Ezra made me forget my self-doubts, at least for a moment.

I remember the next few weeks as if it was an 80s montage scene, full of whiteboards, printouts, and wild gesticulations. At the end of that, we had a plan for a web framework written in Ruby that would be fast, as Ezra wanted, and more extensible, like I wanted.

3a8082e126