Like ArrayEach() and StructEach(), the new filter methods have a “function” parameter (which can also be either an inline function or a named function). However, unlike ArrayEach() and StructEach() which return nothing, the new filter functions return a new array, list, or struct, respectively.

To accomplish this, you need to return a boolean from the function parameter. If the current array element, list item, or structure value matches some criteria and returns “true”, it will be added to the new returned array/list/structure. Conversely, if it fails the criteria and returns “false,” it will be excluded from what is returned.

NOTE:  The array/list/struct filter() functions return NEW arrays/lists/structures. The original arrays/lists/structs against which the filter() functions are called are unaffected.

An Example

Let’s say that we have a simple set of “circles” for a Google+ account which includes a circle for friends, one for co-workers, and another for family. We might model this data like so:

'circles' = {
    'friends': ['Lucas','Phil','Dave','Brian','Dillon'],
    'coworkers': ['Tyler','Mike','Doug'],
    'family': ['Dean','Jared','Jason']
};

Now, let’s imagine that for some reason, we want to filter all of the people in our circles, and return all the contacts (regardless of circle) whose names start with the letter “D”.  One approach might be as so:

// create an array to hold all the names
allDnames = [];
// use structeach() to evaluate each "circle" 
structeach(circles,function(key,value) {
     // "matched" names will be the new array returned from the arrayfilter()
     // which is applied to each circle in the structeach() loop
     matchednames = arrayfilter(value,function(obj) {
         // if the first letter is a "D", return true; otherwise, return false;
         return left(obj,1)=='D';
     });
     // now let's add each filtered name to our master array of "D" names 
     arrayeach(matchednames,function(obj) {
          arrayappend(allDnames,obj);
     });
});

Wrapping Up

As you can see, using CF10′s new ArrayFilter() function is pretty simple, and the ListFilter() and StructFilter() functions work exactly the same, just with slightly different parameters and return types.

But perhaps more importantly, this example shows how functions like StructEach() and ArrayFilter() can make processing of complex data structures a snap. Instead of bothering with messy for-loops in which it would be incredibly easy to lose our place, this approach feels much more sane and easy to follow.

NOTE: The ArrayEach() and StructEach() functions act on the original array/struct. Therefore, if you make changes to the array/struct within these functions (as in the ArrayEach() example below), the original array/struct will be affected (thanks Andy!).

ArrayEach()

So, for example, let’s say you have an array of friends’ names, and you want to make the list all uppercase. Pre-CF10, you might approach this by looping over the array, and executing a function at each iteration. Fine, easy enough, and it works. However, with ArrayEach(), you can ditch the clunkiness of the for-loop, and keep everything self-contained to the array. And, you can execute either an “inline” function, or call a named function. The two examples (which produce the same results) are below:

names = ['John','mary','JOseph','Glenda','Mike'];

// named function
// notice that the function takes one argument, the value of the current iteration of the array
function makeLowercase(obj) {
    names[arrayfind(names,obj)] = lcase(obj);
}

//  run arrayeach() with an inline function
arrayeach(names,function(obj) {
    names[arrayfind(names,obj)] = lcase(obj);
});
writedump(names);

// run arrayeach() with a named function
arrayeach(myarray,makeLowercase);
writedump(myarray);

StructEach()

Not to be outdone, structures get some each() lovin’ in CF10 as well. But instead of iterating over an array, the StructEach() function executes for every key-value pair in the structure. As with ArrayEach(), you can use either use an inline function or a named function.

In this example, we have a simple collection of “favorites,” which we want to print to the screen.

favs = {color: 'blue', food: 'pizza', sport: 'basketball'};

// named function
// notice that the function takes two arguments, the key and value pair of the current iteration of the structure's key-value pairs
function getFavorites(key, value) {
    writeoutput('My favorite ' & key & ' is ' & value);
} 
// run structeach() with a named function
structeach(favs,getFavorites);
// run structeach() with an inline function
structeach(favs, function(key,value) { 
    writeoutput('My favorite ' & key & ' is ' & value);
});

Wrapping Up

