На данный момент они отказались от хранения вложенных документов, мотивируя это тем что с такими документами база данных дольше работает. Предлагают теперь хранить все или по разным коллекциям или в строковых полях в сериализованном виде.
Для каких целей используется данная библиотека? При падении сервиса операция останется висеть в полуобработанном состоянии, т.к. события никуда не персистируются. Т.е. для критичной бизнес-логики не подходит. Для логирования - ОК. Возможно, стоит прописать это явно?
Вы совершенно правы! Добавим в осписание сервиса что у нас нет персистентного хранения сообщений.
Имеет смысл ещё написать про реентрабельность. Напр., что будет, если я дёрну bell.Ring в обработчике?
В данный момент если из обработчика вызывать то же событие, то ничего не произойдет. Если вызвать другое событие, то будет вызван обработчик этого события.
Как дела с graceful degradation? Т.е. у нас крутятся тяжеловесные обработчики, а процесс нужно срочно стопануть. Как поведёт себя библиотека?
Сейчас graceful degradation у нас нет. Деградируем некрасиво (все просто прекратится на середине выполнения) :) Спасибо за наводку. Поставили таску на доработку.
Мы не можем понять как иначе поступить в данном случае? Может быть подскажете, направите?
Если код порождает горутины - то почему нет возможности их из-вне прибить? Контекст там, или отдельный канал какой-нить для уведомления об этом.
Вот тут будет происходить блокировка до момента, пока предыдущие вызовы не будут обработаны, а если их будет много? Выглядит как узкое место
Структура вместо интерфейса для описания сообщения заставит код быть более связанным, что по идее не очень хорошо
Спасибо! Поставили себе таски на доработки.
Почему бы в дизайне не заложить то, что при подписке на события - просто передавать на вход канал, в который надо отправить сообщение, а при отписке наоборот - его принимать (пример можно глянуть тут)?
А какое преимущество даст передача сообщений в каналы на ваш взгляд? Изначально мы решили не выбрасывать каналы наружу потому что не хотели чтобы они использовались напрямую в обход библиотеки.
Определить о какой сумме желаемой заявите (эта сумма должна быть скорее всего выше чем из п.1)
Определить минимальную сумму повышения на которую согласитесь (сумма ниже которой вы перестанете торговаться и выйдете из переговоров).
Определить за счет каких дополнительных благ согласитесь на повышение ниже желаемого уровня (например повышаем не на 50к, а на 40, но по пятницам можно не работать)
Определиться что будете делать если получите отказ (уволитесь, поссоритесь, ничего, и т.п.)
Изучить когда лучше вступать в переговоры (хорошее настроение и т.п.)
Соберете все доводы, честно определите свои минусы
Будете готовы выполнить все из п. 5 если до этого дойдет
Я бы начал с озвучивания суммы из п.2. Дополнительно не раскрывая "за что". Дальше будут вопросы - отвечаете но не оправдываетесь, стараетесь выстраивать диалог а не допрос.
Дальше уже по ситуации. Главное не идти сразу на уступки и не вываливать сразу свои "козыри".
Мне понравились еще книги Игоря Рызова о переговорах: Кремлевская школа переговоров и Переговоры с монстрами.
Там есть похожие идеи с теми которые вы описываете тут (определить свой минимум который вы готовы принять, определить стартовую "цену" с которой надо начинать переговоры, определить на какие компромиссы можно пойти чтобы получить выгоду для себя), но есть и другие интересные мысли.
В книгах о переговорах от Игоря Рызова иногда упоминаются дети как лучшие переговорщики. Они требуют именно то что они хотят, они не боятся получить отказ, у них нет чувства страха перед провалом переговоров :)
В ситуации с исключениями обрабатывать эти исключения можно на разных уровнях стека вызовов. К тому же разные типы исключений можно обрабатывать в разных местах. В этом мне видится некое удобство.
Вы правы, про ООП вопрос холиварный. Нужны выверенные формулировки чтобы точно выразить свою мысль :)
Спасибо за примеры.
Про возможность встраивания структуры в структуру знаю, как найти ключ в мапе тоже понятно. Я же писал о том что нет аналога array_search/in_array.
Каждый раз когда я не могу найти какую-то для меня обычную "стандартную" функцию вроде проверка присутствия элемента (не ключа) в мапе (in_array в PHP), я удивляюсь и задаю вопрос: "Ну почему вы ее не реализовали? Неужели только мне она понадобилась?".
Рефакторинг можно делать в зарезервированное время спринта под работу над техдолгом.
Да, вопрос взаимодействия людей с разными ролями очень интересен. Интересно как строится это взаимодействие и кто в итоге их контролирует.
По теме статьи - согласен со всем. Использую все это в своих проектах и командах. Все так или иначе работает.
Оффтопик (хаха, англицизм):
Что за бред начался в комментариях про англицизмы? Вы первый раз читаете статью по IT-тематике? Идите на первый канал, там умничайте.
На данный момент они отказались от хранения вложенных документов, мотивируя это тем что с такими документами база данных дольше работает. Предлагают теперь хранить все или по разным коллекциям или в строковых полях в сериализованном виде.
По первой части стало понятно. Подумаем над реализацией, спасибо!
По второй части, если честно, нужно какое-то время на осознание :)
Вы совершенно правы! Добавим в осписание сервиса что у нас нет персистентного хранения сообщений.
В данный момент если из обработчика вызывать то же событие, то ничего не произойдет. Если вызвать другое событие, то будет вызван обработчик этого события.
Сейчас graceful degradation у нас нет. Деградируем некрасиво (все просто прекратится на середине выполнения) :) Спасибо за наводку. Поставили таску на доработку.
Спасибо за быстрое ревью!
Мы не можем понять как иначе поступить в данном случае? Может быть подскажете, направите?
Спасибо! Поставили себе таски на доработки.
А какое преимущество даст передача сообщений в каналы на ваш взгляд? Изначально мы решили не выбрасывать каналы наружу потому что не хотели чтобы они использовались напрямую в обход библиотеки.
Определить желаемую зарплату (это ваша цель)
Определить о какой сумме желаемой заявите (эта сумма должна быть скорее всего выше чем из п.1)
Определить минимальную сумму повышения на которую согласитесь (сумма ниже которой вы перестанете торговаться и выйдете из переговоров).
Определить за счет каких дополнительных благ согласитесь на повышение ниже желаемого уровня (например повышаем не на 50к, а на 40, но по пятницам можно не работать)
Определиться что будете делать если получите отказ (уволитесь, поссоритесь, ничего, и т.п.)
Изучить когда лучше вступать в переговоры (хорошее настроение и т.п.)
Соберете все доводы, честно определите свои минусы
Будете готовы выполнить все из п. 5 если до этого дойдет
Я бы начал с озвучивания суммы из п.2. Дополнительно не раскрывая "за что". Дальше будут вопросы - отвечаете но не оправдываетесь, стараетесь выстраивать диалог а не допрос.
Дальше уже по ситуации. Главное не идти сразу на уступки и не вываливать сразу свои "козыри".
В общем случае вступление в переговоры не всегда может означать заинтересованность.
Может быть они тянут время
Может быть за счет вас выбивают лучшие для условия у других
Да и наверняка еще может быть куча поводов вступить в переговоры.
У него есть еще свой ютуб-канал где он в коротких видео (буквально по три минуты) дает разные советы.
А еще если ему написать на почту, он может дать рекомендации по книгам и фильмам про переговоры (я писал и где-то через месяц он ответил).
Мне понравились еще книги Игоря Рызова о переговорах: Кремлевская школа переговоров и Переговоры с монстрами.
Там есть похожие идеи с теми которые вы описываете тут (определить свой минимум который вы готовы принять, определить стартовую "цену" с которой надо начинать переговоры, определить на какие компромиссы можно пойти чтобы получить выгоду для себя), но есть и другие интересные мысли.
В книгах о переговорах от Игоря Рызова иногда упоминаются дети как лучшие переговорщики. Они требуют именно то что они хотят, они не боятся получить отказ, у них нет чувства страха перед провалом переговоров :)
В ситуации с исключениями обрабатывать эти исключения можно на разных уровнях стека вызовов. К тому же разные типы исключений можно обрабатывать в разных местах. В этом мне видится некое удобство.
Про сигнатуру согласен, она нагляднее)
Рассказать подробности проекта не могу, информация не публичная.
Если говорить образно, то Go мы решили использовать для глубокого бэкенда. Где большая нагрузка по количеству запросов на сервис.
Почему-то уже лет 10, наверно, нет такого желания) До этого времени были попытки.
Что вы имеете ввиду? Не смог ничего связанного в интернетах найти.
Да, вы правы, имелась ввиду динамическая типизация. Косноязычность моя проклятая)
Да, ждем.
Вы правы, про ООП вопрос холиварный. Нужны выверенные формулировки чтобы точно выразить свою мысль :)
Спасибо за примеры.
Про возможность встраивания структуры в структуру знаю, как найти ключ в мапе тоже понятно. Я же писал о том что нет аналога array_search/in_array.
Каждый раз когда я не могу найти какую-то для меня обычную "стандартную" функцию вроде проверка присутствия элемента (не ключа) в мапе (in_array в PHP), я удивляюсь и задаю вопрос: "Ну почему вы ее не реализовали? Неужели только мне она понадобилась?".
Конечно можно вернуть массив.
Но на мой взгляд это менее удобно по нескольким причинам:
Нет никаких гарантий что метод вернет именно два параметра в массиве
Нет никаких гарантий что принимаете вы два параметра
Нет никакой гарантии что элементы возвращаемого массива не будут перепутаны.
И так далее.