This is the Electric Boogaloo in my series on discovering the functional and sexy aspects of Javascript within Ruby. For those of you who haven’t read Part I of this series, you should check it out, because I’ll be relying on a few of those concepts in the following blog.

Today, I want to explore the concept of currying, and borrowing code from other functions (or even entire functions) to write DRYer, more compact and elegant code. Brace yourselves:

Javascript - All Types of Curry

Before we delve into the depths of ruby madness, let’s wrap our heads around the concept of what it exactly means to borrow functions, and how it works in Javascript.

Javascript has three separate methods that all allow you to bend functions to your will (and to your specific purpose): Bind, Apply and Call. They each have their own limitations and purpose, so let’s go one by one and pick apart how each of these methods work.

The Ties that Bind()

Chances are, you’ve actually seen a good amount of the function .bind(), it’s a very common way to deal with the “this” problem in Javascript. In short, .bind() allows you to dictate what “this” will refer to inside the function at the time the function is called. From this property alone, you can probably guess how this will allow us to start borrowing functions.

When functions are written vaguely enough, operating on objects using primarily the “this” keyword, they become fairly easy to bend. Let’s take a look at an example:

1
2
3
4
5
6
7
8
9

function Widgets(name, quantity, price) {
  this.name = name;
  this.quantity = quantity;
  this.price = price;
  this.costOfInventory = function(){
    var totalCost = this.quantity * this.price
    return "The cost of the entire inventory of " + this.name + " is $" + totalCost
  }
}

In the function constructor we just defined, we managed to design the function costOfInventory so that it does not take any arguments, and only operates on properties attached to an object, referred to as this. Now we can use this function to refer to any object that has similar structure. For instance:

1
2
3
4
5
6
7

var wonkyWicket = {
  name: "Wonky Wickets",
  quantity: 100
  price: 10
}

Widgets.costOfInventory().bind(wonkyWicket) // -> "The cost of the entire inventory of Wonky Wickets is $1000

This gets even more powerful when you consider Javascript’s support for first class functions:

1

wonkyWicket.costOfInventory = Widgets.costOfInventory().bind(wonkyWicket);

now wonkyWicket has effectively borrowed the costOfInventory function from the Widget constructor, and it can be called normally. BUT WAIT, there’s more! Bind can take additional arguments, and these arguments set default values for the arguments in function .bind() is being called on.

1
2
3
4
5
6

var fakeItem = {
  quantity: 100
  price: 10
}

Widgets.costOfInventory().bind(fakeItem, "Something AWESOME") // -> "The cost of the entire inventory of Something AWESOME is $1000

What the bind function is actually doing is creating a new function with default values in the place of the arguments that you defined in bind. This process is known as currying or partial function application. You substitute hard values for arguments, thus modifying the function.

Nuts right? And it gets even better when we start dealing with useful things like arrays and strings.

One important thing to note that will persist with us is that it’s not as simple as calling .bind(), there is a decent amount of prep involved. Being able to borrow or curry functions is something you have to think through from the beginning, almost like how a certain design principles have some upfront work, but make your life easier down the road.

I’m Call()in' you Out, Apply() Yourself!

The last two methods we are going to go over are .call() and .apply().

Truth be told, these functions are very similar to .bind() but there are a few key differences. Let’s start with the differences between .bind() and .call().

1
2
3
4
5
6
7
8
9
10
11
12

function saySomething(name){
  return this.greeting + name + ", you old dog you!"
}

var hello = {
  greeting: "HALLO "
}

var supChip = saySomething.bind(hello, "Chip")

saySomething.call(hello, "Duckie") //-> "HALLO Duckie, you old dog you!"
supChip() //-> "HALLO chip, you old dog you!"

Here we begin to see the difference between these two very similar methods. They both set “this” with their first argument and set subsequent arguments in the method with their next parameters. However, .bind() returns a new function, whereas .call() immediately evaluates the function it’s called on with it’s special parameters.

.apply() is more similar to .call() than .bind(). In fact, the only difference is in the way .apply() is called.

1
2
3
4
5
6
7
8
9
10

function saySomethingElse(name, color, location){
  return this.introduction + name + ". My favorite color is " + color + " and I'm from " + location
}

var intro = {
  introduction: "YOU GUYZ I'M "
}

