Skip to main content

Context, Tooling and the Beginner Programmer

Renée De Voursney talking at the AU Ruby Conf about the trials and tribulations of learning Ruby.

Renée De Voursney - Teaching Ruby for fun and profit from Ruby Australia on Vimeo.

She talks about context and how there are so many disparate moving parts to get to grips with before one can "become" part of the Ruby community. Gaining a basic understanding of all the moving parts that encompass not only the Ruby language itself, but the social norms of RSpec, Git, Gems, Github, RVM, *nix, Macs, TDD and various command line tools, is too much of a hurdle for many people to jump.

The biggest problem with a complete novice trying to get into programming is always some sort of feedback loop that will give them the justification to carry on. I'm a great believer in learning by debugging, but at the same time, giving the novice quick wins is important. Get them up and running quickly from nothing (and I mean nothing - no tools installed on their machine yet) to "hello world" in ten minutes.

It's a difficult task. People have a variety of operating systems from various flavours of Windows through Linux boxes and OSX machines. Providing a generic one-size-fits-all is nigh on impossible. Fragmentation sets in. People blog about their frustration and put up tutorials that work on their uniquely configured environments. They try to find work-arounds to annoyances like not having admin rights on computers to circumventing firewall rules that seem to get in the way of any sort of gem installation. It isn't long before someone who just wanted to take Ruby or Rails for a quick ride is hitting their head against a brick wall. And the brick wall is usually just tooling.....it isn't even the code.

Comments

Post a Comment

Popular posts from this blog

Getting started with Ruby on Rails 3.2 and MiniTest - a Tutorial

For fun, I thought I would start a new Ruby on Rails project and use MiniTest instead of Test::Unit. Why? Well MiniTest is Ruby 1.9s testing framework dejour, and I suspect we will see more and more new projects adopt it. It has a built in mocking framework and RSpec like contextual syntax. You can probably get away with fewer gems in your Gemfile because of that. Getting started is always the hardest part - let's jump in with a new rails project rails new tddforme --skip-test-unit Standard stuff. MiniTest sits nicely next to Test::Unit, so you can leave it in if you prefer. I've left it out just to keep things neat and tidy for now. Now we update the old Gemfile: group :development, :test do gem "minitest" end and of course, bundle it all up.....from the command line: $ bundle Note that if you start experiencing strange errors when we get in to the generators later on, make sure you read about rails not finding a JavaScript runtime . Fire up...
3 comments
Read more

Rails 3.2, MiniTest Spec and Capybara

What do you do when you love your spec testing with Capybara but you want to veer off the beaten path of Rspec and forge ahead into MiniTest waters? Follow along, and you'll have not one, but two working solutions. The setup Quickly now, let's throw together an app to test this out. I'm on rails 3.2.9. $ rails new minicap Edit the Gemfile to include a test and development block group :development, :test do gem 'capybara' gem 'database_cleaner' end Note the inclusion of database_cleaner as per the capybara documentation And bundle: $ bundle We will, of course, need something to test against, so for the sake of it, lets throw together a scaffold, migrate our database and prepare our test database all in one big lump. If you are unclear on any of this, go read the guides . $ rails g scaffold Book name:string author:string $ rake db:migrate $ rake db:test:prepare Make it minitest To make rails use minitest , we simply add a require ...
4 comments
Read more

Poor person's guide to managing Ruby versions

Understanding the guts of Ruby Version Management by rolling your own I've been tinkering with a fresh install of Ubuntu 12.10, setting up a nice clean development environment. One of the first things to do, of course, is implement some sort of Ruby version management. RVM and rbenv seem to be the clear winners in this arena, though there are a lot of tools out there that do a similar job . Writing your own version management for your Rubies isn't actually all that difficult. At it's core, we need need two things: A way to segregate the executables of the various versions A way to call the versions at will Segregating versions is trivial - working with files and folders, we can put the various versions into named directories. Actually executing our different versions is not all that difficult either. One way would be to create aliases with version numbers and explicitly call those when we want to use them. The more popular way, however, is to manipulate our PATH ...
2 comments
Read more