Friday, 1 April 2005

Learning Ruby – Day 5

Day 5 is all about objects and their methods.

Remember a few months back when Apple introduced the Shuffle? Everyone was up-in-arms about it’s lack of screen and how it was useless an mp3 player without a screen is. When in-fact, the lack of screen simplifies and improves the device a great deal.

Ruby is like that; elegant, well thought out, useful, challenging convention. Case in point:

Methods names can end with ‘ =’. Conceptually treating a method’s values as variables. It not only saves keystrokes in comparison to the traditional methodName(value) convention – it more accurately maps to what’s being described.

Add to that, a built-in method for creating read & write methods – attr_accessor, an I’m understanding why Ruby is called the Programmers’ Best Friend.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Learning Ruby – Day 4

Day 4 – Iterators.

First, all chapters in programming books should start with quotes from Steve Martin .

Second, what’s a language without a convoluted loop syntax to geek out on? Geeez. I thought the purpose of learning to program was the same as learning Arabic from the Defense Language Institute – “because you can’t.” Ruby has iterators for logical, readable code? This means I might actually get something built rather than just debugging loops.

I’ve mentioned before how much I enjoy Slagell’s writing. I also like how the solutions to the exercises are listed immediately after the exercises. This isn’t typical, at in my collection of programming books. It makes getting un-stuck and getting the point much quicker.

Tip: Here’s how I’m remembering how the ‘step’ iterator works:

start.step(to, by)

an example to display all the odd numbers from 5 to -15

5.step(-15, -2)

Quite a few years back I was talking with a programmer/designer (in contrast to my designer/programmer) who didn’t like AppleScript because it was “too much like English”. With syntax like:

  • 3.times to do something, well, 3 times and
  • 10.downto(1) to count down from 10 to 1

I don’t think he’d like Ruby for the exact same reason – if not more so.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Wednesday, 30 March 2005

Learning Ruby – Day 3

Day 3 is all about strings, arrays, hashes, and ranges – abstract, geeky terms for buckets

In Ruby, strings can be treated like arrays. Meaning it’s super easy to access substring. For example:

theString = "It's raining today"
theString[13, 5]
# returns ‘today’

Finally, I always thought substr() methods were an awkward solution for something so common.

Replacing substrings is just as easy:

theString["today"] = "still"
# theString is now “it’s raining still”

All this talk about strings reminds me, Ruby knows the alphabet. Makes me smile just thinking about it.
"a".next # returns “b”

I’ve written a couple plugins (WP-CaTT, WP-iCal) for WordPress. Developing each one of them has sent me digging through PHP’s function list more frequently than I’d like – looking for just the right function. I’ve rewritten Perl apps in PHP to make the more readable and maintainable. As I’m learning more about the Ruby syntax, PHP feels like Perl.

Here’s a Super Useful Thing: Ruby can grep arrays. Need the list of months you can eat mussels in, if months_in_year was an array of months, this would work:
months_in_year.grep(/r/) # returns all months with an “r” in their name

I’d like to thank Slagell for explaining the difference between arrays and hashes in a useful way.

Back in day one, we talked about the Principle of Least Surprise. So far, getting through the end-of-chapter exercises has been a matter of applying that principle.

I was scanning the pages in today’s chapter looking for the method to flatten an array. According to the Principle of Least Surprise the method would be ‘flatten’. It is. 🙂

Al Abut’s 3rd day


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Monday, 28 March 2005

Learning Ruby – Day 2

Day 2 starts with one of the most valuable programming exercises. What can I do with an object? Just ask it:


self.methods

With ‘self’ being the current object, the above question returns a list of all the questions ‘self’ knows how to answer.

Every object in Ruby can be asked this question. So many languages are only object-oriented, not object-saturated like Ruby. Back in my REALbasic days, I’d scan an objects auto-complete menu looking for the right method or attribute. More than once I was baffled in the differences between objects. I was also baffled by the difference between ‘self.’ and ‘me.’ in RB. No sign of ‘me.’ yet in Ruby.

