Какая г.. эти ваша идеология рельсов

Это обратная сторона DSL. Если DSL пишет псих, то остальным будет плохо.

В рельсах нет такой функциональности, это какая-то сторонняя библиотека.

Что мешает добавлять в крон что и как ты хочешь, а не использовать сторонюю библиотеку, которая предоставляет свой DSL и методы для описания крон-задач?

С таким же успехом можно называть GNU/Linux говном, ведь там есть systemd с бинарными логами и ZFS с кривой лицензией.

Предыдущему разработчику значит было так удобней почему-то. Можешь у него спросить почему.

Не нравится – не используй, отключи библиотеку и пиши задачи в крон руками.

Неосилятора-нытика тред детектед.

Причем я бы понял если бы ненерили отдельные cron файлы - но тут просто добавляется фактически в системный файл. Это нормально ?

Нет, но рельсы тут ни при чём :-)

А RoR тут притом что... Закончи пожалуйста. Иначе это 4.2

должен же быть какой-то козел отпущения

RoR на эту роль отлично подходит:

• Здесь нет рубистов, поэтому никто не вступится

• Язык, который нигде вне RoR не используют

• Фреймворк на идеологии предыдущего поколения, сейчас идеология фулл JS-фронтенда с серверным JSON API, максимум там есть прозрачный сервер сайд рендеринг и статик сайт генерация

• Огромное количество шизиков, которые пользуются технологией которую нужно знать так, как будто этого не нужно (опять же несовпадение поколений - большинство мусора с npm знать не нужно).

• Также огромное количество шизиков, для которые кроме руби ничего не видели и на любую критику устраивают религиозную истерику

• Очень неудобно жить на Windows. Напоминаю, Windows все еще основная операционная система в мире

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

• Куча рубистов, которые не только не пишут документацию, но и тесты тоже не пишут. Это совсем финиш.

Продолжать?

Мы однажды переписывали на Java огромную ынтерпрайз систему после команды рубистов, которая дальше не могла ее поддерживать. Задача была - переписать все фичи один в один, только на джаве, чтобы это можно было поддерживать. Моя первая задача была сделать систему бронирования слотов (как в самолете) с таймаутом резервирования 30 минут (если за 30 минут слот не выкупается, то резерв отменяется и надо выбирать заново). Предыдущий рубист разрабатывал ее месяц (!) и закрыл тикет как не поддающийся реализации. Я написал ее за день. Может быть, знал подводные камни, но в тикете об этом ничего сказано не было.

https://github.com/javan/whenever

Ну да вроде сторонняя но все равно написано с использованием идеологии рельсов ( все в одном )

Идеология «все в одном»

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

Опять подмена понятий.

На джава-фреймворках невозможно написать говно, неподдерживаемое говно и неподдерживаемое говно с сервер-сайд рендерингом?

Зачем травить байки про какие-то конкретные проекты, которых никто, кроме вас, не видел и непонятно кем написанные и на личном анализе их, с подмешиванием собственных привычек, делать какие-то громкие выводы?

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

Использование Django, Rails, Laravel и т.п. абсолютно никак не гарантирует, что все приложения написанные на них являются говном.

Ну да вроде сторонняя но все равно написано с использованием идеологии рельсов ( все в одном )

Ты сейчас на ноль поделил. Если идеология всё в одном, то почему библиотека сторонняя?

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

Будь толерантнее! Дружная команда рубистов тебя всему научит. И баттплаг подарит

Ты мне расскажи почему рельсы игнорируют контстраинты между таблицами ?

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

Ничто не мешает работать и проектировать одновременно и на уровне activerecord и на уровне БД. Наоборот, такое дублирование является хорошим тоном и позволяет на ранних этапах выловить возможные ошибки.

На джава-фреймворках невозможно написать говно, неподдерживаемое говно и неподдерживаемое говно с сервер-сайд рендерингом?

думаю, что разработка сайтов на Java - это очень плохо. Если кто-то так сделал, то это уже говнокод просто по факту

разрабатывать на Java стоит микросервисы на сервере, которые будут заниматься вычислениями и хранением, и отдавать наружу результирующие данные с помощью JSON API и GraphQL. (это точно)

причем фронт-сервером к ним, кажется, стоит ставить Node.js, чтобы отдавать совместимый с фронтендом формат. (это уже не точно)

весь веб стоит разрабатывать только на JS фреймворках вроде Angular, React и Vue.

