> Как вы думаете, в современной автомобильной промышленности при каких обстоятельствах автоконцерн вкладывается в разработку своего собственного стеклоподъемника, а не возьмет готовый, хороший и стандартный агрегат? Или когда автоконцерн занимается разработкой нового аккумулятора, а не довольствуется стандартным? Может, даже приведете пример такой компании?
> А вот в нашей области разработки ПО почему-то написание собственных велосипедов возведено чуть ли не в романтическую степень.
А еще в нашей области разработки ПО очень любят дурацкие метафоры. Стеклоподъемник делает очень ограниченную задачу. И интеграция простейшая — +12В, масса, подключение к CAN-шине (на худой конец к сигнальному опять же 12В проводу) — все!
А теперь вспомните фреймворки — шаг в сторону от задуманного автором фреймворка — и начались проблемы…
Да, и почему-то роуты описываются индивидуально.
Нельзя взять и объявить resources :users скажем (такая фича есть разве что в grails, но до лаконичности рельсовой версии ей далеко).
Зачем это нужно? Проще менять роуты.
Database Evolutions не предоставляет никакого обобщенного DSL, нужно писать сырой SQL.
Да, контроля больше. Но с другой стороны, в 95% случаях мне хватало и рельсового DSL, а если уж не хватает, ничего не мешает (почти — автоотката все же не будет) написать специфичный сырой SQL.
Не покидает ощущение недоделанности. При всех недостатках рельсов, у них есть основная идея — удобство разработчика (да, я понимаю, зачастую в ущерб каким-то другим вещам). И вот эту идею в JVM-фреймворках реализуют, на мой взгляд, не в полной мере.
P.S. я разрабатываю и на RoR и на Java, т считаю, что RoR в JVM можно назвать лишь ее же но на jruby. Однако мне она не подошла — см. коммент выше.
Спасибо. Забавно конечно, но не JVM (есть 3rd party библиотека, ради которой весь сыр-бор). А если устраивать межпроцессное взаимодействие а-ля микросервисы, проще взять те же рельсы и не мучиться. Да и не все привычные фичи в vibe.d есть. Не нашел route resources и миграций например.
В JVM-фреймворках с этим, к сожалению, печально.
Искал JVM замену рельсам.
Rails-alike фреймворки существуют, но почему то они не переняли некоторых удобных деталей.
Эти самые URL, миграции, routes.rb с resources :foo, only: [:index, :show], лейауты. Разве что грусть-тоска по asset pipeline отпадает сама собой с появлением webpack и подобных.
jruby on rails сначала показались находкой. Но jruby быстро разочаровала страшными тормозами, очень сильная деградация в зависимости от количества библиотек/кода. TDD-ить невозможно. Прелоадеры глючат. Боль короче)
Конечно нужен. Я использовал sparkjava для небольшого инфраструктурного сервиса. SPA городить слишком жирно, вывести-то всего пару табличек. В целом, было несколько более трудоемко, по сравнению с большими фреймворками.
> Процесс Руби (и Рейлс) запускается только тогда, когда сервер начинает обрабатывать запрос. Поэтому, если, к примеру, необходимо выполнять какое-то действие каждый час, в среде Рейлс придётся использовать CronJob.
Автор давно не писал rails app видимо. Или не так выразился.
> A Ruby (on Rails) process only runs when the web server starts it to answer a request.
В настоящее время, на практике, процесс рейлс стартует единожды, до следующего перезапуска (скажем, в результате редеплоя). По крайней мере в passenger. Не говоря уж о встроенных серверах типа thin, puma итп. Я так и представил себе, как пользователь ждет каждый раз от 3 сек. до нескольких минут…
Другое дело, что действительно, rails представляет возможность лишь обработать запрос. Из коробки, нельзя просто так взять и запустить фоновую задачку в рамках того же процесса (потоки? Здесь это не лучшая идея).
Помимо cron jobs, используются исполнители фоновых задач, такие как delayed_job и sidekiq. Грубо говоря, это еще один rails процесс, который не выполняет веб-запросы, а периодически поллит хранилище задач. Задачи создаются в основных процессах. Существуют планировщики поверх этих исполнителей, например — github.com/moove-it/sidekiq-scheduler
P.S. феникс/эликсир понемногу пробую, пока еще не распробовал, но кажется довольно интересным.
Верно, LGPL вроде бы подходил, но там были нюансы с линковкой. Думаю, что я бы на этом на какое то время увяз, не имея опыта с Qt (и вообще в целом опыт с С++ только в далекие студенческие времена. Да и то скорее — опыты, а не опыт)). А времени было 2 недели на апп + бэкенд.
Да, вы правы, это был очень слабый аргумент. Или неверный.
Вообще, Qt меня очень привлекает с точки зрения ТТХ. Но как-то каждый раз с ним не срастается, слишком много нужно про него узнать.
Слишком широкое заявление. По сравнению с чем? На каких задачах? При каких настройках/ограничениях? У меня rails worker'ы больше памяти потребляют, чем куда-более нагруженный java сервис. Но выводов каких-то я из этого не делаю. Задачи разные и решены по разному.
P.S. в то же время так противопоставлять Electron vs Java FX — это ИМХО несколько перебор.
Делаю хобби-проект с BLE 4.0. Тоже нужна небольшая программка, сидящяя в трее. С BLE 4.0 в Java довольно печально. Qt традиционно «не осилил», хотя честно пытался) А вот для node.js библиотека завелась с полтычка: github.com/sandeepmistry/noble. Если учесть, что мне еще нужны веб-сокеты для интеграции с внешним сервисом, а каких-то ограничений по размеру/производительности не стоит — выбор Electron выглядит вполне разумно.
> А вот в нашей области разработки ПО почему-то написание собственных велосипедов возведено чуть ли не в романтическую степень.
А еще в нашей области разработки ПО очень любят дурацкие метафоры. Стеклоподъемник делает очень ограниченную задачу. И интеграция простейшая — +12В, масса, подключение к CAN-шине (на худой конец к сигнальному опять же 12В проводу) — все!
А теперь вспомните фреймворки — шаг в сторону от задуманного автором фреймворка — и начались проблемы…
Нельзя взять и объявить resources :users скажем (такая фича есть разве что в grails, но до лаконичности рельсовой версии ей далеко).
Зачем это нужно? Проще менять роуты.
Database Evolutions не предоставляет никакого обобщенного DSL, нужно писать сырой SQL.
Да, контроля больше. Но с другой стороны, в 95% случаях мне хватало и рельсового DSL, а если уж не хватает, ничего не мешает (почти — автоотката все же не будет) написать специфичный сырой SQL.
Не покидает ощущение недоделанности. При всех недостатках рельсов, у них есть основная идея — удобство разработчика (да, я понимаю, зачастую в ущерб каким-то другим вещам). И вот эту идею в JVM-фреймворках реализуют, на мой взгляд, не в полной мере.
P.S. я разрабатываю и на RoR и на Java, т считаю, что RoR в JVM можно назвать лишь ее же но на jruby. Однако мне она не подошла — см. коммент выше.
Искал JVM замену рельсам.
Rails-alike фреймворки существуют, но почему то они не переняли некоторых удобных деталей.
Эти самые URL, миграции, routes.rb с resources :foo, only: [:index, :show], лейауты. Разве что грусть-тоска по asset pipeline отпадает сама собой с появлением webpack и подобных.
jruby on rails сначала показались находкой. Но jruby быстро разочаровала страшными тормозами, очень сильная деградация в зависимости от количества библиотек/кода. TDD-ить невозможно. Прелоадеры глючат. Боль короче)
Автор давно не писал rails app видимо. Или не так выразился.
> A Ruby (on Rails) process only runs when the web server starts it to answer a request.
В настоящее время, на практике, процесс рейлс стартует единожды, до следующего перезапуска (скажем, в результате редеплоя). По крайней мере в passenger. Не говоря уж о встроенных серверах типа thin, puma итп. Я так и представил себе, как пользователь ждет каждый раз от 3 сек. до нескольких минут…
Другое дело, что действительно, rails представляет возможность лишь обработать запрос. Из коробки, нельзя просто так взять и запустить фоновую задачку в рамках того же процесса (потоки? Здесь это не лучшая идея).
Помимо cron jobs, используются исполнители фоновых задач, такие как delayed_job и sidekiq. Грубо говоря, это еще один rails процесс, который не выполняет веб-запросы, а периодически поллит хранилище задач. Задачи создаются в основных процессах. Существуют планировщики поверх этих исполнителей, например — github.com/moove-it/sidekiq-scheduler
P.S. феникс/эликсир понемногу пробую, пока еще не распробовал, но кажется довольно интересным.
Смущает следующее: «All you need is a BLED112 dongle on a PC.». Это реализация API для конкретного адаптера?
Всего лишь? Или это зависит от автора/книги? Неужели, скажем, условному Роберту Мартину, за права на перевод тоже платят $200?
Пользователи смотрят кол-во занятой памяти — «ооо, Джава жрет».
Да, вы правы, это был очень слабый аргумент. Или неверный.
Вообще, Qt меня очень привлекает с точки зрения ТТХ. Но как-то каждый раз с ним не срастается, слишком много нужно про него узнать.
Слишком широкое заявление. По сравнению с чем? На каких задачах? При каких настройках/ограничениях? У меня rails worker'ы больше памяти потребляют, чем куда-более нагруженный java сервис. Но выводов каких-то я из этого не делаю. Задачи разные и решены по разному.
А это причина, по которой OSS лицензия не подходила.
Делаю хобби-проект с BLE 4.0. Тоже нужна небольшая программка, сидящяя в трее. С BLE 4.0 в Java довольно печально. Qt традиционно «не осилил», хотя честно пытался) А вот для node.js библиотека завелась с полтычка: github.com/sandeepmistry/noble. Если учесть, что мне еще нужны веб-сокеты для интеграции с внешним сервисом, а каких-то ограничений по размеру/производительности не стоит — выбор Electron выглядит вполне разумно.