saySomethingElse.call(intro, "Adam", "Aubergine", "Austria") //-> YOU GUYS I'M Adam. My favorite color is Aubergine and I'm from Austria
saySomethingElse.apply(intro, ["Benny","Burgundy","Belize"]) //-> YOU GUYS I'M Benny. My favorite color is Burgundy and I'm from Belize

As you can see, the arguments passed through .apply() must be passed in an array. This is useful for functions where the arguments being passed in are more flexible or optional.

A Ruby in the Rough

As we’ve spoken about before, Ruby can play functional with the big dogs, and as it’s evolved as a language, it’s gained even more functional properties. We’re going to explore a few ways of replicating this awesome functionality from Javascript.

Waddya Mean Modules?!

The first method of sharing methods between classes is one we are all pretty familiar with. A Module is a different type of object that can mix methods into another class. Much like binding this to a function, the Module and Class need to share certain functionality to begin with.

1
2
3
4
5
6
7
8
9

module Greetable
  def say_hi
    "HI #{self.name}"
  end

  def say_bye
    "BYE #{self.name}"
  end
end

As long as a class has a name attribute, it can easily become “Greetable” by using the following code:

1
2
3
4
5

class Person
  attr_accessor :name

  include Greetable
end

Now person has the methods #say_hi and #say_bye!

I won’t delve too far into Module functionality, since it’s pretty well covered, but this is a peek at how Ruby can share methods between classes. Much like Javascript leverages the “this” keyword to allow for code that is applicable in many scenarios, Ruby’s “self” keyword affords similar functionality in it’s Object Oriented design.

Call me Ruby?

Turns out that Ruby has it’s own version of .call() and unsurprisingly it’s strongly related to the Proc class. Any proc accepts a message of .call as a command to run the code inside the proc, so simply put, it’s a way of running a proc. Given that Procs don’t arity check (unless they are lambdas), this can be used to replicate some of the usefulness of .call() or .apply(). However, as of Ruby 1.9.3 there is one slightly more useful function.

Keep Calm and Curry On

Ruby gained full partial function application support when it added the .curry function. In 1.9.3 .curry could be called on any proc or lambda and it would return a new proc or lambda that had one of it’s arguments set with a specific parameter. If this functionality is still a bit fuzzy, ponder the following code.

1
2
3
4
5
6
7

do_math = lambda do |operator, x, y|
  a.send(operator, b)
end

do_math.(:+, 2, 3) #-> 5
do_math.(:*, 2, 3) #-> 6
do_math.(:-, 3, 2) #-> 1

This bit of metaprogramming is pretty straightforward, but we can break this down a bit further using #curry.

1
2
3
4
5
6
7

add = do_math.curry(:+)
add.(2,3) #-> 5
add.(10,5) #-> 15

subtract = do_math.curry(:-)
subtract.(4,2) #-> 2
subtract.(12,9) #-> 3

When we called #curry on #do_math we set the first argument (the operator) and store the resulting function in a new variable. We can even take this a step further.

1
2

increment = add.curry(1)
increment.(100) #-> 101

As you can see, the potential here to dry up code is enormous. If one designs their functions properly, one function is powerful enough to write plenty. However, the key word is “design”, it takes a lot of planning or refactoring in order to achieve this next level DRYness.

Final Note

As of Ruby 2.2.0 there is now a way to call curry on any method (instead of just on procs and lambdas). It looks something like this:

1
2
3
4
5
6

def say_hi(name)
  "Hi #{name}"
end

chet = method(:say_hi).curry("Chet")
chet.() #-> Hi Chet

If you’d like to read more, check out the documentation on 2.2.0’s method class - there is lot’s of other cool functional aspects there.

Resources

You know, because god knows I didn’t learn this on my own.

• Javascript is sexy
• Stackoverflow Answer
• Good blog on apply and bind
• How I even learned about Currying

Lastly, RUBY CURRY

As I’ve started learning Javascript, I’ve had alternating moments of progressively confusing rage, soul-encompassing “wat”, laced with moments of being genuinely impressed by Javascript’s functional elements. It’s like eating your least favorite ice cream flavor mixed with your favorite sprinkles.

However, as I’ve delved deeper into some of these features, I’ve been inspired to go back to Ruby and see which of these features have equivalents, and I’ve been pleasantly surprised to see that more than a few do.

In this first part, I want to explore how Ruby handles First-class Functions.

