Как стать автором
Обновить

Комментарии 48

Сейчас Django для Python – клон Rails. То же самое можно сказать о Sails.js для JavaScript. И эти фреймворки не страдают от того, что пишутся на “не мейнстримовых” языках программирования.

не «мейнстримовых»?
Статья 2015 года… Я бы перевел краткую суть вот так: «Не надо использовать Ruby on Rails 3.х для нового проекта» и в этом я с ним согласен.
Есть подозрение, что за последний год фундаментально ничего не поменялось. Разве что график трендов еще больше сдвинулся в сторону ноды :)
Специально посмотрел, тенденции идентичны — плавный спад по поисковым запросам у обоих (что может говорить о некой зрелости, а может и чем то другом ^^).
Рельсы с 3 на 4 стали «приятнее» в плане работы с ActiveRecord и не только. Улучшение имеющегося функционала точно идет. Action Cable немного сомнительный в 5й версии, но зато в коробке.

я начал писать на 4х, потом докрутил туда реакт.
Сейчас пишу апи на 5х рельсах + отдельный фронт на реакте с редуксом, роутером и под вебпаком.

Писать бэкенд (не сильно сложного проекта) на рельсах сплошное удовольствие. Да, там немного абстракций не доложили, но на первых парах можно и имеющимися не сильно напрягаясь обходиться.
Ну а случае реальных нагрузок, масштабируемся железом. Зато легко =) Ну или дербаним от монолита «узкие места» и пишем их на чем-нибудь компилируемом.
Сама по себе панель достаточно простой проект, на мой взгляд. А вот подкапотное взаимодействие с ОС на низком уровне — по мне задача сложная или как минимум серьезная =) Но тут вопрос не к рельсам уже, админки на них пишутся прекрасно. А к коду бизнес-логики.

Код и логику бизнес логики я вынашивал год. даже на сентябрьской осдн немного про панельку рассказал. Но сейчас я пришел к тому что апи сервер и фронт на реакте надо разнести окончательно и засел за фронтенд

Два из четырех графиков в статье показывают зависимость вообще непонятно чего, вот как так? Зачем их вообще добавлять в статью, если они ни о чем не говорят?
Это какие?
Первый и третий.
Можно, конечно, пройти по ссылкам и понять, о чем они, но как-то хотелось бы сразу понимать, о чем графики.
Если с 3м хоть что-то понятно (хотя непонятно, лучше когда больше или когда меньше), то в Первом совсем не понятно, где чей тренд
Первый поменял, третий — тяжкое наследие перевода, полагаю там обычный relative to each over

Rails действительно теряет популярность, но никак не в пользу Node.JS или Go. Первый привлекает много новичков, а второй используется только в узких местах и то для Rails-проектов скоро будет гораздо естественнее узкие места закрывать с помощью Crystal/Kemal, а не Go.
Ну а переход от Rails идёт в основном в пользу Ruby/Hanami и Elixir/Phoenix.

Знать бы еще как это замерить :) Один из самых больных для меня вопросов, который мучает уже много-много лет — как определить меру использования той или иной технологии. Есть нехорошее подозрение, что то, что датамайнится — это очень нерепрезентативная выборка «публичного доступа». И мы понятия не имеем, что используют внутри компании Fortune 500, просто потому, что их разработчики мало ходят на stackoverflow и не пользуются публичными репозиториями git :)

Я все же думаю, что почти любые разработчики, будь они из компаний списка Fortune 500 или нет, в любом случае время от времени ходят на stackoverflow (или на другой подобный тематический ресурс). А вот с отсутствием использования публичных репозиториев я вас полностью поддержу.

Интересная гипотеза. Которую тоже непонятно как проверить :)
НЛО прилетело и опубликовало эту надпись здесь
С одной стороны, да, руби сравнительно медленный.
С другой стороны, насколько это важно? Железо дешевое, программисты дорогие.
Для большей части стартапов вопрос нагрузки чуть менее чем неактуален на раннем этапе. Быть бы живу.

