Forwarded from Бегаешь как девчонка
Обновление в нашем приложении!
Теперь вы можете:
— Видеть на карте все города, где проходят наши пробежки.
— Подать заявку на открытие клуба в своём городе! 🏃🏻♀️🌍
И, конечно, мы без ума от того, как вы переходите из лиги в лигу — это невероятно вдохновляет! Спасибо вам за вашу страсть и движение!
Скачать приложение 💕
Теперь вы можете:
— Видеть на карте все города, где проходят наши пробежки.
— Подать заявку на открытие клуба в своём городе! 🏃🏻♀️🌍
И, конечно, мы без ума от того, как вы переходите из лиги в лигу — это невероятно вдохновляет! Спасибо вам за вашу страсть и движение!
Скачать приложение 💕
❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Сделали свою реализацию бота для поддержки в приложении. Теперь все обращения удобно расположены по топикам.
Можно тоже попробовать что-нибудь написать, а может даже попытаться сломать по ссылке - https://direct-go.run-like-girl.ru/support. Мы хоть и протестили, но может что-нибудь ещё найдётся, всё-таки там очень жёсткий вайбкод)))
Можно тоже попробовать что-нибудь написать, а может даже попытаться сломать по ссылке - https://direct-go.run-like-girl.ru/support. Мы хоть и протестили, но может что-нибудь ещё найдётся, всё-таки там очень жёсткий вайбкод)))
Иногда бывают моменты, где нет правильного решения. Такое редко случается в коде, но довольно часто может происходить при общении с коллегами, особенно в сценариях, когда у вас противоположные точки зрения.
Я как человек довольно сильно рефлексирующий почти над каждой ситуацией переживаю правильное решения я выбрал или были альтернативные варианты лучше.
И в таких ситуациях может помочь ChatGPT. Просто описываешь контекст со своей стороны (конечно он может быть искажен, но что есть) и спросить правильно ли ты поступил в данной ситуации. Обычно он накидывает, как можно было поступить и потом описываешь, как ты поступил и скорректировать действия в будущем.
Например, в последнем кейсе он меня успокоил и сказал, что всё ок, поэтому теперь можно особо не рефлексировать, так как ChatGPT сказал, что всё правильно)
Я как человек довольно сильно рефлексирующий почти над каждой ситуацией переживаю правильное решения я выбрал или были альтернативные варианты лучше.
И в таких ситуациях может помочь ChatGPT. Просто описываешь контекст со своей стороны (конечно он может быть искажен, но что есть) и спросить правильно ли ты поступил в данной ситуации. Обычно он накидывает, как можно было поступить и потом описываешь, как ты поступил и скорректировать действия в будущем.
Например, в последнем кейсе он меня успокоил и сказал, что всё ок, поэтому теперь можно особо не рефлексировать, так как ChatGPT сказал, что всё правильно)
❤2🔥2
"Мы такими темпами во весь skyeng залезем" - шутка, которая вышла из-под контроля.
Хотел написать небольшой пост историю, что скрывалось за этой фразой, но точную хронологию уже не смогу передать, поэтому вынесу сюда основной момент, который хотел отметить.
В начале моего пути в Skyeng мы с https://news.1rj.ru/str/w0man_in_tech и QA отделились в отдельную команду с довольно интересным названием Landing Factory.
Проходит пару лет...
После нескольких лет упорной работы мы оказываемся здесь, где Ирина находится в роли CTO и я, который затащил обновление Angular и планирующий ещё много изменений в рамках монорепы (по заветам от @rokomarov + от себя довольно много докинул).
В целом здесь моя благодарность Ирине, что она лучший тимлид, которого я знаю (на самом деле даже 2 Ирины, чтобы никого не обидеть)) и самый лучший CTO, которого я знаю (я видел, как минимум ещё 3 CTO и почти всегда у них проблема, что они очень далеко от простой разработки, а вот Ирина близко☀️ ).
Да и в целом, она как наглядный пример, что люди, которые проявляют инициативу получают планируемое в жизни и компании в отличие от тех, кто предпочитает двигаться по течению.
В общем, я рад, что работал и продолжаю работать с Ириной в одной команде/компании и смотря на неё всегда есть мотивация становится лучше и видеть планку до которой ещё далеко
Хотел написать небольшой пост историю, что скрывалось за этой фразой, но точную хронологию уже не смогу передать, поэтому вынесу сюда основной момент, который хотел отметить.
В начале моего пути в Skyeng мы с https://news.1rj.ru/str/w0man_in_tech и QA отделились в отдельную команду с довольно интересным названием Landing Factory.
Проходит пару лет...
После нескольких лет упорной работы мы оказываемся здесь, где Ирина находится в роли CTO и я, который затащил обновление Angular и планирующий ещё много изменений в рамках монорепы (по заветам от @rokomarov + от себя довольно много докинул).
В целом здесь моя благодарность Ирине, что она лучший тимлид, которого я знаю (на самом деле даже 2 Ирины, чтобы никого не обидеть)) и самый лучший CTO, которого я знаю (я видел, как минимум ещё 3 CTO и почти всегда у них проблема, что они очень далеко от простой разработки, а вот Ирина близко
Да и в целом, она как наглядный пример, что люди, которые проявляют инициативу получают планируемое в жизни и компании в отличие от тех, кто предпочитает двигаться по течению.
В общем, я рад, что работал и продолжаю работать с Ириной в одной команде/компании и смотря на неё всегда есть мотивация становится лучше и видеть планку до которой ещё далеко
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
misha98857
Подглядел у Вастрика, что была рекомендация данной книги. Так как прочитал пока всё, что хотел прочитать, поэтому теперь на пару дней займусь данной книгой. В целом она более повествовательная, а такое мы любим :) Может уже читал и может поделиться стоит…
Вот знаете Феномен Баадера — Майнхоф? А вот недавно поймал такой кейс.
Это относится к посту о книге "Цель" и то, что отсылки на неё я увидел минимум 4 раза, как в рабочих синках, так и в жизни. Честно, когда я начал её читать, то сначала подумал, что мне ещё рано до неё и прочитав пару глав отложил в пользу книги "от хорошего к великому", но недавно осознал насколько части вещи, которые встречаются в "Цели" обыденны.
На самом деле, здесь довольно показателен пример с QA в нашем Skyeng, как пример вечная проблема, что ресурсов QA не хватает и они встают узким горлышком в процессе поставки задач.
Если 2 варианта:
1. Бесконечно раздувать команду QA. Правда это вызовет проблемы с раздуванием ФОТ, простоем QA, так как поток задач хоть и равномерен, но бывают случае, когда делаются действительно масштабные проекты, больше нагрузки на лидов и ещё масса проблем.
2. Разгрузить QA и стараться всё максимально автоматизировать. Это вариант, который как раз сейчас используют в компании.
Примеры, как разгружаем в Skyeng:
1. Допустима практика dev-теста. Когда разработчик подхватывает задачу другого разработчика, пишет/переиспользует + дополняет новыми пунктами чек-лист и проверяет по чек-листу. Таким образом мы можем снимать нагрузку с QA в случае высокой нагрузки не теряя качества поставляемых решений на прод.
2. Expert QA пишут e2e. Это разгружает не только QA с расчётом, что чем больше качественных e2e-тестов будет в компании, тем меньше нужно будет QA заниматься непосредственной проверкой, но и позволяет разработке вносить изменения заранее находя основные проблемы в решении и потенциально очень помогает при изменении изменений в масштабе всей компании, как пример обновление Angular.
3. Высокое внедрение автоматизации и AI в процессы QA. Сейчас в компании есть решения, которые позволяют создавать задачи по исправлению бага на базе треда, собирать чек-лист проверок на базе изменений в задачах в один клик, автоматизация на рутинные действии.
В целом, об этом хорошо рассказывается в 13-15 главе книги, где очень показательно демонстрируется на походе. И прочитав 3 небольшие главы можно начать замечать довольно много интересных вещей и альтернативных вариантов решения проблемы ТОС
Это относится к посту о книге "Цель" и то, что отсылки на неё я увидел минимум 4 раза, как в рабочих синках, так и в жизни. Честно, когда я начал её читать, то сначала подумал, что мне ещё рано до неё и прочитав пару глав отложил в пользу книги "от хорошего к великому", но недавно осознал насколько части вещи, которые встречаются в "Цели" обыденны.
На самом деле, здесь довольно показателен пример с QA в нашем Skyeng, как пример вечная проблема, что ресурсов QA не хватает и они встают узким горлышком в процессе поставки задач.
Если 2 варианта:
1. Бесконечно раздувать команду QA. Правда это вызовет проблемы с раздуванием ФОТ, простоем QA, так как поток задач хоть и равномерен, но бывают случае, когда делаются действительно масштабные проекты, больше нагрузки на лидов и ещё масса проблем.
2. Разгрузить QA и стараться всё максимально автоматизировать. Это вариант, который как раз сейчас используют в компании.
Примеры, как разгружаем в Skyeng:
1. Допустима практика dev-теста. Когда разработчик подхватывает задачу другого разработчика, пишет/переиспользует + дополняет новыми пунктами чек-лист и проверяет по чек-листу. Таким образом мы можем снимать нагрузку с QA в случае высокой нагрузки не теряя качества поставляемых решений на прод.
2. Expert QA пишут e2e. Это разгружает не только QA с расчётом, что чем больше качественных e2e-тестов будет в компании, тем меньше нужно будет QA заниматься непосредственной проверкой, но и позволяет разработке вносить изменения заранее находя основные проблемы в решении и потенциально очень помогает при изменении изменений в масштабе всей компании, как пример обновление Angular.
3. Высокое внедрение автоматизации и AI в процессы QA. Сейчас в компании есть решения, которые позволяют создавать задачи по исправлению бага на базе треда, собирать чек-лист проверок на базе изменений в задачах в один клик, автоматизация на рутинные действии.
В целом, об этом хорошо рассказывается в 13-15 главе книги, где очень показательно демонстрируется на походе. И прочитав 3 небольшие главы можно начать замечать довольно много интересных вещей и альтернативных вариантов решения проблемы ТОС
❤7
misha98857
Подглядел у Вастрика, что была рекомендация данной книги. Так как прочитал пока всё, что хотел прочитать, поэтому теперь на пару дней займусь данной книгой. В целом она более повествовательная, а такое мы любим :) Может уже читал и может поделиться стоит…
Дочитал книгу + статью в конце. В общем рекомендую)
1. Сразу появляется понимание зачем считаются: TTM и Lead Time (время протока), эффективность потока (отслеживание бутылочных горлышек), количество дизастеров/багов (тоже отслеживание бутылочных горлышек, но уже в плане качества).
2. Понимаешь, почему в правило берём то, что справа сверху идёт первым в работу на канбан доске и придумано оно не просто так. Да и в целом статья хорошо показывает рассказывает про канбан.
3. То, что стратегия pull выгоднее чем push в плане протока и выполнения задача в срок.
4. Пожары и их постоянные тушения - это не норма. В книге довольно хорошо прописан пример work-life balance)
5. Нужно разбивать проекты на минимально возможные таски/сабтаски, тем самым тоже увеличивая проток с точки зрения уменьшения TTM и выполнения коммитов в срок.
На самом деле довольно полезная книга и Skyeng по большей части идёт по ней (особенно стало видно с приходом текущего CTO), правда могу ручаться только за Technology департамент, как у продуктового точно не знаю как это построено)
1. Сразу появляется понимание зачем считаются: TTM и Lead Time (время протока), эффективность потока (отслеживание бутылочных горлышек), количество дизастеров/багов (тоже отслеживание бутылочных горлышек, но уже в плане качества).
2. Понимаешь, почему в правило берём то, что справа сверху идёт первым в работу на канбан доске и придумано оно не просто так. Да и в целом статья хорошо показывает рассказывает про канбан.
3. То, что стратегия pull выгоднее чем push в плане протока и выполнения задача в срок.
4. Пожары и их постоянные тушения - это не норма. В книге довольно хорошо прописан пример work-life balance)
5. Нужно разбивать проекты на минимально возможные таски/сабтаски, тем самым тоже увеличивая проток с точки зрения уменьшения TTM и выполнения коммитов в срок.
На самом деле довольно полезная книга и Skyeng по большей части идёт по ней (особенно стало видно с приходом текущего CTO), правда могу ручаться только за Technology департамент, как у продуктового точно не знаю как это построено)
🔥5❤3
Процесс непрерывного совершенствования
Сегодня запустили новый челлендж и пока шёл домой прокрутил ситуацию в голове с ними.
Представим, что у нас есть такие значения:
Проток - количество пользователей при которых челлендж работает корректно. Под корректно считаем, что количество обращений в поддержку на счёт технических проблем с челленджем и негатива в чатах около 0.
Операционные затраты - Моё с Ирой мыслетоплево + затраты на инфраструктуру
Материально производственные запасы - неутилизированная нагрузка на сервер
В итоге, мы прошли примерно такие шаги:
1. Первый челлендж на 83 человека. Решение отработало и всё ок
2. Третий челлендж на 367 человек. Упали, нашли бутылочное горлышко в отсутствующих индексах и добавили их
3. Восьмой челлендж на 1039 человек. Упали, бутылочное горлышко из-за нового поля (планировщик SQL стал использовать не оптимальный индекс).
4. Десятый челлендж на 1129. Упали, так как отправили пуш всем и нас просто заддосили. Теперь шлём частями через n8n. Так же понял, что можно не падать, если саму базу вынести на внешний ssd.
5. Одиннадцатый челлендж на 1699. Спокойно переживаем.
6. Сейчас идёт двенадцатый и всё выглядит ок.
В целом текущее решение, точно станет бутылочным горлышком на 10к/100к пользователях, но здесь основное в том, что мы заранее не увеличивали операционные расходы (не брали сервер мощнее, так как текущие ресурсы не все утилизировались и не усложняли решения, тем самым экономив мыслетопливо), увеличивали проток (сейчас стабильно выдерживаем минимум 5к участников) и сокращали материально производственные запасы повышая утилизацию сервера (здесь правда не уверен, что так можно сказать).
В общем, довольно интересно, как через падения и поиск бутылочных горлышек всё делали прям как по книге. Правда, здесь очень важно быть честным с самим собой, иначе скорее всего пойдёте не в ту сторону.
Сегодня запустили новый челлендж и пока шёл домой прокрутил ситуацию в голове с ними.
Представим, что у нас есть такие значения:
Проток - количество пользователей при которых челлендж работает корректно. Под корректно считаем, что количество обращений в поддержку на счёт технических проблем с челленджем и негатива в чатах около 0.
Операционные затраты - Моё с Ирой мыслетоплево + затраты на инфраструктуру
Материально производственные запасы - неутилизированная нагрузка на сервер
В итоге, мы прошли примерно такие шаги:
1. Первый челлендж на 83 человека. Решение отработало и всё ок
2. Третий челлендж на 367 человек. Упали, нашли бутылочное горлышко в отсутствующих индексах и добавили их
3. Восьмой челлендж на 1039 человек. Упали, бутылочное горлышко из-за нового поля (планировщик SQL стал использовать не оптимальный индекс).
4. Десятый челлендж на 1129. Упали, так как отправили пуш всем и нас просто заддосили. Теперь шлём частями через n8n. Так же понял, что можно не падать, если саму базу вынести на внешний ssd.
5. Одиннадцатый челлендж на 1699. Спокойно переживаем.
6. Сейчас идёт двенадцатый и всё выглядит ок.
В целом текущее решение, точно станет бутылочным горлышком на 10к/100к пользователях, но здесь основное в том, что мы заранее не увеличивали операционные расходы (не брали сервер мощнее, так как текущие ресурсы не все утилизировались и не усложняли решения, тем самым экономив мыслетопливо), увеличивали проток (сейчас стабильно выдерживаем минимум 5к участников) и сокращали материально производственные запасы повышая утилизацию сервера (здесь правда не уверен, что так можно сказать).
В общем, довольно интересно, как через падения и поиск бутылочных горлышек всё делали прям как по книге. Правда, здесь очень важно быть честным с самим собой, иначе скорее всего пойдёте не в ту сторону.
🔥6
Кстати, а ведь про дев-тест тоже можно провести аналогию.
В книге был пример, как один станок делает работу на 30% быстрее, чем устаревшие станки.
Если приравнять тестирование QA к эффективному станку, а тестирование через dev-тест с чек-листом к устаревшему станку, то можно решить частично проблему с протоком и материально-производственными запасами, то есть быстрее обработают задачи в Ready for test (увеличиваем проток/TTM) при этом не увеличивая объем готовых задач в очереди (не растет МПЗ)
В книге был пример, как один станок делает работу на 30% быстрее, чем устаревшие станки.
Если приравнять тестирование QA к эффективному станку, а тестирование через dev-тест с чек-листом к устаревшему станку, то можно решить частично проблему с протоком и материально-производственными запасами, то есть быстрее обработают задачи в Ready for test (увеличиваем проток/TTM) при этом не увеличивая объем готовых задач в очереди (не растет МПЗ)
Завершаем беговой сезон и с ними 2 краткосрочные цели, которые длились последние 6 месяцев:
1. Поучаствовал в первом своём забеге с памятной медалью, что в целом в начале года было не мыслимо)
2. С первого октября стал Tech Lead в компании
В общем, фраза из нашего приложения для тренировок очень ярко описывает то, что было за последние пару месяцев
1. Поучаствовал в первом своём забеге с памятной медалью, что в целом в начале года было не мыслимо)
2. С первого октября стал Tech Lead в компании
В общем, фраза из нашего приложения для тренировок очень ярко описывает то, что было за последние пару месяцев
🔥7
Ещё статью увидел, прям мой девиз по жизни. Очень многие сразу задумываются о бесконечно масштабируемой архитектуре, стараются как можно сложнее сделать инфру и т.д., причём 99% таких проектов не достигают высоких нагрузок, где такая сложность потребовалась. А здесь прям указывают на другое, что используйте самые простые рабочие решение, что довольно очевидно, но почти все в IT делают совершенно наоборот :/
Forwarded from 🦊 Angular Fox 🚀 — русскогорящие новости сообщества
✨ Используйте простейшие рабочие решения
При проектировании ПО многие инженеры стремятся к идеальной архитектуре — бесконечно масштабируемой и навороченной.
Автор статьи утверждает, что это ошибка. Вместо погони за сложными системами стоит глубоко проанализировать задачу и реализовать самое простое рабочее решение. Этот подход, основанный на принципе YAGNI, применим ко всему: от фиксов багов до разработки с нуля.
👉 https://habr.com/ru/companies/ruvds/articles/949970/
При проектировании ПО многие инженеры стремятся к идеальной архитектуре — бесконечно масштабируемой и навороченной.
Автор статьи утверждает, что это ошибка. Вместо погони за сложными системами стоит глубоко проанализировать задачу и реализовать самое простое рабочее решение. Этот подход, основанный на принципе YAGNI, применим ко всему: от фиксов багов до разработки с нуля.
👉 https://habr.com/ru/companies/ruvds/articles/949970/
❤1
Написал регламент в Skyeng, как вносить глобальные изменения в масштабе всей монорепы + сделал первую задачу по нему и другие ребята тоже подтягиваются делать глобальные изменения согласно регламенту.
А моей задачей затащили следующий пункт, который шёл по плану после обновления Angular - это отказ от устаревших браузеров Safari меньше 16 версии, так как Angular 19 официально вообще никак не хочет их поддерживать в плане виджетов и даже пришлось немного его патчить, чтобы работало.
Сейчас патчей нет и можно переживать, поэтому едем дальше, так как на монорепу ещё как минимум расписан план на 14 шагов для приближения к светлому будущему)
А моей задачей затащили следующий пункт, который шёл по плану после обновления Angular - это отказ от устаревших браузеров Safari меньше 16 версии, так как Angular 19 официально вообще никак не хочет их поддерживать в плане виджетов и даже пришлось немного его патчить, чтобы работало.
Сейчас патчей нет и можно переживать, поэтому едем дальше, так как на монорепу ещё как минимум расписан план на 14 шагов для приближения к светлому будущему)
🔥3
Написал статейку про технический долг на хабр https://habr.com/ru/sandbox/262252/, пока в sandbox, но мб скоро аппрувнут.
Хм, интересно, если перейти по ссылке её будет видно? Чёт доп. аккаунтов хабра под рукой не оказалось, а для анонима просто 403 🤔
Хм, интересно, если перейти по ссылке её будет видно? Чёт доп. аккаунтов хабра под рукой не оказалось, а для анонима просто 403 🤔
🎉3
Сделал сегодня септопластику, в общем Гуглу больше не верим на счёт того, как всё проходит)
Гугл такой, ну общий наркоз снижает когнитивные функции на всю жизнь плюс отходить будешь 3 дня
ChatGPT - всё ок будет, отойдешь через 1-2 часа и с когнитивными функциями всё ок будет
Реальность - отходишь за 10-15 минут 🗿
Гугл такой, ну общий наркоз снижает когнитивные функции на всю жизнь плюс отходить будешь 3 дня
ChatGPT - всё ок будет, отойдешь через 1-2 часа и с когнитивными функциями всё ок будет
Реальность - отходишь за 10-15 минут 🗿
❤2🗿1
misha98857
Написал статейку про технический долг на хабр https://habr.com/ru/sandbox/262252/, пока в sandbox, но мб скоро аппрувнут. Хм, интересно, если перейти по ссылке её будет видно? Чёт доп. аккаунтов хабра под рукой не оказалось, а для анонима просто 403 🤔
Чёт я так устал ждать модерации на хабре, нет случайно у кого-нибудь инвайта? :D
Хотел больше сделать, но мы сейчас по приложению делаем то, что на рынке почти ни у кого нет, поэтому довольно много времени заняло.
А так новый shorts - https://youtube.com/shorts/QQP0xoKWyNA?si=EabgQ50SPSCaBDN9
А так новый shorts - https://youtube.com/shorts/QQP0xoKWyNA?si=EabgQ50SPSCaBDN9
YouTube
Сеньор сеньору рознь: одни поднимают команду, другие — ломают её.
Опыт — это не только про технологии.Важно, каким ты становишься для других.Настоящие сеньоры делают сильнее не код, а людей вокруг.
🐳4🔥1