What is a First-class Function?

When a programming language is said to have First-class Functions, it’s a way of saying that the language allows for functions to be treated like objects, and passed back and forth as arguments.

So when we pass in a function as an argument in JS, or even get one back as a return value, we are exploiting this incredibly useful function of Javascript. As seen below:

1
2
3
4
5
6
7
8
9
10
11
12
13

function theOneWePass(){
  return "This is from the function passed in";
}

function theOneWeCall(theOneWePass){
  console.log(theOneWePass());
  return function(){
    return "and this is the function that was passed back";
  };
}

var thisHoldsAFunction = theOneWeCall(theOneWePass); // logs "This is from the function passed in"
thisHoldsAFunction(); //->"and this is the function that was passed back"

Strictly speaking, ruby does not support First-class Functions. Methods cannot be return values or held in variables. But methods are far from all Ruby uses to implement functions. And some of these functions have Javascript-y super powers.

Blocks and Yield

Nearly anyone who has touched Ruby is probably familiar with a block. It allows us to customize methods by passing in custom instructions that are executed somewhere within the method, using the yield keyword.

1
2
3
4
5
6
7
8
9

def some_method(array)
  array.each do |elem|
    yield(elem)
  end
end

some_method([1,2,3,4]) do |elem|
  puts (elem * 2)
end #-> 2, 4, 6, 8

In this example we are actually passing a block into a method twice, first when we call #some_method and next when we call the #each method. This is almost like passing a function as an argument, except we define the whole function, and instead of calling it by name, it gets called when we use the yield keyword. It’s pretty much a regular closure and it even has the coolest property of a closure, which is access to the scope in which it was defined.

1
2
3
4
5

x= 10

some_method([1,2,3,4]) do |elem|
  puts (elem * x)
end #-> 10, 20, 30, 40

But there is one important difference, we have to write out the function, we still are not assigning it to a variable.

However, there is a way we can do that!

Procs! Procs Everywhere!

A Proc is how ruby wraps a function into an object, and best of all, they can be defined and saved to variables! This means that they can be called at will with the .call method.

1
2
3
4
5
6
7
8
9
10
11
12
13

  def gen_exponential(factor)
    return Proc.new do |n|
      sum = n
      (factor-1).times do
        sum *= n
      end
      sum
    end
  end

  cuber = gen_exponential(3)
  cuber.call(3) #-> 27
  cuber.call(4) #-> 64

You can even pass that Proc back and forth into functions.

1
2
3
4
5
6
7
8
9
10
11
12
13

  [1,2,3,4].map do |elem|
    cuber.call(elem)
  end #-> [1,8,27,64]

  def cool_map(array, something_to_call)
    new_array = []
    array.each do |elem|
      new_array << something_to_call.call(elem)
    end
    new_array
  end

  cool_map([1,2,3,4], cuber)#-> [1,8,27,64]

So far so cool right?

So quick recap, both blocks and procs allow you to pass code into other methods. BUT, procs are objects, and blocks are not. Procs can be passed into methods as arguments, and can be called with the .call(), and blocks can only be passed by writing the whole block out, they must be called with the yield function, and each method can only have one block.

Now let’s go deeper

How Many Procs could a Proc Block Proc if we use the Unary Operator?

Let’s take a look at this piece of code.

1
2
3
4
5
6
7

def some_method(&block)
  block.class
end

some_method do

end #-> Proc

The first thing you should know, is that the ampersand is also known as the unary operator, and it’s a means of turning Blocks into Procs and visa versa. In the above example, it is used to turn the block into a proc, i.e. make it an object. Once it’s an object, we can call object methods on it, and see that it is actually a proc. The unary also works in the opposite direction, turning procs into blocks which can then be passed into methods that need a block.

1
2
3

putstuff = Proc.new{|thing| puts thing}

[1,2,3,4].each &putstuff #-> 1,2,3,4

This allows us to save methods in variables and pass them into blocks with relative ease. But there is one more step to consider when looking at how

Mary had a little Lambda

Now there is one more way in which Ruby supports first class functions: lambdas. Lambdas are actually a lot like procs, but almost a different “flavor”. Lambdas can be passed back and forth, and are called similarly to procs, but they are declared slightly differently, and have a few other important differences.

1
2
3
4
5
6
7
8
9
10

proc_town = Proc.new {}
lambda_ville = lambda {}

