Ottawa Ruby

Group Project Survey Results

Tue, 14 Feb 2012 20:12:22 -0500

A big thanks to everyone who submitted their vote for the group project! We had 15 responses for this survey. Here’s how the votes were spread out:

And the winner is… Whenbot! :) There’s something for everyone in this app, so this will be a fun project to work on.

For the curious, the results from the rest of the survey are below.

Feature Suggestions

Here are three of the (applicable) feature suggestions:

Make the app bilingual (or even plurilingual) to work on I18n.
Look at the OmniAuth gem: this gem handles standarizing the authentication in a similar way to how this app will need to standardize data exchange between services.
Make the Whenbot behavior mobile-friendly.
Consider using Bootstrap 2.0, unless someone wants to tackle the design.

Which approach should we use?

This is an interesting one. Let’s take a look…

It seems that most people do want to create an app of our best practices, so we’ll go ahead with that as the main model. At the same time though, we shouldn’t discourage those who don’t necessarily want to focus on their technique.

It would be good if we could accommodate both sides, without opening up the door to sloppy code. ;) Any thoughts on how to go about this?

In which area(s) do you most want to improve?

The chart pretty much speaks for itself here. One thing that stands out above the rest is that people want to learn more about Testing / Test Driven Development. We’ll try and follow TDD practices while developing the app.

When would you want to work on this?

It’s great to see that people are interested in working on this during their spare time, as well as during some additional code sessions. We’ve got quite a few keeners here! :)

And finally, the touchy-feely question…

At the end of this project, how do you hope you’ll have grown?

(If that’s too small to read, see the full-sized image here.)

Wrap up

Cool, now that we have a project picked out, we just have to figure out how to build it.

Next up:

Planning the app
Creating the base project
Building out the different parts of the app (triggers, parsers and publishers)

If you’re interested in helping out with any of this early-stage stuff (and you haven’t already mentioned that in the survey), please get in touch.

Stay tuned!

Three code-style tips for the budding Ruby Developer

Wed, 08 Feb 2012 18:11:21 -0500

During the last meetup, we had an interesting talk where some of the advanced developers passed on a bunch of great development advice to the beginners. In this post, I wanted to add in one more group of tips for the newer developers.

Other than Kent Beck’s advice to “communicate your intent through your code,” if I had to list only three pieces of advice that would help a newer Ruby Developer write code more like a Rubyist (rather than a Java / C++ / C# developer), I’d suggest the following:

(Note: Please feel free to post a comment if you have any advice to add, or if you disagree with any of this.)

Try to keep your methods short. Following the Single Responsibility Principle helps here. 
Use descriptive variable, method, and parameter names (this goes back to “communicating your intent”).

So, favour method names like calculate_taxes over do_calcs, and variable names like subtotal over value or x. 
You can create self-documenting code by replacing complex logic/statements with a well-named method call.  

So, instead of: 

stripped_html = data.gsub(/<\/?[^>]*>/, ”)

You can use:

stripped_html = remove_html_tags(data)

It may not be the best example, but here’s the point: even though you’re assigning to a pretty descriptive variable name (stripped_html), replacing the regex with a descriptive method name makes the line read almost like a comment. This helps you resist the urge to comment the regex.  :)

Also, as a bonus, even if you didn’t give your variable a descriptive name, the descriptive method call still makes the line quite clear: 

data = remove_html_tags(data)

See? The data variable doesn’t mean much here since it’s out of context, but the method call still gives you a pretty good idea of what’s going on, and even what sort of data is in the variable.  

Of course, you’re still communicating your intent with a well-named variable and the regex, but the second and third ways are more clear, in my humble opinion at least.   

But don’t go crazy with this one, you don’t have to replace every somewhat complex operation with a method call. Use your judgement.

Anyway, those are just some thoughts, I hope they help someone. I believe I got most or all of this from reading Russ Olsen’s Eloquent Ruby. Highly recommended.

Have any other tips or advice? Feel free to post it in the comments. It would be great to collect a bunch of this stuff and turn it into a blog post.

Summary of Ruby Tuesday's meetup (January 24th, 2012)

Wed, 01 Feb 2012 09:02:05 -0500

Hi all,

Thanks for coming out last Tuesday everyone! We have a great Ruby community here in Ottawa. It’s awesome to see everyone’s enthusiasm for Ruby and Rails.

Here’s a recap of what happened on Tuesday for those who missed it, or for anyone who would like a review.

