RSpec and Internal DSLs in Ruby

Wed, 12 Sep 2012 00:00:00 PDT
Note: because these articles usually contain inline code examples it is highly likely that they will not display properly in your feed reader.
To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/rspec_and_internal_dsls.html
I had a developer email me the other day asking for advice on how to tackle a project that required parsing a natural language DSL (Domain Specific Language). He asked if maybe he should look at the parser for RSpec to get some ideas from there.
What some may not realize is that RSpec is a shining example of an ‘internal DSL’ ie: a DSL that is implemented using only the features of the parent language. Writing a DSL this way does not require that you create a separate parser and interpreter. This obviously saves a huge amount of development time in situations that allow using this style of DSL.
The down-side is that you can’t really expose a DSL written this way to un-trusted users. And by un-trusted users I really mean anyone that is not on the development team. The reason is that because an internal DSL makes use of the power of the parent language, it also generally allows users to execute arbitrary code, which is obviously a no-no.
Here’s a quick example of the style of code that RSpec uses to provide it’s natural syntax:
 1 module Kernel  2 def should  3 return Handlers::PositiveOperatorHandler.new(self)  4 end  5  6 def should_not  7 return Handlers::NegativeOperatorHandler.new(self)  8 end  9 end 10 11 module Handlers 12 class PositiveOperatorHandler 13 def initialize(actual) 14 @actual = actual 15 end 16 17 def ==(other) 18 puts "Expected '#{@actual.inspect}' to equal '#{other.inspect}'" unless @actual == other 19 end 20 end 21 22 class NegativeOperatorHandler 23 def initialize(actual) 24 @actual = actual 25 end 26 27 def ==(other) 28 puts "Expected '#{@actual.inspect}' to not equal '#{

Introducing Flea - A tiny Lisp written in Ruby
Mon, 14 Mar 2011 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/introducing-flea.html
         
         
         Flea is a tiny Lisp interpreter implemented in Ruby. Flea is designed to be an example of how simple it can be to bootstrap the core of a small flexible language. Flea essentially defines an informal subset of Scheme, just enough to be fun and interesting.
 Code example:
 Here is a version of the classic ‘guess-the-number’ game implemented using Flea:
  1 (define number (+ (rand 9) 1))  2  3 (display "\n\nI'm thinking of a number between 1 and 10,\n")  4 (display "try to guess it!\n\n")  5  6 (define user-guess  7 (lambda ()  8 (display "Take a guess - ")  9 (define guess (string-to-num (gets))) 10 (if (equal? guess number) 11 (display "Good guess!\n") 12 (begin 13 (if (greater-than? guess number) 14 (display "Lower!\n") 15 (display "Higher!\n")) 16 (user-guess))))) 17 18 (user-guess) 
 Installation:
 For ease of use the Flea is packaged as a RubyGem. Providing you already have Ruby and RubyGems installing Flea is as easy as entering the following command in a terminal:
 1 gem install flea 
 Mac OS X and most Unix/Linux distributions come with an installation of Ruby and RubyGems. If you do not have Ruby and RubyGems installed please check the Ruby website for instructions.
 Usage:
 After Flea is installed you can run a program by typing the following on the command line:
 1 flea /path/to/program 
 You can also launch Flea’s interactive shell by simply calling flea with no arguments.
 The entire API for the language is documented on the project page at GitHub.
 Experimenting and contributing:
 Flea was designed as a learning tool, so with that in mind I strongly encourage you to pull it apart, play with it, and glue it back together in different ways. For an explanation of...