#they are the same class
proc_town.class #-> Proc
lambda_ville.class #-> Proc

#but if you look closer
proc_town #-> <Proc:0x007ff4b3d47510@(irb):59>
lambda_ville #-> <Proc:0x007ff4b3d37660@(irb):60 (lambda)>

There are two other key differences, which very much affect the way these are used.

Arity Checking

As we’ve seen with Javascript, sometimes languages do not care about whether the number of arguments you pass to a function match the number of arguments that function takes.

Similar to Javascript functions, Procs will not throw an argument error if they are passed a varying number of arguments, while Lambdas do enforce argument strictness (or in other words, they arity check). This makes procs a little dangerous, only in the sense that they will fail silently if you mess something up (like Javascript), but they are also more flexible.

Return of the Lambda

Procs and Lambdas differ in the way that they return values to where they are called. A Proc does not create it’s own “return scope”, meaning it almost becomes a part of the function that calls it. So if a Proc triggers the return keyword, it will short-circuit the rest of the method that called it.

1
2
3
4
5
6
7

def messing_with_procs
  foo = Proc.new {return "'nothing' is wrong!"}
  foo.call
  puts "Sometimes Proc's fail silently"
end

puts messing_with_procs #-> "'nothing' is wrong!"

Lambdas are different, they do create their own return scope, so if a lambda triggers the return keyword, it will exit the lambda code, but return to the method that called it.

1
2
3
4
5
6

def sweet_sweet_lambdas
  bar = lambda {return "Actually nothing is wrong"}
  puts bar.call + "because lambdas are so so sweet"
end

puts sweet_sweet_lambdas #-> "Actually nothing is wrong because lambdas are so so sweet"

Recap

So let’s recap, one of the cooler things about Javascript is that it supports First-class functions, which means passing functions to functions and having them return other functions (some of which also take and return functions). FUNCTIONS. Being passed back and forth. Forever.

Turns out, ruby ain’t no slouch. Though the traditional method of passing code to functions through blocks is pretty limited, we still have the options of procs and lambdas, which give ruby true support for First-class functions.

Resources

I took a lot of things from people smarter than I, here they are: Functional Programming Techniques With Ruby: Part II

JavaScript’s Apply, Call, and Bind Methods are Essential for JavaScript Professionals

Ruby Monk on Blocks Procs and Lambdas

What Is the Difference Between a Block, a Proc, and a Lambda in Ruby? (I actually think this is a former flatiron blog)

Ahh, my first foray into placing something on the real webs. I hope that one day I look back on this as a fond learning experience, with much nostalgia on how much I had ahead of me. But to be real, the path to that day seems as fraught and horrible as my path to getting this goddamn site up. To keep it brief, I not only suffered, but tortured my dog with many violent outbursts of fervent cussing.

Where to begin?

Let’s start with what Heroku is. The wikipedia definition is a cloud platform-as-a-service. In plain old english, it’s a way to host and serve your code online. Heroku is lots of web servers (called dynos) which are capable of holding your code, running it, and serving it to people who want to use it. It supports lots of different languages and frameworks, and can even provide you with any nuts and bolts your app might need (like security or databases). Up to a certain point, it’s free and a great way for us to deploy our websites in a professional, scalable manner.

Heroku’s Documentation

In short, the documentation is good. They do a great job of explaining, in a couple simple steps, how to get a rails app up and running with little to no effort.

Once you sign up for a Heroku account and download the toolkit you can upload an app with a few short command line requests:

$ heroku login

will bring up a field where you can enter the credentials for the account you created. Then, after navigating to repository of your app in your terminal, you can create a new app with the following command:

$ heroku create my_awesome_app

Now, all that’s left to do is deploy your code. Luckily, heroku integrates seamlessly with git, so if you have a repository ready, you can push your entire codebase up with:

$ git push heroku master

If it seems to good to be true, that’s because it is. The problem is, we are not using rails, we are using Sinatra - and on top of that, we’re using the Tyrion Lanister of databases - sqlite3. It’s totally functional, but it does not scale at all.

Development Vs. Production

Working with Sinatra and Heroku requires a lot of rejiggering. First off, you’re going to need a few more gems, and you are going to need to start to really demarcate the difference between your Development and Production environments. Right now, we’ve largely been working in what is considered Development environments.

