HTTP Response 418

Воу, коменты подъехали =) обновляйте клиенты =) ВАЖНО! Чтоб комментарии появились к постам на вашем канале, у канала должен быть создан чат.

Самое крутое объяснение артиклей в английском, которое я встречал))) https://www.youtube.com/watch?v=Y1UfqervEb4&ab_channel=VirginiaB%C4%93owulf%C2%B7EnglishStudies

Это очень смешно 😅

А вы используете pubf и другие автогенерируемые сниппеты шаблонов в PhpStorm? https://www.youtube.com/watch?v=ec3aOtWxOog&ab_channel=JetBrainsTV

Тут промокоды для NICUA приехали:) Купон на 1000uah, хостинг с панелью DirectAdmin — BDAY1000HSTNG Код со скидкой 20% на домен .COM.​UA — BDAY13CUA Код со скидкой 20% на домен .KIEV.​UA — BDAY13KUA Код со скидкой 20% на домен .ORG.​UA — BDAY13OUA Код со скидкой 70% на домен .WEBSITE — BDAY13WEB Код со скидкой 85% на домен .TRADE — BDAY13TRA Код со скидкой 85% на домен .PW — BDAY13PW Код со скидкой 85% на домен .PARTY — BDAY13PAR

Написала о том, как был придуман мини-квест и вообще про Spotify-коды. Не поверите куда написала. https://habr.com/ru/post/518970/

У сообщества Women Who Code Kyiv открылась регистрация на вторую волну менторской программы. 🎉 Я сама являюсь учасницей этой программы в роли менти, и довольна всем, от выбора менторки для меня, так и нашим сотрудничеством. Приглашаются как менти, так и менторки и менторы. Подробная информация здесь.

Шёл очередной месяц карантина... https://youtu.be/QBZff_BrK2k

Тут забанили очередное зеркало OPDS каталога флибусты на iOS. Проблема решилась быстро - добавлние А записи в админке Clouflare домена для поддомена - коротеньким конфигом для проксирования Как же классно все таки иметь свои сервачки, всегда могут пригодится P.S. конфиг проксирования для nginx

server {
  listen 80;
  listen [::]:80 ;

  server_name flibusta.webhook.pp.ua;

  location = /robots.txt { return 200 "User-agent: *\nDisallow:/ \n"; }
  location / {
    proxy_pass https://flibusta.is;
  }
}

Кстати сам домен у меня настроен через cloudflare, поэтому нет настроек https. Сервер отдает по http, а cloudflare уже добавляет сертификаты

И мы перемещаемся в Украину Помните, там была петиция по поводу "Запретить внедрение 5G-за крайне негативное его влияние на здоровье!"? Петиция набрала требуемые 25К+ подписей и ушла на принятие решения в аппарате президента. И знаете что... ТАМ ОТВЕТИЛИ! Прям очень хорошо, надо сказать. Грамотно. На русском языке расписали что-как и почему. Со ссылками на исследования и решения различных ведомств и университетов. Можно копипастить оттуда текст и распротранять: https://petition.president.gov.ua/petition/92038 Ну, например: Отсутствуют любые доказательства,подтверждающие содействие 5G в распространении COVID-19 или любой другой болезни или инфекции. На момент появления COVID-19 большинство стран не имела, и в настоящее время не имеет сетей 5G. Следовательно, они даже теоретически не могли способствовать распространению COVID-19. Необходимо отметить, что 5G является технологическим развитием предыдущих стандартов, в частности 4G, а тот в свою очередь 3G и 2G, которые на протяжении нескольких десятков лет доказали свою безопасность и с точки зрения влияния излучения, и несмотря на распространение любой другой болезни или инфекции, в том числе COVID-19.

На гитхабе бейджики подвезли. Про эту программу, за которую я получил бейджик, я писал тут

Утро понедельника добрым не бывает https://www.githubstatus.com/

