Если вопрос именно в тестах - то лучше подготовить образ с инструментарием нужным и через docker run запускать тесты, подсовывая сорцы и кеши через volume.
В принципе, подобный подход применим и для сборки образов - через docker run собираются артефакты и потом отдельно пакуются в образ.
Если связность - это только о внутренней структуре модуля, а между модулями/сервисами это называется связанность (зацепление) - то и связанность от перехода на очереди не становится ниже. Просто потому, что форматы данных и способы их доставки согласуются между сервисами в любом случае (и объем согласований не меняется).
То, что граф связей упростился - форматы передаваемых данных не становятся проще, необходимых знаний о соседних системах не становится меньше. Разве что адреса соседних систем можно не знать, но имя очереди и адрес сервера очереди все равно знать придется, так что объем знаний остается прежний.
Я исхожу из того, что автор говорит именно про связность, а не про связанность. Связанность - согласен, уменьшается, потому что остается, в большинстве случаев, только сервис и сервер очереди.
И основной мой посыл был в том, что от перехода на очереди именно связность не поменяется. Сервисы как оперировали согласованными форматами данных в согласованных местах, так и продолжили оперировать согласованными форматами данных в согласованных местах.
P.S. Бизнес требования могут быть по разному реализованы, так что само по себе бизнес-требование может ничего и не увеличивает, а вот его реализация - вполне себе.
Но вот момент, когда этот модуль 2 проворачивается очень быстро - меня напрягает больше. Это или полностью ненужное движение, или проворот выполняется бесконечно быстро, или шар подклинивает в этот момент на время проворота. На сколько могу судить, это именно что лишнее движение...
Там есть чем цеплять - со стороны шара в этот момент просто продольные зацепы, которые шар и проворачивают (а-ля отверткой). "Соска" у шестерни только с одной стороны.
Да, меньше связность - это про "один модуль стал о другом знать меньше". Это я и называю "упростился протокол взаимодействия модулей".
Но сам процесс "стал знать меньше" - это не потому, что на событийную модель перешли, а потому что рефакторинг/переделки были, которые и уменьшили связность модулей, чтобы взаимодействие лучше на событийную модель "ложилось".
Но такие переделки вполне применимы и при REST API (и любом другом API). И дадут ничуть не худшее уменьшение связности.
Я про это и говорю. Изменился протокол взаимодействия, он стал проще. Проще протокол - меньше связность.
Очередь тут вторична. С тем же успехом можно без очереди жить. Сделать REST API которое все входящие ордера просто обрабатывает.
А если имеется сервис с этим же API, который все входящие ордера из API в очередь добавляет, а из очереди уже другой сервис их обрабатывает?
Для внешнего наблюдателя эти 2 сервиса (что с обработкой сразу, что с очередью) будут полностью идентичны. И связность они будут давать полностью идентичную. Просто потому, что применение очереди на связность не влияет - это внутренний нюанс реализации сервиса и/или связи между сервисами.
А чем это отличается от единой точки входа - API компонента B? Формат данных согласовывается одинаково, очереди/пути для отправки данных - аналогично, подлежат согласованию между сервисами. Связность остается той же.
Или мы рассматриваем ситуацию, что у компонента B свое API для A и С, но при переходе на событийную модель упрощается протокол взаимодейсвия и появляется общая очередь? Тогда уменьшение связности - заслуга рефакторинга под более простой протокол, а не перехода на событийную модель.
Я могу согласиться, что в событийной модели связность может быть слабее. Но это только потому, что протокол взаимодействия, как правило, значительно проще. В событийном модели организация сложного протокола взаимодействия требует значительно больших усилий от разработчика (в отличии от REST или RPC подходов).
Но сама по себе событийная модель не уменьшает связность.
Такой подход позволяет нам сильно уменьшить связность нашей системы и упростить её поддержку и расширяемость.
Связность не меняется.
Что в REST надо знать, в какое API и в каком виде данные отправляются, что в событийной модели надо знать, в какую очередь и в каком виде данные отправляются. От изменения способа доставки данных связность не поменяется.
В Event-driven добавляется 3й элемент - очередь сообщений, что наоборот, усложняет схему работы (потому как появляется дополнительная точка отказа).
В четверг шансы на подобный отдых намного меньше. Тем более меньше ситуаций "Я уже выехал из города на все выходные. Связи нет и не будет.".
Даже если подобное случилось, разработчик будет на связи уже в пятницу (через считанные часы), а не через два дня, в понедельник.
Так что правило "не лить обновления в пятницу" достаточно популярно. Как и "не обновляться перед длинными выходными" по тем же причинам.
Хотя в данном случае оно бы не помогло, с этим я тоже полностью согласен. Хотя бы потому, что в данном случае, пятница вечер - это пик нагрузки. И не говоря уже о том, что с обновлением инцидент не связан.
Битые ссылки - это не nil-указатели, а указатель на область памяти, где раньше была эта переменная, а потом ее собрал сборщик мусора и пометил область свободной для заполнения снова... В итоге к моменту чтения, по старому адресу уже совсем другие данные могут оказаться...
Проблема в том, что возникает плавающая бага, которую очень сложно диагностировать (в любом языке)...
Ладно утечки... Лично меня больше напрягают битые ссылки, которые выявляются только при запуске со специальными флагами... А там и гонки - что быстрее? Переменная прочтется или перезапишется?
Следует учитывать, что code-server - это не VS Code. Главным образом в плане расширений. Code-server использует свой репозиторий расширений и там далеко не все, что есть для VS Code. Кроме того, часть расширений не работает должным образом - в частности местами не завелся дебаг.
Поэтому для меня гораздо удобнее VS Code с плагинами удаленной разработки. Впрочем, я и для локальной разработки подобной схемой пользуюсь - разрабатываю в контейнере ).
Причем тут есть 2 пути: делать для каждого проекта свой контейнер (VS Code отлично такой путь поддерживает) или вручную запускать контейнер с доступом по SSH и к нему подключаться (я в итоге остановился на такой схеме).
Если задача была в получении опыта по работе с вендинговыми автоматами - то молодцы.
Однако судя по описанию:
Конечно, мы понимали, что наша схема выдачи неидеальна, но такой подход должен был помочь вести учет техники. Однако коллеги забывали отмечать позиции или вносили в Jira неправильные данные — в таких условиях вести статистику было практически нереально.
Задача была в улучшении сбора статистики... Ну что же, между "никакой автоматизации" и "полная автоматизация" очень большая пропасть... И на мой взгляд, в данном случае достаточно было очень сильно упростить заполнение таски в Jira (или в другом средстве сбора статистики) - просто упростив заполнение таски. Например, штрих-код на пропуске + штрих-код на упаковке товара (или коробке с определенным типом товара) и небольшой сервис... Дополнительно - комп со сканером (тот же Raspberry Pi) или даже смартфон с камерой... Сосканировал бейджик + сосканировал товар - и пошел по своим делам. А все остальное сделает сервис...
Полная автоматизация нужна когда вообще нет доверия между участниками схемы... А когда доверие есть - достаточно сделать удобно.
То, что отношений нет на уровне СУБД - не значит, что отношения нельзя организовать на уровне ключей или хранимых объектов.
Да, придется самостоятельно следить за целостностью и согласованностью данных. Но это вполне реализуемо и достижимо.
Впрочем, полноценно заменить реляционную СУБД все равно не удастся скорее всего - главным образом потому, что SQL позволяет очень гибко данные получать и обрабатывать. А с KV-базами надо заранее планировать "где кто и как" будет данные получать и обрабатывать.
По крайней мере в git история правится так или иначе ) Удобно/неудобно - другой вопрос.
Hg же в принципе не дает править историю (максимум - локально, до push). Однажды пробовали и на сервере подправить... По факту всем пришлось заново клонировать репозиторий )
Я бы назвал это главным различием git vs hg. И поэтому для публичных проектов git лучше, на мой взгляд. А как итог - git в принципе вышел вперед...
Как Василий ускорял сборку тестов
Если вопрос именно в тестах - то лучше подготовить образ с инструментарием нужным и через
docker runзапускать тесты, подсовывая сорцы и кеши через volume.В принципе, подобный подход применим и для сборки образов - через
docker runсобираются артефакты и потом отдельно пакуются в образ.GitHub с 8 января 2024 года прекратит поддержку системы управления версиями Subversion
Есть форк GitLab-a переделанный под hg. Не знаю, правда, как у него дела сейчас идут...
В очередь, ...! Как управлять состоянием системы через события
Если связность - это только о внутренней структуре модуля, а между модулями/сервисами это называется связанность (зацепление) - то и связанность от перехода на очереди не становится ниже.
Просто потому, что форматы данных и способы их доставки согласуются между сервисами в любом случае (и объем согласований не меняется).
То, что граф связей упростился - форматы передаваемых данных не становятся проще, необходимых знаний о соседних системах не становится меньше.
Разве что адреса соседних систем можно не знать, но имя очереди и адрес сервера очереди все равно знать придется, так что объем знаний остается прежний.
В очередь, ...! Как управлять состоянием системы через события
Прошу прощения, невнимательно прочитал.
Я говорю про связность, которую и упоминает автор, а не про связанность.
В очередь, ...! Как управлять состоянием системы через события
Я исхожу из того, что автор говорит именно про связность, а не про связанность.
Связанность - согласен, уменьшается, потому что остается, в большинстве случаев, только сервис и сервер очереди.
И основной мой посыл был в том, что от перехода на очереди именно связность не поменяется. Сервисы как оперировали согласованными форматами данных в согласованных местах, так и продолжили оперировать согласованными форматами данных в согласованных местах.
P.S. Бизнес требования могут быть по разному реализованы, так что само по себе бизнес-требование может ничего и не увеличивает, а вот его реализация - вполне себе.
Технология ABENICS: революция в области механики?
Но вот момент, когда этот модуль 2 проворачивается очень быстро - меня напрягает больше. Это или полностью ненужное движение, или проворот выполняется бесконечно быстро, или шар подклинивает в этот момент на время проворота. На сколько могу судить, это именно что лишнее движение...
Технология ABENICS: революция в области механики?
Там есть чем цеплять - со стороны шара в этот момент просто продольные зацепы, которые шар и проворачивают (а-ля отверткой). "Соска" у шестерни только с одной стороны.
В очередь, ...! Как управлять состоянием системы через события
Да, меньше связность - это про "один модуль стал о другом знать меньше". Это я и называю "упростился протокол взаимодействия модулей".
Но сам процесс "стал знать меньше" - это не потому, что на событийную модель перешли, а потому что рефакторинг/переделки были, которые и уменьшили связность модулей, чтобы взаимодействие лучше на событийную модель "ложилось".
Но такие переделки вполне применимы и при REST API (и любом другом API). И дадут ничуть не худшее уменьшение связности.
В очередь, ...! Как управлять состоянием системы через события
Я про это и говорю. Изменился протокол взаимодействия, он стал проще. Проще протокол - меньше связность.
Очередь тут вторична. С тем же успехом можно без очереди жить. Сделать REST API которое все входящие ордера просто обрабатывает.
А если имеется сервис с этим же API, который все входящие ордера из API в очередь добавляет, а из очереди уже другой сервис их обрабатывает?
Для внешнего наблюдателя эти 2 сервиса (что с обработкой сразу, что с очередью) будут полностью идентичны. И связность они будут давать полностью идентичную.
Просто потому, что применение очереди на связность не влияет - это внутренний нюанс реализации сервиса и/или связи между сервисами.
В очередь, ...! Как управлять состоянием системы через события
А чем это отличается от единой точки входа - API компонента B?
Формат данных согласовывается одинаково, очереди/пути для отправки данных - аналогично, подлежат согласованию между сервисами. Связность остается той же.
Или мы рассматриваем ситуацию, что у компонента B свое API для A и С, но при переходе на событийную модель упрощается протокол взаимодейсвия и появляется общая очередь?
Тогда уменьшение связности - заслуга рефакторинга под более простой протокол, а не перехода на событийную модель.
Я могу согласиться, что в событийной модели связность может быть слабее. Но это только потому, что протокол взаимодействия, как правило, значительно проще. В событийном модели организация сложного протокола взаимодействия требует значительно больших усилий от разработчика (в отличии от REST или RPC подходов).
Но сама по себе событийная модель не уменьшает связность.
P.S. спасибо, Concepts возьму на заметку.
В очередь, ...! Как управлять состоянием системы через события
Связность не меняется.
Что в REST надо знать, в какое API и в каком виде данные отправляются, что в событийной модели надо знать, в какую очередь и в каком виде данные отправляются.
От изменения способа доставки данных связность не поменяется.
В Event-driven добавляется 3й элемент - очередь сообщений, что наоборот, усложняет схему работы (потому как появляется дополнительная точка отказа).
P.S. а в чем картинки рисовались?
4 часа недоступности: постмортем падения Dodo IS
Так то оно так, только 2 нюанса:
В четверг шансы на подобный отдых намного меньше. Тем более меньше ситуаций "Я уже выехал из города на все выходные. Связи нет и не будет.".
Даже если подобное случилось, разработчик будет на связи уже в пятницу (через считанные часы), а не через два дня, в понедельник.
Так что правило "не лить обновления в пятницу" достаточно популярно. Как и "не обновляться перед длинными выходными" по тем же причинам.
Хотя в данном случае оно бы не помогло, с этим я тоже полностью согласен. Хотя бы потому, что в данном случае, пятница вечер - это пик нагрузки. И не говоря уже о том, что с обновлением инцидент не связан.
Go 1.20 и арена памяти
Битые ссылки - это не nil-указатели, а указатель на область памяти, где раньше была эта переменная, а потом ее собрал сборщик мусора и пометил область свободной для заполнения снова...
В итоге к моменту чтения, по старому адресу уже совсем другие данные могут оказаться...
Проблема в том, что возникает плавающая бага, которую очень сложно диагностировать (в любом языке)...
Go 1.20 и арена памяти
Ладно утечки... Лично меня больше напрягают битые ссылки, которые выявляются только при запуске со специальными флагами...
А там и гонки - что быстрее? Переменная прочтется или перезапишется?
Go 1.20 и арена памяти
А причем компиляция и самодостаточность екзешника?
Java и C# вполне компилируются, пускай и в промежуточное представление.
Новые форматы публикаций
А чем кейс от туториала принципиально отличается? Особенно для технических статей?
Как бы и в обоих категориях подходит тема вида "Я сделал ЭТО ТАК".
Как развернуть IDE для прототипирования в облаке за 5 минут?
Следует учитывать, что code-server - это не VS Code. Главным образом в плане расширений.
Code-server использует свой репозиторий расширений и там далеко не все, что есть для VS Code.
Кроме того, часть расширений не работает должным образом - в частности местами не завелся дебаг.
Поэтому для меня гораздо удобнее VS Code с плагинами удаленной разработки. Впрочем, я и для локальной разработки подобной схемой пользуюсь - разрабатываю в контейнере ).
Причем тут есть 2 пути: делать для каждого проекта свой контейнер (VS Code отлично такой путь поддерживает) или вручную запускать контейнер с доступом по SSH и к нему подключаться (я в итоге остановился на такой схеме).
Выдать периферию, батарейки и другую оргтехнику — для этого мы установили вендинговый автомат в офисе
Если задача была в получении опыта по работе с вендинговыми автоматами - то молодцы.
Однако судя по описанию:
Задача была в улучшении сбора статистики... Ну что же, между "никакой автоматизации" и "полная автоматизация" очень большая пропасть... И на мой взгляд, в данном случае достаточно было очень сильно упростить заполнение таски в Jira (или в другом средстве сбора статистики) - просто упростив заполнение таски. Например, штрих-код на пропуске + штрих-код на упаковке товара (или коробке с определенным типом товара) и небольшой сервис... Дополнительно - комп со сканером (тот же Raspberry Pi) или даже смартфон с камерой... Сосканировал бейджик + сосканировал товар - и пошел по своим делам. А все остальное сделает сервис...
Полная автоматизация нужна когда вообще нет доверия между участниками схемы... А когда доверие есть - достаточно сделать удобно.
Как базы данных «ключ-значение» обеспечивают производительность и масштабируемость без границ
То, что отношений нет на уровне СУБД - не значит, что отношения нельзя организовать на уровне ключей или хранимых объектов.
Да, придется самостоятельно следить за целостностью и согласованностью данных. Но это вполне реализуемо и достижимо.
Впрочем, полноценно заменить реляционную СУБД все равно не удастся скорее всего - главным образом потому, что SQL позволяет очень гибко данные получать и обрабатывать. А с KV-базами надо заранее планировать "где кто и как" будет данные получать и обрабатывать.
Trunk Based Development — кто такой и зачем нужен
По крайней мере в git история правится так или иначе ) Удобно/неудобно - другой вопрос.
Hg же в принципе не дает править историю (максимум - локально, до push). Однажды пробовали и на сервере подправить... По факту всем пришлось заново клонировать репозиторий )
Я бы назвал это главным различием git vs hg. И поэтому для публичных проектов git лучше, на мой взгляд. А как итог - git в принципе вышел вперед...