Классный лонгрид о том как появился и как работает QR код.
В конце 90х японская компания Denso Wave изобрела его как альтернатив бар коду, потому что последний был крайне неудобен в использовании. Идея прижилась и через несколько лет, компания открыла идею для всех не став регистрировать патент.
https://typefully.com/DanHollick/qr-codes-T7tLlNi
https://www.denso-wave.com/en/technology/vol1.html
В конце 90х японская компания Denso Wave изобрела его как альтернатив бар коду, потому что последний был крайне неудобен в использовании. Идея прижилась и через несколько лет, компания открыла идею для всех не став регистрировать патент.
https://typefully.com/DanHollick/qr-codes-T7tLlNi
https://www.denso-wave.com/en/technology/vol1.html
👍4
Exactly-Once Semantics Are Possible: Here’s How Kafka Does It
https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/
https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/
Хороший анализ распространенной ловушки у разработчиков - "Давайте построим это сами." Строить с нуля необязательно плохо, просто надо учитывать контекст. Будущим менеджерам/лидам полезно распознавать и минимизировать такие ситуации.
Пара советов от автора статьи как это сделать:
- разработчики должны быть ближе к клиентам (конечным пользователям продукта)
- категоризировать проблему (эта проблема это наше основное направление бизнеса или нет)
- фиксировать время на такие разработки (Работа заполняет время, отпущенное на неё(с));
Причины возникновения такого поведения у разработчиков:
- чрезмерный оптимизм (Оценка задач в разработке всегда была и остается сложной, в зависимости от опыта разработчики могут недооценивать сложность системы)
- желание учится а не решать проблемы (Просто шикарное определение на мой взгляд, это то что я стараюсь проверять на интервью. Не просто тащить новые технологии в проект, а тащить потому что они решают нашу проблему. Опять же, не всегда это плохо, важно понимать момент)
- Чувство добавленной ценности (Очень тонкая штука. Работа для многих то, где люди самореализуются. Люди хотят понимать что они приносят ценность и они стараются делать это как умеют. Задача менеджеров/лидов направить их, помочь им это делать иначе)
https://www.patkua.com/blog/the-builders-trap/
Пара советов от автора статьи как это сделать:
- разработчики должны быть ближе к клиентам (конечным пользователям продукта)
- категоризировать проблему (эта проблема это наше основное направление бизнеса или нет)
- фиксировать время на такие разработки (Работа заполняет время, отпущенное на неё(с));
Причины возникновения такого поведения у разработчиков:
- чрезмерный оптимизм (Оценка задач в разработке всегда была и остается сложной, в зависимости от опыта разработчики могут недооценивать сложность системы)
- желание учится а не решать проблемы (Просто шикарное определение на мой взгляд, это то что я стараюсь проверять на интервью. Не просто тащить новые технологии в проект, а тащить потому что они решают нашу проблему. Опять же, не всегда это плохо, важно понимать момент)
- Чувство добавленной ценности (Очень тонкая штука. Работа для многих то, где люди самореализуются. Люди хотят понимать что они приносят ценность и они стараются делать это как умеют. Задача менеджеров/лидов направить их, помочь им это делать иначе)
https://www.patkua.com/blog/the-builders-trap/
Очередная книга по распределенным системам. Хорошие рейтинги на Goodreads.
Здесь можно почитать пару глав бесплатно.
https://understandingdistributed.systems/
Здесь можно почитать пару глав бесплатно.
https://understandingdistributed.systems/
Один из примеров чеклиста для новых фичей в Etsy.
О чем стоит помнить запуская фичу:
- Scope (Фича запускается как МVP или уже как полноценная фича? Если MVP как можно уменьшить/упростить скоуп фичи)
- Eligibility (Какие группы пользователей и где должны видеть эту фичу?)
- A11y/Accessibility (Нужны ли какие-то особенные требования по доступности для этой фичи?)
- Translations (Нужны ли какие-то переводы на другие языки для этой фичи?)
- Observability (Как мы поймем что фича работает? Нужно ли настроить какие-то метрики или трешхолды/алерты?)
- Performance (Может ли эксперимент повлиять на производительность? Нужно ли провести тесты для определения влияния на производительность?)
- Error States (Дизайн состояния экранов, для ошибки, для процесса исполнения/загрузки. Все ли ошибки у нас понятны для пользователя?)
- QA (Нужен ли какой-то специфический список браузеров/устройств)
- Ramping strategy (Предусматривается ли какая-то особенная стратегия раскатки фичи?)
https://www.etsy.com/codeascraft/a-checklist-manifetsy
О чем стоит помнить запуская фичу:
- Scope (Фича запускается как МVP или уже как полноценная фича? Если MVP как можно уменьшить/упростить скоуп фичи)
- Eligibility (Какие группы пользователей и где должны видеть эту фичу?)
- A11y/Accessibility (Нужны ли какие-то особенные требования по доступности для этой фичи?)
- Translations (Нужны ли какие-то переводы на другие языки для этой фичи?)
- Observability (Как мы поймем что фича работает? Нужно ли настроить какие-то метрики или трешхолды/алерты?)
- Performance (Может ли эксперимент повлиять на производительность? Нужно ли провести тесты для определения влияния на производительность?)
- Error States (Дизайн состояния экранов, для ошибки, для процесса исполнения/загрузки. Все ли ошибки у нас понятны для пользователя?)
- QA (Нужен ли какой-то специфический список браузеров/устройств)
- Ramping strategy (Предусматривается ли какая-то особенная стратегия раскатки фичи?)
https://www.etsy.com/codeascraft/a-checklist-manifetsy
Etsy Engineering
Etsy Engineering | A Checklist Manifetsy
Introduction
The first time I encountered it, Atul Gawande’s The Checklist Manifesto made intuitive sense to me. The book's...
The first time I encountered it, Atul Gawande’s The Checklist Manifesto made intuitive sense to me. The book's...
👍3
Опыт Airbnb по разработке омниканальной системы по управлению контентом и созданию разного промо. Тех деталей не много, но само развитие и работа такой платформы показана детально.
https://medium.com/airbnb-engineering/airbnbs-promotions-and-communications-platform-6266f1ffe2bd
https://medium.com/airbnb-engineering/airbnbs-promotions-and-communications-platform-6266f1ffe2bd
Натолкнулся на интересную технику которая используется при разработке на фронте - Debounce. Его называют Design паттерном. Он помогает повысить отзывчивость UI приложения и снизить нагрузку на бекенд сервисы.
Проблема - при работе с интерфейсом пользователь может не понимать работает ли UI или нет, и нажимать на кнопку несколько раз. Это рождает лишнюю нагрузку на сервисы, и ухудшает пользовательский опыт.
Решение - подход debounce предлагает кешировать события от пользователя, и если в течении X миллисекунд, действий не происходило. только после этого отправляет запрос на сервер. Есть еще вторая реализация, берется первый запрос (leading edge/imediate) и далее в течении X миллисекунд все события игнорируются.
Фронт реализация с примерами (можно понажимать)
https://css-tricks.com/debouncing-throttling-explained-examples/
Проблема - при работе с интерфейсом пользователь может не понимать работает ли UI или нет, и нажимать на кнопку несколько раз. Это рождает лишнюю нагрузку на сервисы, и ухудшает пользовательский опыт.
Решение - подход debounce предлагает кешировать события от пользователя, и если в течении X миллисекунд, действий не происходило. только после этого отправляет запрос на сервер. Есть еще вторая реализация, берется первый запрос (leading edge/imediate) и далее в течении X миллисекунд все события игнорируются.
Фронт реализация с примерами (можно понажимать)
https://css-tricks.com/debouncing-throttling-explained-examples/
"Secrets of Performance Tuning Java on Kubernetes by Bruno Borges"
Очень насыщенный доклад про оптимизацию Java и не только. На 2 с половиной часа с демонстрациями на примере Azure.
https://www.youtube.com/watch?v=wApqCjHWF8Q
Очень насыщенный доклад про оптимизацию Java и не только. На 2 с половиной часа с демонстрациями на примере Azure.
https://www.youtube.com/watch?v=wApqCjHWF8Q
🔥2
Курс для тимлидов.
p.s. Сам курс не проходил, но платформа очень известная свои тщательным подходом к контенту, ну и программа выглядит интересно.
https://making.hexlet.io/teamleads
p.s. Сам курс не проходил, но платформа очень известная свои тщательным подходом к контенту, ну и программа выглядит интересно.
https://making.hexlet.io/teamleads
👍1
Начал читать статью по мониторингу редиса, что за параметры рекомендуют отслеживать авторы статьи, и понял, что тот дешборд которым пользуюсь часть параметров не покрывает. Посмотрел ретроспективно, по рабочему кластеру параметры из статьи, они есть (просто не выведены в дешборд) и именно в них были какие-то изменения). Надо короче ставить новый дешборд (ссылка в конце статьи).
Какую мораль вывел для себя, кривая обучения/исследования выглядит примерно так.
Ставишь дефолтное, понимаешь что его тебе не хватает, разбираешь что есть еще, находишь новое, обновляешь. И так итеративно. Ну и главное не забыть про главную цель за всеми этими действиями.
https://sysdig.com/blog/redis-prometheus/
#observability
Какую мораль вывел для себя, кривая обучения/исследования выглядит примерно так.
Ставишь дефолтное, понимаешь что его тебе не хватает, разбираешь что есть еще, находишь новое, обновляешь. И так итеративно. Ну и главное не забыть про главную цель за всеми этими действиями.
https://sysdig.com/blog/redis-prometheus/
#observability
Sysdig
How to monitor Redis with Prometheus | Sysdig
Learn how to monitor Redis with Prometheus, and check out the most important metrics you should be looking at
👍1
В семействе инструментов для Prometheus пополнение. Promlens - helper для построения, визуализации и отладки PromQL запросов. Выглядит покруче чем то что есть в графана и стоковом браузере prometheus.
online demo
promlens.com
#observability
online demo
promlens.com
#observability
👍1
Сделал подборку с видео с PrometheusDayNA 2022 которых по моему мнению стоит взглянуть
Keynote: Reality Check: Is it Time to Raise Your Metrics Game? - Martin Mao & Yash Kumaraswamy.
Как рассчитать ROI сбора/использования метрик? Доклад пригодится для тех у кого еще нет метрик, можно понять как рассчитать ценность. Ну а тем у кого уже есть поможет обосновать ценность ваших инфраструктурных работ.
Boost Your Logs with Prometheus! From Logs to Metrics - Jaime Yera Hidalgo, Sysdig
Рассматривается подход как из логов системы сделать обычные Prom метрики. Может быть полезно если у вас есть древняя легаси система и все, что есть от нее, это логи веб сервера. Ну и плюс унификация всех метрик ваших систем в одном месте.
Building a Runbook Automation System for Prometheus and Kubernetes - Natan Yellin, Robusta.dev
Основная идея доклада, что в месте со сработавшим алертом хорошо бы передавать и контекст (в идеале максимум контекста), последние логи поды, список ивентов. CPU нагрузка и прочее. Это тема известная. Но автор проекта Robusta.dev пошел дальше и сгруппировал на базе таких контекстов готовые решения которые даже можно автоматические применять. Все это упаковано в платный продукт, но часть движка open source.
Centralized vs Decentralized Prometheus Scraping Architecture... - Rabun Kosar & Ales Koprivnikar
Doordash рассказывают про свой опыт на переход децентрализованный сбор метрик.
Film Premiere - Inside Prometheus: An Open Source System That Changed Technology
Документальный фильм о создании Prometheus, почему появился, как развивался.
Весь плейлист здесь.
#observability
Keynote: Reality Check: Is it Time to Raise Your Metrics Game? - Martin Mao & Yash Kumaraswamy.
Как рассчитать ROI сбора/использования метрик? Доклад пригодится для тех у кого еще нет метрик, можно понять как рассчитать ценность. Ну а тем у кого уже есть поможет обосновать ценность ваших инфраструктурных работ.
Boost Your Logs with Prometheus! From Logs to Metrics - Jaime Yera Hidalgo, Sysdig
Рассматривается подход как из логов системы сделать обычные Prom метрики. Может быть полезно если у вас есть древняя легаси система и все, что есть от нее, это логи веб сервера. Ну и плюс унификация всех метрик ваших систем в одном месте.
Building a Runbook Automation System for Prometheus and Kubernetes - Natan Yellin, Robusta.dev
Основная идея доклада, что в месте со сработавшим алертом хорошо бы передавать и контекст (в идеале максимум контекста), последние логи поды, список ивентов. CPU нагрузка и прочее. Это тема известная. Но автор проекта Robusta.dev пошел дальше и сгруппировал на базе таких контекстов готовые решения которые даже можно автоматические применять. Все это упаковано в платный продукт, но часть движка open source.
Centralized vs Decentralized Prometheus Scraping Architecture... - Rabun Kosar & Ales Koprivnikar
Doordash рассказывают про свой опыт на переход децентрализованный сбор метрик.
Film Premiere - Inside Prometheus: An Open Source System That Changed Technology
Документальный фильм о создании Prometheus, почему появился, как развивался.
Весь плейлист здесь.
#observability
👍1
12 Signs You’re Working in a Feature Factory
https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory
Фабрика фич - команда/компания которая просто клепает фичи одна за одной без оглядки на пользователя продукта и результат.
https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory
Фабрика фич - команда/компания которая просто клепает фичи одна за одной без оглядки на пользователя продукта и результат.
Частенько замечаю такую вещь, что когда знаешь какую-то тему чуть лучше среднего может происходить такой интересный эффект - читая любую статью или книгу как будто пропускаешь ее через свой опыт и начинаешь видеть одни и те же слова совершенно по-другому. Вот прямо чувствуешь в них новый смысл, с "высоты" своего опыта. В результате даже короткое предложение может заиграть новыми красками.
Курс которые сегодня рекомендую, для меня был именно таким, общая его длительность всего 1 час и это скорее начальный курс, для погружения в тему. Но на мой взгляд этот час собрал в себя прямо самое важное и слушая курс я прям удивлялся точности формулировок каждого предложения. Курс называется "Engineering and Product Collaboration". Его автор, James Stanier (Director of Engineering в Shopify).
Я рекомендую курс широкому кругу читателей, не только инженерам, но и продактам. Тем у кого мало опыта, посмотрят еще один источник информации, сравнят его с тем что уже читали. Тем у кого опыта побольше, структурируют свои знания и могут найти что-то новое.
Пару фраз которые запомнились из этого курса.
- Этот курс про инструменты, а не про готовые рецепты.
- Здесь нет правильного ответа (контекст - тема лекции была про инженерные практики и то, что можно использовать при доставке приложения к пользователям).
В этих фразах вся простота и сложность разработки одновременно. Есть куча информации о том какие есть инструменты, но какие и как правильно применять никто вам не скажет. Потому что "It depends".
https://www.udemy.com/course/engineering-and-product-collaboration/
Курс которые сегодня рекомендую, для меня был именно таким, общая его длительность всего 1 час и это скорее начальный курс, для погружения в тему. Но на мой взгляд этот час собрал в себя прямо самое важное и слушая курс я прям удивлялся точности формулировок каждого предложения. Курс называется "Engineering and Product Collaboration". Его автор, James Stanier (Director of Engineering в Shopify).
Я рекомендую курс широкому кругу читателей, не только инженерам, но и продактам. Тем у кого мало опыта, посмотрят еще один источник информации, сравнят его с тем что уже читали. Тем у кого опыта побольше, структурируют свои знания и могут найти что-то новое.
Пару фраз которые запомнились из этого курса.
- Этот курс про инструменты, а не про готовые рецепты.
- Здесь нет правильного ответа (контекст - тема лекции была про инженерные практики и то, что можно использовать при доставке приложения к пользователям).
В этих фразах вся простота и сложность разработки одновременно. Есть куча информации о том какие есть инструменты, но какие и как правильно применять никто вам не скажет. Потому что "It depends".
https://www.udemy.com/course/engineering-and-product-collaboration/
👍4