VIDEO: iFans Gather to Gawk at Latest Apple Accessories

Billed as “the ultimate ifan event,” MacWorld in San Francisco offers a sneak peak at the latest in apps and accessories for all your Apple products.

Thanks for checking us out. Please take a look at the rest of our videos and articles.

To stay in the loop, bookmark our homepage.


(Powered by LaunchBit)

OpenGL ES for Android; Core Data 2nd Ed.

OpenGL ES for Android in beta; Core Data 2nd Ed. in print

SimpleStateMachine – a simple Enum based state machine for ruby

Following my previous post on Using Enums in Ruby we have been working
on a state machine implementation in Ruby, based on an Enum representation of states.

Why should you use a state machine?

A state machine is mainly used to indicate a specific status a certain object is in. A State is some kind of a description – usually
a few words commonly stored as a string in the storage layer.
State machine simplify the process of transition between certain states that an object is allowed to do, mechanizing the transition itself – transition, callbacks and persistence included.

You should be using a state machine when your code defines different behaviors for an object – based on the current status the object is in.
For example: a simple example for a state machine is a blog post. A blog post can be saved as a “draft” – then it Continue reading “SimpleStateMachine – a simple Enum based state machine for ruby”

SimpleStateMachine – a simple Enum based state machine for ruby

Following my previous post on Using Enums in Ruby we have been working
on a state machine implementation in Ruby, based on an Enum representation of states.

Why should you use a state machine?

A state machine is mainly used to indicate a specific status a certain object is in. A State is some kind of a description – usually
a few words commonly stored as a string in the storage layer.
State machine simplify the process of transition between certain states that an object is allowed to do, mechanizing the transition itself – transition, callbacks and persistence included.

You should be using a state machine when your code defines different behaviors for an object – based on the current status the object is in.
For example: a simple example for a state machine is a blog post. A blog post can be saved as a “draft” – then it won’t be shown in the blog, and a “published” state which makes it available for display in the blog.

You’ll probably want to add some callback functionality for the state change, like sending out a tweet notifying the world of your new post when a post becomes “published”.

The state machine in the Ruby world: AASM

One of the most widely used state machine gems in the Ruby/Rails world is probably the AASM gem. AASM is a great gem that has one basic flaw – it requires the state column / attribute
to be of a String type.
Using this gem your database will look something like this (a simple user table for example):

varchar mysql column for states, using MySQL
1
2
3
4
5
6
7
8
mysql> select id, username, status from users limit 2;
+----+--------------+---------+
| id | username     | status  |
+----+--------------+---------+
| 18 | zidane       | retired |
| 71 | zessi        | active  |
+----+--------------+---------+
2 rows in set (0.00 sec)

and to simplify your queries you may have scopes in your model to match the the available states:

a user ActiveRecord::Base model with AASM
1
2
3
4
5
6
7
8
9
10
11
12
class User < ActiveRecord::Base

  include AASM

  initial_state :active

  # more AASM configuration 

  scope :active, where(status: "active")
  scope :retired, where(status: "retired")

end

Yes, this is simple and clear enough to be used on almost any application that requires a state machine functionality, but when your data size increases
beyond a certain point the string type dependency can be a real PITA.

Storing states: String vs. Integer vs. Enum

You have 3 options when you choose your data storage type for a state column: String (VARCHAR), Integer and Enum (Not all databases are supported).

Strings

Storing strings is by far the easiest implementation you can choose. As shown earlier when you store states as strings the code is readable, the database output is readable
and you can add and remove states pretty easily (as long as those new states do not exceed your string column length LIMIT bar).
As far as indexing strings, MySQL string indexes are bigger comparing to integer column indexes and comparing strings is a little bit slower than comparing integers so traversing a string index performance can drop a little bit.

Enums

ENUM column type is available out of the box for MySQL:

Enum column in mysql
1
2
3
4
CREATE TABLE users (
    ...
    status ENUM('active', 'retired')
);

And you can still query the ENUM column based on the string representation of the ENUM:

querying an ENUM column
1
mysql> SELECT * FROM `users` WHERE status = 'active';

Adding an ENUM fields to a Postgres database is a little bit tricky and requires a custom defintion for the ENUM column type

While simple to create, maintaining an ENUM column has its own PITA:

  • When you use an ENUM column, you’re technically moving data from where it belongs (in actual database fields), to somewhere it doesn’t (into the database metadata, specifically a column definition). This is different than putting constraints on the data which can achieve the same result.
  • When you create an ENUM column, you basically say “this is never going to change”. but when it does you’ll need to ALTER TABLE that can take a serious amount of time on big tables.
  • You’ll have to maintain the same list of available ENUM values for application level usage (e.g: a drop down) since you can’t easily extract a distict list of available ENUM values from the column itself.
  • Aside from not being reusable on the application layer, ENUM members aren’t reusable even in other tables.
  • Inserting an illegal value to an ENUM does not cause an error (like a constraint will do) – in most databases it will simply truncate the value to an empty string and insert the faulty data silently, yay!.

Integers

The great ancestor of everything, the integer type is the simplest of them all but carries an overweight of being completely unreadable and depends on conjunction with
the application code to provide a textual representation for vogue number based values.
It is pretty clear that

varchar mysql column for states, using MySQL
1
2
3
4
5
6
7
mysql> select id, username, status from users limit 1;
+----+--------------+---------+
| id | username     | status  |
+----+--------------+---------+
| 18 | zidane       | 1       |
+----+--------------+---------+
1 rows in set (0.00 sec)

doesn’t really makes it clear on which status zidane is.

Introducting: SimpleStateMachine

The SimpleStateMachine gem is now available at a alpha version and includes a very simple state machine implementation:

  • State definition
  • Transition setup
  • Callbacks
  • Enum representation of states