Предыдущий рубист разрабатывал ее месяц (!) и закрыл тикет как не поддающийся реализации. Я написал ее за день.

Это, конечно, 100% из-за того, что он на Ruby писал, а ты - нет.

причем фронт-сервером к ним, кажется, стоит ставить Node.js, чтобы отдавать совместимый с фронтендом формат. (это уже не точно)

Какая разница чем отдавать фронту сериализованные данные, т.е. JSON, если мы говорим про веб в 2020? Ничто не мешает писать бэкенд хоть на OCaml, если есть разработчики всё это потом поддерживать.

Почему на бэкэнд стоит ставить исключительно Node.js? Кроме как «один язык для фронтенда и бэкенда», но это весьма сомнительное преимущество и маркетинговая агитка начала десятых годов, и сейчас вроде бизнес уже как давно понял, что у других вариантов на бэкенде могут быть свои преимущества, часто куда более весомые, и хайп с нодой давно утих.

весь веб стоит разрабатывать только на JS фреймворках вроде Angular, React и Vue.

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

думаю, что разработка сайтов на Java - это очень плохо. Если кто-то так сделал, то это уже говнокод просто по факту

Почему бэкенд веб-приложения на Java это очень плохо? Не помешало бы подробное пояснение.

вот ты написал что-то на React или Angular. Но теперь ты хочешь, чтобы оно искалось в гугле. Значит тебе нужен React на сервере теперь, чтобы он генерил там. Значит тебе нужен JS на сервере, все-таки React ни на Java ни на Ruby не написан

теперь, у тебя react-router. Зачем тебе роутер еще и в джава-коде? Роутинг на стороне джавы оказываевается не нужен

теперь, страницы у тебя все равно генерит React. Значит такие штуки как Spring MVC не нужны. Да они и несовместимы между собой, тупо потому что смешать код на Java и JavaScript сложно (хоть и можно с помощью Nashorn или GraalVM). Еще один кусок отпал.

теперь, в старых веб-фреймворках был инструментарий для генерации страниц, в том числе крудов из моделей. Но дело в том, что если у тебя доменно-ориентированная микросервисная архитектура, то со стороны микросервисов у тебя нет таких понятий как «страница» - у тебя есть объекты доменной модели типа «пользователь» или «документ». Весь инструментарий про модели идет псу под хвост, т.к. у тебя может теперь и есть «модели», но в мире Domain Driven Design они значат другое

у тебя был ORM вроде Hibernate (кажется, лучший ORM из всех популярных языков вообще), но все больше и больше людей начинают писать тупо SQL, или всякие генераторы запросов. Hibernate - это слишком сложно. Все эти модные когда-то фичи, которые имели идею про то, что вот у тебя есть виджет, и у него есть нижележащая модель, которая является объектом в ORM - они больше не работают.

и так кирпичик за кирпичиком, всё что составляло сущность «веб-фреймворка» исчезает.

его всё еще, конечно, можно использовать, если ОЧЕНЬ изголяться - пихать туда GraalVM-ы, генерить из Hibernate схему для GraphQL и всё в таком духе, но это больно и жутко, и непонятно зачем нужно.

я знаю только один кейс - это нгужно для старичков, которые хотят что-то написать, но не могут, потому что пропустили изменения парадигмы. То, что сейчас происходит в мире - это не появление «еще одного чуть лучшего SpringMVC, который умеет еще лучше отдавать JSON», это прямо фундаментальные изменения в том, как должна выглядеть архитектура веба

тут еще конечно нужно написать огромный текст про Flutter, Kotlin.js, Progressive Web Apps и изоморфные мобильно-десктопные приложения но я пока не осмыслил эту тему, плюс надо ехать в Икею пока не закрылась и покупать матрас ;)

Почему бэкенд веб-приложения на Java это очень плохо?

Потому что сайты написанные на java становятся рассадниками безумцев. Посмотри на ЛОР, посмотри на стивджобса (:

вот ты написал что-то на React или Angular. Но теперь ты хочешь, чтобы оно искалось в гугле. Значит тебе нужен React на сервере теперь

Чегоо?

и так кирпичик за кирпичиком, всё что составляло сущность «веб-фреймворка» исчезает.

Вопрос был не почему нужен фреймворк X (хотя это довольно условный и многозначный термин), а почему нужен именно Node.js на бэкэнде. Можно пилить что угодно и без фреймворков, но непонятно почему исключительно на ноде и джаваскрипте.

у тебя был ORM вроде Hibernate (кажется, лучший ORM из всех популярных языков вообще), но все больше и больше людей начинают писать тупо SQL

На Java нельзя писать «тупо SQL», если захочется? Только из ноды можно дёргать?

На Java нельзя писать «тупо SQL», если захочется? Только из ноды можно дёргать?

Если ты модный IT евангелист, то нельзя. :)