An environment is the tier to which your code is deployed, or in short, where your code “lives”. The definition of a development environment is pretty loose, but in general it is an environment where code can be changed freely. No thought has to be given to making changes in the development environment because it’s usually isolated, or running on a single server or machine. In our case, our development environment is our computer.

However, now that we are considering serving our web application to other people, and hosting in on heroku where it can be accessed by just about anyone, we have to rethink what our code is. It is no longer this malleable hunk of clay that we can change at will. It needs to be stable, and a lot of thought needs to go into how and when it is changed. Heroku is a production environment, one where the code and application is publicly accessible, or actively serving it’s purpose.

In big companies, there are generally steps in between Development and Production (such as testing, quality assurance and staging), but for now let’s focus on these two. So what does this mean for us? It means we have to start thinking about what it means to push something up to production. It’s time to get serious.

Getting with the Postgres

According to heroku, SQLite3 is not a production-grade database. Their reasoning as sound, and can be read here if you are interested.

This means we are going to have to upgrade our databases. Postgres is fairly easy to get your hands on, it’s open source and readily available. You might already have it installed.

If you don’t you can do so by typing in:

brew install postgres

Now, we need to make sure that your postgres db launches automatically. There is a good guide here, which I’ll summarize quickly.

After you’ve gotten postgres installed via brew, open it up in your finder and make sure it’s running on your computer. Then you need to initialize your database, using the following command:

initdb /usr/local/var/postgres

You can continue following the instructions in order to get postgres to launch automatically, however, if you have it up and running right now, we can move on.

Sinatra, you sweet, sweet lightweight fool

This is where Sinatra falls short of Rails. Rails takes care of a lot of the plumbing for you, but in Sinatra, we are going to have to do it ourselves.

After including the ‘pg’ gem in our gemfile, we are going to need to create a database.yml file in your config folder, right next to environment.rb.

Here is a sample yaml file that serves as a decent template.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

default: &default
  adapter: postgresql
  pool: 5
  encoding: UTF8
  timeout: 5000
  port: 5432

development:
  <<: *default
  username: <%= ENV['PG_USER'] %>
  password: <%= ENV['PG_PASS'] %>
  database: db/my_db_development

test:
  <<: *default
  database: db/my_db_test

production:
  url: <%= ENV["DATABASE_URL"] %>

Two notes, the PG_USER and PG_PASS are environment variables that need to be set in your bash profile, thusly:

export PG_USER = 'flatiron' export PG_PASS = 'learnlovecode'

You know, for safety reasons.

Second, the last line in this file is important for working with Heroku. Heroku will give your app an ENV (short for environment) hash with some data. In that hash is the database url, and will be essential for connecting the instance of a postgres db that heroku provides with your app.

Now we need to make sure that your gem file is divided into a development group, and includes the proper postgres gems. You will also need to include the ‘pg’ gem, which will act as your adapter between active record and postgres - much like our sqlite3 gem has done up until now.

Heroku REALLY hates sqlite. Make sure you delete the sqlite3 gem from any mention in your gemfile. Also, go into your Gemfile.lock and delete any mentions of sqlite3 to remove any accidental dependencies (or just delete your Gemfile.lock). Make sure to run bundle install before you try to redeploy.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

source "https://rubygems.org"

ruby '2.2.3'
gem 'sinatra'
gem 'activerecord'
gem 'sinatra-activerecord'
gem 'sinatra-flash'
gem 'sinatra-redirect-with-flash'
gem 'rake'

#postgres!
gem 'postgresql'
gem 'pg'

group :development do
  gem 'pry'
  gem 'pry-nav'
  gem 'rspec'
  gem 'tux'
end

Next we move on to making the connection with active record. In your config/environment file, you will have to do some extra work to connect to postgres and make it compliant with Heroku. I took this piece of code from a great guide for getting Sinatra to work with Postgres and Heroku, so credit where credit is due.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

require 'bundler'
Bundler.require(:default, :development, :production)

configure :production, :development do
  db =  URI.parse(ENV['DATABASE_URL'] || 'postgres://localhost/[the name you gave your db in your yaml file]')
#  db =  'postgres://localhost/topofthemorning_development'

  ActiveRecord::Base.establish_connection(
    :adapter  => db.scheme == 'postgres' ? 'postgresql' : db.scheme,
    :host     => db.host,
    :username => db.user,
    :password => db.password,
    :database => db.path[1..-1],
    :encoding => 'UTF8'

  )