If you ask 10 people “What is your name?”, you’ll receive 10 different answers. In programming, this is called ‘polymorphism’ and it means different objects can respond differently to the same question. A useful example comes from Object-Oriented Thought Process: all shapes – circles, squares, triangles – have a perimeter and an area. Thought the equation to calculate each is different.

Occasionally, I’ll hit a programming problem where it makes sense to return multiple values out of a method. Normally, I take this as a cue I’m not being clear about what I’m trying to accomplish and make 2 methods. Looks like Ruby can return multiple values separated by commas. Seems useful for debugging.

The Ruby syntax is truly Zen-like. No semi-colons explicitly declaring the end of a line made me smile. Now Slagell’s saying ‘return’ at the end of a method isn’t needed either. Without an explicit ‘return’, the last thing evaluated is returned.

me.jump(up, down)

Here’s a useful tip I learned going through today’s exercises. Between 2 datetime strings, Ruby doesn’t know what ‘+’ means. For example:

return Time.now + Time.now

returns an error, where as

return "it's #{Time.now}" + ", now it's #{Time.now}."

spits out a sentence.

Good to know.

Al Abut’s 2nd day


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Sunday, 27 March 2005

Learning Ruby – Day 1

Mark Slagell’s writing style is conversational and educational. I’ve gone through a number of software language tutorials. I found Slagell’s first chapter a comfortable mix of background info, simple examples, and experiments.

On the outset, Slagell states Ruby is based on the:

Principle of Least Surprise:
“If you don’t know how to do something and you try to say clearly what you mean, there’s a good chance it will work.”

This principle’s more descriptive if less sexy moniker is the principle of maximum boredom.

The remainder of Day 1 is examples proving his point.

Al Abut’s first day


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Thursday, 24 March 2005

Learning Ruby in 3 Weeks

A year ago I dropped REALbasic. Since then, I’ve struggled to get my head around Cocoa and Objective-C.

With the recent hype around Ruby on Rails, I started looking at Ruby and found a Ruby/Objective-C bridge. To me, this means there’s a huge potential to have tightly-integrated desktop and web-based applications in a single, easy-to-maintain language. Therefore putting a different spin on REALbasic’s cross-platform promise, while still giving me platform-specific functionality.

With this in mind, I’ve picked up the ebook version of Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.

Monday, 21 March 2005

The Object-Oriented Thought Process

On my way to better understand object-oriented programming ( ) and thereby check “Learn enough Objective-C to be dangerous” off my ThingsToDo list, I picked up The Object-Oriented Thought Process by Matt Weisfeld.

Not having formal training in software engineering, I found the book’s focus on the language-agnostic basics of OO extremely helpful.

Here’s what I learned from the book:

  • Classes are almost always nouns
  • A Class’s ‘Responsibilities’ are almost always verbs
  • In the Model-View-Controller (MVC) pattern;
    • Model = the application object, the data-model
    • View = the screen presentation
    • Controller = the user interface’s response to user input
    • (this wasn’t as helpful as I’d like, it may just need to sink in)
  • ‘is-a’ relationship = one object is a specific version of a more general object (e.g. Hamlin is a turtle)
  • ‘has-a’ relationship = one object has another object contained within it (e.g. a bicycle has a seat)
  • Patterns are general principles for solving programming problems
  • AntiPatterns are specific examples of programming problems solved poorly or solutions to redeem poorly-solved problems

Weisfeld was mostly language-agnostic, he uses Java ( ) for his examples. At times, the example code gets in the way of the illustrating the point. With the little I know about Ruby ( ) (100% object-oriented, simpler syntax than Java), I may have chosen that language to illustrate OO principles to novices.

If you’re looking for a non-programming book to wrap your head around OO, I haven’t found an alternative to The Object-Oriented Thought Process.