SimpleStateMachine does not makes it necessary to use ActiveRecord or any kind of ORM, it is a ruby free implementation.
state enum indexes will be stored as integers in case you choose to use some ORM, and will be transformed back to strings.

The is still some work to be down, especially on the query interface so patches and pull requests are welcome.

Short, short example

SimpleStateMachine example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class User
  include SimpleStateMachine

  state_machine do |sm|
    sm.state_field "status"
    sm.initial_state "happy"
    sm.add_state "sad", :before_enter => :cry
    sm.add_transition :be_sad, :from => :happy, :to => :sad
  end

  def cry
    puts "*sniff sniff*"
  end
end

# Console
> sad_clown = User.new
> sad_clown.status
0
> sad_clown.human_status_name
"happy"
> sad_clown.be_sad
*sniff sniff*
> sad_clown.status
1
> sad_clown.human_status_name
"sad"

SimpleStateMachine – a simple Enum based state machine for ruby

Following my previous post on Using Enums in Ruby we have been working
on a state machine implementation in Ruby, based on an Enum representation of states.

Why should you use a state machine?

A state machine is mainly used to indicate a specific status a certain object is in. A State is some kind of a description – usually
a few words commonly stored as a string in the storage layer.
State machine simplify the process of transition between certain states that an object is allowed to do, mechanizing the transition itself – transition, callbacks and persistence included.

You should be using a state machine when your code defines different behaviors for an object – based on the current status the object is in.
For example: a simple example for a state machine is a blog post. A blog post can be saved as a “draft” – then it won’t be shown in the blog, and a “published” state which makes it available for display in the blog.

You’ll probably want to add some callback functionality for the state change, like sending out a tweet notifying the world of your new post when a post becomes “published”.

The state machine in the Ruby world: AASM

One of the most widely used state machine gems in the Ruby/Rails world is probably the AASM gem. AASM is a great gem that has one basic flaw – it requires the state column / attribute
to be of a String type.
Using this gem your database will look something like this (a simple user table for example):

varchar mysql column for states, using MySQL
1
2
3
4
5
6
7
8
mysql> select id, username, status from users limit 2;
+----+--------------+---------+
| id | username     | status  |
+----+--------------+---------+
| 18 | zidane       | retired |
| 71 | zessi        | active  |
+----+--------------+---------+
2 rows in set (0.00 sec)

and to simplify your queries you may have scopes in your model to match the the available states:

a user ActiveRecord::Base model with AASM
1
2
3
4
5
6
7
8
9
10
11
12
class User < ActiveRecord::Base

  include AASM

  initial_state :active

  # more AASM configuration 

  scope :active, where(status: "active")
  scope :retired, where(status: "retired")

end

Yes, this is simple and clear enough to be used on almost any application that requires a state machine functionality, but when your data size increases
beyond a certain point the string type dependency can be a real PITA.

Storing states: String vs. Integer vs. Enum

You have 3 options when you choose your data storage type for a state column: String (VARCHAR), Integer and Enum (Not all databases are supported).

Strings

Storing strings is by far the easiest implementation you can choose. As shown earlier when you store states as strings the code is readable, the database output is readable
and you can add and remove states pretty easily (as long as those new states do not exceed your string column length LIMIT bar).
As far as indexing strings, MySQL string indexes are bigger comparing to integer column indexes and comparing strings is a little bit slower than comparing integers so traversing a string index performance can drop a little bit.

Enums

ENUM column type is available out of the box for MySQL:

Enum column in mysql
1
2
3
4
CREATE TABLE users (
    ...
    status ENUM('active', 'retired')
);

And you can still query the ENUM column based on the string representation of the ENUM:

querying an ENUM column
1
mysql> SELECT * FROM `users` WHERE status = 'active';

Adding an ENUM fields to a Postgres database is a little bit tricky and requires a custom defintion for the ENUM column type

While simple to create, maintaining an ENUM column has its own PITA:

  • When you use an ENUM column, you’re technically moving data from where it belongs (in actual database fields), to somewhere it doesn’t (into the database metadata, specifically a column definition). This is different than putting constraints on the data which can achieve the same result.
  • When you create an ENUM column, you basically say “this is never going to change”. but when it does you’ll need to ALTER TABLE that can take a serious amount of time on big tables.
  • You’ll have to maintain the same list of available ENUM values for application level usage (e.g: a drop down) since you can’t easily extract a distict list of available ENUM values from the column itself.
  • Aside from not being reusable on the application layer, ENUM members aren’t reusable even in other tables.
  • Inserting an illegal value to an ENUM does not cause an error (like a constraint will do) – in most databases it will simply truncate the value to an empty string and insert the faulty data silently, yay!.

Integers

The great ancestor of everything, the integer type is the simplest of them all but carries an overweight of being completely unreadable and depends on conjunction with
the application code to provide a textual representation for vogue number based values.
It is pretty clear that

varchar mysql column for states, using MySQL
1
2
3
4
5
6
7
mysql> select id, username, status from users limit 1;
+----+--------------+---------+
| id | username     | status  |
+----+--------------+---------+
| 18 | zidane       | 1       |
+----+--------------+---------+
1 rows in set (0.00 sec)

doesn’t really makes it clear on which status zidane is.

Introducting: SimpleStateMachine

The SimpleStateMachine gem is now available at a alpha version and includes a very simple state machine implementation:

  • State definition
  • Transition setup
  • Callbacks
  • Enum representation of states

SimpleStateMachine does not makes it necessary to use ActiveRecord or any kind of ORM, it is a ruby free implementation.
state enum indexes will be stored as integers in case you choose to use some ORM, and will be transformed back to strings.

The is still some work to be down, especially on the query interface so patches and pull requests are welcome.

Short, short example

SimpleStateMachine example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class User
  include SimpleStateMachine

  state_machine do |sm|
    sm.state_field "status"
    sm.initial_state "happy"
    sm.add_state "sad", :before_enter => :cry
    sm.add_transition :be_sad, :from => :happy, :to => :sad
  end

  def cry
    puts "*sniff sniff*"
  end
