Migrating in Phoenix

Phoenix Migration

This is part of the series on Phoenix, taking you from noob to !noob. Here are the list of posts so far:

1. Intro
2. Scaffolding

Today we will look at the migration file that's produced from the scaffolding we performed last time.

Migration File

defmodule PhoenixLibrary.Repo.Migrations.CreateBook do
  use Ecto.Migration

  def change do
    create table(:books) do
      add :title, :string
      add :author, :string
      add :description, :text

      timestamps()
    end

  end
end

At the end of generating the scaffold, we created the file above - priv/repo/migrations/20161014160805_create_book.exs. We are going to take a quick look at it and figure out what it's doing.

In the Rails world, we would have gotten a file like this:

class CreateBooks < ActiveRecord::Migration[5.0]
  def change
    create_table :books do |t|
      t.string :title
      t.string :author
      t.text :description

      t.timestamps
    end
  end
end

What's great is that the same basic thing that we are doing in Rails we are doing in Phoenix. In the Rails version we are creating a class to capture us creating a new books table and in the Phoenix version, we aren't creating a class, but instead creating a module.

In the Rails world, we are extending from ActiveRecord, but in Phoenix we are using helpers from Ecto.Migration. The important method that we are defining is the `change` method. This allows us to go forwards or backwards in our migration, to either create or tear down the table.

# Rails is rake db:migrate
mix ecto.migrate         # Runs migrations up on a repo

# Rails is rake db:rollback
mix ecto.rollback        # Reverts migrations down on a repo

The change method in both worlds take two arguments, a symbol representing the table we are going to create and a block where we create the actual columns in the table. In Rails we get a helper object that we can use to call functions where as in Phoenix we don't have/need a helper and can just call the add function passing in the name of the column and the type. And of course in Phoenix we call the timestamps function to create the created_at and updated_at column. But, in Rails we call the timestamps method on the helper.

In the future, we will dig into the models that are created from the scaffold command.

Phoenix Scaffolding

Phoenix, Let's Build

Welcome to the second installment of our Phoenix walkthrough. Last time we set up Phoenix, our database and saw our default 'Welcome' page for our dummy library application.

This week we will use some more generators and create our first model, views, and controller. Since this will be a library application, the most obvious choice of our first model should be a `book`.

Generate Scaffold

# mix [generator name] [model name] [table name] [attribute name : attribute type]
mix phoenix.gen.html Book books title:string author:string description:text

# in rails we do
#   rails generate scaffold Book title:string author:string description:text

There are a few key differences between the two, although they are very similar:

• mix: it's the rake/rails of the elixir world.
• phoenix.gen.html: this is the generator to use. remember that generators are just ordinary elixir scripts. also notice the `html` suffix which uses the script to generate html (as opposed to json -> phoenix.gen.json).
• Book: this is the model name. notice the upper case. all models are uppercased.
• books: this is an interesting distinction vs the rails world. WE NAME THE TABLE OURSELVES.
  in rails the name of the table is automatically made to be the pluralized name of the model, like Book (model name) -> books (table name).
  but English is a quirky language and you cannot always just add `s` to the end of the word, like child to children. so there is some complication in how rails needs to figure out to pluralize you model name.
  this is the first example of some bloat that Phoenix does away with, instead of trying to figure out how to pluralize your model name, Phoenix just defers to you, the developer, to name the table.
• attributes: this is exactly the same as rails. except in Phoenix, if we omit the type, it defaults to `string`.

➜  phoenix_library git:(master) mix phoenix.gen.html Book books title author description:text

* creating web/controllers/book_controller.ex
* creating web/templates/book/edit.html.eex
* creating web/templates/book/form.html.eex
* creating web/templates/book/index.html.eex
* creating web/templates/book/new.html.eex
* creating web/templates/book/show.html.eex
* creating web/views/book_view.ex
* creating test/controllers/book_controller_test.exs
* creating web/models/book.ex
* creating test/models/book_test.exs
* creating priv/repo/migrations/20161014160805_create_book.exs

Add the resource to your browser scope in web/router.ex:

    resources "/books", BookController

Remember to update your repository by running migrations:

    $ mix ecto.migrate

Look at all the nice things that are generated. This is very similar to scaffold generation. You can see theres:

• controller: book_controller
• templates: index, show, new, edit, form
• views: book_view
• model: book
• tests: book_controller, book
• migration

We will eventually tackle them all, but not right now. Let's go ahead and follow the prompts. Open up web/router.ex and add in the new route to our books resource. Notice this distinction from Rails also. In Rails, this is done for you.

  scope "/", PhoenixLibrary do
    pipe_through :browser # Use the default browser stack

    get "/", PageController, :index

    # added this line here
    resources "/books", BookController
  end

Next run `rake db:migrate`...I mean `mix ecto.migrate`. :)

➜  phoenix_library git:(master) ✗ mix ecto.migrate
Compiling 9 files (.ex)
Generated phoenix_library app

04:42:58.436 [info]  == Running PhoenixLibrary.Repo.Migrations.CreateBook.change/0 forward

04:42:58.436 [info]  create table books

04:42:58.456 [info]  == Migrated in 0.0s

Now start the server and check out your changes!

➜  phoenix_library git:(master) ✗ mix phoenix.server
Compiling 8 files (.ex)
[info] Running PhoenixLibrary.Endpoint with Cowboy using http://localhost:4000
21 Oct 04:46:52 - info: compiled 6 files into 2 files, copied 3 in 2.1 sec

Don't forget to hit the new route -> http://localhost:4000/books. Alright, that's it for now. Next time we'll talk about the model and migration.

The Rise of the Phoenix

Phoenix For the Rails People

I've been doing Rails for a long while now. Before Rails I was doing Enterprise Java but then my mentor at the time showed me this cool framework that took convention over configuration seriously and allowed really powerful things to be built quickly and easily. I was amazed and have been using tools like this ever since.

But the big argument against Rails is that it doesn't scale and is a bit bloated. Also there is a bit of a shift towards using more functional approaches. Enter my fascination with Elixir and Phoenix.

The next series of posts will be all about me learning Phoenix, but with a slant towards comparing and contrasting it against Rails. So strap in and take the journey with me.

I learn by doing, so I'll be building my normal 'hello world' type application, which is a library application. I used to spend a lot of time in libraries as a kid so I think thats the reason my default application is usually an application to track and catalog books. So let's get started.

Prerequisites

Before getting started, you will need to install a few things. I'll assume you are on mac and have homebrew installed. First is postgres.

brew update
brew install postgres
createuser -P -s -e root
# then setup your root user or whatever you want your user to be called

Next install Elixir and mix.

brew install elixir 
mix local.hex

Now install Phoenix.

mix archive.install https://github.com/phoenixframework/archives/raw/master/phoenix_new.ez

Now we are ready to start building our app.

New Application

We will start first by creating the application. In rails we'd do something like:

rails new rails_library --database=postgresql

but in Phoenix we do:

mix phoenix.new phoenix_library

First thing to note here is `mix`, which is Elixir's build tool. Already a little different than the rails command. Also notice we run `phoenix.new` which really is nothing more than just a script that we run with mix. Lastly we pass it the name of the new project. Also notice that postgres is the default, so we don't have to tell it that we will be using it.

