Comments 48
Рельсы с 3 на 4 стали «приятнее» в плане работы с ActiveRecord и не только. Улучшение имеющегося функционала точно идет. Action Cable немного сомнительный в 5й версии, но зато в коробке.
я начал писать на 4х, потом докрутил туда реакт.
Сейчас пишу апи на 5х рельсах + отдельный фронт на реакте с редуксом, роутером и под вебпаком.
Ну а случае реальных нагрузок, масштабируемся железом. Зато легко =) Ну или дербаним от монолита «узкие места» и пишем их на чем-нибудь компилируемом.
Панель управления хостингом — это, по Вашему, сильно сложный проект?
Можно, конечно, пройти по ссылкам и понять, о чем они, но как-то хотелось бы сразу понимать, о чем графики.
Если с 3м хоть что-то понятно (хотя непонятно, лучше когда больше или когда меньше), то в Первом совсем не понятно, где чей тренд
Rails действительно теряет популярность, но никак не в пользу Node.JS или Go. Первый привлекает много новичков, а второй используется только в узких местах и то для Rails-проектов скоро будет гораздо естественнее узкие места закрывать с помощью Crystal/Kemal, а не Go.
Ну а переход от Rails идёт в основном в пользу Ruby/Hanami и Elixir/Phoenix.
Я все же думаю, что почти любые разработчики, будь они из компаний списка Fortune 500 или нет, в любом случае время от времени ходят на stackoverflow (или на другой подобный тематический ресурс). А вот с отсутствием использования публичных репозиториев я вас полностью поддержу.
С другой стороны, насколько это важно? Железо дешевое, программисты дорогие.
Для большей части стартапов вопрос нагрузки чуть менее чем неактуален на раннем этапе. Быть бы живу.
Еще один момент — из-за нативных гемов что-то конкретное может быть очень быстрым.
Пример.
Генерация json при помощи oj gem. По факту, он написан на С.
Если ваш проект — обычный CRUD API, где много Read, толку то от «быстрого» языка, где нет хорошей и быстрой реализации json генератора…
Короче, проблемы надо комплексно рассматривать.
На мой взгляд проблемы Rails совсем не в Ruby. Здесь было много статей на эту тему.
Только вот стартует он секунды, даже со всеми нужными прописанными заклинаниями, даже на мощных процессорах. Использование console tools как в rails — мука. Прелоадеры? Покажите мне хоть один нормально работающий.
После этого пробывали писать документооборот на YII,
Как же надоели эти $ в PHP почему нельзя просто было сделать переменные без $?
Изучал Rails, но там было многое не явно.
Друг утроился в Mail.ru и сказал используй Django.
Теперь смотрю и оцениваю Benchmark'i.
Прельщает Go со своей скоростью, но отталкивает что MVC приложение на нем хорошее не напишешь.
Хотел Изучать Nodejs но увидев Асинхронную лапшу, понял что это ужжжссс,
Теперь уж даже не знаю куда стоит плыть!
Ветка с другом не раскрыта! Что не так с django? Используйте его
Используйте Babel с JavaScript, или TypeScript, и можете радоваться async/await, убирает сложности со спагетти. В ES2017 будет входить в язык. Взято из .NET.
Diaskhan сказал, что
Как же надоели эти $ в PHP почему нельзя просто было сделать переменные без $?, а в Руби на Рельсах многое неявно (слишком много магии). Так вот, в Дарте магии немного, есть встроенные типы массивов, множеств (Set), отображений (Map); и он компилируется в JavaScript, то есть, его можно воспринимать как тот же TypeScript, но на сервере его можно исполнять либо в DartVM, либо компилировать Dart --> JS и запускать в node.js. Так что, в качестве будущей замены PHP, Dart вполне себе вариант, ПМСМ. Ну и нужные на веб-сервере библиотеки уже включены в стандартный набор.
Ну и самое важное, что он рассматривает язык с точки зрения нагрузки(он стал третьим по посещаемость сайтом на Rails), а этот кейс далеко не критичен для большинства проектов, тем более узкие места всегда можно затюнить.
Пришлось саппортить один проект на рельсах, норм фреймворк, много полезных фич, которые перенимают фреймворки с других языков, не стоит торопиться его хоронить.
Откуда node.js в 2004м году?
https://developer.mozilla.org/en-US/docs/Web/API/Node
Тренд до середины 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.
И на следующее: http://jruby.org/bench9000/
Почему я бы не стал использовать Rails для нового проекта