В апреле прошла конференция ProductSense — крупнейшее мероприятие по продуктовому менеджменту в России и странах СНГ. На нём Нетология узнала у практикующих продакт-менеджеров, какие навыки они применяют в работе и какие считают актуальными для рынка в целом. 

Всего мы получили более 70 идей о том, какими должны быть профессиональные навыки, soft skills и просто те качества, которые пригодятся продакт-менеджеру. В итоге получился объёмный список, который мы для удобства оформили в «осьминожку» навыков, — она поможет начинающему продакту наметить план своего профессионального развития. 

Делимся с вами конспектом самых интересных инсайтов. Это статья для тех, кто рассматривает для себя карьеру в продакт-менеджменте.

Появление Docker привело к взрывному росту популярности контейнеров, но с тех пор появились и другие инструменты. К сожалению, разобраться в них может быть совсем непросто. Но мы попробуем! И если вы считаете себя единственным, кто всего этого пока не понимает, не волнуйтесь... Это не так!

В одном из прошлых материалов мы рассказали вам о фразовых глаголах, в которых есть слово get. Статья была принята очень хорошо, поэтому мы решили сделать еще одну. На этот раз с глаголом take.

Мы насчитали минимум 65 фразовых глаголов и их значений с take — и не исключено, что есть и еще. Но в этой статье приведем примеры наиболее распространенных, которые носители языка часто используют в быту. Естественно, с кучей примеров. Поехали.

У Филиппа Кросби заслуженная репутация лидера в вопросах качества в обрабатывающей промышленности, он написал множество книг о качестве в период с 1968 по 1999 год. Среди его известных и цитируемых работ — «Качество бесплатно», «Ноль дефектов с помощью предотвращения» и «4 абсолютных принципа качества». Хотя Кросби говорил об этих темах в контексте компаний с производственными линиями, его уроки часто без изменений можно перенести на разработку ПО.

После участия в Твиттере во многих обсуждениях работ Кросби и прочтения некоторых его книг, я написал эту статью, чтобы передать на более глубоком уровне мои мысли о «4 абсолютных принципах качества» Кросби из его книги «Качество бесплатно». По моему мнению, эти четыре принципа поддерживают дискуссии о концепции отсутствия дефектов и качестве без затрат.

Примечание: у Кросби много хороших работ! Эта заметка не критикует его творчество. Она подчёркивает, как я использовал идеи Кросби и применил их в контексте моей работы с программным обеспечением. Вы можете согласиться со мной, а можете не согласиться. И это нормально. Я лишь делюсь своими знаниями и взглядом на мир качества в моём представлении.

Четыре абсолютных принципа качества

1. Качество определяется как соответствие требованиям.

2. Способ обеспечения качества — предотвращение, а не оценка.

3. Стандартом работы должно быть Отсутствие Дефектов.

4. Мера качества — цена несоответствия, а не индексы.

Требования меняются и расширяются в ходе любого проекта. Это естественный аспект разработки программного обеспечения. Менеджер проекта должен предвидеть и планировать это, например, путем включения буферов в планы на случай непредвиденных обстоятельств при взятии на себя обязательств. Расползание рамок (от англ. "scope creep", также известное как расползание возможностей и расползание требований), однако, относится к неконтролируемому расширению возможностей, которые команда пытается запихнуть в уже переполненный проект. Все это не помещается.

Постоянное изменение и расширение требований затрудняет своевременную реализацию приоритетных функций. Постоянное расширение функциональности приводит к задержкам, проблемам с качеством и нерациональному использованию энергии. Расползание рамок — одна из самых распространенных проблем в разработке программного обеспечения.

Тимлидами редко рождаются, чаще — становятся. Самый частый пример, который я видел — тимлидом назначают самого ответственного разработчика из команды. Наделить ответственного человека еще большей ответственностью — сильное и эффективное решение, правда же? 

Как говорил дядя Бен, большая сила — это большая масса, умноженная на большое ускорение большая ответственность. Поэтому новоиспеченный тимлид (со всей этой растущей ответственностью и силой) может поддаться соблазну принимать как можно больше сильных и эффективных решений.  

Давайте рассмотрим десять простых практик, которые помогают ответственному тимлиду добиться нужного результата.

Эта статья является переводом статьи из блога Uber. Обычно мы в Qameta Software не занимаемся переводами, но мимо этой статьи пройти не смогли. Хороший и исчерпывающий материал о том, что такое flaky-тесты, какие они бывают и как с ними справляться (с некоторыми проявлениями). Часть материала, посвященную переезду Uber с микросервисов на монорепо я опустил, оставив только то, что напрямую связано с отработкой flaky-тестов.

Юнит-тесты лежат в основе любой Continuous Integration (CI) системы. Они позволяют обеспечить контроль над качеством кода при высоких темпах разработки, предупреждая инженеров о багах в новом коде и регрессии в кодовой базе. Кроме того, они снижают стоимость разработки за счет обнаружения ошибок на ранних этапах. Именно поэтому построение стабильной и работающей тестовой инфраструктуры является одним из базовых требований для любой крупной разработки.

К сожалению, flaky-тесты осложняют жизнь тем, кто это требование пытается выполнить. Давайте считать, что мы будем принимать тест как flaky если на любых двух воспроизведениях он возвращает разные результаты: прошел или упал, — без изменения кода. Такие тесты чаще всего возникают в результате одной из двух причин: недетерминированность на уровне кода (порядок исполнения тредов и другие сложности с многопоточностью) или неоднородностью окружений, в которых выполняется тестирование (на одной машине все работает хорошо, а на CI-сервере тесты падают).

