Сегодня я хочу поговорить о вере в то, что можно поднапрячься хорошенько и решить все проблемы. И не будет их больше, этих проблем. Надо только поднапрячься...

Это верование фундаментально неверно по нескольким причинам. Во-первых, обычно мы фокусируемся на самой явной и приоритетной проблеме. Но как только она устранена, на ее место выходит вторая по списку. А за ней третья и т.д. Причём, в какой-то момент времени каждая из них кажется супер-критичной и важной. А когда проблема уходит в прошлое, то ее место занимает следующая по списку. И так до бесконечности.

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

Активная система перестаёт иметь проблемы и области для улучшений только когда умирает или специально игнорирует их. Ни то ни другое не приводит к позитивным результатам.

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

Не прошло и много лет... :)

Вышел Selenium 4.0 alpha

Здарова, пацаны и дамы💋

Вышел новый Selenium, срочно нужно все менять. Саймон Стюард в своем твиттере написал, что новая версия уже доступна в мавен central.

Что нового?

✔️ WebDriver became W3C - теперь совместимость с браузерами должна быть стабильна, как скала. Это так же полезно для Аппиума, так как они завязаны на этот протокол
✔️ Улучшеный Selenium Grid - переписали много кода внутри, улучшили консоль. Теперь можно запускать много тестов в разных браузерах и разных ОС параллельно. Также обновили UI.
✔️ Выпилили нативную поддержку для Opera и PhantomJS.
✔️ Новая Selenium 4 IDE
✔️ Обещают апдейтить документацию прямо сразу, чтобы войтишникам было проще разобраться.

‼️ Сломали совместимость

⭕️ Методы getPosition и getSize заменили на getRect

Добавили в API:

✅ Теперь можно указывать путь к Safari driver через проперти webdriver.safari.driver

✅ Теперь можно делать скриншот конкретного элемента

✅ Теперь есть метод не только maximize, но и minimize

✅ Добавили driver.switchTo().parentFrame(). Теперь станет проще переключаться между фреймами

✅ В Chrome driver завезли новые методы
- sendDevToolsCommand - позволит делать черное с devtools
- setDownloadPath - позволяет засетать папку для скачивания

✅ В Firefox driver добавили installAddon и uninstallAddon

✅ Options теперь реализует класс Capabilites для Chrome, Firefox, IE и Safari

✅ Залили Ralative locators

Прямо хорошо поработали. Что вы думаете по поводу нового Selenium 4?

Следующую неделю астрологи объявили неделей обучения. В Киеве компания Provectus организовывает уникальное мероприятие AWS Loft. Это 5-дневное погружение в AWS технологии вместе с AWS евангелистами и украинскими экспертами. Участие совершенно БЕСПЛАТНОЕ!

Мероприятие неформальное, поэтому можно сходить только на интересные доклады, а потом поработать в коворкинге, посетить воркшоп, стенд Ask An Architect c вопросами или встретиться на кофе c AWS евангелистом. Есть уникальная возможность забукать встречу 1:1 с экспертом AWS, чтобы проконсультироваться про лучшее AWS решение для проекта.

Стоит приходить со своим ноутбуком. Он и бесплатный AWS аккаунт пригодятся тебе для воркшопов, тренингов и практических сессий. Завести аккаунт можно здесь: http://bit.ly/AWS-account.

На сайте уже доступно расписание. Я себе выбрал несколько интересных докладов для посещения. Увидимся!

#инфраструктура #aws #конференции

​​На злобу дня...

Меня всегда удивляло отношение к дефектам и ошибкам в IT. Начиная от именования и заканчивая ответственностью за качество, которую долгие годы навязывали тестировщикам. Мы используем такие слова как bug (вместо ошибка или дефект) и «возникает» (вместо выявлен или обнаружен), как будто это вовсе никак не связано с конкретными исполнителями и происходит просто само собой. Что само собой не настраивает на то, что нужно активно работать над исполнителями и влиять на самые ранние стадии разработки для раннего нахождения и предотвращения ошибок. А иначе бывает очень больно... Я натолкнулся на интересную статью с примерами плачевных последствий IT ошибок. Можно использовать как страшилки на курилке или мотиваторы для повышения качества. ;)