While these two functions probably won’t garner the attention that other additions will, I think they’re pretty dang awesome. Not only are they a long time coming (honestly, how often do you loop over an array…like 20 times every hour!!), but they help to make developing with these basic data types just a bit easier as they more closely align methodologies in CF with those you’d find elsewhere.

At some point, however, you’ll need to retrieve data from your Store in a query-like manner. That is, instead of looking up a record by a known ID or position within the store, you may need to find one or more records based on a search term, a category, or whatever else is required by your app.

Of course, as with everything else, ExtJS makes this pretty simple. Let’s suppose that we have the following Model:

Ext.define("MyApp.model.Bookmark", {
     extend: "Ext.data.Model",
     idProperty: "id",
     fields: [
         {name: "id", type: "int"},
         {name: "target", type: "string"},
         {name: "title", type: "string"},
         {name: "category", type: "string"},
         {name: "created", type: "date"}
     ]
});

Nothing to crazy here. Just a simple model with some standard kinds of fields for storing data, in this case, “bookmarks.” Now, let’s define our data store:

Ext.define("MyApp.store.Bookmarks", {
    extend: "Ext.data.Store",
    model: "MyApp.model.Bookmark",
    autoLoad: true,
    storeId: 'bookmarks',
    proxy: {
        type: 'localstorage',
        id  : 'myapp-bookmarks'
    }
});

As with the model, this is very straightforward. We’ve configured a simple store which happens to have a localStorage proxy (change it if you want–ExtJS doesn’t care!).

Simple Data Lookup

Ok, so now that we’re up and running with our model and store, let’s pretend we’ve created a simple app to save bookmarks into our data store. As we’re plugging along, we find that we need to put some kind of tollgate in place to prevent the same bookmark from being entered over and over: after all, having one bookmark to Charlie the Unicorn 2 is certainly enough!

How can we prevent this? In our addBookmark() method, we can do a simple lookup on our data store to see if a bookmark with the same title already exists. This might look something like so:

function addBookmark(target,title,category) {
    var store = Ext.data.StoreManager.lookup('bookmarks');
    var match = store.find('title','title');
    if(match == -1) {
        ...add the bookmark
    }
}

In this simple example, we use the store’s find() method to search through the store’s records. The find() method takes two required arguments–the column to search, and the value to be used in the search–but has more flexibility for case-sensitivity, partial matches, etc. Based on whether the index of a record in our store is returned, we decide whether or not to add the new data to our store.

Of course, if we don’t care about the index of the record and simply want to get a matched record, we could use findRecord() instead. It functions in the same way, but returns a model instance instead of a record index.

More Complex Data Lookup

The store’s find() and findRecord() methods are great if you only need to find matches based on a single data column. What if you need to match on more than one column, though? For example, let’s say that we want to be able to store bookmarks with the same title as long as they belong to a different category. Obviously, our previous method will not work, since the method will prevent insertions of records with already-existent titles. Nope, we need something a bit more robust. Thankfully, ExtJS data stores have just the ticket: findBy().

The findBy() method’s power lies in the fact that you can specify a custom function that will be executed against every record in the data store. Within this custom function, you can do any manner of checks on the entire data record (not just the value of one column). If the conditions you specify succeed, the method will return the index of the first matching record.

So here’s what that might look like for our scenario of checking for the uniqueness of both bookmark title AND category:

function addBookmark(target,title,category) {
    var store = Ext.data.StoreManager.lookup('bookmarks');
    // custom function for finding record with complex criteria
    var match = store.findBy(function(record,id) {
        if(record.get('target')==target && record.get('category')==category) {
            return true;
        }
    });
    if(match == -1) {
        ...add the bookmark
    }
}

As you can see, the custom function is passed two arguments: the model instance of the currently-evaluated record, and the id of the record. Since we want to check to make sure that the combination of bookmark title and bookmark category are unique, we can simply check the “title” and “category” values of the would-be-bookmark against each model in our data store. If no match is found, we know the record is unique and we can add it to the data store. Magical

Wrapping Up

Obviously, the example provided above is very simple; however, I hope it shows just how easy it is to not only query data from a data store, but moreover to create custom functions to apply more complex query logic to the data in your stores.