end

require_relative '../app/controllers/application_controller.rb'
require_all 'app/models'

require "open-uri"
require "json"

The fifth line of code sets the database connection. It first checks to see if it’s being served with a url (which we received from Heroku and assigned in our database.yml file), otherwise it uses the database we set up in our yml file.

As another note, make sure you name your local db on the other end of the || the same as you did in the database.yml file.

And that should do it! Your postgres db should be running locally just fine (really you should probably check). You can redeploy your app to heroku (with the git push heroku master command) and it should be up and running!

Keep in mind if your db has any data in it before, it will be gone now!

Full Disclosure

I did not get this far on my own at all. Seriously, as of first writing this, my shit still didn’t work. Thanks to help from some awesome people (thanks Sophie and Joe!), I’ve gotten it up and running.

However, that being said, I have a few pitfalls to avoid and few hints to give you so you can dodge the cesspit I found myself mired in for a few days.

1. When you make changes to your code, you need to push them up to git before you push them up to heroku. When you push to Heroku, it’s coming from your git repository, not your local files.
2. Postgres is a lot stricter on the ‘foreign key’ constraint. If you write your migrations with belongs_to relationships, and define foreign keys, make sure that the table already exists in a previous migration. Sqlite3 will let that shit slide, but postgres is a lot less forgiving.
3. Pry doesn’t work in your heroku! If you’re code is broken it is much harder to fix once in a production environment. SO - a solid tip is make sure your code is working before you deploy it.
4. So Pry doesn’t work, but you can still do some spot debugging by writing some rake tasks. For instance, if I want to see what’s going on in my environment db, I can write some rake tasks to display the contents of a few of my models.
5. Rake tasks are an awesome way to interact with your code in general once it’s in environment, having some tasks is a great way to do some maintenancy things, like clearing your db, or resetting a user, etc.
6. Make sure to set your public folder explicitly in your app controller! Otherwise, heroku will not serve your CSS, images, or any other files you link to your html from your public folder. Do so like this right in your application controller:

1

set :public_folder, File.join(root, "../../public")

That’s all I got guys, hopefully, once you tune in next time this will be further down the road. You know what they say, when you shoot for the stars and miss, at least you still have cat gifs:

While working on my last project, our main goal was solving one very difficult problem.

While ingesting around 1,000 articles a day, we needed to add some semblance of location data to each one of those articles. When we first launched, this was done by me. Manually. All. Goddamn. Day.

I would manually scan the article for some kind of address, or area (like 5th ave between 42nd and 43rd). We noticed that I was following very similar patterns - addresses are generally clean patterns, and areas often use the same prepositions over and over again. My partner figured that we could begin parsing these texts automatically with a series of rules.

Since I was not any kind of developer at the time, I was less involved with the coding of the solution, but one way I was able to chip in was in writing the logic of finding these phrases through something called Regex.

Regex stands for Regular Expressions, and is a very powerful tool used for identifying, matching and capturing certain patterns in text and strings.

We would write regular expressions to begin automatically filtering and flagging the articles we were pulling in for items that didn’t fit what we were doing, like sponsored advertising:

/sponsored/i

But more importantly, we wrote a series of expressions that would look for the prepositions connecting areas, or the patterns of addresses. Here are some of the finished products:

\b([0-9]+ (West|W|East|E|North|N|South|S) [0-9]+(st|nd|rd|th))\b

((East|West)? ?([0-9]+|[A-Z][a-z]+|first|second|third|[a-z]+th)(st|th|nd|rd)? ?(Road|road|rd|Rd|Street|street|St|st|Avenue|avenue|Ave|ave|Place|place|Pl|pl|Parkway|parkway|pk|Pkwy|pkwy|Drive|drive|Dr|dr|Boulevard|boulevard|Blvd|blvd|Way|way|Lane|lane|Ln|ln|Court|court|Plaza|plaza|Square|Terrace|terrace)) +(near|and|at) +(Avenue [A-Z])\b

But let’s not get ahead of ourselves. Let’s start with the basics of Regex.

How it works

At its most basic, regex is just writing expressions that try to match combinations of characters. Every string can be broken down into characters, so we should be able to codify some kind of logic that allows us to build up every combination we see in the real world. That’s what the regex engine does.