This command created a bunch of folders full of stuff, which we will get to as we need....which is right now. :) Open up the `dev.exs` file in the config dir and modify it as necessary to use the correct username and password to connect to your locally running postgres instance. Go ahead and do that for the `test.exs` file as well.

With that done, we can set up your db schemas by running:

mix ecto.create

# in rails we would do `rake db:create`

Very similar to rails, but instead of the rake command we use our Elixir build tool called mix, and we run the ecto.create script. Ecto is the database wrapper, so we will be seeing `Ecto` a lot.

The last thing we will do in our very gentle intro is to start the Phoenix server.

mix phoenix.server

# in rails we would do `rails server`

Then navigate to localhost:4000 and you will see the dummy page.

Next time we will be creating some models, views, and controllers. Until then!

Elixir Destructuring

Break it all apart

Welcome to the fourth installment of our work with Strings. As usual here's a reminder of the original problem we were trying to solve:

take_prefix.("Mr. John", "Mr. ")
# returns 'John'

We want to be able to chop off some prefix and return the suffix of a string.

So far we've come up with three implementations, each one improving upon each other. Our initial implementation:

# slow bc of multiple String.lengths
take_prefix = fn full, prefix ->
  base = String.length(prefix)
  String.slice(full, base, String.length(full) - base)
end

IO.puts take_prefix.("Mr. John", "Mr. ")

The second implementation used ranges:

# replace one of our slow length call with a range
take_prefix = fn full, prefix ->
  base = String.length(prefix)
  String.slice(full, base..-1)
end

IO.puts take_prefix.("Mr. John", "Mr. ")

The third implementation used binary functions due to their constant speed regardless of the size of the given string.

take_prefix = fn full, prefix ->
  base = byte_size(prefix)
  binary_part(full, base, byte_size(full) - base)
end

IO.puts take_prefix.("Mr. John", "Mr. ")

The final improvement is really more aesthetics. We can make this solution a bit more functional and feel more Elixir-y by using a concept known as destructuring.

Destructuring is a way of taking a complicated data structure and breaking it apart into simplier components. Quick example:

[a, b, c] = [1, 2, 3]
# a now has the value 1
# b now has the value 2
# c now has the value 3

In this example, we took the array holding three numbers and broke it apart into it's separate elements. This is destructuring in a nutshell. Taking something and breaking it apart.

Here's another example using tuples (a data structure holding elements that are contiguous in memory).

{status, status_message} = {:ok, "Success"}

Sometimes our complex object that we want to break apart has information we don't care about. You might think you could do something like this:

# this will not work!
{status, status_message} = {:ok, "Success", "Junk"}
#** (MatchError) no match of right hand side value: {:ok, "Success", "Junk"}

Elixir thinks you messed up, so you have to be very explicit in telling it that you don't care about the last match. You do this by using an underscore.

{status, status_message, _} = {:ok, "Success", "Junk"}

Now this will work. Alright, I think we have all the tools we need to understand the final solution.

take_prefix = fn full, prefix ->
  base = byte_size(prefix)
  # this is the destructuring
  <<_::binary-size(base), rest::binary>> = full
  rest
end

IO.puts take_prefix.("Mr. John", "Mr. ")

Here we are destructuring the full string into two binary components. The << and >> signify that this is a binary data structure, in this case with two elements. The first element will contain a binary string that is the binary size of the prefix and the second element is the rest of the string. Let's get into a bit more detail.

Remember what we saw last week, a String is just a binary string in disguise. So what we are doing here is figuring out the number of bytes used in the prefix (so we know how much to chop off). Then we destructure the full string into two binary parts. The first binary part is the number of bytes that we calculated before (but now represented as the size in binary due to us wanting to destructure this into a binary data structure). And the second part is the actual string that we want to return, represented as a binary data structure. But as we saw last week, a String is just a UTF-8 encoded binary so returning this is just fine.

Destructuring is a powerful technique and is very useful in producing short and concise code. Elixir is not the only language that has this feature. ECMAScript 2016 has it as well.

With that, this concludes our multi-post demonstration on a simple problem I found from the Elixir docs, and how they were able to iterate through a few solutions until the settled on their favorite implementation. I felt like their explanation didn't go into enough detail, which is why we've been looking at each a bit more closely these past few weeks. Hopefully you learned something and had fun while doing it.

Next week, we'll discover and discuss a new topic that I haven't yet decided on yet :)

Getting Faster By Going Deeper

Elixir Code Points

This week is the third installment of our look at Strings. As a quick reminder, we tried to implement a function that chops off a prefix from a string.

take_prefix.("Mr. John", "Mr. ")
# returns 'John'

So far we've come up with two implementations, the second improving on the first. Our initial implementation:

# slow bc of multiple String.lengths
take_prefix = fn full, prefix ->
  base = String.length(prefix)
  String.slice(full, base, String.length(full) - base)
end

IO.puts take_prefix.("Mr. John", "Mr. ")

The second implementation used ranges:

# replace one of our slow length call with a range
take_prefix = fn full, prefix ->
  base = String.length(prefix)
  String.slice(full, base..-1)
end

IO.puts take_prefix.("Mr. John", "Mr. ")

The next improvement is to not even use String functions at all! Wait, what? How can you do that? What would you use??

To answer this, we have to see how Strings are represented. Everything in computers essentially boil down to 0's and 1's; we call these bits. If you put 8 of these together, you get a byte. With 8 bits put together, and each digit representing 2^n, where n is the number of positions from the far right, you can represent 0 to 255. So with 255 numbers, you just represent each letter with a number. For example, we use the number 97 to represent the small letter `a`. Another way to say this is that the small letter `a` has code point 97. This mapping is called the character encoding and Elixir uses UTF-8.

Problem is we have more than 255 characters that we want to represent, like letters with accent marks, or non-latin characters like Chinese. This means we need more numbers, which means we need more bytes. Let's look at an example using iex, the interactive elixir repl.

# `?` shows us the code point
iex> ?a
97

iex> ?ł
322

The small `a` is less than 255, which means we only need one byte to represent it. But the letter `ł` is over 255, and actually will require 2 bytes to represent 322. We can check double check this to see we are right.

iex> byte_size("a") 
1

iex> byte_size("ł") 
2

We can go even further and force Elixir to spit out it's binary representation by using a trick where we concatenate a null byte `<<0>>` to the string.

iex> "a" <> <<0>>
<<97, 0>>

iex> "ł" <> <<0>>
<<197, 130, 0>>

iex> "ał" <> <<0>>
<<97, 197, 130, 0>>

We can see that the small letter `a` only needs one byte to show 97, but `ł` needs more than one byte. So Elixir splits up the 2 bytes into two different and separate bytes and then represents each byte with it's own number. This is why we get 197 and 130 to show the 322 that really is the letter `ł`.

All this that we covered is really just to say that any letter will always be between 1 to 4 COMPLETE bytes. Elixir will never use a fraction of a byte to represent a letter. We can take advantage of this and use Elixir byte functions, which are WAY faster than Elixir String functions.

There is one more caveat, we have to make absolutely sure that whatever byte functions we use, we never chop in between code points. We don't want to chop `ł` into two separate bytes because then it won't be `ł` anymore, you need both bytes to represent this letter. Let's see our new solution:

take_prefix = fn full, prefix ->
  base = byte_size(prefix)
  binary_part(full, base, byte_size(full) - base)
end

IO.puts take_prefix.("Mr. John", "Mr. ")

Instead of `String.length` we used `byte_size`. The `String.length` function as you recall gets more expensive the longer the string is, but the latter `byte_size` always runs in constant time, regardless of the input size. This is great! Similar improvements are also gained by using `binary_part` instead of `String.slice`.

This is a good example of how understanding how something works under the covers allows you to employ some neat tricks. This is a valuable bit of insight that you will see often and should employ yourself. Whenever possible, think about replacing String functions with low level byte functions, you will get nice performance gains.

Next week we will use perform our final enhancement to this solution and wrap up our series on Elixir Strings.

Home Home on the Elixir Range

Elixir Ranges

Last week we were digging around the Elixir docs and had some fun with strings. As a reminder, we tried to implement a function that chops off a prefix from a string. Something like this:

take_prefix.("Mr. John", "Mr. ")
# returns 'John'

We saw our initial implementation:

take_prefix = fn full, prefix ->
  base = String.length(prefix)
  String.slice(full, base, String.length(full) - base)
end

IO.puts take_prefix.("Mr. John", "Mr. ")

But one big problem were the multiple calls to

String.length

which as we saw last week, does a full traversal of the string. As per the Elixir docs, the first improvement they perform is replacing

String.slice(full, base, String.length(full) - base)

with

String.slice(full, base..-1)

Let's look at this a bit. What are those dots in the second argument? This is something called a range. From the docs, a range is:

A range represents a discrete number of values 
where the first and last values are integers.

Ranges can be either increasing (first <= last)
or decreasing (first > last). Ranges are also always inclusive.

Let's take an example to help illustrate this:

range = 1..5

The `range` variable holds 5 numbers (1, 2, 3, 4, 5). That's it! It's just a collection of sequential numbers. Now let's check the docs on the new slice method:

slice(string, range)

#Returns a substring from the offset given by the
#start of the range to the offset given by the end
#of the range

So our call to slice

# As we saw last week, base is 4
# base = String.length(prefix)
String.slice(full, base..-1)

really is:

String.slice("Mr. John", 4..-1)

This function takes the string starting at the 4th letter and goes to the first letter counting backwards.

To say this another way, it's saying to take the string starting from the 4th letter up to and including the last letter.

Again, the advantage of using the range is that we save having to do the `String.length` call in the Slice method that we did last week.

Ranges are fun and come in quite handy. One more quick example with Ranges

println = fn x ->
  IO.puts x
end

Enum.each 1..5, println
Enum.each [1, 2, 3, 4, 5], println

Both of the last two lines will print out the numbers 1 through 5. The first one does so using a range and the second one uses a list of numbers.

That's it this week on the second improvement to our `take_prefix` method. Next week we will look at the next improvement that we can make to this method. As a teaser, it will involve us knowing how strings are represented. Until then!

Elixir Prefix by Suffix

Elixir Strings

I was reading through the Elixir docs and found some interesting code snippets in the `String` section. The example was how we could implement a function that returns the ending of a string.

So in other words, we want a function like this:

take_prefix.("Mr. John", "Mr. ")
# returns 'John'

The docs actually show a few solutions, gradually iterating on each, improving it slowly. I really liked how they did it, but thought that each solution could use a bit more detail.

This post will take the first naive solution and talk about it. This solution is probably the most intuitive, so is a nice way to ease into Elixir strings.

Solution

take_prefix = fn full, prefix ->
  base = String.length(prefix)
  String.slice(full, base, String.length(full) - base)
end

IO.puts take_prefix.("Mr. John", "Mr. ")

Let's jump right in.

First line

take_prefix = fn full, prefix ->

The first line declares the function. We want a function that takes in two parameters, the full/entire string, and the prefix that we want chopped off.

Second line

base = String.length(prefix)

This line figures out how long the prefix string is. There is something to note here, and that this function `String.length` needs to traverse the entire string in order to figure out it's length. The reason for this is that some letters are made up of two characters, but are perceived by humans as one.

One example is this letter:

# é
iex> String.codepoints("é")
["e", "́"]

Two characters used to represent one. So the `String.length` function has no choice but to traverse the entire string to check for weird conditions like this. As a result, as the string gets longer, this function call takes longer to complete as it has more characters to check.

Third line

String.slice(full, base, String.length(full) - base)

The next line is a bit compact, but let's dig in and see if we can't unpack it.

Let's start inside and go out.

String.length(full) - base

We saw the first part before. But now we are taking the length of the full/entire string. And from that we are subtracting out the length of the prefix.

So from our example, the length of our full string is ("Mr. John") is 8, and the length of the prefix ("Mr.  ") is 4. Simple subtraction (8-4) and we have 4.

Our call really then is:

String.slice(full, 4, 4)

Looking up the docs for that:

slice(string, start, len)
Returns a substring starting at the offset start, and of length len

In plain English, this method says, "take the string Mr. John and starting at the 4th element (0 based), give me back a string 4 characters long".

Fourth line

IO.puts take_prefix.("Mr. John", "Mr. ")

And the last line shows the invocation of the method and the write to the console.

Tada. But as you may have noticed, this method is expensive, mainly due to the two length calls we have. And then we have an additional slice call that has to yet again traverse the string in order to give us the substring. For short strings, this solution is no problem. But when you get longer strings, this method will not be so great. There are ways we can improve on this, which we will take a look at next time.

First Sip of Elixir and Beer

Trying out Elixir

I've always been meaning to try out some Elixir but wasn't until I chatted a bit with José Valim about it until my curiosity was really piqued. I love the idea of embracing failure and not worry about catching and trying to handle exceptional cases. After all, this is what exceptions are, exceptional things. Just let the process die and rely on the framework to spin another one up. Beautiful! Additionally, add in the fact that it's a functional language, really makes it shine. Pattern matching and data transformation are so nice. Today I'll talk a bit about how to get started with Elixir and a bit about building a command line program. I chose to solve the "99 bottles of beer" problem, which is essentially just to print out the lyrics to the 99 bottles of beer song.

First installation of Elixir and project setup.

  # install Elixir, mac specific instructions
  brew install Elixir
  
  # create a new project, I named it elixir_99_bottles
  mix new elixir_99_bottles

Now a bit of setup to turn this into a command line tool. First open up mix.exs.

# A defmodule is sort of like a `class` in the object oriented world.
# But since this is a functional language, this is really more like a
# collection of related functions.
defmodule Elixir99Bottles.Mixfile do
  use Mix.Project
  ...

  # add the escript line.  
  # this tells elixir that this is a command line tool.
  # and that to invoke it, the escript_config method must be called
  def project do
    [app: :elixir_99_bottles,
     version: "0.1.0",
     elixir: "~> 1.3",
     build_embedded: Mix.env == :prod,
     start_permanent: Mix.env == :prod,
     escript: escript_config,
     deps: deps()]
  end

  ...

  # Notice that it's defp - meaning its a private function.
  # Compare that with def, which means a public function.
  defp escript_config do
    [main_module: Elixir99Bottles]
  end

end