end

# Console
> sad_clown = User.new
> sad_clown.status
0
> sad_clown.human_status_name
"happy"
> sad_clown.be_sad
*sniff sniff*
> sad_clown.status
1
> sad_clown.human_status_name
"sad"

“Free” Git and GitHub Course – 7th batch

Send to Kindle

“Free” Git and GitHub Course – 7th batch

Registrations are now open for RubyLearning’s popular Git and GitHub course. This is an introductory but an intensive, online course for beginners. Here you’ll learn the essential features of both Git and GitHub that you’ll end up using every day.

What’s Git and GitHub?

Git is an open source version control system designed to handle very large projects with speed and efficiency, but just as well suited for small personal repositories (collection of resources that can be accessed to retrieve information); it is especially popular in the open source community. With GitHub you can host your public and private projects there and use it to collaborate on projects.

Ruby Master, Josh Susser1 in an interview with RubyLearning said:

First off, get an account on GitHub. (If you haven’t learned git yet, get going on that too – it’s the future for open source SCM.) Then do some exploring around the various projects and see where you think you can jump in and contribute something. Pick a project that is currently under development and has an active community. You’ll have enough going on that you don’t want to be championing a project just yet.

Get involved in the Ruby community. Join GitHub

What Will I Learn?

The course topics in brief are:

  • What’s Version Control
  • What’s Git
  • Downloading and Installing Git
  • Create your SSH Key
  • Introduce yourself to Git
  • Add some additional Git settings
  • What’s GitHub?
  • Set up your GitHub account
  • Follow a Friend
  • Watch projects
  • Creating a new repository
  • Deleting and renaming repositories
  • Fork a repository
  • Push changes to a repository
  • Clone a public project
  • Add collaborators to a project
  • Collaborate with other users
  • Send a pull request
  • Merge changes from a pull request
  • Use project wikis
  • Create and delete branches and tags
  • Create GitHub pages
  • Gist
  • Exercises

Who’s It For?

The Git and GitHub course is a starting point for people new to Git and GitHub, to learn it as quickly and easily as possible.

Dates

The course starts on 9th Feb. 2013 and runs for a week.

The first six batches were a run-away success. So hurry, registrations have started.

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 5 for the course. However, you are under no obligation to pay anything at all and hence the course would be free for you. For those who contribute US$ 5 or more, we shall email them a copy of the book (.pdf) “Using Git & GitHub eBook” – the course is based on this book.

How do I register?

  • You can pay either by Paypal or send cash via Western Union Money Transfer or by bank transfer (if you are in India). The fees collected helps RubyLearning maintain the site, the various courses and provide quality content to you.
  • Once you pay the fees below, register on the RubyLearning.org site and send us your name and registered email address while creating an account at RubyLearning.org to satish [at] rubylearning [dot] org We will enrol you into the course which normally takes place within 48 hours.

After you click the “Pay Now” button below, you will be taken to a webpage as shown below.

Please enter the amount you want to pay for the course in the “Item price” field and click on the “Update” link. You can safely pay via PayPal.

You can now pay the Course Fees by clicking on the “Pay Now” button below.

Technorati Tags: ,


(Powered by LaunchBit)

Waza 2013 – Keynote Speakers

Waza (技) 2013 is less than a month away and we are excited to have a full lineup of speakers who will be talking about their perspectives on art and technique. In between the talks, take part in an unique blend of conversation and craft through the hands-on workshops led by artisans teaching their trades from origami creations, to take-home woodblock prints, and even a hand-crafted and dyed quilt. Take part in this celebration of skill and making at Waza 2013.

Waza Keynotes:

Michael Lopp: Rands in Repose

Michael has been blogging since 2002 as his alter-ego Rands in Repose.

Our favorite recent quote: "Engineers don’t hate process. They hate process that can’t defend itself." We couldn’t agree more.

Kirby Ferguson: Everything is a Remix.

Kirby is a filmmaker, storyteller, and remixer. He is known for his fantastic video series Everything is a Remix

Favorite quote: “We are not self-made. We are dependent on one another. Admitting this to ourselves isn’t an embrace of mediocrity and derivativeness, it’s a liberation from our misconceptions.”

He’s been featured at TED.

Speaker Lineup:

In addition to these fantastic keynotes, we have a full day of sessions that include:

Afterparty, sponsored by Github

Waza doesn’t end after the last speaker leaves the stage. All attendees are invited to join Heroku and Github at the Waza afterparty. Live music, drinks, and a great time is on the schedule.

Don’t miss out – Register Today!

Cross-Site Request Forgery Vulnerability Resolution

On Friday January 18, security researcher Benjamin Manns notified Heroku of a security vulnerability related to our add-ons program. At a high level, the vulnerability could have resulted in disclosing our Cross-Site Request Forgery tokens (these tokens are used to prevent browser hijacking) to third parties.

We quickly addressed the vulnerability and on Sunday, we deployed a patch to remediate the issue. We also reviewed our code for related vulnerabilities and conducted a review of our audit logs to determine the impact of the vulnerability. We found no instances of this issue being exploited.

We wish to thank Mr. Manns for his work and commitment to responsible disclosure. You can access his write up here: http://www.benmanns.com/posts/security-vulnerability-found-in-heroku-and-rails-form-tag/

We would also like to reaffirm our commitment to the security and integrity of our customers’ data and code. Nothing is more important to us.

Oren Teich, Chief Operating Officer

#402 Better Errors & RailsPanel

Here we take a look at two tools to aid us in development: Better Errors which makes it easier than ever to debug exceptions, and RailsPanel, a Chrome extension to see Rails requests.

A “Free” online course: Sinatra 101

Send to Kindle

A “Free” online course: Sinatra 101