If you’d prefer to look through the slides, they’re up at: http://www.slideshare.net/michaeldwp/ruby-tuesday-ottawa-jan-24-2012.

Announcements

Peter Cooper (Ruby Inside, Ruby Weekly, author, blogger, and more) will be giving us a (live, remote) talk during the February meetup. See http://peterc.org for more information on Peter. 
Jeff Casimir (Jumpstart Lab founder, world traveling teacher of Ruby, Rails and Javascript) is booked to give us a (live, remote) talk in March. 
Rails 3.2 is out!

Release post: http://weblog.rubyonrails.org/2012/1/20/rails-3-2-0-faster-dev-mode-routing-explain-queries-tagged-logger-store 
Upgrade instructions: http://guides.rubyonrails.org/3_2_release_notes.html

Introductions

We went around the group and everyone introduced themselves. It was interesting to see such a wide range of backgrounds an expertise in the room.

The Video

We didn’t have a live speaker booked this month, so we watched “Fat Models Aren’t Enough,” by Jeff Casimir. It was a good talk. :)

Here are the links for the talk:

The video is here
The slides can be found here

Food, Mingling, Schmoozing and Networking…

We took a break part-way through the video to mingle and eat some pizza. It was great to see everyone getting to know one another during the break!

Video Discussion

After finishing up part II, we had an interesting talk about a few of the topics from the video. We then opened up the floor for people to give a few of their favourite pieces of advice for the newer developers.

There were a number of good tips in there, and it was great to hear the advice from everyone. If anyone remembers what they said, or has any additional advice, please post it in the comments as this is wisdom that should be passed on to future Rubyists.

…And what better way to do that than to save it on the Internets! :)

Ruby Katas

We had some Katas for those who didn’t want to discuss the group project (see below), but most people didn’t get to try them since I made the mistake of saying that laptops were optional, heh. Sorry again about that, it was sort of an impromptu thing. :\

For anyone who would like to give the Kata’s a go, here are the links:

Yellow Belt Kata (for Ruby beginners): https://github.com/gigasquid/yellow_belt_ruby_katas 
Gilded Rose Kata (refactoring Kata): https://github.com/jimweirich/gilded_rose_kata

The slides briefly mention how to clone the source, but you could just download the zip file from the Github page.

You should also read the main page of the Yellow Belt Kata for instructions on how to get going. As mentioned, you should go through these in Test Driven Development-style. To do so, after you’ve cloned/unzipped the source: 

Run “bundle install” to install the required gems (specifically, rspec)
Run “rake spec” to start on your TDD journey. Fix the bugs one by one.

Note: When you pick a spec to work on, you’ll have to remove the line that says

before { pending }

to get the tests to actually run. Then, re-run the specs and fix the bugs, starting from the top and working your way down.

The Group Project

If you haven’t heard, we’re looking at doing a group project to help improve everyone’s Ruby / Rails skillz. :)

We went over the existing project suggestions (also listed in the slides), and got some feedback on each idea. It was great that all of the submitters were around to present their ideas, by the way, thanks again fellas! :)

We’ll have an anonymous survey for everyone to vote on which project we should work on. Stay tuned to the Google Group.

Following this, we talked about how it may be good to try and make this as an “app of our best practices,” so that we all learn from each other a little better.

(The alternative here would be for everyone to just create their part(s) of the app and try to learn what they could from their portion [e.g. the specific API they’re dealing with]. But, with everybody focused on producing their best code, people can look through the source and get great tipis and insights from fellow group members.)

A good point was brought up here though: what about the beginners? They may not even be sure if what they’re doing is correct, let alone whether it’s good coding style or the best way to solve the problem. Sean gave a great suggestion: we can do code reviews (at least I think it was Sean… please forgive and correct me if I’m wrong).

This would be good both for beginners, and for the advanced developers (as long as we can get others to talk about why they did things they way they did).

So, the next steps are to choose a project (via the survey), and then get a starting project framework going. If anyone is willing to help out with this, please send us a message.

Wrap Up

Thanks again for coming out everyone, we hope to see you next month! Feel free to holler with any questions, comments or feedback.

Thanks,

The Ruby Tuesday Team

Survey Results are in! :)

Wed, 01 Feb 2012 07:00:06 -0500

First off, a big thanks to everyone for taking the time to fill in the Ottawa Ruby survey, the feedback was fantastic! We had 29 submissions in all, each chalk full of great insights.

If you haven’t done so already, please go ahead and give us your feedback. Every submission is important, and we’re still keeping track of new responses.