На днях мы обсуждали на конференции такую популярную тему как T-shape инженеры. Концепция получила широкое распространение в рамках перехода на кросс-функциональные команды. Если кратко, то вместо узкой и ограниченной специализации (I-shape, где каждый умеет что-то одно) предполагается развитие у человека определенного уровня знаний в соседних областях. Это дает возможность лучше балансировать нагрузку в команде по разным специализированным направлениям и страховать друг-друга.

Например, самые популярные "соседи" для бэкенд-разработчика - это фронтенд, автоматизация тестирования, архитектура и управление инфраструктурой. Для инженера, занимающегося автоматизацией тестирования, кандидатами для расширения своих знаний и умений будут управление инфраструктурой, ручное тестирование и бэкенд. Такой же принцип можно применить и к другим ролям/должностям.

Так вот, T-shape подход имеет в себе одну очень интересную ловушку. Дело в том, что если выбрать слишком много соседних областей, то можно превратиться в Ш-shape или человека-расческу. Такие люди много в чем разбираются поверхностно, но ничего не знают глубоко и не могут делать целиком самостоятельно. Благодаря распылению внимания, можно утратить уровень экспертизы по профильному направлению.

Это происходит благодаря очень простому, но действенному, "закону малинового варенья". Он гласит, что чем шире намазываешь малиновое варенье, тем тоньше становится слой. Можете попробовать на практике. ;) Для нашей темы, данный закон предостерегает об ограниченности и конечности имеющегося у нас времени. Если его тратить на дополнительные области знаний, то меньше времени остается на основные и уровень начинает уменьшаться. Поэтому T-shape - это круто, но аккуратно выбирайте соседние области, не пытайтесь охватить слишком много и посвящайте большую часть времени основной экспертизе.

#команда

​​Прокрастинация - один из главных врагов нашей эффективности в современном мире. Она незаметно крадет у нас кучу времени и смещает фокус с важных дел и проблем на мелочи и фоновые активности. В результате, мы успеваем делать гораздо меньше, а за какие-то дела не берёмся вовсе. Я не буду рассказывать о глубинных причинах прокрастинации. Об этом в очень доступном виде много говорит и пишет Макс Дорофеев. Есть и более глубокие труды на данную тему, так что материала для изучения данного «феномена» хватает. Я расскажу о том, какие практики помогают лично мне бороться с прокрастинацией.

Начнём с анекдота. Встречаются как-то два специалиста по прокрастинации и один спрашивает:

- Слушай, как побороть прокрастинацию?
- Да легко, могу рассказать!
- Рассказать и я могу, как побороть?

Советов дают много, но по разным причинам не все из них приживаются на практике. Дальше речь пойдёт о ТОП-3, которые работают лично для меня.

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

2. Списки задач и микро-планирование. Любые возникающие задачи я выгружаю из мозга в общий список задач на телефоне. Оттуда они могут отправиться в план на какой-то день с чётким дедлайном. Если задача пока не срочная, то она остаётся пожить в списке. Регулярно список пересматривается и часть задач либо добавляется в ежедневный план, либо дробится, либо удаляется за ненадобностью. Таким образом, я постоянно держу фокус только на самых важных задачах, остальных не захламляют мозг.

3. Отмечание задачек как сделанные и визуальные инструменты для отслеживания прогресса по плану на день. Закрытие задачки даёт приятное ощущение завершенности и прогресса. А уменьшающееся число оставшихся задачек мотивирует доделать все запланированное.

А что помогает вам? Мне очень интересно услышать ваши истории, поэтому я добавил пост на Facebook для обсуждения данной темы.

С лета прошлого года мы полностью ушли от новостей, статей и анонсов на своём сайте, заменив его на социальные сети и Telegram канал. Но оказалось, что для определённого рода контента сайт все таки удобнее. Поэтому мы снова будем задействовать данный ресурс для объемного материала.

Первой публикацией после долгого перерыва стал обзор конференции XP Days Ukraine 2018: новинки, ТОП-10 докладов, фотки, материалы. Читаем и вспоминаем как это было.

Программа этого года уже доступна на сайте конференции. Мы вот-вот откроем основной этап регистрации. Будем рады видеть вас в гостях 22-23 ноября.

#конференции

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

На прошлой неделе мне скинули ссылку на новую книжку с вызывающим названием «Get Your Hands Dirty on Clean Architecture», которая как раз преследует перечисленные выше цели. Она небольшая, но с примерами на Java. Я прикупил и добавил в список на прочтение. По результатам опубликую отзыв.

