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 ...

EcmaScript 2015 / ES6 or how backend developers lost JavaScript...

tl;dr; A humble point of view of an average backend/"full stack" developer on JavaScript. How it evolved, how backend devs stayed in JavaScript 2010 and how the gap between jQuery-JS and ES6-JS became an abyss.


Let's wrap up some terms that I'll use further:

  • Backend developer - a person who writes PHP/Ruby/Python/etc. server-side code.
  • Frontend developer - a person who writes complex JS/CSS/HTML.

It is about specialization. Of course all web devs are a little bit "full-stack", but only a super guru are really "full-stack".

Once upon a time...

I remember the times 15 years ago when JS world was a total mess.
For me, as a beginner home-made web developer, it was a black magic.
It was hard.

I was making some PHP sites, generated everything at backend side. Sometime I needed some "bells and whistles". You could copy-paste some "pretty gallery or dropdown menu" from some "JS libs site". And you were lucky if it worked for you. If not - there was literally no way to get "what is happening there" and the JS code was just ugly mess (at least how I saw the situation at that moment).
It was hard.

Year 2006 blown web dev world ... jQuery.
Anyone could make some easy JS trick really easy with jQuery. And more over it had such a cool plugins system. You just add some "pretty gallery plugin" and attach that gallery with simple selector. There were clear "entry points" for customization.
Then AJAX epoch. And again jQuery made it as simple as $.ajax. All that things made JS world easier, simpler to backend developer (actually we were more like full-stack in that time).
It became easy.

But "the world has changed...". SPA and cross-platform JS mobile apps appeared. First it was "ugly-toys", but then it appeared to be serious. jQuery is not enough to make SPA or a big JS app.
Backbone came to the rescue. It was hard to get some things, but it was so "jQueryish". It literally added some app structure, but allowed us to use the same old-known things we had before (that was actually the key to adoption).
It was kinda easy too.

Dark times...

One day it just exploded: Node.js, Phonegap, Konckout, jQuery Mobile (*trollface*), thousands of Backbone-based frameworks, Marionette, Angular...

Some backend devs tried to follow, but honestly - for example it is too hard to follow your PHP news and keep yourself up-to-date with every JS framework. Someone took Node.js and became happy, someone chose Backbone-based things and decided to dive in there.

Read more ...

Learning Elixir lang - my first steps

I have heard of Elixir in late 2015. Strong Ruby developers just started to write something about it in their Twitter accounts - that it is a functional programming language and one can do a blazing fast realtime web apps with it.

Then I have watched this intro video, made a quick look on Phoenix framework, read really inspiring comparison "Phoenix is not Rails" and my inner Magpie Developer was alarming "looks so awesome, you must try it !". I couldn't stand :)

I have started from the very beginnig. A few pages of Elixir lang introductions. Then first "hello world" Phoenix application. And... ok, just try to breath deep and calm after 4 ms response time... it is just a dummy page with static HTML (but all routing and Plugs infrastructure involved). But it already makes an impression, as PHP shows the same speed only with empty echo "hello world"; script :)

Phoenix web framewok app structure is pretty clear at the first look. And surprise - it uses Node.js/NPM + to manage and compile assets by default - good start, not inventing the wheel!
It introduces a lot of new concepts compared to RoR. Of course it has not clear yet WebSockets endpoints etc., but in general by mixing it with my knowledge of middleware (Plugs in terms of Phoenix) implementations in Ruby, Node.js and PHP - I see a way to go further.

Erlang and functional programming

But wait. Have I told you that Elixir is working on Erlang VM? That is well-known and rock-solid foundation. It has Ruby-inspired syntax, but not Object Oriented, it is Functional. And that is another reason to try it out - to make your coding paradigm wider. It really breaks all patterns of data flow in web app (that were made of concrete after years with PHP, JS and Ruby). I definitely love pattern matching concept, piplines and absence of "internal state". And these lightweight threads - I could not even dream about such things in PHP :)

Next steps

Get deeper in Elixir lang docs, walk through Phoenix docs and writing some basic "blog app" to see Phoenix in real action.

And as usual some resources collection to get started and move further...

Read more ...
Kuzminov "iJackUA"
Web Team Lead
at MobiDev (Kharkiv, Ukraine)
Code in PHP and Ruby, play with JS/Node.JS, evaluate Elixir, explore databases, use Ubuntu and MacOS, think about IT people and management


Staticman - handles user-generated content for you and transforms it into data files that sit in your GitHub repository, along with the rest of your content.