As expected, this is pretty straightforward, and has the same capabilities as the <cfoutput> corollary. Here’s a quick example:

<cfquery name="qproducts" datasource="somedatasource">
     select *
     from   products
     order by category,subcategory,product
</cfquery>

<cfoutput>
     <cfloop query="qproducts" group="category">
          <h1>#category#</h1>
          <cfloop group="subcategory" groupcasesensitive="true" >
               <h2>#subcategory#</h2>
               <cfloop>
                    #product#<br />
              </cfloop>
          </cfloop>
     </cfloop>
</cfoutput>

Pretty simple, but something which I know a lot of people have wanted for quite a while. Well, now you have it!

But enough of that nonsense.

This day of Ruby is a short one: exceptions and iterations.

Exceptions

I’ll be perfectly honest: I’m lost on this one. I understand parts of it (for example, that particular errors…like StandardError…are subclasses of other errors), but this is a good example where I think the Koans (or probably my brain) come a little short. If I were to stop here, I’d be completely lost when it comes to handling exceptions in Ruby.

Fortunately, the internet exists, and a quick Google reveals that there a dozens of good articles (like this one) about exception handling in Ruby. So I’ve got some reading to do. And you know what? That’s okay. Part of learning is getting frustrated, hitting a wall, and seeking out the answers. I expected this all along, so no biggie.

Iterations

The Iterations Koan is all about looping over arrays and collections (which have the same methods for iterations, btw). As one might exepct, you have most of the standard operations, like “each”, “find”, “select”, etc. The syntax is pretty straightforward:

myarray = ['one', 'two', 'three']
myarray.collect { |item| 'twenty-' + item}
// gives us => ['twenty-one', 'twenty-two', 'twenty-three']

In this example, I’m using the array’s “collect” method to transform each individual element in the array. Pretty nifty.

Wrapping Up

Well, that was short and sweet. I’m [hopefully] diving back more full-time into Ruby tomorrow, so should have some more cool stuff to share soon. I <3 Ruby

Of course, I am by no means ready to really start doing anything with Ruby. However, I do feel like I am grasping basic concepts, and my journey through the Koans is becoming less of flailing blindly and more of thinking about what I’ve learned and trying to reason through the challenges I encounter. Granted, not impressive, but it is progress

Constants

The first Koan dealt with the concept of constants. The role of constants in programming is pretty well-understood, so there’s nothing difficult to understand about their usage in Ruby…in fact, the Koan dealt mostly with how to access constants (within and outside of their definitions relative to particular classes). I did find a nice, more in-depth explanation of the role and usage of constants within Ruby. Check it out when you have a chance.

Control Statements

Ah, what would programming be without control (if, else, for, while…) statements? Probably not worth doing!!

A couple cool things I want to point out about control statements in Ruby.

First, I’m warming to the idea of “statement modifiers”. For example, consider the following:

def mytest()
    value = if true
            :somethingtrue
         else
            :somethingfalse
     end
end

Pretty straightforward, a standard if->else convention. However, in Ruby, you can do something like this:

def mytest()
     value = :somethingfalse
     value = :somethingtrue if true
end

Notice the bit at the end of the third line, the ending “if true”. This accomplishes the same thing as the first example, without the *bulk* of the extra lines. By default, Ruby will return the first “value”, since methods ALWAYS return something. However, the value is overwritten with :somethingtrue if true is…well…true. Probably not a huge advantage either way, but it’s kind of an interesting way to go about it.

The other thing I wanted to mention is related to the first in that it uses a statement modifier. However, instead of using an “if x” evaluator, this uses “unless”:

def mytest()
     value = :somethingfalse
     value = :somethingtrue unless false
end

Nothing terribly profound about that, but it’s a nice way of shortcutting a bunch of unnecessary evaluation, if suitable.

True and False

Coming from a ColdFusion background, this one was a bit interesting. ColdFusion has interesting ways of dealing with booleans, and interesting “things” which evaluate as booleans. Check out Mark Kruger’s excellent article on the subject.