Еще один момент — из-за нативных гемов что-то конкретное может быть очень быстрым.
Пример.
Генерация json при помощи oj gem. По факту, он написан на С.
Если ваш проект — обычный CRUD API, где много Read, толку то от «быстрого» языка, где нет хорошей и быстрой реализации json генератора…

Короче, проблемы надо комплексно рассматривать.
На мой взгляд проблемы Rails совсем не в Ruby. Здесь было много статей на эту тему.
>> JRuby по-прежнему активен и последние версии подают надежды, но впереди ещё много работы.
Только вот стартует он секунды, даже со всеми нужными прописанными заклинаниями, даже на мощных процессорах. Использование console tools как в rails — мука. Прелоадеры? Покажите мне хоть один нормально работающий.
До этого писал проект на чистом ПХП,
После этого пробывали писать документооборот на YII,

Как же надоели эти $ в PHP почему нельзя просто было сделать переменные без $?

Изучал Rails, но там было многое не явно.

Друг утроился в Mail.ru и сказал используй Django.

Теперь смотрю и оцениваю Benchmark'i.
Прельщает Go со своей скоростью, но отталкивает что MVC приложение на нем хорошее не напишешь.
Хотел Изучать Nodejs но увидев Асинхронную лапшу, понял что это ужжжссс,

Теперь уж даже не знаю куда стоит плыть!

Ветка с другом не раскрыта! Что не так с django? Используйте его

Вы об этом: «Друг утроился в Mail.ru»?

Я бы сказал, что все три варианта хороши: MVC-фреймворки на «китах»(главных интерпритируемых языках). Какой язык больше нравится(опыт, окружение помощников, личное отношение и тд), в ту сторону и идти. Врятли в ближайшие 2-4года скажите себе: «Какой же я был, надо было Y, а не X выбирать».
Попробуйте .NET Core
Ну, или Kotlin.
Зачем?

Используйте Babel с JavaScript, или TypeScript, и можете радоваться async/await, убирает сложности со спагетти. В ES2017 будет входить в язык. Взято из .NET.

Может, стоит попробовать Dart?
Я так понимаю, минус мне влепили за то, что предлагаю новую, не распространённую в индустрии технологию. Попробую объяснить своё предложение:
Diaskhan сказал, что
Как же надоели эти $ в PHP почему нельзя просто было сделать переменные без $?
, а в Руби на Рельсах многое неявно (слишком много магии). Так вот, в Дарте магии немного, есть встроенные типы массивов, множеств (Set), отображений (Map); и он компилируется в JavaScript, то есть, его можно воспринимать как тот же TypeScript, но на сервере его можно исполнять либо в DartVM, либо компилировать Dart --> JS и запускать в node.js. Так что, в качестве будущей замены PHP, Dart вполне себе вариант, ПМСМ. Ну и нужные на веб-сервере библиотеки уже включены в стандартный набор.
Мне vibed.org нравится.
Вот тоже присматриваюсь помаленьку, интересно же.
Я так понимаю, статья старая. Аналогом Rails в Node.js я бы, скорее, назвал Adonis.
НЛО прилетело и опубликовало эту надпись здесь
Какой-то бред, зачем-то приплели сюда facebook, хотя этим самым hiphop никто не пользуется, сообщество ускоряет язык и без мордокниги. Nodejs и Go концептуально другие языки, а не замена ruby, копаться в асинхронных запросах то ещё удовольствие.
Ну и самое важное, что он рассматривает язык с точки зрения нагрузки(он стал третьим по посещаемость сайтом на Rails), а этот кейс далеко не критичен для большинства проектов, тем более узкие места всегда можно затюнить.

Пришлось саппортить один проект на рельсах, норм фреймворк, много полезных фич, которые перенимают фреймворки с других языков, не стоит торопиться его хоронить.
Ну что за гадкая привычка молча лепить минус и портить карму, отпишитесь хоть почему. Я же привёл аргументированную точку зрения, если надо ещё докину аргументов и ссылок.
Смущают тренды в первом графике.
Откуда node.js в 2004м году?

Тренд до середины 2009 года можно использовать для нормировки текущего… Неважно что ещё ищут по такому запросу, но это явно надо вычесть, если хотите увидеть тренд именно по Node.JS

