Конечно, статье уже год, но добавлю свои 5 копеек, т.к. она гуглится и прочее:
Как сервер до сих пор использовать на практике не возможно, т.к. нет клиентов к Redis, Postgres и тем более к другим сетевым БД. Это печально, но факт. Вроде бы что-то и есть (https://github.com/madhead/kn-redis), но там в репозитарии всего 4 комита 4 года назад, т.е. все-таки самим нужно писать и поддерживать. А уж что проще для БД, чем текстовый протокол Redis.
Конкретно про Kotlin Native бенчмарки не искал, но уже давно были сравнения Java и С++. Да, JVM медленнее стартует, но работает быстро, иногда даже быстрее за счет своих оптимизаций в runtime.
`и для высокопроизводительных задач можно рассматривать сочетание Kotlin Native + Ktor + KStore для хранения данных` -- все-таки KStore для мобилок, локально хранить данные на сервере странно, т.к. непонятно что делать с бекапами, масштабированием и прочим.
В итоге, Kotlin Native перспективен для консольных утилит (быстро стартует, нет внешних зависимостей -- примерно как у golang), для слабых устройств (быстро стартует, малый размер, ест мало памяти, легко поставлять(один файл)), для сценариев быстрого масштабирования (типа облачных лямбда-функций), для поставок коммерческих решений (как вариант обфускации кода). Насколько эти перспективы реализованы пока что непонятно: полазил по их сайту, не понял, видимо, нужно отдельно искать, а они, в основном, про мобилки.
Интересно сравнение Kotlin Native с JVM Native -- может Kotlin Native на серверах сейчас вообще не нужен, если он будет хуже (тем более с учетом скудности библиотек)
Тем кросскомпиляции не раскрыта, поэтому скорее ее нет, что хуже, чем golang.
Что имеется в виду? Я же правильно понимаю, что данных для обучения нет, а есть уже готовые "бинарники" модели и код, чтобы их запускать?
Может быть лучше было бы, если бы вообще не выкладывали -- т.к. такая бесплатная версия убивает (не дает появится) действительно открытой версии.
Gemma поставляется с инструментами "ответственного ИИ". Это важно, т.к. открытые модели сложнее контролировать. Инструменты позволяют создавать правила и отлаживать модель.
Непонятно почему открытые модели сложнее контролировать. Потому что код этого контроля обычно не пишут (не открывают)? Или?
Вывод, к сожалению, пока что другой: современный Kubernetes (у всех провайдеров) все еще предоставляется не как чистая услуга, а клиенту нужно иметь своих devops, которые в нем разбираются.
В этом случае, уже часто непонятно зачем брать услугу K8s, а не виртуалки, если все равно есть инженеры которые это поддерживают. Или не так?
Почему сразу изоляция? Нужно продавать не только в России.
Опять же, это постепенное движение. Его нужно делать, а не обсирать любой шаг...
Объясните мне тупому почему сборка серверов должна быть иностранной? А это неплохой кусок маржи сам по себе. На его базе можно и дальше локализовывать производство.
Нет, это как с экологичностью: ее можно увеличить, но 100% вряд ли будет. Все-таки мир уже давно глобален, что-то, но придется докупать у союзных стран.
Замена вендоров готовых систем (сервера, схд, мфу) -- шаг вперед, но, понятно, не полный. Далее нужно переходить и на собственную компонентную базу.
При этом банк готов поддержать подобные решения, если они будут подходить под заявленные требования.
А вот эта фраза действительно несколько огорчает. Основное заявленное требование хотя бы для критичных систем должно быть российское производство, а остальное уже под это подстраивается, а не наоборот... Так можно реально доиграться
Надеюсь, хотя бы на наш софт полностью перейдут -- уже хоть какая-то возможность бороться с рисками и проблемами. И не к 2030 году...
Что работает? Да, я написал, что в маке Ранчер и эту новую штуку можно использовать через консоль. Как поставить докер-совместимое окружение (чтобы была команда docker), но без лицензионного ограничения docker desktop через консоль без gui приложения в маке не знаю. Знаете — поделитесь.
В целом, я поддерживаю стремление к простоте. И от JEE на Rails переходил, и на Golang программировал, и на Python FastAPI.
При этом у меня немного другой приоритет: не простота всего приложения в целом, а именно кода, который читает и пишет программист. Без относительно того сколько кода написано в библиотеках и фреймворках. Важно, чтобы минимальное время тратилось на технологический код и максимальное на бизнес-код.
С этой точки зрения представленный шаблон во многом закрывает технологические аспекты и направляет как писать бизнес-код. Как по мне, получается весьма хорошо.
При этом, вполне возможно, есть подходы и лучше. Чтобы собрать обратную связь это и публиковалось. Например, тот же Ktor предлагается несколькими людьми. Но у меня с ним опыта нет, а замена Spring -- это практически весь шаблон переделать. Если мы при этом ничего не потеряем (читаемость и кол-во кода приложения и всю дополнительную функциональность, которая уже заложена в шаблоне), а только приобретем более быстрый старт и меньший размер на диске и в памяти -- я двумя руками "За". Но хотелось бы такое увидеть не от неофита в Ktor фреймворке и его окружении (меня), а от человека, который это уже использует года, т.к. наверняка есть моменты в конфигурации и лучших практиках, которые можно показать в шаблоне. Если же это окажется примерно то же самое или хуже, то переходить нет смысла.
В итоге, в любом случае нужно будет как-нибудь посмотреть что-то подобное на Ktor, чтобы понять оно лучше или хуже.
Не, вы не так поняли. Docker Desktop стал платным (с условиями, но все же). Поэтому народ, кого это затронуло, начал массово ставить Rancher Desktop. RH посмотрел на это и выпустил свой.
Все, что вы перечислили, это не основной функционал (который для пользователей именно чистый Docker в большинстве случаев), а что-то вроде триала, чтобы больше людей познакомились с RH версией Кубернетеса. Та же схема, что и в Rancher Desktop.
Вводя понятие основной проекции переизобретается велосипед снапшот - это построенный по первым N ивентам слепок агрегата. Тогда если в команде нужен агрегат, он строится не по всем ивентам, а начиная с N+1. Если снапшот обновлять после каждого нового ивента, то получится ровно то, что в статье называется основной проекцией.
Все-таки снапшот -- это обычно тоже событие. Соответственно, он сокращает количество проигрываемых событий при построении агрегата. Это же проекция, но с необходимой полнотой данных, чтобы не нужно было отдельно строить агрегат, и с единой транзакцией с событием, которая исключает eventual consistency.
Кстати снапшот никак не влияет на eventual consistency. Не важно, строится в команде агрегат по всём ивентам с первого или с N+1, всё равно между добавлением ивентов в ивент стор и обновлением проекций для чтения будет лаг.
Да, классический снапшот никак не влияет, но основная проекция -- не снапшот (в классическом смысле). Идет 1 транзакция на БД с созданием события и обновлением основной ("встроенная" даже более точное определение) проекции, так что это уже никак не отличается по консистентности от обычных (не event sourcing) систем.
Опять же, я не считаю это каким-то своим изобретением -- нечто подобное наверняка есть и у других. Моя роль скорее подсветить этот вариант и показать пример реализации.
Скрам -- это про отсутствие линейного менеджера и групповую динамику (Скрам-мастер -- не менеджер).
Если есть менеджер, то это уже не скрам (скрам -- организационный фреймворк вокруг расщепления руководителя проекта на скрам-мастера и владельца продукта).
Перечисленные причины выбора скрам странные, они все как раз больше за Канбан.
Да, Канбан часто лучше, т.к. мало кто готов к Скрам-мастерам.
Короче тут не про то как выстроить экосистему ориентированную на kotlin и его специфику
Да, не было цели взять Kotlin + всё, что только для него написано, и посмотреть как это будет. Выбор компонентов кратко описан.
От спрингбута уже плохеет если честно. 7 лет назад сменили Java на kotlin. И через год весь этот спринг, и его Бут из стека ушли в небытие. Для экосистемы kotlin полно микро фреймворков и di. Мы используем. Ktor и kodein. ... а скорее как впихнуть kotlin в этот жутковатый и полный мемов про оверинжениринг шаблон со спрингами и прочим
Я не пользовался ни Ktor, ни kodein. Возможно, из-за привычки не вижу проблем со спрингом и прочим. Можете раскрыть свою мысль чем стек Ktor и kodein лучше?
В идеале, конечно, форкнуть репозитарий и показать как это будет. Тогда можно будет "пощупать", понять плюсы/минусы. Мы же все-таки про код, а не теории. Конечно, я понимаю, что это наверняка займет несколько дней, поэтому вероятность не очень большая.
Как железо можно присмотреться к Orange Pi R1 Plus LTS: новый (легко купить без поисков б/у) безвентиляторный с корпусом стоит 2.9тр с Али. Нужно только блок питания добавить (можно взять от старого телефона, если там разъем usb, т.к. мало требуется). Он слабее, но и ест меньше. Мощности на статику должно хватить.
Бесперебойник вряд ли нужен, но это у кого как.
Но на практике VPS 200р/мес именно для хостинга сайта выглядит лучше (туда и кулифай можно поставить).
Дома лучше хостить что-то вместо SaaS-решений. Например, Nextcloud или Gitea. При это уже что-то на x86 лучше: мощнее и точно ПО запустится. У меня, например, не запустился офисный редактор под ARM в Nextcloud.
Генерация -- это хорошо, но еще лучше без нее (как в openapi), т.к. ее либо руками нужно запускать, либо она отнимает время при каждой сборке. Плюс, сложности при внесении изменений. Например, какое-то вычислимое поле в DTO сделать или что-то такое.
Из дополнительных бонусов - можно все согласовать с фронтендерами ДО того, как написал GraphQL сервис. Потому что разработка начинается с написания схемы.
Вот тут я чувствую свое бессилие в объяснении позиции. Этот аргумент часто употребляется, но, как по мне, это не отличается.
Да, начинается со схемы. Но где ее писать? Я предпочитаю в IDE в виде Котлин-кода. Писать код и получить из него схему не дольше. Тут я говорю про OpenAPI и GraphQL в Quarkus, в Spring ситуация с GraphQL другая, т.к. подход не поддерживается. Так же этом может быть точнее, особенно если какие-то классы с данными уже есть.
Далее можно обсуждать спеку в формате GraphQL. Обычно ее приношу я. Изменения после совещания легко отследить и внести -- обычно никаких проблем на данном этапе нет.
В принципе, если бы мне какие-нибудь бизнес-аналитики приносили GraphQL-спеку, то да, я бы генерировал из нее код. Разово или на постоянной основе зависит от того обновляли бы они его с компьютерной (а не человеческой) точностью или нет.
Конечно, статье уже год, но добавлю свои 5 копеек, т.к. она гуглится и прочее:
Как сервер до сих пор использовать на практике не возможно, т.к. нет клиентов к Redis, Postgres и тем более к другим сетевым БД. Это печально, но факт. Вроде бы что-то и есть (https://github.com/madhead/kn-redis), но там в репозитарии всего 4 комита 4 года назад, т.е. все-таки самим нужно писать и поддерживать. А уж что проще для БД, чем текстовый протокол Redis.
Конкретно про Kotlin Native бенчмарки не искал, но уже давно были сравнения Java и С++. Да, JVM медленнее стартует, но работает быстро, иногда даже быстрее за счет своих оптимизаций в runtime.
`и для высокопроизводительных задач можно рассматривать сочетание Kotlin Native + Ktor + KStore для хранения данных` -- все-таки KStore для мобилок, локально хранить данные на сервере странно, т.к. непонятно что делать с бекапами, масштабированием и прочим.
В итоге, Kotlin Native перспективен для консольных утилит (быстро стартует, нет внешних зависимостей -- примерно как у golang), для слабых устройств (быстро стартует, малый размер, ест мало памяти, легко поставлять(один файл)), для сценариев быстрого масштабирования (типа облачных лямбда-функций), для поставок коммерческих решений (как вариант обфускации кода). Насколько эти перспективы реализованы пока что непонятно: полазил по их сайту, не понял, видимо, нужно отдельно искать, а они, в основном, про мобилки.
Интересно сравнение Kotlin Native с JVM Native -- может Kotlin Native на серверах сейчас вообще не нужен, если он будет хуже (тем более с учетом скудности библиотек)
Тем кросскомпиляции не раскрыта, поэтому скорее ее нет, что хуже, чем golang.
Что имеется в виду? Я же правильно понимаю, что данных для обучения нет, а есть уже готовые "бинарники" модели и код, чтобы их запускать?
Может быть лучше было бы, если бы вообще не выкладывали -- т.к. такая бесплатная версия убивает (не дает появится) действительно открытой версии.
Непонятно почему открытые модели сложнее контролировать. Потому что код этого контроля обычно не пишут (не открывают)? Или?
Вывод, к сожалению, пока что другой: современный Kubernetes (у всех провайдеров) все еще предоставляется не как чистая услуга, а клиенту нужно иметь своих devops, которые в нем разбираются.
В этом случае, уже часто непонятно зачем брать услугу K8s, а не виртуалки, если все равно есть инженеры которые это поддерживают. Или не так?
Почему сразу изоляция? Нужно продавать не только в России.
Опять же, это постепенное движение. Его нужно делать, а не обсирать любой шаг...
Объясните мне тупому почему сборка серверов должна быть иностранной? А это неплохой кусок маржи сам по себе. На его базе можно и дальше локализовывать производство.
Т.е. предлагается лечь в гроб и ничего не делать? В чем конструктив в текущей ситуации, а не про прошлое?
Согласен, что все далеко не хорошо, но это не значит, что любые шаги в правильном направлении нужно объявлять попилом бюджетов.
Надо все закупать. И то, и то.
И радоваться, когда есть прогресс.
При этом тоже огорчаюсь, что он слишком медленный, но я просто сторонний наблюдатель.
Не производится. И мне это тоже не нравится -- об этом мой абзац про огорчает.
При этом закупка серверов российской сборки увеличивает локализацию. Это не что-то итоговое, но шаг в правильном направлении.
да, главное, что российский. Падение раз в час можно купировать и на программном уровне. Полное отключение работы (и внезапное) гораздо хуже.
Нет, это как с экологичностью: ее можно увеличить, но 100% вряд ли будет. Все-таки мир уже давно глобален, что-то, но придется докупать у союзных стран.
Замена вендоров готовых систем (сервера, схд, мфу) -- шаг вперед, но, понятно, не полный. Далее нужно переходить и на собственную компонентную базу.
А вот эта фраза действительно несколько огорчает. Основное заявленное требование хотя бы для критичных систем должно быть российское производство, а остальное уже под это подстраивается, а не наоборот... Так можно реально доиграться
Надеюсь, хотя бы на наш софт полностью перейдут -- уже хоть какая-то возможность бороться с рисками и проблемами. И не к 2030 году...
Так или иначе пропагандировать бесплатно работать неделю неправильно. Даже если люди от отчаяния на это соглашаются.
Что работает? Да, я написал, что в маке Ранчер и эту новую штуку можно использовать через консоль. Как поставить докер-совместимое окружение (чтобы была команда docker), но без лицензионного ограничения docker desktop через консоль без gui приложения в маке не знаю. Знаете — поделитесь.
В целом, я поддерживаю стремление к простоте. И от JEE на Rails переходил, и на Golang программировал, и на Python FastAPI.
При этом у меня немного другой приоритет: не простота всего приложения в целом, а именно кода, который читает и пишет программист. Без относительно того сколько кода написано в библиотеках и фреймворках. Важно, чтобы минимальное время тратилось на технологический код и максимальное на бизнес-код.
С этой точки зрения представленный шаблон во многом закрывает технологические аспекты и направляет как писать бизнес-код. Как по мне, получается весьма хорошо.
При этом, вполне возможно, есть подходы и лучше. Чтобы собрать обратную связь это и публиковалось. Например, тот же Ktor предлагается несколькими людьми. Но у меня с ним опыта нет, а замена Spring -- это практически весь шаблон переделать. Если мы при этом ничего не потеряем (читаемость и кол-во кода приложения и всю дополнительную функциональность, которая уже заложена в шаблоне), а только приобретем более быстрый старт и меньший размер на диске и в памяти -- я двумя руками "За". Но хотелось бы такое увидеть не от неофита в Ktor фреймворке и его окружении (меня), а от человека, который это уже использует года, т.к. наверняка есть моменты в конфигурации и лучших практиках, которые можно показать в шаблоне. Если же это окажется примерно то же самое или хуже, то переходить нет смысла.
В итоге, в любом случае нужно будет как-нибудь посмотреть что-то подобное на Ktor, чтобы понять оно лучше или хуже.
Не, вы не так поняли. Docker Desktop стал платным (с условиями, но все же). Поэтому народ, кого это затронуло, начал массово ставить Rancher Desktop. RH посмотрел на это и выпустил свой.
Все, что вы перечислили, это не основной функционал (который для пользователей именно чистый Docker в большинстве случаев), а что-то вроде триала, чтобы больше людей познакомились с RH версией Кубернетеса. Та же схема, что и в Rancher Desktop.
Это прежде всего для macOS и Windows: чтобы там локально запускать Docker (в том числе и через консоль). Для Linux да, особо не нужно.
Спасибо за комментарий)
Все-таки снапшот -- это обычно тоже событие. Соответственно, он сокращает количество проигрываемых событий при построении агрегата. Это же проекция, но с необходимой полнотой данных, чтобы не нужно было отдельно строить агрегат, и с единой транзакцией с событием, которая исключает eventual consistency.
Да, классический снапшот никак не влияет, но основная проекция -- не снапшот (в классическом смысле). Идет 1 транзакция на БД с созданием события и обновлением основной ("встроенная" даже более точное определение) проекции, так что это уже никак не отличается по консистентности от обычных (не event sourcing) систем.
Опять же, я не считаю это каким-то своим изобретением -- нечто подобное наверняка есть и у других. Моя роль скорее подсветить этот вариант и показать пример реализации.
Скрам -- это про отсутствие линейного менеджера и групповую динамику (Скрам-мастер -- не менеджер).
Если есть менеджер, то это уже не скрам (скрам -- организационный фреймворк вокруг расщепления руководителя проекта на скрам-мастера и владельца продукта).
Перечисленные причины выбора скрам странные, они все как раз больше за Канбан.
Да, Канбан часто лучше, т.к. мало кто готов к Скрам-мастерам.
Спасибо за комментарий и что поделились опытом).
Да, не было цели взять Kotlin + всё, что только для него написано, и посмотреть как это будет. Выбор компонентов кратко описан.
Я не пользовался ни Ktor, ни kodein. Возможно, из-за привычки не вижу проблем со спрингом и прочим. Можете раскрыть свою мысль чем стек Ktor и kodein лучше?
В идеале, конечно, форкнуть репозитарий и показать как это будет. Тогда можно будет "пощупать", понять плюсы/минусы. Мы же все-таки про код, а не теории. Конечно, я понимаю, что это наверняка займет несколько дней, поэтому вероятность не очень большая.
Спасибо за найденную статью)
Как железо можно присмотреться к Orange Pi R1 Plus LTS: новый (легко купить без поисков б/у) безвентиляторный с корпусом стоит 2.9тр с Али. Нужно только блок питания добавить (можно взять от старого телефона, если там разъем usb, т.к. мало требуется). Он слабее, но и ест меньше. Мощности на статику должно хватить.
Бесперебойник вряд ли нужен, но это у кого как.
Но на практике VPS 200р/мес именно для хостинга сайта выглядит лучше (туда и кулифай можно поставить).
Дома лучше хостить что-то вместо SaaS-решений. Например, Nextcloud или Gitea. При это уже что-то на x86 лучше: мощнее и точно ПО запустится. У меня, например, не запустился офисный редактор под ARM в Nextcloud.
Генерация -- это хорошо, но еще лучше без нее (как в openapi), т.к. ее либо руками нужно запускать, либо она отнимает время при каждой сборке. Плюс, сложности при внесении изменений. Например, какое-то вычислимое поле в DTO сделать или что-то такое.
Вот тут я чувствую свое бессилие в объяснении позиции. Этот аргумент часто употребляется, но, как по мне, это не отличается.
Да, начинается со схемы. Но где ее писать? Я предпочитаю в IDE в виде Котлин-кода. Писать код и получить из него схему не дольше. Тут я говорю про OpenAPI и GraphQL в Quarkus, в Spring ситуация с GraphQL другая, т.к. подход не поддерживается. Так же этом может быть точнее, особенно если какие-то классы с данными уже есть.
Далее можно обсуждать спеку в формате GraphQL. Обычно ее приношу я. Изменения после совещания легко отследить и внести -- обычно никаких проблем на данном этапе нет.
В принципе, если бы мне какие-нибудь бизнес-аналитики приносили GraphQL-спеку, то да, я бы генерировал из нее код. Разово или на постоянной основе зависит от того обновляли бы они его с компьютерной (а не человеческой) точностью или нет.
да, нужно попробовать kotest, может будет лучше