Хорошо, если ты хипстер и нравится, изменяя мир, писать скрипты на скорую руку — есть же хотя бы Python. Он все так в лидерах по популярности и найти разработчика не составляет большого труда.
Здравствуйте, Shmj, Вы писали:
S>Но Ruby? Зачем?
Основная мотивация — биг босс скатался на конференцию, услышал там про новый волшебный язык программирования, в результате чего производительность разработки возрастает в миллион раз, ибо он лаконичный, динамически типизированный (это модно, на статически типизированных только заросшие мхом дебилы пишут же щас), там можно прямо в момент выполнения изменять код, в него встроен ОРМ, сделать микросервис занимает 5 минут. И вообще там все легко, не нужны сеньеры с 20 летним опытом, возьмем студентку филфака и она нам налабает мегасоцсеть и мы будем все миллиардерами (за исключением студентки филфака, от которой собственно и ожидается что она по быстрому все запилит).
Потом эти мечты разбиваются об реальность, но пройти может чуть ли не 10 лет, пока у инвесторов деньги кончатся. А там глядишь и новый бигбосс появится, который скатается на новую мегаконференцию и начнется все сначала.
этот вопрос надо было задавать много лет назад
когда рельсы еще нигде не скопировали, а с гемами разве что спан конкурировал
а теперь момент инерции набран — отвечать на него незачем
привычка!
Здравствуйте, elmal, Вы писали:
E>услышал там про новый волшебный язык программирования, в результате чего производительность разработки возрастает в миллион раз, ибо он лаконичный, динамически типизированный (это модно, на статически типизированных только заросшие мхом дебилы пишут же щас), там можно прямо в момент выполнения изменять код
Так бывает. Писали себе стартапы на Ruby, все было нормально. Потом узнали о clojure, цитата:
clojure is really cool
Functional programming!
Immutable data structures!
Parellelization, for free!
The JVM is ... faster?
И решили переписать на clojure. Но что-то пошло не так И переписали обратно на Ruby
Здравствуйте, Shmj, Вы писали:
S>Хорошо, если ты хипстер и нравится, изменяя мир, писать скрипты на скорую руку — есть же хотя бы Python. Он все так в лидерах по популярности и найти разработчика не составляет большого труда.
S>Но Ruby? Зачем?
А откуда такие сведения? Ruby вроде давно вышел из моды,
и в этом году в моде Go.
Фишка Ruby это его фреймворк Ruby on Rails, который позволяет быстро делать типовые сайты. Ну это в теории, я лично не пробовал, но много слышал. Особенно, как говорят, удобно делать прототипы. Захотел заказчик сайт, а ты раз и уже сделал 90%. Потрясённый заказчик тебе насыпает денег и говорит мол вот тут чуть-чуть по-другому хотелось бы, а ты спокойно переписываешь всё на Java по уму.
Здравствуйте, vsb, Вы писали:
vsb>Фишка Ruby это его фреймворк Ruby on Rails, который позволяет быстро делать типовые сайты. Ну это в теории, я лично не пробовал, но много слышал. Особенно, как говорят, удобно делать прототипы. Захотел заказчик сайт, а ты раз и уже сделал 90%. Потрясённый заказчик тебе насыпает денег и говорит мол вот тут чуть-чуть по-другому хотелось бы, а ты спокойно переписываешь всё на Java по уму.
Тоже самое позволяет сделать Django + Python, и примерно с такой же скоростью. Плюс меньше всякого геморроя с гемами. Так что Ruby on Rails — это чистый хайп, который уже несколько лет сходит на нет.
Здравствуйте, fdn721, Вы писали:
F>Тоже самое позволяет сделать Django + Python, и примерно с такой же скоростью. Плюс меньше всякого геморроя с гемами.
Личный опыт с гемами (в чем были проблемы?) или в блогах питонщики пишут?
F>Так что Ruby on Rails — это чистый хайп, который уже несколько лет сходит на нет.
Да. Где-то раз в квартал на reddit и quora кто-нибудь вылазит с вопросом "Is Ruby dead?"
Здравствуйте, Shmj, Вы писали:
S>Хорошо, если ты хипстер и нравится, изменяя мир, писать скрипты на скорую руку — есть же хотя бы Python. Он все так в лидерах по популярности и найти разработчика не составляет большого труда.
Задача-то не найти разработчика, а сделать сервис, который потом можно будет поддерживать и дорабатывать.
S>Но Ruby? Зачем?
Попробую ответить, как человек, выбравший несколько лет назад, Руби и не пожалевший об этом. Рельсы наиболее зрелый (и до сих пор один из лидеров по фичам) веб-фреймворк.
Могу написать, почему его выбрал я. Кроме, собственно решаемой бизнес задачи, при разработке ПО много усилий уходит на то, чтобы:
1. Код был хорошо структурирован и ответственности не расползались.
2. Код был тестируем.
3. Код был лаконичен и выполнялись принципы DRY.
4. Взаимодействие частей системы: БД, FTS, кеши, API, система безопасности, браузер не требовало низкоуровневого взаимодействия, но позволяло переходить на него при необходимости.
5. Решения большинства типовых задач были в библиотеках, которые легко прикручиваются и кастомизируются.
6. Соотношение кода бизнес-логики и программного "клея" для его написания и поддержки было высоким. Клей должен быть максимально отделен от самой логики.
7. Окружения — development/staging/production должны максимально хорошо выполнять свои задачи и минимально отличаться друг от друга для разработчика. Это противоречивые требования и разрешение этих противоречий это та сложность, с которой борются разработчики всех фреймворков.
Руби, как язык и рельсы, как фреймворк, дают сейчас, на мой взгляд, лучшие показатели по большинству этих пунктов.
Java/.NET завязаны на типизацию данных. Типы, которые в вебе приходится создавать практически на лету. Практически всегда приходится идти на компромисс и использовать типы данных, которые для данной операции не оптимальны и не безопасны. Например частичная загрузка данных и передача их на слой представления и обратно. Либо переходим на анонимные типы (или даже динамику) либо тонем в вагонах различных DTO, DI и тому подобных техник. Достаточно написать один раз слой взаимодействия логики со строгими типами и представления со строками, которые вводит пользователь, чтобы понять о чем я пишу. Их можно выбрать за возможность максимально обезопасить себя от случайного выстрела в ногу, но ценой будут постоянное ношение кевларовых сапог.
PHP — серьезный игрок на рынке разработки Web приложений. Но уровень самого языка, его библиотек и большинства программистов заметно ниже.
Python — отличный язык с кучей библиотек, но веб-фреймворки у него заметно хуже рельс. Типовых решений либо мало либо их сложно кастомизировать.
Javascript — уже несколько лет идет мода делать бэкенд на nodejs. Есть плюсы — можно типизировать то, что стоит типизировать и шарить код между клиентом и сервером. Можно писать для мобилок. Но есть и минусы — нестабильные и плохо совместимые друг с другом библиотеки, постоянная асинхронность, даже там, где она реально не нужна (то есть нужна для решения каких-то там сугубо архитектурных особенностей), серверные фреймворки все еще уступают рельсам. Нужно писать и поддерживать заметно больше кода.
Различные closure, elexir, elm, haskell, go, C++, rust и т.д., на мой взгляд, могут быть выбраны только из большой любви к самому языку и парадигме, которую он представляет. Сама разработка будет заметно дороже, зато программисты мотивированнее.
Я люблю статику, легкий рефакторинг и некоторое автоматическое доказательство корректности кода. Но бизнес требует приложения, которые меняются на каждый чих. Новое законодательство, новые процессы, не учтенные требования, запросы от маркетологов и пользователей. Все это плохо совместимо с архитектурой, которую можно продумать на этапе проектирования с учетом известных требований. Архитектура приложений должна обеспечивать дешевые и безопасные изменения и последующую поддержку кодовой базы. И динамика, при всех ее минусах, здесь проявляет свои сильные стороны.
Кто-то скажет, что проблема в неумении правильно собирать и анализировать требования, я отвечу, что сбор требований со всех необходимых источников может быть дольше и дороже чем создание приложения на динамике и его корректировка с учетом опытной эксплуатации.
Так или иначе каждый волен сам выбрать свой путь в отрасли, благо инструментов сейчас масса.
Здравствуйте, fdn721, Вы писали:
F>Тоже самое позволяет сделать Django + Python, и примерно с такой же скоростью. Плюс меньше всякого геморроя с гемами. Так что Ruby on Rails — это чистый хайп, который уже несколько лет сходит на нет.
Джанго неплох, пока функционал вписывается в его концепцию моделей. Когда я его изучал, проблемы начались со сражением с left join и они решались совсем не просто Даже древний zope не был так плох.
Простенький сайт наклепать можно, серьезные системы на django требуют замену, как минимум, ORM.
Здравствуйте, msorc, Вы писали:
M>Так бывает. Писали себе стартапы на Ruby, все было нормально. Потом узнали о clojure, цитата: M>
M>clojure is really cool
M>
Functional programming!
M>Immutable data structures!
M>Parellelization, for free!
M>The JVM is ... faster?
M>
M>И решили переписать на clojure.
На одной из конференций год или два назад тоже слышал про такой опыт от одного питерского разраба. Типа функциональщина, все процессы прозрачны, никаких неочевидных манипуляций в гемах, а иммутабельность безумно рулит.
M>Но что-то пошло не так И переписали обратно на Ruby
Позадавал ему вопросов, тоже показалось, что не все не так прекрасно, отсутствие проблем с гемами оборачивается необходимостью писать гемы самим, но на тот момент за кложу держались. Интересно, как у них сейчас дела.
Faster это конечно круто, но это чаще всего это про алгоритмы, а не язык.
Я не веб-программист вообще, деньги я зарабатываю разработкой под мобильные, т.е., С++/Objective-C/Java/Swift/Kotlin. Но иногда мне надо не по работе сваять бэкэнд.
Я знал python и был наслышан про Django, поэтому первым делом сунулся в Django. За джва часа чтения мануалов я не понял, как мне сделать то, что мне надо.
Я не знал ruby вообще, но попробовал сунуться в RoR. Через полчаса у меня был прототип.
Здравствуйте, Ziaw, Вы писали:
Z>Типа функциональщина, все процессы прозрачны, никаких неочевидных манипуляций в гемах, а иммутабельность безумно рулит.
В лиспы надо уметь. Знать инфраструктуру. Не быть фанбоем
Появился на одном проекте соседний отдел, где писали на Clojure. По указанным выше причинам написание довольно простого микросервиса с отладкой у них растянулось на пару недель с хвостиком. Я заглыдвал в их код и занимался интеграцией в наше Rails приложение.
Здравствуйте, Ziaw, Вы писали:
Z>Java/.NET завязаны на типизацию данных. Типы, которые в вебе приходится создавать практически на лету. Практически всегда приходится идти на компромисс и использовать типы данных, которые для данной операции не оптимальны и не безопасны. Например частичная загрузка данных и передача их на слой представления и обратно. Либо переходим на анонимные типы (или даже динамику) либо тонем в вагонах различных DTO, DI и тому подобных техник. Достаточно написать один раз слой взаимодействия логики со строгими типами и представления со строками, которые вводит пользователь, чтобы понять о чем я пишу. Их можно выбрать за возможность максимально обезопасить себя от случайного выстрела в ногу, но ценой будут постоянное ношение кевларовых сапог.
Вот это вот — как бы да. При этом в дотнете я наблюдаю постепенное движение в нужную сторону, но не так быстро, как хотелось бы.
В целом, что мы имеем? Имеем некоторую вполне себе жёсткую модель хранимых данных (если мы хотим её сделать мягкой, то мы всегда можем это сделать руками — к примеру, для веб-магазина с его расплывчатым понятием "атрибуты товара" применяем схему EAV и имеем желаемый накал).
Поверх этой жёсткой модели порождается большое количество представлений. Где-то нам нужен полный профиль пользователя, где-то — только его аватарка, где-то — никнейм и таймстамп последнего входа на сайт.
Представления, по большому счёту, диктуются сиюминутными потребностями данной веб-страницы (или данного метода API).
Для того, чтобы всё работало как надо, нам нужен метод быстрого порождения вот этой вот локальной модели из нашей "настоящей" статической модели. Без того, чтобы нудно описывать все эти бесконечные DTO вида (string Name, DateTimeOffset LastLogin).
Плюс к этому нам нужен способ всё это биндить к UI.
Причем в обоих случаях желательно иметь статическую валидацию — чтобы мне компилятор сразу сказал, что не так; и чтобы рефакторинг типа переименования назания колонки в таблице не сломал 100500 мест.
Без статической валидации всё работает прекрасно во всех недотипизированных фреймворках — да хоть на тех же рекордсетах гую к данным привинчивай.
А вот со статикой...
В шарпе у нас есть Linq.
Для полноты счастья мне не хватает по большому счёту только возможности автовывода типа свойств.
Чтобы писать примерно так
public class FrontPageModel: DbBoundObject // подтаскиваем инициализацию коннекта из предка
{
public CurrentUser => from Context.Users u where u.Id == Session.UserID seleсt DisplayName(u), LastLoginStamp(u);
public UserPosts => from Context.Posts p where p.UserId == Session.UserID select Topic, FirstPostStamp, LastPostStamp
}
И у меня типы для CurrentUser и UserPosts автовыводились. В принципе, так, как мне нужно, себя ведёт конструктор анонимного класса, но получившийся тип я могу использовать только "вниз". Т.е. я могу вызвать генерик-метод, параметризованный этим типом, но я не могу сконструировать класс View, который был бы этим типом параметризован.
Потому, что я хочу иметь возможность построить
public class FrontPage: UI.Page<FrontPageModel>
{
...
}
И в его теле обращаться типизированно к данным вот этой вот модели. Тогда мне компилятор обнаружит некорректное использование ещё в процессе редактирования (или пре-коммит сборки), а рефактор тул переименует и выделит всё так, как надо.
Ну, вот ещё пока непонятно насчёт утиной типизации — ведь собственно страничка собирается не с нуля, из сырых тегов, а скорее из каких-то более-менее библиотечных фрагментов типа "плашка", у которой есть три-пять-десять полей для отображения, на которые нужно биндить специфичные для конкретной странички компоненты данных. В принципе, на первый взгляд всё опять решается linq-style проекциями или конструкторами типов, ну вроде как
public PaneViewData PaneViewDataGet<T>(realDataModel model) => new PaneViewData(){Title = model.CurrentUser.DisplayName; Subtitle = $"Last Login: {model.LastLoginStamp:d}"}
Тут и типизация, и преобразование. Но это может оказаться занудным, если в большинстве случаев мы имеем источники данных, уже оборудованные типичными свойствами типа Subject и Body, а вот дальше — хвост специфичных свойств.
Тогда, наверное, захочется мочь их биндить к разнообразным MessaageListView просто так, без вот этого вот перекладывания Subject = model.Subject, Body = model.Body.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Для того, чтобы всё работало как надо, нам нужен метод быстрого порождения вот этой вот локальной модели из нашей "настоящей" статической модели. Без того, чтобы нудно описывать все эти бесконечные DTO вида (string Name, DateTimeOffset LastLogin).
Я когда-то давно заморачивался задачей автогенерации ViewModel типов через Nemerle. Потом как-то остыл. Динамика, она и есть динамика. То, что приходит от пользователя или внешнего сервиса, это все равно по факту динамика.
S>Плюс к этому нам нужен способ всё это биндить к UI. S>Причем в обоих случаях желательно иметь статическую валидацию — чтобы мне компилятор сразу сказал, что не так; и чтобы рефакторинг типа переименования назания колонки в таблице не сломал 100500 мест.
Тут есть еще один момент. К UI надо биндить строки, по крайней мере пока пользователей не научили вводить сразу даты в нужном формате.
И если пользователь ввел что-то не в том формате, ему надо вывести это что-то снова в том же формате. А не результат ToDate->ToString.
В простых случаях, типа даты, можно решить проблему с помощью масок, клиентских валидаций и прочих js компонентов, но это все равно припудривание. Но типизированных данных намного больше — IP, URI, Email, имя пользователя в системе тоже по факту имеет свой тип.
Чем больше работаешь со строками в UI, тем меньше понимаешь, пользу типизированных кортежей, которые мы достали из базы. Ибо толку от них, если основное их предназначение быть переданными в UI, а затем, пользовательский ввод передать обратно в базу. БД сама по себе типизирована и по сути наша типизация обеспечивает нам лишь отсутствие ошибок при записи в БД.
Еще типизация дает возможность коду бизнес логики работать с типизированными записями при выполнении бизнес транзакций. Много это или мало?
Не знаю, у меня часто получается, что транзакциям типизация фактически по барабану. Переводим из данные одного состояния в другое и главная задача сохранить консистентность, а не ошибиться где-то в типе поля.
В руби я пишу так: count = order.items.calculatable.sum(:count) и оказалось, что различные сервисы бизнес логики мне не нужны. Не нужен OrderItemsSummator вместе с гарантиями передачи туда типизированного списка и различными DI для его передачи куда надо. Как и гарантия, что значение будет целым числом. Логика пишется именно там, где она применяется, а не размазывается по проекту. То, что в нужные методы передаются нужные параметры получается как бы само собой и ошибок в этом достаточно мало.
Впрочем в 6х рельсах для особых случаев добавили таки сервисы с DI.
Не так уж страшна оказалась динамика, если следить за чистотой кода, тестами и по максимуму изолировать программный клей от логики.
Здравствуйте, Dair, Вы писали:
D>Я не веб-программист вообще, деньги я зарабатываю разработкой под мобильные, т.е., С++/Objective-C/Java/Swift/Kotlin. Но иногда мне надо не по работе сваять бэкэнд. D>Я знал python и был наслышан про Django, поэтому первым делом сунулся в Django.
Быстрее, лучше и проще взять отдельные либы для db и веба по вкусу и намешать их в нужном количестве. В питоне именно этот подход популярен, а не всемогуторы, включая Django или RoR.
Даже древний zope не был так плох.