Правда он жава евангелистом был вроде как, а тут получается жава не нужна - фронт на реакте, бек на ноде, микросервисы с «вычислениями» уровня достать из базы и отдать в json.

Как так получилось - загадка.

Язык, который нигде вне RoR не используют

Кто тебе такую глупость сказал?

Моя первая задача была сделать систему бронирования слотов (как в самолете) с таймаутом резервирования 30 минут (если за 30 минут слот не выкупается, то резерв отменяется и надо выбирать заново). Предыдущий рубист разрабатывал ее месяц (!) и закрыл тикет как не поддающийся реализации. Я написал ее за день.

Удивительно, но мой опыт работы с командой рубистов был примерно таким же. На какие-то банальные задачи уходило чудовищное количество времени.

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

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

Такое кто угодно может сказать и про Haskell и про С и про Prolog. Любую неверифицируемую байку.

Про Haskell я сам знаю забавную историю, когда хаскелист писал проект три недели и его решение не проходило все acceptance-тесты и он так и не смог за дополнительную неделю исправить проект до полного прохождения тестов, и в итоге решение на OCaml разработчиком из французского филиала было написано за 8 рабочих дней и работало идеально.

Репрезентативный ли это показатель? Думаю, что нет. И мне и голову не приходит считать любителей Haskell тупицами и русских программистов идиотами (а хаскелист был русским).

Учитывая, что Ruby и Python очень часто компании и стартапы выбирают в вебе для быстрого прототипирования и демонстрации концепта, то байки про чудовищное количество времени на банальные задачи читать смешно.

+1

Репрезентативный ли это показатель? Думаю, что нет. И мне и голову не приходит считать любителей Haskell тупицами.

А конкретно этого любителя хацкелла?

Учитывая, что Ruby и Python очень часто компании и стартапы выбирают в вебе для быстрого прототипирования и демонстрации концепта, то байки про чудовищное количество времени на банальные задачи читать смешно.

Почему? Никто же не говорит, что на руби или пистоне невозможно быстро писать прототипы. И никто не говорит, что все разработчики на руби – поголовно дебилы. Но многие жалуются, что при работе с жирной кодовой базой на этих языках накладные расходы на разработку возрастают до небес. Что, заметь, к разработке прототипов отношения вообще не имеет.

Почему? Никто же не говорит, что на руби или пистоне невозможно быстро писать прототипы. И никто не говорит, что все разработчики на руби – поголовно дебилы. Но многие жалуются, что при работе с жирной кодовой базой на этих языках накладные расходы на разработку возрастают до небес. Что, заметь, к разработке прототипов отношения вообще не имеет.

Если не использовать метапрограмирование на метапрограммировании, не забивать на документацию и неистово блюсти KISS, то разработка ничем не отличается от других динамических языков. Т.е. «жирная кодовая база» одинаково замедлит внесение существенных изменений в проект написанный на любом динамическом языке, будь то Ruby, Python, PHP, JS и т.п.

Что не мешает существовать всяким Электронам и Дискурсам с Гитлабами и Гитхабами.

Хотя если использовать TDD/BDD и соблюдать SOLID и DRY, то не так уж и катастрофично всё. Не у каждого и не каждая задача это «фейсбуки» писать по пять раз на день.

И именно ради этого и в Пайтоне и в Руби запиливают аннотации типов, чтобы можно было сильно упростить себе жизнь на больших проектах. А в Руби в след. версии ещё и полностью иммутабельные строки.

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

Вот ТС типичный этому пример – видит что-то, что сделано не так как он привык (синдром утёнка) – бежит и кричит, что всё говно и всё не так. Хотя говном, скорее всего, будут смотреться его собственные правки в этом проекте.

А конкретно этого любителя хацкелла?

Он просто поверил, что существует серебряная пуля и она у него в обойме. А оказалось, что объектность OCaml пришлась в конкретной задаче как нельзя лучше к месту. Хотя и тот и тот это ML-языки, которые непосвящённый условный Вася Пупкин с виду, может, и не различит.