If you are from the same background, a word of warning: Ruby treats true and false in different ways than ColdFusion!

Here’s a rundown, from the Koan, of some ways that Ruby deals with true and false:

true => true
false => false
nil => false
1 => true
0 => true
[] => true
{} => true
"icecream" => true
"" => true

In a nutshell, Ruby treats “false” and “nil” as false. Beyond that, everything else—EVEN EMPTY STRING?!?–is treated as “true”. Interesting

Wrapping Up

Yay, 5 days of Ruby…done! Onward!

On Saturday, Google Politics & Elections posted an interesting infographic about search trends over the last week related to the four remaining GOP Presidential candidates.

Here’s the infographic:

From Google Politics & Elections

Overall, pretty nice. It makes good use of color, highlights the important details, and avoids loading the graphic with needless frills, pointless content, etc.

The one problem, though, is that it’s simply an image. While it’s nice to look at, it’s kind of boring.

Some CSS3 Up In Here

So as I was internally complaining about how boring the image qua image is, it occurred to me that some simple CSS3 flourishes could really make this nice.

Check Out the Example (note: you’ll need a more recent version of Webkit or Firefox for this to work…)

In this experiment, I’m using a few things I’ve not messed with much in the past: keyframes and the flex-box model.

Flex-Box Model

If you’re a web designer, you’ve no doubt spent endless hours trying to coax HTML and CSS to do simple things like expand “columns” a particular percentage in width and height. This is a horrible nightmare to endure, and it usually ends in a lot of hacks and more cursing, just to get content to line up correctly.

Enter the flex-box model. WIth the flex-box model, you can create dynamic, “flexible” areas of content that not only “flex” to fill space based on your precise specification, but can also have intrinsic relationships to other elements.

In my example, I used the flex-box model to handle laying out the “name” and “percentage” content in each candidate’s “bar.” Here’s the HTML:

<div class="bar">
    <img src... />
    <div class="name">Newt Gingrich</div>
    <div class="total">+688%</div>
</div>

Very simple. In fact, the flex-box doesn’t really require much in the way of mark-up…you can easily use the basic structures that you would normally implement.

Since there’s nothing special about the markup, the real magic happens in CSS:

// flex box styles for "bar" container
.bar {
    display: -webkit-box;
    display: -moz-box;
}
// flex box styles for "name" content
.name {
    -webkit-box-flex: 1;
    -moz-box-flex:1;
}

That’s it? Yep, that’s it. When we add “display:box;” to the parent element, we are telling it that it should behave according to the flex-box model. By default, this will lay out all of its children along the horizontal axis. Notice we didn’t have to float anything. That is awesome.

And for the “name” content, we’ve added the “box-flex” attribute and given it a value of “1″. This tells the individual item that not only should it be laid out horizontally with its siblings, but that moreover it should take up additional space. Since we’ve applied “box-flex” to only 1 element, this will take up any remaining space in the parent–if other siblings had “box-flex” as well, the value of “1″ would change in relation to the box-flex of the other siblings.

In essence, what this does it to give us a really nice horizontal layout of 3 items (the image, the “name” and the “percentage”) without needing floats, positioning, or any other nonsense. Since “name” is the only content with “box-flex” assigned, it will greedily gobble up the remaining space left over in the parent, resulting in a nice right-alignment of the variable-width “percentage” content. Did I mention no floats? Hooray.

Keyframe Animations

Besides the super-sweet flex-box utilization, this example also uses the super-fancy keyframe animation specification. What are keyframes? Think about when you used to create animations in Flash, and you created keyframes at specified points along a timeline where you wanted specific events to occur. Keyframes in CSS3 animations are very similar.

In this example, I wanted to animate the background of the main content area (the gradients behind each candidate). WIth the keyframe specification, this is stupid simple. Here’s some CSS:

@-webkit-keyframes expanding {
    0%   { width:0;}
    100% { width:100%;}
}
.bar {
    -webkit-animation-iteration-count: 1;
    -webkit-animation-name: expanding;
    -webkit-animation-duration: .25s;
    -webkit-animation-timing-function:ease-in-out;
    -webkit-animation-fill-mode: forwards;
}

