Color customization for Material Theme in VSCode 1.11.1


Recently I have switched to use VSCode IDE for Ruby and Elixir development.

And as I like to use Material Theme in editors (initially inspired by Sublimes Material theme), the same exist for VSCode. But not all panels are colored in Material colors (due to previous VSCode API limitations), and vscode-custom-theme extension helped with this (but now there is no need in it).

Since v1.11 VSCode has build-in support for color customization

"workbench.experimental.colorCustomizations": {
       "panelBackground": "#2f333d",
       "tabsContainerBackground": "#2f333d",
       "inactiveTabBackground": "#2f333d",
       "sideBarBackground": "#2f333d"

This preset works for me to have a complete look of VSCode Material Theme

A Little Trailblazer Cookbook

Trailblazer is a high-level Architecture libraries for the Ruby web application (not only for Rails). If you are no familiar with it yet - take a 20 minutes walk through guide...

I want to cover once again those places where our team had issues or misunderstanding. Trailblazer documentation got a lot of improvements recently and keep getting more and more care. Some points from this list are covered by the docs, but in practice not everything was smooth.

Read more ...

Metaprogramming in Ruby lib: beauty vs usability

Recently I have evaluated different HTTP request wrapper libraries for Ruby project. Took 3 most popular: Faraday, RestClient, HTTParty. And found an interesting fact that illustrates very common issue in the world of Ruby libs.

Metaprogramming is used for the sake of Metaprogramming - "because it is Ruby and I can do it like this...". Not to make end-user developer life simpler.

Let's see the main purpose of HTTP request lib - is to send HTTP request (GET, POST, etc.). And the main purpose should dictate public interface of the lib classes. It should have a generic method to do any kind of HTTP request + shortcut methods to do the most common requests, like GET and POST.

That is what all these libs have

# kind-a this
# or this, body_params_hash)
# it doesn't really matter is it static or object method

The issue is - these methods get/post are not real. For some reasons lib author try to spare 10 lines of code, but to use "cool Metaprogramming approach". The consequences of this - I am as an end-user of this lib, can't Ctrl+Click on post method in my IDE to see how it is implemented and what's happen inside. Because this method does not really exist in class, it appears in runtime after class_eval or define_method. I can't even find the place in Gem where it defined without getting deep in internal implementation. That is a bit frustrating for me. These 3-5 methods are the most important parts of such a lib, I don't care about all other parts, but exactly these parts are hidden from me. And for what good reason?

Proof Faraday

 %w[get head delete].each do |method|
      class_eval <<-RUBY, __FILE__, __LINE__ + 1
        def #{method}(url = nil, params = nil, headers = nil)
          run_request(:#{method}, url, nil, headers) { |request|
            request.params.update(params) if params
            yield(request) if block_given?

Proof RestClient

POSSIBLE_VERBS = ['get', 'put', 'post', 'delete']
POSSIBLE_VERBS.each do |m|
  define_method(m.to_sym) do |path, *args, &b|
    r[path].public_send(m.to_sym, *args, &b)

Only HTTParty has explicit declaration of these methods . Thank you guys, you rock! :)

    def get(path, options = {}, &block)
      perform_request Net::HTTP::Get, path, options, &block

As we can see it is 3-5 line methods. There is no any problem to write them explicitly and hardcode method name inside them + extract all repeating lines inside a separate method. That is absolutely normal code design approach. Instead of sacrificing code simplicity and readability of favor of code size.

Read more ...

Ruby (on Rails) ecosystem bittersweet or "we like to hate PHP"

I am putting some facts and personal experience to prove that PHP has healthier, more competitive and loosely-coupled ecosystem, than Ruby. I am talking about Performance, Syntax and Coding aspects, Community and Tools support.

If you want to skip a lot of empty rant - scroll till the "The main part goes here..." heading :) But I need to say all of this...

What? Yet another anti-RoR rant?

Yep, I started to gather materials for this posts more than 6 months ago, and I know about all that discussions that are going around RoR's pros and cons recent weeks. The main are "My time with Rails is up" and Rails has won: The Elephant in the Room. I am definitely not so experienced in RoR to say something new, that hasn't been said yet in terms of architecture. I just want to argue on Rails leadership in web development.

[PHP] ... fragmented, independent and isolated communities ... is one big ocean of disconnected islands.

Says AkitaOnRails, and as always that's true from one side, but not true - from another. Dear Rubyists let me show you the world of the closest competitor - PHP. And there is nothing special in Ruby for "Basecamp-like" app, that we can't find in PHP.

Read more ...

Ruby Web Dev: The Other Way [Draft release]


Read th most recent version of this guide here I have transferred it to GitHub Pages with custom domain.


This guide is born after a question "Could you write a list of all the things, that a good RoR developer should know?". I decided to expand it to a whole Ruby Web development and related “Full Stack” skills (but also limit it to "Web", as it is not about Ruby in general).

I am inspired by "PHP The Right Way" guide format (and advises). So this guide also contains sections dedicated to very important aspects of web dev, some explanation (if needed) and list of tutorial links.

Sometimes I will suggest some tools or Gems (with comparison if possible), but it is only to have a starting point. It is up to you to decide "use it or not".

Important notice. All suggestions in this guide is my personal opinion. It is not an absolute truth or a 100% best practice. I just want to suggest the best I know.

Also this guide is not complete tutorial - some clear steps like installing Ruby (via rbenv or rvm), managing dependencies via Bundler, etc. are not described due to wide coverage of these aspects in other tutorials (and there are no fatal issues regarding of e.g. how you install Ruby, if it works – that's fine).

Why not "Ruby On Rails" and not "The Right Way"?

I am glad you are asking! :)
It is not a secret that most of Ruby Web Dev came in Ruby via Rails. That is good and bad simultaneously. It simplifies the entry barrier, but also narrows knowledge range. This guide have special RoR section to cover some RoR-specific things, but mostly it will encourage you to look outside of Ruby on Rails and especially “Rails Way”. And I can't call the way described here as "The Right Way". It is just another way to look on common things.


  • Prefer simple solutions (Occam's razor)
  • Configuration over Confusion
  • Boilerplate over Magic

Read more ...
Kuzminov "iJackUA"
Web Team Lead
at MobiDev (Kharkiv, Ukraine)
Code in Ruby and Elixir, but still love PHP. Explore ES6 and Vue.js. Explore databases, use Ubuntu and MacOS, think about IT people and management