RubyLearning announces the tenth batch of its “Free” online “Sinatra 101” course starting from Saturday 2nd Mar. 2013.

Sinatra – quickly create tiny web apps and services

What’s Sinatra?

Sinatra is a micro-framework for quickly creating tiny web-applications and small services in Ruby. It is not a Model-View-Controller (MVC) based framework.

Please read – Sinatra, a Ruby web framework, and Why it Matters.

Heroku Logo

Thanks to Heroku for providing the facility to create free hosting accounts for all the participants, to host their apps created during the course. Heroku – it’s fast, it’s easy, and it just works!

What Will I Learn?

In this introductory course, you will learn the essential features of Sinatra that you will end up using every day. The course topics are:

  • What is Sinatra?
  • Sinatra Installation and its dependencies
  • Routes
  • set
  • before block
  • pass
  • status
  • Building a trivial Sinatra application
  • Deployment of a Sinatra app to Heroku
  • Views – ERB and HAML
  • Handler
  • Form parameters
  • Layouts
  • Error Handling – 404 and 500
  • Helpers
  • Exercises
    • Hosting a static webpage on Heroku
    • Text String Reversal Service
    • Stock Exchange Quote Service
    • Using Sinatra to access the Google+ API
    • Running a Sinatra app using JRuby
    • A Sorter Web Service in Sinatra
    • Finding Photos on Flickr
    • A Sinatra app to access GEO Info via GeoCoder
    • Simple CRUD app with ActiveRecord, SQLite3 and YAML
  • Using Rack Middleware

You can read through the RubyLearning FAQ.

Some Fun Apps

Sinatra Icon

Here are some of the fun apps created by the previous batch participants and deployed to Heroku:

Yes, you too can build all such applications and many more.

Who’s It For?

Anyone who knows the Ruby programming language can take the “Sinatra 101” course, and is a starting point for people new to Sinatra and a guide to help learn it as quickly and easily as possible.

Dates

The course starts on Saturday 2nd Mar. 2013 and runs for a week.

Is the course really free?

A lot of effort and time goes into building such a course and we would really love that you pay at least US$ 10 for the course. However, you are under no obligation to pay anything at all and hence the course would be free for you. For those who contribute US$ 10 or more, we shall email them a copy of the book (.pdf) “Introduction to Sinatra” – the course is based on this book.

How do I register?

  • You can pay either by Paypal or send cash via Western Union Money Transfer or by bank transfer (if you are in India). The fees collected helps RubyLearning maintain the site, the various courses and provide quality content to you.
  • Once you pay the fees below, register on the RubyLearning.org site and send us your name and registered email id while creating an account at RubyLearning.org to satish [at] rubylearning [dot] org We will enrol you into the course which normally takes place within 48 hours.

After you click the “Pay Now” button below, you will be taken to a webpage as shown below.

Please enter the amount you want to pay for the course in the “Item price” field and click on the “Update” link. You can safely pay via PayPal.

You can now pay the Course Fees by clicking on the “Pay Now” button below.

Famous Rubyists using Sinatra talked to RubyLearning and gave us their views on:

Also, thanks to Adam Keys, Aaron Quint, and Ryan Tomayko for sharing their expertise on Sinatra with the course participants.

So hurry, registrations have started.

By the end of the course, you can quickly create your own tiny web-applications in Ruby and write lots of small services.

Technorati Tags: , , , , ,


(Powered by LaunchBit)

An open letter: Internet, Lighten up

Yesterday, something terrible happened.

Me and a group of dev-friends were working a few months ago on a private project in ruby, a simple state machine implementation that was hosted
as a private repository on Github.
A few days ago one of my friends came to me and asked to use this project – so I opened it to public access.

Well, I really didn’t see it coming.

First let me say, I do not – under any circumstances agree or endorsed such behavior either in code or in the real world – but part
of the test code for that repo included mentions of the words “gay” and “gangrape” in conjunction.

It was first brought to my attention on Twitter – I immediately went to the code
and shamefully removed the offensive file and added a sorry note to the readme file.
I also published a quick tweet explaining how sorry I was and that no matter how funny it was in our inner developer circle (yes, including a homosexual with a sense of humor) it shouldn’t have
crossed the line into the Internet public highway.

The tweet mentioned above caused an immediate avalanche that headed straight at me, by people that were focusing entirely on how offensive this code was, but disregarded
the fact that I admitted in a mistake, promised to make sure it wouldn’t happen again – and published 2 (!!!) public messages on being the down bottom ashamed that I am.

Yes. It is almost inexcusable. But things should be put in perspective.

Not every time someone makes a bad decision, a mistake or even something awful like we did – deserves an immediate attack and a righteous stampede.

The Internet and the open-source communities are FULL of naming conventions that are offensive and considered hurtful to almost anyone alive. As a Jewish person I come across at least
3-4 times a day with the all-known Grammar Nazi that you all know, but as a person that lost a huge part of his family in the holocaust, am I offended by this WIDELY used meme?
or by wide usage of the “Nazi” phrase everywhere in the open-source community? or maybe I should go up to all of the people that use MongoDB and ask them if they know
how hurtful the word “Mongo” (Check the other uses section where it says “A variant of mong, a derogatory shortening of Mongoloid”) means to some people?

No. I am not offended either by the Nazi, and not even by 10gen (Guys, I love you).

I am not offended because people make this things either by mistake, either by purpose and in most of the time no matter what you do – someone can take offense.
Being judgmental and complaining about hurtful things you find on the Internet is like complaining on the noise level in a Megadeath concert – it is there, and it will always be there.

So please, if you see someone making a mistake – or something that you think worths the heads-up – there is no need to start a witch hunt, let them know and
I am sure that if they are reasonable people they will change whatever it is that is bothering you and beg for forgiveness.

Yours,
Elad

An open letter: Internet, Lighten up