Довольно странно видеть все эти графики популярности, составленные по количеству запросов в поисковиках. А о том, что сколько компаний используют какой-то фреймворк — так это вообще чушь — сколько еще компаний не опрошено, сколько просто разработчиков не опрошено.
Я использую Ruby и Ruby on Rails уже более 5 лет в своей работе (опыт разработки более 20 лет) и АБСОЛЮТНО ВСЕМ доволен — скорость меня устраивает, удобство разработки, сам язык восхитителен, переход на более новые версии RoR без затруднений (прошел от 3 до 5) — разработал уже множество проектов — от простейших страничек до порталов — все прекрасно работает. В том-то и дело, что на Ruby пишут преимущественно профессионалы, потому как у языка довольно высокий порок вхождения, и поэтому абы кто на нем не сможет писать. А если занимаются этим профессионалы, то, по своему опыту скажу, что спрашивать что-то у гугл особой необходимости не возникает — все есть в документации, да и сам знаю, как и что работает, как и что написать.
Я согласен, что сейчас много новых проектов, фреймворков, направлений — вот молодые и неопытные мечутся в поисках святого грааля — чтобы толком ничего не изучить, а получались прям супер-крутые проекты.
Например, я сам вообще не сторонник г… на под названием JavaScript — вот и лажу по каждому поводу в поисковик за ответами, а он из-за этого как бы набирает популярность, если судить по количеству запросов в поисковиках.
Уже столько лет прочат закат Ruby, Ruby on Rails, а эти проекты, не обращая внимания особо ни на какие мнения, все развиваются и становятся только лучше. Я думаю, что со мной согласятся многие разработчики Ruby — мы просто делаем свое дело, а смотреть и, тем более, ориентироваться на какие-то там графики — это совершенно излишне. Инструментарий удобный и качественный — этого достаточно для профессионала.

Уважаемый переводчик!


Ваш перевод значительно лучше недавних шедевров от гуру перевода LukinB и лидера рейтинга MagisterLudi, но и его можно улучшить.


Я тут написал немного рекомендаций:


Рекомендации
We built Scribd into the #3 largest rails site by traffic and it worked for us,

Ваш перевод:


Мы сделали Scribd на Rails, и он стал третьим по посещаемость сайтом на Rails, и фреймворк работал, как надо.

Уточнённый перевод


Мы сделали Scribd третьим по посещаемости сайтом на rails, и нас это устроило



I see a lot of new companies using rails

Ваш перевод:


я вижу огромное число новых проектов,

Уточнённый перевод


я вижу много новых компаний

Вообще перевод слова company как проект встречается у вас больше одного раза, я не понимаю почему




Most new sites were still being written in PHP or Java, and there were huge numbers of engineers for those platforms.

Ваш перевод:


Большинство новых сайтов продолжали писать на PHP и Java – этому способствовало наличие огромного количества разработчиков для этих платформ.

Уточнённый перевод


Большинство новых сайтов всё ещё писалось на PHP и Java и для этих платформ существовало огромное количество разработчиков.

У автора оригинала нету утверждения, что наличие большоного количества разработчиков способствовало чему либо. Есть просто констатация факта, что они были.




deep set of open-source libraries and, most importantly, a pool of developers interested in working in it.

Ваш перевод:


свитой хороших библиотек и армией лояльных разработчиков

Смысл, в общем не потерян, только вот в оригинале нет слов свита, армия и лояльный.
А вот most importantly и open-source — есть.


Поэтому перевести лучше вот так


множеством библиотек с открытым кодом и, что самое важное, программистами которым интересно с ним поработать.



It was the right bet.

Ваш перевод:


Нам повезло

Уточнённый перевод


И ставка была верной!



As one of the first rails sites to hit scale, we benefited enormously from this, picking up great talent by offering a chance to work with rails.

Ваш перевод:


Когда взлетел наш проект, мы оказались в выигрыше — к нам потянулись талантливые ребята, поскольку мы могли предложить им поработать на Rails.

Уточнённый перевод:


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



Все знают, что Ruby медленный. Но на самом деле, Ruby – это самый медленный язык среди популярных языков программирования.