Next bit of magic, go to lib/elixir_99_bottles.ex. Here you need to add a special main method that will serve as the entry point.

defmodule Elixir99Bottles do

  # entry point
  def main(args) do
    # args is a list, so we grab the first element and "set" that into string_val
    # if there are no args, we set string_val to 99
    string_val = List.first(args) || "99"

    # we want an integer, so we parse it.
    # the return is actually a tuple, which is a nice set of numbers.  
    # kind of like how x and y coordinates on a map make a nice tuple.
    # a tuple is a finite list of things that all logically belong together
    # the return tuple here is actually the { parsed integer, remained after parsing }.
    # but since we are using base 10, all our integers will parse nicely
    # `start` will be set to the parsed integer
    {start, _} = Integer.parse(string_val)

    # loop over the entered `start` value down to 1, i will be the iterator
    for i <- start..1
      do 
        IO.puts format i
      end
  end
  
  # when the num argument is 1, call this function and return this interpolated string
  defp format(num) when num == 1 do
    line_one = "#{num} bottle of beer on the wall, #{num} bottle of beer.\n"
    line_two = "Go to the store and buy some more, 99 bottles of beer on the wall."
    line_one <> line_two
  end

  # when the num argument is more than 1, call this function and return this interpolated string
  defp format(num) when num > 1 do
    line_one = "#{num} bottles of beer on the wall, #{num} bottles of beer.\n"
    line_two = "Take one down and pass it around, #{num-1} bottles of beer on the wall.\n"
    line_one <> line_two
  end

end

Now lastly we add some tests. Open up test/elixir_99_bottles_test.exs.

defmodule Elixir99BottlesTest do
  use ExUnit.Case
  doctest Elixir99Bottles

  # this import allows us to capture and compare things printed to standard out
  import ExUnit.CaptureIO

  # first test is when we have an input of 1.
  # notice we call our class with a list of "1" and compare that with our output
  # """ -> this is a heredoc where you can create multiline strings.  
  # """ starts and ends the multiline string.
  test "1 line" do
    assert capture_io(fn ->
      Elixir99Bottles.main(["1"])
    end) == """
    1 bottle of beer on the wall, 1 bottle of beer.
    Go to the store and buy some more, 99 bottles of beer on the wall.
    """
  end

  # first test is when we have an input of 2.
  # notice we call our class with a list of "2" and compare that with our output
  test "more than 1 line" do
    assert capture_io(fn ->
      Elixir99Bottles.main(["2"])
    end) == """
    2 bottles of beer on the wall, 2 bottles of beer.
    Take one down and pass it around, 1 bottles of beer on the wall.\n
    1 bottle of beer on the wall, 1 bottle of beer.
    Go to the store and buy some more, 99 bottles of beer on the wall.
    """
  end
end

Now, time to run it all!

  # compile the code
  mix escript.build

  # run it.  defaults to 99
  ./elixir_99_bottles 

  # run it for 50 beers
  ./elixir_99_bottles 50

  # run the tests
  mix test

Boom! A very simple demonstration of using mix to create an Elixir project complete with tests. Check out the code here:
https://github.com/jkeam/elixir_99_bottles

Syntax Highlighting

Blog Enhancements

I've been rocking Alex Gorbatchev's syntax highlighter for a while on this blog, and it I really liked it.  It was quick and easy to use and at the time but lately, and for the past few years, I've really been into darker themes.  The syntax highlighter didn't appeal to me anymore and I didn't particularly like the themes they had.  So I searched around and stumbled upon Prism.  I like the way Prism looks and I found the installation super simple.  Take a look below at a code sample:

  var bubbleSort = function(unsorted) {
    for (var i = 0; i < unsorted.length; i++) {
      var swapped = false;
      for (var j = i + 1; j < unsorted.length; j++) {
        if (unsorted[i] > unsorted[j]) {
          var tmp = unsorted[j];
          unsorted[j] = unsorted[i];
          unsorted[i] = tmp;

          swapped = true;
        }
      }
      if (!swapped) {
        return unsorted;
      }
    }
    return unsorted;
  };

If you too want syntax highlighting like this, this is how!

Instructions

1. Include the theme stylesheet

   
         <head>
           <link href="https://cdnjs.cloudflare.com/ajax/libs/prism/1.4.1/themes/prism-okaidia.min.css" rel="stylesheet" type="text/css"></link>
         </head>
       

2. Include the prism javascript file and all the languages you want highlighted, say you wanted support for ruby

   
         <body>
           ...
           <script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.4.1/prism.min.js"></script>
           <script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.4.1/prism-ruby.min.js"></script>
         </body>
       

3. Wrap your code that you want highlighted

    
     <pre><code class="language-ruby">
       puts 'hi' 
     </code></pre>
     

4. Done! You should get something like the following:

    
       puts 'hi'
     

Extra

For more information, definitely check out their site http://prismjs.com/.
And once you find the theme you like and language you want highlighted, stop over here for a nice cdn that will serve up the javascript and css's that you need https://cdnjs.com/libraries/prism.

Arrow Functions

I love the new arrow function in EcmaScript 6.  I use it for everything, pretty much all the time :)

Quick Rundown

Basic Form

var add = (numberOne, numberTwo) => {
  return numberOne + numberTwo;
};
add(1, 2);
//returns 3

Here I'm creating a function named add that takes two parameters, numberOne and numberTwo.  This function will return the two numbers added together.  When the body of the function is a single expression, we can write this even more concisely.

var add = (numberOne, numberTwo) => numberOne + numberTwo;

At first glance, this looks just like a different syntax for creating a function.  But there's more to it than that.  Inside of the arrow function, there is no new 'this' pointer defined.

Let's look at an example (taken from MSDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions):

function Person() {
  var self = this; // Some choose `that` instead of `self`.
                   // Choose one and be consistent.
  self.age = 0;

  setInterval(function growUp() {

    // The callback refers to the `self` variable of which

    // the value is the expected object.

    self.age++;

  }, 1000);

}

Notice the strange self variable we had to create in order to access age.  This is because the function growUp gets a brand new 'this' pointer that is quite different than the 'this' pointer inside of Person.  That means that when growUp is called, calling this.age will not work, because there is no 'age' variable inside of the growUp function.  The new fat arrow fixes this:

function Person(){
  this.age = 0;

  setInterval(() => {
    this.age++; // |this| properly refers to the person object
  }, 1000);
}

Notice that 'this' can correctly find and use the age variable.  This is very nice and just feels much better overall.

Gotchas

1.  Returning an object literal needs to be wrapped in parens.

const gimmeFoo = () => {  foo: 1  };
//will not work!  calling gimmeFoo() returns undefined

instead do this:

const gimmeFoo = () => ({  foo: 1  }); 

2.  You also cannot override the 'this' inside of an arrow function.  That means that bind is useless here, so don't try it.  Same thing for call and apply.  You can still pass in arguments, but you cannot override 'this'.

3.  You also don't have access to the 'arguments' variable, but a good workaround is to use rest parameters (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters), which we won't cover here.

var f = (...args) => args[0];

4.  Even if you don't have arguments, you still need the parens:

const gimmeHi = () => 'hi';

but you can also do this:

const gimmeHi = _ => 'hi';

That's pretty much it! Go forth and start using it :)