Что не мешает существовать всяким Электронам и Дискурсам с Гитлабами и Гитхабами.

Это не то чтобы аргумент. Мегамонстрам на коболе тоже ничего существовать не мешало. К счастью, они сдохли вместе с коболом.

И именно ради этого и в Пайтоне и в Руби запиливают аннотации типов, чтобы можно было сильно упростить себе жизнь на больших проектах.

То есть, статическая типизация таки победила? Впрочем, я не уверен, что это поможет. По опыту Erlang, где аннотации есть давно, очень часто, особенно при работе с неаннотированными сторонними библиотеками, вся эта шняга скорее мешает. Так что, исходя из моего опыта, лучше полностью переходить на статическую типизацию.

Хотя если использовать TDD/BDD и соблюдать SOLID и DRY, то не так уж и катастрофично всё

Ну да, всего-то нужно весь код дважды писать: сам код и тесты для него.

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

Т.е. хорошие программисты с хорошим менеджментом пишут хороший код, плохие – плохой код. Кто бы мог подумать?

Хотя говном, скорее всего, будут смотреться его собственные правки в этом проекте.

Или нет.

Парадоксальная вообще штука. Язык неплохой, а все приложения - говнокод.

Полная противоположность питону, который сам по себе то ещё поделие, но качественного кода на нем очень много.

Мне очень нравится руби по концепции. Но поддерживать на нем существующий код - извините….

Потрясающий коммент с неожиданным финалом :D

Спасибо, прямо от души)

Имхо, культура какая-то такая. Язык-то вполне себе язык, мудьтипарадигменный, с читабельным синтаксисом, с неплохой по скорости реализацией (неплохой для скриптухи).

React на сервере теперь

Чегоо?

когда ты на урл щелкаешь в браузере, тебе страничку рендерит JS на клиенте. Но гугл у тебя при переходе на тот же урл не сможет запустить настолько сложный JS, у него движок JS примитивный и ограниченный по времени. Кроме того, юзер может перейти на этот урл по внешней ссылке с ЛОР-а, и будет крайне огорчен, если ему страничка будет рендериться не сразу, а с промежуточными этапами. Поэтому у тебя два сценария: в браузере JS, а при прямом переходе тебе совершенно идентичную страничку нужно отрендерить на сервере.

так как UI у тебя весь написан на Angular / React / Vue / …, то если коротко, это означает, что и в браузере и на сервере у тебя должен быть один и тот же реакт (чтобы не перечислять их все, пусть здесь и далее героем будет реакт). Но так как реакт - это никакой не стандарт и не спецификация, то существует ровно один способ заиметь реакт - запустить его единственную на свете джаваскрипт реализацию прямо на сервере, и вот она будет тебе рендерить странички по прямой ссылке. Способности Джавы запускать JS даже с учётом GraalVM - крайне слабые, поэтому по сути, тебе нужно иметь на сервере Node.js в качестве генератора страниц по-любому. Куда ты уж его впендюришь - вопрос второй, но самый простой способ - поставить её фронт-сервером

заметь, что речь тут шла именно о server side rendering, а не о static site generation. Именно о случае, когда сгенерированный результат может варьироваться в зависимости от текущего состояния пользователя, параметров урла и других глобальных обстоятельств - то есть, заранее отрендерить это всё как статический сайт и вложить на nginx нельзя

а почему нужен именно Node.js на бэкэнде

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

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

Упрощаются разные элементарные штуки вроде того, что всё равно тебе весь браузерный фронтенд нужно собирать Webpack-ом и Babel-ем, то есть нода уже используется в процессе сборки любой HTML страницы, и можно упростить процесс выкладки, заставив ноду же и отрабатывать простейшие запросы.

Всеми этими вопросами вроде провязки браузер-серверного API, выкладкой, управлением зависимостями, итп могут заняться фронтендеры без помощи бэкендеров. Каждый наконец находится на своём месте. Тем более, что джава-бэкендеры как правило срать хотели на богомерзкий JS и наоборот, а фронтендеры о том как работает бэк имеют самое смутное представление и SQL в последний раз видели в голливудских хоррор фильмах. У всех у них совершенно разыне пайплайны сборки, CI/CD, дистрибуции, итп, и это дополнительно развязывает руки.

Там есть более умные способы вроде GraphQL, который позволяет наладить диалог между фронтендерами и бэкендерами, но это еще один пласт истории.