Давайте рассмотрим простой пример, на котором будет понятно, откуда у проблемы ноги растут:

Вам поручили спроектировать инфраструктуру на основе контейнеров? И вы, скорее всего, понимаете, какую пользу могут принести контейнеры разработчикам, архитекторам и командам эксплуатации. Вы уже что-то читали о них и с нетерпением ждете возможности более подробно изучить эту технологию. Однако перед погружением в обсуждение архитектуры и развертывание контейнеров в продакшн-окружении необходимо знать три важные вещи.

Я читатель со стажем. Можно сказать, что я читаю всю свою осознанную жизнь — с раннего детства и до прошлого года каждую неделю я проглатывал пару-тройку книжных новинок. И я с удовольствием бы продолжал читать и дальше… вот только книжки кончились.

Нет, я серьёзно. Кажется, я прочитал их все. Конечно, не все вообще, а все интересные. Современная книжная пустыня настолько пуста и безвидна, что начинает казаться, будто современные писатели дружно перестали писать.

— Ага, — скажет на этом месте внимательный читатель, заглянув в мой профиль, — так это у вас старость. Мужчины после сорока часто бросают читать.

— Но, я-то как раз не бросил! — воскликну я, — я до сих пор могу читать до утра, если найду интересную книжку! Вот, давеча, нашел на АТ «Семь дней до Мегиддо» Сергея Лукьяненко, так лишний круг на МЦК намотал, пока дочитывал. К сожалению, таких историй я встречаю всё меньше и меньше…

— Интересно почему? — спросит мой собеседник, — у тебя есть версия?

— Вот она, — вздохну я, виновато добавив, — только я, это… от Адама начну.

Когда задачи не выполняются, виноват часто не только тот, кто их делал, но и тот, кто ставил. Ведь от правильной постановки напрямую зависит качество и эффективность выполнения. Не приложили инструкций, не объяснили целей и ожидаемых результатов, не дали инструментов – вот у сотрудника или подрядчика и не получилось сделать все, как нужно.

Сложность еще и в том, что часто с позиции постановщика сложно оценить, какая именно информация, данные и инструменты нужны исполнителю. Первому кажется, что все очевидно, а для второго это не так. Чтобы этого избежать, можно использовать методы постановки задач, которые помогают разложить все по полочкам, не упустить ничего важного и повысить шансы на успех. В статье рассмотрим 5 таких методов с примерами.

Правильный подход к Progressive Delivery

Команда Argo с гордостью представляет Argo Rollouts v1.0! Узнайте, зачем был запущен этот проект и как мы работали над ним. Инструкции по установке см. на странице релизов.

Обычно когда речь идет про «научную фантастику», то наукой, которая лежит в основе сюжетов выступают физика, биология, может, компьютерные технологии. Что-то из области точных наук. Но некоторые фантасты не спешат идти проторенными путями, предпочитая удивлять читателя. Например, обращаясь к лингвистике и показывая миры или конфликты, в которых слово играет ключевую роль. 

Очень приятно знакомиться с изобретательными способами показать, что речь — это инструмент, причем весьма функциональный и пластичный. На тему необычных языковых систем, вопросов взаимопонимания и того, как слово может влиять на человека (и не только) можно сказать не меньше интересных вещей, чем по поводу искусственного интеллекта или терраформирования Марса. Вот несколько тому примеров.

Стресс — это норма жизни. Без стресса нет роста и обучения новому.

Передоз стресса, как передоз чего угодно — вызывает защитную реакцию. Сначала — сопротивление и попытки адаптации, затем, если эти попытки провалились — схлопывание энергетических систем, чтобы не умереть. 

Выгорание — яркий пример случая, когда защитная реакция организма может убить, если сознательно не вмешаться в процесс.

Привет, Хабр! Меня зовут Антон. Примерно год назад я начал работать с Serverless — и был покорён этим подходом к разработке приложений. Несмотря на определённые недостатки и ограничения, потенциал бессерверных вычислений огромен, за ними большое будущее. Очень приятно, что честь стать первым куратором хаба Serverless выпала именно мне. Мои задачи — находить интересные материалы, показывать новые возможности и помогать тем, кто интересуется этой архитектурой. В первом посте я собрал статьи разных авторов с Хабра, которые знакомят с идеей Serverless- подхода и помогают разобраться, для чего её лучше всего применять.

У меня есть несколько микросервисов, которые общаются друг с другом с помощью JSON через REST, и мне кажется, что скоро они достигнут предела производительности VPS, и мне нужно будет его апгрейдить, чтобы не было просадки по производительности.

И я решил оценить, какой выигрыш в производительности я смогу получить от gRPC (если вообще смогу) и, что более важно, сколько усилий мне придется приложить, чтобы полностью перевести все мои микросервисы на gRPC.

За эти годы мне посчастливилось работать над некоторыми крупномасштабными проектами, написанными на React. Сегодня я соберу важные вещи, которые нужно учитывать при создании нового проекта или расширении функциональности любого крупномасштабного приложения. Мы начнём с самых основ, а затем пойдём глубже. Так что пристегнитесь!