#архитектура #java #книги

Большинство отечественных IT компаний очень сильно тормозит в развитии неумение тратить деньги. Вместо этого они тратят кучу времени и сил на поиски способов сэкономить. В результате:

- одни пилят "на коленке" простенький CRM чтобы не покупать готовое решение;
- другие строят отделы ручного тестирования с кучей народу вместо найма пары грамотных людей, способных выработать здравую автоматизацию тестирования;
- третьи строят процессы "по интуиции" вместо того чтобы обратиться за компетентной помощью;
- четвёртые не могут несколько месяцев выпускать быстро новые фичи, потому что не выходит нанять классных разработчиков на зарплату -$500 от хорошей рыночной;
- у пятых нет CTO и его работу приходится делать CEO, который и так перегружен, но нанять человека "дорого";
- ну и я молчу про орехи и фрукты в офисе, вкусный кофе, соки и молоко...

На постоянной экономии очень трудно построить успешный растущий бизнес. А если и можно, то он получится очень хрупким по отношению к конкурентам без подобных подходов.

Вот только недавно писал в канале про топ известных ошибок в IT. А представьте сколько не таких известных окружает нас каждый день. Вот свежий пример сегодня с сайта магазина известного спортивного бренда:

- выпускается новая коллекция с кучей товаров;
- делается маркетинговая компания с рекламой по разным каналам, включая email рассылки постоянным клиентам;
- в названии большинства товаров есть две кавычки ‘’, а разработчики не позаботились об их экранировании;
- в результате, при нажатии кнопки купить ничего не происходит и пользователя перекидывает на главную страницу сайта (в урле «кнопки» стоит #) без показа каких-либо ошибок;
- саппорт разводит руками и предлагает всем чистить кэш и куки, ведь их тестовый товар покупается без проблем...

Зато в результате я узнал, что если оставить товар в корзине и не купить его, то через час тебе высылают напоминалку и дают 10% дополнительной скидки. :) Но зачем скидка, если купить все равно ничего не получится? :)

Сегодня решил написать об ещё одной забавной психологической ловушке, в которую попадают очень многие на разных уровнях. Я уверен что у неё есть официальное название, но я назвал её «синдромом инвестиций». :) Суть ловушки заключается в следующем:

- вы инвестируете во что-то время, деньги или другие ресурсы;
- скоро становится понятно, что инвестиция не принесёт желаемого результата;
- но вам очень жалко уже вложенных инвестиций, поэтому вы не останавливаетесь;
- в итоге результата нет, но ресурсов потрачено гораздо больше.

Приведу пару примеров из мира IT:

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

2. Купили в компании какой-то инструмент для тестирования или тест-менеджмента. Жутко неудобный под новые проекты и технологии. Все мучаются, но на любые попытки что-то изменить звучит: «мы уже инвестировали в инструмент, не будем же теперь выбрасывать его».

3. Вместо адекватного платного CI/CD инструмента под конкретные нужды взяли Jenkins общего назначения (тут прямо моя личная боль последних 5 лет). Начали пытаться из говна и палок собрать нужные пайплайны с адекватной визуализацией. Все криво и косо, погрязли в DSL на Groovy, визуально выглядит как в 2000 году, но ведь «уже столько усилий вложено, почти все настроили, да и Jenkins бесплатный»...

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

5. Кто-то не покидает проект, хотя давно пора двигаться дальше, потому что столько усилий было вложено в построение процессов, команды, архитектуры. И человек думает: «ну как же оно тут все без меня, я же так долго это строил».

К сожалению, не так просто выбраться из данной ловушки. В бытовых вопросах мы сталкиваемся с ней постоянно. Я для себя единственный способ нашёл в том, чтобы для каждой инвестиции ставить четкую краткосрочную цель и критерий успешности. Если он не пройден, то надо остановиться, даже если очень жалко потраченных ресурсов.

UPD: читатели говорят, что это называется «эффект Конкорда».

Я редко публикую в канале вакансии. Исключением являются клиенты, с которыми я работаю очень плотно и верю в их успех. Сегодня как раз такой случай. Для масштабирования продуктовой разработки мы ищем сильных Java инженеров в Одессе. Пару слов о компании и продукте:

- небольшая продуктовая компания с R&D центром в Одессе;
- делает инновационный продукт для рынка логистики;
- существующие клиенты из США;
- вся разработка локализована в Украине;
- комфортный офис в центре, много «плюшек» из соцпакета.

Что интересного для Java инженера:

- отсутствие бюрократии и микроменеджмента;
- современный стек технологий (Spring Boot, микросервисы, Kubernetes, AWS, Kafka, PostgreSQL, Redis, Elastic и т.д.);
- небольшие кросс-функциональные команды с продуктовым майндсетом;
- возможность влиять на любые технические решения;
- сильный упор на автоматизацию тестирования и CI/CD.

Что нужно знать и уметь:

- 5+ лет разработки на Java;
- глубокий практический опыт построения и поддержки микросервисных распределённых систем;
- профессиональный уровень использования Spring Boot стека;
- умело использовать Docker для всех стадий от локальной машины до продакшен окружений;
- эффективно работать в кросс-функциональной команде;
- конструктивно доносить свою точку зрения, слышать других, признавать ошибки;
- отвечать за качество своей работы и уметь его обеспечивать.

Если вас заинтересовала вакансия и вам захотелось присоединиться к команде, то смело пишите мне в личку или отправляйте резюме на mikalai.alimenkou@gmail.com.

Kent Beck пишет в своей классической книге "Extreme Programming Explained: Embrace Change" про 40-часовую неделю и овертаймы:

Overtime is a symptom of a serious problem on the project. The XP rule is simple - you can’t work a second week of overtime. For one week, fine, crank and put in some extra hours. If you come in on Monday and say "To meet our goals, we’ll have to work late again", then you already have a problem that can’t be solved by working more hours.

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

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

Поэтому берегитесь овертаймов и старайтесь их избегать в своих командах. Точечно они могут помочь решить срочную проблему или выполнить больший объем работ, но при длительном применении способны принести вам много проблем, причем совершенно незаметно.

​​Если вы хотели разобраться в разных подходах к разработке, но не было наглядного пособия... ;)

Давненько я не делился с вами интересными видео для самообразования. У меня есть несколько любимых докладчиков в мире Agile и один из них Angel Medinilla. Обожаю его доклады за прекрасные метафоры, энергетику, отличное чувство юмора и очень глубокие темы. Доклад, которым я решил поделиться, посвящен теме изменений в организациях и преодолению препятствий на пути к ним.

#видео #Agile #трансформации

P.S.: эксперимент с обезьянками так глубоко запал мне в душу, что я теперь несу его в массы. :)

До конференции XP Days Ukraine осталось чуть меньше месяца и я решил написать небольшую статью о том, как формировалась программа в этом году. Ключевыми направлениями стали Kubernetes, observability и SRE, а также инженерная культура. Получилось насыщенных 2 дня и 3 потока докладов. Надеемся, участникам понравится.

Так как я в последнее время просматриваю много резюме разработчиков, то решил написать про часто встречающийся анти-паттерн в составлении резюме. Он заключается в следующем:

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

Проблем тут сразу несколько:

- непонятна совершенно связь конкретных технологий и истории работы, если что-то использовалось последний раз лет 3-5 назад, то нет смысла об этом говорить;
- непонятно что конкретно умеет делать кандидат, с какими конкретно задачами и инициативами ему приходилось иметь дело;
- нет смысла указывать список технологий, которые просто были на проекте и с которыми кандидат не имел практического опыта, так как их используют в качестве первичного фильтра;
- из резюме хотелось бы узнать хоть немного о достижениях кандидата, не то что делал, а что Сделал;
- не стоит подробно расписывать непрофильную рабочую деятельность, например детальный опыт в PHP/C++/Delphi мало интересен, если вы ищете работу Java разработчиком или менеджером;
- важной графой является самообразование, что читал, посещал или проходил кандидат в рамках собственного развития.

Иначе все резюме похожи как 2 капли воды, отличаются только фотки (если они есть) и ФИО.

Составив хорошее резюме, вы сэкономите кучу времени себе и нанимающей стороне, а также заведомо заработаете себе плюсов в карму.

#найм #резюме #кандидаты

По последнему посту про резюме прилетело несколько вопросов в личку. Оказалось, я когда-то уже начинал эту тему в блоге на сайте. Перечитал, все по-прежнему актуально, мало что изменилось. 😄

#найм #резюме #кандидаты