​​🍸 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 2. Когда есть целая команда, допустим backend и она сервисная, то ведет она себя как мини-аутсорс. Если не ведет, то с высокой вероятностью скатится в такой мини-аутсорс. В команду вбрасывают грязевой ком из плохо сформулированных задач, а на выходе ожидают Рафаэлло. Но оно все не выходит и не выходит, это чертово Рафаэлло. Знакомо? Порой начинается охота на ведьм и все скатывается в обвинение разработчиков, а разработчики обвиняют постановщиков. Правы и первые, и вторые. Истинная проблема заключается в том, что у участников процесса происходит отрыв от истинной сути, ради которой задача и ставилась. Сервисной backend команде абсолютно непонятно какую цель преследуют продукты. Сервисная же команда как аутсорс работает Получил... распишись. Годами я доносил до тимлидов сервисных команд, что стоит вникать в суть задачи, которая прилетает на разработку. Стоит пытаться разобрать мотивацию постановщика и докопаться до сути, поняв какую проблему бизнеса он пытается решить. Очень часто бывает, что задачи ставят уже с детализацией “как сделать”, а не “зачем делать”. Продакт менеджерам я всегда говорю, что сформулируйте цель и проблему, предложите варианты решения, обсудите с исполнителями, аналитиками, службой поддержки свои варианты и послушайте что предлагают люди, которые связаны или влияют на достижение цели. Наблюдая за результатами моих советов, я пришел к умозаключению, что это не особо сильно помогает и создается больше видимости действий, чем реальных действий. Мало того, увеличилась цепочка коммуникации. Посчитаем на пальцах. Продакт менеджер проводит встречи с 3 командами, дабы донести свою идею. Тратит на это N часов, включая фоллоу-апы. Если он по-отдельности проводит митинги, то потратит 3*N часов своего времени и суммарно 3*N часов тимлидов. Можно оптимизировать до одного митинга, и тогда затраты всех участников составят 4*N часов. Затем тимлид тратит время на обдумывание, может поэкспериментировать, расписывает эту задачу и доносит до конечного исполнителя. Это еще затраты на коммуникацию с конечным исполнителем. Конечно же, включается испорченный телефон и исполнитель получает не цель продакт менеджера, интерпретацию этой цели из уст тимлида, может цель вообще видоизменится и тимлид свою цель озвучит. Порой возникают трудности и выполнить желаемое не получается. Маховик начинает вращаться в обратную сторону: проходят снова митинги, выяснения что делать и согласования. Если медиатором служит тимлид, то происходит тройная трата ресурса (конечный исполнитель-тимлид, тимлид-менеджер, тимлид-исполнитель). Если еще и переписать после этого задачу придется, то это снова повторные согласования и все по кругу. Ах да, все же заняты, митинги с уточнениями происходят когда у всех есть время. Это смещает срок до получения результата, как уже писал в прошлом посте. Неэффективненько. Пробовали напрямую менеджера и исполнителей связать, чтобы вовлечь человека в выполнение задачи и наладить прямую коммуникацию. Вылезли другие грабли… Тимлид должен быть в курсе, ибо он же отвечает за работу исполнителя. Все по кругу... Что еще не так и есть ли выход? Об этом далее… @noTieInIT

​​🍸 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 1. Когда готовился предыдущий стрим по OKR, то в компании как раз проходили другие трансформационные процессы и они уже воплотились в жизнь. Рано говорить о результатах, но я донесу смысл, а еще хочу пройти по пути размшлений и разьяснений почему была выбрана такая стратегия, какие плюсы и минусы. Поговорить подробнее об этом. Мои вот эти все тексты направлены в первую очередь на углубление в аспекты менеджмента. Сегодня расскажу о том подходе что был ранее. Проблематика довольно обширна, потому буду частями публиковать, ибо по обьему на небольшой роман бы сгодилось) В компании была структура где присутствовали сервисные команды. Это когда есть отдельно backend, отдельно frontend, отдельно qa, аналитики… все отдельно. Когда product manager придумывал новую задачу, то она проходила технические команды и оценивался их эстимейт. Замечу, что несколько команд проводили оценку. Вот прошло от нескольких дней до нескольких недель, оценка составлена и принимается решение какие задачи делать. Конечно, на базе эстимейта, ведь мы хотим делать те задачи, которые менее затратны и дают наибольший возможный результат. WUT? Что тут не так? 🔎 Время от идеи до получения результата значительно растягивается. 🔎 Это бьет негативно по мотивации. Все же хотят видеть результаты своей работы как можно быстрее? Это только тибетские ламы могут медитировать годами на рост сакуры, а в жизни все совсем иначе. 🔎 Переключение контекста. Это отвлекает и продуктивность падает. Об этой теме еще отдельно поговорю, ибо там много что сказать можно. 🔎 Через неделю некоторые узнать свой код не могут, а попробуйте теперь вспомнить детали задачи, которая была написана месяц назад? Это неэффективная перетрата времени. 🔎 Не возникает возможности копать глубоко. Чтобы преуспеть в каком-то деле, нужно совершенствоваться и погружаться в него. При поверхностных действиях результаты будут посредственные. Это чисто статистически, задумайтесь над воронкой. Еще есть чего не так и негативные, впрочем, как и позитивные аспекты сервисных команд. Об этом в следующей части. P.S. Друзья, если вам нравится контент, то делитесь им, делитесь каналом. Это очень поддерживает и стимулирует меньше спать и больше думать и писать. Я почти год на одном и том же уровне по количеству подписчиков. Чет тут не чисто)