Yesterday, something terrible happened.

Me and a group of dev-friends were working a few months ago on a private project in ruby, a simple state machine implementation that was hosted
as a private repository on Github.
A few days ago one of my friends came to me and asked to use this project – so I opened it to public access.

Well, I really didn’t see it coming.

First let me say, I do not – under any circumstances agree or endorsed such behavior either in code or in the real world – but part
of the test code for that repo included mentions of the words “gay” and “gangrape” in conjunction.

It was first brought to my attention on Twitter – I immediately went to the code
and shamefully removed the offensive file and added a sorry note to the readme file.
I also published a quick tweet explaining how sorry I was and that no matter how funny it was in our inner developer circle (yes, including a homosexual with a sense of humor) it shouldn’t have
crossed the line into the Internet public highway.

The tweet mentioned above caused an immediate avalanche that headed straight at me, by people that were focusing entirely on how offensive this code was, but disregarded
the fact that I admitted in a mistake, promised to make sure it wouldn’t happen again – and published 2 (!!!) public messages on being the down bottom ashamed that I am.

Yes. It is almost inexcusable. But things should be put in perspective.

Not every time someone makes a bad decision, a mistake or even something awful like we did – deserves an immediate attack and a righteous stampede.

The Internet and the open-source communities are FULL of naming conventions that are offensive and considered hurtful to almost anyone alive. As a Jewish person I come across at least
3-4 times a day with the all-known Grammar Nazi that you all know, but as a person that lost a huge part of his family in the holocaust, am I offended by this WIDELY used meme?
or by wide usage of the “Nazi” phrase everywhere in the open-source community? or maybe I should go up to all of the people that use MongoDB and ask them if they know
how hurtful the word “Mongo” (Check the other uses section where it says “A variant of mong, a derogatory shortening of Mongoloid”) means to some people?

No. I am not offended either by the Nazi, and not even by 10gen (Guys, I love you).

I am not offended because people make this things either by mistake, either by purpose and in most of the time no matter what you do – someone can take offense.
Being judgmental and complaining about hurtful things you find on the Internet is like complaining on the noise level in a Megadeath concert – it is there, and it will always be there.

So please, if you see someone making a mistake – or something that you think worths the heads-up – there is no need to start a witch hunt, let them know and
I am sure that if they are reasonable people they will change whatever it is that is bothering you and beg for forgiveness.

Yours,
Elad

An Instrumented Library in ~30 Lines

The Full ~30 Lines

For the first time ever, I am going to lead with the end of the story. Here is the full ~30 lines that I will break down in detail during the rest of this post.

require 'forwardable'

module Foo
  module Instrumenters
    class Noop
      def self.instrument(name, payload = {})
        yield payload if block_given?
      end
    end
  end

  class Client
    extend Forwardable

    def_delegator :@instrumenter, :instrument

    def initialize(options = {})
      # some other setup for the client ...
      @instrumenter = options[:instrumenter] || Instrumenters::Noop
    end

    def execute(args = {})
      instrument('client_execute.foo', args: args) { |payload|
        result = # do some work...
        payload[:result] = result
        result
      }
    end
  end
end

client = Foo::Client.new({
  instrumenter: ActiveSupport::Notifications,
})

client.execute(...) # I AM INSTRUMENTED!!!

The Dark Side

A while back, statsd grabbed a hold of the universe. It swept in like an elf on a unicorn and we all started keeping track of stuff that previously was a pain to keep track of.

Like any wave of awesomeness, it came with a dark side that was felt, but mostly overlooked. Dark side? Statsd? Graphite? You must be crazy! Nope, not me, definitely not crazy this one. Not. At. All.

What did we all start doing in order to inject our measuring? Yep, we started opening up classes in horrible ways and creating hooks into libraries that sometimes change rapidly. Many times, updating a library would cause a break in the stats reporting and require effort to update the hooks.

The Ideal

Now that the wild west is settling a bit, I think some have started to reflect on that wave of awesomeness and realized something.

I no longer want to inject my own instrumentation into your library. Instead, I want to tell your library where it should send the instrumentation.

The great thing is that ActiveSupport::Notifications is pretty spiffy in this regard. By simply allowing your library to talk to an “instrumenter” that responds to instrument with an event name, optional payload, and optional block, you can make all your library’s users really happy.

The great part is:

  1. You do not have to force your users to use active support. They simply need some kind of instrumenter that responds in similar fashion.
  2. They no longer have to monkey patch to get metrics.
  3. You can point them in the right direction as to what is valuable to instrument in your library, since really you know it best.

There are a few good examples of libraries (faraday, excon, etc.) doing this, but I haven’t seen a great post yet, so here is my attempt to point you in what I feel is the right direction.

The Interface

First, like I said above, we do not want to force requiring active support. Rather than require a library, it is always better to require an interface.

The interface that we will require is the one used by active support, but an adapter interface could be created for any instrumenter that we want to support. Here is what it looks like:

instrumenter.instrument(name, payload) { |payload|
  # do some code here that should be instrumented
  # we expect payload to be yielded so that additional 
  # payload entries can be included during the 
  # computation inside the block
}

Second, we have two options.

  1. Either have an instrumenter or not. If so, then call instrument on the instrumenter. If not, then do not call instrument.
  2. The option, which I prefer, is to have a default instrumenter that does nothing. Aptly, I call this the noop instrumenter.

The Implementation

Let’s pretend our library is named foo, therefore it will be namespaced with the module Foo. I typically namespace the instrumenters in a module as well. Knowing this, our noop instrumenter would look like this:

module Foo
  module Instrumenters
    class Noop
      def self.instrument(name, payload = {})
        yield payload if block_given?
      end
    end
  end
end

As you can see, all this instrumenter does is yield the payload if a block is given. As I mentioned before, we yield payload so that the computation inside the block can add entries to the payload, such as the result.

