Сохранение в бд и агрегата, и события в принципе понятно. А тема вычитки из бд и отправки в очередь, например, в Kafka, раскрыта не полностью. Как при отправке в Kafka гарантировать, что события по одному субъекту отправляются в том же порядке, что и были сохранены? И желательно не в один поток
Существует два вида JWT токенов: access token и refresh token, которые создаются и используются только в паре
Ещё существует третий тип - ‘id_token‘, который тоже в форме JWT. Это часть OpenID https://ru.wikipedia.org/wiki/OpenID. Представляет собой информацию о текущем пользователей, результат аутентификации. Для его получения чаще всего требуется ‘openid‘ scope.
‘refresh_token‘ не всегда присутствует в парк с ‘access_token‘. Поскольку он позволяет бесконечно обновлять ‘access_token‘, хранить его в браузере небезопасно. Лучше всего хранить его в веб сессии на бэкенде. Там же можно хранить и ‘access_token‘, кстати. А если бэкенда нет, то и ‘refresh_token‘ не нужен - в этом случае и secret клиента не нужен тоже, для таких открытых клиентов используют расширение PKCE.
Сам по себе picocli неплох, но для приложений побольше хочется иметь дополнительные возможности, такие как DI, получение конфигурации из внешних файлов равно как и из переменных окружения.
Хорошо в этом случае помогает Spring, но он добавляет дополнительные секунды на старте приложения.
В моём случае также несколько кластеров, но при этом настройки подключения ко всем хранятся в одном ~/.kube/config. Переключение: kubectl config use-context development. Упомянутый выше https://github.com/ahmetb/kubectx делает то же самое, просто меньше набирать текста. Алиасы (в моём случае - функции для PowerShell в файле profile.ps1) тоже решают эту же задачу.
А какую задачу решает несколько файлов kubeconfig?
Сходу вижу недостаток этого: большинство инструментов для работы с k8s считают, что файл ~/.kube/config - один, и не поддерживают коллекцию. А какие плюсы (иметь несколько файлов по сравнению с одним стандартным)?
А может ли кто поделиться опытом, как multi-stage build использовать для сборки NodeJS приложения?
Есть package.json, в котором есть dependencies и devDependencies. При npm install в node_modules устанавливаются и те, и другие. А в итоговой сборке devDependencies не нужны, и копирования целиком всего node_modules в итоговый образ хотелось бы избежать.
TF провайдер - всего лишь бинарник на golang, с которым tf CLI интегрируется по RPC. Pulumi, как я понимаю, делает аналогично - скачивает бинарник провайдера и интегрируется с ним.
Но в таком случае говорить, что pulumi использует tf не вполне корректно, ибо tf провайдер и сам tf - разные вещи.
3) не разглашать информацию, составляющую коммерческую тайну, обладателями которой являются работодатель и его контрагенты, после прекращения трудового договора в течение срока, предусмотренного соглашением между работником и работодателем, заключенным в период срока действия трудового договора, или в течение трех лет после прекращения трудового договора, если указанное соглашение не заключалось;
Стало так:
3) возместить причиненные работодателю убытки, если работник виновен в разглашении информации, составляющей коммерческую тайну и ставшей ему известной в связи с исполнением им трудовых обязанностей;
Из закона это убрали, и это хорошо. Но как быть, если в соглашении к трудовому договору это прописано?
Похоже, вы получили много негативного опыта в компаниях, где совсем не умели "готовить" scrum. Так не везде, уверяю вас! Мой опыт со scrum совсем другой, и я надеюсь нести этот положительный опыт дальше.
А если руководство захочет эксплуатировать сотрудников, оно найдёт способ это сделать с любой методикой, верно? Поэтому не ругайте методику, она не виновата ?
Если в компании практикуют оценки задач и требуют в них уложиться - там не то, что перерабатывать не нужно. Там вообще не нужно работать.
Такими словами можно весь scrum перечеркнуть и выкинуть. Там ведь как раз практикуется оценка задач командой исполнителей, набор задач на ближайший спринт с окм, чтобы выполнить их все в срок.
Таким образом, в перспективе нескольких спринтов выделяется предсказуемая производительность команды, и повышается предсказуемость работы. А предсказуемость намного важнее производительности.
Попробуйте https://github.com/obsidiandynamics/kafdrop - довольно шустрый и удобный инструмент.
Сохранение в бд и агрегата, и события в принципе понятно.
А тема вычитки из бд и отправки в очередь, например, в Kafka, раскрыта не полностью.
Как при отправке в Kafka гарантировать, что события по одному субъекту отправляются в том же порядке, что и были сохранены? И желательно не в один поток
https://github.com/gorilla
Не самый актуальный инструмент в 2023.
Ну и это не фреймворк, а набор библиотек. https://www.gorillatoolkit.org/
Конечно, только создан он для публичных
Ещё существует третий тип - ‘id_token‘, который тоже в форме JWT. Это часть OpenID https://ru.wikipedia.org/wiki/OpenID. Представляет собой информацию о текущем пользователей, результат аутентификации. Для его получения чаще всего требуется ‘openid‘ scope.
‘refresh_token‘ не всегда присутствует в парк с ‘access_token‘. Поскольку он позволяет бесконечно обновлять ‘access_token‘, хранить его в браузере небезопасно. Лучше всего хранить его в веб сессии на бэкенде. Там же можно хранить и ‘access_token‘, кстати.
А если бэкенда нет, то и ‘refresh_token‘ не нужен - в этом случае и secret клиента не нужен тоже, для таких открытых клиентов используют расширение PKCE.
Ещё один способ обойти ограничение — использовать дату вместо порядкового номера версии.
Например,
V20210103_0530__Change_description.sqlИнструмент хороший, спасибо.
Но почему python, а не бинарник? Это сильно ограничивает возможности использования, ведь не везде есть python.
Сам по себе picocli неплох, но для приложений побольше хочется иметь дополнительные возможности, такие как DI, получение конфигурации из внешних файлов равно как и из переменных окружения.
Хорошо в этом случае помогает Spring, но он добавляет дополнительные секунды на старте приложения.
А какую нагрузку создаёт дополнительный слой команды copy?
@Ryder95 Спасибо за статью!
В моём случае также несколько кластеров, но при этом настройки подключения ко всем хранятся в одном
~/.kube/config. Переключение:kubectl config use-context development.Упомянутый выше https://github.com/ahmetb/kubectx делает то же самое, просто меньше набирать текста. Алиасы (в моём случае - функции для PowerShell в файле
profile.ps1) тоже решают эту же задачу.А какую задачу решает несколько файлов kubeconfig?
Сходу вижу недостаток этого: большинство инструментов для работы с k8s считают, что файл
~/.kube/config- один, и не поддерживают коллекцию. А какие плюсы (иметь несколько файлов по сравнению с одним стандартным)?Я так понимаю, релиз новой версии докер образа в хабе и есть приглашение к обновлению.
А это уже давно автоматизировано
Спасибо, но как же быть с тестами?
Имею в виду, тестовые зависимости - они в devDependencies, нужны для прогона тестов, но не нужны в итоговой сборке.
Делать прогон тестов и сборку в разных фазах (stages)?
А может ли кто поделиться опытом, как multi-stage build использовать для сборки NodeJS приложения?
Есть package.json, в котором есть
dependenciesиdevDependencies. Приnpm installвnode_modulesустанавливаются и те, и другие. А в итоговой сборкеdevDependenciesне нужны, и копирования целиком всегоnode_modulesв итоговый образ хотелось бы избежать.Правильно ли я понял, что вы предлагаете внутри метода foo сделать проверку if w == nil?
TF провайдер - всего лишь бинарник на golang, с которым tf CLI интегрируется по RPC. Pulumi, как я понимаю, делает аналогично - скачивает бинарник провайдера и интегрируется с ним.
Но в таком случае говорить, что pulumi использует tf не вполне корректно, ибо tf провайдер и сам tf - разные вещи.
Я очень удивлён, что typealias позволяет передать переменную типа Weight в тип Brightness. Неочевидное решение.
Какой тогда смысл в typealias кроме нейминга?
На первый взгляд в golang аналогичные типы понятнее.
Большое спасибо!
Было так:
3) не разглашать информацию, составляющую коммерческую тайну, обладателями которой являются работодатель и его контрагенты, после прекращения трудового договора в течение срока, предусмотренного соглашением между работником и работодателем, заключенным в период срока действия трудового договора, или в течение трех лет после прекращения трудового договора, если указанное соглашение не заключалось;
Стало так:
3) возместить причиненные работодателю убытки, если работник виновен в разглашении информации, составляющей коммерческую тайну и ставшей ему известной в связи с исполнением им трудовых обязанностей;
Из закона это убрали, и это хорошо. Но как быть, если в соглашении к трудовому договору это прописано?
А можно об этом поподробнее, пожалуйста, со ссылками на первоисточник?
Похоже, вы получили много негативного опыта в компаниях, где совсем не умели "готовить" scrum. Так не везде, уверяю вас! Мой опыт со scrum совсем другой, и я надеюсь нести этот положительный опыт дальше.
А если руководство захочет эксплуатировать сотрудников, оно найдёт способ это сделать с любой методикой, верно? Поэтому не ругайте методику, она не виновата ?
Такими словами можно весь scrum перечеркнуть и выкинуть. Там ведь как раз практикуется оценка задач командой исполнителей, набор задач на ближайший спринт с окм, чтобы выполнить их все в срок.
Таким образом, в перспективе нескольких спринтов выделяется предсказуемая производительность команды, и повышается предсказуемость работы. А предсказуемость намного важнее производительности.