This is a bit more involved than the flex-box model, so let’s take a look piece by piece.

The first chunk of code is where we define the keyframe to be used in the animation. You use the @-webkit-keyframes directive, and then provide a name (“expanding”, in this example). Then, within the object, you simply define the style rules that should be applied at each “frame” of the animation. In this example, we have a very simple definition. At the start of the animation (0%), the width of the element will be 0; at the end (100%) the width will be 100%. The cool part is that the browser takes care of the animation in between each keyframe, and this is why we get the horizontal bar “expansion” animation in this example.

The next chunk of code is how we 1.) apply the keyframe specification to the particular element (“animation-name”) and 2.) additionally configure how the animation will behave, such as the duration, why kind of timing function should be applied, how many times the animation should run, etc.

Pretty cool stuff.

Some Caveats

Unfortunately, support in browsers for some of the cooler stuff in this demo is currently pretty limited. To the best of my knowledge, both the flex-box and keyframe specification are only implemented in Webkit and Firefox.

Moreover, I didn’t bother with a graceful degradation to other browsers. So if you open this example in IE, Opera, etc., you’re out of luck. If you feel like implementing a graceful degradation, feel free to grab the source from GitHub.

Wrapping Up

While a lot of these features are still not yet ready for primetime, I think this example shows ways in which these new aspects of CSS3 can help to improve the experience of the internet. Does this application of CSS3 radically improve the infographic? Probably not. However, it does show the promise of how simple interactivity can be added without much pain at all.

But now I’m back!

Day 4 of Ruby entails some tasty symbols, regular expressions, and methods.

Symbols

While I knew this going in, I’m finding more and more that Koans are a great tool for teaching how to use stuff in a language. What they are not great at, however, is explaining precisely what the “stuff” is.

Symbols are a great example of this gap. They’re scattered sneakily throughout the preceding examples, and seem easy enough to use. However, defining what a “symbol” is by virtue of the Koan itself leaves a bit to be desired.

So I did some reading. I eventually came across a nice article entitled “The Ruby_Newbie Guide to Symbols” by Steve Litt. In this article, Steve makes a helpful, birds-eye exploration of symbols in Ruby, sticking to broad categories and avoiding getting lost in the weeds of over-definition.

I’ll let you read Steve’s article for the full scoop, but my reading of symbols is that they are “things” comprised of an integer identifier and a string; are immutable (can’t be changed at runtime); are the same “thing”, regardless of how many times they are used (see below).

Clear as mud? Sure. However, an easy way (for me, at least) to think of symbols is to think of them in the context of a hash. Consider this example:

# create an array of hashes using strings for keys
names = []
names[0] = {"name" => "Joel"}
names[1] = {"name" => "Jason"}

In this example, we’re using strings for keys. However, when we do this, each instance of “name” becomes a separate object. We can see this by looking at the object id of each key:

names[0].keys[0].object_id // => something like 2167457900
names[1].keys[0].object_id // => something like 2167433500

As you can see, each key is its own object. No big deal in our example, but over thousands of keys, this would add up to some possibly significant memory usage.

Now, let’s do the same thing, but this time with symbols:

# create an array of hashes using symbols for keys
names = []
names[0] = {:name => "Joel"}
names[1] = {:name => "Jason"}

If we look at the object ids of the keys now, we’ll see something very interesting:

names[0].keys[0].object_id // => something like 435228
names[1].keys[0].object_id // => something like 435228

The object ids of the two keys are the same because…well…it’s the same symbol. Instead of a new object being created for each key, one symbol is shared between the two, as well as any other keys using the same symbol that we might create. As you can imagine, over thousands of iterations, this could add up to a decent performance win. Kind of cool.

Regular Expressions

I have a horrible aversion to regular expressions. I’m not very good at them, and frankly this Koan did not help that sentiment. I mostly muddled my way through this Koan, and I’ve decided that regular expressions are something that I need to dedicate some significant time to later this year.

Believe me, I’m not (just) trying to be lazy here. I honestly am not good at regular expressions AT ALL, so I don’t feel that I can speak even partially intelligently about any sort of evaluation of this Koan.