Cheating your way to Lisp with Ruby
Sun, 13 Mar 2011 00:00:00 PST

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/cheating-yor-way-to-lisp-with-ruby.html
         
         
         The main purpose of this post is to illustrate how simple it can be to bootstrap a small programming language using a high level language. The core of the language we’ll create is well under 100 lines, and is so extensible that it would be a relatively simple task to turn it into a full-blown Scheme implementation.
  The code examples in this post are stripped down versions of code found in my miniature Lisp implementation, Flea. 
 Let’s dive right in and have a look at the core code for our mini-lisp! First let’s have a look at MiniLisp::Environment. This class is responsible for defining and finding variables, each environment can optionally have a parent which gets included in the variable lookup chain, this allows us to implement lexical scoping.
  1 module MiniLisp  2 class Environment  3  4 attr_accessor :parent  5  6 def initialize(parent = nil)  7 @parent = parent  8 @table = {}  9 end 10 11 def find(name) 12 return @table[name] if @table.has_key?(name) 13 return nil if @parent.nil? 14 return @parent.find(name) 15 end 16 17 def define(name, value) 18 @table[name] = value 19 end 20 21 end 22 end 
 Next is MiniLisp::Interpreter, this class has two main methods: run and evaluate. The run method simply steps through an array of expressions and passes them individually to the evaluate method. The evaluate method then does several checks:
  If it has been passed a Symbol then it calls find on the current environment using the symbol as the key and returns the value it finds.
 If it is anything other than an Array at this point then we are looking at a literal (be it a String, Integer, or Float), and we need to return the literal untouched.
 If it is an array then we are...


A quick intro to writing a parser with Treetop
Mon, 13 Sep 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/a-quick-intro-to-writing-a-parser-using-treetop.html
         
         
         Treetop is a Ruby library that allows you to create parsers easily by describing them using a Parsing Expression Grammar (PEG). Writing a parser using Treetop is a fairly pain-free process, but getting started can be non-trivial, especially if you’re not familiar with PEGs, so this is going to be a fairly short ‘getting started’ guide. To keep things simple our example parser is going to process a subset of S-Expression syntax like so:
 1 (define test (lambda () 2 (begin 3 (display "something") 4 (display 1) 5 (display 3.08)))) 6 7 (test) 
 It will be a fairly simplistic example, but it should be enough to get you started!
 Installing Treetop
 Provided that you already have Ruby and RubyGems installed, installing Treetop is a very simple process. Simply enter this at your command line:
 1 gem install treetop 
 If you do not have Ruby and RubyGems installed then you should have a look at the Ruby website for installation instructions.
 Getting Started
 There are going to be three main parts to our parser:
  The Ruby class Parser which will contain the API for interacting with the parser
 The Treetop grammar file in which we will create all the rules that define how our parser will behave
 A series of simple classes that subclass Treetop::Runtime::SyntaxNode, these will allow us to easily describe our parsed structure by having each type of entity map directly to a custom syntax node class
 
 The first thing we need to do is create skeletons for the three files involved:
  1 # In file parser.rb  2 require 'treetop'  3  4 # Find out what our base path is  5 base_path = File.expand_path(File.dirname(__FILE__))  6  7 # Load our custom syntax node classes so the parser can use them  8 require File.join(base_path, 'node_extensions.rb')  9 10 class Parser 11 12 #...


Writing an S-Expression parser in Ruby
Sun, 05 Sep 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/writing-an-s-expression-parser-in-ruby.html
         
         
         S-Expressions are a very versatile syntax for defining data structures and program code that are used by most Lisp-derived programming languages.
 When experimenting with new languages S-Expressions are fantastic because they are extremely flexible but only require minimal effort to parse. In this article I am going to cover the basic principles of creating a robust S-Expression parser in Ruby.
 Note: if you just want a complete and working S-Expression parser library for Ruby please check out Sexpistol
  Note: Since writing this article I have found a more performant and concise parsing method using StringScanner. I will be writing an updated post shortly. If you would like to to have a look at the completed code using the new method check it out at GitHub. The code in this article is still relevant as an introduction. 
 
Our parser
 One of the first things we should have a look at is a simple example of some program code written as an S-Expression:
 1 (define test (lambda () ( 2 begin 3 (print "test") 4 (print 1) 5 ))) 6 7 (test) 
 The first step in most parsers is to break the input text up into ‘tokens’, and in order to do that we have to know what the possible tokens are in our target grammar. In our case we have it easy as there are only 5 distinct tokens that we care about initially:
  Opening parentheses (
 Closing parentheses )
 Symbols define begin print etc...
 String literals "test" "foo" etc...
 Integer literals 2 5 99 etc...
 
 The first thing we should notice is that one of these tokens is a ‘special case’ in that it can contain other sequences of characters that we would normally perceive as tokens in of themselves. This complicated token is the String literal.
 In order to simplify the problem for ourselves the first thing we are going to do is find all of the string literals, copy them into an array, and then replace them with a special placeholder string:
  1 def extract_string_literals( string )  2 string_literal_pattern = /"([^"\\]|\\.)*"/  3 string_replacement_token = "___+++STRING_LITERAL+++___"  4 # Find and extract all the string literals...