Now that we have a default instrumenter, how can we use it? Well, let’s imagine that we have a Client class in foo that is the main entry point for the gem.

module Foo
  class Client
    def initialize(options = {})
      # some other setup for the client ...
      @instrumenter = options[:instrumenter] || Instrumenters::Noop
    end
  end
end

This code simply allows people to pass in the instrumenter that they would like to use through the initialization options. Also, by default if no instrumenter is provided, we use are noop version that just yields the block and moves on.

Note: the use of || instead of #fetch is intentional. It prevents a nil instrumenter from being passed in. There are other ways around this, but I have found using the noop instrumenter in place of nil, better than complaining about nil.

Now that we have an :instrumenter option, someone can quite easily pass in the instrumenter that they would like to use.

client = Foo::Client.new({
  :instrumenter => ActiveSupport::Notifications,
})

Boom! Just like that we’ve allowed people to inject active support notifications, or whatever instrumenter they want into our library. Anyone else getting excited?

Once we have that, we can start instrumenting the valuable parts. Typically what I do is I setup delegation of the instrument to the instrumenter using ruby’s forwardable library:

require 'forwardable'

module Foo
  class Client
    extend Forwardable

    # forward instrument in this class to @instrumenter, for those unfamilier
    # with forwardable.
    def_delegator :@instrumenter, :instrument

    def initialize(options = {})
      # some other setup for the client ...
      @instrumenter = options[:instrumenter] || Instrumenters::Noop
    end
  end
end

Now we can use the instrument method directly anywhere in our client instance. For example, let’s say that client has a method named execute that we would like to instrument.

module Foo
  class Client
    def execute(args = {})
      instrument('client_execute.foo', args: args) { |payload|
        result = # do some work...
        payload[:result] = result
        result
      }
    end
  end
end

With just a tiny wrap of the instrument method, the users of our library can do a ridiculous amount of instrumentation. For one, note that we pass the args and the result along with the payload. This means our users can create a log subscriber and log each method call with timing, argument, and result information. Incredibly valuable!

They can also create a metrics subscriber that sends the timing information to instrumental, metriks, statsd, or whatever.

The Bonus

You can even provide log subscribers and metric subscribers in your library, which means instrumentation for your users is simply a require away. For example, here is the log subscriber I added to cassanity.

require 'securerandom'
require 'active_support/notifications'
require 'active_support/log_subscriber'

module Cassanity
  module Instrumentation
    class LogSubscriber < ::ActiveSupport::LogSubscriber
      def cql(event)
        return unless logger.debug?

        name = '%s (%.1fms)' % ["CQL Query", event.duration]

        # execute arguments are always an array where the first element is the
        # cql string and the rest are the bound variables.
        cql, *args = event.payload[:execute_arguments]
        arguments = args.map { |arg| arg.inspect }.join(', ')

        query = "#{cql}"
        query += " (#{arguments})" unless arguments.empty?

        debug "  #{color(name, CYAN, true)}  [ #{query} ]"
      end
    end
  end
end

Cassanity::Instrumentation::LogSubscriber.attach_to :cassanity

All the users of cassanity need to do to get logging of the CQL queries they are performing and their timing is require a file (and have activesupport in their gemfile):

require 'cassanity/instrumentation/log_subscriber'

And they get logging goodness like this in their terminal:

The Accuracy

But! BUT, you say. What about the tests? Well, my friend, I have that all wrapped up for you as well. Since it is so easy to pass through an instrumenter to our library, we should probably also have an in memory instrumenter that keeps track of the events instrumented, so you can test thoroughly, and ensure you don’t hose your users with incorrect instrumentation.

The previous sentence was quite a mouthful, so my next one will be short and sweet. For testing, I created an in-memory instrumenter that simply stores each instrumented event with name, payload, and the computed block result for later comparison. Check it:

module Foo
  module Instrumenters
    class Memory
      Event = Struct.new(:name, :payload, :result)

      attr_reader :events

      def initialize
        @events = []
      end

      def instrument(name, payload = {})
        result = if block_given?
          yield payload
        else
          nil
        end

        @events << Event.new(name, payload, result)

        result
      end
    end
  end
end

Now in your tests, you can do something like this when you want to check that your library is correctly instrumenting:

instrumenter = Foo::Instrumenters::Memory.new

client = Foo::Client.new({
  instrumenter: instrumenter,
})

client.execute(...)

payload = {... something .. }
event = instrumenter.events.last

assert_not_nil event
assert_equal 'client_execute.foo', event.name
assert_equal payload, event.payload

The End Result

With two instrumenters (noop, memory) and a belief in interfaces, we have created immense value.

Further Reading

Without any further ado, here are a few of the articles and decks that I read recently related to this.

Fin

Go forth and instrument all the things!

Good Math in beta; Working with TCP Sockets

Good Math in beta; Working with TCP Sockets now available

Ruby 1.9.3-p374

In this episode, Jason and Peter talk about the latest Ruby release, developing iOS applications with Ruby, Kids Ruby, and the usual round up of interesting projects and posts.

Announcing Ember! Master Space and Time With JavaScript Book 4

You have no idea how happy I am to announce that Book 4 of Master Space and Time with JavaScript: Ember is now on sale. You can buy it at http://www.noelrappin.com/mstwjs

It’s not done, of course. But it’s off to a good start, and I think it’s going to be great. Here’s the state of the world:

  • Release 1 of the Ember book is $7, just like its recent siblings. The four book bundle is still $15.

  • Release 1 is about 20 pages of content (plus the same intro, acknowledgments, and so on). It covers setting up the Time Travel app with an Ember front end, then the basic concepts involved in getting data from the server, displaying it to the browser and responding to actions. We basically end at a chapter break, so it’s a contained example, though obviously the rest of the book will take it farther.

  • The code is written against Ember 1.0pre4, which means its current as of yesterday.

  • Unlike some of the other betas, this one has been reviewed by a few people, including people who know more about Ember than I do, so I’m pretty happy with how it’s going so far.

  • We don’t cover testing yet (in part because the framework does so much that there isn’t much logic to test yet). It’s coming, though. Trust me.

  • The plan is for basically weekly releases until done.

  • I don’t know how long this is going to get — to some extent it’s going to depend on the reception, more sales = more encouragement to write. It will be at least in the 100is page range as the previous books. If it gets much longer than that, I may raise the price at that time.