For anyone who’s interested, the results summary is below. But here’s the TL;DR version:

It looks like almost everyone comes out to increase their knowledge of Ruby / Rails, including those who already are super proficient. But, just as importantly it seems, people also want to meet fellow Rubyists.
For the meetups themselves, the vast majority would like a presentation followed by some coding. It looks like the goal of the coding session isn’t just to hack on something cool, but also to learn something new.
There’s a whole bunch of topics that people are interested in, with the most interest in Ruby Best Practices [95%], Front-end stuff (best practices, etc.) [81%], and Productivity Tips and Hacks [76%].
As far as the other topics go, most people want to learn more about Testing [67%], Back-end Stuff (Redis, Memcache, MongoDB, etc.) [62%], CoffeeScript [62%], Debugging [57%], Random APIs [57%], and more.

Now, let’s dive into those results!

The Results

Note: Some of the personal questions / free-form responses have been purposely left out, since we didn’t say upfront that the results would be published.

Ruby and Rails Skill Levels

We have a pretty wide range of skill levels actually, as you can see from the graphs:

Ruby Proficiency

Rails Proficiency

That’s a pretty wide spread, which actually makes things a little tough. We definitely want to remain beginner friendly, but at the same time, we want to make sure that the advanced folk find the meetups worthwhile.

This is something we’re going to have to figure out. We’ll be working on this for the upcoming meetups, aiming to get better each time.

What do you want out of the meetups?

Here’s the graph of the results for this one:

Unfortunately, Google cut off some of the text. Here’s a text-based tally:

So, almost everyone wants to increase their Ruby and/or Rails knowledge, no surprises here. But, at the same time, most people also want to meet fellow Rubyists. There’s a few ways we can go about this, from straight up “networking time,” to doing some pair-programming, or perhaps creating mini-teams for the group project.

We’ll figure this out. The last meetup actually had some great mingling / networking going on during the break, so we’ll likely keep encouraging that. :)

If you happen to have any suggestions on this, please do let us know in the comments.

Meetup Type Preference

This one has a clear winner: people want to have a presentation as well as some hands-on coding during the meetups.

And since I like graphs:

Based on the other feedback, it looks like the purpose of the hands-on coding isn’t just to hack for hacking’s sake, but rather to learn something new. This rings true for both the beginners and the super advanced Rubyists.

It may be tricky, but we should be able to figure something out that will accommodate pretty much everyone.

Topics, topics, topics…

Here, the highest number of votes went towards the things that every Ruby developer should be well versed in: best practice patterns, productivity, and testing. These were followed by some more specific topics. Let’s take a look:

The topic list wasn’t exhaustive, but it’s helpful to see how things rank.

Over the coming months, we’ll be looking to either have presenters discuss these topics, or incorporate them into the group project somehow. If you’d be willing to present on any of these topics yourself, please feel free to let Edward, Dwayne or myself know and we’ll be happy to schedule you for a talk. You can contact us via the Google Group.

So, how can we help you grow?

We’ve got some thinking to do on this. One way is to work on a project as a group, which we’ve already started discussing here.

With this, people of different skill levels can focus on the parts of the project that would help them grow. For example, you may want to focus specifically on the Model, View, or Controller layer.

For the really advanced developers, they can do some fancy things that they normally wouldn’t be able to / need to do with an early stage app, like making it crazy scalable or something.

Another thought is to try and make this an “app of our best practices,” and rather than focusing on just completing the project, focus on our style, patterns and practices.

(And looking at the topic list [see above], almost everyone is interested in best practices, so this fits! With such a wide range of experience, we can all probably learn a thing or two from each other.]

If anyone has any ideas on this, please either post something in the comments, or feel free to join us in the Google Group and toss in any ideas you have. If you’d prefer to talk one on one, send us an email.

Wrap up

Thanks again for providing us your feedback through the survey. Ottawa has a great and interesting Ruby community, and we will continue to work to help every Rubyist to grow.

What do you think we should do to help you grow? Let us know in the comments.

Officially good to go!

Wed, 11 Jan 2012 21:47:00 -0500

woot! We’re officially finished with the new Ottawa Ruby site. Hope to see everyone at the next event! :)

Wrapping up new design

Wed, 28 Dec 2011 11:49:38 -0500

New design is almost Tumblr’d up and good to go! Just working on some final tweaks…

First P0st!

Fri, 09 Dec 2011 15:23:37 -0500

Woop!