So, moving on…

Methods

The methods Koan was pretty tame–nothing terribly out-of-the-ordinary from what you’d expect to find in a discussion of using “methods” within language A, B, or C. There were a few interesting tidbits, through.

Look Ma, No Parentheses!

First, you can call methods with arguments without parentheses. So the following…

### define method
def my_method(a,b)
    a+b
end
### call method
result = mymethod 4,5  // => 9

This is disconcerting to me, a person who likes things “bracketized.” However, it’s there, so if you REALLY need to save those 2 keystrokes and don’t care about driving the OCD amongst us crazy, go for it.

Default Arguments

Another cool thing is that you can easily define default values for arguments directly in the method definition:

### define method
def my_method2(a,b=3)
    a+b
end
### call method
result = my_method(4) // -> 7

Explicit or Not Explicit Returns

Last, and perhaps in keeping with the possible frustrations inherent in #1, is that methods will potentially return values, whether or not you explicitly define a “return”. For example, the following will return the same value:

### define method
def my_method3(a,b=3)
    return a+b
end

### define method
def my_method4(a,b=3)
    a+b
end

There’s a part of me that hates that (I kind of like the self-documenting nature of brackets, specifying returns, etc.). However, I’m trying to keep an open mind to the patterns that are used in Ruby…hopefully it will make me better precisely by making me uncomfortable!

Wrapping Up

Another great day of Ruby. I’m happy with my progress so far, and I’m looking forward to Day 5!

The Main Idea

If you design a lot of forms, you know that radio and checkbox lists are hard to style. And no matter how perfectly you lay them out, they are still just plain boring. I thought it would be fun to make checkbox and radio lists a bit more fun by going an entirely different route, and by getting a bit more 3D.

Enter “Chunky Checker.” This set of styles takes an ordinary list of checkboxes or radio buttons and converts them into a super-chunky 3D list. As the radios/checkboxes are activated, the particular segment of the list transforms, creating a “depressed” look, sort of as if a button was physically pressed.

The Markup

This approach is completely, 100% CSS and HTML–no JavaScript whatsoever. Moreover, it uses a pretty standard markup. The following is all that’s needed to recreate the demos:

<fieldset>
    <legend>Favorite Color:</legend>
    <input type="checkbox" name="color" value="Red" id="red" class="red"/>
    <label for="red">Red</label>
    <input type="checkbox" name="color" value="Orange" id="orange" class="orange" />
    <label for="orange">Orange</label>
    <input type="checkbox" name="color" value="Yellow" id="yellow" class="yellow" />
    <label for="yellow" class="yellow">Yellow</label>
    <input type="checkbox" name="color" value="Green" id="green" class="green" />
    <label for="green" class="green">Green</label>
    <input type="checkbox" name="color" value="Blue" id="blue" class="blue" />
    <label for="blue">Blue</label>
    <input type="checkbox" name="color" value="Indigo" id="indigo" class="indigo" />
    <label for="indigo">Indigo</label>
 </fieldset>

Nothing out of the ordinary here.

How it Works

in general, the styling is created by completely hiding the checkbox/radio buttons, and applying all of the styles to each input’s label. As checkboxes and radio buttons will be activated by their label being clicked, it’s easy to manage the “state” of the input element.

Speaking of input state, the stylesheet uses the :checked psuedo-selector to determine whether or not to apply particular styles based on the state of the input. There are also rules to apply particular styles based on the state of adjacent inputs.

Finally, there are box-shadows added to create a 3D-ish look, and some animations are thrown in the mix to make the whole thing a bit more dynamic.

Caveats

This has been tested very little I don’t recommend you use it in production anywhere, as the following issues have been admittedly neglected. If you have suggestions for improving in these areas, please get the source from GitHub and hack away to your heart’s content.

Cross-browser Compatibility: I’ve only tested it on Chrome, Firefox, Safari, and Opera, and even then, only on Mac. It seems to work decently well on all of them, although by far it works best in Firefox (go figure). There’s no telling how it behaves in IE9+, and it will surely be terrible in anything before IE9. On the other hand, this is an experiment in CSS3, so that’s kind of expected…

