Category Archives: Ruby

Watching – Writing a Test Framework from Scratch

Building up a simple test runner by example. It’s a great way to explain how the testing framework is doing. The testing framework is relatively simple for most of the scenarios. Learn by doing is a good practice.

Watching – the Changelog #202: 23 Years of Ruby with Matz

The Changelog podcast is interviewing with Matz this week. I had listened many Matz interviews, but this is one of the good ones to intensively covers the origin and early history of ruby. Even now, new languages are keep appearing after years of computing history, and it’s good to know how the languages are born and grow.

Mono Timer – Pomodoro-style timer on Ruby on Rails

Recently, I just learned about Pomodoro Technique, and started applying on my daily life, as indicated in the post before.

There’re many good applications which implements the pomodoro-style timer, but I couldn’t find good one which consistently works on laptop and mobile. Then, I came up to create one for my specific needs, and also for my study on Ruby on Rails application development.

It’s initial implementation yet, but I will be adding some more capability for fighting against my procrastination habits.

Ruby Rogues Code Reading – Dotenv

Ruby Rogues Code Reading

A nice code reading session on dotenv by ruby rogues.

dotenv is an environment variable loader for ruby. It’s a simple library, but there’re some edge cases around parsing and loading setting from the .env file, and resulted in a good session about some good ruby techniques.

It talks about

  • difference between protected and private
  • enumerator behaviors with inject and each_with_object method
  • composing complex regexes with multiple sections and recursions
  • parsing quoted and unquoted variables in the .env file


Looking for another session.

Vim and Tmux

Chris Hunt – Impressive Ruby Productivity with Vim and Tmux – Ancient City Ruby 2013

A nice talk on Vim and Tmux features. I’ve once tried Vim several times, but ended up with Sublime after certain amount of struggling. But, every-time I see the expert vim user operations, I become inclined to try it again.

I haven’t tried Tmux before, and played around some after waching this. Basically, it works nicely, but haven’t been able to key factor to change. I don’t usually use so many windows, and basic terminal tabs and the following bashmark is good enough. Maybe need to look into a little more deeper.

Riak at Ruby Rogues Podcast

139 RR Riak with Sean Cribbs and Bryce Kerley

A nice episode of riak, which is a erlang-based distributed database. It talks about its feature-set, how/where to apply, and some technical backgrounds around replication/partitioning. Also, the podcast page has a lot of references to the great resources, like Amazon’s Dynamo, CAP Theorem, etc.

As Elixir is coming around, erlang may be getting more attention in ruby community. Though its programming-model is quitely different from ruby, nice ruby-syntax pretty much reduces the threshold for trying out.

I haven’t been able to get deep into this different programming model (concurrency, fault-tolerance provided through process and supervisor), but I would like to be working on in near term by using affordable Vagrant and DigitalOcean/Amazon AWS environments.

Watching Question for Matz

Ruby Conf 2013 – Question for Matz

It’s a nice Q&A session which talks about ruby history and now and futures, with funny interactions. At around 6:00, one question was what could be different if you resigning ruby now. One of the answer is about the concurrency, existing thread vs actor models. It’s interesting that many of the object-oriented languages are introducing actor based modeling features.

Ruby is equipped with Fiber for lightweight threading, but its mutable nature and performance penalties might be sometimes difficult to super-concurrent programming. Along with JRuby and Rubinius, how ruby will be going for this area may be an interesting topic to keep watching.

Learning on Ruby’s Method Cache

Just watched the above explanatory video on ruby’s method caching. Maybe it’s a little old topic which is mostly about ruby 1.9 change, but it was a nice resource for me (which means I didn’t know much about this topic).

It talks about the ruby’s dynamic method resolution, and how MRI is implementing the caching of method dispatch, like the following.

  • Ruby allows defining methods dynamically and it’s required to check the class and module hierarchy every time methods are called. To alleviate the cost, method caching is introduced in ruby 1.9, but yet there is performance penalty in defining methods due to cache busting.
  • The method cache is maintained globally with a generation counter, and once generation is incremented, all the cache becomes invalidated, and need to pay the price again. Even a innocent-like internally defines singleton method, and causes the expiration of global cache.

I didn’t know the caching is maintained globally, and the blog post (MRI’s Method Caches) is talking about improving by limiting the scope. Also, I can see the JRuby’s doc (JRuby Internal Design) talks about caching too, and I need more research on this one.

This kind of dynamic feature and mutable nature of the language is a major advantage of ruby, but the performance penalty also comes with it. With this in mind, the immutability in core framework sounds more like an interesting approach, as Scala or Elixir(Erlang) is advocating.

Boundaries – Functional Core and Imperative Shell

Designing module boundary is an important factor on developing a software. As it grows, number of paths and its combination grows exponentially. Then, it becomes difficult to pick paths to test, since it’s not feasible to test all the possible paths.

One idea is to isolate modules into smaler pieces by making “values” as boundary, rather than the message communications. It reduces the dependency, and removes the complex mocking codes.

Another idea is to seperate modules into 2 different types, which are functional core and imperative shell. Functional core provides logics in a isolated manner. It has few dependencies and many paths, which is suitable for unit testing. Imperative shell provides the adapter functionality wrapped around the core. It has many dependencies and few paths, which is good for integration testing.

Evented Ruby vs Node.js @ YouTube

RailsConf 2012 Evented Ruby vs Node.js by Jerry Cheung

An introduction for event-based programming in ruby. It’s mainly about EventMachine, but it nicely describes the behaviors of event-based model, about where or when I/O blocking is happening. Also, it talks about the importance of hiding the complexity of process-handling from the usage interface. For example, faraday http library can switch its handler to EventMachine with the same interface.

EventMachine is a nice library, which is simple enough to program.
But, as indicated in the presentation, it would have smaller community compared with node.js one, which leads into lack of information. Also, built-in event-based paradigm in node.js enforces all the libraries works on this model. In ruby, single event-unaware component of the stack can block the process which becomes the bottleneck.

Recently, many languages and libraries are advocating on the non-blocking concurrency models. This kind of tutorials would be great to understand the backgrounds and how to use them appropriately.