Конечно, надо не забывать про Flutter, который может теоретически убить весь современный веб и мобайл, переведя всё на совершенно новый гибридный фронтенд, общий для мобилы и веба. Туда же Kotlin Native. И там везде будут свои нюансы. Не надо забывать про Progressive Web Apps, у которых пайплайн разработки и дистрибуции несколько другой.

Но теперь ты хочешь, чтобы оно искалось в гугле

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

Что мешает добавлять в крон что и как ты хочешь, а не использовать сторонюю библиотеку, которая предоставляет свой DSL и методы для описания крон-задач?

Тонкий намёк на системдэ таймеры?

Полная противоположность питону, который сам по себе то ещё поделие, но качественного кода на нем очень много.

Только в манямирке утят и воображаемой вселенной.

То есть, статическая типизация таки победила?

На огромных проектах – да. На неогромных и не пишущихся годами особого смысла в ней нет, хотя опционально и в отдельных местах была бы и не лишней.

думаю, что разработка сайтов на Java - это очень плохо. Если кто-то так сделал, то это уже говнокод просто по факту

смотря какой сайт. Работать с базой из явы несколько приятнее чем из пистона или js. Или ты про фронт?

весь веб стоит разрабатывать только на JS фреймворках вроде Angular, React и Vue

вот так веб в говно и катится

Только в манямирке утят и воображаемой вселенной.

Программист на Ruby не палится с лексикой недоразвитого.

Программист на Ruby не палится с лексикой недоразвитого.

А что на счёт твоего паления с примерами недоразвитых?

Или это не из этих?

Ты писал:

Все приложения на Ruby - говнокод.
Полная противоположность питону, который сам по себе то ещё поделие, но качественного кода на нем очень много.

Это не балабольство недоразвитого?

Чтобы это не было религиозными установками, нужен какой-то объективный и верифицируемый способ оценки.

А пока это выглядит словно утверждение «все приложения с лицензией GPL шикарны, а с BSD - написанные людьми с задержками в развитии и когнитивными дисфункциями». «Все приложения на Си – говнокод, а на Паскале качественного кода очень много.»

Какими критериями это доказывать и опровергать – непонятно. Забежал, ляпнул что-то с умным видом и всё.

Припекает, панемаю.

Кстати, как раз размышлял сейчас.

Вот взять, например, PHP. Язык — просто свалка из фич и функций, которые вводились без всякой логики и соответствия друг другу. Помойка, а не язык.

Но я встречал много грамотных программистов и просто вменяемых людей, в том числе и здесь на ЛОР, которые этим языком пользуются и успешно решают задачи. Ну, наверное потому что бизнес требует, так почему бы не писать код. Какая разница на чем, если клиент доволен?

С другой стороны, Ruby действительно во многом первоклассный язык. Но вот сообщество вокруг него подобралось… гм. Своеобразное. Вот взять тебя, брызжащего слюной. Всё нормально, продолжай в том же духе.

все приложения - говнокод

Вот взять тебя, брызжащего слюной.

Ага-ага.

вроде бизнес уже как давно понял Да комон, что там этот бизнес понял)

ЗЫ давно я тут не холиварил..

Чтобы это не было религиозными установками, нужен какой-то объективный и верифицируемый способ оценки.

Есть неплохой способ оценки, и это сравнение времени перехода с ruby 1.8 на ruby 2.0 и с python 2.x на python 3.0. Когда рубисты все переписали махом, а питонщики еще не закончили миграцию.

Но вообще, трудно не признать, что js побеждает, а бэк становится все тоньше. А если смотреть в корень, то, наверное, меняется само назначение веб-приложений.

Есть неплохой способ оценки, и это сравнение времени перехода с ruby 1.8 на ruby 2.0 и с python 2.x на python 3.0. Когда рубисты все переписали махом, а питонщики еще не закончили миграцию.

Я не думаю, что тут причина в неком эфемерном «говнокоде», который мерещится всякого рода сектантам и утятам с их синдромом. Я слабо представляю себе объём изменений между Python 2 и 3, только наслышан, но изменения между Ruby 1.8 и 2.0 (для конечного разработчика, если не брать то, что под капотом) не такие уж и разительные, чтобы все написанные библиотеки и приложения легли мёртвым грузом. Возможно между пайтонами изменения были более радикальными и уж точно совсем никак не следует, что все приложения на нём – это говнокод.

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