Accessibility: Accessibility for this is probably awful, although I don’t have the interest to test it. There is currently no “focus” class for the inputs’ labels, so this probably isn’t great for use with a keyboard.

Chrome Hack: There is a crazy, silly bug in Chrome that caused me some headaches. If you depress a label, you’ll notice that an inset shadow appears on the depressed label element. When depressing the label to the right of an already-depressed label, the shadow *should* disappear. This works correctly in Firefox and Opera, but only works in Chrome if you move your mouse over the previously-depressed label, open Developer Tools, close Developer Tools, or do some other action that messes with Chrome’s chrome.

Fortunately, I ran across a good description of this bug, which helpfully also had a hack solution. Check it out if you’re curious.

The Demos

I whipped up a couple of demos to show that this works pretty snazzily with radios and checkboxes.

• Checkbox Example (Color)
• Checkbox Example (Grey)
• Radio Example (Color)
• Chrome Bug Active

Day 3 of Ruby Koans brings 3 new lessons: array assignments, hashes, and strings.

Let the fun begin!

Array Assignments

With one significant exception the array assignment koan was pretty straightforward. Dealing with arrays in most languages is pretty straightforward, and the idioms used in Ruby are much of what you’d expect.

A couple interesting things, though.

First, let’s say that you try to access a position in the array that doesn’t exist:

icecream, gummybears = ["Vanilla"]
favorite = gummybears

In this example, I’m trying access the “gummy bears” position within the array. However, it doesn’t exist. Instead of annoyingly erroring out, Ruby returns nil. Remember, nil is an object. So no error, but something useful to deal with. Nice.

But the most interesting part in this koan was the brief example of using the “splat operator.” Before deferring to others for an explanation, here’s the example:

first_name, *last_name = ["John", "Smith", "III]
last_name = ["Smith", "III"]

In this example, using the splat operator (*) when assigning “last_name” not only assigned “Smith” and “III” to last_name, but additionally transformed them into an array.

Honestly, I’m still trying to figure out exactly what the splat operator is meant to do. While I muddle through figuring it out, you can check out this article, this one, and one more.

Hashes

Like array assignments, there wasn’t a ton in hashes that was out of the expected in the koan. A few helpful things to keep in mind, though:

• Keys in hashes are unordered.
• A hash’s keys are an array
• A hash’s values are also an array

One cool thing you can do with hashes is to merge them. Consider the following:

hash = {"videogames" => "awesome", "opera" => "interesting"}
newhash = hash.merge({"opera" => "amazing", "NBA" => "boring"}) 
newhash => {"videogames" => "awesome", "opera" => "amazing", "NBA" => "boring"}

As you’ll notice, merging two hashes with the same keys will overwrite the value of the original key. With a hash, you’d expect this…but still, the merge method is pretty elegant.

Strings

The strings koan is long. There are a lot of methods covered (your typical split, join, etc. idioms). I’m not going to go into a ton of detail about the koan, but I will call out a couple of things that I found really interesting.

First, there’s the “shovel” operator (<<) for concatenating strings. Actually, you can really call it “building” strings, since the shovel operator modifies the original string. Consider the following:

ostr = "Hello "
nstr = ostr
person = "Joel"
nstr << person
ostr => "Hello Joel"

Even though “ostr” is not explicitly modified before the end, the final dump of “ostr” shows that it has, in fact, been modified via the string concatenation with the shovel operator.

Next, there’s the interpolation of variables within a string. For example:

myval = "Wildcats"
str = "My favorite college basketball team is the #{myval}"
str => "My favorite college basketball team is the Wildcats"

Straightforward enough. But consider the same example, just with single quotes:

myval = "Wildcats"
str = 'My favorite college basketball team is the #{myval}'
str => "My favorite college basketball team is the #{myval}"

This is hard to swallow. Double quoted strings interpolate variables, but single quoted strings do not. I suppose if you do it enough, this becomes “one of those things” that you get used to. However, I can just anticipate some half-hour of frustration in my future when I forget this