Comments 34
Ну, что сказать, отличный инструмент. :)
Многие технологии попадают в тренд, у многих есть пик популярности, но факт, что у Rails своя ниша будет всегда.
Активно пользуюсь пол года, сообщество и сейчас очень большое.
Многие технологии попадают в тренд, у многих есть пик популярности, но факт, что у Rails своя ниша будет всегда.
Активно пользуюсь пол года, сообщество и сейчас очень большое.
UFO just landed and posted this here
Мода ушла, хороший инструмент остался. Это нормально, одна технология не может вечно быть в фокусе внимания. Для классических (не реалтаймовых) сайтов рельсы все равно остаются одной из лучших доступных платформ.
UFO just landed and posted this here
EventMachine, Twisted и т.п. Под рельсы есть удобный Faye, который решает часть задач реалтайма (какие-нибудь уведомления пользователям отправлять — самое то).
Но конкурировать им не обязательно, лучше просто применять наиболее подходящий для конкретной задачи инструмент. Ведь никто не запрещает использовать и рельсы и ноду в рамках одного проекта.
Но конкурировать им не обязательно, лучше просто применять наиболее подходящий для конкретной задачи инструмент. Ведь никто не запрещает использовать и рельсы и ноду в рамках одного проекта.
UFO just landed and posted this here
Если брать только ноду, то есть, например, SailsJS, выглядит очень интересно. Тут уже смотря что нужно от платформы. Для чего-то простого и Sinatra/Flask/Express неплохо сгодятся, а вот если хочется много проверенных временем плагинов и админку, то тут уже Rails/Django могут оказаться лучшим выбором.
django? =)
Сейчас в моде минимализм, поэтому часто гораздо проще уговорить человека взять маленькую библиотечку, даже если потом он накачает ворох других библиотек и модулей, чтобы решать сопутствующие задачи, чем убедить его в том, что будет лучше взять готовый комбайн.
В мире Руби это случается сплошь и рядом: люди думают «я сделаю проект гораздо проще, если возьму вместо Рельс Синатру», а потом их gemfile начинает расти, и расти, и расти, — пока суммарно приложение не сравняется по объему зависимостей с аналогичным на Ruby on Rails.
В мире Питона та же история: люди часто скачут между Django и Flask (или аналогами). Так же модно взяться за Node или Go, а потом наплодить микросервисов, каждый из которых концептуально прост, а вот все вместе — каша.
Бывают, конечно, и удачные примеры минимализма в мире разработки, но не так часто, как это может показаться.
В мире Руби это случается сплошь и рядом: люди думают «я сделаю проект гораздо проще, если возьму вместо Рельс Синатру», а потом их gemfile начинает расти, и расти, и расти, — пока суммарно приложение не сравняется по объему зависимостей с аналогичным на Ruby on Rails.
В мире Питона та же история: люди часто скачут между Django и Flask (или аналогами). Так же модно взяться за Node или Go, а потом наплодить микросервисов, каждый из которых концептуально прост, а вот все вместе — каша.
Бывают, конечно, и удачные примеры минимализма в мире разработки, но не так часто, как это может показаться.
Интернет поменялся, логика плавно перебирается с серверной стороны на клиентскую. Фокус смещается в сторону клиент-сторонних фреймворков, таких как Angular, Ember, Backbone. И рельсы по прежнему прекрасно работают, но уже больше как просто как API, удобный и знакомый рендерер шаблонов для клиентской стороны и сборщик ассетов для неё же. Кстати, уже создано много библиотек для того, чтобы дружить Angular и Rails.
UFO just landed and posted this here
И это ужасно. Были у нас одни клиенты, которые делали пагинацию на фронтенде, выкачивая десятки страниц с бэкенда. А еще они лепили вотермарк на картинки динамически, на фронтенде. Впрочем, не хочется о грустном.
UFO just landed and posted this here
Это верный путь развития ввиду все большего разнообразия точек входа для доступа к информации. Пишем одно API (можно на Rails), а дальше можно делать абсолютно разные фронтенды для десктопов, мобильных устройств, различных умных железяк.
И если API написано и задокументировано правильно, то выкачивать десятки страниц не придется. В случае с пагинацией достаточно передать параметр, ограничивающий вывод элементов на страницу и номер страницы.
И если API написано и задокументировано правильно, то выкачивать десятки страниц не придется. В случае с пагинацией достаточно передать параметр, ограничивающий вывод элементов на страницу и номер страницы.
Angular — потрясающий инструмент, я просто был реально ошеломлен, когда увидел в действии как работает databinding в нем.
Но в тоже время, мне нравится подход DHH, который звучит примерно так: сервер всегда мощнее даже самого мощного десктопа, потому что он под это заточен.
Поэтому логичнее на клиент отправлять уже готовый HTML, отрендеренный на сервере, а на клиенте только замещать элементы.
У них Basecamp, как я знаю, так работает. В одном выступлении он показывал, что если открывается форма редактирования — она вероятнее всего приходит с сервера и просто вставляется в контейнер (он говорил они такие элементы даже не рендерят, а сразу отдают из хранилища типа memcached).
Хотя это и увеличивает трафик, но на клиенте сохраняется достаточно простая логика и это будет работать везде без тормозов и отклик сайта получается очень быстрый.
Но в тоже время, мне нравится подход DHH, который звучит примерно так: сервер всегда мощнее даже самого мощного десктопа, потому что он под это заточен.
Поэтому логичнее на клиент отправлять уже готовый HTML, отрендеренный на сервере, а на клиенте только замещать элементы.
У них Basecamp, как я знаю, так работает. В одном выступлении он показывал, что если открывается форма редактирования — она вероятнее всего приходит с сервера и просто вставляется в контейнер (он говорил они такие элементы даже не рендерят, а сразу отдают из хранилища типа memcached).
Хотя это и увеличивает трафик, но на клиенте сохраняется достаточно простая логика и это будет работать везде без тормозов и отклик сайта получается очень быстрый.
Такой подход хорошо работает тогда, когда канал широк (и всегда есть). Тем более, в Rails 4 с турболинками так оно из коробки и работает. И пока канал широк — всё замечательно. Но стоит ему стать хреновым — и приложение с turbolinks начинает откровенно бесить, потому что ты нажимаешь на ссылку и ничего не происходит, пока отрендеренная формочка не приползёт и javascript её не вставит. В качестве времянки вкорячивается яваскриптовый же прогресс-бар, чтобы снять неопределённость, и так и остаётся.
Когда же канал узок и нестабилен по определению (даже 3g, знаете ли, не везде есть), то уже начинаешь думать и о логике в клиенте и о том, как бы по сети лишний раз данные без острой нужды не переслать, и что все формочки лучше держать поближе. И Angular тут начинает сиять.
Так что всё снова сводится в подбору инструмента под задачу (а не наоборот).
Когда же канал узок и нестабилен по определению (даже 3g, знаете ли, не везде есть), то уже начинаешь думать и о логике в клиенте и о том, как бы по сети лишний раз данные без острой нужды не переслать, и что все формочки лучше держать поближе. И Angular тут начинает сиять.
Так что всё снова сводится в подбору инструмента под задачу (а не наоборот).
Очень люблю эту технологию, хотя часто она бывает магической, но стоит немного понять как работает сам Ruby — все становится на свои места.
Это лично мое мнение, но я считаю, что самый главный минус Ruby on Rails (и Ruby) — это прожорливость памяти.
Или взять тот же самый форум Discourse — отличная вещь, но минимальные требования 2 GB, хотя я смог запустить его на 512 MB при помощи сервера puma, но работал он как-то нестабильно.
Но на 512 MB он не смог выполнить команду assets:precompile, только на 1 GB :) 1 гигабайт памяти на склеивание пару десятков файлов? Кхм…
Многие могут сказать, что сейчас память стоит значительно дешевле, но чтобы сделать небольшой сайт — иногда думаешь влезет он на 512 MB или раздуется даже под небольшой нагрузкой :)
Просто платить 20 долларов за тот же изначально пустой форум — это небольшая лишняя трата, по-моему.
Поэтому сейчас частично перешли на Golang (много разных маленьких пакетов типа Gorilla Mux): 2-5 MB при запуске вместо 50-100 MB и под нагрузкой вырастало максимум до 17 MB вместо около 700 MB в Rails. Скорость ответов тоже радует.
Хотя вот в Golang нехватает быстрой разработки (Revel не совсем подошел под задачу), иногда приходится переизобретать что-то или писать много больше кода, чем в том же Rails.
Это лично мое мнение, но я считаю, что самый главный минус Ruby on Rails (и Ruby) — это прожорливость памяти.
Или взять тот же самый форум Discourse — отличная вещь, но минимальные требования 2 GB, хотя я смог запустить его на 512 MB при помощи сервера puma, но работал он как-то нестабильно.
Но на 512 MB он не смог выполнить команду assets:precompile, только на 1 GB :) 1 гигабайт памяти на склеивание пару десятков файлов? Кхм…
Многие могут сказать, что сейчас память стоит значительно дешевле, но чтобы сделать небольшой сайт — иногда думаешь влезет он на 512 MB или раздуется даже под небольшой нагрузкой :)
Просто платить 20 долларов за тот же изначально пустой форум — это небольшая лишняя трата, по-моему.
Поэтому сейчас частично перешли на Golang (много разных маленьких пакетов типа Gorilla Mux): 2-5 MB при запуске вместо 50-100 MB и под нагрузкой вырастало максимум до 17 MB вместо около 700 MB в Rails. Скорость ответов тоже радует.
Хотя вот в Golang нехватает быстрой разработки (Revel не совсем подошел под задачу), иногда приходится переизобретать что-то или писать много больше кода, чем в том же Rails.
Уважаемый, я думаю, что Вы сравнивайте мягкое с теплым. Поясню, RoR это огромный фреймворк с кучей библиотек, которые действительно требуют много памяти + сам руби это интерпретируемый язык. Я считаю, что в Вашем случае уместно было бы сравнивать sinatra или с rake.
Так же не забывайте, что в discourse только в css 89 файлов + js (которого там действительно очень много) так что это далеко не пара десятков файлов ;) Плюс discourse это не просто пустой форум, там довольно серьезный клиенсткий код на ембере.
Так же не забывайте, что в discourse только в css 89 файлов + js (которого там действительно очень много) так что это далеко не пара десятков файлов ;) Плюс discourse это не просто пустой форум, там довольно серьезный клиенсткий код на ембере.
Я не спорю, потому что я тут сравниваю интерпретируемый и компилируемый языки.
Но я сравнил ROR с проектом Golang не просто так — фунционал получился точно таким же. Те же самые «кучи библиотек», только на Golang теперь.
То есть мы переписали достаточно сложный проект с ROR (больше 30 таблиц со сложными зависимостями, больше 80 view, про assets pipeline — мы остались на Sprockets) на Golang и действительно сократили конфигурацию серверов и стоимость, сами worker'ы потребляет не больше 20 MB памяти в пике, процессор вообще на 1-3%, сервер как-будто на отдыхе :)
Большой плюс — убрали Sidekiq, заменив их на goroutines и заменили Faye (опять же средствами самого языка сделали).
Хотя, как я уже сказал, не всегда было так удобно, как на ROR — приходилось писать больше кода, иногда изобретать и переизобретать, написали много библиотек своих (частично выложили их на github).
Просто часто удивляет, что на достаточно простые задачи тратится столько памяти.
Возможно я чего-то не понимаю, но по-моему склеить даже 300 файлов в 1 или несколько маленьких не должно занимать много минут и около 1 GB памяти :)
Но я сравнил ROR с проектом Golang не просто так — фунционал получился точно таким же. Те же самые «кучи библиотек», только на Golang теперь.
То есть мы переписали достаточно сложный проект с ROR (больше 30 таблиц со сложными зависимостями, больше 80 view, про assets pipeline — мы остались на Sprockets) на Golang и действительно сократили конфигурацию серверов и стоимость, сами worker'ы потребляет не больше 20 MB памяти в пике, процессор вообще на 1-3%, сервер как-будто на отдыхе :)
Большой плюс — убрали Sidekiq, заменив их на goroutines и заменили Faye (опять же средствами самого языка сделали).
Хотя, как я уже сказал, не всегда было так удобно, как на ROR — приходилось писать больше кода, иногда изобретать и переизобретать, написали много библиотек своих (частично выложили их на github).
Просто часто удивляет, что на достаточно простые задачи тратится столько памяти.
Возможно я чего-то не понимаю, но по-моему склеить даже 300 файлов в 1 или несколько маленьких не должно занимать много минут и около 1 GB памяти :)
При всем (не очень большом, если честно) уважении к RoR, есть множество других фреймворков с кучей библиотек, написанных на других интерпретируемых языках, которые съедают намного меньше памяти. Вышупомянутый Django, например.
> Но на 512 MB он не смог выполнить команду assets:precompile, только на 1 GB :) 1 гигабайт памяти на склеивание пару десятков файлов? Кхм…
Это uglifier выжирает память. К ruby он отношения не имеет, так как написан на javascript. И его можно отключить, тогда компиляция assets будет проходить значительно быстрее.
Это uglifier выжирает память. К ruby он отношения не имеет, так как написан на javascript. И его можно отключить, тогда компиляция assets будет проходить значительно быстрее.
Я решил не пользоваться метро. Просто платить 20$ за обычное перемещение в пространстве — это небольшая лишняя трата, по-моему. Поэтому сейчас перешел на самокат или велосипед. Хотя вот на самокате не хватает скорости чтобы вовремя на работу приехать, иногда приходится пользоваться маршрутным такси. Это во первых.
Во вторых, 20$ в месяц, это 1/60 — 1/80 зп среднего разработчика.
Во вторых, 20$ в месяц, это 1/60 — 1/80 зп среднего разработчика.
Все плюсы рельсовой экосистемы становятся не такими уж и вкусными, когда посмотришь, как оно реализовано внутри, и как используется. Буэээ.
И конечно же жаль, что умер сайт www.didrailshaveamajorsecurityflawtoday.com/
И конечно же жаль, что умер сайт www.didrailshaveamajorsecurityflawtoday.com/
Пруфы? Что и где именно реализовано и используется плохо? На моём счету уже с десяток pull request'ов в различные гемы (включая rails) и я пока ещё нигде не видел плохого кода, наоборот, самому приходится «подтягиваться», чтоб патч приняли :-)
Дело не в плохом коде, а в архитектурных косяках и болезнях роста. Нет человеческих масштабируемости и многопоточности. Железобетонный MVC-каркас, который проще выкинуть и забыть, чем согнуть и допилить. Даже моей закаленной годами реверсинга и низкоуровневой отладки психике тяжело далось впервые наблюдать dependency hell из-за гемов с нативным кодом.
Ну и никто вообще не думал о безопасности года эдак до 2012, что удручает, мягко говоря.
Ну и никто вообще не думал о безопасности года эдак до 2012, что удручает, мягко говоря.
>> Железобетонный MVC-каркас
Вот кстати очень оценили его железобетонность, когда фронтенд стали делать на backbone, и ввиду его вседозволенности каждый разработчик стал пилить так, как ему нравится, в результате нет единого стиля кода по умолчанию, нужны доп ресурсы на надзор/контроль/разработку guidestyles.
Вот кстати очень оценили его железобетонность, когда фронтенд стали делать на backbone, и ввиду его вседозволенности каждый разработчик стал пилить так, как ему нравится, в результате нет единого стиля кода по умолчанию, нужны доп ресурсы на надзор/контроль/разработку guidestyles.
С таким отношением в нашей профессии нельзя. Если заглянуть под капот таких продуктов как Apache Hadoop, Hibernate, исходники Java, V8, .NET, ядра Linux или Windows, то там все также печально (в разной степени печальности).
Что поделать? Жизнь — тлен.
Нужно учиться пользоваться абстракциями там, где это возможно, и одновременно с этим не бояться нырять с головой в проблему, если абстракция для вашего случая оказалась решетом.
Rails хорош, если с одной стороны, вам недостаточно возможностей CMS, но с другой — у вас нет задачи заниматься real-time вебом и нет заоблачных требований по производительности. Если вы делаете HTTP API или традиционный сайт с элементами интерактива, то Рельсам в этой нише равных нет. Во-первых, сам фреймворк из коробки кучу всего умеет. А во-вторых, для него есть огромное множество библиотек для расширения базового функционала. Часто проекты достигают стадии «готово на 80%» уже в первые дни только за счет того, что инжинеры быстро находят и подключают готовые библиотеки и.
И пусть оно внутри страшное. Оно работает и часто у него отлично спроектированный публичный API, и значит, каким бы плохим не был код самого фреймворка или плагинов, это никак не портит вашего кода. А ваш код — это как раз то, что волнует вас больше всего.
Что поделать? Жизнь — тлен.
Нужно учиться пользоваться абстракциями там, где это возможно, и одновременно с этим не бояться нырять с головой в проблему, если абстракция для вашего случая оказалась решетом.
Rails хорош, если с одной стороны, вам недостаточно возможностей CMS, но с другой — у вас нет задачи заниматься real-time вебом и нет заоблачных требований по производительности. Если вы делаете HTTP API или традиционный сайт с элементами интерактива, то Рельсам в этой нише равных нет. Во-первых, сам фреймворк из коробки кучу всего умеет. А во-вторых, для него есть огромное множество библиотек для расширения базового функционала. Часто проекты достигают стадии «готово на 80%» уже в первые дни только за счет того, что инжинеры быстро находят и подключают готовые библиотеки и.
И пусть оно внутри страшное. Оно работает и часто у него отлично спроектированный публичный API, и значит, каким бы плохим не был код самого фреймворка или плагинов, это никак не портит вашего кода. А ваш код — это как раз то, что волнует вас больше всего.
Sign up to leave a comment.
Ruby on Rails исполнилось 10 лет