That’s the scoop. Buy it: http://www.noelrappin.com/mstwjs, enjoy it, spread the word.

Thanks

Dataclips 2.0 – Unlock the value of your data

An organization’s data is its most valuable asset. Unfortunately, that data is usually trapped inside a database with few ways to access it by a privileged handful of people. Too often reports are manually generated and their results pasted into emails; dashboards get built but rapidly become outdated and never answer the right questions.

We have so many great tools for collaborating around our source code, why is data still in the dark ages?
At Heroku Postgres, we believe that your data should flow like water. Only the most up-to-date data should be available any time you have a decision to make. Instead of being trapped in disparate systems, you should be able to move data smoothly between development, staging, and production. It should flow across apps, between teams, and between services.

That’s why we built Dataclips, a tool for sharing live query results. Think of it as pastebin for SQL, or gist for your data. Each dataclip is a sharable handle to a live query and is available in a variety of formats.

Read more about the new version of Dataclips 2.0 over on the Heroku Postgres blog and how it can help you gain better insight into your data.

Rails Security Updates

In this episode, Peter and Jason talk about the latest Rails security releases (upgrade now!), Ruby 2.0.0 preview 1, and some cool new projects.

The App Design Handbook; Definitive ANTLR 4 Reference in print

The App Design Handbook; Definitive ANTLR 4 Reference in print

Restraping Enum to your Ruby toolbelt

Where did my Enum go?

Enum is probably one of the things I miss most in Ruby. Not sure why – but as a fairly common design pattern I expected to see it more than I do
in Ruby’s Stdlib (or maybe even Core) and in Ruby / Rails implementations around.

Enum (or Factor if you will) is basically a set of values called members (or elements) that act as a constant and represent some sort of a numeric (mostly integer) value.
It is mainly used to represent a string constant in a numeric way, allowing easier serialization of data representation and avoiding recurring typs of long / annoying strings.