Тут нету "Но". Можно оставить "На самом деле", можно написать "Вообще-то", но тут нету "Но".




Some people will point to language design characteristics, which are part of the story

Ваш перевод:


Некоторые укажут на характеристики языка, которые сложились исторически. И это верно.

Про то, что характеристики сложились исторически в оригинале нет.
Есть — "language desing characteristics"


Некоторые укажут на особенности дизайна языка, что вносит определённый вклад

Перечислить всё — меня не хватило, увы :(. Но, наверное, лучше так, чем никак.


Повторюсь, ваш перевод безусловно лучше, чем то, с чем я столкнулся на Хабре в последние несколько дней.
И мои замечания могут показаться мелочными, я не икслючаю.
Главное, что я хотел сказать — не надо искажать авторские тексты, надо их переводить.
Там, где можно обойтись без искажения, конечно.

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


Мы сделали Scribd третьим по посещаемости сайтом на rails, и нас это устроило

В Вашем варианте получилось, что их устроило 3-е место по посещаемости, т.е. ещё дальше от оригинала.


Вообще при переводе необязательно сохранять дословный смысл, потому что языки отличаются не только словами, и буквальный перевод будет выглядеть как у ребят из Edison.
Например, "It was the right bet." переведённая как "И ставка была верной!" выглядит как Promt, потому что по-русски так не говорят. Самое близкое, что мы говорим: "Ставка сыграла!"
Т.е., несмотря на то, что ряд Ваших исправлений в кассу, я бы призвал не гнаться за буквальным соответствием.

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

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


В Вашем варианте получилось, что их устроило 3-е место по посещаемости, т.е. ещё дальше от оригинала.

Фразу можно понять как — мы сделали наш сайт третьим по посещаемости, среди сайтов на Rails и нас третье место в общем устраивало, мы были довольны.


Или можно истолковать как — мы сделали сайт третьим по посещаемости среди сайтов на Rails и Rails нас устроил.


Я понял первым способом. Вполне возможно, что я не прав.


"И ставка была верной!" выглядит как Promt, потому что по-русски так не говорят. Самое близкое, что мы говорим: "Ставка сыграла!"

Поддерживаю.


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

Согласен, конечно, но когда статья называется Why I wouldn’t use rails for a new company — увидеть в переводе — Почему я бы не стал использовать Rails для нового проекта — ну очень неожиданно. Я считаю, что такие коррективы в авторский текст это уже неправильно.

стандартный ответ на коментарий о качестве перевода с примерами ошибок

Просто считается, что это надо в личку автору перевода писать. Хотя я такую агрессию не одобряю, т.к. тема улучшения переводов тоже интересная.


Фразу можно понять как — мы сделали наш сайт третьим по посещаемости, среди сайтов на Rails и нас третье место в общем устраивало, мы были довольны.

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


Why I wouldn’t use rails for a new company — увидеть в переводе — Почему я бы не стал использовать Rails для нового проекта — ну очень неожиданно.

Но если подумать, то это вполне корректная адаптация к российским реалиям. Это у них распространённая практика для каждого нового проекта открывать новую компанию. У нас так не принято. Вот и получается, что речь в статье именно о старте новых проектов, просто для американца начать проект и открыть компанию — это одно и то же.

Подавляющее большинство современных веб-приложений (нормально написанных) по настоящему нагружают только базу данных, так что зависимость от языка программирования для них довольно небольшая. Ну и масштабировать никто не мешает (разве только бюджет).
Так что именно на скорость языка стоит обращать внимание только если действительно планируются высокие вычислительные нагрузки, которые при этом нельзя или не имеет смысла передать специализированному приложению на чем-то быстром, или самописному расширению на C.
Ну, если на чистоту, все-таки ruby прилично времени тратит на десериализацию-сериализацию большого количества данных, GC опять же не особо шустрый. У меня рендеринг чаще медленнее гет-запросов происходит, если не из кэша доставать. Но, даже зная все узкие места производительности, я все равно начинаю проекты на ruby тупо из-за меньшего времени разработки. Потом уже, если потребуется оптимизация, какие-то части переписываю с использованием других инструментов.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.