Я сам люблю заменить англицизм русским словом, но в профессиональной среде самое важное - одинаковое понимание терминов всеми участниками обсуждения, т.е. строгость. И вот я уже не обращаю внимания на "груминг" и "ретро". А про всяческие "кролик", "ручка", "борда", "стата", "фриз", "лок", "джоин" и прочее и говорить не приходится :)
А скажите, пожалуйста, насколько спроектированное решение должно приходить в команду имплементации? Вплоть до классов-интерфейсов или что-то более верхнеуровневое?
Очень любопытно, потому что не приходилось работать в таком ключе.
Спасибо за наводку. Я натыкался на сторонние библиотеки, но использовать их в prod-е я бы не стал. Жду поддержки отдельно ORM именно от Django-проекта.
Такие вопросы мне всё-таки больше нравятся, чем "сколько окон в Москве?" :)
Ещё однажды просили посчитать сколько в день расходуется деревянных палочек для мороженого во всех макдональдсах столицы. Понимаю, что интересует подход и обоснование методологии, но тут точно можно подобрать задачи на "подумать" из предметной области.
В той компании собеседование было на большой монолит с приличной историей. Кода было всякого не мало.
Такие задачи, мне кажется, дают, чтобы проверить "соображалку" и понимание языка. А релевантные примеры обрезаются до минимума, чтобы кандидату не пришлось вникать в условную "бизнес логику", а сосредоточиться на поведении языка.
А какие задачи вам запомнились на собеседованиях? Что хорошо характеризовало работодателя? Что было приятно решать?
Да, можно. Но нужно держать в голове минусы такого подхода: по вашей ссылке чуть ниже есть Caveats. При разных таймаутах на сообщение может сложится ситуация, когда находящееся в голове очереди сообщение с бОльшим ttl блокирует уже "протухшие" сообщения, стоящие за ним.
Если правильно понял, вы храните задачу в памяти приложения за счет
await Bluebird.delay(wait - estimatedTime);
Мы намеренно отказались от такого подхода.
Можно узнать, как себя показывает ваше решение? Есть ли проблемы? Какие примерно RPS и количество откладываемых задач?
Честно говоря, мне кажется, мы не знали об этом плагине. Но думаю, мы бы не стали ставить «experimental yet fairly stable and potential suitable for production use» плагин на продовый кластер RabbitMQ.
Celery используем в python-проектах, но с ним бывали внезапные утечки памяти. Предложенное решение реализовано для golang-проекта. А примеры сделал на python из-за его большей популярности.
Подход, действительно, не уникальный. Но, как показывает практика, не все о нём знают.
Изменение payload — тоже вариант. Мы выбрали заголовок, потому что предпочли не изменять тело сообщения, и заголовки обновляются «кроликом» за нас.
А как вы называете эти встречи?
Я сам люблю заменить англицизм русским словом, но в профессиональной среде самое важное - одинаковое понимание терминов всеми участниками обсуждения, т.е. строгость. И вот я уже не обращаю внимания на "груминг" и "ретро". А про всяческие "кролик", "ручка", "борда", "стата", "фриз", "лок", "джоин" и прочее и говорить не приходится :)
А скажите, пожалуйста, насколько спроектированное решение должно приходить в команду имплементации? Вплоть до классов-интерфейсов или что-то более верхнеуровневое?
Очень любопытно, потому что не приходилось работать в таком ключе.
Всё так. Я намеренно упустил инженерную конкретику, чтобы пример оставался простым и главные идеи не скрылись за сложностью обсуждаемых решений.
А технические сложности, конечно, были в обоих решениях.
Поиск по внутренней вики показывает 231 результат по слову "грумминг" и лишь 169 по слову "груминг". Видимо, какое-то общее искажение.
Спасибо, что указали на ошибку! Исправлюсь.
Спасибо за наводку. Я натыкался на сторонние библиотеки, но использовать их в prod-е я бы не стал. Жду поддержки отдельно ORM именно от Django-проекта.
Такие вопросы мне всё-таки больше нравятся, чем "сколько окон в Москве?" :)
Ещё однажды просили посчитать сколько в день расходуется деревянных палочек для мороженого во всех макдональдсах столицы. Понимаю, что интересует подход и обоснование методологии, но тут точно можно подобрать задачи на "подумать" из предметной области.
Спасибо за интересный пример!
В той компании собеседование было на большой монолит с приличной историей. Кода было всякого не мало.
Такие задачи, мне кажется, дают, чтобы проверить "соображалку" и понимание языка. А релевантные примеры обрезаются до минимума, чтобы кандидату не пришлось вникать в условную "бизнес логику", а сосредоточиться на поведении языка.
А какие задачи вам запомнились на собеседованиях? Что хорошо характеризовало работодателя? Что было приятно решать?
Да, можно. Но нужно держать в голове минусы такого подхода: по вашей ссылке чуть ниже есть Caveats. При разных таймаутах на сообщение может сложится ситуация, когда находящееся в голове очереди сообщение с бОльшим ttl блокирует уже "протухшие" сообщения, стоящие за ним.
Если правильно понял, вы храните задачу в памяти приложения за счет
Мы намеренно отказались от такого подхода.
Можно узнать, как себя показывает ваше решение? Есть ли проблемы? Какие примерно RPS и количество откладываемых задач?
Celery используем в python-проектах, но с ним бывали внезапные утечки памяти. Предложенное решение реализовано для golang-проекта. А примеры сделал на python из-за его большей популярности.
Изменение payload — тоже вариант. Мы выбрали заголовок, потому что предпочли не изменять тело сообщения, и заголовки обновляются «кроликом» за нас.