Introducing Koi - A language that teaches the basics of language implementation
Sun, 29 Aug 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/introducing-koi.html
         
         
         Several months ago I started on a quest to learn more about how programming languages work internally. Today I am releasing my first programming language: Koi.
 Koi is designed, above all else, to be a language whose implementation demonstrates the basics of how to build a language in a straight-forward way.
 Most programming language implementations are written in low-level languages like C in order to maximize performance, and this generally makes them very opaque and difficult to follow.
 In order to avoid this problem Koi is written from the ground up in Ruby to make sure that the implementation language never gets in the way of the intent of the code. Koi will likely never be suitable for use as a production language, but that was never one of its goals.
 Koi is an imperative, dynamic, weakly-typed language with first-class functions. Koi’s syntax and features were influenced by Lua, JavaScript and Ruby. Additionally Koi makes a special point of working very hard to be unambigous in its syntax so that it is easy to write parsers for.
 Code example:
 An old-school ‘Blast Off!’ example in Koi:
  1 countdown = function( count )  2 print( to_string( count ))  3 print( ", " )  4 if( count == 0 )  5 return()  6 end  7 count = count - 1  8 call( countdown, count )  9 end 10 11 call( countdown, 10 ) 12 13 print( "Blast Off!" ) 14 15 #=> 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, Blast Off! 
 More code example are available at the Koi GitHub repository
 Installation:
 For ease of use Koi is packaged as a RubyGem and will automatically install its dependencies. OSX and most flavors of Linux come with Ruby and RubyGems pre-installed so you should just be able to type:
 1 gem install koi-lang 
 If you need to install Ruby please check the Ruby website for instructions...


