This post will get into how Ruby chooses a path through your program, aka "flow control"

Now you've got an understanding of what tools you can use and it's time to start thinking about how the Ruby interpreter moves through your code. Sometimes you want to execute a certain chunk of code, other times you don't. In this post, you'll see the different ways of controlling the flow of your program.

You'll need to understand which types of things Ruby considers "true" and which ones it considers "false". "Truthiness" and "Falsiness" are ways of saying "what evaluates to true?"" and "what evaluates to false"? In many languages, there is some nuance to that question. In Ruby, it's simple: nil and false are false and that's it. Everything else is "truthy".

Read More…

This post will get into a few other random things that are really useful but usually skipped by beginners

So What is nil? It represents nothing... literally. Before you assign a value to something, it starts as nil, for instance an item in an array or a variable:

> my_arr = []
=> []
> my_arr[3]
=> nil          # hasn't been assigned yet

Sometimes you want to know if a value or variable is nil before doing something (because otherwise the operation would throw a bunch of errors at you). Use the method nil? to ask whether it's nil or not beforehand.

> nil.nil?
=> true
> [].nil?
=> false        # Waitasecond....

Why is [] not nil? The array itself exists so it isn't nil... it just happens to contain no values yet so it's empty. If we asked for the first value of that array using [][0].nil?, that would be true

Read More…

This post will get into Hashes, which many Ruby newbies have never seen before but which are incredibly useful

Hashes may be a bit intimidating at first but they're actually pretty similar to arrays. They're basically just containers for data, like arrays, but instead of storing data based on numeric indices, you use "keys" which can be strings or symbols. This makes hashes more appropriate for storing data with a bit more depth to it.

A Hash is just a container for data where each piece of data is mapped to a Key. The data is called the Value. Keys can be either strings or symbols. Values can be anything, just like with arrays. A hash looks almost like an array, but with squiggly braces {} instead of hard ones [] There's no order to a hash (unlike an array)... you're accessing your data using strings anyway so it doesn't matter which order they're in.

Read More…

This post will get into Arrays, which is where you really start seeing some of Ruby's cool programmer-friendly features

Arrays are almost as ubiquitous as strings. You'll be working with them all the time to help store data, everything from the names of all your users to coordinates on a game board. An array is an all-purpose bucket into which you can put pretty much anything.

Here, you'll learn the basics of creating arrays, how to manipulate them in a dozen different ways, and some best practices for working with arrays. Note that we'll be learning even more about how to dig around inside of arrays in a future lesson, so if you're excitedly waiting to better understand #each, #map and others like them, we're almost there! If not... you will be.

Read More…

This post will cover strings and all the interesting things you can do with them in Ruby.

Strings are a huge part of web programming and you'll run into them everywhere from variable names to user input to giant gobs of HTML text to handling big dictionary files. They're actually pretty simple at the core but, for being just a jumble of characters, strings have some pretty cool properties in Ruby and you can do a whole lot to manipulate them.

This post should give you an appreciation for the ways you can mess with strings and some of the handy methods that Ruby gives you along the way to make your life easier.

Strings are just made up of individual characters and denoted with quotes. > I confuse Ruby and probably throw an error but > "I do not because I have quotes"

Read More…

This post will cover objects, methods and some things about classes in Ruby

"Everything in Ruby is an Object" is something you'll hear rather frequently. "Pretty much everything else is a method" could also be said. The goal here is for you to see the Matrix... that everything in Ruby is an Object, every object has a class, and being a part of that class gives the object lots of cool methods that it can use to ask questions or do things. Being incredibly object-oriented gives Ruby lots of power and makes your life easier.

Think of every "thing" in Ruby as a having more than meets the eye. The number 12 is more than just a number... It's an object and Ruby lets you do all kinds of interesting things to it like adding and multiplying and asking it questions like > 12.class or > 12+3

Read More…

This post will be very brief look at some of the basic numbers, operators, and expressions in Ruby

When doing mathematical operations, Ruby expects the result to be the same type as the inputs, so dividing two integers by each other will produce an integer... whether you want to or not:

> 5 / 3
=> 1  

To fix this, you need to make one of the inputs a different data type that can handle decimals, like a floating point number (float):

> 5.0 / 3               # as long as one of them is a float...
=> 1.6666666666666667   # ... the result is a float

Converting between integers and floats is easy -- just use to_i and to_f respectively:

> 5.0234.to_i
=> 5
> 5.to_f
=> 5.0

Because Ruby is so flexible, it lets you do some quirky things like multiplying completely different data types together in a way that you sort of think you should be able to but never expected to actually be able to do:

Read More…

The other weekend I had the pleasure of teaching a Rails workshop with Daniel Kehoe of RailsApps. I really wanted a chance to do some teaching and organization and Daniel was testing out the material of his new Rails 4 book. Feedback about the workshop itself was quite good but we also learned a lot about marketing and hustle along the way. In the spirit of that learning, here are some of our victories and mistakes:

Format

We decided to do a full weekend in-person workshop aimed at beginners and technology switchers in the Bay Area. It was two full 9-hour days on Saturday and Sunday with a brief 2 hour installfest on Friday evening. App Academy was generous enough to host for us, so we had a good space to work with and expected to have 20-30 students.

The goal was to install Rails then build and deploy a sample app by the end of the weekend and to help the students understand why they took the steps they did. The app favored APIs like Google Drive instead of using ActiveRecord on the back end so we could actually cover all the material in the time allotted.

Read More…

The Old

Building modernwanderlust.com (my old blog site) was a fantastic starter project to break into web development. I basically followed a tutorial on Udemy that used an AMP (Apache/MySQL/PHP) stack and hacked, smashed and sweated my way to a working prototype over about a month during the summer of 2012.

And ever since it launched, I've been terrified to change anything. Think about the first thing you ever built... how robust and modular was your code? Yeah, this is probably worse. Couple that with the fact that all my focus has gone into learning Ruby and Rails (NOT PHP), and you can understand why I've had this thing in my sites for a major overhaul. Given my new Rails wizardry, it couldn't take more than 4 hours on a weekend, right?

Famous last words for a side project, of course... It's been several weekends spaced out over a couple months :)

Read More…

It's been some time since I last got the chance to put down some words here and it's not for lack of anything to say. I've been incredibly busy over the past few months putting together what has been a devilishly interesting and intense project. I left my position at App Academy in May to do so full time.

The Odin Project is an attempt to put my efforts where my mouth is... a chance to try and make a meaningful impact in online education. The goal of the project is to educate developers from absolute beginner to employable using the same project-based and pair-oriented methodology that proved so effective in my own education. It is based around an open-source curriculum that leverages as much existing content as possible to get from A to B.

Building out the curriculum and the tools to help students pair together has been a herculean task so far but traction is picking up and I'm running a regular class based on what I've put together. It's incredibly exciting to see the project so far help real people take a meaningful step forward in their own education. I'm also beginning to get interest from other developers in the community, which has opened up some great dialogues around the project.

Read More…