Главный вопрос — стоит ли ввязываться в это и побеждать подводные камни, или через N условных лет библиотеки намного лучше будут приспособлены к наличию реактивности в проекте? Речь не про изучение нового ради опыта, а практически — выиграл ли ваш проект?
Мы на нашем проекте рассматриваем такой путь: перед текущим сервлетным монолитом ставим spring cloud api gateway, затем по очереди вырезаем функциональные домены в отдельные микросервисы, попутно решая, кому их них быть реактивным, а кому опять сервлетным. Для внешних систем останемся тем же чёрным ящиком.
На Java, сперва на голой, через год переделал на Спринг )
если береш любой альт за один из этих активов, дальше только продать уже в другом , а этот другой только прогнать либо к первоначальному либо к тем что есть, т.е. получается только из 3х цепочка или я не прв, и может быть больше?
Не знаю, как сейчас на Binance, на BTC-E было порядка 45+ торговых пар и цепочки у меня были длиной от 3 до, кажется, 8 инструментов. Что-то типа BTC -> USD -> EUR -> LTC -> ETH -> RUB -> BTC. Хотя да, чаще всего профитные появлялись на длинах 4+/-1.
Ещё я фейлился на том, что у меня не было сумм на всех инструментах, и я проводил сделки последовательно :) Это лол, конечно, они часто застревали на середине, потому что цепочка отыквилась кем-то другим, и приходилось "эвакуировать" деньги с минимальными потерями. Кстати, тем же алгоритмом, только начало и конец разные были )
Ещё из прикольного было явно заметное влияние расстояние. Сервера биржи стояли, судя по всему, в Люксембурге, у меня дедик был в OVH, оттуда за сек делал 20+ итераций поиска, а из своей Сибири с локального ПК только 2-3 итерации. Юзал REST, не вебсокеты.
Как биржа несколько лет назад всех обманула и пропала, больше таким не занимался.
Делал такое же на ныне закрытой бирже BTC-E. Алгоритм простой -- берешь все возможные торговые пары, дальше брутфорс всех возможных цепочек переходов. Фильтрация по пригодности (out/in > 1), сортировка по прибыльности, и поехали.
Даже смог наторговать с 1500 руб до 4200, но потом биржа сказала Аривидерчи :)
Так ротация это ок. Работаю на галере скоро уже 5 лет. Сперва менялись проекты, сейчас текущий с лета 2019, новый, всё супер -- сами делаем и бек, и фронт, и деплоим. И всё равно иногда посещали мысли, что хочется поменять, хотя тут и тимлид, и любые технологии тащишь. И в случае с галерой варианты как раз интереснее, чем в проекте, потому что сильнее друг от друга отличаются.
Я тоже за ним с интересом наблюдаю, и всё жду, что будет достигнута какая-то точка. Например, выход Spring Boot 3. А после этой точки интересна судьба микронавта, кваркуса и т.п.
Да, согласен, но я вижу некоторую нотку, которая мне не нравится. Автор хотел показать в статье как можно больше возможных проблем и их решений, и я его полностью понимаю, но суммарный тон получился "Смотрите, как много проблем вас ждёт при апдейте", что может в какой-то мере добавить страху другим разработчикам и остановить их от попыток апдейта.
Я думаю автор сам понимает, но нарочно выбрал такой путь, чтобы получилась статья.
Ведь на самом деле 2/3 этой части по то, как обновить Спринг Бут большим прыжком, с 2.3 на 2.5. А почему не 2.6? Автор опять собирается копить костыли для будущей статьи "как всё тяжело и он устал". И этот реверанс с ломбоком как будто сделан специально, чтобы увеличить материал. Я не обвиняю, скорее всего именно таких читателей у него будет много и статья найдет отклик.
Обновление Спринга и обновление джавы -- могут быть и скорее всего должны быть отдельными задачами. На нашем проекте я всегда обновляю Спринг до нового релиза, решая проблемы по мере их появления, а не откладывая, поэтому все обновления джав (проект был начат на 12) -- в общем-то были банальны, вплоть до "заменить одну циферку".
Лучше добавить @EqualsAndHashCode.Include на единственное корректное для этого поле — id, и над каждой сущностью дополнительно @EqualsAndHashCode(onlyExplicitlyIncluded=true).
Я тоже не стесняюсь использовать Lombok в проектах и JPA-сущностях по полной, но должен предупредить автора о наличии в коде проблем. У вас @Data на сущностях с двусторонними взаимоотношениями — там по умолчанию есть @ToString и будет Stack Overflow при попытке вывести сущность в лог. Да и hashCode и equals тоже будут на него напарываться.
Стол достаточно широкий и глубокий, может быть это из-за "рыбьего глаза" не так заметно (все мониторы 24"). К тому же я не очень люблю на столе держать какие-то лишние вещи, например стакан и йогурт это временное, типичное содержимое: клавиатура, мышь, тетрадка с ручкой на ней, мои руки. Стикеры на подставках.
Мне не нравится, что системник на полу собирает сильно больше пыли, плюс об него можно начать биться ногами.
Мне нравится работать с тремя мониторами. Пусть даже они не очень современные и где-то цвета не вытягивают до конца. И рамки есть, но я не располагаю окна так, чтобы они делились между мониторами. Пожалуй, попробую развернуть хотя бы левый, он уже на кронштейне и крутится :)
Если у меня есть Java Spring проект с тестовыми зависимостями в Testcontainers, оно ваш докер обнаружит, или мне придется ему помогать?
Аспекты вполне написаны и работают в спрингбутовом проекте, который сейчас апнут на 17ю джаву. У вас какой-то более сложный кейс использования?
Письмо пришло с большой задержкой. Но хотя бы пришло, ага.
Прочитал, спасибо!
Главный вопрос — стоит ли ввязываться в это и побеждать подводные камни, или через N условных лет библиотеки намного лучше будут приспособлены к наличию реактивности в проекте? Речь не про изучение нового ради опыта, а практически — выиграл ли ваш проект?
Мы на нашем проекте рассматриваем такой путь: перед текущим сервлетным монолитом ставим spring cloud api gateway, затем по очереди вырезаем функциональные домены в отдельные микросервисы, попутно решая, кому их них быть реактивным, а кому опять сервлетным. Для внешних систем останемся тем же чёрным ящиком.
На Java, сперва на голой, через год переделал на Спринг )
Не знаю, как сейчас на Binance, на BTC-E было порядка 45+ торговых пар и цепочки у меня были длиной от 3 до, кажется, 8 инструментов. Что-то типа BTC -> USD -> EUR -> LTC -> ETH -> RUB -> BTC. Хотя да, чаще всего профитные появлялись на длинах 4+/-1.
Ещё я фейлился на том, что у меня не было сумм на всех инструментах, и я проводил сделки последовательно :) Это лол, конечно, они часто застревали на середине, потому что цепочка отыквилась кем-то другим, и приходилось "эвакуировать" деньги с минимальными потерями. Кстати, тем же алгоритмом, только начало и конец разные были )
Ещё из прикольного было явно заметное влияние расстояние. Сервера биржи стояли, судя по всему, в Люксембурге, у меня дедик был в OVH, оттуда за сек делал 20+ итераций поиска, а из своей Сибири с локального ПК только 2-3 итерации. Юзал REST, не вебсокеты.
Как биржа несколько лет назад всех обманула и пропала, больше таким не занимался.
Делал такое же на ныне закрытой бирже BTC-E. Алгоритм простой -- берешь все возможные торговые пары, дальше брутфорс всех возможных цепочек переходов. Фильтрация по пригодности (out/in > 1), сортировка по прибыльности, и поехали.
Даже смог наторговать с 1500 руб до 4200, но потом биржа сказала Аривидерчи :)
+1
Пользуюсь даже вне работы, например, вёл для себя план будущих работ по строительству дома :)
Так ротация это ок. Работаю на галере скоро уже 5 лет. Сперва менялись проекты, сейчас текущий с лета 2019, новый, всё супер -- сами делаем и бек, и фронт, и деплоим. И всё равно иногда посещали мысли, что хочется поменять, хотя тут и тимлид, и любые технологии тащишь. И в случае с галерой варианты как раз интереснее, чем в проекте, потому что сильнее друг от друга отличаются.
Я тоже за ним с интересом наблюдаю, и всё жду, что будет достигнута какая-то точка. Например, выход Spring Boot 3. А после этой точки интересна судьба микронавта, кваркуса и т.п.
Запуститься на более свежем LTS-рантайме (11, 17) — уже для многих подвиг.
Если ваш код + все зависимости работают нормально в таких условиях, то дальше поднять уровень своего исходного кода — уже вообще ни разу не проблема.
Да, согласен, но я вижу некоторую нотку, которая мне не нравится. Автор хотел показать в статье как можно больше возможных проблем и их решений, и я его полностью понимаю, но суммарный тон получился "Смотрите, как много проблем вас ждёт при апдейте", что может в какой-то мере добавить страху другим разработчикам и остановить их от попыток апдейта.
Я думаю автор сам понимает, но нарочно выбрал такой путь, чтобы получилась статья.
Ведь на самом деле 2/3 этой части по то, как обновить Спринг Бут большим прыжком, с 2.3 на 2.5. А почему не 2.6? Автор опять собирается копить костыли для будущей статьи "как всё тяжело и он устал". И этот реверанс с ломбоком как будто сделан специально, чтобы увеличить материал. Я не обвиняю, скорее всего именно таких читателей у него будет много и статья найдет отклик.
Обновление Спринга и обновление джавы -- могут быть и скорее всего должны быть отдельными задачами. На нашем проекте я всегда обновляю Спринг до нового релиза, решая проблемы по мере их появления, а не откладывая, поэтому все обновления джав (проект был начат на 12) -- в общем-то были банальны, вплоть до "заменить одну циферку".
Лучше добавить
@EqualsAndHashCode.Includeна единственное корректное для этого поле — id, и над каждой сущностью дополнительно@EqualsAndHashCode(onlyExplicitlyIncluded=true).Я тоже не стесняюсь использовать Lombok в проектах и JPA-сущностях по полной, но должен предупредить автора о наличии в коде проблем. У вас
@Dataна сущностях с двусторонними взаимоотношениями — там по умолчанию есть@ToStringи будет Stack Overflow при попытке вывести сущность в лог. Да и hashCode и equals тоже будут на него напарываться.Всё это описывает вот эта вполне себе "классическая" статья: https://thorben-janssen.com/lombok-hibernate-how-to-avoid-common-pitfalls/
Стол достаточно широкий и глубокий, может быть это из-за "рыбьего глаза" не так заметно (все мониторы 24"). К тому же я не очень люблю на столе держать какие-то лишние вещи, например стакан и йогурт это временное, типичное содержимое: клавиатура, мышь, тетрадка с ручкой на ней, мои руки. Стикеры на подставках.
Мне не нравится, что системник на полу собирает сильно больше пыли, плюс об него можно начать биться ногами.
Мне нравится работать с тремя мониторами. Пусть даже они не очень современные и где-то цвета не вытягивают до конца. И рамки есть, но я не располагаю окна так, чтобы они делились между мониторами. Пожалуй, попробую развернуть хотя бы левый, он уже на кронштейне и крутится :)
А вы генератор или какой-то свой другой код не планируете выкладывать в открытый доступ?
9/19 "за", так и знал, что я не плюсовик! :)
Мне кажется, с Java 8 стоило хотя бы начинать. Это старьё уже никому не интересно и сотни раз расписано.
У них слишком маленький рынок