German Jet

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

Для клиента:
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, но на них потом еще сложнее кого-то найти. В общем, заказчикам этот геморрой не нужен.

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

1. Собака не имеет никакого отношения к include. Это не один оператор, а два совершенно разных оператора.
   
2. Увидев @ в коде ты можешь почти со стопроцентной уверенностью сказать, что его писал неграмотный пользователь, и пользоваться этим кодом не стоит.
   
3. Увидев в коде @include ты можешь смело считать его автора абсолютным лохом и нубом, а сам код надо выкидывать немедленно. Потому что @include глушит не только саму ошибку включения файла, но и все ошибки в этом файле - то есть, поступает стократ хуже. Это значит, что если автор допускает такие косяки в коде, то и все остальное у него тоже ад кромешный.
   
4. Самое главное. Ошибки надо не подавлять. Ошибки надо исправлять. Но опять же, делать это с умом. Начинающие программисты считают сообщения об ошибках своими личными врагами, и борются с ними всеми доступными средствами - с помощью @, error_reporting(0) и др. Получив линейкой по рукам и запомнив на всю жизнь, что так делать не надо, ониначинают с не меньшим рвением писать всякие проверки - лишь бы не допустить, не дай бог, ненавистного сообщения об ошибке. Например:
   
   

if (file_exists($inc))
{
    include $inc;
} else {
    echo "Файл не найден";
}

Так вот, это - еще хуже. Для начала, часть ошибок этот код все равно не отловит. Но это даже не самое главное. Главное - что вот это вот "Файл не найден" не имеет ни малейшего смысла. Пользователю оно ничего не скажет. А программист о нем не узнает. А если и узнает, то ничего не поймет! Какой файл? Где не найден? По какой причине? Системное сообщение об ошибке содержит массу бесценной информации помогающей идентифицировать ошибку, сообщая нам где она произошла, какой файл не найден, по какой причине не найден. Выдавать вместо этого огрызок "файл не найден" - это мазохизм.

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

Ошибки не надо подавлять. Ошибки не надо прятать. Ошибки надо исправлять.

Мартин Фаулер круто пишет обо всех паттернах. Про DI можно почитать тут. Вообще у него отличный блог. И он же автор книги P of EAA. Правда русский ее перевод крайне не рекомендую читать, можно только запутаться, так что читайте в оригинале.

Если хотите разобраться с паттернами, то самая простая (и при этом дельная!) книга - это Фриман&Фриман. Ее можно читать и на русском.

Применительно к PHP - вот лучшая книга про шаблоны (и не только), которую я видел PHP. Объекты, шаблоны и методики программирования от Мэт Зандстра.

Порядок прочтения рекомендую следующий: Фриман&Фриман, затем Мэт Зандстра, и на десерт Фаулера P of EAA.

UPD:
Важно отличать паттерн Dependency Injection от Dependency Injection Container.
Простейший пример внедрения зависимости:

interface IEngine {}
 
class V8Engine implements IEngine {}
 
class Car {
  public function __constructor(IEngine $engine) {
    $this->engine = $engine;
  }
}
 
$car = new Car(new V8Engine());

Простейший пример игнорирования явного внедрения (для такого кода трудно писать unit-тесты, его труднее понимать и править):

class V8Engine {}

class Car {
  public function __constructor() {
    $this->engine = new V8Engine();
  }
}

$car = new Car();

Отличный (и легковесный) пример DIC - это pimple:

// define some services
$container['session_storage'] = function ($c) {
    return new SessionStorage('SESSION_ID');
};

$container['session'] = function ($c) {
    return new Session($c['session_storage']);
};

Советую прочитать и понять его исходники, чтобы убедиться, что в DIC (во всяком случае для PHP) нет никакой магии. Первая версия была всего ~100 строк. Необходимо также отметить, что класс Session использует шаблон Dependency Injection, явно определяя свою зависимость от SessionStorage. А контейнер делает лишь правильную связку.

И да, контейнер сам по себе можно использовать как service locator, если к нему, например, есть глобальный доступ. Но это очень плохая практика, потому что если что-то обращается к сервис локатору, то формально оно начинает зависеть сразу от всех компонентов системы.