​​👻 Как известно, Google и другие топовые компании мира, такие как: Linkedin, Twitter, Netflix, BMW, Samsung, UBER, Amazon используют метод постановки целей и достижения желаемых результатов — OKR. Сундар Пичаи, CEO Google, даже заявил, что благодаря OKR Google стал той компанией которую мы знаем (нет, это не про империю зла, как уже могли подумать). Наблюдая за чужим опытом, я начал изучать что такое OKR и как же он помогает. Пару месяцев, читал книги, статьи, собирал чужой опыт по крупицам, общался со знакомыми кто использовал эту методологию. Ну какой я задрот к деталям и качеству вы и так знаете. В конце 2019 я инициировал переход в Aurora Technologies на OKR. После полной пропитки идеей и подходом себя самого, была стадия продажи этого решения другим участникам бордпака. После продажи идеологии, наступил черед формализации и донесения до всех команд и людей информации об этом инструменте. И мы запустились. Пережили уже 2 этапа планирования и успели поменять некоторые подходы. Проблем с внедрением OKR оказалось немало. Они всплывают и спустя 5 месяцев, а потом от нашего HRD узнал, что ее предыдущая компания адаптировалась почти год к OKR. Кста, минутка рекламы, канал нашего HRD, вот он, на украинском, авторский. Но так как мы знакомы и с CTO этой компании, то с ним я начал обсуждать с чем же они столкнулись. Слов за слово… и мы уже придумали записать видео с 4 компаниями, которые живут и работают по OKR и имеют разный размер, разную структуру, культуру. Но всем им, в том или ином виде, OKR помогают быть успешными. А потом начались грабли с поставкой техники для записи, затем карантин… Несерьезно пообещать и не сделать, потому мы решили сделать стрим на эту тему! Встречайте, стрим #2. 🔥 OKR. Опыт внедрения системы целеполагания в компаниях. Без воды, булшита и всего такого. Кто видел мои доклады и выступления, посты и прогнозы, прекрасно понимает какую концентрацию полезной инфы я стараюсь донести. Наш звездный состав: — Алексей Солнцев (CTO, Kasta, ранее известная как ModnaKasta) — Дмитрий Гринь (CTO, Jooble) — Евгений Пилянкевич (CEO & CTO, Cossack Labs) — Дмитрий Меньшиков (кто бы это мог быть? 😄) Стрим будет бесплатный и интерактивный. Вопросы уже сейчас можно и нужно задать https://app.sli.do/event/qpkn7ib3/live/questions. Вопросы во время стрима чуть ниже имеют приоритет, потому прошу задать в sli.do, а на стриме уточнения. Нам нужно подумать тоже. Что можно вынести из ивента? ● Ознакомитесь с кейсами от 4-х разных компаний ● Поймете как работает система OKR на практике ● Сможете использовать методологию OKR для себя, команды и для достижения целей компании ● Узнаете заранее о возможных нюансах, сможете учесть все подводные камни, избежать факапов ● Получите от внедрения системе OKR только преимущества (быстрый рост, достижение результатов, синхронизация задач,мотивация команды) Для кого будет полезно? Для руководителей, топ-менеджеров, собственников компаний, для HR менеджеров, HR директоров, тимлидов, руководителей направлений и департаментов, для всех людей, которые стремятся увеличить свою эффективность и добиваться целей! 🎥 Ссылка на стрим (жмите кнопку “Напомнить” чтобы не пропустить): https://youtu.be/NuwPzwM5tnw 🍸Чтобы не забыть, сделали и ивент в фейсбуке, чтоб напоминал: 🚀 Если вы не знаете что такое OKR, то я выложил запись и текст. В том же виде, как давал это в Авроре. Я убрал всю воду, консолидировал чужой опыт. Теперь делюсь бесплатно во имя науки! http://dmenshikov.com/2020-04-21-okr-goal-setting-system/ Друзья, делитесь каналом с друзьями, контент все круче и круче, а органика как-то запнулась. Ничто не мотивирует так двигаться вперед, как ваша поддержка и понимание того, что это приносит пользу.

У многих разработчиков и архитекторов законно возникает множество вопросов к согласованности данных в микросервисах. Некоторые приходят к паттерну SAGA и вопросов становится еще больше 🙂 Saga из тех паттернов, к которым интуитивно подходит я бы не советовал по двум причинам: 1. Она все-таки сложна в реализации и 2. Нередко затрагивает достаточно важные бизнес-процессы в распределенной, событийной системе То есть вероятность завалить всё высокая, а исправить быстро (и ладно бы исправить — банально понять в чем дело) получается далеко не всегда. А ведь больше половины ответов на чаще всего возникающие вопросы содержатся прям вот в том самом документе, который её и породил: https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf И практически все статьи повторяют в том или ином виде описанное в этой статье (иногда дополняя технологическими особенностями, иногда приводя примеры из конкретных предметных областей). Но я все же считаю, что если уж и изучать что-то сложное, то начинать с первоисточников (если первоисточники не дискридитированы, но тогда и о чтении базирующихся на первоисточнике материалов стоит задуматься), после чего можно переходить к интерпретациям. Кто еще не читал — must read!

Understanding Raft Consensus - Part 1 https://www.micahlerner.com/2020/05/08/understanding-raft-consensus.html #raft #cluster