Hardware Upgrades for Developers
Sun, 29 Aug 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/hardware-upgrades-for-developers.html
         
         
         A little while ago I noticed my MacBook was becoming a little laggy. Opening applications seemed to have gotten slower, and switching between applications was often the cause of several seconds of waiting. Furthermore whenever my backup program starting doing it’s thing the machine would start swapping and everything would become extremely sluggish. Given that this was all breaking up my workflow I decided that I needed to upgrade.
 Initially I looked at buying a new 13” MacBook Pro, but for the extra expense the only place where it had a clear advantage over my current 13” Aluminium Unibody MacBook was in the battery life, which wouldn’t solve my performance issues.
 That led me to think about solid-state hard drives. Many people have become strong proponents of them over the last few years as they have matured as a product. I also wondered how an SSD would fare against a simple RAM upgrade in terms of seeing better performance in day-to-day use, so I decided to document the results of each step of the upgrade so other people could use the information to make choices for themselves.
 The original hardware:
 Late 2008 13” Aluminium Unibody Macbook (Model: MacBook5,1)
  2Ghz Core 2 Duo
 2Gb DDR3 PC8500 RAM
 1066Mhz front-side bus
 120Gb 5400RPM HDD
 
 The upgrade options:
 6GB of DDR3 PC8500 RAM in 2 DIMMS: 1x 2GB, 1x 4GB
 Note: while I did all the tests with the full 6GB of RAM, I ended up taking out the 2GB DIMM and just going for 4GB total. This is because 6GB of RAM in this machine is unsupported and was causing issues when the computer went to sleep.
 50GB OCZ Vertex 2 SSD
 This is an insanely fast drive even by SSD standards, but it was primarily chosen for it’s controller. The Sandforce controller in this drive implements on-drive garbage collection that helps minimize performance degradation due to OS X’s lack of TRIM support.
 Testing methodology:
 I can’t pretend to be an expert on statistics, so I basically approached the problem of benchmarking the upgrades the same way I would when profiling a software system. I wrote a series of automated benchmarks (the complete code for which can be found here: http://gist.github.com/603332) and then I did a series of runs of the tests. After each run the machine was restarted. The test suite was run 4 times...


A simple intro to writing a lexer with Ragel.
Tue, 13 Jul 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/a-simple-intro-to-writing-a-lexer-with-ragel.html
         
         
         It seems that there is a fair variety of tools designed to make writing Lexers, Scanners and Tokenizers easier, but Ragel has a reputation for being simple and consistently producing the fastest final code. This is a short and simple intro to Ragel for a common use-case: writing a Lexer for a programming language.
 Start by making sure you have Ragel installed. This process varies for each OS so I'm not going to cover it in detail. On OS X it's as easy as installing MacPorts and then opening a terminal and typing 'sudo port install ragel'. You should now be able to use Ragel via the command-line.
 Next you need to decide on your 'host language'. The host language is preferably the same language that the rest of your project is written in, though many people opt to use C for their lexer because of the dramatic increase in speed that it provides. Ragel supports a number of host languages including: C, C++, Objective-C, D, Java and Ruby. For the purpose of this intro we will be using Ruby as it won't obscure the Ragel-specific code as much as other languages would.
 First let's create a blank file called 'lexer.rl' and then define an empty state machine inside it. Ragel state machines are defined inside blocks demarcated with '%%{ }%%' like so:
  In this Ragel code block we are defining a blank state machine called 'test_lexer', then telling Ragel that the state machine should be compiled in this file using the 'write data' directive. The ability to define where the state machine should be compiled is more useful once we start defining machines that span multiple files. Regions outside of '%%{ }%%' blocks and lines that do not start with '%%' are assumed to be written in the host language.
 In Ragel the syntax for defining a lexer/scanner differs from that required for creating a normal state-machine and looks like this:
  If the 'scanner_name' is 'main' then it is automatically run when our state machine is executed. An 'action' is a section of host-language code that is executed whenever the token represented by 'token_description' is found. It could be something as simple as printing out the token, or it could be code to affect the state of something external like a parser.
 Token descriptions can either be a string literal (like 'keyword')...


Bootstrapping a prototype-based object-model in 44 lines of code.
Mon, 12 Jul 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/bootstrapping-a-prototype-based-object-oriented-language-in-44-lines-of-code.html
         
         
         Until a few weeks ago I had always thought that writing a language required some crazy voodoo, but it turns out that once you start digging into the fundamentals they are actually fairly easy to understand and, under certain circumstances, fairly easy to implement as well.
 In this short example we are going to implement a prototype-based object-model in Ruby. To make it a valid exercise we will not be using any of Ruby's object-oriented features. The final mini-language we create will not be pretty, but it will work. Making it pretty will require syntactical sugar for things like sending a message to an object, which is not something we will tackle just yet.
 The first thing we need is a way to store the structure of our objects. For this purpose we are going to use a Hash like so:
  The 'slots' in this hash will store the methods/data that are associated with the object. The 'parent' will be a pointer to the object's parent if it has one, and the 'size' will simply keep track of how many key/value pairs are stored in 'slots'.
 Next we need to define functions for sending a message to an object, and for creating a new object that inherits the behaviour of a previous one:
  The 'send' function depends on the fact that each object is required to define or inherit a 'lookup' method. The 'lookup' method defines how an object reacts when it is sent a message. If the send function cannot find a 'lookup' method defined on the current object then it follows the chain of inheritance upwards (via 'parent') until it finds one, or until the inheritance chain is exhausted.
 The 'derive_from' function simply creates a new object with an existing object as it's 'parent'. This provides a way to create a new object that inherits behaviours from an existing object, this layout is technically known as 'single inheritance'.
 Next up we need to manually create the initial 'lookup' method for our basic object:
  The 'lookup' method is very similar to the 'send' function in that it traces the chain of inheritance looking for a slot with a key which corresponds with the 'message'. If it finds a match then is simply returns the value of the slot so that 'send' can execute it as a method. If it cannot find a corresponding...


Improving application throughput 9x with asynchronous responses in Rails 3
Sat, 12 Jun 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/improving-application-throughput-900-percent-with-asynchronous-responses-in-rails-3.html
         
         
         
Update: A quick overview of the changes needed to setup Ajax-Gist to use asynchronous responses is available here: commit summary at GitHub
 Several weeks ago when writing Ajax-Gist.com one aspect of the project I neglected was performance. Because every un-cached request requires that we do a HTTP call to gist.github.com, application throughput was very low, on the order of 5 requests per second.
 For the most part this was 'good enough' and logs showed that very few people were being left waiting on the queue because of my fairly aggressive HTTP caching. But when it came down to it I wanted to be able to offer a more reliable and more performant service, ideally without shelling out the extra clams for access to more application instances on Heroku.
 While thinking about the problem I remembered that Thin (the web-server that Heroku uses) is capable of serving asynchronous requests using EventMachine. I knew that asynchronous Rack applications were fairly easy to write, but I didn't want to abandon Rails because, while this is a fairly simple application, keeping the simplicity of Rails and getting the advantage of higher application throughput in this and other more complex applications would be a big win.
 Luckily this is one of those occasions where other, much smarter, people already had the same idea, albeit fairly recently. My research turned up a lot of work by Ilya Grigorik and Mike Perham that pushed toward this goal. Rack/Fiber-Pool by Mike is a piece of Rack middleware that runs each request in it's own Fiber, allowing the possibility of easy cooperative scheduling in Rack applications. While EM-Synchrony provides a set of Fiber-aware EventMachine clients for common things like HTTP requests, Memcached, MySQL and Mongo.
 Mike was kind enough to do all of the leg-work in creating a guide for creating asynchronous Rails 2.X applications and only 2 days ago Ilya provided an example for achieving the same results in Rails 3.
 In the end implementation turned out to be relatively simple, and the results speak for themselves:
  1 # Synchronous:  2  3 Benchmarking 192.168.1.3 (be patient).....done  4 Document Path: /gist/1010.js  5 Concurrency Level: 30  6 Time taken for tests: 18.312 seconds  7 Complete requests: 100  8 Requests per second: 5.46 [#/sec] (mean)...


Ruby, shallow copy surprise!
Wed, 19 May 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/ruby-shallow-copy-surprise.html
         
         
         Many people, like me, that have done any C, C++ programming are used to the idea that programming languages either copy variables by value, or by reference, or either if explicitly set.
 I was under the impression Ruby was a 'pass by value' language, but no longer. After spending most of a day debugging a problem and then finding out that one of my base-level assumptions about Ruby was fundamentally flawed I was quite shocked, and felt more than a bit stupid. But upon talking to some fellow Rubyists the other day at Rails Pub Nite I found out I was not alone in my assumptions. This may seem silly to some that have broader experience with a range of high level languages, but to others (like me!) it can be quite surprising.
 Consider this:
  1 require 'test/unit'  2  3 class SanityTest < Test::Unit::TestCase  4 def test_my_sanity  5 complex_array = [{:blah => "hello"},{:foo => "blah"}]  6 copied_array = complex_array  7 copied_array[0][:blah] = nil  8  9 assert_not_equal copied_array, complex_array 10 end 11 end 12 13 # 1) Failure: 14 # test_my_sanity(SanityTest): 15 # <[{:blah=>nil}, {:foo=>"blah"}]> expected to be != to 16 # <[{:blah=>nil}, {:foo=>"blah"}]> 
 What? If ruby is copying by value why is that change back-propagating to our original array? How about Object.clone? That should fix whatever the problem is. But no. After some research it turns out that there is a big difference between the way Ruby handles 'immediate' values (Fixnum, Symbol) and the way it handles more complex objects (Float, String, Array, Hash, YourClass) during copying. The key thing that eventually jumped out at me when reading over the ruby Object docs was the phrase 'shallow copy'. What is a 'shallow copy'? A shallow copy means that only the fundamental datatypes actually get copied into new objects, everything else gets copied as a reference to the original object!
 So how can we fix this? It's not very Rubyish, but at least it's simple:
 

Automatic content moderation with 'validates_text_content'
Tue, 13 Apr 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/validates_text_content.html
         
         
         Over the last 6 months I have been working on a number of community websites, all of which aim to make it as easy as possible for people to contribute. No account creation, no captchas, no hassle. This has brought a particular problem to my attention: one of the greatest differences between a valuable online community and a horrible one is the level of time and thought that goes into the comments/content produced by the community members. As an example of this consider the comments written on Hacker News versus the ones on YouTube.
 A big issue for many online communities is the fact that distinguishing between valuable content and trash content in an automatic fashion is very hard. Most communities solve this problem by enlisting the help of human moderators in addition to a member-accessible content flagging system.
 But what if human moderation is not an option? You have a small community that you want to grow quickly but you can't afford to devote untold hours moderating content or lots of money paying someone else to moderate the content for you. Luckily some simple statistical analysis can probably come to the rescue!
 How many words does it take to say something of worth? Surely content that is only 20 characters long cannot be contributing much? How about content that has no capital letters? Or no punctuation? There are many patterns inherent in any written language that we can leverage to determine whether or not textual content meets a certain level of quality. Text that has been well though out will be laid out into sentences and paragraphs, will be well punctuated and consist mainly of words that are listed in a dictionary somewhere, rather than short abbreviations.
 With this in mind we can dig up some simple relevant facts about how the English language is structured:
  Sentences start with a capital letter and end with one of a variety of punctuation marks.
 The letter 'E' is the most commonly used letter in English words, occurring roughly 12% of the time. [source]
 The average length of an English word is roughly 5.1 characters. [source]
 
 We can also pull in a relevant point from simple common sense etiquette:
  Writing exclusively in BLOCK CAPS is a sign of either rudeness or laziness.
 
 Without inventing strong A.I. or resorting to complex Bayesian Filtering we can still...


Ternary Quandry
Tue, 13 Apr 2010 00:00:00 PDT

           Note: because these articles usually contain inline code examples 
           it is highly likely that they will not display properly in your feed reader.
           
           To see this article as it was originally written please visit: http://thingsaaronmade.com/blog/ternary-quandry.html
         
         
         When writing even fairly simple code in JavaScript you will encounter many situations where you need to test for the existence of a variable, and either use it or a secondary variable if it does not exist (or more correctly, does not evaluate to ‘true’). Consider this:
 1 if( object.property ) 2 { 3 var result = object.property; 4 } 5 else 6 { 7 var result = object.otherProperty; 8 } 
 This, while being easy to understand, clearly takes up a lot more room than it needs to. With this in mind many developers will turn to the Ternary operator to gain the same result in a more compact form:
 1 var result = (object.property) ? object.property : object.otherProperty; 
 Personally I find the syntax of the Ternary operator confusing… Can you easily recall which variable is assigned when the condition is met? How about someone that has just started programming? What if it is used in the middle of another expression? I am a big believer in making the function of your code as obvious as possible and, for me at least, the Ternary operator does not contribute toward that ideal.
 Enter the Or operator:
 1 var result = object.property || object.otherProperty; 
 In this example we are using a lesser-known sprinkling of JavaScript’s syntactical sugar. If the object.property variable evaluates to true it is assigned, otherwise the Or operator jumps in and hands the second variable (object.otherProperty) to the receiving variable. To illustrate:
 1 window.firstProperty = "Hello!"; 2 window.secondProperty = "I'm number 2!"; 3 4 var result = window.firstProperty || window.secondProperty; 5 6 alert( result ); // Hello! 
1 // window.firstProperty === undefined; 2 window.secondProperty = "I'm number 2!";
Things Aaron Made

RSpec and Internal DSLs in Ruby

Introducing Flea - A tiny Lisp written in Ruby

Code example:

Installation:

Usage:

Experimenting and contributing:

Cheating your way to Lisp with Ruby

A quick intro to writing a parser with Treetop

Installing Treetop

Getting Started

Writing an S-Expression parser in Ruby

Our parser

Introducing Koi - A language that teaches the basics of language implementation

Code example:

Installation:

Hardware Upgrades for Developers

The original hardware:

The upgrade options:

Testing methodology:

A simple intro to writing a lexer with Ragel.

Bootstrapping a prototype-based object-model in 44 lines of code.

Improving application throughput 9x with asynchronous responses in Rails 3

Ruby, shallow copy surprise!

Automatic content moderation with 'validates_text_content'

Ternary Quandry
