Здравствуйте, sfsoft, Вы писали:
S>Не знаю насколько ты знаком с работой с СУБД и Джавой, S>но, к примеру, если мы обновляем метаданные в БД, то и в сервере приложений нужно изменить сигнатуру sql-запросов.
Обычно наоборот делается — новый jar обновляет БД под себя (Liquibase, Flyway etc)
S>То есть exe или jar тоже нужно заменить. Как заменить exe — мы знаем, а как заменить jar после апдейта метаданных БД в том же Tomcat без админа — увы, знаний не хватает. Возможно как раз потому, что с Джавой плохо знакомы. Потому и спрашиваю здесь.
Не надо jar в томкат пихать. Можно пихать томкат в jar. https://docs.spring.io/spring-boot/docs/current/reference/html/executable-jar.html
Здравствуйте, Pzz, Вы писали:
Pzz>Но зато, хоть это и вкусовщина, Go — гораздо более приятный язык.
Вообще пофиг на вкус.
Главный вопрос, где программистов искать.
По PHP я могу пойти в ближайшую ночлежку и у меня будет очередь.
По Java я найду людей по объявлению на городском форуме.
А по Go я вообще их в живом виде не видел, наверное в интернете обитают, но вид довольно редкий.
Здравствуйте, sfsoft, Вы писали:
S>Потенциальное решение: переписать на Лазаре или на Java. Честно — Лазарь не нравится. Да и используется часть возможностей Дельфи, которые в нем недоступны (например, аннотации к private членам класса). Но у Джавы, если выбирать ее, есть проблемы с деплойментом, нужен админ.
Нужен админ, чтобы залить .jar на сервер и запустить через java -jar?
S>Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
У одного из моих заказчиков крутится 3 сервиса на Java. Все запущены как обычные приложения, без всяких web-application-server. Запускаются через systemd и стоит watchdog. Правда, я бы не назвал это shareware.
Здравствуйте, sfsoft, Вы писали:
S>Вводные: есть десктоп приложение на Дельфи, которое активно работает с СУБД через собственный сервер приложений. Также написанный на Дельфи. В общем классическая трехзвенка.
S>Проблема: в сервере приложений есть сторонние компоненты не особо хорошего качества, которые «текут» по памяти. Плюс юзеры хотят Линукс, хотя бы на сервере.
S>Потенциальное решение: переписать на Лазаре или на Java. Честно — Лазарь не нравится. Да и используется часть возможностей Дельфи, которые в нем недоступны (например, аннотации к private членам класса). Но у Джавы, если выбирать ее, есть проблемы с деплойментом, нужен админ.
S>Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
Я бы вам советовал wine. Поставьте линукс, поставьте wine, запустите ваше приложение под ним и, если будут проблемы, попробуйте их точечно исправить. Хотя с консольным приложением, с большой вероятностью, проблем никаких не будет.
Java это хорошо, но её надо уметь готовить. Судя по вашим сообщениям вы её приготовить не сумеете и она принесёт вам больше проблем. Если всё же возьмётесь, забудьте всё, что вы о ней знали, и приступите к работе с чистого листа. Вам нужен Spring Boot.
Здравствуйте, cppguard, Вы писали:
C> запустить через java -jar
C>Запускаются через systemd
Более того: если писать сервер на Spring Boot (а так в Джаве сейчас и делают), то он автоматом собирает самозапускаемый .jar-файл, который может реагировать на стандаартные параметры командной строки, которые передают демону (сервису): "start", "stop", "status", и его можно тупо сразу линковать в /etc/init.d и настраивать автозапуск.
Плюсую за Java. Сам по вышеописанной схеме сервер с БД держу для всех своих SaaS-сервисов (но не распространяю его, сервер чисто у меня).
vsb>Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.
тут же шаравара. не будешь же ты писать скрипт который поставит жаву нужной тебе версии, поломав клиенту весь остальной софт. так что тут достаточно важно как запускать и чего делать если апгрейд скрипты базы выполнились с ошибкой.
Здравствуйте, Иль, Вы писали:
vsb>>А какие альтернативы? Спринг бут это 90% жава "рынка". Библиотек, конечно, миллион, но по буту хотя бы есть ответы на все возможные вопросы.
Иль>Есть ответы на базовые и/или стандартные вопросы. Есть ответы на некоторые нестандартные вопросы. Но тут уже надо чтобы совпала версия спринга, по которой отвечали и той, которую используешь. А ответов на большинство нестандартных вопросов нет.
Мой опыт другой, я на все свои вопросы обычно ответы нахожу очень быстро. Редко бывает, что не нахожу. Обычно если хочу очень странного. Порой это признак того, что делаю что-то не так.
Иль>ИМХО спринг часто ошибочно воспринимают как такое самостоятельное универсальное решение. В реальности же помимо самых базовых вещей — (spring core кажется оно называется) — типа позднего связывания через Reflection (что, кстати, не так уж и сложно сделать и без спринга при желании) и т. п. — спринг просто объединяет кучу сторонних библиотек. Но что мешает использовать те же самые библиотеки без спринга? Т. е. не подтягивая кучу ненужных зависимостей через Spring Boot?
Какие библиотеки? Spring MVC/Spring WebFlux это вполне себе самостоятельная библиотека для роутинга. Или взять встраиваемый томкат. Я его пытался без спринга встраивать как-то раз. У меня ещё была стадия непринятия бута. Потом залез в исходники этого самого бута, оценил, сколько они там "клея" написали для того, чтобы этот самый встраиваемый томкат у них заработал, и это было одной из вех моего "принятия" бута.
Иль>Например Srping data прикольная вещь для больших проектов. Но иногда она не нужна. А надо, допустим, исполнить запрос к БД хотя бы через тот же spring jdbc. Так вот spring boot отдельно spring jdbc не подтягивает, а только в комплекте с чем-то монструозным.
Не очень понял, о чём речь. Просто добавляешь spring-jdbc в зависимости и всё, не?
У спринг бута есть два функционала.
Первый функционал это автоконфигурирование спринга. Я раньше писал без бута. Ничего страшного в этом нет, но настройка компонентов требует времени и усилий. Если пишешь огромный монолит на 100 человеколет, то нормально. А если пишешь микросервисы, по 10 штук в год, то эти усилия уже будут занимать измеримый процент, поэтому тут бут себя оправдывает.
Второй функционал это уникальный функционал. К примеру тот же упомянутый встроенный томкат. Там довольно много кода написано. Думаю, и другой функционал есть подобного рода. Хотя можно и без встроенного томката обойтись или таки самому написать что нужно.
При этом ничего не мешает тебе использовать спринг бут там, где ты хочешь и не использовать его там, где ты не хочешь. Как в примере со spring-jdbc. Просто добавь зависимость, сконфигурируй датасорс руками, jdbctemplate-ы и тд. И всё. Бут этому никак не помешает. Или подключай бут со spring data и просто игнорируй его. Он особо кушать не просит. А spring-jdbc в зависимостях уже по-любому будет и сконфигурирован будет автоматом.
Pzz>Может на Go? Будет все ваше приложение — один большой статически слинкованный исполняемый файл. Соответственно, при обновлении он, один, и меняется целиком.
Иль>Да фиг знает. Может быть вам стоит почитать прекрасный мануал, где это всё описано?
если не знаешь, чего влез то рассуждение по теме в которой абсолютный ноль ?
Иль>Я как-то беседовал со спецом, который ровно то же самое говорил про EJB. Типа нафиг ваши поделки типа спринга, когда есть испытанный временем промышленный стандарт, который делает всё то же самое и даже больше, есть куча серверов под него и куча профессиональных спецов? ... Блин, что за тоталитарность сознания? Спринг — не первый IoC и не последний. И джава не равна спрингу (и чему бы то ни было ещщё), как бы кому из подсевших на тот или иной фреймворк этого не хотелось.
ну так этот спец то теперь, когда спринг стал промышленным стандартом, топит за него. как и все остальные, что еще вчера топили за EJB. о том и речь — достигнет критической массы, тогда и поговорим. конечно спринг что-то заменит. в один момент казалось, что Scala заменит вместе с жава синтаксисом, но критической массы набрать не удалось и многим проектам такой эскперимент дорого стоил.
Здравствуйте, Pzz, Вы писали:
Pzz>Да не, их все больше становится. И потом, Go вам не Ява, любой сишник его за неделю выучит.
Я помню у Яндекса при приеме на работу джуниоров был FAQ:
Яндекс HR: Нам нужно знание C++
Претендент: Я знаю PHP, С++ выучу за две недели уже в процессе работы
Яндекс HR: Ждём вас на собеседование через две недели :trollface:
Вводные: есть десктоп приложение на Дельфи, которое активно работает с СУБД через собственный сервер приложений. Также написанный на Дельфи. В общем классическая трехзвенка.
Проблема: в сервере приложений есть сторонние компоненты не особо хорошего качества, которые «текут» по памяти. Плюс юзеры хотят Линукс, хотя бы на сервере.
Потенциальное решение: переписать на Лазаре или на Java. Честно — Лазарь не нравится. Да и используется часть возможностей Дельфи, которые в нем недоступны (например, аннотации к private членам класса). Но у Джавы, если выбирать ее, есть проблемы с деплойментом, нужен админ.
Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
Здравствуйте, YuriKobets, Вы писали:
YK>Это какие проблемы? Как-то столкнулся с похожей проблемой и выбрал Java, правда из другого набора. Никаких проблем не испытал.
Не знаю насколько ты знаком с работой с СУБД и Джавой, но, к примеру, если мы обновляем метаданные в БД, то и в сервере приложений нужно изменить сигнатуру sql-запросов. То есть exe или jar тоже нужно заменить. Как заменить exe — мы знаем, а как заменить jar после апдейта метаданных БД в том же Tomcat без админа — увы, знаний не хватает. Возможно как раз потому, что с Джавой плохо знакомы. Потому и спрашиваю здесь.
Здравствуйте, sfsoft, Вы писали:
s> Проблема: в сервере приложений есть сторонние компоненты не особо хорошего качества, которые «текут» по памяти. Плюс юзеры хотят Линукс, хотя бы на сервере.
s> Потенциальное решение: переписать на Лазаре или на Java. Честно — Лазарь не нравится. Да и используется часть возможностей Дельфи, которые в нем недоступны (например, аннотации к private членам класса). Но у Джавы, если выбирать ее, есть проблемы с деплойментом, нужен админ.
s> Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
Дельфи и сама умеет в линукс. С текучкой можно разобраться, при желании.
Здравствуйте, rudzuk, Вы писали:
R>Дельфи и сама умеет в линукс. С текучкой можно разобраться, при желании.
Я тоже люблю Дельфи всей душой, но в свете текущей ситуации хотим подстраховаться. Плюс Дельфи все таки в Линукс не до конца умеет, гуй только от Крюкова за отдельные деньги. И не факт, что он хороший, обезьяну до сих пор в чувство приводят. А гуй, хотя бы минимальный, нужен, апдейты только на сервере ставятся, ибо структуру БД приходится менять и делать ее бэкап на всякий случай. Вдруг клиент на бесперебойнике сэкономил и в момент апдейта комп выключится? Без прямого доступа к БД никак.
Здравствуйте, GarryIV, Вы писали:
GIV>Обычно наоборот делается — новый jar обновляет БД под себя (Liquibase, Flyway etc)
GIV>Не надо jar в томкат пихать. Можно пихать томкат в jar.
Супер, спасибо.
А если в момент апдейта метаданных что-то пойдет не так, например скрипт какой-то не пройдет? Сейчас у нас приложение само откатится на предыдущую версию, а здесь как , если jar уже новый?
Здравствуйте, sfsoft, Вы писали:
s> Я тоже люблю Дельфи всей душой, но в свете текущей ситуации хотим подстраховаться.
Тут, конечно, да.
s> Плюс Дельфи все таки в Линукс не до конца умеет, гуй только от Крюкова за отдельные деньги. И не факт, что он хороший, обезьяну до сих пор в чувство приводят.
Если ты про FMXLinux, то она бесплатно идет для редакций с линуксом. Но она так себе, да.
s> А гуй, хотя бы минимальный, нужен
В смысле, гуй на сервере нужен? А не окажется, что у клиентов нет иксов на серверах?
Здравствуйте, sfsoft, Вы писали:
S>Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
Есть инсталяторы джавовские вплоть до того что тащат нужный JRE, можно сделать пакеты отдавая их через apt-get и прописывать в /etc/init.d, написать sh скприт, сделать докер образ наконец.
P.S. Есть ещё fatJAR
Здравствуйте, sfsoft, Вы писали:
S>А если в момент апдейта метаданных что-то пойдет не так, например скрипт какой-то не пройдет? Сейчас у нас приложение само откатится на предыдущую версию, а здесь как , если jar уже новый?
Примерно все то же самое, можно откатить БД назад (если писать роллбек скрипты).
Ну и изменения делать транзакционными тоже полезно.
Здравствуйте, GarryIV, Вы писали:
GIV>Примерно все то же самое, можно откатить БД назад (если писать роллбек скрипты). GIV>Ну и изменения делать транзакционными тоже полезно.
Про БД вопросов нет, я про jar спросил. Как его обратно на старый заменить, если скрипты на базе не прошли? Вручную? Или есть какие-то варианты?
vsb>Java это хорошо, но её надо уметь готовить. Судя по вашим сообщениям вы её приготовить не сумеете и она принесёт вам больше проблем. Если всё же возьмётесь, забудьте всё, что вы о ней знали, и приступите к работе с чистого листа. Вам нужен Spring Boot.
Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
Gradle + shadow даст JAR со всеми зависимостями, который можно запускать как java — jar myjar.jar . По моему проще некуда.
S>Про БД вопросов нет, я про jar спросил. Как его обратно на старый заменить, если скрипты на базе не прошли? Вручную? Или есть какие-то варианты?
Самое простое — заменить вручную. Можно забрасывать этот jar в какую-нибудь систему версионирования — типа git или что-то ещё — и выкладывать/откатывать через неё (через рабочую копию).
При желании можно даже установить какую-нибудь систему CI/CD, которых куча. Но они по сути делают то же самое + ещё что-то дополнительное (типа автотестирования, проверки каких-то требований к коду и т. п.). Проблема с этими системами в том, что в каждой из них надо отдельно разбираться, а это требует времени/сил.
Иль>Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
как раз в этом и преимущество популярного инструмента — на любую нестандартную задачу будут сотни и тысячи гвайдов и топиков стековерфлова. всякие орм + рест с простенькой секьюрити вполне докой и гвайдами покрывается.
Здравствуйте, Gt_, Вы писали:
Иль>>Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
Gt_>как раз в этом и преимущество популярного инструмента — на любое нестандартную задачу будут сотни и тысячи гвайдов и топиков стековерфлова. всякие орм + рест с простенькой секьюрити вполне докой и гвайдами покрывается.
Вообще, все обсуждаемые в теме проблемы (миграции БД и их откаты, деплой и его откат и т.д.) имеют в джава энтерпрайзе стандартные типовые надежные и достаточно простые решения, отработанные годами бизнесом, который на этой самой джава энтепрайзе сидит (уже третий десяток лет пошёл). ТС может нанять на месяц джависта и девопсера с корпоративным опытом, они всё под ключ наладят на типовой инфраструктуре, типовыми стандартными инструментами и подходами, напишут инструкцию по сопровождению, и бинго, профит.
Здравствуйте, Иль, Вы писали:
Иль>Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
А какие альтернативы? Спринг бут это 90% жава "рынка". Библиотек, конечно, миллион, но по буту хотя бы есть ответы на все возможные вопросы.
Не, если есть много времени и желания заниматься интересным, я бы даже на com.sun.net.httpserver-е сделал веб-сервер, работающий с базой через JDBC, с кучкой своих велосипедов и итоговым размером жарки в пару сотен килобайтов. Которую потом вполне реально можно в полноценный бинарник преобразовать размеров мегабайтов в 15. Но... Так не делают.
Иль>Gradle + shadow даст JAR со всеми зависимостями, который можно запускать как java — jar myjar.jar . По моему проще некуда.
Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.
Иль>>Я бы напротив не стал бы с нуля связываться со Spring Boot. По личному опыту любое нестандартное требование приводит к необходимости ковыряться в исходниках самого спринга. И в этом даже людям с опытом можно увязнуть надолго.
Gt_>как раз в этом и преимущество популярного инструмента — на любую нестандартную задачу будут сотни и тысячи гвайдов и топиков стековерфлова. всякие орм + рест с простенькой секьюрити вполне докой и гвайдами покрывается.
Парадоксальным образом именно в этом проблема и кроется. Версий спринга — множество. Причём значительные отличия зачастую присутствуют даже в минорных версиях. При этом понять для какой версии и какой конфигурации написано то или иное руководство или дан тот или иной ответ — решительно невозможно.
Я, помнится, мучился примерно день методом тыка пытаясь подобрать решение какой-то проблемы (ЕМНИП я пытался реализовать полноценное логгирование для какой-то RPC-библиотеки). Но у меня так ничего и не получилось. Отчаявшись я полез в исходники, через какое-то время нашёл нужный вид параметра в настройках и методы которые потребовалось переопределить — и всё в итоге заработало как надо. Но я решил проверить — было ли какое-то руководство с упоминанием этого параметра и этого метода. Так вот нет, не было!
С того времени я особо на руководства не надеюсь. Да, какие-то базовые вещи типа @Service @Scope или @Autowired там описаны внятно и с версиями не меняются. Но что-то более или менее специфичное — напрочь отсутствует.
Здравствуйте, Gt_, Вы писали:
vsb>>Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.
Gt_>тут же шаравара. не будешь же ты писать скрипт который поставит жаву нужной тебе версии, поломав клиенту весь остальной софт. так что тут достаточно важно как запускать и чего делать если апгрейд скрипты базы выполнились с ошибкой.
Жаву не нужно ставить. Жава прекрасно работает из папки, никому не мешая. Просто распространяешь jre рядом со своей программой и всё. Есть и другие способы, к примеру jlink выдергивает из JRE нужные для твоей программы куски, но это уже сложней.
vsb>А какие альтернативы? Спринг бут это 90% жава "рынка". Библиотек, конечно, миллион, но по буту хотя бы есть ответы на все возможные вопросы.
Есть ответы на базовые и/или стандартные вопросы. Есть ответы на некоторые нестандартные вопросы. Но тут уже надо чтобы совпала версия спринга, по которой отвечали и той, которую используешь. А ответов на большинство нестандартных вопросов нет.
vsb>Не, если есть много времени и желания заниматься интересным, я бы даже на com.sun.net.httpserver-е сделал веб-сервер, работающий с базой через JDBC, с кучкой своих велосипедов и итоговым размером жарки в пару сотен килобайтов. Которую потом вполне реально можно в полноценный бинарник преобразовать размеров мегабайтов в 15. Но... Так не делают.
ИМХО спринг часто ошибочно воспринимают как такое самостоятельное универсальное решение. В реальности же помимо самых базовых вещей — (spring core кажется оно называется) — типа позднего связывания через Reflection (что, кстати, не так уж и сложно сделать и без спринга при желании) и т. п. — спринг просто объединяет кучу сторонних библиотек. Но что мешает использовать те же самые библиотеки без спринга? Т. е. не подтягивая кучу ненужных зависимостей через Spring Boot?
Например Srping data прикольная вещь для больших проектов. Но иногда она не нужна. А надо, допустим, исполнить запрос к БД хотя бы через тот же spring jdbc. Так вот spring boot отдельно spring jdbc не подтягивает, а только в комплекте с чем-то монструозным.
vsb>Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.
Можно, конечно. Но зависимости (а без них что-то писать это уж совсем хардкор) придётся класть рядом. Не всегда это удобно. ИМХО проще переупаковать все зависимости в один jar и его уже класть куда надо, контролировать его версию и запускать простейшей командой.
Иль>Я, помнится, мучился примерно день методом тыка пытаясь подобрать решение какой-то проблемы (ЕМНИП я пытался реализовать полноценное логгирование для какой-то RPC-библиотеки). Но у меня так ничего и не получилось. Отчаявшись я полез в исходники, через какое-то время нашёл нужный вид параметра в настройках и методы которые потребовалось переопределить — и всё в итоге заработало как надо. Но я решил проверить — было ли какое-то руководство с упоминанием этого параметра и этого метода. Так вот нет, не было!
сопрягать вещи бывает сложно, но это не стандартная задача и уж всяко сопрягать со спрингом много проще, чем с твоими поделками без спринга. понадобиться у него столь же абсурдная задача как нахлобучивать левые логерры, ну наймет спеца. а с велоспедом от Вани никто ни за какие деньги не будет подписываться помочь.
Иль>ИМХО спринг часто ошибочно воспринимают как такое самостоятельное универсальное решение. В реальности же помимо самых базовых вещей — (spring core кажется оно называется) — типа позднего связывания через Reflection (что, кстати, не так уж и сложно сделать и без спринга при желании) и т. п. — спринг просто объединяет кучу сторонних библиотек. Но что мешает использовать те же самые библиотеки без спринга? Т. е. не подтягивая кучу ненужных зависимостей через Spring Boot?
обычно мешает опыт. кто и за какие деньги будет разбираться, что ты там натворил рефлекшеном ?
Иль>Например Srping data прикольная вещь для больших проектов. Но иногда она не нужна. А надо, допустим, исполнить запрос к БД хотя бы через тот же spring jdbc. Так вот spring boot отдельно spring jdbc не подтягивает, а только в комплекте с чем-то монструозным.
расскажи нам чего такого тащит spring-boot-starter-jdbc ?
Коллеги, вы столько всего написали про Джаву, что респект вам и уважение. Но знаний это не добавило )))
Есть желающие в СПб провести небольшой ликбез по этому поводу, можно даже за деньги. Ну, или, за что-нибудь другое, если деньгами не комильфо?
Здравствуйте, sfsoft, Вы писали:
S>Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
Может на Go? Будет все ваше приложение — один большой статически слинкованный исполняемый файл. Соответственно, при обновлении он, один, и меняется целиком.
Здравствуйте, sharez, Вы писали:
Pzz>>Может на Go? Будет все ваше приложение — один большой статически слинкованный исполняемый файл. Соответственно, при обновлении он, один, и меняется целиком.
S>Так и на Java так же.
Но зато, хоть это и вкусовщина, Go — гораздо более приятный язык.
S>Коллеги, вы столько всего написали про Джаву, что респект вам и уважение. Но знаний это не добавило ))) S>Есть желающие в СПб провести небольшой ликбез по этому поводу, можно даже за деньги. Ну, или, за что-нибудь другое, если деньгами не комильфо?
с моей локации на территорию РФ наверно проблематично теперь заехать. лучше распиши в жава топике верхний уровень. верно ли я понял, что серверную часть клиент ставит, что нужны апдейты с базой данных, соответственно что-то изобрести с откатом апдейта. что за база на сервере сейчас ? если чего хитрое, чего в простых гайдах можно и не найти ?
Здравствуйте, vsb, Вы писали:
vsb>Какие библиотеки? Spring MVC/Spring WebFlux это вполне себе самостоятельная библиотека для роутинга. Или взять встраиваемый томкат. Я его пытался без спринга встраивать как-то раз. У меня ещё была стадия непринятия бута. Потом залез в исходники этого самого бута, оценил, сколько они там "клея" написали для того, чтобы этот самый встраиваемый томкат у них заработал, и это было одной из вех моего "принятия" бута.
У меня итог был другой. Я не принял бут, а понял, что "взять встраиваемый томкат" — плохая идея. Есть более вменяемые сервера, которые клеить не надо, две строчки кода и оно работает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gt_, Вы писали:
Gt_>лучше распиши в жава топике верхний уровень. верно ли я понял, что серверную часть клиент ставит, что нужны апдейты с базой данных, соответственно что-то изобрести с откатом апдейта. что за база на сервере сейчас ? если чего хитрое, чего в простых гайдах можно и не найти ?
Пока здесь напишу, CTRL+C, CTRL-V можно быстро сделать
СУБД: Firebird
Сервер приложений — это свой веб-сервер, отрабатывающий JSON-RPC запросы от клиентов. Естественно многопоточный, с пулом соединений с СУБД, есть собственная реализации очереди, для долгоиграющих запросов, а также генератор отчётов (а данном случае FastReport, довольно старый, именно он и "течёт" время от времени). Отчётов около 150 и их перевод на тот же birt — долгая затея... Всё это написано на Delphi (используется самая последняя версия, есть подписка на неё). Работает шустро, никто не жалуется.
По установке у пользователей. Чаще всего никаких админов у наших пользователей нет. Да и с компьютером многие из них на "вы". Поэтому работает это всё следующим образом: наш инсталлятор копирует нужные файлы, устанавливает сервис Firebird и создает необходимые ярлыки. Т.е. запустить инсталлятор и нажать несколько раз Далее юзеры могут в большинстве своём.
По обновлениям. При запуске клиентского ПО появляется плашка, что доступна новая версия. Пользователи на своем сервере (хотя обычно это такая же рабочая машина) открывают окно сервера приложений и там жмут кнопку Обновить. Программа скачивает с нашего сайта апдейт в архиве, распаковывает его, затем создает копию рабочей БД и накатывает скрипты обновления. Если всё прошло успешно у текущего exe меняем расширение на bak, а на его место записываем новый exe. И рестартим приложение. Если произошла ошибка во время накатывания скриптов (например, юзеры сунули руки в метаданные БД и что-то сломали), то программа удаляет нерабочую копию БД и восстанавливает рабочую копию из созданной ранее. Как-то вот так всё работает.
Update: сервер приложений сам регистрируется при запуске в Планировщике Windows, поэтому при перезапуске компа он сам запускается. Прав Администратора нигде не требуется, всё работает с правами обычного юзера.
Здравствуйте, Gt_, Вы писали:
Gt_>тогда вопрос кто и как его ставит ? клиент выходит сам админит
Это первоначальная установка программы. Выполняется один раз. Кнопкой "Далее". Firebird ставит наш инсталлятор. Но да, он требует повышения прав, иначе сервис не поставить и порт в брандмауэре не открыть.
Больше прав админа программа в работе не требует. В т.ч. и при установке обновлений. И не только прав, но и админ вообще не нужен.
Pzz>Но зато, хоть это и вкусовщина, Go — гораздо более приятный язык.
Один мой коллега начинал на ПХП, потом несколько лет работал на джаве (посматривая на котлин и скалу), потом пересел на Go, а потом... вернулся на джаву. Его цитата:
Gt_> сопрягать вещи бывает сложно, но это не стандартная задача и уж всяко сопрягать со спрингом много проще, чем с твоими поделками без спринга.
Ну как знать, как знать... Мои поделки — это зачастую несколько классов на 500 строк. И с той же функциональностью, для которой пользуют что-нибудь монструозное типа Hibernate. Хрен его знает что проще — разбираться в багах хибера (которых под нагрузкой вылазит овердофига) или что-то поправить в этих 500 строках. Всё ИМХО.
Gt_> понадобиться у него столь же абсурдная задача как нахлобучивать левые логерры,
Я когда корячил свой логгер (причём не в первый раз) всё не мог понять — как вообще народ работает со стандартным? Там (в стандартном) в логе видно только часть заголовков и первые пару сотен символов запроса или ответа. Ещё и неотформатированные при этом. И что с ними делать на бою — и о чём они могут сказать разработчику — я так и не понял. И таки запилил логгер, который разворачивает полный отформатированный JSON и запроса и ответа и не использует при этом буфер на весь ответ.
Gt_> а с велоспедом от Вани никто ни за какие деньги не будет подписываться помочь.
Ну я бы не стал говорить за всех. Тем более Спринг — не первый и не последний. До этого был EJB (свят-свят), знатоки которого говорили про спринг то же самое.
Gt_>обычно мешает опыт. кто и за какие деньги будет разбираться, что ты там натворил рефлекшеном ?
Я как-то беседовал со спецом, который ровно то же самое говорил про EJB. Типа нафиг ваши поделки типа спринга, когда есть испытанный временем промышленный стандарт, который делает всё то же самое и даже больше, есть куча серверов под него и куча профессиональных спецов? ... Блин, что за тоталитарность сознания? Спринг — не первый IoC и не последний. И джава не равна спрингу (и чему бы то ни было ещщё), как бы кому из подсевших на тот или иной фреймворк этого не хотелось.
Gt_>расскажи нам чего такого тащит spring-boot-starter-jdbc ?
Да фиг знает. Может быть вам стоит почитать прекрасный мануал, где это всё описано?
A чего не линуксовый .Net Core? (Который уже не Core, a просто .Net)? Деплой без админа, без внешних зависимостей, хочешь одним исполняемым бинарником, хочешь — бинарником с пачкой dll. Второй случай удобнее для инкрементальной синхронизации бинарей во время разработки: rsync в лапы, три секунды, залито.
Единая сборка под все платформы из одной точки, опять же. Если захочется не только Линукса.
Хотя... Тоже непростая штука, конечно. На первый взгляд всё отлично: ворочать данными с типизированным LINQ – одно удовольствие, нигде больше не видел настолько удобного и продуманного, лично для меня, инструментария. Однако, обуздать рантайм и держаться в рамках приличий по памяти — то ещё приключение.
Ну и да, экосистема эта ещё и весьма нишевая, на которую не так-то просто будет найти людей. Тоже недостаток. Сложилось впечатление, что подобных специалистов хватает, но кучкуются они в определенных местах. В ночлежке-общаге-на городском форуме их точно не найдешь. У безопасников он в ходу, например, в частности вроде как в Касперском на нем что-то очень монументально-бэкендовое пилили для безопасности пром.предприятий. У тех, кому нужен высокоуровневый язык, но позволяющий с лёгкостью спускаться на уровень дергания ОС, битов-байтов и железа — тоже популярен. С трудом, например, могу себе представить что-то подобное на Java: https://github.com/Ryujinx/Ryujinx. A вот для классического DB–бекенда его берут редко: слишком сложный и непривычный комбайн.
S>Не хочу в добрые объятия Microsoft.
Редиски они, конечно, еще те, но проект таки открытый, ECMA–стандартизированный, долгосрочный, не сбавляющий обороты. Вряд ли уже эту пасту получится запихнуть обратно в тюбик
Зависеть от какого-нибудь Жужеля, пачками сливающего проекты в унитаз, ИМХО гораздо хуже.
Здравствуйте, Иль, Вы писали:
Иль>Ну я бы не стал говорить за всех. Тем более Спринг — не первый и не последний. До этого был EJB (свят-свят), знатоки которого говорили про спринг то же самое.
Экосистема Спринга, и лежащий в его основе набор спецификаций JEE — это уникальное явление, труднозаменимый инструмент решения типовых задач энтерпрайза.
Здравствуйте, sfsoft, Вы писали:
S>Вводные: есть десктоп приложение на Дельфи, которое активно работает с СУБД через собственный сервер приложений. Также написанный на Дельфи. В общем классическая трехзвенка.
S>Проблема: в сервере приложений есть сторонние компоненты не особо хорошего качества, которые «текут» по памяти. Плюс юзеры хотят Линукс, хотя бы на сервере.
S>Потенциальное решение: переписать на Лазаре или на Java. Честно — Лазарь не нравится. Да и используется часть возможностей Дельфи, которые в нем недоступны (например, аннотации к private членам класса). Но у Джавы, если выбирать ее, есть проблемы с деплойментом, нужен админ.
S>Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
Либо смотрите в сторону blazor server(C#).
Обновлятор можете сами придумать(отдельным exe — скачал zip, остановил приложение, обновил).
Если гуй нужен настольный, тут тоже два варианта, java swing или java fx
под C# кроссплатформа avalonia ui, pltaform.uno (последний возможно в райдере поддерживается — можно под линуксом разрабатывать, иначе нужна визуал студия).
Здравствуйте, sfsoft, Вы писали:
S>Вводные: есть десктоп приложение на Дельфи, которое активно работает с СУБД через собственный сервер приложений. Также написанный на Дельфи. В общем классическая трехзвенка.
S>Проблема: в сервере приложений есть сторонние компоненты не особо хорошего качества, которые «текут» по памяти. Плюс юзеры хотят Линукс, хотя бы на сервере.
S>Потенциальное решение: переписать на Лазаре или на Java. Честно — Лазарь не нравится. Да и используется часть возможностей Дельфи, которые в нем недоступны (например, аннотации к private членам класса). Но у Джавы, если выбирать ее, есть проблемы с деплойментом, нужен админ.
S>Кто что скажет по этому поводу? Есть идеи как лучше сделать и что выбрать?
Да, у java есть одна фишка которой нет в .net
java web start
на сервер приложений деплоится настольное апп, оно может стартовать с различными аргументами(например источник данных, адрес сервера)
получается два слоя как в дельфи — java server beans — серверные компоненты и клиент.
только не используйте glassfish, я его помню по 2-3 версии. неприятное впечатление.
лучше что-то типа(надо погуглить) https://www.wildfly.org/
Здравствуйте, Gt_, Вы писали:
Gt_>расскажи нам чего такого тащит spring-boot-starter-jdbc ? Иль> Да фиг знает. Может быть вам стоит почитать прекрасный мануал, где это всё описано? Gt_>если не знаешь, чего влез то рассуждение по теме в которой абсолютный ноль ?
Именно с этого я и начал. Я несколько лет делал приложения на спринге — некоторые даже с нуля. В процессе этого писания ковырялся (был вынужден ковыряться!) в исходниках спринга (иначе никак не получалось решить некоторые вопросы), допиливал по ходу дела отдельные особо убогие вещи и т. д. и т. п. — но (!) я так и не нашёл, например, полного и внятного перечня тех же бутстартеров и их зависимостей.
По spring-boot-starter-jdbc есть только вот это:
Starter for using JDBC with the HikariCP connection pool
Всё. А чего он там такое тащит — выясняйте сами. Но для начала надо поизучать инструменты Java, которые покажут вам все зависимости этого вашего стартера ака библиотеки. И да, я, конечно, как и все джависты знаю способы это выяснить (хотя мне откровенно лениво в это лезть). А вот те люди, которые в джаве новички — сколько им потребуется усилий, чтобы вообще понять каким образом это делается?
Именно поэтому я знаю достаточно разработчиков, которые на старте помучавшись с джавой с неделю или две забрасывали её к чёртовой матери, придя к выводу что она бесконечно сложна. После чего уходили во что-то более удобное и пригодное для работы. А были и те, кто предварительно умудрялся написать такой неимоверный шлак, с задействованием всего самого модного на тот момент, что с это потом приходилось разгребать и переделывать действительно профессиональным людям, потратив кратно больше времени, чем на написание всего этого барахла "по шаблону". И это камень в огород всех тех, кто ... Gt_> ...этот спец то теперь, когда спринг стал промышленным стандартом, топит за него. как и все остальные, что еще вчера топили за EJB. о том и речь — достигнет критической массы, тогда и поговорим.
Дошло до того, что начали появляться видео вот с таким говорящим за себя названием . И, возможно, джава бы так и свалилась бы на уровень какого-нибудь Кобола, если бы кто-то в верхах не взялся за ум и не вступил в конкуренцию с тем же C# (в котором новые фичи появлялись раз в несколько месяцев), выпустив сначала Java5 с аннотациями, дженериками и нормальной стандартизованной библиотекой для работы с потоками, потом Java8 с потоками и т. д. и т. п. То есть в т. ч. начал включать в джаву всё то, из за чего народ и щемился куда-то в Скалу. Ох, помню сколько стенаний было поначалу в адрес этих нововведений от "профессионалов"... И именно после таковых нововведений в основной джаве Скале так и не удалось набрать критической массы.
То же самое происходило и в энтерпрайзе. В т. ч. и переход от EJB к Спрингу. Хотя энтерпрайз — болото ещё то. И болото он не только из за огромного объёма древнего как дерьмо мамонта но таки работающего кода, но и из за огромной массы суперконсервативных разработчиков, которые пихают этот энтерпрайз ака "промышленный стандарт" всюду, куда только можно видимо не отдавая себе отчёт, что для новичка это всё запредельно сложно и нафиг не нужно.
Иль>Именно с этого я и начал. Я несколько лет делал приложения на спринге — некоторые даже с нуля.
ну ладно уж сочинять. чувак который не знал про существование spring-boot-starter-jdbc и не в состоянии заглянуть в депенденси писал на java ?
я не верю. это же азы.
Иль>Всё. А чего он там такое тащит — выясняйте сами. Но для начала надо поизучать инструменты Java, которые покажут вам все зависимости этого вашего стартера ака библиотеки. И да, я, конечно, как и все джависты знаю способы это выяснить (хотя мне откровенно лениво в это лезть). А вот те люди, которые в джаве новички — сколько им потребуется усилий, чтобы вообще понять каким образом это делается?
ну да, "mvn dependency:tree" — это же пипец рокет саенс, лишь на втором уроке по жава дают.
что за IQ что бы это могло потребовать усилия ? в идеи в два клика плагин ставиться, что визуально депенданси отображает
Иль>Дошло до того, что начали появляться видео вот с таким говорящим за себя названием . И, возможно, джава бы так и свалилась бы на уровень какого-нибудь Кобола, если бы кто-то в верхах не взялся за ум и не вступил в конкуренцию с тем же C# (в котором новые фичи появлялись раз в несколько месяцев)
конкуренция с C# ? где ? я в соседней ветке уже спрашивал в пустоту, где кроме описания унылой бизнес логики применяется C# ? где проекты с управлением памятью и серьезной многопоточкой аля spark, kafka, casandra, hadoop ? ну или хотя бы просто крупные аля андройда ?
Иль> То есть в т. ч. начал включать в джаву всё то, из за чего народ и щемился куда-то в Скалу. Ох, помню сколько стенаний было поначалу в адрес этих нововведений от "профессионалов"...
я выше уже писал что многие годы идет обратный процесс, со скалы в жава.
Иль> которые пихают этот энтерпрайз ака "промышленный стандарт" всюду, куда только можно видимо не отдавая себе отчёт, что для новичка это всё запредельно сложно и нафиг не нужно.
мой опыт говорит об обратном. я вижу в какую задницу можно загнать кантору, где решили что стандартизация и scala/java сложно, сайентистам дали полную свободу лабать на питончике, кто во что горазд. опять подтвердилась поговорка — простота хуже воровства.
