German Jet

Архитектурные принципы не очень связаны именно с нодой, они будут примерно одинаковыми, на каком бы языке вы не писали. Первое, что я могу посоветовать, когда Вы переходите от технологий программирования к архитектуре систем, это как переход от кладки кирпича к архитектуре зданий - нужно отложить все шаблоны, которые Вы знали до того и подняться на другой уровень абстракции. А именно, нужно перестать мыслить такими понятиями, как DI (dependency injection), REST, MVC, ORM, RPC, шаблонизаторы, компоненты, сокеты, промисы и прочее - это все технологии. Что же нужно понять это: слои (layers), модули, контракты, адаптеры, клиент-сервер, 3-звенная архитектура, микросервисы, СМО (системы массового обслуживания), и т.д. Где так все собрано в одном месте - не могу сказать, я лично по крупицам все осваивал, на что положил 20 лет профессиональной деятельности. Почитайте про ISO/OSI, загляните в три мои статьи habrahabr.ru/post/227753 и habrahabr.ru/post/204958 и habrahabr.ru/post/117791 Раньше хорошие статьи по архитектуре были на www.osp.ru но, к сожалению, давно не читал его. Можно начать с книг Гради Буча и освоения UML, этот дядька сформировал достаточно полный подход и методологию проектирования программных систем, которая ведет правильным путем, но на практике, в каждом отдельном случае может быть заменена интуицией архитектора и существенно упрощена. Удачи!

Я РНР-разработчик, не так давно решил разобраться с рельсами. Сейчас я назову несколько абсурдных вещей, которые в общем-то являются достоинствами, но есть некоторые проблемы...

Для клиента:
1. Нету вордпресса. Да! Как только вордпресс перепишут на руби, его сразу начнут использовать все, кому не лень:)
2. А можно мне сайт на джумле? Просто у нас контент-менеджер уже привыкла к её админке.
3. А почему хостинг стоит 200 рублей? У меня сосед по офису вон за 40 купил.
4. "Нет уж, лучше я найму этого пацана за 3 доллара в час, который мне всё сделает, чем вон того говнюка за тридцатку, который говорит про какой-то руби, что это вообще такое? Мне просто нужен сайт на вордпрессе."

Для программиста:
1. А где фигурные скобочки?
2. Магия. Очень много магии. Оно всё делает "само", вплоть до квази-версионирования базы данных по датам. К этому надо привыкнуть, что не все готовы делать.
3. У меня заняло два дня, чтобы смочь подключиться к mysql. Возможно, я не самый опытный программист, но обилие вопросов на stackoverflow и не только наводит на мысль, что половина желающих отсеялась на этом этапе и пошла ставить вордпресс.

Нувыпонели. Недостаточно популярная (чтобы с энтузиазмом приниматься заказчиками) технология с непривычным для многих подходом и вообще синтаксисом языка (чтобы с энтузиазмом приниматься программистами). И ещё на ней нет вордпресса.

А, кстати.

Почему еще НЕ ВСЕ сайты делают на Rails?

Просто на них вордпресса нет.

P.S. ненавижу вордпресс, если что.

У меня возник закономерный вопрос, есть ли какие-то критические недостатки, которые эту технологию делают не такой популярной как php c его множеством фреймворков и CMS.

Популярность PHP, на мой взгляд, имеет следующую природу:
1. На заре интернета большинство людей были неподготовленными, они не имели навыков программирования, системного администрирования, верстки и т.д.. Большинство сайтов в то время были обычными статическими html или текстовыми страничками. То есть для того, чтобы сделать сайт надо было нанять программиста(верстальщика) и/или системного администратора, чтобы разместить, добавить или изменить информацию опять же нужен был обученный человек.
Интернет рос и развивался и вот, в какой-то момент, возможности статических страничек стало не хватать и их начали генерировать динамически. Но, опять же, простому пользователю который хотел домашнюю страничку, блог или простенький интернет магазин такие "развлечения" были недоступны в силу недешевой рабочей силы.
И тут на сцену выходит PHP (а особенно 4 ветка, дальше все в контексте 4 ветки и выше) с его потрясающей легкостью деплоя. RoR тогда еще не было, да и сам Ruby за пределами Японии не имел широкой известности. Ну так вот, с выходом PHP4, практически любой пользователь мог самостоятельно развернуть приложение на нем, просто скопировав папку по фтп, да и организовать хостинг под PHP было намного легче чем, например, под Java. Спрос рождает предложение. Начали появляться различные, как платные, так и бесплатные CMS на PHP, дешевые хостинги. Пользователь, который хотел дополнительный функционал для своего сайта, мог не нанимать программиста, а просто купить или найти бесплатный модуль под свою CMS. Это породило большое количество PHP программистов которые писали модули под популярные CMS-ки. В дальнейшем приложения стали более сложными и решали нестандартные задачи, а PHP программистов было довольно много и порог вхождения в язык был невелик, так начали появляться PHP фреймворки.
2. PHP при каждом запросе "рождается" и "умирает" в следствии чего неподготовленному пользователю, опять таки, легче устанавливать модули, темы, плагины и т.д. для своих CMS-ок. В RoR (unicorn) при установке gem-а придется перестартовать сервис, зачем такой геморой пользователю? Да и чтобы его(gem) установить, надо обладать некоторыми навыками программирования, а непросто щелкнуть мышкой в админке.

А вот в сложных и не стандартных проектах, с длительным сроком поддержки, все уже не так очевидно... Наверное паритет... Тут их хватает и на PHP, и на Ruby, и на Python, и на JVM...

О языках для аналитики замолвлю словечко.
Python - классный, удобный. Большой набор библиотек для работы с данными, мало специфичных функций для статистики (легко реализуются самостоятельно).
Минусы - все в памяти (pandas Memory Error), 2to3 не для всех библиотек
Плюсы - есть API практически ко всему на свете (а к чему нету, легко прикрутить). По поводу памяти тоже слукавил, есть например pyspark в spark 1.3 в котором классный API именно для аналитиков.
R - если есть время врубаться в несколько нелогичные названия функций и желание получить доступ к огромному количеству удобных пакетов для глубокого анализа - отличный.
Масштабируемость - Oracle R Enterprise/DistributedR/RevolutionR - но это не для опенсорса.
Еще можно попробовать для аналитики - Scala,Lua, Julia (кстати очень быстрый язык).

Сложнее в изучении, много подводных камней, в основном связанных с настройками сервера, и нюансами которые нужно один раз побороть, и больше с этим проблем не будет.

Не сложнее, просто их надо понять и принять.

Проблемы с хостингом. Нету по доступным ценам специализированного Rails хостинга. Приемлемый вариант это VPS/VDS, минимум я нашел 200 рублей, против php хостингов которые идут от ~1$.

VPS сейчас дешевые можно найти, а еще есть бесплатный Heroku для небольших проектов

Относительно мало документации/how-to на русском языке.

Она и не нужна. Без английского с фреймворками делать нечего.

Почему еще НЕ ВСЕ сайты делают на Rails?

Потому что полно пхп разработчиков, которые сделают дешевле, а рубистов еще найти надо. Ну и для визиток рельсы не подходят, хотя есть всякие Padrino, но на них потом еще сложнее кого-то найти. В общем, заказчикам этот геморрой не нужен.

А из минусов ничего не могу сказать. Технология, которая позволяет сделать ВСЕ, причем с изюминкой. Познавать нужно, а не минусы искать :)