Ruby recognizes regular expressions when you offset them by two backslashes, or with %r()

/this is a regex expression/ %r(and this is to!)

and these expressions can be entered in String.#methods such as #Scan or #Split

Basic Rules

Regex recognizes all of our basic characters, so if you were to just type in a word it would match:

There are also modifiers that you can add to the end of expressions, such as “i”, which allows you to recognize any case:

![Case Capture Image]https://github.com/Aemrox/aemrox.github.io/blob/source/source/images/Case%20Match.png?raw=true

You can also capture ranges of characters. Capture any lower case character with the following syntax:

the little g modifier at the ends means it is global, and will match every instance across the string. If we were to remove it, it would only match the first instance.

Beyond basic characters, you can also match punctuation and white space by using escape characters:

The reason for needing the escape character is that there are special characters which denote larger sets, such as the “.” which matches any character

There are also some special characters that regex uses to look at more complex concepts, such as words characters \w for words!

You can also do the same for digits with \d

Capture Groups

Everything we have been doing so far has been restricted to matching a single phrase. However, regex has a lot more potential than just that. You can instruct an expression to group certain matches, or even break down a phrase by using what are called capture groups.

These are particularly useful when using a string method like #scan, which utlizes these groups and places them as separate entries in an array.

You create a group by placing a parenthessis around what you are looking to capture. a parenthesis captures only an entire phrase.

However, you can also define a capture group with brackets, which will match any character in the group.

These kinds of expressions are excellent for splitting up strings. The following piece of code does a decent job of splitting up strings by sentences. See if you can decipher the regex!

“Check out my sentence! Here’s another. And another?”.split(/[.!?]/)

Quantifiers

Unless otherwise specified - most capture groups will capture each instance of a match as an individual capture. However, we can use several quantifiers to modify how capture groups behave and give them more (or less) flexibility

If we look back at our expression to split strings, it works pretty well, but fails if we have two periods in a row:

string = "This. should. split well... but it doesnt!!".split(/[.!?]/) # => ["This", " should", " split", "", " but it doesnt"]

This doesn’t do exactly what we want because the capture group is matching each occurrence of the expression. We can fix this with the + quantifier. The + quantifier can be appended to a capture group to make it match 1 or more occurrences of the expression. This will chain all occurrences of the capture group that occur side by side into one capture. So we can fix our code like this:

"This. should. split well... and it does!!!".split(/[.!?]+/) # => ["This", " should", " split well", " and it does"]

Another excellent modifier is the * or splat. When placed inside a capture group, it takes the preceeding token, and tells regex to match as many of these as possible.

One more modifier that I think is really good to go over is the ?. It is called the optional modifier. What it means is capture 0 or 1 of the preceding token. Here it is in action:

However, ? can also mean lazy, which we’ll dive into below.

Greedy Vs. Lazy

This is one of the tougher concepts to grasp in Regex, at least for me, so I’m going to do my best to explain it.

the * quantifier is called the “greedy” quantifier. It will take as many characters as necessary to create a capture group. To understand this, look at the following string.

“You are becoming quite skilled, young grasshopper,” said Steven with glowing admiration in his eyes. “quite skilled indeed.”

If I wanted a regex expression to match “anything between the quotes” - it actually has several groups it could capture. It could do both traditional quotes (as we see them), it could take the inverse, which is the area between the 2nd and 3rd quotation mark, or it could take the whole sentence.

So a * tells regex, take as many characters as possible, or, be greedy.

This is best displayed below:

This doesn’t get us all the text in quotations as we see them. B ecause we placed a * quantifier, it matches as many characters as possible.

if ? is used on another quantifier, it can be made to make the group “lazy” or match as few characters as possible to make the capture effective. This is a bit of a mental leap, so just look at it in action below.

There are a ton of amazing things regex can do, way too much to go over in one blog post. But hopefully this gives you guys a good start, and if this sparked your interest, keep reading for a few great resources to learn more on your own!

http://regexr.com/ - how I did some of the images

http://rubular.com/ - the right tool to use to build regex for Ruby, uses the same engine.

http://regexone.com/ - a great tutorial that Kaylee found! Thanks Kaylee.

https://regex101.com/ - from Derek. Thanks Derek…

http://www.rexegg.com/ - for those of you looking to master the whole thing and see how far down the rabbit whole you can go.

“Sup party people”