A Docker Movie - Starring Chris Pratt

Ships Ahoy

Lately I've been mucking around with a lot of Docker.  If you are unfamiliar, Docker provides a new approach to deploying software.  Prior to Docker, you had to install all of the libs and dependencies yourself manually on the target machine. But with Docker, you assemble containers that together all make up your application.

Think of it like Lego blocks.  You have a block for, let's say Ruby.  And you have a Lego block for Rails, and another Lego block for your database, say Postgres.  And you put all these blocks together and you have your entire app.  So you don't think of installing servers and language runtimes, you instead think of deploying containers (Lego blocks) that all work with each other.  I would imagine that Chris Pratt could play Ruby in this particular movie.  From the Docker website:

"Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in."

A Docker container for Ruby is completely self contained and works by itself.  A Docker container for a Postgres database is completely self contained and works by itself.  Or you could have them both running at the same time and poof they can work together.  And a Docker container is super easy to run.  You simply pull down the image of a container from a repository (typically DockerHub), then run it.  Done.

Let's take a very simple example.  I've been working recently with a design team that was building a prototype with static html, css and javascript.  They had all their code locally and was zipping them up to me so I could open them up on my computer and view them.  But this process was slow and it was very manual.  No one could see the code except whoever they sent the zip to and I always had to bother them for the latest stuff.  I wanted to be less turtle and more cat with my process.

