Category Archives: Ruby
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.
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.
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.
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.
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.
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.
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.
- Wicked Good Ruby 2013 – Understanding Ruby’s Method Cache
- Speakerdeck – Understanding 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 OpenStruct.new 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.
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.
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.