Java, C#, and even our beloved neighbor Python – all provide some kind of an implementation
to Enum as part of their toolbelt, some databases like (MySQL)[http://dev.mysql.com/doc/refman/5.0/en/enum.html], Postgres provide a specific implementation “by the book” for enum types but some
others like SQL-Server (yes, Microsoft again) provide some black magic to achieve an Enum representation:

An SQL-Server spell to create an enum type column
1
mycol VARCHAR(10) NOT NULL CHECK (mycol IN('Oranges', 'Apples', 'Pineapples'))

But, a decent Enum is still missing in Ruby.

Quick draw Enum in Ruby

If you ignore all the fancy words around the Enum definition, you are probably saying to yourself – “Eh, it’s a hash”.

Right.

The most simple way is to create a frozen hash constant that will hold all your constants:

Quick draw simple hash enum in ruby
1
2
3
4
5
6
7
8
class Canvas
  COLORS = {
              0 => :black,
              1 => :white,
              2 => :green,
              ...
            }.freeze
end

testing it out:

Using the quick draw hash enum
1
2
$> Canvas::COLORS[0]
:black

This implementation is rather simple and convenient – but not too easy to maintain and carries absolutely no syntactic sugar.

Note that if you want to access the numeric value via a given constant (ex: Canvas::Colors[:black]) you’ll need to implement external access methods for the frozen hash. Another problem I have with this implementation is that it is too specific, if you want an other class
to use the COLORS “enum”, you’ll need to redefine it again.

Reusable Module Enum

The Reusable module implementation is very similar to the implementation that you’ll find in C#, Python and Java – a free module that
allows the enum to be re-used in multiple classes and is basically all about defining constants:

Reusable Module Enum in Ruby
1
2
3
4
5
6
7
8
9
10
11
12
13
module ColorsEnum
  BLACK = 0
  WHITE = 1
  GREEN = 2
end

class Canvas
  include ColorsEnum
end

class Wall
  include ColorsEnum
end

This form allows code re-using of course, but still lacks the ability to access the enum members by both numeric index and the constant.

Enum by method

Before reaching out to solve the dual access problem (isn’t it annoying to declare constants manually?) lets add some syntactic sugar to the constant definition process.

Generate an enum by method
1
2
3
4
5
6
7
8
9
10
11
12
13
class Object
  def self.enumify(*args)
    args.flatten.each_with_index do | const, i |
      const_set(const, i)
    end
  end
end

class Bowl
  enumify "ORANGES", "APPLES", "PINEAPPLES"
end

p Bowl::ORANGES # => 0

Now we are getting closer. We can’t use this syntactic sugar anywhere in our app to define enums like the big boys do, but it still doesn’t solve our dual access problem.

Enum with dual-access

The feature that almost all the Enum implementations I presented above are missing is the ability to access an enum member by either its value or by name.
The following implementation (original from here) suggests a more robust module based implementation, it adds an object implementation for each enum member to store all member attributes (index for example) and
extends the enum base class with the Enumerable module capabilities.

I used this base class and added some more attributes to the Enum::Member class to also store the actual value and allow dual access to both the key and the value of the member:

Enum with dual access
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
class Enum < Module
  class Member < Module
    attr_reader :enum, :index, :syme

    def initialize(enum, index, syme)
      @enum, @index, @syme = enum, index, syme
      # Allow Color::Red.is_a?(Color) 
      extend enum
    end

    # Allow use of enum members as array indices 
    alias :to_int :index
    alias :to_i :index

    alias :to_sym :syme
    alias :to_s :name

    def name
      self.syme.to_s
    end

    # Allow comparison by index 
    def <=>(other)
      @index <=> other.index if other.respond_to?(:index)
    end

    include Comparable
  end

  def initialize(*symbols, &block)
    @members = []
    symbols.each_with_index do |symbol, index|
      # Allow Enum.new(:foo)
      symbol = symbol.to_s.sub(/^[a-z]/){|letter| letter.upcase}.to_sym
      member = Enum::Member.new(self, index, symbol)
      const_set(symbol, member)
      @members << member
    end
    super(&block)
  end

  def all
    all = {}
    @members.each_with_index do |member, index|
      all[index] = member
    end
  end

  def [](val)
    if val.is_a?(Numeric)
      @members[val]
    elsif val.is_a?(Symbol)
      @members.select {|member| member.syme == val }.first
    elsif val.is_a?(String)
      @members.select {|member| member.name == val }.first
    end
  end

  def size
    @members.size
  end

  alias :length :size

  def first(*args)
    @members.first(*args)
  end

  def last(*args)
    @members.last(*args)
  end

  def each(&block)
    @members.each(&block)
  end

  include Enumerable
end

Lets focus on the Enum#[] method in line 49:

Enum#[]
1
2
3
4
5
6
7
8
9
def [](val)
  if val.is_a?(Numeric)
    @members[val]
  elsif val.is_a?(Symbol)
    @members.select {|member| member.syme == val }.first
  elsif val.is_a?(String)
    @members.select {|member| member.name == val }.first
  end
end

This method allows the dual-access mode I discussed before when doing the following

  • When getting a Numeric value as a parameter it checks it against any memeber’s #index attribute
  • When getting a string it compares it to the #name attribute.

Voila!

This implementation stores the member list in an array member named @members and delegates manually all the Array and Enumerable methods to this array member.
Seems like we can simply inherit from Array and drop all these delegation methods.

Ruby Set based Enum

Set implements a collection of unordered values with no duplicates. By using Set as a parent we inherit its ability to
traverse members, we don’t need to implement and manage delegation to an array member and we don’t need to create constants (I’ll discuss that later in this article):

Set based ruby Enum
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
require 'set'

class Enum < Set

  class Member

    include Comparable
    attr_reader :symbol
    attr_reader :index
    attr_reader :name

    def initialize(value, index = 0, name = nil)
      @symbol = value.to_sym
      @index = index.to_i
      @name = name ||= value
    end

    def <=>(other_member)
      self.symbol <=> other_member.symbol
    end
  end

  def initialize(*members)
    super()
    populate(members)
  end

  def to_a
    super.sort_by(&:index)
  end

  def each
    block_given? or return enum_for(__method__)
    self.to_a.each { |o| yield(o) }
    self
  end

  def [](index_or_symbol)
    if index_or_symbol.is_a?(Symbol)
      return self.select {|member| member.symbol == index_or_symbol }.first
    elsif index_or_symbol.is_a?(Integer)
      return self.select {|member| member.index == index_or_symbol }.first
    end
  end

  protected

  def populate(members)
    members.each_with_index do |member, index|
      self.add(Enum::Member.new(member, index)) unless self.to_a.collect(&:name).include?(member)
    end
  end
end

First, I’ll focus on the #populate method. This method is fired when #initialize finishes and appends all members applied to the Enum set.
Line 50 is where all the magic happens – it creates a new Enum::Member and adds it to the set, unless it already exists.

Wait! Aren’t set members already unique by default?

Yes, they are. But this implementation runs into a Ruby brick wall. The ruby Set keeps an internal hash (named @hash surprisingly) that holds the member as keys and sets a value of true for each one when they are entered.
Further more, Set#include? is delegated to Hash that on its turn – runs a native C code that compares objects directly.

In our case it will result in something like this:

Hash#include?
1
Enum::Member.new.object_id == Enum::Member.new.object_id

Which, no matter if both members have the same attributes, will return false.

Set#include? does not exercise the Comparable module convenience I included in Enum::Member, so we need to do a comparison on our own.

And why didn’t you use Constants?

It is easy and smart to use constants when you can take care of any naming conventions and constant name limitations that Ruby introduces, in our case
we allow Enum::Member to initialize with any kind of string, even ones that don’t pass the constant name restrictions, some examples are:

Constant naming limitations
1
2
3
4
5
6
7
8
Enum::Member.new("888betonline", 0).symbol #=> :"888betonline"

# Same in a constant
Object.const_set(888BETONLINE, 0)
SyntaxError: compile error
(irb):10: syntax error, unexpected tCONSTANT, expecting ')'
User.const_set(888BETONLINE, 0)
                           ^

Since we don’t know or even want to restrict our enum value names, dropping the constant convention out of the loop seemed like the right thing to do.

Update: A clean, simple and perfect Hash

After this post was published, a talked to my friend Daniel about the Set implementation. He suggested the the Set usage is
not required since that #include? bug causes me to write the presence test myself and that anyway, I traverse the members myself so the Set has no meaning.

he later came up with this suggestion:

Simple hash enum
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Enum < Hash
  def initialize(*members)
    super()
    @rev = {}
    members.each_with_index {|m,i| self[i] = m }
  end
  def [](k)
     super || @rev[k]
  end
  def []=(k,v)
    @rev[v] = k
    super
  end
end

enum  = Enum.new("Apples", "Oranges")

enum[:Apples] # => 0
enum[0]       # => :Apples 

This solution, not only answer the dual access requirement – but it drops the need to use an internal Enum::Member inclusion. Definitely a winner

Conclusion

Ruby misses a real enum implementation. I would be happy to see an official one come out in one of the next releases. Until then the Hash implementation is something I will be using.

Source available here, fork away.