My first thought was to standup an sftp server somewhere that they could copy files to that would then be served up by nginx or something.  That approach is fine but required me to setup an sftp server and nginx and then configure both.  It also required the design team to periodically upload the files so that I could view them.  Things still felt very manual, and I was feeling lazy.  If you guessed my ultimate solution involved Docker, you are correct :)  The instructions below assume you have docker installed already.  I am running ubuntu and the instructions for setting Docker up are great (https://docs.docker.com/engine/installation/linux/ubuntulinux/).

Setup

Nginx

1.  Download the nginx image from DockerHub and install it locally.
docker pull nginx

2.  Run the image
docker run --name prototype /usr/local/code:/usr/share/nginx/html:ro -d -p 8081:80 --restart=unless-stopped -v nginx

There's a lot here, so I'm going to break down the arguments a bit:

Option	Explanation
docker run	runs the nginx image that we pulled down from DockerHub
--name prototype	this is what I named my container.  This makes it easy to start and stop the container bc I can reference it using this name, 'prototype'
-v /usr/local/code:/usr/share/nginx/html:ro	this mounts a volume from the host machine (my ubuntu aws instance) and makes it available to nginx.  So the nginx docker container will see /usr/share/nginx/html, but on my real ubuntu machine, it's actually /usr/local/code.  The last bit 'ro' means that docker cannot write to the volume (read only).  One last gotcha, make sure that the docker group can read /usr/local/code on the host ubuntu machine or you will get permission denied errors.
-d	runs the container as a daemon
-p 8081:80	port bindings.  the host ubuntu machine will forward port 8081 to the containers port 80.
--restart=unless-stopped	if the docker container dies for any reason, docker will attempt to restart it, unless a person stopped it manually using `docker stop [name]`

Source Code

I created a BitBucket repo that the design team could check code into.  I went with bitbucket b/c they have nice free private plans.

CI Tool

I had Jenkins running already for other projects so I just added a new project.  On BitBucket checkins to the repo I created, Jenkins would pull down the code and build it.  Since everything was static and it's a prototype so I don't really care about code quality yet, my build doesn't really do anything.  But what's important is that the Jenkins project has an scp step that scp's the code to my host ubuntu server.  And it scp's all the code to /usr/local/code.

Flow

So to recap:
1.  Design team checks in code
2.  Jenkins pulls down latest and scp's it to ubuntu:/usr/local/code
3.  Nginx Docker container has /usr/local/code mounted correctly and will serve everything in that dir to http://ubuntu:8081

The major wins for me here was that to download and setup nginx was very easy.  And the deploy process was just as easy.  And of course it happens on every checkin so I can see the latest whenever they push.

So Much More

Docker can do so much more than what I've put here.  On my other projects, as part of my build process, I actually have Jenkins create Docker images that I check into DockerHub.  I can then pull them from anywhere and run them; be it another developers laptop, or even production.  And on every machine, it will run identically.   And Docker just added Docker Cloud to make it even easier to deploy your docker images to a cloud like AWS, MS Azure or DigitalOcean.  So if you haven't played with Docker yet, I really recommend doing so.  And getting started is probably going to be a lot easier than you think it would be.

The Keystrokes - Generating Interest in STEM

Back in November, my friend Cheryl, whilst in casual conversation, mentioned to me that she was volunteering for Women in Tech (WIT) as well as Girls in Tech (GIT). She was in the middle of setting up a science fair type event that was meant to showcase current innovation and interesting projects from various tech and science companies to try and get girls more interested in science, technology, engineering, and math (STEM). Everything she was describing to me sounded super interesting and I asked her if I could get a booth. I had a few friends in mind that I thought would be interested in helping, but at this point, I hadn't asked them and I had no idea what we were going to showcase. But I was still very interested in helping, and Cheryl had an extra booth, so she said "Sure". Now to find a team and an idea.

I could go on, but my friend Mary, who was part of the team that we assembled for the showcase, gives a thoughtful and thorough retelling. Check it out here.

Mary is an excellent wordsmith and her account, including the events leading up to and including the showcase is truly excellent. I highly recommend the read.

RTFM

We're all guilty of it.  You are using this awesome tool that made your life so much easier.  You were initially debating writing something like this yourself or cobbling together a bunch of other tools in order to do what you want, but Behold!  Tool 'X' is doing everything you needed and more.

You started using it straight away.  You dove right in, and never looked back.  Now your app is in production and everything seems to be going great.

That is until your world is shattered by an article such as:

http://news.hitb.org/content/major-security-alert-40000-mongodb-databases-left-unsecured-internet
or
http://www.techworm.net/2015/02/major-security-alert-40000-mongodb-databases-left-unsecured.html

D'oh!  

You double check your configs and notice that you left a lot of things as 'default'.  Shouldn't it be safe by default!?  You read a little more into what the actual defaults are and realize that alas, no, they are not.

A lesson not to be taken lightly.  Even if you weren't affected by this MongoDB issue, let it be a lesson.  Understand what all the configuration options are and make sure you configure your tools correctly.  DO NOT TRUST THE DEFAULTS.

This happens all the time.  Another one that comes to mind was the JMX console on JBoss.  As a quick reminder, JMX is a tool used by most application servers to allow you quick access to monitor applications or interact with container managed beans.  And by interact, I mean things such as calling functions and invoking business logic.  The JMX Console is a webpage that allows you access to JMX.  For a long time, the default was no security for this page.  Anyone could put in your JMX console URL, and start mucking around with your server.  Even worse, because it's a public page, Google will actually index it.  Don't believe me?  Just do a search for "8080/jmx-console" and you'll find a bunch of servers with their JMX consoles exposed.

Happily, the latest version of JBoss has the JMX Console removed and allows access to JMX through JConsole.  From there you can use a username and password to log in and start using JMX.  These usernames and passwords come from either the ManagementRealm or the ApplicationRealm, so again, RTFM and do not simply use the defaults!

tl;dr RTFM and don't trust the defaults.

Virtual Method Table

Today I'm going to blog about something called a "virtual method table".  I randomly caught a talk where the speaker was saying that teaching someone to sling code is not sufficient. The student has to also understand the theory and fundamentals behind what they are learning.  A great analogy he used was that a "plumber should know what's going on underneath the sink."  He then randomly threw out some computer science terms and concepts; and let me tell you, it was refreshing.

So often we see those "learn to code" websites where they promise to teach you how to program in XX hours.  Reminds me of a great Abstruse Goose comic:

Love this comic

It's a little dated in that it references the old "Sam's Teach Yourself C++ in 21 Days" book but for those of you who don't remember this series:

Oh the lies

I remember this well because I actually had this book.  And I remember I felt like such a failure when I'd take me multiple hours to get through a single "1 hr" lesson.  Frustrated I remember throwing the book aside.

The book that really taught me how to program was:

A Beast of a Book

I forget exactly which edition, but I won't forget the name of the book.  This particular edition is a whopping 984 pages of text and weighs 3.4 pounds.  It was a beast back then, and it's a beast now.  But it's that large b/c the examples are so thorough and the explainations so in depth (at least my particular version was, I can only assume the core of the book is still the same for the fifth edition).

I really enjoyed this book, which is why I wanted to highlight it today.  Ok enough aside, onto the content.

What is a virtual method table?  For that matter, what is a virtual method?  It's really simple.  A virtual method is just a function that can be overriden by an inheriting class.  Basic rules apply, like you need to have the same signature, but it's not much more complicated conceptually than that.  Virtual methods are a core part of object oriented programming.  They can help allow things like polymorphism to happen, a key of OOP.  (There's more to polymorphism than just this, but that discussion is out of scope right now.)

So how are virtual methods implemented?  That's where we get into virtual method tables.  A typical function is bound at compile time.  In other words, when you compile your language, you compile in the location of where your function will live.  So when your program runs, it's a simple jump instruction to the spot in memory where your function resides.  Your program keeps track of where you came from, so when your function is done, you just hop right back where you came from.

Virtual methods on the other hand cannot compile in the memory location, because, you the programmer, could have created an inherited class that overrides that method.  So the compiler cannot figure out during compile time, which exact implementation to jump to.  As a result, the compiler (or runtime, depending on the language/implementation) will create a bit of indirection, called a 'virtual method table' (one table for each class) that acts as a lookup to the proper implementation that should be invoked.  Each instance of your class will have a pointer to this special virtual method table so that when the virtual method is called, the virtual method table can be checked to see which method implementation we actually want to invoke.  Because we don't know precisely the location until runtime (when we check the table), this is called "late" binding (as opposed to compile time, or "early" binding).

Virtual method tables are awesome because it allows us to be flexible in the behavior of our program.  Nothing in life is free though.  This table takes up memory and because of the added hop to the table, then to the actual method, the performance is also slower than an early bound method.  So in C++, you have to explicitly declare which ones of your methods will be virtual by using the keyword...virtual.  Shocking name, I know.  In Java, every method is virtual by default, unless you declare that method to be final or static.

That is the basic concept.  A relatively simple solution to a simple problem.  You'll often hear these concepts refered to by a bunch of various names, but it all refers to the same thing.  A virtual method table is also called a virtual function table, or a virtual call table, or vtable.  But tomato tomato (works better when you say that part aloud).

Hopefully this teaches you something, or at the very least refreshes your memory on a topic you probably don't have to deal with daily.  Take care and happy holidays :)

JavaScript Generators

Intro

One of the things people are really excited about that is coming in EcmaScript6 (Harmony) are generators.  There is a lot of writing out there today on generators but for the most part, I found the writing to be too quick to skip over the fundamental question of what they are.  Basically I was looking for a tl;dr.  Cuz ain't nobody got time for that.

Definition

I actually really like Mozilla's definition.  Short and sweet:
"Generators are functions which can be exited and later re-entered. Their context (variable bindings) will be saved across re-entrances."

Allow me to paraphrase:
tl;dr Generators are special functions that save their variable state between calls.

Example

Now that you got the basic idea, let's look at an example.

First notice that the function definition has an asterick *.

//will double the number passed in
function* doubler(i){
  var doubled = i;
  while(true){
    doubled *= 2;
    yield doubled;
  }
}

Next notice the yield keyword.  We'll come back to that.  Let's take a look at the usage.

var gen = doubler(1);

The interesting thing is that calling doubler doesn't actually invoke the function.  A special object called an iterator is returned.  So gen holds an iterator, so lets see how to use that:

var result = gen.next();

Calling the next method on the iterator actually runs the doubler function, but stops when it hits the keyword yield (told you we'd come back to it).  And whatever you pass to yield (in this case the variable doubled), the iterator returns that.  So line by line:

var doubled = i;
//remember from above that i is 1, var gen = doubler(1);

while(true) {
 //nothing says that the iterator has to terminate. 
 //it can go on forever like this one does

  doubled *= 2;
  //doubled was 1, now its 2, b/c well 1*2 is 2

  yield doubled;
  //the iterator will stop here for now and return 2
}

So there you go, result should be 2.  Conceptually, that's sufficient to say, but in practice, the iterator takes 'doubled' and wraps it inside of a result object.  The result object has two attributes:

1.  The 'value' attribute which holds the value of 'doubled'.
2.  An attribute called 'done' that tells us if the iterator is done, which of course it isn't b/c we have a forever loop there.

{value: 2, done: false}

So what happens if we call next() again?

result = gen.next();

If you said

{value: 4, done: false}

Then congrats!  This is just the surface of how we can use generators, but once you understand this, the rest is cake.

Further Reading

If you would like to dive deeper into generators, check out this guide.  It's pretty detailed and explains some of the many ways you can use generators.

I also recommend the Mozilla documentation:

Using It Today

Great, you love generators now and want to use them today.  Unfortunately, the spec isn't officially finalized yet and not all browsers support it today.  To see who supports it, check out this table here.

You could also use transpilers like Traceur to turn it into regular JavaScript.

Or you can do what I did, and that's to use node.  Let's say all your JavaScript code is in generators.js.  Then just install node and run:

node --harmony generators.js

RubyNation Recap

This weekend I attended RubyNation, a great Ruby conference right here in DC.  Well technically it was at Silver Spring, MD, but still; I had a fantastic time.  All of the speakers and attendees were wonderful.  As usual, the best part was the human aspect.  Connecting and talking with people from all around the world that share the same love and passion that I have is something truly special and this conference was particularly fantastic.

That isn't to say the talks/presentations weren't amazing also.  If I had to sum up some of the main takeaways, they would be:

1.  Always keep reaching.
Do things outside of your comfort zone.  Force yourself to grow by challenging what you know and what you think you can do.

2.  Give back to the community.
Open source survives because a bunch of awesome people dedicate themselves to solving problems so you don't have to.  Do your part and give back in any way you can.

3.  TDD is not dead.
Writing good testable code is not a bad thing.  Knowing what to test and how to test can help you get insight into what you are building and can lead to a better design and better code.

That's it for now.  After the talks get posted online, I'll link them here.

JavaScript Hoisting

Today I'm going to spend a little bit of time on hoisting in JavaScript.  A very cool and useful feature if you know how it works, but painful and confusing if you don't.

So what is hoisting?  Hoisting is JavaScript's behavior of moving declarations to the top of your scope (typically either the top of the global scope or function if you are in one).

There are two main types of things that can get hoisted, variables and functions.  We will go through each one of these presenting example cases to help illustrate how they work.  And at the end we will put everything together with a short quiz that contain aspects of everything discussed here.

Variable Hoisting

Case 1: Using a variable that doesn't exist.

console.log(name);

If you run this script, you get

ReferenceError: name is not defined.

This makes sense.  The variable name wasn't defined anywhere and as such, our JS engine can't resolve it and blows up.

Case 2: Correctly defining a variable and using it.

var name = 'Jon';
console.log(name);

This declares and defines name, and then uses it.  This works as expected and you will see 'Jon' written out to the console.

Case 3: Defining name after usage.

console.log(name);
var name = 'Jon';

You would expect to see the same behavior as Case 1, a ReferenceError, but what you see instead is 'undefined' written out.  This is because of hoisting, in this case, variable hoisting.  The declaration of the name variable was hoisted to the top of this scope.  Notice I said declaration, not definition.  The definition stays right where it is.  This is why name is undefined when it gets printed out.  Let me rewrite what the JS engine actually executes after hoisting.

var name;  //gets the default value of undefined
console.log(name);
name = 'Jon';

As you can see, now the output makes sense.
What other things can get hoisted?  In the next section, I'll talk about function hoisting.

Function Hoisting

Just like variable declarations, function declarations can get hoisted too.  But fun bit here, since the declaration and definition are done together, everything gets hoisted.

Case 1:  Using a function that doesn't exist.

sayHi();

This gives us the same result as Case 1 above,

ReferenceError: sayHi is not defined.

This makes sense.  You can't use something that you haven't declared.

Case 2: Using a function correctly defined after we declare and define it.

function sayHi() {
  console.log('hi');
}
sayHi();

Output here is 'hi'.  We declare and define a function sayHi, and then invoke it.  Everything works and this code is easy to understand.

Case 3: Using a function before we declare and define it.

sayHi();
function sayHi() {
  console.log('hi');
}

The output here is the same as Case 2, we get 'hi' printed out.  This is because the entire sayHi function is hoisted to the top.  So when we invoke sayHi(), it already exists.  Let's take a look at the code after hoisting.

function sayHi() {
  console.log('hi');
}
sayHi();

Notice that it's exactly the same as Case 2.

Hoisting of a Variable Holding a Function

What about this case, if we have a variable that holds a function.  That function is typically anonymous (it doesn't have to be) and we often see it as such:

var sayHi = function() {
  console.log('hi');
}

How does this get hoisted?

Case 1: Using a function that doesn't exist.

sayHi();

This looks like Case 1 above and is.  It gives us the same result,

ReferenceError: sayHi is not defined.

Same reason as before, you can't call something that isn't declared.

Case 2: Using the function after we declare and define it.

var sayHi = function() {
  console.log('hi');
}
sayHi();

This works as expected and prints out 'hi' into the console.  We've properly defined an anonymous function, set it to a variable, and then later invoked it.

Case 3: Using the function before we declare and define it.

sayHi();
var sayHi = function() {
  console.log('hi');
}

Boom!  We get

TypeError: undefined is not a function. 

What happened here?  Why didn't hoisting save us?  It saved us for both variables and functions, why not this time?  It's very subtle, but if you apply the hoisting rules you have learned thus far, you can see why this failed.  Let's rewrite the code after hoisting is applied.

var sayHi;  //set to default value of undefined
sayHi();
sayHi = function() {
  console.log('hi');
}

Because sayHi is actually a variable here, the variable hoisting rule applies.  The JS engine declared the variable at the top of the scope, and left the definition where it was.  So at the time we try and invoke sayHi, it's actually set to undefined.  Obviously, undefined is not a function, which is what our exception complained about.

An important thing to remember here is that for variables, only the declaration gets hoisted, while as for a function, the whole thing gets hoisted.  So this has implications in that when a function gets hoisted, it's immediately accessable/invocable anywhere within that scope.  But if you have a variable containing a method, you can't actually invoke that method until the definition of that method.  Up until that point, the variable will hold the value 'undefined' which you have already seen.

Now let's put it all together.  Look at the code below and see if you can figure it out before I reveal the answer.

The Quiz

Taking everything you learned, what gets executed here?

var f = function() {
    console.log("Me original.");
}
function f() {
    console.log("Me duplicate.");
}
f();

Answer just below....

Answer

If you said 'Me original', you are right!  Wow, pat yourself on the back.  If you got it wrong, don't worry, I did too.  Let's see what this thing actually produces after hoisting, and then we'll tackle it step by step.

After Hoisting

var f;  //gets value of undefined
function f() {
    console.log("Me duplicate.");
}
f = function() {
    console.log("Me original.");
}
f();

First thing that happens is that the declaration of f gets hoisted.  Then, the function f gets hoisted.  Even though this looks weird, so far we are ok.  Odd as it looks, this is valid JS.  We just have a single variable, f, that contains a function that prints out 'Me duplicate.'.  Next we redefine f to print out 'Me original.'.  Finally we have our invocation.  This calls f which has been reassigned to an anonymous function that prints out 'Me original.'

Hopefully all this helps clear up the mystery of hoisting in JavaScript.


A lot of these examples were taken from some stackoverflow questions:
http://stackoverflow.com/questions/23889317/explain-this-javascript-name-clash
http://stackoverflow.com/questions/336859/var-functionname-function-vs-function-functionname

Wow Where Does The Time GO???

Omg I been super busy.  Doing what?  I have no idea.  I think I took a short vacation, and then work went all hell bent busy, and the random side things I work on went all ape nuts crazy too.

Sadly, I didn't take my deep dive into Erlang or Elixer yet and it's fallen on my list of things to get done.  More recently I'm actually getting my windows redone (yay).  I also recently attended NationJS, a great JavaScript convention.  Got to listen to a great talk on Brackets, an open source editor for the web.  It's actually pretty slick.  You type and it reloads immediately.  Nice JS debugging.  And looks pretty nice.  They actually develop it using Brackets.  I love when products eat their own dog food.  Check it out if you have time.  They also make it real easy to contribute.  They have what they call starter issues, which are like bugs for people new to brackets.

Also one last bit of coolness.  If you have time or have figured out how to halt time, check this list out:
https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md

Dave Thomas Recap and Elixir Intro

Just wanted to follow up with my talk with Dave Thomas and various other fun speakers.  Dave didn't speak for very long, but the little he did was very impressive.  Let's just get right into it.  Dave talked about Elixir, which as you already know from my last post is a Ruby like syntactical language that runs on the Erlang VM.  Now the ErlangVM is dang cool, and for more information, read my last post :)

So pretty syntax?  That's it??  Well, there is quite a bit of power in more than just the syntax, but I'm not ready to go into all that yet in this post.  I'm here just to talk about the pretty syntax.  How pretty you might ask?  Let's say you wanted to solve the infamous Fibonacci series.  Everyone's done this.  The concise way is typically to use two methods, one that you call recursively to build your result.  And then you're a clever person so you do some sort of memoization or dynamic programming approach.  Yay (I'll probably post more about these approaches later, but for now, just wiki them)!  Well throw all that stuff out and check out the Elixir approach:


defmodule Cool do
  def fib(0) { 0 }
  def fib(1) { 1 }
  def fib(n) { fib(n-1) + fib(n-2) }
end

IO.puts Cool.fib(10)


Ok what???  Yes, that's the program.  It looks like all I did was describe the problem, there's no way that's actual runnable code.  But it is.  Taking from the Erlang gentle intro from last post, every bit of code is name spaced, or in some sort of class type object, or in Erlang, a module.  We simply describe the problem:

If we pass in 0, we want 0.
If we pass in 1, we want 1.
If we pass in anything else, we want that thing called using this statement but subtracting one and then added to the same but substracting two.

Ok not as concise as the mathmatical symbols, but you get the idea.  We describe the problem and bam!  It just works.  This works because of an Erlang construct known as pattern matching.  It's really not that complex.  So if we call

Cool.fib(1)

This method matches the second of the equations up there, b/c the argument is 1.  If we call

Cool.fib(0)

it matches the first equation (function) because the argument here is 0.  And if we pass something that's not 1 or 0, that falls into n which then calls the third function.   Which as you can see, will cause a recursive call.  Pattern matching is awesome and allows us to define the problem in terms of equations instead of if/else's.  Dave boasts that using this, you can write a whole program devoid of any if/else branching.  He also quickly created a program that spawned multiple processes and had them all work in parallel to compute some result.  I'm not going to get into that now, but just now that it's out there.  I think the best take away I had from his talk was his last quote:

"If you aren't writing functional code in the next few years, you'll be writing maintenance code."

This Elixir Comes From What?

Wednesday I'm going to a talk with Dave Thomas (http://en.wikipedia.org/wiki/Dave_Thomas_(programmer)).  It was his "Agile Web Development with Rails" and "Programming Ruby" that started me with my love affair with Ruby and Ruby on Rails.  He's coming to talk about his latest book, "Programming Elixir".  I knew about Elixir from various blogs, but I was never particularly interested in it.  To me, it was just Erlang with Ruby syntax.  But knowing that Dave would be taking about it in a few days, I decided to take another look at it.  On closer inspection Elixir turns out to be very interesting.

First off, what is it?

"Elixir is a functional meta-programming aware language built on top of the Erlang VM. It is a dynamic language with flexible syntax with macros support that leverages Erlang's abilities to build concurrent, distributed, fault-tolerant applications with hot code upgrades."
-- Jose Valim (creator)

In some cases, Elixir will actually run faster than Erlang.  That's pretty damn cool.  And if you're reluctant to try it out, check out this blog post by one of Erlang's creator, Joe Armstrong (http://joearms.github.io/2013/05/31/a-week-with-elixir.html).  If he likes it, there must be something to it.

So while reading the docs, I thought, yep, this is very Rubyish.  But I didn't understand the abstraction that it was doing from Erlang, and that bothered me.  I hadn't done Erlang since college and figured it was time to get back in it, but really learn it this time.  So this post and most likely some future posts are going to be my dip back into Erlang.

Erlang Background
Every language is created with a specific problem in mind to solve.  Erlang started out in the 80s at Ericsson where they were trying to figure out the best way to build systems for their phone systems, switches and such.  They examined over 20 languages and found that none of them totally suited their needs.  So they took what they liked from each language, and with Prolog as it's syntactic inspiration built a new language with the following goals in mind:

1.  Fault tolerance
  The entire system should be stable enough to withstand errors that could occur.
  - Erlang has light-weight processes that are all isolated from one another.  They run in complete isolation which means that if one dies, it does not compromise the entire system.
  - When processes die, they can tell other linked processes that they are dead.  Using something like the OTP (Open Telecom Platform) framework gives you advanced process supervision in the form of trees that delegate responsibility for things like process restarts and restart timeouts.

2.  Non-stop
  They system should never go down nor should you ever have to take the down.  Put simply, they should not stop.
  - The system is fault tolerant so errors will not take the entire system down.
  - Code can be hot swapped in.  This means that you can actually push out newly compiled code while the system is still running.  You also can choose which part of the system you want to deploy the new code to, so you get total control.

3.  Concurrent
  All the processes in an Erlang application are truely concurrent.
  - There is a scheduler per core (with SMP -- Symmetric Multi Processing enabled) that will schedule the work to be done
  - They employ preemptive scheduling so the developer doesn't have to worry about cooperative scheduling.
  - All processes are equal.  This means that no one gets special priority, internal Erlang processes get the same priority as your processes.

4.  Distributed
  Multiple Erlang processes can actually live on different machines and all communicate with each other.  Erlang uses the actor model which means each Erlang process is itself an actor with a mailbox that can receive messages and choose what they do with it.  Each process can additional send messages to any process.  This is a very powerful mechanism and is actually built into the language without having to add any additional modules.

5.  Soft real-time
  Real-time is critical for applications like airplanes where processing in real-time could cost lives.  Erlang was built for phone systems, so real-time is NOT a must.  They are not bound to the same constraints as airplanes.  This is the platform that Erlang was targetted for, and these laxer requirements allows such things as a garbage collector for the Erlang VM.

6.  Prototypeability
  This is a made up word coined by Lennart Ohman used to describe Erlang, but this really just means speed to produce code, or "time to market".  Basically programmer efficiency and speed from inception to production.
    - To allow programmers to work faster, Erlang was designed to be a functional over imperative language, which they believed would allow faster development.
    - Run-time linking.  Linking is done at run time allowing code to be hotswapped in.  This is pretty cool, see the non-stop section.

Erlang has a compiler and that compiled code is then linked at run time and executed.  As I mentioned above, Erlang has a virtual machine, called BEAM, or sometimes EVM.  One of the awesome things about Erlang is that processes are cheap to create and all execute concurrently (to give a little more depth to this, you can actually configure three parameters to help you adjust your concurrency profile.  -P for your process threads, these are actually green threads.  -S which are the scheduler threads, typically one per cpu.  These will schedule the green threads for execution.  -A for your async threads that react to select and poll events).

Erlang isn't all sunshine and rainbows though.  People have complained about the poor performance (notice that performance wasn't one of the goals of the language), the GC isn't that great, and of course the most common criticism is the syntax.  Either way, I'm going to blog about my dive into the language, but for now I'll leave you with the canonical hello world:

Example
Save the following in a file named hello.erl (it must match module name)
-------------------
-module(hello).
-export([hello_world/0]).

hello_world() -> io:fwrite("Hello World\n").
-------------------

Then start Erlang by typing erl at the command prompt.  Then type the following:

c("hello.erl").
hello:hello_world().

Notice the output.
A few things about the syntax:
1.  All lines end in a period.
2.  Module named 'hello', sort of like a namespace.
3.  Export is a method that exposes internal methods to the outside world, sort of like building an api, or declaring public methods.
4.  In the export, notice the brackets, they signify [method name/num of args]
5.  -> is a function definition
6.  c() is a built in Erlang method to compile
7.  module:method() is how you invoke a method.  Notice we called our module 'hello' and method 'hello_world'

And that's pretty much it.  Until next time.