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

Также, если у кого-то есть идеи тем, которые стоит освещать в дайджесте — пишите в комментариях :)

Приятного чтения!

Цифры в скобках возле заголовков — примерное время на изучение материала

Статьи

Общее

Acceptance Criteria: Purposes, Formats, and Best Practices(8 мин). Очень хороший обзор для начинающих, чтобы получить общее представление о подходах к работе с критериями приемки.

How to Run a Prioritization Session Using the MoSCoW Framework(8 мин). Еще один отличный обзор. Автор поясняет тонкости применения техники, а также предоставляет свой шаблон в Google Sheets для фиксации принятых решений.

MVP: balancing ‘value’ and ‘minimums’(6 мин). Статья о том, как легко можно скатиться к тому, чтобы начать думать о том, как сделать «минимальный» продукт в первую очередь, забывая о том, что он еще должен приносить ценность. Уверен что многие здесь, как я и мои знакомые коллеги из разных компаний, попадались в эту ловушку. В статье разобран классический пример про машину и скейтборд, на котором показано как избежать заблуждений.

8 shortcuts for a Minimum Viable Product (MVP)(5 мин). Несколько простых, но полезных советов о том, как правильно подойти к определению MVP для своего продукта.

Что такое SAP?(11 мин). Если вы слышали об этой ERP, но боялись начать ее изучать детальнее — этот обзор как раз для вас. Статья содержит высокоуровневый обзор: историю и принципы работы этой ERP.

Overcoming Cognitive Biases That Reduce Feature Adoption(7 мин). Автор поясняет три (вероятно, ключевых) типа предубеждений, с которыми сталкиваются люди при освоении новых функций. В статье приводятся примеры предубеждений и как их преодолеть.

MBA204: Top Skills for 2020(10 мин). О наиболее важных скилах на 2020-йв целом (бизнес-анализ — на 6-мместе). Возьмем себе на заметку, что предлагают прокачивать крупные игроки рынка.

О чем спрашивать потенциального работодателя: инструкция для бизнес-аналитиков(7 мин). BA Анна Домбровская делится своим опытом по подготовке к собеседованию: что почитать о компании, какие вопросы задавать.

20 Lessons Learnt Over 20 Years Of Doing Business Analysis(20 мин). Аналитик делится опытом, который вынес за много лет работы. В статье присутствуют, как может показаться на первый взгляд, весьма очевидные вещи. Вместе с тем, как часто мы сознательно задумываемся о них?

Карл Вигерс поделился подборкой из 45 видеопро бизнес-анализ. Отличный материал как для новичков, так и для тех, кто хочет вспомнить основы. Очень рекомендую!

Detailed Requirements for Data Importing and Exporting(11 мин). Статья рассказывает о том, из каких этапов (уровней) состоит работы с импортом и экспортом. Каждый уровень подробно расписан (от контекста до требований к конкретному полю) с примерами и пояснениями.

Usability

Re-Imagining The Bottom Navigation Bar(5 мин). Хорошая подборка видов нави-панели в одном месте. Уверен, что вы встречали все (либо большинство) из указанных. И также уверен, что в «оперативной памяти» вряд ли хранится что-то кроме последнего. Так что освежить не помешает :)

22 rules for designing sign up & sign in journeys(13 мин). Подборка правил, которых стоит придерживаться при создании формы логина. Некоторые из них ситуационные, на некоторые, как правило, не будет бюджета. Но хорошо иметь под рукой чеклист из важных нюансов и «плюшек», которые можно переиспользовать в вашем продукте.

Writing Microcopy(10 мин). Очень полезная статья с множеством примеров о том, как правильно использовать микрокопии — слова или фразы, с которыми взаимодействует пользователь: названия кнопок, полей, плейсхолдеры и т. д.

You’re not still using «Read More» are you?(3 мин). Несколько полезных советов (чек-лист) о правильном именовании ссылок.

How to Write and Design User-Friendly Error Messages(8 мин). Небольшое эссе, состоящее из 6 рекомендаций, основанных на гайдлайнах от Microsoft и Apple.

The ultimate guide to not f#!@ing up push notifications(12 мин). Автор статьи рассматривает правила применения пуш-нотификаций: когда это уместно, когда — излишне. Причем, примеры не абстрактные, а основаны на вполне реальных кейсах.

Локализация приложений: как мы подружили перевод и разработку(18 мин). Очень основательный материал от компании Badoo. Разработчики делятся нюансами своего процесса, раскрывая проблемы, с которыми сталкиваются, и как их обходят.

Повышаем тех. бэкграунд

Building a Drag and Drop UI (10 мин). Очень достойный обзор основных принципов создания DND. В частности, затронуты вопросы usability, accessibility и и responsiveness различных вариантов реализации DND.

Как масштабироваться с 1 до 100 000 пользователей (7 мин). Простыми словами о главном: какие бывают уровни масштабирования и из чего они состоят.

Микробраузеры повсюду. Но что мы о них знаем? (9 мин). До этой статьи не задумывался, благодаря чему после вставки ссылки, в мессенджерах отображаются доп. картинки и текст. Если вы тоже — эта статья поможет разобраться.

События

Уже в следующий четверг (20 февраля) в Харькове пройдет BA Workshop «Business Analyst. Guilty!»от очень крутых аналитиков, посвященный критике со стороны команды. Опытные ребята поделятся своим бесценных жизненным опытом и смогут ответить на наши вопросы

14 марта в Киеве состоится Data Science UA Conference — мастхэв для тех, кто в теме.

21 марта можно будет прокачать свои знания в SCRUM на ScrumDayUA 2020 в Киеве.

24-27марта состоится REFSQ 2020 (Италия, Пиза). На этой конференции вы не найдете банальных и обыденных тем, вроде «как я построил SCRUM в своей команде». Это конференция уровня advanced. Темы очень нетипичные: авторы материалов бьют очень точечно, но очень конкретно, без «воды». Цена кусается, в сравнении с отечественными мероприятиями, но контент обещает быть ну очень интересным и расширяющим границы сознания :)

Еще есть возможность успеть на Тренинг по бизнес-анализуот Art of BA, который пройдет с 28 марта по 1 апреля. Тут вы сможете освоить основы бизнес-анализа на базе BABOK^® v. 3.0 под руководством Дениса Гобова. Также по окончании курса вам будет засчитано 40 PDU, необходимые для сдачи экзамена CCBA/CBAP.

Ну и, конечно же, не могу не упомянуть UBA 2020, которая уже совсем близко (24-26 апреля,Киев). Кстати, в этом году мне выпала честь быть спикером, так что приглашаю послушать об одном интересном случае из моей практики, а также подискутировать на тему нелегкой судьбы бизнес-аналитика ;)

← Предыдущий выпуск: BA дайджест #6

Оцінюючи свої компанії для рейтингу роботодавців, українські IT-фахівці ставили оцінки за різними критеріями, а також в коментарях уточнювали, що саме їм не подобається (якщо поставили бал нижче середнього). З більш ніж 5 тисяч коментарів ми вибрали найтиповіші і найцікавіші скарги та побажання.

До речі, якщо ви ще не голосували у рейтингу за свою компанію, то зробіть це зараз.

Компенсація

Оцінювали матеріальну компенсацію та корпоративний соцпакет. Респонденти залишили 1301 коментар, в яких найчастіше скаржилися на непрозорий та нерегулярний процес перегляду зарплат, неоплачувані овертайми, невелику кількість днів відпустки та лікарняних, а також відсутність компенсації спортзалу та медичного страхування.

«Керівник ніколи не ініціює обговорення зміни матеріальної компенсанції і задоволення поточною позицією, як у інших компаніях це робиться раз у пів року. Кожного разу це доводиться „вибивати“, через що інколи є сумніви щодо того, чи дійсно компанія так цінує своїх співробітників».

«З/п не соответствует предложенной сумме в вакансии. Нужно время, чтобы до нее дойти. Перерасчет происходит по непонятным и призрачным схемам».

«Пересмотр зарплаты был 4 года назад».

«Периодические задержки зарплаты, на несколько дней от обещанного срока».

«Овертаймы не оплачиваются, если свет в офисе отключат и оповестят за 3 часа до отключения — твои проблемы. 40 часов в неделю — требование СЕО!»

«Страховку — плати сам, английский — плати сам, за все группы, которые организовывают сами сотрудники, в виде йоги, стретчинга — плати сам...»

«Как таковой соцпакет отсутствует. Отпуск ничтожно мал — 10 рабочих дней. Оплачивается только 50% (!) от з/п во время отпуска. Оплата овертаймов есть, но она невелика. Зато бессмысленные овертаймы — это мастхев. Не будешь овертаймить — будет куча недовольств и много удивлений, что у тебя есть личная жизнь вне работы».

«Хотелось бы иметь возможность больше работать удаленно».

«С падением курса доллара вернулась к зарплате 1,5 годичной давности. Среднеконкурентая зп по городу».

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

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

«Матеріальна компенсація далека від ринкової. HR-департамент живе у своєму світі зі своїми розцінками. На прохання переглянути зарплати зсилаються на сторонні фактори, котрі ніяк не можуть впливати на рівень винагороди працівників ІТ-галузі».

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

«Все не влаштовує. Зарплатню дуже занижують, при цьому готові брати нових людей на значно більші гроші, замість того, щоби підвищити зарплатню співробітникам».

«В компании есть „потолок“ зарплат, выше которого можно подняться только, если идти в около менеджерские позиции. Оставаться техническим специалистом и рост зарплаты — вещи не совсем совместимые».

«Страхование немного странное, очень маленькое количество клиник, нет компенсации медикаментов».

«Больничных нет, страховки нет, компенсаций курсов нет, лицензии IDE не оплачиваются».

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

«Лично я не могу себя полностью комфортно чувствовать при данном уровне зарплаты и была бы более эффективной, если бы она была выше».

Умови праці

Оцінювали офіс компанії (розташування, ремонт, освітлення, температура повітря, вентиляція тощо), робоче місце (меблі, техніка, канцтовари, ПЗ) та графік роботи (наскільки він зручний та гнучкий). У цьому блоці респонденти залишили 1346 коментарів. Найчастіші проблеми — погана вентиляція та система кондиціювання приміщень, затісні опенспейси та офіси в цілому, недостатня кількість вбиралень та погане оснащення кухонь, застарілий ремонт і робоча техніка, а також незручне розташування офісу, негнучкий графік роботи й відсутність можливості працювати віддалено.

«Офис устарел, не развивался последние несколько лет. Людей много и сидеть в толпе некомфортно. Туалетов мало и очереди, места для отдыха нет. Шумно от улицы, летом жарко, а зимой холодно».

«Старый советский институт, проблемы с отоплением и горячей водой, ремонт есть только на этажах компании и то очень простенький. Кабинетная система напоминает, что угодно, кроме современной IT-компании».

«Окна темные, даже днем нужно включать свет, в офисе холодно».

«Жёсткая привязка к отметкам времени по карте или отпечатку пальца, это раздражает».

«Тіснява. Обіцяють ще один новий офіс, але поки немає».

«Мало туалетів. Та не зовсім зручні кімнати для мітингів».

«Вентиляція: часом не можна зупинити приток холодного повітря, часом не можна провітрити затхле, бо або вікно недостатньо широко відчиняється, або кімната не має витяжки. Кондиціонери дують у вухо, і так просто не пересядеш і не вимкнеш. Недостатня кількість нарадчих кімнат».

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

«Нет своей парковки для сотрудников, вечером рядом с офисом много пьяных на лавочках».

«Не хватает возможности иногда работать удаленно. Например, раз в две недели один день можно работать из дома».

«Мебель довольно старая, видно, что давно не делали ремонт. В офисе даже нет фруктов. Кондиционеры 2002 года».

«Все опоздания в офис нужно трекать, отсутствие в офисе — тоже. Ощущение, что нацеленность идет не на результат, а на 8 часов отработки и все».

«Установлен график — прийти до 10:15, за нарушение которого нужно объясняться и можно словить немаленький штраф».

«Потрібно обов’язково сидіти 8 годин на роботі в день. Усі недопрацьовані години будуть вираховуватися з твоєї відпустки».

«Постоянная нехватка устройств для тестирования, трудности с покупкой нового оборудования. Приходится использовать личные вещи/устройства».

«Деякий софт доводиться використовувати на ком’юніті ліцензіях або взагалі піратські версії».

«Нет понятия персонального пространства: шкафчиков, тумбочек».

«Ноутбук и монитор есть, если хочешь второй — плати деньги, если хочешь тумбочку — также надо заплатить».

«Хотелось бы стол с регулируемой высотой».

«Канцтовари не видаються зовсім. Хоч би мінімальний набір: ручки, блокнот тощо».

«Дешевые неудобные стулья, бывает тяжело выпросить хорошую технику».

«Из-за плотной расстановки столов не у всех есть достаточно места для личных вещей (тумбочки есть не у многих), нет места для сменной одежды и обуви. Не у всех достаточно мощные ноуты и ПК. Стулья низкого качества, часто ломаются, со столами та же история».

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

Кар’єра

Оцінювали зворотний зв’язок про виконану роботу, можливості для професійного розвитку (навчання, стажування, консультації більш досвідчених колег тощо) та умови для кар’єрного зростання. У 1375 коментарях найчастіше респонденти жалілися на відсутність зворотнього зв’язку та кар’єрного зростання, замалу кількість ініціатив щодо професійного розвитку — конференцій, курсів тощо.

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

«Карьерный рост медленный. Невозможен за пределами департамента».

«За три года нет карьерного роста, при том что часто напоминаю о желании выполнять более важные поручения и готов к обучению».

«К сожалению, присутствует кумовство. Повышают друзей, подруг, кумов, сватов. Это очень демотивирует».

«70% работы состоит из унылого портирования и багфикса, не думаю, что в таких условиях может быть карьерный рост».

«Якщо сам собі не створиш плану розвитку і не змусиш менеджерів його погодити й виконувати — ніякого зрушення не буде».

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

«Фидбек только тогда, когда уже что-то реально плохо».

«Насправді фідбек можна отримати на рев’ю, але хотілось би і між ними також якось знати чи справляєшся ти зі своєю роботою і наскільки, хоча б від менеджера, щоб не відчувати себе непотрібним».

«Обучение стало только внутренним, и посещение внешних тренингов и конференций компания больше не покрывает».

«Ни тренингов, ни стажировок, обучение не поощряется, получение сертификатов (за свои деньги) не поощряется».

«Я как разработчик хотел бы получать код ревью от сильных разработчиков. По факту сделал таску — молодец. А какими костылями — это твои проблемы».

«Смену направления нужно очень аргументированно обосновать, более опытные коллеги далеко не всегда готовы консультировать. Освоение новых навыков по большей части вне рабочего времени».

«Компания не предоставляет даже частичную оплату конференций, не говоря уже о каких-то внутренних программах».

«Пойти на обучение не всегда получается просто. Последние разы когда пробовал, бюджет было утвердить достаточно сложно».

Проект

Оцінювали проект, технології та інструменти, атмосферу в колективі та менеджмент. Респонденти залишили 1266 коментар і найчастіше спеціалісти незадоволені непрофесійним менеджментом або взагалі відсутністю менеджера, застарілими технологіями, токсичною атмосферою в команді.

«Менеджери мають вчитись бути саме менеджерами, а не розробниками».

«Багато місандерстендів з обох сторін. Треба якось старатись краще зрозуміти замовника, щоб потім не було поспіху і фейлів, бо не так щось зрозуміли».

«Проект цікавий більш-менш, але дуже нестабільний замовник, з ним важко працювати, при і так великій кількості комунікації іноді виникає багато непорозумінь, а це збиває з пантелику іноді».

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

«Менеджмента не существует в этой компании. Только СЕО, который следит по камерам, как кто работает, трекает время входа/выхода. Тимлиды были золото, но и те ушли».

«Проект долгоиграющий, поэтому много устаревших технологий. Новые направления развиваются на современных технологиях».

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

«Основна проблема — інколи проект виявляється просто нецікавим. Не відчуваєш, що приносиш реальну користь, і розумієш, що працюєш лише на зп, ну і щоб професійно розвиватися звичайно. Це трохи демотивуючий фактор. Компанія не завжди може повпливати на таке, тим більше якщо люди на аутстафі, тому працюєш ’поки тебе на це хватає’».

«Не используем технологии новее 1984 года. IDE надо покупать за свои».

«Не устраивают токсичные люди, которые подавляют всякую мотивацию делать больше для проекта».

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

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

«Высокомерие как корпоративная культура. Навязывание лайфстайла в виде агрессивной пропаганды ЗОЖ. Хамство, грубость, перебивания, отсутствие положительных фидбэков друг о друге. В основном все, что делают разработчики, — это критикуют чужой код или переливают из пустого в порожнее, жонглируя умными словами и терминами, создавая таким образом убедительную видимость „серьезного проекта“ и якобы проявляя свой профессионализм».

«Руководство так договорилось с клиентом, что разработчикам некогда писать нормальный код. Приходится постоянно писать костыли лишь бы работало хоть как-то».

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

«Атмосфера крайне токсична. Вместо командной работы постоянный поиск виновных и упрёки тех, кто „ниже рангом“. При этом на факапы „высших рангом“ глаза закрываются. На других проектах лучше, но от этого не легче».

«Процессы все время меняются, кроме того компания никак не может понять, как натянуть SAFe на Agile Scrum. Все время изобретают что-то свое. Кроме того роли PPM/PM/PO настолько размыты, что даже трудно сказать, чем эти люди все-таки занимаются».

Ізюм

Виділили в окремний блок найдивніші та найсмішніші коментарі респондентів.

«Сложновато экстраверту с интровертами уживаться в коллективе».

«Хромает трудовая дисциплина. Многие считают нормальным опаздывать или работать из дома».

«Страховки нет. Овертаймы как коты Шредингера — в компании не приветствуются, но на проектах овертаймить приходится. Больничные оплачиваются, но нужен больничный лист, если болеешь больше двух дней подряд. Оплачиваются не более 10 дней. Больше ничего. Хотя нет. Иногда, раз в неделю, приносят яблоки на кухню, штук 10».

«Нет честности со стороны компании».

«Соцпакета почти нет, но никто ничего и не обещал :)».

«Обедики закончились!»

«Знаю, что ставки для продавцов по городу есть гораздо выше».

«Не имеет значения для компании, как долго ты работаешь... тебя одинаково не ценят... коллеги проработали больше 14 лет в одной компании... думаете им тортик или хоть поздравление на почту прислали? Нет!»

«Бывает, что печенье не очень свежее; капучинизатор в кофе машине работает не всегда хорошо; кофе хотелось бы вкуснее :)».

«В плане уборки офиса, особенно санузлов, есть к чему стремиться».

«График — с 10 до 19, даже если овертаймил. Жестко. Начальство бегает и фоткает, кто когда был на работе. Аж смешно для ИТ-компании».

«Смотря, что считать гибкостью графика. Чтобы опоздать на 15 минут, напиши в кучу чатов, заполни weekly планинг, потом отпишись боту, потом тимлиду. Праздничные дни? Ахахах. Цитата из нашего конфлюенса: «28 июня — День Конституции (выпадает на субботу, так что и так выходной)».

«На кухні зажди голодні печенькоїди, чай нереально приготувати».

«Стул не очень удобный, но недостаточно, чтоб пересилить лень создавать тикет».

«Нам сто років влаштовували пакет Майкрософт Офіс. Майкрософт Офіс, Карл!»

«Есть все, кроме тишины для концентрации».

«Уже все выросли, тут гребут, а не строят карьеру».

«Ви забули дописати „адекватний“ зворотний зв’язок, тімлід може дозволити не тільки дуже експресивно виражати свої думки, але й переходити на нецензурну лексику».

Підписуйтеся на Telegram-канал «Редакція DOU», щоб брати участь у наших публікаціях та не пропустити найважливіше.

Три года назад Юля Дейнегастала студенткой школы программирования 42 school, где нет преподавателей, а обучение — бесплатное. Специально для DOU она поделилась своей историей смены профессии и переезда в США, а также рассказала о стажировках в Samsung и LinkedIn.

Предыстория

По образованию я — экономист-международник, но по профессии не работала ни дня, не считая, конечно, работы аспирантом на кафедре, откуда я сбежала спустя год. Практически сразу после университета я попала в кино и осталась там на четыре года. Это было в 2014 году. В стране кризис, я только-только выпустилась из университета, искала работу по специальности и параллельно подрабатывала моделью. В этот момент меня пригласили на кастинг в иностранный кинопроект. До этого в кино я никогда не снималась, только в рекламе. Но я успешно прошла кастинг и улетела на съемки в Турцию. Проект снимала европейская кинокомпания, а организовывала всё турецкая компания-подрядчик. В первый же съемочный день мы по вине турков ушли в большую переработку, а каждый час переработки стоит немалых денег. Это был не первый и не последний косяк со стороны организаторов.

Я подумала, что могла бы в Украине за те же деньги и даже меньше организовать съемки в сто раз лучше, и начала активно продвигать эту идею. Рассказала о том, что в Украине часто снимают международные проекты, что у нас классные специалисты и полно крутых локаций для съемок. Так я получила нашего первого клиента и стартанула бизнес. Вместе с мужем Денисом мы основали продакшн-студию и успешно занимались её развитием. Мы делали большие проекты один за одним, появлялись новые клиенты, доход мы получали в валюте. И через год мы смогли купить свою первую квартиру. Инвестировали на этапе строительства, выгребли все деньги под ноль и вложили их в котлован. Потом не заметили, как заработали и на вторую квартиру.

В 2016 году наш основной иностранный заказчик разошелся со своим партнёром и начал с нуля строить собственную компанию. От него перестали поступать заказы. Мы бросились искать новых клиентов. Больше полугода выстраивали отношения с одним рекламным агентством. Удача была близко — агентство хотело заключить с нами контракт на год, но сделка сорвалась в последний момент. Меня накрыло эмоциональным выгоранием. В начале 2017 года мы с Денисом уволили сотрудников и рванули в Таиланд на зимовку. Планировали отдохнуть и с новыми силами взяться за поиск клиентов. Мы перезагрузились, все обдумали и прилетели обратно в Киев с четким намерением вернуться к работе, но не тут-то было. Я по-прежнему не испытывала к ней никакого интереса. Такое чувство, что кто-то просто отключил во мне эту функцию.

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

С мужем Денисом

Обучение в 42 school и переезд в США

Школа программирования 42 school была основана в 2013 году в Париже на спонсорские деньги миллиардера Ксавье Ньеля (сколотил состояние на телекоме, 232-еместо в мировом списке Forbes). У него самого не было высшего образования, а программирование он изучал самостоятельно. Методика обучения основана на принципах peer-to-peer педагогики: в школе отсутствуют преподаватели, студенты оценивают проекты других студентов и помогают друг другу. Нет никаких теоретических занятий, только самостоятельное изучение и практика. В школе свободный график, она открыта семь дней в неделю круглосуточно.

Обучение бесплатное, специальных требований для поступления нет, учиться здесь может кто угодно старше 18 лет. Программа школы рассчитана на срок от трех до пяти лет (в разных кампусах могут быть свои особенности). По франшизе 42 school открылись школы во многих странах, в Киеве по этой модели работает UNIT Factory. Чтобы поступить в эту школу, сначала нужно пройти онлайн-тест на память и логику, а потом выдержать испытание «бассейном» (pool) — так называются четыре недели интенсивного обучения языку С. Каждый день по будням студенты получают задания, которые нужно выполнять самостоятельно, а по выходным — работа над групповыми проектами в режиме rush (спешка, гонка). В принципе, весь «бассейн» проходит в такой спешке, потому что за две недели нужно с нуля освоить абсолютно новую технологию, и гугл — чуть ли не единственный, кто может тебе помочь. Можно, конечно, дернуть ещё соседа справа или слева от тебя, но здесь — как повезет. Возможно, ему самому понадобится твоя помощь.

Для меня испытательный срок оказался очень сложным, так как я не была готова, что абсолютно всю информацию нужно искать самостоятельно, теорию никто не разжевывал, а никаких технических знаний у меня не было. К тому же существовало ограничение по времени, так как за месяц нам нужно было освоить огромный массив информации, эквивалентный, наверное, семестру в университете. В моем наборе было 500 человек, до конца «бассейна» дошло около 200, и где-то 100 продолжили учиться дальше. После выигрыша грин-карты мы год проучились в UNIT Factory, а потом школа помогла нам перевестись в официальный филиал 42 school во Фримонте в Кремниевой долине.

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

Поиски стажировки

За три года обучения в нашей школе каждый студент должен пройти две стажировки. Они являются обязательными и засчитываются как отдельные проекты в системе. Закрыв дедлайн за первый год, мы получили возможность выйти на первую стажировку. У нас было около полугода, чтобы найти себе стажировку в Долине. Вскоре после переезда в школе объявили о начале сотрудничества с Tesla. Всю неделю, включая выходные, у нас были практические занятия по подготовке к интервью. Потом мы проходили тестовое интервью в школе, по результатам которого были оглашены списки тех, кто попадет на онсайт-интервью с Tesla. Нас с Денисом в этих списках не оказалось. На самом деле, этот результат был ожидаем. Уже с первых занятий стало понятно, что мы просто-напросто не были готовы к подобного рода интервью. Недостаточно знаний по алгоритмам, а главное — недостаточно практики быстрого решения алгоритмических задач. Хорошо, что у нас была возможность поучаствовать в подготовке к интервью, потому что мы посмотрели, как проходят технические собеседования в США, и поняли, чего ожидать и к чему готовиться. Мы трезво оценили себя и свои знания, поняли, где наши слабые стороны и какие пробелы нам нужно закрыть.

Через несколько месяцев после неудавшейся подачи в Tesla я подалась на стажировку по Android-разработке в компанию Pandora — это крупнейший музыкальный стриминговый сервис в США с более 70 млн пользователей. До этого я не знала ни Java, ни Android и всё учила с нуля. Первые два этапа отбора представляли собой онлайн-тесты на платформе HackerRank. Первый тест на 30 минут состоял из 10 вопросов по Java, а второй на два часа — из восьми вопросов по основам Android-разработки и двух задачек по алгоритмам на Java. Тесты я сдала так себе, Java учила в экстренном режиме, успела пройти только треть курса онлайн на Udemy, а в Android-разработке вообще не разбиралась, так что приходилось гуглить. Помимо тестов, нужно было написать еще три коротких эссе, и они, как мне кажется, сыграли ключевую роль в моей заявке. Первое эссе касалось дизайн-паттернов. Весь год я кодила на C и только недавно начала изучать объектно-ориентированное программирование, соответственно, я не могла похвастаться большим опытом использования дизайн-паттернов и решила написать как есть. Во втором эссе нужно было рассказать, как вы мотивируете себя к учебе, с какими трудностями сталкиваетесь и как их преодолеваете. А в третьем — ответить на вопрос, как и почему вы решили стать программистом.

Я упаковала весь свой опыт и постаралась раскрыть свою личность через эти эссе, и это сработало: меня пригласили на финальное онсайт собеседование. За неделю до онсайта я получила тестовое задание — написать приложение под Android, которое должно было отвечать определенным требованиям. Всю неделю я буквально не спала ночами. До этого я никогда не писала под Android, и сейчас передо мной стала задача за неделю освоить новую технологию и параллельно написать далеко не простенькое приложение. Но, к сожалению, невозможно объять необъятное. Мое тестовое не впечатлило компанию Pandora, и мне отказали. Я была морально раздавлена. Очень сложно месяцами работать в режиме нон-стоп и не видеть никакого результата. Честно говоря, я сама удивляюсь, как всё это выдержала.

В апреле 2019 года у нас в школе проводился хакатон от компании Samsung, посвящённый их голосовому ассистенту Bixby. Администрация школы намекнула, что компания готова взять наших студентов на стажировку. Несмотря на жуткую усталость после двух месяцев подачи в Pandora, которая не увенчалась успехом, я решила участвовать. В течение недели мы с командой трудились над приложением для Bixby, которое, по нашей задумке, должно было помогать пользователям изучать английский язык. Трудились, как позже выяснилось, не зря, потому что заняли второе место, и нас всех позвали на собеседование. Интервью проводилось у нас в школе и состояло из двух частей — технической и поведенческой. После онсайта мне предложили стажировку на три месяца, по 20 часов в неделю. Я стала интерном в отделе Bixby, который занимается связями со сторонними разработчиками. Samsung как раз тогда запускал Bixby Marketplace, что-то типа Apple Store, только для голосового ассистента. У сторонних разработчиков появилась возможность размещать там свои капсулы (так называются приложения для голосового ассистента), с помощью которых можно проверить состояние своего банковского счёта, забронировать отель или вызвать такси.

Первый месяц на стажировке мы с другими интернами делали ревью приложений, которые подавались на этот маркетплейс: тестировали их, смотрели, насколько они соответствуют требованиям, давали рекомендации, как их улучшить. Второй-третий месяц мы занимались тем, что усовершенствовали те приложения, которые нам присылали, дорабатывали какие-то фичи, а иногда и переписывали их с нуля. После этого я стала работать инжиниринг-менеджером 30 часов в неделю, сопровождая сторонних девелоперов в процессе разработки приложений, от момента появления идеи до код-ревью и релиза приложения на маркетплейсе. Бэкенд-капсулы пишутся на JavaScript, а логика и фронтенд — на Bixby Language. Что касается условий стажировки, то она была оплачиваемой, у меня была возможность частично работать из дому, а еще компания покрывала 50% расходов на питание в офисе.

Samsung Developer Conference

Стажировка в LinkedIn и дальнейшие планы

Изначально стажировка в Samsung была на три месяца, потом ее продлили еще на три, но какой-то определенности в том, что меня возьмут на фул-тайм, не было, а я хотела все-таки найти не контракт, а полноценную работу с бенефитами. Поэтому параллельно начала искать другие варианты. Сейчас у многих компаний (Microsoft, Twilio, Twitter, Dropbox) появились отдельные программы стажировок для тех, кто не соответствует стандартным требованиям, чтобы стать интерном (для этого нужно либо иметь степень бакалавра, либо учиться в аккредитованном вузе). Но существует очень много людей, которые заканчивают буткемпы, учатся онлайн или самостоятельно, или в такой школе, как я, то есть у них нет формального образования в компьютерных науках. Тем не менее, компании заинтересованы брать на работу разных людей, с неординарным бэкграундом, которые мыслят не шаблонно, как учили в университете, и могут показать новый подход к решению задач. Такая программа есть и в LinkedIn, называется REACH.

На нее могут податься люди, заинтересованные в инжиниринге, которые хотели бы получить опыт, необходимый, чтобы стать специалистом в таких направлениях, как Applications, Mobile, User Interface, Site Reliability или Artificial Intelligence. Подача заявок открывается только на один день, так как желающих очень много (в этот раз — 1200 аппликантов). Нужно было загрузить три эссе, в которых рассказать свою историю, о своем пути в программировании и описать какой-то реализованный проект так, чтобы человек, не видя твоего кода, мог составить представление о нем.

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

В итоге я получила офер на фул-тайм и вместе с еще 17 ребятами с декабря работаю и учусь в LinkedIn. Длительность программы, а также ее содержание определяются индивидуально, в зависимости от уровня соискателя. Это оценивает независимая компания, которой LinkedIn отправляет все документы для эвалюации опыта. Для меня программа будет длиться год — это минимальный срок. По прошествии этого времени я могу претендовать на повышение, но для этого нужно, чтобы мой уровень соответствовал тем требованиям, которые LinkedIn предъявляет к людям со степенью бакалавра.

Меня определили в команду Profile, я занимаюсь Android-разработкой. У меня есть ментор, который расписал для меня детальный план обучения, и один день в неделю я буду посвящать только учебе. Я очень довольна командой, в которую попала, и в целом атмосферой в компании. Ребята очень дружные, делают все, чтобы первые недели адаптации для новеньких прошли легко и непринужденно. Особенно меня впечатлило, насколько все разные, та самая diversity: среди моих коллег — люди десятка разных национальностей, и это очень круто и интересно. В LinkedIn у меня отличные условия, есть бенефиты, как у всех фул-тайм сотрудников, хорошая медицинская страховка и так далее. Эта стажировка позволила нам наконец-то съехать из общежития и снять квартиру недалеко от офиса.

Что касается моего мужа Дениса, то он с лета 2019 года занимается своим стартапом Postohub — это платформа для коммуникации компании с клиентом через email, мессенджеры, смс. Денис с командой начали работать над этим продуктом в ответ на запрос другого сервиса, с которым они должны были впоследствии интегрироваться. Но интеграция не состоялась, и ребята продолжили разрабатывать свой независимый продукт. За полгода работы команда Postohub разрослась до семи человек, и ребята получили $15 000 от Amazon на разворот инфраструктуры в AWS (Amazon Web Services). Если дела со стартапом пойдут в гору, то Amazon может увеличить эту сумму до $100 000.

Мне осталось учиться еще год, нужно оформить мою стажировку как проект и завершить его, тогда обучение будет считаться официально законченным. В UNIT Factory при поступлении ты подписываешь договор, по нему обучение в школе бесплатно при условии, что ты ее в итоге заканчиваешь, пройдя все этапы, выполнив все проекты, соблюдая дедлайны. Если же ты уходишь раньше или не выполняешь условия, то должен заплатить штраф. Я считаю, что это справедливо, так как украинская школа работает по франшизе и платит за доступ каждого студента к системе. Если ты не учишься, то возвращаешь, так сказать, потраченные на тебя деньги.

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

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

[Павел Обод — основатель Growth Factory — обучающей платформы для IT-предпринимателей, организатор конференции Outsource People, CEO Sloboda Studio — RoR agency]

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

1. Контроль затрат энергии

Есть такие таски, которые занимают не очень много времени, но требуют много энергии. Для меня это монотонная, рутинная работа, например, набирать текст. Она утомляет, хотя мозг в процессе почти отключается.

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

Учитывайте энергетические затраты на задачи в своем плане на день. Для продуманного распределения своих запасов энергии можно планировать жизнь на 5–6недель вперед. Так, чтобы в это время обязательно были вещи, которые вас заряжают, даже самые простые. Например, побыть наедине с собой, отдохнуть, куда-то съездить.

2. Так ли нужна многозадачность, как принято считать

Давайте сделаем небольшое упражнение.

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

Не верьте в многозадачность. Если вы делаете один таск — делайте только его. Кроме того, когда вы делаете один таск и получаете результат, вы радуетесь. Это тот самый отчасти медитативный процесс, творческий поток, когда вы глубоко погружаетесь в разработку или создаете концепт.

Люди очень легко отвлекаются. Во время работы над сложными задачами убирайте от себя соблазны — отключайте мессенджеры, уносите телефоны в другую комнату. Выделите себе дома «кресло без вайфая», сидя в котором вы обязуетесь не пользоваться интернетом. Когда я арендовал квартиру, то первый год не подключал интернет вообще. Мобильный интернет тогда был дорогим и медленным. И это было круто: вернувшись домой, я мог углубиться в важные, интересные задачи.

По отношению к отвлекающим факторам предлагаю делить задачи так:

• Коммуникации и мелкие задачи: мессенджеры и прочее — ок.
• Сложные задачи: отключайте мессенджеры, а в хард-моде — и телефон.

3. Принцип лягушки

Это классика тайм-менеджмента, поэтому простите, если вы уже знакомы с таким подходом.

Часто у нас бывают неприятные задачи, которые не хочется делать, — условная лягушка, которую надо съесть. Идея подхода в том, что нужно начинать день именно с нее. Так вы получаете несколько выигрышей:

• задача-лягушка потом не будет квакать и напоминать о себе;
• вы будете чувствовать себя победителем, знать, что вы молодец и смогли съесть лягушку.

4. Метод прогрессивного джипега

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

Смысл метода — не стараться сделать каждую часть задачи идеальной до перехода к следующей. Вначале вы делаете все как-нибудь, а потом постепенно улучшаете. И даже если не хватит времени закончить, у вас в любой момент будет готовая версия, просто определенного качества. То есть лучше сделать 100% задачи с качеством 2 из 10, чем сделать задачу на 20%. Лучше пусть у вас будет машина, которая плохо едет, чем только идеальный руль. Подход может быть удобным, когда вы составляете договор, пишете концепт или даже разрабатываете софт. Собственно, это MVP (minimum viable product) любой задачи.

Иногда не знаешь, как сделать хорошо, а плохо делать не хочется, потому что потом будет стыдно перед собой и другими. Или боишься, что вообще не сможешь сделать. В итоге прокрастинируешь и совсем не делаешь нужную задачу. В этом случае надо сказать себе: «Ну давай сделаем максимально плохо. Сделай самый ужасный договор, какой только можно». По собственному и чужому опыту знаю, что даже создание нового документа с нужным названием помогает начать работу и получить исходную версию. В 99% случаев потом вам захочется улучшить MVP.

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

Такой подход нужен, когда у нас ограничено время, или вы не знаете, сколько времени займет задача, или когда задача может занять значительно больше времени, чем запланировано. Бывают случаи, когда результаты непропорциональны затраченному времени. Например, 1 час уходит на то, чтобы сделать задачу с 80-процентнымкачеством, а потом еще 4 часа на то, чтобы сделать 100%. В таком случае часто можно пойти на компромисс и не делать задачу на 100%.

5. Правило Чехова, оно же правило паровоза

Когда у Чехова спросили: «Антон Павлович, а как вы себя заставляете писать?» — он ответил, что просто берет ручку и начинает писать то, что приходит в голову: «Вот что-то не хочется писать. А писать-то и надо. Надо бы и героя обрисовать, внешность ему сделать». Начав записывать свои мысли, он постепенно вовлекается в процесс и делает что-то полезное.

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

6. Правило 2 минут

На мой взгляд, несколько спорная, но все же рабочая идея. Логика тут такова: если вам нужно что-то сделать и это займет меньше 2 минут, лучше сделать это сразу. Потому что иначе вам придется записать задачу или держать ее в голове, постоянно к ней возвращаться и потом все-таки делать, в итоге потратив гораздо больше 2 минут.

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

7. Метод виноградинки

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

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

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

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

8. Сколько стоит ваш час

Посчитайте, сколько вы заработали денег за прошлый квартал. Можно очень приблизительно. А теперь разделите эту сумму на среднее количество отработанных часов. При 40-часовойрабочей неделе месяц — 168 часов, квартал — 504 часа.

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

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

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

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

Мои подходы к работе с ассистентом:

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

9. Принцип слона, или Искусство маленьких шагов

Основа принципа — «Молитва» Экзюпери об искусстве маленьких шагов. Ее идея в том, что мы часто хотим получить все быстро, а нужно регулярно и постепенно двигаться к результату. Меня сейчас расстраивает мой медленный прогресс в немецком, а когда-то огорчал медленный прогресс в английском. Но я понимаю, что шаг за шагом я иду к хорошему уровню. Не всегда развитие стремительное. За историями о one night success очень часто стоят многие часы труда.

Как съесть слона? По маленькому кусочку. Многие сложные вещи нужно просто резать на кусочки и делить на части.

10. Метод стрелы

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

Я выступаю наконечником стрелы, делаю небольшую, но самую важную часть работы, а менеджеры — как древко стрелы — выполняют остальное. Не нужно брать на себя все, но и не стоит отправлять своих сотрудников делать работу с пустым древком.

Итог

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

Удачи в выполнении ваших задач!

Віта Ткаченко стала айтішницею, коли ще й слова такого не існувало — на гірничо-збагачувальному комбінаті у Горішніх Плавнях на Полтавщині її посада офіційно звалася електромеханік з обслуговування обчислювальної техніки. Прийшла на роботу у 1985-му —і це місце праці стало її єдиним записом у трудовій книжці аж до звільнення кілька років тому. Комбінат, а разом із ним і Віта, переживали періоди злетів та спадів, розрухи у 90-х,дальшого відродження у 2000-хта відтоку кадрів через міграцію останніми роками.

Багато причин тримали жінку на одній роботі все життя: і неписані правила тодішнього суспільного укладу, і мізерні альтернативи іншого місця праці, але чи не найбільше — страх випасти з квартирної черги. Помешкання зрештою отримали аж у 2001-му.А кілька років тому жінка звільнилася, щоб переїхати разом із чоловіком у Клавдієво під Києвом. Тримає город біля дому, де садить тюльпани і малину, бере участь у громадському житті селища, подорожує світом. Двоє її дітей також стали програмістами — і, за спостереженнями жінки, сьогодні в цій професії значно комфортніше, ніж їй 35 років тому. Історія Віти — про те, як їй працювалося айтішницею у 80-хроках минулого століття, коли робочим інструментом був громіздкий ЕОМ на весь кабінет, а найновішою довідковою літературою вважався «Windows для чайників».

Віта Ткаченко, 2019 рік

І. «Буду вінегретиком». Студентка

Дев’ятимісячним немовлям Віта з батьками переїхала з Кіровоградської області до тодішнього Комсомольська на Полтавщині, теперішніх Горішніх Плавнів. Батько, гірський механік із освітою Київського політеху, отримав туди скерування на комсомольське будівництво. Став головним енергетиком на комбінаті. Для малої Віти тато був неабияким авторитетом. Не в змозі до ладу вимовити назву професії, повторювала: «Буду, як тато, вінегретиком». Допомагала йому лагодити телевізори, змалку знала, що таке діоди, а що таке — тріоди, вміла міняти лампочки. Зі школи приносила відмінні оцінки. Коли Віці було 15, батька перевели до новоствореного відділу автоматичних систем управління — у 1974-мукомбінат переходив на цикл повного виробництва і розширював збут не лише на країни тодішньої соціалістичної співдружності, а й на Австрію та Німеччину. Через Дніпро, що тече поруч, дешевше (порівняно з гігантом-конкурентом у Кривому Розі) обходилося переправляти продукцію. Одного дня Віта прийшла до батька на роботу — там саме укладали угоди з представниками американської та німецької фірм. Той день — дотепер один із найяскравіших спогадів жінки.

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

Тож коли в 1977 році закінчила школу, не вагалася, куди вступати. Спакувала пожитки і переїхала — стала студенткою інженерно-фізичного факультету Харківського політехнічного інституту за спеціальністю «Автоматизовані системи управління виробництвом». Розмаїття факультетів — не рівня теперішньому. З майбутнім чоловіком, який стане електронником на тому ж заводі, вчилася на одному факультеті та спеціальності, тільки групи відрізнялися.

Згадуючи студентські роки, Віта описує навчання як суцільне домінування математики (аналітична алгебра, теорія диференційних рівнянь, вища математика, булева алгебра), засилля теорії, відсутність будь-якої навчальної практики, окрім хіба збирання картоплі на сільськогосподарських угіддях. Програмування, згадує жінка, було вдосталь. Із третього курсу розпочався поділ на кафедральні предмети. Вивчали методи оптимізації систем, алгоритми, трохи радіоелектроніки. Професор, завідувач кафедри, де вчилася Віта, розробляв штучний інтелект, — відтак студенти вчили цю дисципліну. Втім, як згадує жінка, вимоги його не вирізнялися особливою суворістю: уже за те, що студент правильно вимовляв його вірменське ім’я, по батькові і прізвище, можна було отримати тверду трійку. Під керівництвом цього професора Віта писала й курсову: тема — оптимізація навчального плану на їхній спеціальності. Переважно всі курсові, які писали студенти, передбачали багато математичного підґрунтя. Курсову захистила, утім, англійської, звучання якої захопило ще школяркою, в інституті не вивчила на такому рівні, як хотілося б. Попри те що англійська була в переліку дисциплін протягом чотирьох років, і курс Віки був першим, якому належало скласти іспит на четвертому курсі.

З англійською виникали курйози. Головним у вивченні вважалося скласти письмовий переклад — свою одну тисячу слів. Тексти для перекладу брали з газети «Московський комсомолець» — і студенти вдавалися до хитрощів. Якщо продавчині у кіоску протягнути у віконечко замість трьох копійок (вартість англомовного примірника) п’ять, то вона видавала ще й російськомовну версію, з якої і переписували переклад.

Загалом же, каже Віта, вивчення англійської зосереджувалося на перекладі та правописі — відтак і досі їй важче сприймати цю іноземну на слух, досі в усному мовленні може проскочити «де-ле-те» (delete). Зате впевнена, що не помилиться в написанні терміну. Особливості навчання у 80-хроках — без ґуґлу, заради одного слова слід розгортати словник — натренували зорову пам’ять.
Уже згодом, коли Віта потрапить на своє перше і єдине робоче місце, продовжуватиме вчити англійську самостійно — вся література, що стосувалася роботи систем, була цією мовою. На робочому столі Віта покладе товстий словник — термінологія з нього підказуватиме про помилки в коді.

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

Віта Ткаченко (в центрі) на університетській практиці на картоплі, 1982 рік

ІІ. «Windows для чайників». Робота

За щасливим збігом обставин, Віті вдалося уникнути однієї особливості радянської вищої освіти — направлення на роботу, обов’язкового трирічного відпрацювання «молодого спеціаліста» у місці, куди скерує інститут. Вона точно знала, що повертатиметься на комбінат, писала при ньому курсову та дипломну (про оптимізацію транспортних потоків) роботу. У цьому випадку єдиною перевагою для її однокурсників було те, що їм не загрожувало направлення до віддалених сіл або містечок — наявністю перших комп’ютерів могли похизуватися банки і підприємства лише у великих містах. Минуть роки — і більшість однокурсників Віти, які мали таку тодішню перевагу, як комп’ютер на робочому місці, повиростають у банкірів та бухгалтерів. А поки ж вона, чи не єдина зі свого випуску, влаштовується програмісткою на виробництві — відразу після дипломної практики у 1984 році.

Жінка прийшла працювати до відділу АСУ (автоматизованих систем управління), який налічував 10 тисяч робітників і десятки цехів. Перші чотири роки обіймала рядову робочу посаду, числилася в штаті електромеханіком з ремонту обчислювальної техніки. Її робочим місцем був кабінет із громіздким ЕОМ, першим комп’ютером — між собою їх жартома називали холодильними шафами. Виникли взаємопов’язані складнощі: по-перше, все доводилося вивчати заново, по-друге, вивчати було особливо ні з чого.

На Віту чекала позмінна робота, в тому числі і нічна — технологічний процес безперервний. Чотири дні — із сьомої ранку до третьої по обіді, наступні чотири дні — з 15:00 до 23:00, а тоді ще чотири — з 23:00 до 7:00. Коли ж пізніше перейшла в інженери-програмісти, графік унормувався: типова п’ятиденка з 8:00 до 17:00. У службовій інструкції Віти значилося, що вона, як інженер третьої категорії, зобов’язана писати програми, вести бази даних, а також забезпечувати цілодобовий супровід необхідних програм. Віта пригадує: ледь не на руці собі записувала, що і за чим робити: заправити стрічку для лінійного запису, дочекатися завантаження, вивчити двійкове числення, щоб завантажити систему. Єдине, з чим було легше, — це зі статусом молодого спеціаліста: за законом, його не могли звільнити, натомість мали навчати і допомагати освоїтися на новому місці.

Перша зарплата Віти становила 130 рублів, приблизно стільки ж отримував і чоловік, який влаштувався на комбінаті електронником. Ця професія вважалася престижнішою, ніж програмування. Існував негласний поділ: чоловіки — електронники, жінки — програмісти. Про сексизм тоді мало хто говорив.

При середній зарплаті у 70 рублів заробітків подружжя вистачало на життя — хоча й, розповість Віта потім, без особливих розкошів. Спочатку з грішми допомагали батьки. Уперше її діти побачать море у десятирічному віці, і здивуються: у готельному люксі кожен має власну кімнату! (Подружжя житиме у батьків Віти, доки не переселиться до гуртожитку, а потім і до малосімейки). Пізніше платили і 200, і 300 — металургійна галузь передбачала доплати за шкідливість праці.

Невдовзі, за неповний рік роботи, Віта пішла в декрет, а коли через три роки повернулася, здивувалася: електронно-обчислювальні машини прибрали, замість них поставили «Роботрони» — і їй довелося опановувати нову техніку. Щоб освоїти персональний комп’ютер, мусила зайнятися самоосвітою. Книжки були дорогі — «Windows для чайників», що тоді сприймався як джерело таємної інформації, коштував більше, як середня зарплата: 80 рублів. Свій примірник Віта отримала в подарунок від сестри — вона мешкала в Києві і, покинувши програмування, яке теж вивчала в інституті, працювала бухгалтеркою. Уже пізніше домоглися, щоб до бібліотеки комбінату виписували тематичні журнали — хоча б один на відділ; чекаєш черги, щоб почитати, але бодай якась інформація.

Будівництво комбінату, 1970 рік

Хоч Віті і гарантувався соціальний пакет із законними лікарняними на період, коли діти хворіють, насправді все виявилося геть інакше. Телефонує, щоб попередити, що в дитини температура 39, натомість чує: «Коли це закінчиться? Хто працюватиме? Коли в моєї дружини були малі діти, вона звільнилася і вдома сиділа». Чоловікові тоді лікарняних не давали, а їй самій довелося наслухатися перед тим, як отримати належне звільнення. Тепер Віта каже про це: пресинг. Тоді просто зітхала, поклавши трубку.

Так само, коли сьогодні жінка чує від дочки Віри, тімліда в MacPaw, про регулярний перегляд посад і зарплат, мимоволі порівнює це зі своєю історією. У тодішньому середовищі такий підхід годі й уявити. Навіть якщо котрийсь інженер нічого не робив на своєму робочому місці, його неможливо було звільнити. Попри те що Вітин тато обіймав керівну посаду на виробництві, самій їй не світило стрімке просування кар’єрними сходами (він вийшов на пенсію за кілька років після того, як там почала працювати Віта). Спершу Віта крок за кроком здобувала все вищу і вищу категорію електромеханіка, доки не стала провідним фахівцем. Заради стрибка в професії довелося схитрувати. Віта знала, що її колега, інженер, планує звільнятися, оскільки виходить заміж. Коли вона зайшла до кабінету начальника з заявою про звільнення, Віта стояла поруч — щоб відразу попроситися на це місце, аргументуючи це чотирирічним робочим стажем. Спрацювало.

Що значило тоді бути інженером? До поділу на тестувальників, продакт-менеджерів та інших було як до неба рачки, і, каже Віта, їй доводилося бути «самій собі режисером», поєднуючи всі ці обов’язки. Ось, наприклад, приходить начальник і каже: «Потрібно зробити у відділі програму, щоб працівники рахували не на рахівниці». Аби впоратися з таким завданням, Віта спершу зо п’ять днів проводила з цими людьми, щоб зрозуміти, як влаштована їхня праця. Тоді сама для себе мала зробити постановку завдання. Потім — поміркувати: де взяти дані для цього? Окрім того, каже Віта, їй доводилося бути ще й психологом. Головна відмінність між тодішнім і теперішнім запровадженням автоматизованих програм полягає в тому, наскільки готовими до новацій є працівники.

— Коли тепер фірми запроваджують у себе певні системні продукти, роблять це з розрахунку, що всі відразу ними користуватимуться. Мені ж часто доводилося ще й умовляти непідготовлених людей почати користуватися програмою, — згадує жінка.

Щоб переконати, часто доводилося вдаватися до хитрощів. Зі слів Віти, рядові працівники замість радіти, що їхні робочі місця обладнали комп’ютерами, хвилювалися через це. Поширювалися чутки, наче тепер усіх позвільняють, тож ставилися до новацій із пересторогою.

— Я мала пояснити все простою мовою, зважаючи на те, що людина вперше у своєму житті працює з подібним. Уникати слів на зразок «файли», «директорії» тощо. Похвалити, коли вдавалося, аби заохотити людей. Може, це й неправильно — але діяло! Якось подзвонили серед ночі: не запускається система. Відповідаю: «Давайте перезапустимо». «А що робити?». «Ну ось, шукайте кнопку Power». «Нема такої кнопки, — чую. — Є тільки «Ровер». Так дійшли згоди, — згадує Віта.

Педагогічні здібності жінки, зокрема — її вміння знайти до кожного підхід та пояснити інформацію доступною мовою, сприяли тому, що її уповноважили читати курси при навчальному комбінаті, за що отримувала доплату. Цей додатковий обов’язок справно виконувала впродовж майже усієї своєї роботи. На курсах навчала інших працівників комп’ютерних програм. Колеги Віту любили — за те, що, вдаючись до мови своїх підопічних, вміла пояснити їм тему. Скажімо, машиністам вітряків — солідним чоловікам старшого віку — мала розтлумачити Excel. Замість пояснювати формули пропонувала змоделювати ситуацію: ось отримали ви зарплату, пішли на базар і маєте розподілити статті витрат. «Шабашка», «заначка», «на пропій» — такими термінами машиністи вітряків вивчали комп’ютерну грамоту.

Із 2000-хроків відділ автоматизованих систем перейменували в інформаційне управління, а вже коли Віта звільнялася, управління дістало нову назву — «Цех інформаційних технологій і зв’язку». З 2005-говона працювала провідним інженером-програмістом, дальшою кар’єрною сходинкою для неї могла б бути посада начальника бюро — але такі, стверджує Віта, діставалися переважно чоловікам.

Роки спливали, «Windows для чайників» незабаром припинить бути ексклюзивною інформацією з обмеженим доступом, у спину дихатимуть молодші випускники вишів, вони приходитимуть на комбінат і сипатимуть новими термінами. Професія програміста помолодшає, її частіше обиратимуть і хлопці, тоді як за часів Вітиного студентства не такий престижний фах був більше затребуваний дівчатами. Віта на якийсь час уже запише себе до «старої гвардії тіток-програмістів» і гадатиме: «Як же я у свої 55 буду програмувати? Мої старі знання нікому не потрібні». А потім передумає: вік — не головне, коли хочеться навчатися. Їздитиме на курси підвищення кваліфікації у Київський політех — Віта одна з небагатьох жінок, хто залишився на роботі, не злякавшись безгрошів’я, та дочекався такої форми освіти.

Та поки це все станеться, Віта переживе на комбінаті найдраматичніший його період.

Тодішня техніка: ЕС-1035, перший робочий комп’ютер Віки Ткаченко. Чоловік у центрі — її наречений

ІІІ. Черги і острах. 90-тіі 2000-ні

Й у Вітиному житті був період, коли думала: «Все, йду геть». Це трапилося в 90-х,коли після краху Союзу комбінат, доти градотворче підприємство, змушений був шукати нові ринки і мав труднощі у нових умовах. Гроші виплачували частинами і з боргами — саме тоді чоловік Віти залишив підприємство. Йому запропонували роботу у зовнішньоекономічному відділі фірми, яка при комбінаті продавала залізорудні окатиші за кордон — там, зокрема, стало у пригоді його знання комп’ютера.

Окрім гірської промисловості, ще однією візитівкою міста була швейна фабрика, яка теж зазнала краху в 90-х.Обладнання нишком рознесли по оселях і підпільно шили білизну вдома. Заради такого заробітку дехто лишав працю на заводі, прикинувши, що шиттям зможе заробити втричі більше. Комусь це вдавалося, комусь ні — бізнес, як і все життя навколо, був нестабільним.

Віта теж мала нагоду змінити професію. Тодішній знайомий чиновник мерії пропонував познайомити її з одним молодим бізнесменом, який хотів відкрити заклад із комп’ютерними іграми та відеосалон. Віта загорілася, але повернулася додому, розповіла новину мамі. Роздумавши, постановила, що не може кинути квартирної черги для працівників комбінату. (На обіцяне житло чекатимуть ще 20 років — і зрештою отримають його в 2001-му,їхнє помешкання — в останньому домі, де квартири працівникам давали безплатно. Теперішній власник комбінату Костянтин Жеваго побудує великий дім, квартири в якому продаватиме робітникам під безвідсотковий кредит на 25 років. А відколи його не виберуть на останніх виборах нардепом за мажоритаркою, місцеві вже не знають, чи чекати їм бодай такого).

Черга, пригадує Віта, мала якусь магічну силу над нею і тими, хто чекав із нею поруч. Усі, хто чекав на кооперативне житло, боялися якось себе знеславити: чи то зайвою пиятикою, чи зухвалою поведінкою — чим завгодно. Озираючись на той час, Віта називає його не інакше, як «незримим кріпосним правом». Тоді, з 1988-го,вона з родиною — чоловіком і двома дітьми — мешкала в однокімнатній квартирі, в будинку, зведеному для «молодих спеціалістів». Перед тим жили в гуртожитку: кімната на 12 квадратів із сидячою ванною.

Квартирна черга була вагомим, та не єдиним приводом для Віти не покидати роботи аж до пенсії. У маленькому місті з її програмістською спеціалізацією не так багато альтернативних робочих місць: хіба школа або технікум, але з меншою зарплатою. А тут — і стабільний заробіток, і відпускні, соцпакет. Та й стиль життя відрізнявся від, наприклад, столичного. Нині покійна молодша Вітина сестра мешкала тоді у Києві, програмування покинула, щоб стати бухгалтером. Вона легко змінювала робочі місця, коли Віта на це тільки закочувала очі (мовляв, як так: залишати роботу, коли іншої ще не знайшла), і вміла визначати вартість своїх фахових знань. Віта ж каже: «У нас, у маленьких містах, панувала подоба рабовласницького ладу в умовах розвинутого соціалізму». Єдиною нагодою дістати підвищення для неї було дочекатися, коли звільниться хтось на її ділянці (як трапилося свого часу з колегою-інженером). Іноді доводилося працювати за трьох, але на всі спроби суперечити знаходився один аргумент: «Черга охочих на її місце — за парканом».

Комбінат вистояв і в найскрутніші 90-ті —якщо сусідні у Кривому Розі чи Жовтих Водах закрилися, то у тодішньому Комсомольському робота не припинялася ні на день. Значною мірою — завдяки налагодженій співпраці з Австрією, Німеччиною, Бразилією та іншими країнами за межами соціалістичного табору.

Згодом комбінат викупив його нинішній власник Костянтин Жеваго. Ще наприкінці 2000-х,згадує Віта, працівники непогано заробляли, та згодом знайшли для себе кращі альтернативи. На аналогічній роботі за кордоном заробляли у кілька разів більше — і масово мігрували здебільшого представники робітничих професій, водії.

Коли три роки тому Віта наважилася написати заяву на звільнення, стіни підприємства прикрашали рекламні плакати: «Приведи друга — отримай 500 гривень». Жінка каже: для неї той текст прозвучав як пісня без слів.

Уперше в житті Віта Ткаченко наважилася звільнитися з роботи, щоб присвятити час собі, сім’ї, власним хобі, подорожам та давнім мріям.

ІV. «Дівчинка на пенсії». Життя сьогодні: англійська, подорожі, квіти

На той час Вітині діти вже міцно стояли на ногах, та й сестра переконувала: на схилі років варто пожити разом. Чоловік Віти вже на пенсії, відтак тільки їй залишалося кинути роботу. Гуртом придбали дім у Клавдієво, де оселилися разом із сестрою. Родички не стало після хвороби, Віта згадує її з неабияким теплом: вона придбала перший комп’ютер для її старшого сина, коли ця техніка все ще здавалася чимось захмарним, вона підтримувала її дітей, коли ті поїхали вчитися до Києва.

Віта міркує: напевно, це професія наклала свій відбиток: постійно бути в русі, прагнути дізнаватися щось нове. Ще на Полтавщині, коли діти роз’їхалися по інститутах, жінка, що звикла ставити їхні справи на перше місце, що була їм найкращим другом і залюбки проводила з ними час на прогулянках та у походах, відчула порожнечу на душі. Сидіти перед телевізором вечорами — не її вибір. Так Віта опинилася на східних танцях.

Нині називає себе «дівчинкою на пенсії». У Клавдієво теж створила свою зону активності. Щойно переїхали, запросили до себе пожити на пів року американського волонтера з Корпусу миру. Грейсон святкував із ними Різдво, разом ходили колядувати з вертепом, запікали індичку і місили пиріг — відтворювали святкову американську вечерю. З його допомогою підтягнули і англійську мову, він натомість вчив російську.

Віта є членом громадської ради своїх односельчан — такий собі громадський контроль за діяльністю місцевої влади. Доглядає 23 сотки городу біля свого обійстя, висаджує на них городину, квіти і малину, тримає трьох котів, собаку, ще й десять курок у господарстві. Активно подорожує світом, ходить на концерти — її сторінка у фейсбуцітеж живе насиченим життям. Має змогу часто бачити дітей та онука. П’ятирічний Адам у своєму віці вже вчить англійську і математику — може, стане програмістом, як його тато та бабуся з дідусем.

Цього разу DOU Ревізорзавітав до львівського офісу Elitex. Головний фокус аутсорсингової компанії спрямований на JavaScript-розробку, проте також команда має справу з технологіями Java, Python та .NET. Компанія працює з клієнтами з США, Великої Британії, Європи, Ізраїлю та Сінгапуру.

Компанія заснована у 2015 році та зареєстрована у Британії, а єдиний офіс розробки знаходиться у Львові. Команда налічує 45 осіб, 30 з них — технічні спеціалісти. Найбільше в команді senior-позицій, трохи менше middle-, а найменше — junior-спеціалістів.

В околицях і поблизу

Уже два роки офіс Elitex знаходиться за адресою вулиця Городоцька, 2 навпроти Львівського оперного театру.

Оскільки офіс розташовано в історичному центрі міста, команда має можливість обирати місце для обіду з вичерпного переліку закладів поблизу. Популярністю користуються паби «Феркель», де чек обійдеться у суму до 100 грн, та «Когут», у якому вартість бізнес-ланчу складає 89 грн. Також поруч знаходяться «Пузата хата», McDonald’s, Оpen, а ще фудкорт у ТЦ «Форум». Усіх закладів можна дістатися за п’ять хвилин пішої прогулянки. Тим не менш, спеціалісти регулярно замовляють доставку їжі до офісу.

Для тих фахівців, що дістаються до роботи громадським транспортом, розв’язка дуже зручна. Для власників авто компанія орендує чотири місця на паркуванні ТЦ «Магнус», що в двох хвилинах від офісу, також дві автівки можна розмістити у дворі біля будівлі. Безкоштовних місць вистачає не для всіх спеціалістів. Тож ті автомобілісти, що встигли зайняти місця, повідомляють про це у чаті. Ті, що не встигли, можуть залишити машину на платному паркувальному майданчику біля офісу за власні кошти (100 грн/день) або на паркуванні в п’яти хвилинах від офісу (5 грн/година).

Офісний побут

У будівлі працює охорона, що відкриває офіс для співробітника, який приходить раніше за всіх, та зачиняє після останнього. Щоб потрапити всередину, наприклад, на вихідних, необхідно зателефонувати та попередити охорону.

Рекомендовані години роботи в Elitex — з 10:00 до 19:00. Втім, усе залежить від проекту, а саме — від країни його замовника. Спеціалісти самостійно погоджують зручний час для синхронізації зі стороною клієнта. Дехто в компанії приходить о 8:00, дехто — о 12:00, жорсткої регуляції немає.

Спеціалістам надають 12 днів віддаленої роботи на рік зі 100% оплатою. Працювати віддалено можна і більше, але оплата додаткових днів складатиме 80%. Компанія також забезпечує 10 оплачуваних днів лікарняного на рік, кількість днів для опції «хворію, але працюю» вираховується окремо. При народженні дитини, весіллі, смерті близької людини спеціалісту надають два додаткових дні відпустки.

У компанії є маленька та велика кухні з усім необхідним, від кавоварок до посудомийок. Сміття в офісі не сортують, проте відмовилися від одноразового посуду та бутильованої води. Натомість шафи заповнили брендованими чашками та встановили фільтри.

В офісі є чотири переговорні кімнати та одна маленька кабінка для перемовин. Як зауважують спеціалісти компанії, на 45 осіб їх цілком вистачає. Бронюють кімнати стандартно через Google-календар.

Пульти управління вентиляцією розташовані у кожному спейсі. У коридорах та в кабінетах немає задухи, у робочих зонах та місцях для відпочинку встановили зволожувачі повітря. Підлога в офісі підігрівається, проте на початку робочого тижня дещо прохолодно, оскільки наразі вихідними опалення відключають.

Зона для куріння розташована на балконі, що веде у внутрішній дворик.

В Elitex спільні жіночі та чоловічі вбиральні, також є душова в офісі.

Робочий простір

Офіс займає один поверх та 468 м² площі. За даними компанії, кількість квадратних метрів на одну особу в робочому приміщенні складає близько 8,67.

Робочий простір реалізовано у форматі опенспейс. У найбільшій кімнаті працюють 19 спеціалістів. Бухгалтерія, рекрутери та відділ продажу і маркетингу мають свої окремі кабінети.

У просторі, що відкрили минулого літа, встановили панелі під стелею, які поглинають шум. Проте між цим простором та великою кухнею немає дверей, тож в обідній час працювати заважає гамір.

Робоче місце кожного спеціаліста передбачає стіл, крісло, тумбочку та необхідну техніку. Також на весь офіс є дві підставки для роботи стоячи. Спочатку планували, що вони будуть спільними, і спеціалісти, що схочуть попрацювати стоячи, просто до них підходитимуть. На практиці великого зацікавлення підставки не викликали і згодом осіли на конкретних місцях.

Перед виходом на роботу спеціаліст може обрати, якою технікою він користуватиметься. Стандартно надають iMac 27’ з Retina дисплеєм, також популярністю користуються MacBook Pro 13/15, ноутбуки Acer Swift 3, HP 250 G6. Також кожному фахівцю надається монітор, зазвичай iMac або Dell 23.8, навушники (JBL T500BT White або Sony WH-CH500) та мишка з клавіатурою.

Якщо спеціаліст має зауваження щодо техніки або іншого обладнання, він може замінити їх на інші. Обладнання замінюють того ж дня, за умови, що воно наявне на складі. Найчастіше залишають заявки на підставки під ноутбуки та адаптери.

Першого дня в компанії спеціаліст отримує welcome pack, що наразі складається з брендованих футболки, блокноту, ручки, стикерів, вітальної листівки, шоколаду та кубику Рубіка, в якого грані, окрім кольорів, відзначені назвами технологій.

Щомісяця у компанії виділяють Happy Budget — $200 на реалізацію ідей у офісному просторі. Голосуванням вирішують, що покращити цього разу у межах бюджету. Наприклад, влаштувати майстер-клас, купити нову гру на PlayStation, зволожувачі, соковижималку, барбекю, бутербродницю до офісу тощо. Пропозиції висувають самі члени команди.

Спеціалісти мають змогу скористатися профільною літературою в офісній бібліотеці або замовити її. Для цього треба залишити заявку HR-спеціалісту. Також можна залишати запити на відвідування курсів та конференцій. Їх розглядають в індивідуальному порядку і вирішують, компенсовувати витрати повністю, частково або відхилити заявку. У більшості випадків профільні курси та конференції компенсуються у 100% обсязі.

В межах менторської програми кожен охочий в Elitex може отримати ментора і розробити з ним PDP (personal development plan). Ментором виступає хтось зі спеціалістів компанії.

Відпочинок і натхнення

В офісі є дві основні зони для відпочинку. Перша знаходиться в залі біля ресепшену та невеликої кухні. Там можна пограти в кікер, настільні ігри або просто відпочити. Також раз на два тижні спеціалісти збираються в залі на кіновечори.

Поруч із залою у коридорі розмістили турнік. На внутрішньому хакатоні компанії з Internet of things його диджиталізували: додали датчики, що підраховували, скільки разів людина підтягнулася. Хакатон тривав кілька тижнів: учасники збиралися у команди, у межах певного бюджету закуповували датчики та все, що потрібно для проекту, у вільний час займалися розробкою. Завершився хакатон презентацією, визначенням та нагородженням переможців.

Друга зона відпочинку — велика кухня. Саме там щодня о 15:50 спеціалісти збираються та роблять планку, а раз на два тижні організовують внутрішні Tech Talks з лекціями на технічні та довільні теми. Наприклад, про досвід соло-походу в гори, правила бізнес-комунікації, React Native, GraphQL тощо. На кухні також розташований тенісний стіл, тож в Elitex грають щодня. Тому восени організували внутрішній турнір. На кухні зона зі сходами несе і функціональне навантаження: під сидіннями зберігають каремати, додаткові стільці тощо.

Окрім того, відпочити можна на гамаках, кріслах, диванчиках, що розміщені в опенспейсі.

В останній четвер місяця команда Elitex збирається на кухні на Happy Thursday. Це невелика вечірка з випивкою та частуванням, де вітають новачків та підбивають підсумки Happy Budget. На день народження спеціаліста влаштовують привітання, збирається вся команда, а іменинник отримує презент, зазвичай солодкий. У компанії відзначають літні та зимові корпоративи, часто виїздом на природу.

Спеціалісти можуть займатися англійською мовою тричі на тиждень з україномовним викладачем граматики та тричі на тиждень відвідувати розмовний клуб із носієм мови з Великобританії. Тривалість кожного заняття — одна година.

В Elitex є кімната для відпочинку з PlayStation 4 та масажним кріслом. Влітку до зон відпочинку додається ще й тераса. На балкон виносять багато рослин, а іноді на ньому влаштовують барбекю.

DOU Ревізор запитує

Ми провели анонімне опитування серед команди Elitex, у якому взяли участь 65% фахівців львівського офісу, з них 63% — технічні спеціалісти. Ми поцікавилися, чи задоволені вони офісом, і попросили оцінити за п’ятибальною шкалою певні характеристики: розміщення, графік і офісний простір.

Розміщення офісу отримало середній бал 4,78, хоча 94% спеціалістів оцінили характеристику на п’ятірки та четвірки. Високі оцінки отримали такі характеристики, як графік роботи та стан периферійних пристроїв, — по 4,84 бали. Робочому комп’ютеру дали найвищу оцінку — 4,91 з 5 балів.

Хоча в кожному просторі є регулятор температури та зволожувачі, вентиляцію оцінили лише у 4,63 бали. Можливість віддаленої роботи отримала оцінку 4,19, а офісне паркування показало найнижчий результат у 3,69 бали. При цьому 53% нічого не хотіли б змінювати.

Серед пропозицій до покращення: прибрати шум, додати більше місць для паркування, посилити освітлення.

За традицією, ми поспілкувалися зі спеціалістами особисто й поставили два нескладних запитання: що їм найбільше подобається в офісі та що хотілося б поліпшити або змінити.

Андрій, JavaScript developer, 1,5 роки з компанією

Інна, QA Engineer, 1 рік з компанією

Рома, Front-End developer, 1,5 роки з компанією

Андрій, Senior Manual QA, 1 рік з компанією

Ну що, ми рушаємо далі... А якщо ви хочете, аби DOU Ревізор завітав до вас, пишіть: revisor@dou.ua

Ми катаємося по Україні в пошуках найкреативніших та нестандартних офісів ІТ-компаній. Разом з нами ви зможете зазирнути за лаштунки офісного життя. Але вирішувати, гарний це офіс чи ні, будете тільки ви!

Стежте за нами у Facebook.

Підписуйтесь на відеоканал DOU Ревізора на YouTube.

Фотограф: Євгеній Щегольський

Всім привіт! Мене звати Дмитро, я працюю AQA інженером в компанії Intellias на automotive проєкті. У цій статті я хочу розказати про технології комп’ютерного зору, які допомогли вирішити багато складних задач у тестуванні UI автомобільної навігаційної системи.

У першій частині ми розглянемо деякі алгоритми порівняння зображень та познайомимося з теорією Computer Vision. У другій частині перейдемо до реалізації скриптів для пошуку об’єктів на зображеннях та інтегруємо їх у тестовий фреймворк. Для прикладів будемо використовувати Google Maps — відомий додаток з простим функціоналом, на якому можна показати всі складнощі автоматизації навігаційної системи.

У статті наведені деякі приклади коду, проте їх ціль більше демонстративна, ніж практична. Посилання на програмне рішення з повним описом його встановлення та роботи буде доступне у кінці другої частини.

Базові методи роботи із зображеннями в OpenCV, такі як: читання з файлу, збереження, малювання фігур тощо, виходять за рамки цієї статті, однак ви можете ознайомитися з ними туті ось тут.

Проблематика

Зазвичай в аплікаціях UI елементи описуються мовою розмітки (HTML чи XML) у поєднанні з таблицею стилів. У цьому випадку тестування UI зводиться до пошуку елементу в розмітці і перевірці його характеристик. За необхідності можемо емулювати дії користувача, щоб автоматизувати сценарії та різноманітні user flow. Для кожної платформи (веб, мобайл, десктоп) існує достатньо інструментів, які дозволяють організувати автоматизоване тестування (Webdriver, Appium, Ranorex тощо). Вибір того чи іншого фреймворку часто залежить від уподобань і досвіду спеціаліста, який відповідає за автоматизацію на проєкті.

Кнопка «Restaurants» у додатку Google Maps — гарний приклад елементу, який легко знайти в горстці та отримати вичерпну інформацію про розмір, колір, розміщення на екрані, статус та інші характеристики. Але бувають UI елементи, які представлені не за допомогою горстки, а іншим способом. Анімація, мапа, об’єкти на мапі, різноманітні діаграми і графіки не доступні в HTML/XML. Автоматизувати перевірку цих елементів досить важко — вибір інструментів невеликий i більшість з них розповсюджується на платній основі.

Усі елементи мапи Google (міста, вулиці, площі, будинки, ріки, мости і т.д.) «намальовані» всередині елементу canvas. Очевидно, що інформації, отриманої з горстки, недостатньо навіть для простого тесту отриманої локації на мапі.

Кнопка Restaurants і мапа в HTML Google Maps

У навігаційній системі намальованих функціональних елементів ще більше, ніж у мапі. Тут є позиція машини, активний маршрут, проміжні точки руху, кінцева зупинка, іконки маневрів, іконки локацій, схеми заторів, відстані і т.д. Щоб перевірити правильність відображення цих елементів необхідно працювати безпосередньо з зображенням (картинкою).

UI типової навігаційної системи

Найпростішим рішенням, що дозволяє перевірити наявність чи відсутність елементу на картинці, є повне або часткове порівняння скріншоту додатку з еталонною картинкою. За допомогою цього методу можна досягти надійних результатів порівняння для тих елементів, які:

• не змінюють свого положення на екрані, тобто відображаються статично;
• не спотворені іншими елементами.

В тестовому методі можна вказати координати фрагменту, яким буде виділено цікавий для нас малюнок, і вже його порівнювати з еталонним зображенням. Очевидно, що з різних причин — артефакти рендеренгу, перекриття елементів, зображення елементів з різних точок спостереження тощо, одні і ті ж елементи на різних скріншотах будуть зображені по-різному, тому 100% збіг картинок малоімовірний.

Порівняння зображень за допомогою pHash

Існує багато інструментів, які дозволяють порівняти картинки з допустимим рівнем спотворень. Наприклад, для Ruby — це Imatcher, RMagick, Vips тощо. На проєкті ми використовували pHash — популярну бібліотеку, доступну для різних платформ. Демо pHash можна переглянути онлайн.

Наприклад, ми хочемо порівняти дві картинки: еталонну і картинку, на якій є шум. Алгоритм обчислює величину «hamming distance» в байтах, що фактично означає різницю між картинками. Також для даної картинки алгоритм робить прогнозний розрахунок порогового значення, на яке можна опиратися при прийнятті рішення — збігаються ці картинки чи ні. Для демо картинки з котиками ми отримали різницю в 12 байт і порогове значення в 26 байт. Таким чином система дає рекомендацію, що картинки ідентичні, бо різниця менша за порогове значення.

Демоверсія сайту з алгоритмом pHash

Ми використовували pHash у тестах позиціонування автомобіля — порівнювали ту частину екрану, яка містить current car position (на картинці нижче закрита чорним квадратом). Різні версії мапи та додатку, затори, інциденти на дорозі, нові заклади і т. д. призводили до появи додаткових спотворень: зміщення позиції напрямку руху, перекриття назви вулиці з іконкою машини тощо.

Ось приклад фрагментів екрану, які порівнюються в тесті. З правої сторони наведена різниця в байтах кожного фрагменту у порівнянні з першим. Бачимо, що різниця першої і другої картинки — 8 байт, першої і третьої — 17 байт, далі — 16, 14 та 6 байт. Тобто для тесту цієї локації, встановлення порогового значення у 20 байт забезпечує високу ймовірність проходження тесту, якщо на картинках правильна локація (помилка 2-городу — хибний fail — мінімальна). Так само цей поріг дає високу ймовірність, що картинки з іншою локацією не пройдуть тест (помилка 1-городу — хибний pass — мінімальна).

Різниця в байтах між фрагментами рисунків з однаковим положенням автомобіля на вулиці

Але в іншому тесті, де перевіряється функціонал збільшення (Zoom In test), вже зовсім інші цифри: haming distance від 0 до 27. Тобто, якщо встановити порогове значення на рівні 20, то у 2-мута 3-мутесті ми б отримали fail, хоча насправді Zoom In спрацював нормально (виникла помилка 2-городу).

Різниця в байтах між фрагментами рисунків з однаковим положенням автомобіля в разі збільшення (Zoom In)

Щоб зменшити ймовірність таких помилок, можна зберегти декілька еталонних зображень і використовувати їх, якщо попереднє порівняння було невдалим. У моїй практиці, для деяких локацій кількість зображень сягала 8-миштук. Таким чином, зменшується ймовірність помилки 2-городу (хибний fail), але збільшується ймовірність помилки 1-городу (хибний pass), бо одна із збережених еталонних картинок може збігтися з неправильною локацією.

Нижче наведені картинки з різними локаціями та haming distance при порівнянні їх між собою. Через те, що наша система має сіру тему оформлення (сірі будівлі, сірі вулиці), іноді результат порівняння зовсім різних картинок дорівнює 18 (менше за поріг у 20 байт). Порівнюючи 3-ймалюнок (повністю пусту вулицю) з 4-м (вулиця з написом), отримуємо 21, що дуже близько до порогового значення.

Різниця в байтах між фрагментами рисунків з різними положеннями автомобіля

Очевидно, що для перевірки правильності локацій даний метод не підходив. З написанням великої кількості тестів ми почали отримувати все більше хибних фейлів і все менше були впевнені в успішному проходженні тестів. Необхідно було знайти інший підхід, і ми звернулися до Computer Vision.

Computer Vision та OpenCV

Computer Vision — це технології та методи для виявлення, відстеження та класифікування об’єктів на зображенні. Однією з найпопулярніших бібліотек, в якій реалізовані алгоритми Computer Vision, є OpenCV. Існує реалізація на Python, С++ та інших мовах. Через зручність встановлення і написання скриптів ми будемо використовувати реалізацію на Python 2. OpenCV має широкі можливості у роботі з зображеннями — пошук об’єктів, сегментація, трекінг і т. д. Це «швейцарський ніж» у комп’ютерному зорі, однак, нас цікавить саме те, що допоможе нам у тестуванні. У 90% випадках тестування зображень нам допоможе метод Template Matching.

Метод Template Matching

Розглянемо роботу методу на прикладі. Нижче наведено картинку, на якій Мессі б’є по м’ячу. Припустимо, нам цікаво знайти місце, де зображено обличчя Мессі. Готуємо заздалегідь шаблон (темплейт) з обличчям — вирізаємо його з тієї ж самої картинки і зберігаємо. Цей метод рухає наш темплейт по кожному пікселю довжини і висоти, утворюючи скануюче віконце, в яке потрапляють фрагменти тестової картинки. Для кожного такого фрагмента обчислюється результат порівняння з темплейтом. Таким чином, на виході методу ми отримуємо монохромне зображення, в якому кожен піксель є результатом порівняння темплейта з фрагментом тестового зображення. Зображення, отримане в результаті, менше, ніж тестове, на висоту і ширину темплейту, оскільки крайніми пікселями порівняння виступатимуть ті точки, де темплейт доходить до границі тестового зображення.

Що нам дає це результуюче зображення? У тому місці (набір пікселів), де матчинг найкращий, картинка буде найсвітліша. Застосувавши фільтр, щоб знайти найсвітлішу точку, ми знайдемо положення найкращого матчингу.

Template Matching в Python реалізований через метод machTemplate модуля cv2, який приймає три параметри — тестове зображення, темплейт і назву алгоритму порівняння. На виході отримуємо набір пікселів, які формують результуюче зображення. Знайти положення та яскравість найсвітлішої та найтемнішої точки на результуючому зображенні можна за допомогою методу minMaxLoc.

Template Matching: шаблон, тестове зображення й підсумкове зображення

Існує три алгоритми матчингу темплейту. Деякі алгоритми результатом найкращого матчингу повертають найсвітлішу точку (TM_CCOEFF, TM_CCORR), деякі — найтемнішу (TM_SQDIFF). Їхня ефективність варіюється для різних категорій зображень, тому щоб отримати найкращий результат, їх треба підбирати. За замовчуванням використовується алгоритм TM_CCOEFF, який дає непогані результати для багатьох типів зображень.

Методи порівняння зображень

Також, для кожного алгоритму існує нормована версія, коли найкращий результат матчингу приводиться до значення від 0 до 1 (0% і 100% матчинг). Це зручно для прийняття рішення щодо якості матчингу. При ненормованому методі в найкращому місці матчингу яскравість пікселя буде довільної величини (скажімо 1428 одиниць). Цієї інформації недостатньо, щоб прийняти рішення. У випадку з нормованим методом ми знаємо, що 100% матчинг має результат, який дорівнює 1, і ми можемо ввести порогове значення (скажімо 0.8) для визначення прийнятного результату. Більш того, нормований метод допомагає при визначенні кількості об’єктів на картинці. Застосувавши фільтр, ми можемо вибрати ті точки, де результат вищий за порогове значення, і порахувати ці точки.

Наприклад, у нас є картинка з гри Супер Маріо і наша задача порахувати кількість монеток у підземеллі. Темплейт — це монетка. Застосовуємо метод, знаходимо найсвітліші точки, фільтруємо точки, де результат більший від порогового значення (0.8) і отримуємо позиції, де розташовані монетки.

Template Matching. Пошук декількох об’єктів

Template Matching — потужний інструмент, який дозволяє перевірити багато кейсів: знайти елемент на екрані, визначити його координати (щоб зробити клік), порахувати елементи на екрані, пересвідчитись, що елемента немає на екрані і т. д. Проте все ж є обмеження його використання. Як і в порівнянні картинок через pHash, Template Matching дуже чутливий до спотворень і перекриттів на зображеннях. Він чудово знайде іконки, кнопки, графічні позначки та інші елементи UI, але буде видавати помилки при роботі з локаціями і мапою, де є багато варіацій перекриттів назв вулиць, трафіку і додаткових об’єктів.

Наприклад, спробуємо перевірити правильність позиціонування адреси в Google Maps через Template Matching. Якщо ми введемо в пошук адресу офісу Intellias — «Intellias Kyrylivska 39», підготуємо з нього темплейт і спробуємо порівняти його із зображенням, на якому інша локація (інший офіс Intellias «Intellias Kyrylivska 15/1») , то ми отримаємо результат, вищий за порогове значення (0.85 при порозі 0.8). Тобто для алгоритму ці дві локації схожі з результатом 85%.

Template Matching у Google Maps

Очевидно, що Template Matching не підходить для перевірки локацій.

Пошук об’єктів на зображеннях зі спотворенням

У Computer Vision існує набір методів, які дозволяють організувати пошук об’єктів на мапі. Але для того, щоб зрозуміти як ними користуватися, необхідно трохи заглибитись в теорію, зокрема, згадати, як ми складаємо пазли.

Уявімо, що наша картинка — це великий пазл. Які частини пазлу складати найважче? Зазвичай, це частини, які створюють фон: небо, хмари, море, земля, стіни будинків і т.д. Щоб скласти таку чистину, потрібно багато шматочків пазлу, які мало відрізняються один від одного. На картинці знизу ці елементи позначені літерами A і В. Трохи легше складати картинку, де є переходи кольору або границі об’єктів. Вони мають прив’язку до горизонталі чи вертикалі (позначені літерами C і D). Тут вже можемо визначити, що С — лінія даху правої будівлі, а D — лівої. Але все ще залишається невизначеність, в якому саме місці мають бути ці частинки. Якщо ж подивитися на елементи E і F, то ми побачимо, що це кутики, які можна встановити тільки в одному місці на картинці. Ці кутики дають найбільше інформації про характеристики об’єкту.

Об’єкти на картинці, які ми описали (площини, границі і кутики), в Computer Vision називаються Features. Пошук цих об’єктів називається Feature Detection, а опис і знаходження їхніх характеристик — Feature Description.

Пошук та опис об’єктів на зображенні

Одна з найважливіших задач, яку треба вирішити при порівнянні об’єктів, — це пошук кутиків на картинках. Алгоритми, які займаються цим, називаються Corner Detectors. Чи не найперший алгоритм був описаний Крісом Харрісом у 1988-муроці. Він запропонував розбивати зображення на фрагменти і, рухаючи їх по горизонталі і вертикалі, порівнювати з сусідніми фрагментами. Спостерігаючи, як змінюються (чи не змінюються) характеристики, можна зробити висновок, що фрагмент містить плаский об’єкт (якщо характеристики не змінюються), границю (якщо характеристики різко змінюються при русі в одну із сторін) або кутик (якщо характеристики різко змінюються при русі в будь-яку зі сторін). На малюнку представлена модель алгоритму Гарріса.

Модель Гарріса

В OpenCV існує метод cornerHarris, який дозволяє знаходити кутики на картинці. В параметрах, крім зображення, він приймає коефіцієнти, які впливають на кількість і якість отриманих точок. В документації рекомендують почати з дефолтних значень і змінювати їх при потребі.

Детектор Гарріса в OpenCV

Наступним кроком після знаходження кутиків є обчислення їхніх характеристик. В алгоритмі SIFT (Scale-Invariant Feature Transform), описаному у 2004 році, Девід Лоу уточнив пошук кутиків за рахунок додаткових перевірок на різних масштабах зображення. При збільшенні виявляється, що кутик складається з кількох границь і точки перетину, яку нам і треба визначити якомога точніше. Також він запропонував розбивати фрагмент з кутиком на менші фрагменти (128 фрагментів) і обчислювати вектор збільшення яскравості для кожного з них. Таким чином, для кожної точки з кутиком обчислюється 128 бітове значення (дескриптор), яке використовується у порівнянні.

Обчислення дескрипторів у SIFT

На прикладі показано, як обчислюється дескриптор для кольорової і чорно-білої картинок. У разі кольорової картинки для кожного фрагменту вимірюється кут зміни кольору відповідно до кругової діаграми відтінків. При обчисленні чорно-білого дескриптора, береться до уваги напрямок і величина зміни яскравості фрагменту від темнішого до світлішого.

Обчислення дескрипторів для кольорового й чорно-білого зображень

В OpenCV алгоритм обчислення дескрипторів (а також точок з кутиками) реалізований через метод detectAndCompute об’єкту SIFT. За допомогою методу drawKeypoints можна позначити на картинці знайдені точки.

SIFT в OpenCV

Існує багато способів знайти кутики на картинці і обчислити їхні характеристики, але їх розгляд вимагає більшого заглиблення в теорію. Втім, приклади і алгоритми, які ми вже розглянули, дозволяють нам порівнювати не просто картинки, а об’єкти, зображені на картинках.

Feature Matching

Після того як ми знайшли ключові точки порівняння (кутики) і обчислили їх характеристики (дескриптори), можна переходити до їх порівняння. Існує два основних методи порівняння об’єктів — Cross Check та тест Девіда Лоу. Наприклад, ми маємо один і той самий трикутник, зображений на 2-хкартинках під різними кутами. Як відбувається порівняння? Припустимо, що різниця між дескрипторами обчислюється простим відніманням, і чим менша по модулю величина, тим більше точки подібні одна до одної. Тобто у 2-ходнакових точок різниця дорівнює 0.

У методі Cross Check ми обчислюємо різницю між кожною точкою першого зображення і кожною точкою другого, а потім обчислюємо різницю для кожної точки другого зображення з кожною точкою першого (перехресна перевірка). Після цього ми робимо висновки щодо отриманих результатів. Дві точки вважаються відповідними (позначено зеленою лінією), коли у двох напрямках різниця між ними менша за різницю з іншими точками. Так, для верхньої точки першого трикутника найменша різниця дорівнює 3, але для верхньої точки другого трикутника, найменша різниця дорівнює 2, тож ці точки не відповідні (червона лінія). У цьому випадку серед 3-хзнайдених ключових точок ми отримали 1 точку з матчингом (33%).

Метод Cross Check

Інший метод був запропонований Девідом Лоу, який також є автором SIFT. У ньому ми визначаємо різницю в одному напрямку: для кожної точки першого зображення з кожною точкою другого зображення. Ідея полягає в тому, що якщо два зображення містять один об’єкт, то для кожної точки першого зображення існує тільки одна точка на другому зображенні, різниця з якою буде прагнути до нуля. Різниці з іншими точками будуть суттєво відрізнятися в більшу сторону. Тому щоб матчинг був прийнятий, його результат має бути набагато кращим за всі інші результати матчингів для цієї точки. Можна задати параметр цього порівняння, наприклад, найменша різниця має бути на 75% менша за всі інші різниці. Маємо ті самі 2 трикутники і обчислені різниці для кожної точки. Для найвищої точки першого трикутника результати — 3, 7 і 8. Найкращий результат 3, що становить 42% від 7, і 37% від 8. Це набагато менше за 75%, тому цей матчинг приймається. Для середньої точки маємо результати 5, 4 і 6. Найкращий результат 4, що є 80% від 5 і 66% від 6. Це більше за 75%, тому чей матчинг вибраковується. Бачимо, що доцільно порівнювати тільки 2 найкращих результати, бо якщо хоча б один з результатів буде більший за 75%, матчинг вибраковується. У даному прикладі серед 3-хзнайдених точок ми отримали 2 точки з матчингом (66%)

Тест Девіда Лоу

При прийнятті рішення також можна брати до уваги координати точок, які порівнюються. Якщо ми знаємо, що у фрагментах має бути один і той самий об’єкт і його спотворення не передбачають поворотів, то ми можемо додати перевірку того, що координати точок не мають відрізнятися суттєво.

В OpenCV існує класс BFMatcher (Brute-Force), який використовується для порівняння дескрипторів. Відповідно до того, яким методом були обчислені дескриптори (SIFT чи інші), та який метод буде використано для порівняння (Cross-Check чи тест Девіда Лоу), створюється об’єкт bf класу BFMatсher. Якщо використовується Cross-Check, то метод bf.match приймає два масиви дескрипторів (для першої і другої картинки) і повертає масив з об’єктами типу match. Кожен об’єкт match містить координати, дескриптори і результат порівняння для двох точок які пройшли Cross-Check.

Якщо використовується тест Девіда Лоу, то метод bf.knnMatch приймає два масиви дескрипторів і параметр k — кількість порівнянь для кожної точки, які будуть приймати участь у тесті Девіда Лоу. На прикладі вище ми бачили, що 2 найкращих результати для кожної точки достатньо для порівняння, тому k=2. Метод повертає масив масивів з результатами для кожної точки (результати сортовані від меншого). Далі застосовується тест, де у циклі перевіряється, чи з двох найкращих результатів один менший за другий на 75%. З тих результатів, що пройшли тест, формується масив good. Метод drawMatches дозволяє намалювати лінії між картинками, які порівнюються.

Brute Force matching в OpenCV

Порівнюючи співвідношення точок, які були знайдені, і точок, що пройшли тест, ми можемо визначити, який метод порівняння є кращим для наших задач. При тестуванні локацій на мапі кращі результати показав тест Девіда Лоу, тому ми взяли його за основу для написання скрипту перевірки.

Висновки

Ми розглянули деякі елементи теорії Computer Vision та познайомилися з бібліотекою OpenCV. Це дуже мала частина усіх знань про обробку зображень, але вона дозволяє створити інструменти, які будуть корисними у тестуванні.

У наступній частині ми розберемо на прикладі простого фреймворку, як працюють скрипти для пошуку темплейтів та об’єктів, протестуємо їх на скріншотах екрану Android-смартфону, визначимо особливості такого тестування.

Привет! Я работаю CTO в компании Poster, облачной системе автоматизации для кафе и ресторанов. За шесть лет мы из днепровского стартапа выросли до второй по величине планшетной POS-системы в Европе.

В статье я поделюсь нашим опытом и расскажу о том, как мы перестраивали процессы, стремясь к удобному и качественному деплою. Когда-то давно СТО (раньше эту должность занимал нынешний CEO Родион Ерошек) заходил на единственный сервер и вручную делал git pull origin master. Сейчас же наш серверный парк перевалил за 100, причем любой программист, прошедший испытательный срок, может задеплоить свой код на продакшен в любое время дня и ночи, и даже CTO обязан прислать соответствующей гильдии код на ревью перед деплоем на первых клиентов.

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

Немного контекста

Poster — это высоконагруженный продукт: с помощью системы ежемесячно пробивается 17 млн чеков в 11 тыс. ресторанах в 90 странах мира. Система состоит из POS-терминала для официантов и админпанели для владельцев. Программа работает на iPad- и Android-планшетах, desktop-версии запускаются под Windows и macOS, есть и веб-версия.

Ядро системы работает на JS + PHP. Нативные приложения используют Objective-C и Swift, Java и Kotlin, Electron и React Native. Часть микросервисов написаны на Python и Node.js. Вся инфраструктура размещается примерно на 75 dedicated и 25 виртуальных и cloud-серверах. В Dev-команде 40 человек.

Система позволяет сторонним разработчикам интегрироваться с ней на четырех уровнях:

• API с веб-хуками;
• кастомные страницы в админпанели;
• отдельные JS-приложения, внедренные в POS-терминал и перехватывающие различные события;
• другие iOS- и Android-приложения на иных планшетах, взаимодействующие c POS-терминалом внутри локальной сети по отдельному протоколу.

Сегодня в маркетплейсе находится порядка 40 сторонних приложений, плюс еще примерно 400 закрытых личных интеграций.

Техническая автоматизация деплоя

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

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

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

Сейчас же тесты стали стандартом и входят в Definition of Done практически во всех командах. Хотя мы все еще против бездумного покрытия тестами ради самих тестов.

С автоматизацией деплоя происходило примерно то же самое. Мы проводили ее понемногу, маленькими шажками, когда уже упирались в ежедневную рутину ручного труда.

Ручной деплой

В первый год жизни компании, когда в ней работало лишь несколько программистов, CTO выливал код банальным git pull origin master. Этого было достаточно, ведь деплой чего-то нового происходил не каждый день.

Первой ласточкой стала автоматизация миграций. Данные каждого клиента Poster хранятся в отдельной базе. В первый год работы компании, чтобы провести миграцию баз, программисты писали новый метод в контроллере :) Затем происходило переподключение по всем базам и выполнение какого-то SQL-ника или куска PHP-кода. А передача изменений между разработчиками, которым также надо было локально обновить у себя базу, осуществлялась через Skype.

Эта схема накрылась примерно тогда, когда я пришел в компанию. Кто-то забыл скинуть в Skype один из SQL-запросов, и после деплоя система начала работать совсем не так, как надо. Я выбил неделю для устранения этой проблемы и написал библиотеку, которая могла бы гибко мигрировать все базы клиентов или какую-то конкретную.

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

Capistrano

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

Deployer

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

Со временем мы начали использовать параллельный деплой на все app-серверы одновременно. Это позволяет выливать новый код на десятки серверов в среднем за 5-7 минут.Конечно, бывает и дольше, особенно если есть миграции или же в коде было очень много изменений (но теперь это мало кого беспокоит, так как все выполняется уже без участия разработчиков).

/* * Deploy task */
task('deploy', [    'deploy:info',    'deploy:lock',    'deploy:prepare',    'deploy:release',    'deploy:update_code',    'deploy:last_commit',    'deploy:copy_dirs',    'deploy:copy_files',    'deploy:npm_install',    'deploy:build',    'deploy:shared',    'deploy:shared_local',    'deploy:check_migrate_pos',    'deploy:check_migrate',    'deploy:symlink_previous',    'deploy:appcache_generate_data',    'deploy:prepare_migrate',    'deploy:symlink',    'deploy:generate_webp',    'deploy:reset_opcache',    'deploy:migrate_pos',    'deploy:migrate',    'deploy:update_appcache',    'cleanup',    'deploy:unlock',
]);

После перехода на Deployer мы деплоили примерно два года с локальных машин. На тот момент у нас толком не было тестов, поэтому такой процесс нас хоть и с натяжкой, но устраивал. Когда же мы наняли первого Automation QA, то вариантов не создавать полноценный CI-/CD-процесс уже не было. У нас появился выделенный DevOps-инженер, который этим и занялся.

GitLab

CI-/CD-процесс мы организовали в рамках своего GitLab-сервера. Сначала создали pipeline для прохождения тестов, а после этого добавили отдельный pipeline непосредственно для деплоя после принятия MR.

В итоге сейчас все, что нам надо сделать, чтобы вылить какую-то ветку, это поставить MR в GitLab, а затем принять его после прохождения тестов. Либо же сразу выбрать автоматический деплой после прохождения тестов. И все.

4 часа, die(); и 11 514 чеков

Однажды года четыре назад я деплоил ночью большое изменение, которое нельзя было выливать днем: задача требовала вынужденной блокировки аккаунтов для проведения сложных миграций в базах. Хоть я и проверил, чтобы POS-терминалы клиентов запускались, но в сонном состоянии не учел, что это был кеш, который позволяет нашим клиентам работать offline. Довольный результатом работы я пошел спать. А в это время система лежала четыре часа. Тогда у нас еще не было круглосуточной технической поддержки, и до утра меня никто не разбудил... До сих пор с ужасом вспоминаю то утро.

Три года назад после окончания отлова одной из ошибок разработчик забыл <? die();?> в библиотеке, отвечающей за синхронизацию POS-терминалов с бэкендом. Благодаря дикой случайности этот код не ушел на серверы и не поломал нашим клиентам синхронизацию.

В тот же год наш будущий DevOps-инженер вылил код, который за 20 минут поломал закрытие 11 514 чеков. Мы потратили 12 часов, чтобы достать детали клиентских данных из логов и починить их.

К счастью, такие случаи были единичными, но именно благодаря им у нас появились E2E-тесты, а затем API- и unit-тесты. Только пройдя через боль и страдания, бизнес принимает необходимость автоматического тестирования.

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

Клонирование баз

Первое, что мы сделали, это автоматизировали клонирование баз с боевых серверов на локальные машины разработчиков. Сначала это был один маленький bash-скрипт, затем второй, третий и так далее, пока все скрипты не превратились в библиотеку poster-core-tools. Сейчас любой разработчик может законтрибутить туда изменение, которое автоматизирует его работу или работу всего отдела. Клонирование баз привело к тому, что мы смогли локально тестировать написанный нами код на данных лояльных клиентов.

QA-инженер

Мы очень долго сопротивлялись появлению у нас QA-инженеров. Как и у многих продуктовых компаний, у нас был стереотип, что разработчики должны писать код, не требующий дополнительного тестирования. И долгое время мы работали именно так: все разработчики тестировали свой код самостоятельно, либо это делали техлиды во время ревью.

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

Stage-сервер

Мы создали свой первый stage-сервер, куда научились выливать любую ветку с любой базой для проверки нового кода. Stage-сервер стал настолько популярным, что нам практически сразу пришлось добавить еще несколько: команда технической поддержки захотела делать то же самое во время обработки клиентских тикетов, чтобы удостовериться в наличии бага.

Когда запросы на stage-серверы превысили десять штук, в poster-core-tools была добавлена возможность разворачивать их автоматически. Сейчас у нас 40 серверов для ручного тестирования и еще 10 для прогона автоматических тестов. При необходимости можем добавить еще пару десятков запуском одной утилиты.

AQA-инженер

Два года назад мы наняли первого AQA-инженера. Нам понадобилось примерно 8 месяцев, чтобы покрыть все основные функции E2E-тестами и создать свой первый pipeline для проверки работоспособности системы.

Параллельно с E2E-тестами мы начали писать API-тесты и развивать культуру написания unit-тестов. Нельзя сказать, что все идет гладко, но практически ежеквартально у нас происходят какие-то изменения в процессе тестирования.

Примером такого изменения стало появление QA-гильдии. QA-инженеры изо всех команд собираются раз в спринт, обсуждают то, что было сделано за последние две недели, составляют план написания тест-кейсов на следующий спринт, а также синхронизируются с AQA-инженером.

Канареечный деплой

Отдельно хочу рассказать о канареечном деплое. Мы ввели его четыре года назад, чтобы максимально быстро доставлять пользователям изменения продукта. Такие пререлизы позволяют безопасно тестировать новые функции на небольшом проценте пользователей. А если с обновлением что-то идет не так, можем быстро откатиться назад, и большинство клиентов ничего не заметит.

Сначала такой деплой состоял из beta- и production-веток. Со временем к ним добавились testing, а примерно год назад stable-ветки. В итоге сейчас у нас следующая схема разлива кода:

Beta 5% → Testing 10% → Production 15% → Stable 70%

Все разработчики ежедневно льют свой код в beta, на следующий день он переливается из beta в testing, а еще через день — из testing в production. Каждый понедельник код меняет распложение — из production в stable.

Клиенты находятся в постоянной ротации между ветками согласно простому алгоритму: остатку от деления их ID на 5. При этом на ветки ниже stable стараемся переносить клиентов с наибольшим ID, чтобы «старики» оставались на stable. На beta находится примерно 5% клиентов с остатком, равным 1; на testing — 10% с остатком, равным 2; на production — 15% с остатком, равным 3; а все остальные — на stable.

У нас есть еще три ветки — beta 2, beta 3 и beta 4. На них выливаются большие или сложные изменения, которые требуют неопределенного времени тестирования в боевых условиях на работающих лояльных клиентах. После этого код переносится в стандартную beta-ветку.

Доверяй, но проверяй

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

В самом начале код на боевые серверы выливали основатели компании. Ревью проходило по-разному: где-то код проверялся внимательно, а где-то — по диагонали.

Когда тогдашнему CTO надоело смотреть мой код и мы научились деплоить с помощью Capistrano, все ревью кода и право деплоя негласно перешли ко мне. Так продолжалось примерно полтора года, пока я не стал самым узким местом в ядре и из-за меня не начала падать скорость доставки фич клиентам.

Это был первый урок: мы поняли, что техлид не должен тормозить и надо делегировать право деплоя и ревью другим ребятам. В тот момент я уже занимал позицию CTO, и надо было как-то ускорять процесс. Таким ускорением и стало появление позиций техлидов среди бэкенд- и фронтенд-разработчиков. Эти ребята взяли на себя обязанности ревью и деплоя, что существенно продвинуло нас вперед.

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

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

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

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

Примерно три месяца назад на собрании Dev-отдела, я, CEO и Head of Engineering получили запрет на деплой кода без ревью соответствующей гильдии... Так и живем, создавая отдел по бирюзовой методологии.

Подведем итог

Сейчас из инструментов мы используем GitLab (для хранения репозитория) и Continuous Integration. Для Continuous Deployment применяем Deployer, а стартует все также из GitLab.

Каждый раз, когда разработчик пушит свой код в репозиторий, мы прогоняем unit-тесты и проверяем code style для JS и PHP.

После того как ветка готова, разработчик ставит MR. В этот момент запускается расширенный pipeline вместе с деплоем ветки на stage-серверы, зарезервированные под автотесты. В качестве тестов сейчас гоняем API-тесты, приемочные на Codeception и E2E-тесты на Selenium.

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

Как только все виды тестов и ревью пройдены, в GitLab принимается MR и код автоматически выливается на клиентов, находящихся на beta-ветке. На следующий день код будет перемещен на testing, а затем на production. С наступлением ближайшего понедельника код из production попадет на stable.

При необходимости разработчик может вылить код не на beta, а на beta 2 / beta 3 / beta 4 и перевести туда нескольких заинтересованных клиентов, чтобы они какое-то время потестили фичу. Но потом она все равно будет влита в beta.

Что дальше

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

1. Добавить в pipeline SonarQube, чтобы ускорить и упростить дальнейшее ревью кода.
2. Сделать автоматический, а не ручной ежедневный перелив кода между ветками beta ⟶ testing ⟶ production ⟶ stable в рамках канареечного деплоя. Сейчас MR создаются автоматически, но после прохождения всех тестов подтверждаются вручную.
3. Улучшить алгоритм и автоматизировать выбор клиентов для канареечного деплоя. Уйти от «глупого» остатка от деления и начать использовать более качественное распределение. Например, чтобы на beta, testing и production были клиенты как с большим, так и маленьким количеством чеков, с большим и маленьким меню, клиенты, работающие со всеми типами оборудования, и так далее. Это позволит находить неточности в новом коде раньше, не дожидаясь их попадания на всех клиентов.
4. Деплоить только после получения определенного количества лайков со стороны гильдии.
5. Автоматизировать выбор тех, кто будет ревьюить код.

И наконец, мы созрели для полного переосмысления своего текущего подхода к CI/CD, чтобы его можно было масштабировать с основного проекта на сателлитные подпроекты и микросервисы. Пока большая часть из них по-прежнему деплоится вручную без своих pipeline. Этим мы и займемся в скором времени.

Main image by Jonathan Segal

Читайте также: Щоденні релізи: досвід продуктових ІТ-компаній

Понад 8 років я працюю у сфері розробки програмного забезпечення, переважно з JavaScript і RoR, і всі 8 років беру участь в open source. Серед проєктів, участю в яких пишаюся найбільше — Botpressта Spree.

Уперше з open source мені довелося мати справу ще в школі, коли я пробував запускати Linux замість чергового «перевстановлення Windows» у себе й своїх близьких. Згодом почав використовувати його й у роботі, проте не наважувався брати участь. Свій перший PRя відкрив до Spree, з яким саме тоді працював і якому бракувало перекладу українською. Його прийняли, і ось тоді я зрозумів, що, виявляється, це не лише не так і складно, а й можна поєднувати роботу із задоволенням.

Але цю статтю пишу не для того, щоб розповісти, що в Open Source робив я. Моя мета — пояснити, чому open source потрібні ви. Чи можна заробити на open source, як почати й для чого це все треба?

Що таке open source і community

Open source — це рух, що підтримує розробку й просування відкритого програмного забезпечення. Простіше кажучи, open source — це, наприклад, безліч проєктів на GitHub, куди ви точно не раз заходили, щоб знайти потрібне вам рішення. Open source — це ще й Linux, улюблена ОС більшості розробників програмного забезпечення.

За кожним проєктом open source стоїть спільнота, тобто community, яка його розробляє, підтримує і просуває. Community — це різні люди з різними намірами: хтось хоче розвинути програмний продукт, наприклад тому, що використовує його в роботі або навіть виконує завдання, яке оплачує кінцевий замовник; хтось хоче вдосконалити власні навички — так люди, які тривалий час працюють в одному проєкті, хочуть урізноманітнити свій досвід, перевірити знання й уміння та отримати фідбек від ком’юніті; хтось робить внесок в open source заради різних community-заходів — вони й додають фану в роботу; а комусь просто цікаво, можна сказати з дослідницького погляду, зрозуміти, як працює щось складне (той самий Virtual DOM у реакті).

Неважливо, які цілі ці люди мають на прикметі. Важливо те, що, з одного боку, без спільноти проєкт Open Source не зможе довго існувати, а з іншого, для реалізації цих цілей, нам і самим потрібен open source!

Учасники Lviv Hacktoberfest

Як community може вести розробку продукту

Ми вже з’ясували, що за розробку, підтримку, документацію і просування проєктів відповідає спільнота. Але як? Кому належить проєкт? Хто ним керує?

Є два способи, за допомогою яких можна зорганізувати роботу над проєктом open source.

1. Проєкт повністю контролює спільнота

Тут принцип простий: кожен учасник спільноти може повідомити про проблему або розв’язати її, створити pull request і з’єднати його з певною гілкою. У таких проєктах open source є один або кілька адміністраторів, що переглядають кожен pull request, кожне зареєстроване issue і наводять лад.

Адміністратори — це розробники програмного забезпечення, зазвичай засновники тих проєктів, які вони адмініструють. Наприклад, Стів Клабнік (Steve Klabnik) — це один з авторів мов програмування Ruby on Rails і Rust. Більшість з вас знають його як надактивного користувача твіттеру, але, крім того, він ще й адміністратор такого проєкту open source як Rust. Колись він писав, що понад місяць займався лише тим, щоб навести лад у списку issues, про які повідомляли учасники спільноти — видалити повторювані, закрити розв’язані або зібрати вимоги до незрозуміло пояснених проблем. Уже згаданий раніше Linux — це також проєкт, який повністю контролює спільнота. Лінус Торвальдс (Linus Torvalds), засновник цього проєкту, віддав його на повну опіку спільноті open source, хоча він і досі лишається тією людиною, що найактивніше розробляє, підтримує й адмініструє Linux.

2. Спільнота контролює проєкт лише частково

Над проєктом працює спільнота розробників, але є певна команда — центр спільноти, core, який ухвалює основні рішення щодо проєктів. Наприклад, популярний JavaScript-фреймворк Reactпідтримує спільнота, але керують ним розробники з компанії Facebook. Інший приклад — платформа для створення чатботів Botpress. Чимало людей працюють над цим проєктом, і я пишаюся бути серед них. Проте керівник проєкту — компанія Botpress.

Чи можна заробити на open source

Заробити реально, але невиправдано важко. Як звичайний малоактивний учасник певної спільноти ви не зможете одержати прибуток. Як власник проєкту або ентузіаст open source — можливо, хоча й малоймовірно. Ось кілька способів, щоб монетизувати цю ініціативу:

Для власників проєктівможна одержати прибуток з підтримки й консультацій корпоративних користувачів продукту. Повертаючись до прикладу з Linux, ми вже з’ясували, що ця ОС безплатна. Однак уявіть, що є велика компанія, яка хоче перевести всі свої комп’ютери на Linux. Налаштувати десятки й сотні пристроїв — це робота не для однієї людини й не на один день. Компанія Linux пропонує таким клієнтам платну послугу зі встановлення й налаштування свого програмного забезпечення на всіх комп’ютерах замовника. Якщо замовник згоден, компанія Linux одержує прибуток.

Для власників проєктів і деяких учасників спільноти:

• Bug Bounty — це ініціатива, яка дає змогу розробникам програмного забезпечення отримати нагороду від власника проєкту за знаходження і розв’язання помилок у коді. Таку ініціативу підтримують, наприклад, Google, Microsoft, Reddit, Yahoo й Facebook. Доволі часто такі ініціативи перетинаються з проєктами open source.
• Bountysource — це платформа, де люди пропонують грошову винагороду, якщо ви розв’язуєте певну програмну проблему. Як це пов’язано з open source? У деяких GitHub-проєктах ви можете зауважити таке речення: «Want to back this issue? Post a bounty on it! We accept bounties via Bountysource». Ось це і є ваш шанс заробити!
• Крім того, можна спробувати знайти спонсорів, які підтримуватимуть власників проєкту, найактивніших учасників спільноти або програмістів, які розв’язуватимуть найскладніші проблеми.

Хай там як, а заробіток — не основна мета участі в open source. Тоді виникає запитання: навіщо?

Для чого брати участь в open source

Усі знають, як важко знайти роботу людині без досвіду. Open source — це досвід, який ви можете сміливо згадати у своєму CV. Якщо HR запитає вас, чи знаєте ви React, то вразьте його й скажіть, що належите до спільноти розробників цього фреймворку! Або ж реалістичніший приклад: сконтактуйтеся з кимось з community й прилучіться до підтримки менш розкрученого проєкту (наприклад, Svelte) на місяць. Ви й користь зможете принести проєкту, й цікаві знайомства здобути, і, звісно, у резюме зможете це згадати.

Open source — це чудова нагода вдосконалити свої знання й навички програмування без курсів і без книжок. Коли ваш pull request перевіряє Ден Абрамов (Dan Abramov) або той самий Стів Клабнік (Steve Klabnik), то ви думаєте про якість коду й про зауваження до нього куди більше, ніж коли пишете код для себе або на курсах. І повірте, ці хлопці знають «трохи» більше за пересічного тимліда з вашого міста, а отже, є і більше речей, яких можна й повчитися в них.

Open source — це соціальна відповідальність. Ви розв’язуєте один баг в проєкті open source й автоматично розв’язуєте його для всіх, хто використовує цей продукт. Наприклад, розв’язуючи одну проблему в Botpress, я ще додав підтримку української мови на платформі.

Як можна долучитися до Open Source

Прилучитися до open source просто. Зробити це добре — трохи важче, але цілком реально. Правила гри доволі прості:

1. Якщо ви використовуєте певний продукт open source (бібліотеку, фреймворк, операційну систему, програму...), підтримайте мотивацію людей, які до нього докладають зусилля. Поставте їм зірочку, лишіть декілька дописів до наявних issue, висловіть подяку комусь із розробників. Не уявляєте, скільки відкритих проєктів це могло б урятувати від занепаду.
2. Якщо ви знаходите помилку в проєкті open source, що його ви використовуєте, — відкрийте GitHub проєкту й повідомте про проблему. Повідомити про проблему можна добре, а можна погано. Щоб повідомити погано, напишіть, що проблема є, але не описуйте її, не розповідайте деталі й не додавайте зображень. Ба більше, напишіть це «на емоціях» і звинуватьте адміністратора в поганій підтримці проєкту: «ВАША ПРОГРАМА НЕ ПРАЦЮЄ!!! ЗРОБІТЬ ЩОСЬ!!!» Так ви, звісно ж, «підвищите» мотивацію людей, які працюють над проєктом (зазвичай у вільний від роботи час на безоплатній основі) й змусите їх потренувати свої детективні навички в розумінні ваших натяків на існування проблеми. Щоб повідомити про помилку добре, зробіть навпаки — додайте ідеальний опис того, що сталося та за яких умов, а ще ліпше, зробіть знімки екрана, на яких проблему буде видно. Ось гарний приклад того, як створювати опис помилок, з якими розробниками приємно працювати:

3. Якщо можете розв’язати проблему, яку знайшли ви або хтось інший, то розв’яжіть її і зробіть pull request. Pull request теж можна зробити добре й погано. Щоб виконати його погано, проігноруйте всі інструкції та гайди, зробіть багато невмотивованих або непояснених змін, ігноруйте стиль коду, не пишіть тестів і не ведіть документацію. У результаті ваш PR висітиме місяцями й відбиратиме енергію на спілкування й пояснення потреби в дотриманні стандартів у команді. І, можливо, так і не буде прийнятий. Щоб зробити pull request добре, уважно прочитайте й використайте Contribution Guidelines — опис основних принципів і правил роботи з певним проєктом, а також зважайте на те, у яку гілку ви мерджите свій pull request.

Ще один спосіб стати частиною спільноти open source — це відвідувати заходи, що вона проводить. Наприклад, Hacktoberfest — це рух, що підтримує open source й щороку проводить жовтневі хакатони в усьому світі. У Львові ця подія вже відбувалася 2018 і 2019 роках за підтримки компанії KeenEthics. Читайте в пресрелізіпро те, як це було.

Як розпочати

Багато хто думає: «Я не такий кваліфікований, щоб викладати щось на GitHub». З чого ж розпочати в такому разі?

Найперше, як описано вище, спробуйте відвідувати заходи, що організовує спільнота. Коли ви подивитеся на учасників open source, то зрозумієте, що не святі горшки ліплять. Колеги й однодумці допоможуть вам здобути впевненість у собі та ліпше збагнути філософію open source.

Крім того, можете зорганізувати собі імпровізовану менторську програму. Серед друзів або колег знайдіть когось досвідченішого, хто вже підтримує open source, і попросіть його поділитися досвідом. Попросіть оцінити ваші технічні навички, попрацюйте пліч-о-пліч з ними й разом зробіть ваш перший pull request на GitHub.

Уже згадував, що своїм першим PR я всього-на-всього поправив українську локалізацію. Це хороший варіант для старту: це зазвичай нескладні зміни для носія мови, до того ж може статися, що носіїв української в ком’юніті певних проєктів мало або тільки ви і є.

Підсумуємо

Участь в open source навряд принесе вам фінансову вигоду. Однак вона подарує щось більше — задоволення собою, нестандартні головоломки для тренування мозку, спілкування з цікавими людьми й безцінний досвід. Якщо хочете дізнатися більше про те, як і навіщо ставати учасником цієї спільноти, пишіть на oleksiy.pletnov@keenethics.com. Якщо переконувати вас більше не треба, відкривайте GitHub, повідомляйте про issue і робіть ваш перший pull request.

Всем привет! Меня зовут Юра Сысоев, и вот уже 7-йгод я занимаюсь в индустрии задачами разного плана — от создания концептов новых проектов до детализации гейм-дизайн-документа (ГДД) и пострелизного анализа продуктов. Долгое время анализировал входящие запросы на создание продукта, и благодаря порой «очень качественным» из них был вынужден найти решение, которое позволяло бы получать результат за короткий промежуток времени.

Таким подходом стал «обратный инжиниринг» (Reverse Engineering) — исследование некоторого готового устройства (или программы), а также документации на него с целью понять принцип его работы © Wiki. Используя данный подход, я начал тратить меньше времени на запросы, выдавать качественный результат в короткие сроки, и проект получил финансирование. Для удобства далее я буду называть обратный инжиниринг реверсом.

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

Вот один из примеров, когда нет времени на анализ и док, а результат нужен. Допустим, вам приходит запрос на создание документа, который описывал бы некую механику/игру, и на это дается 1–2 дня.Конечно же, вы можете в силу своей креативности придумать что-то невероятно крутое, что впоследствии, по вашему мнению, изменит мир. Но есть большая вероятность того, что продюсер или директор игрового направления скажет «работать это не будет, давай сначала», а вы уже потратили все доступное время. Именно в таких случаях я предпочитаю путь реверс-инжиниринга.

Что такое Reverse Engineering

Давайте коротко разберем, что же такое реверс-инжиниринг. Вы без труда можете найти определение в Википедии, но мне больше нравится то, что есть в Лурке :)

Некоторые слова в цитате пришлось заменить, так как в Лурке обычно пишут более экстравагантно — мат через мат.

Так вот, Reverse Engineering (ревёрсинг, обратная разработка) — это процесс «заимствования», восстановления исходников из конечного продукта инженерной и/или научной деятельности с интуитивным конструированием внутренней механики по принципу «а какие процессы должны вызвать такое внешнее поведение этого продукта?». Ориентируясь на нюх, так сказать. Иногда приводит к написанию собственного дока. Много их, ибо ваистену... © Lurkmore

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

Совет:никогда не пишите документы «просто, чтобы написать документы». Поставьте конкретную видимую цель и конкретный результат, которого хотите достичь. К примеру, вы хотите, чтобы прыжок вашего героя отлично ощущался с точки зрения контроля, например как в Super Mario Bros. Вы начинаете долгую разработку документации с тестированием с прототипами и т. д. Но что вы можете сделать вместо этого? Включить «Супер Марио» и проанализировать механику прыжка, выписать это все в документ и отдать в разработку. Важно понимать, что реверс нужно делать только тогда, когда вы точно понимаете, зачем он нужен, и только в случае, когда вы не делаете артхаус инди Death Stranding для эмуляторов андроид-устройств...

То есть, если вы делаете «Матч-3», то не выдумываете велосипед, вы идете играть в Candy Crush Sagaили Homescapesи смотрите, как у них все работает. В данных проектах аудитория давно известна, и она привыкла к некоторым стандартным механикам игр «Матч-3». Если им предложить что-то «слишком уникальное», есть шанс, что вы отпугнете свою целевую аудиторию (ЦА). Я не говорю о том, что нужно создавать клоны, речь о грамотном анализе с целью сокращения вашего же времени при написании или создании общеизвестных игровых механик.

Зачем нужен Reverse Engineering

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

Разберем на примере. Вы делаете продукт из серии «Матч-3». Вам нужно понять, какие М3-элементы-«блокеры» необходимо вставить в начальный игровой цикл (самые важные для продукта 20–30минут игровой сессии). Чтобы не отпугнуть пользователя и не сделать игру слишком простой или сложной, делать это нужно очень аккуратно. Поэтому вы можете потратить кучу ресурсов и человеко-часов на создание документации, прототипирование и анализ или «выписать» задачу для гейм-дизайнера на реверс-инжиниринг 3–5топ-игр данного жанра. Впоследствии вы получите небольшую выборку по элементам типа «М3-блокер» для первых 30 минут игровой сессии и сможете на основании этих данных либо принять решение об интеграции какого-то из «блокеров» в свой продукт на ранних стадиях, либо будете анализировать дальше. В любом случае такой подход даст быстрый результат и сэкономит время.

Следующий пункт, который я хотел бы отметить, — «наигранность». В моем понимании этот термин означает то, насколько хорошо вы знаете продукты схожего жанра и рынок в целом, а также, как хорошо вы ориентируетесь в игровых механиках. Приведу пример из личного опыта. Мой телефон выглядит как игровая приставка, на нем установлены на текущий момент порядка 100–150 игр,все они отсортированы по жанрам, типам и т. д. Что я делаю каждую неделю, так это иду в App Store или Play Market, захожу в фичер и скачиваю все игры, которые показались мне интересными. Дальше минимум 30–60минут играю в каждую из них. Во время игровой сессии я делаю быстрый поверхностный реверс. В случае, если нахожу интересную или уникальную, не известную мне до сих пор механику, начинаю углубляться в ее изучение.

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

Типы Reverse Engineering

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

Глобально реверс можно разделить на софтовый (Software), «ощущения» (How does it feel) и железо (Hardware). Последний нас не интересует, поскольку в рамках данной статьи мы затрагиваем только софт. Возможно, некоторые из вас могут разрабатывать новый Nintendo Switch, но реверс железа — это тема для другой статьи. Мы же остановимся на софтовом реверсе и реверсе «ощущений».

• Software.
  
  • Code and technical approaches.
  • Core and meta mechanics.
  • Balance.
  • Interface.
  • Art style and animations.
  • Lvl design.
• How does it feel.
  
  • User experience.
  • Sounds and music.
  • Narrative.
  • Overall impression.
• Hardware.

Софт-реверс — это реверс, направленный на поиск интересных гейм-дизайнерских и технических решений. Тот же пример с «Супер Марио», о котором было написано ранее, — это софтовый реверс. Другой пример: как ведет себя звук на экране загрузки в Death Stranding (далее DS). Те из вас, кто уже успел оценить игру, могли заметить, что при полной загрузке уровня или главы в DS есть звук, который проигрывается на экране загрузки уровня. Дело в том, что загрузки в игре достаточно продолжительные, поэтому может случиться так, что игрок попросту уйдет, а то и вовсе забудет, что он ждет загрузку уровня. Я лично, пока идет загрузка в DS, играю на мобильном телефоне. Как этот вопрос решили гейм-дизайнеры? Через несколько секунд после полной загрузки звук на экране становится громче! :)

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

Реверс «ощущений».Называю я его так потому, что слово «ощущения» наиболее полным образом описывает то, что входит в задачу: описать ощущения от игры или игрового элемента. Возьмем в пример тот же DS. В игре, особенно в самом ее начале, имеются большие локации. На этих больших локациях Хидео Кодзима, на мой взгляд, хотел показать одиночество, и у него это получилось, потому что делать там реально нечего. И чтобы локация вызывала у вас именно «нужное ощущение», был применен ряд технических моментов, например: отдаление камеры в нужные моменты, звуки ветра и т. д. Помимо этого, была добавлена очень грустная музыка, которая подчеркивает одиночество игрока в данный момент. Если вы выключите звук и захотите пройти начальные локации DS без музыкального сопровождения, игра покажется вам очень скучной. Это и есть реверс «ощущений»: когда вы подмечаете эмоциональную составляющую игровой механики или элемента либо понимаете, какой опыт пользователя (user experience) создается в данный момент.

Далее, в софтовой части, идет реверс механик.С помощью реверса вы можете быстро получить информацию по интересующей вас игровой механике, скажем по прыжку главного героя (ГГ). Например: если вы хотите достичь идентичного результата, как в игре «Х», можно расчертить поле и считать по пунктам, пикселям или как вам будет удобнее расстояние прыжка, приземление, скольжение и прочие параметры механики. В Super Smash Brothers Ultimate, кстати, есть тренировочная локация, где разметка уже есть. Все, что вам необходимо, выписать это в документ в удобной для вас и ваших разработчиков форме. Также одним из решений «готового реверса» механик являются постмортемы и дневники разработчиков, в которых описываются приемы, методологии и другие подходы, с помощью которых создавались игровые механики.

Возможно, кто-то из читателей уже видел дневники разработчиков, постмортем игры Shovel Knightили другие материалы по платформерамлибо метроидваниям. В подобных материалах можно встретить подробное описание того, как гейм-дизайнеры делали и рассчитывали баланс прыжка ГГ и как на базе этого строились уровни, какими навыками обладал герой, как это влияло на расстояние прыжка, какие дополнительные механики применялись для создания продвижения ГГ по уровням, — все это является уже «готовым реверсом» механики и поможет вам в написании собственного документа.

Баланс.На нем не буду подробно останавливаться, потому что лично для меня это самая нелюбимая часть реверса. Как и в ходе создания баланса, во время реверса ваша задача — воссоздать математическую/экономическую модель продукта, основываясь на имеющихся данных. Я советую отдавать данный тип реверса гейм-дизайнеру по балансу или другому специалисту, который занимается математикой в вашем продукте.

Далее к софтовому реверсу я отношу интерфейсы (UI),но не опыт пользователя при их использовании (UX). Дело в том, что при софтовом реверсе вы подмечаете технические детали интерфейса, такие как зона или область нажатий — место, куда игрок достает пальцем и жмет чаще всего. Очень простой пример. Ваш продукт — Idle/Clicker (например, Tap Titans 2) в вертикальной ориентации, наиболее часто нажимаемая кнопка — улучшить ГГ. Вы берете и ставите данную кнопку в левый верхний угол, а 95% вашей ЦА — правши, которые играют на устройствах Android с 7-йдиагональю...

Как вы думаете, как скоро к вам прилетят «благодарственные» письма разъяренных игроков за такое «удобное» расположение кнопки? Уверен, очень быстро.

Небольшая ремарка по поводу «нужно ли делать реверс, а потом это имплементить в собственном проекте?». Короткий ответ: «Нет». Если вы где-то увидели пример реализации интерфейса, как я описал, поверьте, он не лучший. Думайте всегда своей головой, даже если в похожих с вашим продуктом играх есть аналогичный подход. Ваша игра — только ваша, и вам решать, какой в ней будет интерфейс. Конечно же, ваша задача как разработчика — сделать интерфейс как можно более удобным для максимального количества игроков, но не стоит бездумно гнаться за трендами и копировать неудачные кейсы. Всегда руководствуйтесь здравым смыслом и по возможности данными. Все вышеописанное касается софтового реверса интерфейса — того, что несет в себе технический характер. Все, что касается опыта пользователя от использования такого интерфейса, я отношу к реверсу «ощущений».

К последнему также я причисляю анимации,поведение кнопок или (ВАЖНО!) самого устройства. Приведу пример. Некоторые игры, в частности мобильная Call of Duty, для взаимодействия с пользователем и привлечения его внимания используют вибрации (доступны в большинстве современных мобильных устройств) — Haptic technology. Такие вибрации дают вам знать, когда игра найдена или стартует, когда вашего героя убили и так далее. Или, скажем, вы можете найти игры, в которых применяются красивые анимации и звуки при появлении окон, и они гармонично вписаны в игровой процесс. Все это я отношу к реверсу «ощущений» опыта игрока от использования интерфейсов.

На самом деле граница очень размыта, порой она и вовсе может исчезать, поэтому выбор, куда относить и как объединять элементы реверса, зависит только от вас. Если ваш продукт — игра, основанная на повествовании, к примеру красочная визуальная новелла, скорее всего, нужно будет сделать лаконичные окна, которые подчеркнут все прелести геймплея, а не миллион кнопок, как, например, в ММОРПГ-проектах.

Как итог, реверс «ощущений» — это то, как игрок чувствует происходящее на экране устройства, какие эмоции испытывает и какой опыт получает; и неважно, какой это будет тип реверса.

Давайте перейдем к арту.На мой взгляд, гейм-дизайнер может делать реверс артовых составляющих до определенной стадии, например: указать стилистику, размеры объектов, описать, какие части объекта будут анимироваться и что с ними будет происходить. Но более тонкие моменты: толщина линий, форма, подходы в построении теней и направление света — лучше делать техническому художнику или арт-директору/лиду. Все это тоже софтовый технический реверс. Гейм-дизайнер при реверсе арт-составляющих продукта должен понять, как было сделано, для чего, сколько анимаций имеется и для каких типов объекта используется и т. д., и описать все это в гейм-дизайн-документе. По сути, реверс арта напоминает написание ГДД, но только при реверсе у нас уже есть пример. Считайте, что вы списываете контрольную, но почерк человека разбираете с трудом :) При правильном подходе при реверсе арта на выходе вы получите документ, который будет выглядеть как ассет-лист: в нем будет указан персонаж, сделан его скриншот, описаны анимации, даны их тайминги и т. д.

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

Как видим, софтовый реверс направлен в первую очередь на выявление технических параметров игровых элементов. А вот как эти элементы должны ощущаться и какой опыт передавать/создавать, это уже реверс «ощущений», о котором мы и поговорим далее.

Я выделяю следующие типы реверса «ощущений»:

• опыт пользователя от использования интерфейсов и игровых элементов (User Experience), об этом мы уже поговорили;
• звуки и музыка (Sounds and music);
• повествование (Narrative);
• общее впечатление (Overall impression).

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

Документ с реверсом «общего впечатления»от игры впоследствии может использоваться в создании концепт-ГДД, питч-документах и презентациях для продюсеров/ гейм-директоров.

Представленный выше список типов реверса не статичен, вы можете без труда добавлять к нему те типы реверса и то количество пунктов, которые считаете необходимыми. Возьмем тот же нарратив, начитку диктора; они ведь тоже содержат технические параметры, например длину звуковой дорожки; если это текст, то его размеры и стиль шрифта, то есть, по сути, можно добавить нарратив в софтовый раздел. Я веду к тому, что все продукты разные («Спасибо, Капитан Очевидность!»); и в зависимости от жанра игры и содержащихся в ней элементов вы можете варьировать типы реверса, добавляя или удаляя ненужные куски. Нет же смысла делать реверс «ощущения» по звукам для продукта, в котором их не будет?

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

Reverse Engineering по тетраде элементов

Существует много способов разбивки игры на элементы и их группировки. Одним из них является тетрада элементов. Уверен, большинство читающих уже слышали о книге «Искусство гейм-дизайна» Джесси Шелла. Тем же, кто не в курсе, советую обязательно ее прочитать. Книга вышла давно, и какие-то вещи утратили актуальность, но в ГД-кругах некоторые называют ее библией гейм-дизайнера. Так вот, в данной книге автор описывает то, как он видит компоненты игры, и называет данную схему «тетрада элементов». Тетрада состоит из четырех основных элементов: «механики», «эстетики», «технологии» и «повествования». Подробнее об этом читайте в книге. Если же коротко, то суть тетрады в том, что чем более видимым является элемент игры для пользователя, тем он находится выше.

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

Итак, что есть реверс по тетраде элементов? Все просто: схема тетрады позволяет разбить игру на конкретные элементы, по ним и можно делать реверс. Берем условный платформер. Как говорилось выше, верхним элементом в большинстве платформеров является механика. Вот с нее и начинаем. Запускаем интересующую нас игру, в которой есть то «нужное», что мы можем «заимствовать» в собственный проект или принцип работы чего хотим понять, берем тетрадку и ручку или создаем новый документ в Google Docs и начинаем декомпозицию увиденного на экране. Подробно записываем все детали и делаем скриншоты-референсы, чтобы не только вы понимали, что описано в документе, но и ваша команда смогла уяснить, о чем идет речь. Визуальные референсы в целом отлично облегчают понимание документа.

Закончили с «механикой» — приступаем к следующему элементу, например к «эстетике». Ваша задача — понять, что, как и почему работает в референс-игре, а затем успешно реализовать это в собственном проекте.

Благодаря реверсу по тетраде элементов вы будете получать результат, уже разбитый на конкретные составляющие, а затем использовать данные заметки/наработки в своем проекте. Минус такого подхода в том, что более «крупные» игры, те, в которых много механик и игровых элементов (MMORPG, Battler, RTS), будет сложно реверсить, поэтому данный метод больше подходит для реверса более «простых» проектов, например гиперказуальных и некоторых казуальных.

Reverse Engineering с помощью AERM-таблицы

Следующий и, пожалуй, мой любимый тип реверса — это реверс с использованием AERM-таблицы. Любимый он потому, что дает наиболее полную, понятную и структурированную, на мой взгляд, систему реверса и анализа конкурентной игры.

Тем, кто не знаком с AERM-таблицей, я советую зайти в блог Александра Штаченкои обязательно ознакомиться не только с рекомендуемой статьей, но и с другими заметками. Саша уже давно ведет блог, делится опытом и регулярно обновляет сайт полезной информацией.

AERM-таблица состоит из стадий: A — Acquisition/привлечение; E — Engagement/вовлечение; R — Retention/возвращаемость; M — Monetization/монетизация. Именно в этом порядке пользователь в вашем проекте в идеале должен проходить стадии. Например: мы не сможем заработать на проекте (M), если не купили или не привлекли органический трафик на первой стадии (А). Помимо стадий, AERM-таблица разделена на столбцы согласно основным составляющим игры — Core, Meta, Social. Полагаю, все читающие уже знакомы с перечисленными базовыми понятиями.

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

Простой пример. Вы выпустили игру, к вам приходит пользователь. Первое, что должна делать хорошая игра, конечно же, сунуть пользователю под нос 5 красивых баннеров «Купи все за 99,99»... Конечно же, это не так :) Первое, что должна делать игра, это вовлекать пользователя в процесс (E), чтобы он остался в игре так долго (R), чтобы впоследствии заплатить (M). Как и в случаях с предыдущими подходами, вы сами вольны выбирать, какой из участков нуждается в реверсе.

AERM-таблица хороша не только на ранних стадиях проекта, когда вы начинаете разрабатывать первичную документацию, но и для анализа конкурентов. Как и в случае с тетрадой, здесь все просто: выберите необходимую стадию/составляющую и сделайте по выбранной части реверс. Например, вы скачали новую игру, и core-геймплей вас настолько увлек, что были готовы даже заплатить. Вы думаете: «Ничего себе, я тоже хочу, чтобы в моей игре Engagement работал так же хорошо!» И садитесь за реверс Core — Engagement. Или же, к примеру, вы делаете «Матч-3» и хотите, чтобы социальные взаимодействия ежедневно возвращали ваших пользователей в игру. Вы берете несколько игр жанра и делаете реверс Social — Retention. И так далее. Плюс реверса по AERM-таблице в том, что она покрывает все аспекты игры и при всей своей простоте является понятным, простым и очень эффективным инструментом. Дальше все зависит только от вас и жанра вашего проекта.

Советы по применению Reverse Engineering

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

1. Прежде чем приступить, решите для себя, нужно ли это вам? Как уже говорилось выше, не делайте реверс, только чтобы сделать его. Он должен иметь смысл.
2. Реверс будет полезен не только в жанре своей игры, но и в других жанрах. Это поможет развивать наигранность, будет ориентировать в других жанрах. Да и кто знает, какой «клад» вы найдете в другой игре :)
3. Выберите тип и установите правила реверса. Сформулируйте правила игры: чем конкретнее будет поставлена задача, тем лучше вы получите результат.
4. Всегда записывайте то, что показалось вам стоящим. Все запомнить невозможно, и, увы, иногда случается так, что новая интересная механика, которую вы нашли в одной из сотен игр, просто забудется. Поэтому настоятельно рекомендую делать даже минимальные записи элементов, которые вы сочли интересными.
5. Делайте скриншоты, а еще лучше — видео интересующих вас элементов. Визуальные референсы отлично подкрепляют описанную механику, вашей команде будет намного проще ориентироваться в документе, а вам — лучше понимать, какого результата ждете и о чем идет речь.
6. Не стоит реализовывать функционал, который вы зареверсили, только потому, что в другой игре он работает. То, что работает в референс-игре, необязательно подойдет вашей; поэтому никогда не спешите с реализацией функционала. Обсудите с командой или посоветуйтесь со старшими коллегами.
7. Старайтесь оперировать цифрами и непредвзятым фидбэком. Данный совет связан с предыдущим. Если вам кажется, что вы «нащупали» что-то интересное, лучше потратить еще немного времени на поиск дополнительной информации и подтверждения эффективности найденной механики.
8. Сделав реверс, покажите его коллеге и получите фидбэк. Всегда старайтесь получать фидбэк по выполненной работе, это позволит вам расти как профессионалу.
9. Давая задачу по реверсу начинающему ГД, не забывайте о качественном фидбэке. Если вы ведущий гейм-дизайнер или продюсер и запросили джуна сделать реверс, непременно дайте своему коллеге фидбэк: это поможет вам быть на одной волне и качественно улучшит создаваемые реверс-документы.

В заключение

Хотелось бы привести одно высказывание. Пабло Пикассо сказал: «Хорошие художники копируют, а великие — воруют». В случае с реверсом это высказывание как нельзя хорошо подходит, т.к. эту фразу можно истолковать так: «Плохой Гейм-дизайнер создаст клон, а хороший сворует так, что в итоге создаст новый продукт — игру, которая принесет яркие эмоции и новый крутой опыт вашим пользователям». Делайте хорошие игры и радуйте своих пользователей!

Бонус

P. S. Обещанные бонусы всем, кто дочитал до конца. По данным ссылкам вы найдете мою личную базу знаний, которая пополняется интересными материалами: Knowledge Base, а также доклады и выступления с прошедших конференций: Conference Reports.

Приветствую, дорогой читатель DOU! Меня зовут Ростислав, я Java-разработчик в DGN Games, где работаю уже третий год. Это продуктовая международная компания, где большая команда занимается созданием онлайн-игр. Здесь я получил огромный опыт как в поддержке и доработке высоконагруженной системы, так и в построении микросервисной архитектуры приложения с нуля с использованием современного Spring Boot стека (включая всеми любимый Kubernetes).

В этой статье не будет информации о сборке кастомной ОС, сравнения существующих ОС, версий Java, документации по работе с Docker, так как подразумевается, что ты умеешь написать свой Dockerfile и собрать образ на его основе. Зато будет рассказ о том, как мне удалось построить Docker-образ весом всего ~100-200 MB, базирующийся на Debian Buster slim, с использованием Java (версия 13.0.2).

В чем проблема

Если ты читаешь эту статью, значит, так же, как и я, интересуешься новыми технологиями в мире Java. Сейчас существует много готовых решений для быстрого старта проектов любой сложности, приложения пишутся очень быстро, и бизнес хочет получать результат как можно скорее, чтобы целевая аудитория смогла воспользоваться фичей в кратчайшие сроки. А это влечет за собой частые деплои на prod, stage-энвайронменты и т. д.

Все Java-разработчики знают, что приложение может весить, например, 100 MB (вместе с зависимостями), но, чтобы оно успешно запустилось и выполняло свою задачу, ему нужен еще JRE (Java Runtime Environment), который весит в среднем 200 MB. Сюда же нужно добавить операционную систему (далее — ОС), где будет исполняться JRE, а это еще ~50-100 MB (если использовать slim-сборку). Итого получается 350-400 MB.

Размещая Docker-образы (images) в каком-нибудь удаленном хранилище (Container Registry), например ECR, можно значительно сократить время, потраченное на передачу (загрузку или скачивание) данных, чтобы размер образа занимал всего ~100-200 MB. Помимо времени, сокращается также и плата за тарификацию удаленного хранилища: например, ECR берет плату за объем хранилища и количество переданных данных (Data Transfer). Поэтому, экономя деньги компании и время на доставку образов, я написал эту статью, которая покажет, как уменьшить вес Java-приложения с использованием готовых инструментов JDK.

Напишем простое приложение

Я буду использовать Spring Boot версии 2.2.4.RELEASE, куда подключу базовые зависимости:

• spring-boot-starter-web — для написания простого REST-эндпоинта и запуска приложения в embedded Tomcat.
• spring-boot-starter-log4j2 — для работы с логированием от Apache Log4j 2.
• jackson-dataformat-yaml — чтобы Spring смог проинициализировать конфигурацию логирования из YAML-файла.

Собирать приложение будет Maven, поэтому опишем для него POM-файл следующим образом:

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0"         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">    <modelVersion>4.0.0</modelVersion>    <groupId>org.example</groupId>    <artifactId>slim-docker-image</artifactId>    <version>1.0-SNAPSHOT</version>    <packaging>jar</packaging>    <parent>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-starter-parent</artifactId>        <version>2.2.4.RELEASE</version>        <relativePath/>    </parent>    <properties>        <java.version>13</java.version>    </properties>    <dependencies>        <dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-starter</artifactId>            <exclusions>                <exclusion>                    <groupId>org.springframework.boot</groupId>                    <artifactId>spring-boot-starter-logging</artifactId>                </exclusion>            </exclusions>        </dependency>        <dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-starter-log4j2</artifactId>        </dependency>        <dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-starter-web</artifactId>            <exclusions>                <exclusion>                    <groupId>org.apache.tomcat.embed</groupId>                    <artifactId>tomcat-embed-websocket</artifactId>                </exclusion>            </exclusions>        </dependency>        <dependency>            <groupId>com.fasterxml.jackson.dataformat</groupId>            <artifactId>jackson-dataformat-yaml</artifactId>        </dependency>    </dependencies>    <build>        <finalName>${project.artifactId}</finalName>        <plugins>            <plugin>                <groupId>org.springframework.boot</groupId>                <artifactId>spring-boot-maven-plugin</artifactId>            </plugin>        </plugins>    </build></project>

Само приложение не представляет из себя ничего интересного, поэтому не буду уделять ему много внимания, а просто покажу класс контроллера:

package com.example.controller;

import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import static java.lang.String.format;

@Slf4j
@RestController
public class HelloController {    @GetMapping("/hello")    public String hello(@RequestParam(required = false) String name) {        if (name == null) {            name = "World!";        }        String response = format("Hello, %s", name);        log.info("Created response '{}'", response);        return response;    }
}

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

После запуска вызовем эндпоинт GET запросом по адресу: localhost:8801/hello?name=Rostyslav

В итоге увидим в консоли примерно следующие логи:

Проанализировав содержимое, можем сделать вывод: приложение успешно выполняет свою задачу.

А что получается по размеру Jar?

Размер получился маленький (всего 17,43 MB), за счет того, что были подключены только базовые зависимости; ничего особенного и слишком тяжелого не используется. Но в любом другом большом проекте, где используется много различных библиотек и фреймворков, итоговый размер может достигать 100 MB и даже больше.

Сборка Docker-образа

Возьмем за основу openjdk:13.0.2-slim-buster. Его размер составляет 409 MB:

Напишем простой Dockerfile:

FROM openjdk:13.0.2-slim-buster
RUN mkdir -p /jar
COPY ./target/slim-docker-image.jar /jar/app.jar
ENTRYPOINT ["java","-jar","/jar/app.jar"]

и соберем образ. Итоговый размер получился 427 MB:

Теперь можно запустить контейнер на основе этого образа и убедиться, что приложение успешно запускается, как запускалось и без использования Docker:

Теперь проанализируем, сколько занимает установленный туда JDK 13.0.2:

Как видно на скриншоте, JDK занимает 316 из 409 MB размера всего образа.

Ну что ж, меня эта цифра не устраивает, поэтому дальше буду собирать свой кастомный JRE, чтобы он тоже был slim и за счет этого весил как можно меньше.

Модули, jdeps и jlink

Для сборки кастомного slim JRE я буду использовать модульную систему, которая введена с 9-йверсии Java. Полное ее название — Java Platform Module System, или JPMS. На помощь также придут инструменты jlink и jdeps, которые поставляются вместе с JDK.

При использовании jlinkна выходе получается «урезанный» JRE, который будет включать только те модули, которые требует приложение и его зависимости, а все остальные модули просто не будут включены в сборку.

Прежде чем приступать к процессу сборки, нужно определиться, какие именно модули необходимы для запуска приложения. Для этого мы можем использовать инструмент jdeps. Он позволяет проанализировать JAR и вывести использующиеся модули. Но я бы хотел сразу прояснить некоторые моменты по этому инструменту и рассказать, почему я все же его не использую. Чтобы добиться правильного отображения использующихся модулей, надо потратить много времени, но каждый раз вылазит очередная ошибка, и ты пробуешь нагуглить решение. Например, возьмем следующую команду:

jdeps -cp "java -jar target/slim-docker-image.jar --thin.classpath" target/slim-docker-image.jar

Получается такой результат:

Как видим, есть модули not found, что не дает понимания, каких модулей в итоге не хватает. Изучая вопрос сборки JRE, я так и не смог добиться успешного вывода всех модулей из JAR, поэтому решил, что если даже после использования jdeps может броситься ClassNotFoundException, то почему бы самостоятельно не перебрать недостающие модули, запуская приложение на собранном JRE и анализируя stack trace? Тем более это не отнимает много времени, да и вообще, я уверен, что для других проектов не придется пересобирать новый JRE каждый день и даже каждый месяц. Это нужно будет сделать только в случае добавления новых зависимостей, да и то если они используют какой-то другой модуль, которого нет в сборке.

Итак, абсолютно для любого приложения требуется модуль java.base. Поэтому берем его и запускаем команду:

jlink --no-header-files --no-man-pages --compress=2 --strip-java-debug-attributes --add-modules java.base --output slim-jre

Подробнее обо всех параметрах можно почитать по ссылке, там все объяснено доступным языком.

Пробуем запустить приложение на собранном JRE:

Бросился ClassNotFoundException: java.beans.PropertyChangeEvent. Идем сюда, в строку поиска вводим java.beans.PropertyChangeEvent и смотрим на имя модуля:

Добавляем его к команде jlink:

jlink --no-header-files --no-man-pages --compress=2 --strip-java-debug-attributes --add-modules java.base,java.desktop --output slim-jre

В этот раз бросается ClassNotFoundException: javax.naming.NamingException.

Снова идем в поиск и ищем javax.naming.NamingException, добавляем его модуль java.naming. Повторяем манипуляции до тех пор, пока приложение не запустится.

Во время поиска модулей по какому-то из классов может быть так, что поиск не выдает результатов. Это значит, что ты пытаешься найти класс из модуля jdk.unsupported, поэтому берем и смело добавляем его к команде.

В итоге получился такой список модулей:

java.base,java.desktop,java.naming,java.management,java.security.jgss,java.instrument

Можем запустить приложение на собранном JRE и убедиться, что оно успешно работает, как и раньше:

Docker-образ с кастомным JRE

Берем за основу Dockerfile, который используется в openjdk, и модифицируем его таким образом, чтобы вместо установленного JDK использовался кастомный JRE. Ниже представлен уже готовый к использованию файл:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

FROM debian:buster-slim

RUN set -eux; \
	apt-get update; \
	apt-get install -y --no-install-recommends \
# utilities for keeping Debian and OpenJDK CA certificates in sync
		ca-certificates p11-kit \
	; \
	rm -rf /var/lib/apt/lists/*

# Default to UTF-8 file.encoding
ENV LANG C.UTF-8

ENV JAVA_HOME /usr/java/openjdk-13
ENV PATH $JAVA_HOME/bin:$PATH

# backwards compatibility shim
RUN { echo '#/bin/sh'; echo 'echo "$JAVA_HOME"'; } > /usr/local/bin/docker-java-home && chmod +x /usr/local/bin/docker-java-home && [ "$JAVA_HOME" = "$(docker-java-home)" ]

# https://jdk.java.net/
# > Java Development Kit builds, from Oracle
ENV JAVA_VERSION 13.0.2
ENV JAVA_URL https://download.java.net/java/GA/jdk13.0.2/d4173c853231432d94f001e99d882ca7/8/GPL/openjdk-13.0.2_linux-x64_bin.tar.gz
ENV JAVA_SHA256 acc7a6aabced44e62ec3b83e3b5959df2b1aa6b3d610d58ee45f0c21a7821a71

RUN set -eux; \
	\
	savedAptMark="$(apt-mark showmanual)"; \
	apt-get update; \
	apt-get install -y --no-install-recommends \
		wget \
	; \
	rm -rf /var/lib/apt/lists/*; \
	\
	wget -O openjdk.tgz "$JAVA_URL"; \
	echo "$JAVA_SHA256 */openjdk.tgz" | sha256sum -c -; \
	\
	mkdir -p "$JAVA_HOME"; \
	tar --extract \
		--file openjdk.tgz \
		--directory "$JAVA_HOME" \
		--strip-components 1 \
		--no-same-owner \
	; \
	rm openjdk.tgz; \
	\
	jlink --no-header-files \          --no-man-pages \          --compress=2 \          --strip-java-debug-attributes \          --add-modules java.base,java.desktop,java.naming,java.management,java.security.jgss,java.instrument \          --output /usr/java/slim-jre \    ; \    rm -r $JAVA_HOME; \    mv /usr/java/slim-jre $JAVA_HOME; \
	\
	apt-mark auto '.*' > /dev/null; \
	[ -z "$savedAptMark" ] || apt-mark manual $savedAptMark > /dev/null; \
	apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false; \
	\
# update "cacerts" bundle to use Debian's CA certificates (and make sure it stays up-to-date with changes to Debian's store)
# see https://github.com/docker-library/openjdk/issues/327
#     http://rabexc.org/posts/certificates-not-working-java#comment-4099504075
#     https://salsa.debian.org/java-team/ca-certificates-java/blob/3e51a84e9104823319abeb31f880580e46f45a98/debian/jks-keystore.hook.in
#     https://git.alpinelinux.org/aports/tree/community/java-cacerts/APKBUILD?id=761af65f38b4570093461e6546dcf6b179d2b624#n29
	{ \
		echo '#!/usr/bin/env bash'; \
		echo 'set -Eeuo pipefail'; \
		echo 'if ! [ -d "$JAVA_HOME" ]; then echo >&2 "error: missing JAVA_HOME environment variable"; exit 1; fi'; \
# 8-jdk uses "$JAVA_HOME/jre/lib/security/cacerts" and 8-jre and 11+ uses "$JAVA_HOME/lib/security/cacerts" directly (no "jre" directory)
		echo 'cacertsFile=; for f in "$JAVA_HOME/lib/security/cacerts" "$JAVA_HOME/jre/lib/security/cacerts"; do if [ -e "$f" ]; then cacertsFile="$f"; break; fi; done'; \
		echo 'if [ -z "$cacertsFile" ] || ! [ -f "$cacertsFile" ]; then echo >&2 "error: failed to find cacerts file in $JAVA_HOME"; exit 1; fi'; \
		echo 'trust extract --overwrite --format=java-cacerts --filter=ca-anchors --purpose=server-auth "$cacertsFile"'; \
	} > /etc/ca-certificates/update.d/docker-openjdk; \
	chmod +x /etc/ca-certificates/update.d/docker-openjdk; \
	/etc/ca-certificates/update.d/docker-openjdk; \
	\
# https://github.com/docker-library/openjdk/issues/331#issuecomment-498834472
	find "$JAVA_HOME/lib" -name '*.so' -exec dirname '{}' ';' | sort -u > /etc/ld.so.conf.d/docker-openjdk.conf; \
	ldconfig; \
	\
# https://github.com/docker-library/openjdk/issues/212#issuecomment-420979840
# https://openjdk.java.net/jeps/341
	java -Xshare:dump; \
	\
# basic smoke test
#	javac --version; \
	java --version

# "jshell" is an interactive REPL for Java (see https://en.wikipedia.org/wiki/JShell)
CMD ["jshell"]

В строке 47 я добавил создание кастомного JRE, в строках 54 и 55 удалил установленный JDK и вместо него поместил собранный.

В строке 51 можно расширять модули, которые будут нужны для других проектов.

Теперь самое интересное. Собираем образ и смотрим на его размер:

Получилось 141 MB вместо 409 MB, что не может не радовать.

Теперь можно отправить его, например, в Docker Hub или любое другое хранилище и использовать как основу для образа приложения.

Модифицируем Dockerfile-приложения

1
2
3
4

FROM rostyslavm/slim-jre:1.0.0
RUN mkdir -p /jar
COPY ./target/slim-docker-image.jar /jar/app.jar
ENTRYPOINT ["java","-jar","/jar/app.jar"]

В строке 1 я использую образ, который отправил в Docker Hub.

После сборки образа, используя вышеуказанный файл, получаем slim-вариацию, которая весит 159 MB вместо 427 MB:

Создаем контейнер и убеждаемся, что приложение успешно работает:

Спасибо за внимание! Буду рад получить фидбэк, это будет мотивировать меня писать и на другие темы.

Если остались какие-то вопросы, можно писать в комментариях к статье и стучать мне в Telegram.

Ссылки, на которые лучше таки нажать (по мнению автора), отмечены знаком (!)

Что-то вроде новостей

Jakarta EE 9 Release Plan. Интересует мнение читателей DOU. Насколько JEE/Jakarta актуальна сейчас? Используете ли в продакшен проектах? И почему не спринг?

Spring Framework maintenance roadmap in 2020 (including 4.3 EOL).

(!) Spring Data R2DBC goes GA. Всем побольше реактивности!

(!) Вышел Groovy 3.0и обсуждение этого факта на форуме DOU.

Java 14

JDK 14 is now in Rampdown Phase Two.

Java 14 Is in Feature-Freeze and Release Rampdown.

Records Come to Javaиз Java magazine.

Java 14 Feature Spotlight: Records.

Почитать и посмотреть

(!) State of Valhalla Section 1: The Road to Valhallaи Section 2: Language Model.

Programming the GPU in Java, если кто устал от унылого энтерпрайза.

И в догонку Deep Java Library: New Deep Learning Toolkit for Java Developers.

Performance Testing Spring Boot with Gatling. Gatling — довольно удобный инструмент для нагрузочного тестирования. Статья в (маркетинговом) блоге Opsian, возможно, сам тул также кому-то будет полезен.

Introducing flaky test mitigation tools for Gradle. Как Gradle помогает решать проблему флаки-тестов. Довольно актуально, если пишете UI-тесты.

Staring Into My Java Crystal Ball 2020от Simon Ritter.

(!) The Future of Spring Cloud’s Hystrix Project. Если коротко, то будущее называется Resilience4j.

Unit Test Your Architecture with ArchUnitи Validating code and architecture constraints with ArchUnit. Уже не первый раз слышу про ArchUnit, и с каждой итерацией все меньше вижу в нем смысл. Если кто использует, поделитесь сценариями использования.

Don’t expose your JPA entities in your REST API.

Два видео с re:Invent 2019: Building microservices with AWS Lambdaи Best practices for AWS Lambda and Java.

← Предыдущий выпуск: Java дайджест #45

В выпуске: 10 заповедей iOS-разработки, книга по SwiftUI, план на Swift 6, памятка по работе с форматтерами, много библиотек и немного про функциональщину.

Статьи

Mac Pro Xcode compiling times
Mac Pro стоит намного дороже топового Macbook или Mac Mini, но насколько же он быстрее компилит? Спойлер: не намного быстрее.

Thinking in SwiftUI
Вот и obj-c.ioподоспели с книгой по SwiftUI. Обещают 5+ часов видео, примеры кода, но это все за $79.

Downloading and Caching Images in SwiftUI
Классическая задача — скачать, закешировать и отобразить картинку. Только теперь на SwiftUI.

Exploring Swift 5.2’s new functional features
Не могу сказать, что мне нравятся изменения в Swift 5.2, но в любом случае классно, что язык развивается.

On the road to Swift 6
Продолжая тему — уже есть план на Swift 6.

2020 iOS Conference Calendar
Год только начался, а куча конференций уже начали подготовку.

The iOS internationalization basics I keep forgetting
Мощная памятка по работе с форматтерами, локалями, тайм-зонами.

Practical Functional Programming in Swift: The Fundamentals
Лайтовое чтиво про функциональное программирование. Чистые функции — ван лав.

The Ten Commandments of iOS Development
10 заповедей iOS-разработки. Все по делу и нужно периодически к ним возвращаться.

Can You Answer This Simple Swift Question Correctly?
Так люблю подобные викторины. Может и самому что-то такое сделать?

Tips & tricks for iOS app debugging.
Брейкпоинты, логи — это, конечно, хорошо. Чтобы использовали chisel, я еще не видел, но выглядит как маст хэв.

Optionals in Swift Objective-C Interoperability
С Optional и Objective-C не все так просто, и иногда было уж больно странное поведение.

Swift fatalError is a fatal error
fatalError сливает вашу структуру проекта!

Building ViewModels with Combine framework
RxSwift не нужен или пишем mvvm с помощью Combine.

Библиотеки

UBKAccessibilityKit
Библиотека, которая облегчают работу и валидацию accessibility. Репозиторий оформлен так себе, но идея неплохая.

Puma
В последнее время все больше кайфую от CLI на Swift. Типа Fastlane на Swift.

Swift Embedded
Swift для железок. Почему бы и нет.

Barber
Берем один экран приложения, делаем из него отдельное приложение и запускаем.

Storyboard to SwiftUI
Сториборды мертвы. Да здравствует SwiftUI?

SwiftPowerAssert
Максимально детальное описание ассертов в тестах, которые упали.

Sitrep
Анализатор кода на Swift. Показывает количество файлов, протоколов, количество строк кода, импорты. Не так много всего, но все равно неплохо.

Finger Massage
Самое странное, что я видел за последнее время. Массаж для пальцев с помощью тачпада с поддержкой Force Touch.

Poes
В Xcode 11.4 завезли тестирование push-уведомлений в симуляторе, и вот уже удобная CLI утилита для этого. По сути, simctl + запись файла во временную директорию.

Видео

BA: Swiftable

SwiftConf ’19

dotSwift 2020

← Предыдущий выпуск: iOS дайджест #35

Закордонні поїздки — не рідкісна практика в IT-компаніях. Тож ми вирішили розпитати компанії та з’ясувати, чому і куди їздять, за що спеціалістам можуть організувати поїздку в якості винагороди, хто оплачує відпочинок та що в програмі. Спочатку про найцікавіше.

У всіх випадках поїздки виконують роль тимбілдингів — спілкування, відпочинок, розваги. Компанії, які мають розподілені команди, наприклад Railsware, iDeals Solutions, використовують поїздку ще і як нагоду перезнайомити співробітників. Майже усі компанії їздять у подорож традиційно раз на рік.

Знайшлося кілька кейсів, коли співробітники отримують поїздку як винагороду. Наприклад, команди appflame та BetterMe вирушають у подорож (Балі, Шри-Ланка, Іспанія тощо), щойно досягнуть визначених бізнес-результатів, Tranzzo організувала подорож до Франції за перемогу у внутрішньому хакатоні, а Symphony Solutions винагороджує найлояльніших співробітників: за 5 років роботи в компанії вони їдуть до Амстердама, а за 10 — до Нью-Йорка.

Найчастіше компанії покривають перельоти, проживання та активності, які самі організовують. У деяких випадках оплачують навіть харчування. Цікавий кейс у Binary Studio. Компанія оплачує екскурсії, роботу гідів, чайові, фуд- та паб-краули, а ось перельоти і проживання — за кошт учасників (крім джуніорів, їм покривають 50%). Судячи з того, що в компанії відбулося вже 6 поїздок у такому форматі, він цілком дієвий.

Щодо того, чи можна брати в подорож членів родини та дітей — кожна компанія вирішує по-своєму. Хтось наголошує на тому, що подорож організовують передусім для того, щоб співробітники спілкувалися між собою, тож «+1» не беруть у будь-якому разі. Деякі компанії беруть, але члени родини самі сплачують подорож, а є й ті компанії, що покривають і їхні витрати повністю. У SMART business подорож була з самого початку задумана як об’єднувальний сімейний відпочинок — компанія бере в поїздку та покриває витрати всіх членів родини. І таким чином поки що б’є рекорд (принаймні в цьому огляді) з кількості осіб, які брали участь в одній поїздці — 320 людей їздили до Вільнюса (Литва)!

Щодо програми, крім традиційних екскурсій, вечірок та розваг, деякі компанії використовують подорож як привід підвести підсумки за рік, поділитися зі співробітниками планами на наступний рік, провести кілька робочих майстер-класів. Та в більшості в планах передусім відпочинок. Є компанії, які розписують план подорожі майже похвилинно, а й ті, які віддають майже весь час на розсуд людей. Наприклад, у YouScan планують лише один-два загальні заходи на всю подорож, щоб відпочинок був невимушеним.

Нижче читайте деталі щодо кожної компанії. Обирайте, який формат подорожі вам найбільше до вподоби та діліться в коментарях.

Astound Commerce

Закордонні поїздки проводять кілька років поспіль. Найпопулярніші напрямки: Угорщина, Туреччина, Єгипет, Греція та Словаччина. Були й поїздки в Індію.

Серед цілей закордонних тимбілдингів:

• підвищення мотивації в команді проєкту (зокрема й нових членів команди);
• винагорода за ефективну й успішну роботу над проєктом;
• поліпшення загальних результатів роботи, якщо проєкт зараз триває;
• поліпшення комунікації, балансу взаємовідносин між усіма членами команди.

Зазвичай у поїздці беруть участь від 10 до 30 спеціалістів.

Поїздки здебільшого фінансуються із загального корпоративного бюджету на тимбілдинги з можливістю додаткового залучення коштів (бюджет проєкту/компанії або кошти тих учасників команди, які погоджуються на перевищення лімітів). Члени родин спеціалістів дуже рідко приєднуються до таких подорожей, але бувають винятки, і в такому разі вони їдуть власним коштом.

Що саме оплачує в поїздці компанія, вирішується кожного разу окремо. В більшості випадків покривають витрати на транcпорт, проживання, вечері та активності.

Плануванням активності, погодженням усіх дозволів та пошуком додаткових бюджетів здебільшого опікується проєктний менеджер, зацікавлений в ефективній роботі своєї команди. Організацію тимбілдингів для спеціалістів забезпечує фахівець з Events-команди. Якщо група невелика, проєктний менеджер організовує всю поїздку самостійно, адже він/вона може швидко зібрати всю інформацію та побажання від своєї команди.

Як правило, поїздка триває близько трьох днів. Дати й період вибирають такі, що підходять більшості членів проєктної команди. Це може охоплювати й вихідні, й державні свята. Переважно програма містить екскурсію містом, популярні туристичні маршрути.

SMART business

Здійснили 3 закордонні подорожі: до Угорщини, Словаччини й Литви.

Ідея належить керівникам компанії — зробити об’єднувальну сімейну подорож, щоб до неї долучилися діти й «половинки» співробітників — разом відпочити, добре провести час, дізнатися одне про одного щось нове поза роботою. Запрошують усіх колег та членів їхніх родин (останнього разу брали участь 320 осіб). Поїздки почали проводити з 2012 року, перша закордонна була 2014-го.Проводять їх традиційно раз на рік. Намагаються об’єднувати з українськими святами й беруть 1 робочий день.

Компанія оплачує для співробітників та їхніх близьких транспорт, проживання зі сніданками, усі заплановані активності в програмі й завершальну вечірку.

Поїздка триває 4 дні. У програмі є колективні активності (байдарки, тролей, гольф), екскурсії, квізи, забіги на 1, 3, 5 км, конференція, вечірка й дискотека, є вільний час на розсуд співробітників. До загальних активностей не примушують долучатися, але в компанії кажуть, що беруть участь майже всі.

Для кожної подорожі продумують головну ідею. Востаннє це була Grand White Party: 300+ учасників біля озера на тлі великого готелю білого кольору. Усі, включно з дітьми, одягнені відповідно до дрес-коду.

SPD-Ukraine

Провели дві закордонні поїздки в Туреччину (2011) та Єгипет (2015). Тепер їх не організовують, оскільки компанія значно виросла й складно везти в подорож усіх. Зараз співробітники об’єднуються в групи за бажанням і подорожують самостійно.

Поїздки — це формат корпоративного тимбілдингу. Їздили, щоб відпочити, поспілкуватися, провести час у неформальній атмосфері, познайомитися спеціалістам з різних проєктів. Запрошували всіх охочих (у Єгипет полетіла половина команди).

Під час поїздки в Єгипет компанія оплачувала 60% від вартості туру. Могли приєднатися й члени родин, вони оплачували свій тур самостійно.

Поїздка тривала 5 днів. У програмі пропонували екскурсії на вибір, настільні та спортивні ігри. Кожен обирав те, що йому до вподоби.

Symphony Solutions

Здійснили 4 поїздки. Відвідали Амстердам і Нью-Йорк.

Мета — винагородити найлояльніших співробітників компанії. Поїздка в Амстердам — для тих, хто з компанією 5 і більше років; до Нью-Йорка їдуть ті, хто в компанії понад 10 років. Наразі понад 50 людей відвідали Амстердам, а двоє побували в Нью-Йорку.

Поїздки проводять щороку, починаючи з 2016-го.Ідея належить нідерландцю Тео Шнітфінку, засновнику компанії, який прагнув поділитися зі співробітниками особливостями своєї культури. Цікаве питання: чому для другої поїздки вибрали Нью-Йорк? Це місто голландці заснували як фортецю Новий Амстердам. Лише згодом, коли місто захопили англійці, воно було перейменоване на Нью-Йорк.

Поїздки дають змогу спеціалістам побачити, що саме стало натхненням для створення Symphony Solutions. Усі офіси в різних локаціях оформлено в стилі Зансе-Сханс, невеликого села-музею просто неба поблизу Амстердаму, яке співробітники відвідують під час поїздки. Наприклад, воно надихнуло додати в інтер’єр офісу вітряки й дерев’яні будинки, що виконують роль офіс-румів.

Компанія оплачує витрати на візу, авіаквитки, проживання та страхування. Долучатися можуть і члени родини, проте свої витрати вони покривають самостійно.

Поїздка в Амстердам зазвичай триває 3 дні, їдуть групами по 12-15 осіб;у Нью-Йорк — 1 тиждень, 1-2 особи.Компанія надає певну суму коштів на поїздку, якими спеціаліст може розпорядитися самостійно. За бажанням можна докласти свої кошти та залишитися в Нью-Йорку на 2 тижні. Так співробітниця, що відвідала Нью-Йорк, окрім музеїв і визначних пам’яток, подивилася мюзикл «Чикаго» на Бродвеї та потрапила на концерт Мадонни.

В Амстердамі в програмі багато музеїв і прогулянки містом.

appflame

За кордон подорожували 6 разів. Відвідали Чехію, Єгипет, Кіпр, Шри-Ланку та двічі Іспанію.

Поїздки влаштовують як винагороду для команди за досягнення бізнес-результатів та як мотивування. Щойно досягають визначених цілей — бронюють квитки. Уперше з’їздили до Праги 2017 року з ініціативи CEO. У компанії кілька проєктів, у кожного свої KPI. У подорож їде завжди команда всього проєкту, без членів родин.

Компанія оплачує переліт, п’ятизіркові готелі All Inclusive, екскурсії, трансфер, солодощі в дорогу, страхування.

Подорож зазвичай триває 3-4 дні,до Шри-Ланки їздили на 7 днів. Під час планування подорожі вибирають декілька варіантів екскурсій, опитують команду та бронюють те, що вибрала більшість. Під час подорожі завжди заплановано одну екскурсію, яку просять відвідати всіх. Щовечора компанія разом вечеряє, обмінюючись враженнями.

BetterMe

Мандрували за кордон двічі: 2018 року до Шри-Ланки, 2019-го —на Балі.

Поїздки організовують як винагороду співробітникам за бізнес-досягнення. У компанії впевнені, що подорожі підвищують згуртованість і рівень довіри в команді. Запрошують усю команду (наприклад на Балі їздили 65 осіб без членів родин).

Компанія оплачує дорогу, проживання, їжу, заплановані активності.

Подорож на Балі тривала 4 дні. У програмі були різні види активностей: відвідали культурні та природні пам’ятки (древні храми, вулкан, ліс мавп), навчалися серфінгу, спостерігали за заходом сонця, спробували снорклінг тощо.

Binary Studio

Усього поїздок було 6. Щоразу це 2-3країни та 3-4 міста.За цей час відвідали Німеччину, Францію, Італію, Нідерланди, Португалію, Угорщину, Польщу, Австрію, Бельгію, Словаччину.

Мета поїздок — відпочити, провести час разом з командою та отримати нові враження. Уперше в подорож вирушили 2013 року різдвяною Європою. Після цього вирішили проводити подорож щороку як виїзний корпоратив. Зазвичай її організовують у грудні на різдвяні свята. Їдуть усі охочі співробітники, найчастіше це третина компанії (в останній подорожі взяли участь 25 осіб), але без членів родин.

Здебільшого за одну поїздку компанія оплачує 3-4 екскурсії,роботу гідів, чайові, фуд- та паб-краули. Джуніор-девелоперам покривають 50% витрат на дорогу та проживання. Решта учасників оплачують вартість перельотів і проживання самостійно.

Як правило, поїздка триває 5-6 днів.Найдовша тривала 7 днів. People Operations команда розробляє декілька варіантів маршрутів, з яких вибирають оптимальний за вартістю та цікавістю. Як кажуть у компанії, маршрут планують ретельно й складають похвилинний розклад. Зазвичай програма містить велотур містом, відвідування музеїв, різдвяних ярмарків, спільні ланч і вечерю. В основному всі учасники дотримуються програми та майже весь час проводять разом.

Сodeminders

Здійснили 2 поїздки — до Словаччини та Єгипту.

Мета — тимбілдинг, підтримка командного духу. Поїздки почали проводити з 2018 року за ініціативи керівників компанії замість традиційних передноворічних корпоративів. Запрошують усіх спеціалістів.

Компанія оплачує проїзд, харчування, проживання. Додаткові активності — коштом співробітників (наприклад, квитки в музеї, картки на лижні підйомники). За бажанням з собою можна взяти членів родини, включно з дітьми. Вони покривають витрати самостійно.

Зазвичай поїздка триває 4 дні. Перед подорожжю здебільшого проводять опитування серед співробітників щодо їхніх побажань. Усі активності — за бажанням.

iDeals Solutions

Здійснили 3 поїздки — до Словаччини (Татранська Ломниця), Греції (Халкідіки) й Туреччини (Каппадокія).

Позаяк офіси компанії є у 8 країнах, мета подорожі — не лише відпочинок, а й знайомство між собою всіх членів команди. Їздять починаючи з 2018 року (на той рік також припало 10-річчякомпанії, тому поїздок було навіть дві). Поки що подорожі організовують постійно з однаковою періодичністю, але в компанії зазначають, що думають над тим, як пов’язати закордонні тимбілдінги з досягнутими результатами. До участі запрошують усю команду (у Туреччині, наприклад, побувало 120 людей), однак без членів родини. Якщо в останню мить хтось через особисті обставини не може поїхати в подорож, його місце пропонують новачкам, що вже підписали офер, але ще не вийшли на роботу.

Компанія оплачує перельоти, таксі, розважальну програму, індивідуальні затрати на їжу, напої, платні розваги.

Середня тривалість поїздок — 3-4 дні.Програму складають так, що майже завжди є можливість вибрати з кількох активностей. У Каппадокії, наприклад, літали на повітряних кулях, каталися на лижах і сноубордах на гірськолижному курорті, ходили на екскурсію до печер і провели тематичну вечірку. Як зазначають у компанії, тимбілдінг у Каппадокії посів друге місце на конкурсі Best Event Awards World 2019 у категорії «Найкращий тимбілдінг», що проходив у Мілані.

Команда продажів також проводить робочі зустрічі для обговорення планів і підсумків своєї діяльності. Запланований у програмі й вільний час.

InterLink

Здійснили 4 поїздки, з них 3 до Туреччини й 1 до Єгипту.

Подорожують для об’єднання колективу, починаючи з 2016 року, а також святкують день народження компанії, який припадає на 29 травня. Запрошують усіх охочих співробітників, зазвичай їде 80 осіб. Можуть приєднуватися також члени родин разом з дітьми.

Компанія оплачує трансфер, авіаперельоти та проживання в готелі з харчуванням All Inclusive або Ultra All Inclusive. Коштом учасників зазвичай екскурсії та шопінг.

Поїздка триває тиждень. У програмі — спільні екскурсії, pool parties, ігри в «мафію» та «крокодила», вечірні посиденьки зі спогадами про шлях компанії, ретроспективи по проєкту з командою. Участь у цих івентах не є обов’язковою, проте, як стверджують у компанії, співробітники активно долучаються.

Yukon Software

Здійснили 5 подорожей. Відвідали Угорщину, Польщу, Австрію, Словаччину, Німеччину, Латвію, Литву, Естонію, Чехію, Румунію, Молдову й Нідерланди (по кілька країн за раз).

Мета — заохочення співробітників, пізнання світу, відпочинок. Корпоративні подорожі проводять з 2014-гороку постійно раз на рік. Спершу їздили взимку, тепер у травні. Запрошують усіх співробітників. Бере участь приблизно 50-60осіб + 50-60«половинок» / братів / сестер / дітей. Наприклад, 2019 року їхало близько 120 людей — два туристичні автобуси.

Компанія оплачує транспортування, проживання, екскурсії та сніданки. Додаткові витрати — коштом співробітників. Можна брати членів сімей, але вони оплачують поїздку самі.

Здебільшого подорож триває 7-8 днів,лише винний тур до Молдови тривав 2 дні. У програму туру зазвичай входять екскурсії (містом, у музеї, замки), відвідування термальних вод або аквапарків, дегустація національної кухні, спа-центри, парки атракціонів і дискотеки.

P-Product

Здійснили 7 подорожей. Відвідали Грузію, Ізраїль, Нідерланди, Чехію, Італію, Іспанію, Кіпр, Грецію.

Мета — відпочинок, тимбілдинг, налагодження комунікації між колегами. Почали їздити з ініціативи одного з перших співробітників компанії. Подорожують постійно, раз на рік на травневі свята. Беруть участь усі охочі (зазвичай до 30 учасників).

Компанія оплачує квитки на літак, трансфер (за потреби), проживання в готелі. Усе інше — коштом співробітників. Можна брати членів родин, але вони оплачують подорож самостійно.

У середньому поїздка триває 5-7 днів.Іноді це одне місто, де команда проводить усі дні, а іноді мінітур декількома містами або країнами. Країну вибирають методом колективного голосування. Під час поїздки передбачено колективні заходи (екскурсії, естафети, дегустації) й один вільний день для особистого відпочинку.

Railsware

Усього здійснили 4 поїздки. Перша була до австрійських Альп 2016 року. Згодом вирішили спробувати літній формат і вже побували в Греції, Італії та Хорватії.

Понад третина співробітників Railsware працює віддалено, тож поїздка — це спосіб познайомитися, поспілкуватися, дізнатися новини компанії й отримати нові враження. Подорожують постійно, раз на рік. Участь беруть усі без винятку full-time-співробітники, які пройшли випробний термін на час подорожі. Можна брати із собою членів сімей включно з дітьми. 2019 року їздило 130 осіб, якщо враховувати й членів сімей.

Компанія оплачує витрати співробітника та його/її партнера: перельоти, проживання в готелі, медичне страхування, харчування (сніданок і вечеря), а також організацію командоутворювальних заходів. Витрати на дітей і додаткові «плюшки» (номер з краєвидом на море, екскурсії, додаткове харчування) співробітники покривають самостійно.

Подорож триває 7 днів. У програмі 2-3бізнес-конференції (презентація результатів команд і стратегії подальшого розвитку, робота в групах над удосконаленням різних аспектів життя компанії), майстер-класи й тренінги з hard і soft skills, спільні сніданки й вечері з використанням рандомайзеру (розробили тул для випадкового вибору сусідів за столиком, щоб команда змогла краще роззнайомитися), великі командоутворювальні заходи (pool party, похід в аквапарк, квести тощо), спортивні заходи (волейбол, футбол, баскетбол), заходи, організовані співробітниками (наприклад, ранкова йога під керівництвом одного з інженерів), екскурсії та особистий час.

Під час планування подорожі орієнтуються на побажання команди, тож проводять опитування й збирають ідеї заздалегідь.

Synebo

Здійснили 2 поїздки — до Туреччини та Єгипту.

Подорожують з метою тимбілдингу раз на рік з ініціативи СЕО компанії. Перша спільна поїздка відбулася 2017 року до Карпат, 2018-гопоїхали до Туреччини (35 осіб), а 2019-го —до Єгипту (45 осіб). Запрошують усіх охочих співробітників.

Компанія оплачує переліт, проживання в готелі та харчування, усі екскурсії. Додаткова розважальна програма оплачується співробітниками. Членів родин не беруть, оскільки поїздки організовують для спілкування команди.

Зазвичай подорож триває 4 дні. Для подорожі вибирають дні, на які припадають офіційні державні свята, щоб не пропускати багато робочих днів.

Tranzzo

Усього було 4 подорожі. Відвідали Францію, Польщу, Німеччину й Нідерланди.

Поїздки — це частина постійного плану з тимбілдингів, а також винагорода. Зазвичай це пригода для невеликої частини команди — 1-3відділи (від 4 до 15 осіб).

Крім покращення спілкування в команді, співробітники перевіряють, чи працює для них формат віддаленої роботи. Важливо, щоб під час подорожі мандрівники хоча б раз на день виходили на зв’язок і готові були долучитися до робочого процесу, якщо виникне якийсь форс-мажор. У компанії досліджують, чи може команда бути ефективною віддалено, і використовують цю інформацію, щоб потім надавати співробітникам опцію гнучкого графіка так, щоб він був зручним для всієї команди. Так, 2018 року 4 співробітники відвідали Німеччину й Нідерланди, а 2019 року 5 співробітників — Польщу.

Подорож як винагорода — це приз за перемогу у внутрішніх хакатонах. Таку традицію започаткували минулого року. Суть хакатону в тому, що співробітники об’єднуються в команди (за бажанням) й розробляють продукт, що так чи інакше пов’язаний зі сферою фінансових технологій. Для реалізації мають 2 місяці. Потім кожна команда презентує своє рішення журі. До журі входять учасники команди Tranzzo. У хакатоні 2019 винагородою стала подорож до Франції. Журі сподобалися обидва проєкти, тому поїхали дві команди. Подорож тривала 7 днів. 13 осіб проїхали майже 3000 км і побували в понад 10 містах Франції.

Компанія завжди оплачує дорогу й проживання. Інші пункти — варіативно — у кожній поїздці по-різному. Опції «+1» немає, оскільки поїздки розглядають як нагоду провести час з колегами.

У програмі може бути відвідування конференцій, екскурсії.

ViSoft

Здійснили 5 закордонних подорожей. Відвідали Німеччину, Італію, Чехію, Словенію, Нідерланди.

Мета — знайомство й налагодження комунікації між співробітниками з різних країн світу, розповідь про досягнення компанії та плани на майбутнє. Поїздки розпочалися майже відразу після створення львівського офісу 2006 року. Ініціатором став засновник компанії. Тимбілдинги проводять раз на два роки, їдуть усі охочі співробітники, однак без членів сімей.

Компанія оплачує квитки на літак/автобус, готелі, вечері й музеї. Видає добові, щоб люди мати змогу придбати собі обід під час прогулянки. Співробітникам потрібні кошти на власні розваги, шопінг, сувеніри тощо.

Зазвичай такі поїздки тривають до 4 днів. Найдовшою була подорож до Мілана, на тиждень, адже там поєднали й тимбілдинг, і всесвітню виставку, на якій презентували продукт компанії, щоб співробітники дізналися, як усе це відбувається.

Як правило, поїздка складається з офіційної частини й вільного часу. Офіційна частина — загальні збори, презентація досягнень компанії за два роки, воркшопи, відвідування магазинів кераміки клієнтів (у компанії розробляють програму, що допомагає створювати дизайн ванних кімнат). До неофіційної частини входять прогулянки, екскурсії та спільні вечері. Складають приблизний список музеїв і місць-мастхевів для візиту, але співробітники вирішують самостійно йти туди з усіма, чи піти за своєю програмою.

YouScan

Відбулося 2 подорожі — в Болгарію й Чорногорію.

Компанія YouScan має декілька локацій (Київ, Харків, Дніпро, Москва). Поїздка дає змогу всім перезнайомитися, отримати спільні враження і, найголовніше, відпочити. Подорожують раз на рік, переважно влітку. Запрошують усіх співробітників, навіть тих, хто нещодавно приєднався до команди. Болгарію відвідало 43 співробітники, Чорногорію — 80.

Компанія оплачує авіаквитки, трансфер у готель, проживання у двомісних номерах, харчування в готелі й під час виїзних заходів, медичне страхування. Членів сімей співробітників не беруть навіть власним коштом, оскільки мета поїздок — поспілкуватися з членами команди.

Поїздка в Болгарію тривала 3 дні, у Чорногорію — 5 днів. У підготовці активно беруть участь топменеджери: щодо вибору напрямку, бюджету, програми й партнерів. На всіх етапах діляться інформацією з командою. У програмі лише відпочинок: жодних презентацій, стратегічних сесій або звітів не планують. У компанії зазначають, що намагаються не перегинати з плануванням, щоб відпочинок не був вимушеним. Зазвичай організовують не більше ніж 1-2загальних активності, на кшталт катання на яхті, поїздки до аквапарку або вечірки, але участь у жодній з них не обов’язкова. Решта часу — на власний розсуд людей.

Сидячий спосіб життя і гіподинамія, властиві більшості IT-фахівців, призводять до цілої низки проблем, серед яких метаболічний синдром, хвороби судин, геморой і, звичайно, болі у спині.

Ця стаття — четверта з серії матеріалів на DOU, яку присвячено здоров’ю. Тут ви знайдете поради від ортопедів і травматологів щодо симптомів та профілактики захворювань опорно-рухового апарату, а також кейси від ІТ-спеціалістів і HR. Уже опубліковано статті з загальними порадами, рекомендаціями неврологата психологів.

Нагадуємо: самолікування може зашкодити, тому в будь-якому разі радимо звертатися до лікарів. Також важливо пам’ятати, що універсальних порад не існує, тож не варто сприймати цей текст як абсолютну істину. Усе індивідуально.

Ілюстрація Каталіни Маєвської

Чому болить спина

Як розповів Антон Білостоцький, лікар ортопед-травматолог, кандидат медичних наук, керівник медичного центру КІНЕЗІО, причин для болю в спині може бути багато. Щоб відповісти на запитання, чому ж болить спина, варто почати з анатомії.

Спина, якщо спрощувати, складається з хребта та м’язів, які цей хребет фіксують. Уся ця конструкція переплетена нервами, які передають електричні імпульси з мозку до тканин і від тканин до мозку. Коли в м’язах або хребті виникають ті чи інші проблеми, запалення чи гіпертонус, больові імпульси передаються по нервах у мозок, і людина відчуває біль у спині.

За підтримку хребетного стовпа в фізіологічному, тобто правильному положенні відповідають паравертебральні м’язи. Розрізняють 4 шари цих м’язів, при цьому за стабілізацію тіл хребців відповідає найглибший шар, що знаходиться в безпосередній близькості до хребта. Ці м’язи не дають хребцям зміщуватися в неправильному положенні, вони здатні довгий час утримувати положення хребта при статичному навантаженні, тобто сидячи або стоячи. Стан цих м’язів дуже важливий для правильного функціонування хребта, оскільки вони є структурним елементом хребта, а також у прямому сенсі годують хребет. При сидячій роботі і нестачі руху ці м’язи не отримують достатнього навантаження і живлення, слабшають і коротшають. Щоб компенсувати слабкість паравертебральних м’язів і стабілізувати хребет, тіло постійно напружує інші, більш поверхневі, не пристосовані до цієї роботи м’язи спини. Від постійних патологічних навантажень і недостатнього розслаблення м’язи спини болять.

Спочатку з’являється біль у м’язах, це ниючий біль у попереку, що посилюється наприкінці робочого дня. Сам по собі цей біль усунути досить просто — за допомогою теплових процедур, масажу або препаратів-міорелаксантів, але цей біль — це перший «дзвіночок» про те, що ваша спина потребує допомоги. При цьому такі м’язові болі будуть з’являтися тим швидше, чим менше м’язової маси у конкретної людини (у астеніків м’язові болі з’являються в кілька разів частіше, ніж у нормо- та гіперстеніків) та чим гірше «налаштоване» робоче місце фахівця. Нижче ми докладніше розглянемо принципи «правильного» робочого місця.

Захворювання опорно-рухового апарату

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

Викривлення хребта: сколіоз та сколіотична постава

Сколіоз діагностується у 2% пацієнтів і характеризується зсувом хребців відносно вертикальної осі, що призводить до патологічних змін усього організму. Перекіс кісток тазу — головна ознака.

Сколіоз у дорослих виникає внаслідок:

• захворювання нервової та м’язової систем;
• порушення метаболізму;
• патології сполучних тканин;
• травм.

Здебільшого з’ясувати причину розвитку сколіозу неможливо.

Сколіотична постава — це не сколіоз.Якщо напружуючись, спину можна тримати рівно певний час, а асиметрія помітна лише тоді, коли людина розслаблена, це означає, що причиною хвороби є нерівномірність навантаження м’язів, слабкість м’язового корсету, який підтримує хребет. Глибокі м’язи більш напружені. Сидяча робота в неправильному положенні посилює неприємні відчуття у спині, виникає біль у шиї.

Симптоми обох хвороб схожі. Для сколіозу та сколіотичної постави характерні такі прояви:

• плечі та лопатки знаходяться на різній висоті;
• в області талії спостерігаються вигини різного ступеня;
• ребра з одного боку помітно випирають.

Деякі прояви хвороби на перших стадіях помітить лише лікар під час огляду та проведення спеціальних тестів. Фахівець визначить вид та форму викривлення, ступінь деформації.

Під час лікування сколіозу важливо позбутися асиметрії. Особливу увагу приділяють м’язам: деякі розслаблюють, а інші навпаки — потребують зміцнення.

Остеохондроз: міф чи справжня хвороба

Остеохондроз — це не захворювання, а фізіологічне старіння опорно-рухового апарату. Воно виражається в дегенеративно-дистрофічних змінах хрящових тканин. З плином часу втрачається здорова структура хребців та дисків, зникає природна еластичність останніх. Функціональність порушується, і біль тут як тут. Безперечно, поліпшити самопочуття можливо, якщо змінити стиль життя і регулярно займатися профілактикою під наглядом фахівців.

Зауважимо, що даний стан ніяк не пов’язаний з відкладенням солей, хоча така ідея вельми популярна.

Шийний остеохондроз — бич працівників IT-сфери. Останнім часом на біль у шиї скаржиться навіть молодь, але не поспішає до лікарів.

Остеохондроз поперекового відділу хребтаі не тільки стає причиною серйозних травм та патологій — протрузій, гриж, викривлень, якщо не взяти його під контроль.

Звідки береться хвороба? Окрім вікових змін, проблема виникає при порушеннях у процесі обміну речовин у тканинах, що оточують хребці. Таке трапляється внаслідок малорухливого способу життя (сидяча робота). Також причиною може бути спадковість, асиметричні навантаження на хребет, травми.

Симптоми остеохондрозу:

• постійний біль ниючого характеру, який посилюється під час навантажень;
• спазми м’язів;
• погіршується рухливість хребта.

Треба зауважити, що біль виникає в уражених ділянках та частинах тіла, що їх оточують. Наприклад, у разі шийного остеохондрозу — це головний біль, а грудного — дискомфорт в області серця. Лікування остеохондрозу — довгий та поступовий процес, але він того вартий.

Грижі та протрузії: операція — не єдиний вихід

Давайте розберемося у термінах. Коли стінки міжхребцевого диску лише випинають, і фіброзне кільце залишається цілим — тоді кажуть про протрузії міжхребцевих дисків. Це початкова стадія грижі. Якщо ж кільце таки розривається, тоді діагноз звучить як міжхребцева грижа.

Причиною таких несправностей може бути як низька активність, неправильне положення під час роботи, так і тяжка фізична праця. Працівникам IT-сфери, які мало рухаються, варто замислитися та почати посильні тренування, якщо ще немає болю.

Чому протрузіяне болить? Біль з’являється тоді, коли защемляється нервовий корінець. Доводити до такого стану лікарі не радять. Та і лікування протрузії на ранніх етапах не потребує хірургічного втручання.

Частіше за все проблеми виникають у поперековому відділі хребта. Слід уважно поставитися до таких симптомів:

• головний біль;
• болі у спині;
• неприємні відчуття у поперековій зоні — скутість руху, «простріли», печіння;
• оніміння, поколювання, порушення чутливості кінцівок;
• біль, який виникає не лише в хребті, а й водночас в руках чи ногах;
• зменшення м’язової спроможності кінцівок та тіла — слабкість, втрата еластичності, рухливості.

Грижа — серйозне ускладнення протрузії

Лікування грижі — непросте завдання, але фахівці можуть допомогти пацієнтам без скальпелю. Підхід базується на нормалізації кровообігу та живлення дисків, які розташовані між хребцями.

Грижа поперекового відділу хребта — найбільш поширена. Для неї характерні хронічні та гострі болі не тільки в попереку, а й у різних частинах ноги.

Симптоми грижі хребта залежать від того, в якій зоні знаходиться уражена ділянка. Вони схожі з клінічною картиною протрузій. Неприємні відчуття виникають внаслідок компресії нервових корінців, а також перенапруження та запалення м’язів, які не спроможні розслабитися (міофасціальний больовий синдром).

Не відкладайте лікування на потім!

Лікування спини базується на комплексному послідовному підході. Мета — зміцнення суглобів та хребта. Для цього сучасна медицина використовує такі методи:

• корекція хребта — методика під назвою «короткий важіль»;
• міофасціальний (глибинний) масаж;
• фізіотерапія (включно з магнітотерапією, електротерапією, терапією лазером);
• ЛФК — лікувальна фізкультура;
• кінезіотерапія — заняття на медичних тренажерах, завдяки яким можна оцінити стан організму пацієнта та підібрати оптимальне дозоване навантаження.

За потреби призначають медикаментозне лікування, щоб полегшити стан пацієнта.

Послідовність та тривалість лікування залежить від стану пацієнта і визначається індивідуально. Головне — дотримуватися режиму, який рекомендує спеціаліст. Корисно регулярно виконувати фізичні вправи для підтримки досягнутих результатів.

«Швидка допомога» при болю в спині

Якщо спина дуже болить, а терміни релізу не дозволяють піти до лікаря або на масаж, скористайтеся лайфхаком. Встановіть у телефоні нагадування кожні дві години, і, як тільки час прийшов, встаньте з-за столу, потягніть поперек — нахил вперед, в боки. Притисніть послідовно одне, потім інше коліно до грудей. Встаньте біля стіни так, щоб потилиця, лопатки, таз і п’яти торкалися стіни. Прогніть поперек вперед так, щоб потилиця, лопатки і п’яти все ще торкалися стіни, а таз і поперек прогнулися вперед. Останньою вправою, але не за важливістю, будуть випади.

Зробіть випад однією ногою вперед, дотримуючись принципу трьох прямих кутів — корпус-стегно, стегно-гомілка, гомілка-стопа. Ви маєте відчути напруження в області паху. Це тягнеться клубово-поперековий м’яз, дуже важливий для стабілізації поперекового відділу хребта, і саме його вкорочення дуже часто є причиною болю в попереку. Другий корисний лайфхак: увечері, якщо біль не мине повністю, прийміть гарячу ванну. Гаряча вода розслабить м’язи, біль ущухне або значно зменшиться. Тільки спершу варто переконатися, що це болять м’язи, а не нирки або інші внутрішні органи.

Стояти чи сидіти

Лікарі Інституту вертебрології та реабілітаціїзазначають, що коли людина стоїть понад три години, починають набрякати ноги, відчувається загальний дискомфорт і когнітивна функція слабшає. Але сидіти безперервно теж не корисно. Ліпше підібрати ергономічний стілець та виконувати різні вправи під час перерви, розминатися.

Як організувати робоче місце

Зараз у мережі дуже багато малюнків правильної організації робочого місця. Ортопед-травматолог Антон Білостоцький зазначає, що для м’язів шиї та грудного відділу важливо, щоб монітор (бажано) або екран ноутбука розташовувався чітко навпроти корпусу. Розташування монітора лівіше або правіше центральної лінії тіла дуже швидко призведе до перенапруження м’язів з одного боку тіла.

Важливо налаштувати висоту стільця під свій зріст. Якщо стіл не надто високий, то правильним положенням вважається те положення тіла, коли ноги не звисають, а спираються на підлогу; лікті можна покласти на стіл, плечі при цьому не піднімаються. Якщо стільниця розташована занадто високо, то можна підняти стілець, але під ноги поставити підставку.

Спеціалісти Інституту вертебрології та реабілітації радять для початку правильно облаштувати своє робоче місце, а почати — з вибору стільця.

Він обов’язково має бути обладнаний механізмом, щоб можна було регулювати кут нахилу спинки, висоту та глибину сидіння, налаштувати підголівник. Підтримка попереку та шиї — теж важливий момент. Не забувайте про регульовані підлокітники, аби лікті мали опору. Спеціальні ортопедичні стільці дають змогу забезпечити безперервне балансування для підтримки рівноваги, тож працюють усі м’язи (як під час ходьби). Сидіння з поглибленням для куприка — зручно та корисно.

Правильне положення:

• кут нахилу спинки — від 100 до 110°;
• руки треба покласти на рівну поверхню і зігнути у ліктях під кутом 90°;
• ноги мають стояти на підлозі під кутом 90°.

Пам’ятаємо, стілець підлаштовується під людину, а не навпаки!

Корсет як панацея

Біль у спині змушує людину шукати різноманітне приладдя, одне з них — профілактичний корсет. Так, він допоможе позбутися дискомфорту, коли очікується важкий день, адже м’язи розслабляються і не працюють на повну. Та згодом це може призвести до їхньої атрофії, якщо зловживати. Найкраще рішення — укріпити власний м’язовий корсет.

Фізична активність для тих, хто в IT

Малорухливий спосіб життя, як ми згадували вище, спричиняє низку хвороб. Тому спорт — це необхідність. Яким він буде, вирішуйте самі. Головне — задоволення та безпека. Бігайте, їздіть на велосипеді, ходіть до спортзалу, але без фанатизму та в ідеалі — під наглядом тренера.

Розглянемо один з варіантів, що вважається найкращим для подолання болю в спині — плавання. Якщо існують протипоказання до інших видів спорту, Слава Баранський, співзасновник LIVE.LOVE, радить саме цей вид фізичної активності. Ну хоча б тому, що це відмінна форма аеробного навантаження з низьким рівнем впливу на спину і хребет зокрема, на відміну від бігу або інших тренувань з ударними навантаженнями. Вода у режимі 3D підтримує тіло, розслабляє та знімає напруження з усіх суглобів та м’язів. Разом з цим плавання допомагає зміцнити м’язовий корсет (особливо м’язи спини та кора). Результат — надійна опора та підтримка вашого хребта, тобто відсутність затисків та перекосів, які є причиною больових відчуттів.

Якщо ви вирішили обрати плавання, щоб зняти тиск з хребта, бажано проконсультуватися з лікарем. Адже біль може бути сигналом про серйозні проблеми, які є протипоказаннями до використання певних стилів плавання або вправ.

Також бажано працювати під наглядом тренера, особливо якщо ви — початківець. Досвідчений фахівець поставить техніку і стежитиме за тим, щоб ви працювали тілом правильно і не травмувалися. Особливо це стосується таких технік, як батерфляй і кроль, тому що вони передбачають сильне обертання (ротацію) тулуба. Ідеальний варіант для того, щоб почати — плавання брасом.

Як плавання допомагає при болях в спині:

1. Розслабляє хребет. Як ми вже згадували, плавання знімає частину навантаження з суглобів та хребта. Маса тіла людини у воді зменшується, тиск на міжхребцеві диски зменшується, і біль вщухає. Крім того, коли ви плаваєте, зміцнюються м’язи спини, що також допомагає впоратися з болем завдяки правильному положенню хребта.
2. Коригує сутулість. При проблемах з поставою рекомендується плавати кролем на спині, тому що в такому положенні хребет вигинається назад. Це значно допомагає при корекції постави.
3. Допомагає при остеохондрозі. Тільки в цьому випадку бажано плавати на спині. Принаймні, це стосується остеохондрозу шийного відділу хребта. У такому положенні не потрібно напружувати шию, але при цьому в роботу включаються інші м’язи, тож ви можете тренуватися й не хвилюватися за свою шию.
4. Крім того, плавання заспокоює і розслабляє не лише тіло, але й нервову систему. Тож приходячи до басейну після робочого дня, ви отримаєте бонус — повний релакс для мозку і тренування для тіла. Приємні «побічні ефекти»: здоровий та міцний сон, покращення настрою та шалений апетит.

Масаж

Дні та ночі за комп’ютером не минають без наслідків, а залишають на згадку класичну «картину айтішника» — підняті плечі, напружена шия та потилиця, голова, нахилена вперед або в бік. Через це часто виникає головний біль, погіршення пам’яті, підвищення тиску. Сидяча робота викликає напруження м’язів спини, застій крові та лімфи, «синдром комп’ютерної мишки», відчуття оніміння в шиї.

Володимир Вікторович Веснін, ортопед-травматолог, остеопат, магістр медицини, асистент кафедри травматології та ортопедії Харківського національного медичного університету, кваліфікований масажист, директор Центру здоров’я, краси та успіху The Vesnina Group, зазначає, що масаж для IT-фахівця потрібен, перш за все, для зменшення втоми від роботи, поліпшення мозкового кровообігу і мозкової діяльності, що, в свою чергу, дає змогу швидше виконувати поставлені завдання. По-друге, масаж усуне біль у спині, шиї і руках, значно зменшить напруженість, скутість і агресивність, унаслідок чого фахівець стане стійкішим до стресів. А по-третє, це загальне розслаблення і відпочинок, що попереджає вигорання на роботі, а також сприяє генеруванню нових ідей і можливостей.

Зараз попит на IT-масаж зростає щодня, як з боку самих фахівців, так і з боку керівників. Останні збагнули важливість масажу для поліпшення якості і швидкості роботи, а значить, і збільшення прибутку. Це своєрідна інвестиція в співробітника. А фахівці, своєю чергою, зрозуміли, що масаж сприятливо впливає на їхню працездатність і витривалість, і, отже, на збільшення заробітку.

Масаж для ІТ-фахівця відрізняється тим, що більше уваги приділяється проблемним зонам, таким як спина, шия, голова і руки. Для цього підбираються спеціальні техніки, які, з одного боку, розслаблюють, а з іншого — тонізують працівника для подальшої роботи. Також цей масаж можливо проводити як лежачи, так і сидячи, що не менш важливо для офісу.

Масаж допомагає впоратися з:

1. Втомою, нервовістю, надмірною дратівливістю і навіть депресивним станом, унаслідок чого покращується загальне самопочуття, підвищується працездатність, зміцнюється нервова система, і навіть сон стає міцнішим.
2. Болем у шиї, спині, попереку, руках, ногах, напругою в очах і голові. Це відбувається за рахунок поліпшення кровотоку і дає змогу мозку людини працювати активніше і ефективніше.

Досвід ІТ-компаній та фахівців

Редакція DOU звернулася до українських ІТ-компаній з проханням розповісти, як керівництво дбає про здоров’я своїх співробітників.

У компанії Yukon є масажне крісло. Це цілий оздоровчий комплекс, що імітує дії професійних масажистів. Масаж допомагає розслабитися, відпочити, і найголовніше — впливає на певні групи м’язів у будь-який час, без додаткових витрат або поїздок до фахівців. Також в офісі є спеціальна кімната психоемоційного розвантаження. Кожен охочий може зробити перерву на короткий сон або просто відпочити в тиші на зручних кріслах. 20-хвилиннаперерва допомагає повністю перезавантажити організм та відновити енергію для продовження робочого дня.

У Netcracker масажиста запрошують до офісу на регулярній основі. Двічі на тиждень у компанії працюють спеціалісти з масажу. Опція зручна тим, що записатись на неї можна просто в день процедури через google-форму, яка постійно оновлюється. Для масажу виділена окрема кімната, з теплим світлом та масажним столом. Більшість з тих, хто відвідує масаж, переконані, що це один з найефективніших способів перезавантажитись посеред робочого дня.

У Dev-Pro діє доповнення до медичної страховки — HealthCare Kit. Мета цього бонусу — покрити витрати фахівців на офтальмологію, стоматологію, відвідування спортзалу, вітаміни або спортивне харчування. Сума в HealthCare Kit збільшується з часом роботи в компанії, і працівники активно користуються пільгами. Якщо фахівцеві рекомендований лікарем ортопедичний стілець — його надають. А щоб попереджати будь-які захворювання або проблеми зі здоров’ям, для профілактики фахівці щорічно проходять курс масажу в офісі (також він доступний і за страховкою).

Масажне крісло в Yukon

А ось що кажуть ІТ-фахівці про власний досвід.

Віталій Маренков, Back-end developer в eTravel S.A.

Анна Топчій, Geocoder в Intetics

Олександр Литвиненко, Developer, Lead, Mentor в ProCode IT School

Вікторія Музичко, SSE в GlobalLogic

На Форумі DOU можна знайти теми, присвячені здоров’ю опорно-рухового апарату.

1. Грижа.
2. Ортопедичний матрац.
3. Протрузії.

До вашої уваги дайджест навчальних програм для тих, хто починає свою кар’єру в ІТ. У цьому номері зібрані можливості, актуальні у березні 2020. Усі програми безкоштовні.

Оскільки протягом місяця редакція оновлює дайджест, будемо публікувати оновлення і в коментарях. Якщо хочете бути в курсі — лишіть коментар під статтею, щоб отримувати нові пропозиції на e-mail.

Якщо ви маєте інформацію про інші безкоштовні курси, стажування та вакансії для початківців, яких немає в дайджесті, пишіть на maria@dou.ua, і ми додамо їх до статті.

Підписуйтеся на наш Telegram-канал, щоб дізнаватися про найактуальніші можливості для джуніорів. Туди ми надсилаємо сповіщення про оновлення дайджесту, нові курси, стажування та вакансії.

AltexSoft

Напрям:курси .NET, Front end, QA.
Місто:Кременчук.
Дедлайн подачі заявок:реєстрація відбувається постійно, навчання у березні та вересні.

Вимоги до кандидатів:

.NET:

• технічна освіта або студенти 2 курсу і вище;
• базові знання C#/.NET/SQL;
• англійська Pre-Intermediate і вище.

Front-end:

• технічна освіта або студенти 2 курсу і вище;
• базові знання HTML5/CSS3/JS;
• англійська Pre-Intermediate і вище.

QA:

• розуміння основ тестування (типів, методів та технік тестування);
• розуміння принципів ООП;
• логічне мислення;
• англійська Pre-Intermediate і вище.

Як потрапити:зареєструватися на сайті.

Умови:заняття двічі на тиждень. Front end та QA: запланована дата старту — 30 березня, у будні з 18:00, тривалість заняття — 2 години, курс триває 2-2,5 місяці. .NET: запланована дата старту — 23 березня, по 2 години у будні день з 18:00 та 6 годин в суботу з 09:00, курс триває 2,5-3 місяці.Найкращим студентам після закінчення курсу пропонують подальше стажування в компанії і працевлаштування.

Деталі:на сайті, або пишіть на пошту lab@altexsoft.com.

Apiko

Напрям:курси React, React Native.
Місто:Тернопіль.
Дедлайн подачі заявок:до 9 березня.

Вимоги до кандидатів: React — базові знання JavaScript, верстки чи інших Front-end фреймворків (Angular, Vue). React Native — теоретичний та практичний досвід роботи з React.

Як потрапити:зареєструватися на сайті, виконати тестове завдання, для web-напрямку — на JS, для mobile-напрямку — на React. Зареєстровані учасники отримають тестове після закінчення реєстрації.

Умови:курси безкоштовні і передбачають виконання фінального проекту.

Деталі:на сайті.

Binary Studio Academy

Напрям:курси — JS, PHP, .NET, Java, QA.
Місто:онлайн.
Дедлайн подачі заявок:до 24 квітня.

Вимоги до кандидатів:

• базові знання з JS / .NET / PHP / Java/ QA;
• вміння працювати з даними (наприклад, через SQL), розуміти принципи ООП та / або ФП;
• можливість навчатись по 8-12годин на день з липня до 12 вересня.

Як потрапити:зареєструватися на сайті, підготуватися до вступного тестування, пройти відбір: скласти онлайн-тест, виконати домашні завдання та поспілкуватися із представником команди Академії.

Умови:липень — лекції, напрацювання теоретичної бази. ~ 15 відеолекцій від топових розробників Binary Studio з домашніми завданнями. Виконані завдання проходять код-рев’ю у викладача. Серпень — вересень: розробка проекту, робота в команді. За шість тижнів студенти під керівництвом коучів створюють проект від ідеї до повністю функціональної демо-версії. Демо завершених проектів презентують 12.09. Найкращі студенти отримають шанс приєднатися до Binary Studio.

Деталі:на сайті, пишіть на пошту academy@binary-studio.comабо телеграм-боту @AcademyRoBot.

EPAM

Тип:курси.
Місто:Київ, Харків, Дніпро, Львів, Вінниця.

Напрями та дедлайни подачі заявок:

Київ:

• BA — 5 березня;
• QA (Automation+Manual) — 16 березня;
• .NET — 18 березня.

Харків:

• Java — 1 березня.

Дніпро:

• Java — 17 березня.

Львів:

• Data Engineering Program — 3 березня;
• Automated Testing — 16 березня;
• Big Data — 16 березня;
• Digital — 16 березня;
• Android — 16 березня;
• Java - 16 березня;
• PHP - 27 березня;
• Python - 27 березня.

Вінниця:

• Java/Android — 29 березня;
• FrontEnd/JavaScript — 3 квітня.

Як потрапити:зареєструватися на сайтіта пройти тест. Тестування включає технічний комп’ютерний тест та перевірку рівня знань англійської мови. Співбесіда з рекрутером.

Умови:зовнішні заняття (до 3 місяців), Pre-Production лабораторія (від 3 до 6 місяців). Після закінчення навчання найкращі випускники отримають можливість продовжити співпрацю з компанією.

Деталі:на сайті.

GlobalLogic

Напрям:курси .NET.
Місто:Харків.
Дедлайн подачі заявок:до 2 березня.

Вимоги до кандидатів:

• базовий досвід у .NET;
• сильний потяг до вдосконалення, оптимізації та виявлення можливостей для найкращого користувальницького досвіду;
• знання англійської на рівні Intermediate.

Як потрапити:подати заявку на сайті, пройти вступне тестування. Претендентів з найкращими результатами тестів запросять для проходження інтерв’ю, за підсумком яких буде відібрано 15 учасників курсів GL BaseCamp.

Умови:курси пройдуть на базі Харківського національного університету радіоелектроніки. Початок курсу: березень 2020. Тривалість: 2 місяці (3 рази на тиждень у вечірній час). У разі успішного складання тесту, після проходження курсів учасники отримають можливість долучитися до проектів компанії GlobalLogic.

Деталі:на сайті.

InternetDevels

Напрям:курси — розробка сайтів на CMS Drupal 8, QA та PM.
Місто:Луцьк.
Дедлайн подачі заявок:реєстрація відбувається на постійній основі, оскільки курси відбуваються регулярно. Охочих, що не встигнуть потрапити на цей набір, запрошують на наступний.

Вимоги до кандидатів:

• для майбутніх програмістів необхідне базове розуміння PHP, HTML, CSS, JavaSсript (не обов’язково);
• для майбутніх РМ’ів необхідне знання англійської мови на рівні спілкування;
• загалом необхідне бажання вчитися та розвиватися.

Як потрапити:подати заявку на сайті.

Умови:курс триває 4 тижні. Заняття 3 — 5 разів на тиждень по 2-3 години.Найкращим студентам після закінчення курсу пропонують подальшу інтернатуру в компанії і працевлаштування.

Деталі:на сайті, на сторінці Facebook.

NIX

Напрям:курси.
Місто:Харків.

Вимоги до кандидатів:

• навчання Java;
• практика PHP + CMS;
• навчання BA;
• навчання JavaScript;
• навчання .NET;
• навчання Azure DevOps;
• практика Android;
• навчання UI/UX Designer;
• навчання Linux administration / DevOps.

Як потрапити:подати резюме на сайті, пройти тестування в офісі або ВНЗ, пройти співбесіду.

Умови:Практика — очне навчання 40 годин на тиждень в офісі компанії протягом 3-хтижнів у літній період. Навчання — 2-3рази на тиждень у вечірній час від 1 до 5 місяців. Інтенсив — очне навчання 40 годин на тиждень в офісі компанії протягом 2-хмісяців.

Деталі:пишіть на пошту education@nixsolutions.com.

QATestLab

Напрям:онлайн-курси QA.
Дедлайн подачі заявок:реєстрація відбувається постійно.
Вимоги до кандидатів:навчатися можуть усі охочі.

Як потрапити:подати заявкута скласти тест, що включає в себе питання на рівень логічного мислення, знання англійської мови та володіння ПК.

Умови:викладачi курсів — QAEngineers компанії QA TestLab. Формат навчання: онлайн. Тривалість курсів — від 3 до 5 тижнів. Курси включають в себе лекції, що проводяться через систему GoToWebinar двічі на тиждень, практичні домашні завдання та підсумковий іспит.

Деталі:на сайті.

RubyGarage

Напрям:курси Ruby/Ruby on Rails.
Місто:Дніпро.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• базові знання HTML, CSS, JavaScript та мінімальний досвід роботи з цими технологіями;
• знання базових принципів роботи баз даних і мови SQL;
• розуміння об’єктно-орієнтованої парадигми програмування;
• знайомство з однією з серверних мов програмування (PHP, Java, С ++ / С #, Python...);
• технічна англійська на рівні читання документації;
• бажання навчатися та вирішувати задачі;
• мінімум 10-15вільних годин в тиждень на навчання.

Як потрапити:заповнити форму на сайті, виконати тестове завдання, пройти співбесіду.

Умови:орієнтовний початок навчання — уточнюється, курс триває 4-6 місяців.Навчання проходить два рази на тиждень у вечірній час. По закінченні студенти складають випускний іспит. Після успішного проходження курсу — можливе працевлаштування у компанії.

Деталі:на сайтіабо пишіть на пошту railscourses@rubygarage.org.

SoftServe

Тип:курси.
Місто:Львів, Івано-Франківськ, Чернівці, Дніпро, Рівне, Харків.
Напрям та дедлайн подачі заявок:

Нижче вказані дати початку курсів. Реєстрація закривається за 14 днів до старту.

QA: Харків — 17 березня.

Test Automation with Python: Рівне — 19 березня.

Quality Сontrol: Дніпро — 20 березня, Львів — 23 березня.

Ruby: Івано-Франківськ — 23 березня.

Java : Харків — 30 березня.

.NET: Чернівці — 1 квітня, Харків — 6 липня.

Database: Львів — 1 квітня.

DevOps for Unix: Івано-Франківськ — 6 квітня.

WebUI: Харків — 6 квітня.

Вимоги до кандидатів:

• рівень англійської Intermediate+;
• студенти дотичних напрямків 2-йкурс і вище;
• готовність до насиченої роботи.

Як потрапити:заповнити заявку на сайті, пройти технічне тестування і тест на знання англійської мови, пройти співбесіду.

SPD-Ukraine

Напрям: Java, Front-end, Test Automation.
Місто:Черкаси.
Дедлайн подачі заявок:на постійній основі.

Вимоги до кандидатів:

Java:

• Java 8 Core: класи/інтерфейси, Generic, Collections API, IO, Exceptions, анотації;
• принципи ООП;
• знання алгоритмів і структур даних;
• основи SQL;
• основи HTML/CSS/JS;
• основи Web: HTTP запити, Cookies, Session;
• основи Git;
• рівень англійської Intermediate або вище.

Front-end:

• знання основ HTML/CSS;
• вміння користуватися одним із графічних редакторів;
• досвід верстки від 3 місяців;
• досвід Responsive або Adaptive верстки;
• розуміння основ програмування, структур даних та алгоритмів;
• базові знання Javascript;
• основи Git;
• рівень англійської Intermediate або вище.

Test Automation:

• теоретична база QA;
• основи Java 8;
• принципи ООП;
• основи SQL;
• основи HTML/CSS;
• основи Web: HTTP запити, Cookies, Session;
• основи Git;
• рівень англійської Intermediate або вище.

Як потрапити:подати заявку на сайті, пройти тестування (англійською), пройти співбесіду (українською).

Умови:тривалість курсу: 7 місяців. Останні півтора місяця — робота в командах над фінальними проектами. Після успішного завершення — сертифікат SPD-Ukraine.

Деталі:пишіть на пошту info@spd-university.comабо на сайті.

Yalantis

Напрям:курси Ruby.
Місто:Дніпро.
Дедлайн подачі заявок: 10 березня.

Вимоги до кандидатів:

• розуміння, як влаштований протокол HTTP (знання REST буде плюсом);
• знання базових принципів БД і мови SQL;
• розуміння об’єктно-орієнтованої парадигми програмування;
• знання основ Ruby. Базове розуміння одного з серверних мов програмування (PHP, Java, Python, C, C ++, Ruby і т.д.) буде плюсом;
• розуміння процесів тестування (unit and integration tests);
• розуміння роботи систем контролю версій;
• знання англійської мови на рівні Intermediate і вище;
• бажання вчитися.

Як потрапити:заповнити форму на сайті, виконати тестове завдання i тест з англійської, пройти співбесіду з куратором школи.

Умови:лекції і домашні завдання. Після успішного закінчення ви зможете претендувати на позицію Ruby developer в Yalantis. Школа безкоштовна, триватиме 2 місяці. Початок занять: 19 березня 2020. Розклад: вівторок і четвер, з 19:00 до 21:00.

Деталі:на сайті, або пишіть на пошту dasha.kornienko@yalantis.netчи skype: dashka_krn.

Школа програмування Ш++

Напрям:курс Java.
Місто:Кропивницький.
Дедлайн подачі заявок:на постійній основі.

Вимоги до кандидатів:вміти пробігтись по масиву циклом, за допомогою однієї з мов: С++, JavaScript, Java.

Як потрапити:зареєструватися, пройти вступне випробуванняна одній із мов: Java, C++, Javascript.

Умови: Peer-to-peer — це коли ви навчаєтесь без менторів, груп, з офлайн-складовою. Тривалість курсу складає 4 місяці і дає можливість обрати напрямки для більш поглибленого навчання (наприклад, web/mobile development). Заняття проходять двічі на тиждень в м. Кропивницький.

Деталі:пишіть на пошту info@programming.kr.ua, телефонуйте 050 20 111 80 або на сайті.

AMC Bridge

Напрям:стажування C++, C#, web services.
Місто:Дніпро, Львів, Суми, Хмельницький, Чернівці.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:студенти 3-6-го курсів технічних спеціальностей вищих навчальних закладів. Термін стажування повинен збігатися з навчальним планом ВНЗ.

Як потрапити:відправити резюме на сайті, виконати тестове завдання, пройти співбесіду із HR-менеджером, технічним інтерв’юером та директором дослідницького підрозділу.

Умови:стажування являє собою роботу на одному з проектів у внутрішньому дослідницькому підрозділі компанії строком на 1 місяць з тижневою зайнятістю 40 годин. Залежно від результатів стажування, студента може бути рекомендовано до прийняття на роботу в компанію.

Деталі:на сайтіабо пишіть на пошту contacts@amcbridge.com.

Andersen

Напрям: JavaScript, .NET, QA.
Місто:Київ, Одеса, Харків, Чернігів, Черкаси.

Вимоги до кандидатів:

• впевнені теоретичні знання за вибраним напрямком;
• наявність навчальних проектів;
• знання англійської мови на рівні Intermediate.

Як потрапити:заповнити анкету на сайті.

Умови:термін навчання — 2 місяці, повний день на базі офісу, викладає індивідуальний ментор. Для стажування QA є оплата.

Деталі:пишіть на пошту d.krepkina@andersenlab.com.

AniArt

Напрям: PHP.
Місто:Київ.

Вимоги до кандидатів:

• студенти 3-5курсів та випускники технічних спеціальностей;
• базові теоретичні знання програмування;
• готовність навчатися інтенсивно.

Як потрапити:надіслати резюме на сайті, виконати тестове завдання, пройти співбесіду.

Умови:тривалість — від 3 місяців. За умови його успішного завершення, кандидат отримує статус джуніора в компанії. Оплата є.

Деталі:на сайтіабо пишіть на пошту managers@aniart.com.ua.

Ascendix

Напрям: Application.
Місто:Харків.
Дедлайн подачі заявок:на постiйнiй основi.

Вимоги до кандидатів:

• англiйська на рiвнi Intermediate;
• знання JavaScript/HTML/CSS;
• базові знання будь-якої об’єктно-орієнтованої мови програмування (бажано Java);
• знання загальних структур та схем реляційних баз даних;
• досвід у створенні SQL-запитів.

Як потрапити:надіслати резюме на сайті.

Умови:тривалість — 3 місяці, є стипендiя та ментори. Можливість працевлаштування в компанії.

Деталі:на сайті.

BAKOTECH

Напрям:кібербезпека.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• студенти та випускники технічних спеціальностей;
• знання серверної частини Windows (MS AD, DNS, DHCP);
• знання архітектури мережі (модель OSI, VPN, VLAN, та ін.);
• навички використання середовища віртуалізації: VMware та / або Hyper-V;
• розмовний рівень англійської мови.

Як потрапити:надіслати резюме з поміткою «Стажування з DOU» на пошту Tatiana.Kiselevich@bakotech.com, пройти співбесіду в офісі, виконати тестове завдання.

Умови:програма розрахована на 3 місяці з можливістю подальшого працевлаштування. Стажування проходить в офісі, 5 днів на тиждень, з 9 до 18 години. Програма включає практичні завдання під керівництвом спеціалістів відділу. Стажування передбачає помісячну оплату.

Деталі:написати на Tatiana.Kiselevich@bakotech.com, 063-117-84-78.

Cleveroad

Напрям: Front-end Angular, Requirement analyst.
Місто:Дніпро.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

Front-end Angular:

• розуміння основних принципів ООП;
• базові знання JavaScript;
• знання HTML5, CSS3;
• розуміння DOM-моделі;
• розуміння Ajax.

Requirement analyst:

• ступінь бакалавра (або вище) з математики, інформатики, бухгалтерського обліку чи бізнесу;
• англійська: Upper-Intermediate або вище;
• вміння аналізувати та вирішувати проблеми;
• ділове спілкування та міжособистісні навички;
• інтерес до технологій та розробки програмного забезпечення.

Як потрапити:надіслати резюме на hr@cleveroad.com, виконати технічний тест, пройти співбесіду.

Умови:стажування проходитиме в офісі компанії 2,5 місяці, повний робочий день 5 днів на тиждень. Кандидат отримає допомогу досвідченого ментора, обладнане робоче місце, практичні завдання. Передбачена оплата. Після успішного завершення стажування можна приєднатися до команди на позицію junior.

Деталі:пишіть на hr@cleveroad.com, або на сайті для Front-end Angular, Requirement analyst.

CodeIT

Напрям і місто:стажування Back-end у Харкові.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

Back-end:

• розуміння принципів ООП;
• хороші знання PHP або Node.js, MySQL;
• знання принаймні одного з PHP або Node.js фреймворків;
• знання системи контролю версій (GIT);
• англійська: Intermediate і вище.

Як потрапити:написати на пошту jobs@codeit.us.

Умови:тривалість програми — 3-4 місяці.Програма оплачувана.

Деталі:пишіть на пошту jobs@codeit.us.

DataArt

Напрям і місто:стажування .NET, Design, Java, QA у Харкові.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• базові знання за обраним напрямком;
• володіння розмовною англійською.

Як потрапити:надіслати резюме на пошту careers.kharkiv@dataart.com.

Умови:програма триватиме близько 3 місяців. Є оплата. На весь період за практикантом закріплюють ментора. Можливе подальше працевлаштування в компанії.

Деталі:на сайті.

DIGIS

Напрям:стажування React Native.
Місто:Одеса.

Вимоги до кандидатів:

• студент 1-4 курсу;
• власні пет-проекти;
• англійская мова від рівня Intermediate;
• знання основ JavaScript.

Як потрапити:надіслати резюме на rn.internship@digiscorp.com.

Умови:викладач— Middle JS developer. Тривалість — 3 місяці. Оплати немає. Після успішного проходження — працевлаштування.

Деталі:пишіть на hr@do-it.co.

GeeksForLess

Напрям:стажування C#.
Місто:Миколаїв.

Вимоги до кандидатів:

• базові знання С#;
• ASP.NET MVC;
• Entity Framework;
• MS SQL Server;
• Bootstrap;
• MS Visual Studio.

Як потрапити:надіслати резюме з поміткою «С# стажування» на Mykolayiv@geeksforless.com, виконати тестове завдання.

Умови:повний робочий день, 5 днів на тиждень.

Деталі:на сайтіабо пишіть за адресою Mykolayiv@geeksforless.com.

Grid Dynamics

Напрям:стажування UI.
Місто:Львів.
Дедлайн:до 1 березня.

Вимоги до кандидатів:

• базові знання HTML / CSS / JS;
• базові знання довільної мови програмування;
• рівень англійської — Upper-Intermediate;;
• здатність описати блок-схему (алгоритм);
• базові знання HTTP ;
• наявність диплому по напрямку комп’ютерних наук чи суміжних дисциплін;
• можливість приділяти повний робочий день.

Як потрапити:надіслати резюме на cv-lviv@griddynamics.comз темою «UI Internship», пройти тест на знання англійської та технологій.

Умови:оплачувана інтернатура тривалістю 4 місяці під керівництвом Senior-розробників. Найкращим інтернам запропонують працювати в компанії надалі.

Деталі:за посиланням.

groupBWT

Напрям:стажування PHP, Python.
Місто:Запоріжжя.
Дедлайн подачі заявок:стажування відкрите на постійній основі.

Вимоги до кандидатів:

• студенти 3-5курсів та випускники технічних спеціальностей;
• базові теоретичні знання програмування;
• готовність навчатися інтенсивно.

Як потрапити:надіслати резюме на сайті, пройти телефонне інтерв’ю, виконати тестове завдання, пройти співбесіду в офісі.

Умови:програма розрахована на 3 місяці с можливістю подальшого працевлаштування. Стажування проходить в офісі 40 годин на тиждень. Можливий індивідуальний графік для поєднання з навчанням у виші. У разі успішного виконання практичних завдань кандидат отримуватиме стипендію. Це не навчання, а стажування, тому теорію, якої не вистачатиме, необхідно буде освоювати самостійно. На стажуванні основний акцент робиться на PHP, Laravel, Python, методи збору і обробки даних (парсери). Крім того, кандидат навчиться працювати в команді, користуватися інструментами розробки та системами ведення проектів, ефективно використовувати свій робочий час.

Деталі:на сайті.

IdeaSoft.io

Напрям:стажування Sales.
Місто:Харків.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• цікавляться подорожами;
• мають гарний рівень англійської;
• люблять і знають як спілкуватися з людьми.

Як потрапити:подати заявку на пошту julia.s@ideasoft.io.

Умови:тривалість — 2 місяці, 6-годиннийробочий день. Початок — коли буде набрана група. Під час стажування буде навчання і підтримка від команди. Після закінчення можливе працевлаштування.

Деталі: Skype: julia.syzonenko.

InterLink

Напрям:стажування Full Stack with ASP.NET Core and React.
Місто:Черкаси.

Вимоги до кандидатів:

• вміти вирішувати прості алгоритмічні задачі з використанням відповідних структур даних;
• розбиратися в простій програмі на об’єктно орієнтованій мові програмування та розширяти її функціонал;
• читати технічні англомовні тексти зі словником.

Як потрапити:заповнити реєстраційну форму на сайті, пройти автотести, виконати технічне завдання, пройти формальну співбесіду з ментором.

Умови:для студентів. Тривалість інтернатури 3 місяці — інтернатура проходитиме у форматі командної роботи над проектом з 9:00 до 18:00 в офісі, під керівництвом менторів InterLink.

Деталі:пишіть на пошту hr@interlink-ua.com, на сторінці Facebook.

JustAnswer

Напрям:стажування .NET.
Місто:Львів.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• комерційний досвід роботи з різними технологіями від 1-гороку;
• рівень англійської Intermediate+;
• здатність швидко навчатись.

Як потрапити:надіслати резюме на пошту lesia.kogut@justanswer.comз темою «Bootcamp», пройти відбіркове інтерв’ю та технічну співбесіду в офісі.

Умови:оплачуване стажування тривалістю 3 місяці, повний робочий день. Можливе працевлаштування в компанії.

Деталі:пишіть на lesia.kogut@justanswer.com.

Leobit

Напрям:стажування .NET, Ruby.
Місто:Львів.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• студенти 4-5-го курсів або випускники за 2 останні роки (технічні спеціальності вищих навчальних закладів);
• теоретичні знання відповідно до обраного напрямку;
• хороші аналітичні навички;
• рівень англійської — Intermediate+.

Як потрапити:надіслати резюме на cv@leobit.comабо заповнити реєстраційну форму на сайті.

Умови:стажування (оплачуване) триває до 3 місяців, під час якого досвідчений ментор допомагає молодому спеціалісту освоїти нову професію і швидко розпочати роботу на реальних проектах. Після успішного проходження стажування Trainee переходить на позицію Junior.

Деталі:пишіть на пошту cv@leobit.com.

Maklai

Напрям:стажування C++.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:технічна освіта буде плюсом.

Як потрапити:написати на job@maklai.com.ua, пройти тестування та співбесіду.

Умови:стажування триває 3 місяці, мінімум 4 години на день в офісі, після закінчення стажування кращих запросять на роботу.

Деталі:пишіть на пошту job@maklai.com.ua, або telegram — agniesha0606, моб: 063 439 13 83, Агнєшка.

MobiDev

Напрям:стажування iOS.
Місто:Миколаїв.

Вимоги до кандидатів:

• поглиблене розуміння об’єктно-орієнтованого програмування (ООП);
• впевнене знання будь-якої мови програмування;
• рівень англійської мови не нижче Intermediate.

Як потрапити:надіслати резюме nikolaev@mobidev.biz, виконати тестове завдання.

Умови:тривалість — 2 місяці, 6 годин в день на базі офісу.

Деталі:пишіть у Skype: kateryna.oleynik.md.

Quality Assurance Group

Напрям:стажування / виробнича практика QA.
Місто:Львів.
Дедлайн подачі заявок:немає.
Вимоги до кандидатів:курс можуть проходити усі охочі.

Як потрапити:подати заявку, заповнивши анкету, або телефонуйте (099) 376 65 05; (098) 903 64 45.

Умови:практика з реальними проектами у групах під керівництвом координатора. Робота з баг-трекінговою системою Jira; Zephyr test management tool, Test Rail, Jmeter etc.

Деталі:на сайті.

RubyGarage

Напрям:стажування QA, PM.
Місто:Дніпро.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

QA:

• рівень англійської: Strong Intermediate та вище;
• теоретичні знання в напрямку QA (проходження курсів або досвід роботи до 6 місяців).

PM:

• 1+ рік досвіду роботи в IT-компанії або стартапі в якості розробника, тестувальника, або проєктного менеджера;
• розуміння життєвого циклу розробки програмного забезпечення;
• знання Scrum-теорії та розуміння принципів Agile та Lean;
• досвід роботи з JIRA;
• уміння читати, розуміти та писати специфікації вимог до програмного забезпечення (epics, user stories, Gherkin-сценарії);
• навички комунікації та ведення переговорів;
• лідерські навички;
• здатність брати на себе відповідальність і швидко приймати рішення;
• знання англійської мови: Upper-Intermediate+.

Як потрапити:відправити резюме на пошту recruiting@rubygarage.orgз темою: QA (або PM) інтернатура RubyGarage. Пройти три етапи відбору.

Умови: QA — підтримка ментора, інтернатура проходить в офісі RubyGarage на full-time основі. Після успішного виконання технічного завдання, найкращі інтерни отримують оффер на позицію Junior QA. PM — інтернатура триває до 2-хмісяців та розрахована на повний робочий день. Навчання проходить в офісі компанії за підтримки досвідченого ментора згідно зі структурованою програмою. Найкращі інтерни отримають офер на позицію Scrum Master.

Деталі:QA, PM або пишіть на пошту recruiting@rubygarage.org.

Sigma Software University

Тип:стажування.

Вимоги до кандидатів та дедлайни:

• Node.js: Харків — 1 березня;
• JS: Одеса — 1 березня;
• UI/UX: Харків — 15 березня;
• IT Researcher : Київ — 31 березня;
• Embedded : Харків, Львів — березень;
• .NET : Харків — березень.

Як потрапити:заповнити реєстраційну форму на сайті (у відповідному розділі) та додати резюме.

Умови:тривалість стажування від 3 до 6 місяців залежно від напряму; повний робочий день.

Деталі:на сайті.

Sparkybit

Тип:стажування Salesforce.
Місто:Дніпро.

Вимоги до кандидатів:

• від 1 року досвіду роботи Back-end розробником (в ідеалі на Java, C #, C ++);
• розуміння і досвід роботи з системами контролю версій (Git);
• English: intermediate.

Як потрапити:написати на wehire@sparkybit.com.

Умови:навчання з подальшим влаштуванням на роботу. Навчання проходить 2-3місяці в офісі. Міжнародна сертифікація (оплачується компанією).

Деталі:на сайті.

SteelKiwi

Тип:стажування Python/Django.
Місто:Вінниця.

Вимоги до кандидатів:

• базові знання Python/Django;
• хороші навики роботи з OOP;
• знання реляційних баз даних;
• досвід з VCS;
• міцні знання систем *nix;
• розуміння клієнт-серверної архітектури та принципів розробки API;
• English — intermediate.

Як потрапити:заповнити заявку на сайті.

Умови:навчанняпротягом трьох місяців (виплачується стипендія у розмірі 1000 грн/міс.), 8 год./день та 5 днів на тиждень. Після інтернатури можливе працевлаштування у компанії, спочатку на позицію трейні з подальшим ростом до джуна.

Деталі:на сайті, або пишіть на пошту verbovetska.ivanna@steelkiwi.com.

TeamDev

Напрям:стажування Java.
Місто:Харків.

Вимоги до кандидатів:

• англійська рівня Intermediate;
• досвід програмування, крім курсових/дипломів;
• профільна технiчна незакінчена/закінчена вища освіта;
• знання основ математики;
• розуміння основних принципів ООП;
• базові знання Java.

Як потрапити:заповнити реєстраційну форму, надіслати резюме за адресою work@teamdev.com. Надіслати приклад вашого коду — це може бути будь-який код на будь-якій мові програмування: покажіть код, яким ви пишаєтеся! Пройти співбесіду з фахівцями компанії.

Умови:перший місяць — теоретична підготовка з практичними заняттями. Другий — стажування на проекті. Виконана протягом програми робота буде оплачена. Найкращі студенти будуть запрошені у команду TeamDev.

Деталі:на сайтіабо пишіть на пошту work@teamdev.com.

Technorely

Напрям і дедлайн:стажування Coordination of Department — до 6 березня.
Місто:Харків.

Вимоги до кандидатів:

Coordination of Department:

• базові знання IT-сфери;
• високий рівень самоорганізованості;
• комунікабельність;
• вміння працювати в режимі багатозадачності;
• рівень англійської — Pre-Intermediate (буде плюсом).

Як потрапити:заповнити форму на сайті, пройти співбесіду.

Умови:по закінченню теоретичної частини навчання інтерни виконують практичне завдання. З понеділка по п’ятницю на локації компанії, під керівництвом ментора. Квітень — червень — повноцінне стажування (з виплатою стипендії). За результатами стажування найкращі студенти отримають шанс приєднатися до команди Technorely.

Деталі:на сайтіабо пишіть на пошту career@technorely.com, Telegram — @career_technorely, +38(063)8641078.

VAIMO

Напрям:стажування PHP.
Місто:Київ, Харків.
Дедлайн подачі заявок:до кінця березня.

Вимоги до кандидатів:

• мінімальний досвід програмування на PHP;
• рівень англійської — Intermediate+;
• базові знання з HTML, CSS, OOP.

Як потрапити:відправити резюме на сайті, пройти технічне тестування, технічну співбесіду та співбесіду з HR.

Умови:інтернатура оплачується та триває 4 місяці, повний робочий день. Найкращим інтернам після закінчення пропонують працевлаштування.

Деталі:пишіть на hr.coe@vaimo.com.

WEB4PRO

Напрям:стажування PHP (Magento 2).
Місто:Харків.
Дедлайн подачі заявок:стажування відкрите на постійній основі.

Вимоги до кандидатів:

• досвід роботи з PHP та MySQL;
• розуміння OOP;
• базові знання JS.

Як потрапити:відправити резюме на hr@corp.web4pro.com.ua, пройти тестування та співбесіду в офісі.

Умови:тривалість — 3 місяці. Стажування в офісі 8 годин на день 5 днів на тиждень. Є стипендія та ментор. Можливість працевлаштування в компанії.

Деталі:hr@corp.web4pro.com.ua.

White Label Agency

Напрям:стажування WordPress.
Місто:Полтава.
Дедлайн подачі заявок:стажування відкрите на постійній основі.

Вимоги до кандидатів:

• студенти останнього курсу та випускники;
• базове розуміння CMS WordPress, PHP;
• знання HTML & CSS;
• досвід програмування.

Як потрапити:заповнити форму на сайтіабо відправити резюме на hr@thewhitelabelagency.com, пройти співбесіду та виконати тестове завдання.

Умови:викладачі інтернатури — Tech leads та Senior Developers компанії. Тривалість програми — від 1 до 2 місяців залежно від рівня кандидата. 5 днів на тиждень, 8 годин на день. Стажування оплачується щомісячно. Програма включає практичні завдання, розробку тесових проектів під керівництвом кураторів та лекції. За умови успішного проходження курсу є можливість працевлаштуватися на позицію Junior.

Деталі:на сайті.

WiserBrand

Напрям:стажування Customer Support.
Місто:Харків.
Дедлайн подачі заявок:стажування відкрите на постійній основі.

Вимоги до кандидатів:володіння англійською на рівні Upper та вище.

Як потрапити:заповнити форму на сайті.

Умови:тривалість стажування 3 місяці, що оплачуються компанією. Є можливість подальшого працевлаштування в компанії.

Деталі:на сайтіабо пишіть на пошту alexa.a@wiserbrand.com, @Aleksa_Andr — telegram.

Dev.Pro

Напрям:робота PHP.
Місто:Харків.

Вимоги до кандидатів:

• знання основ PHP: масиви, цикли, функції, типи даних, OOП (розглянемо випускників курсів);
• знання HTML/CSS;
• навички веб-дизайну для створення якісних візуалів;
• VCS (git);
• рівень англійської не ніжче pre-intermediate ;
• уважність до деталей;
• здатність точно слідувати правилам та інструкціям.

Умови:випробувальній термін — 3 місяці

Як потрапити:подати резюме на сайті.

Деталі:на сайті.

Evrius

Напрям:робота Account manager.
Місто:Київ.

Вимоги до кандидатів:англійська мова — рівень intermediate і вище.

Умови:оплачуване навчання, працевлаштування за результатми тестування.

Як потрапити:подати резюме на сайті.

Деталі:на сайті, або пишіть на info@evrius.com.

Intetics

Напрям:робота Sales Researcher, Functional Programming.
Місто:Харків, Київ, Львів.

Вимоги до кандидатів:

Sales Researcher (Харків):

• англійська — Upper-Intermediate/Advanced;
• аналітичне мислення;
• навички ефективної комунікації.

Functional Programming (Харків, Київ, Львів):

• знання хоча б однієї мови програмування;
• знання англійської на рівні pre-intermediate.

Як потрапити:подати резюме Sales Researcher (Харків)або Functional Programming (Харків, Київ, Львів), поспілкуватися з рекрутером, виконати тестове завдання, пройти фінальну співбесіду з менеджером.

Деталі:на сайтіабо пишіть на пошту a.serdyuk@intetics.com (Sales Researcher) чи t.usova@intetics.com (Functional Programming).

MaybeWorks

Напрям:робота JavaScript.
Місто:Харків.

Вимоги до кандидатів:

• розуміння та застосування принципів ООП у розробці;
• знання базових патернів і архітектури;
• досвід використання одного з фреймворків Front-end: Angular/ React/ Vue;
• уміння написати Back-end на Node.js;
• робота з БД на рівні SQL-запитів.

Як потрапити:надіслати резюме на на сайтіз позначкою «Робота DOU», пройти онлайн-інтерв’ю.

Умови:виконати тестове завдання. У разі успішного результату — працевлаштування (оплата з першого дня).

Деталі:на сайтіабо пишіть на пошту hr@maybeworks.com.

MobiDev

Напрям:робота QA.
Місто:Чернівці.

Вимоги до кандидатів:

• достатній рівень володіння англійською мовою, як письмовий, так і усний (Intermediate);
• знання процесу розробки програмного забезпечення;
• розуміння теорії тестування програмного забезпечення;
• уміння аналізувати та структурувати інформацію.

Як потрапити:надіслати резюме на chernivtsi@mobidev.biz, прикріпити до листа відповіді на запитання: чим відрізняються інтерфейси Samsung Galaxy S10, Google Pixel 4, Huawei P30 Pro, Xiaomi Redmi Note 8 (3-5основних відмінностей буде достатньо). Після цьго Вам може бути запропоновано виконати тестове завдання, пройти співбесіди.

Умови:усі члени команди отримують винагороду з першого дня співпраці. Ви будете закріплені за кваліфікованим ментором, який буде коригувати Вашу роботу, надавати рекомендації та допоможе розробити персональний план розвитку досягнення цілей.

Деталі:на сайті.

NIX

Напрям:робота.
Місто:Харків.

Вимоги до кандидатів:

• BA / Product Owner;
• CMS;
• Android;
• Tech Support;
• BA;
• .NET;
• .NET;
• PHP;
• Java Full Stack;
• QA;
• General QA.

Як потрапити:надіслати резюме на сайті, пройти тестування та співбесіди.

Умови:повна зайнятість.

Деталі:на сайті.

N-iX

Напрям:робота Trainee SQL/DataWarehouse Engineer (Teradata).
Місто:Київ, Львів.

Вимоги до кандидатів:

• диплом бакалавра чи еквівалент;
• базові знання SQL, DataWarehouse;
• розуміння концепцій DataWarehouse;
• знання ETL-інструментів;
• навики ведення документації, хороші комунікаційні навики;
• знання англійської;
• буде перевагою сертифікат про закінчення курсу з BI.

Як потрапити:надіслати резюме на сайті.

Умови:випробувальний термін — 3 місяці.

Деталі:на сайті, або пишіть на пошту lkostyshyn@n-ix.com.

Solid Software

Напрям:робота Android, iOS, Mobile app, Cross-platform software.
Місто:Львів, Харків.

Вимоги до кандидатів:

• бажання працювати з новітніми сучасними технологіями; ;
• здатність швидко навчатися і застосовувати знання на практиці;
• профільна вища освіта (бажано);
• уміння працювати в команді;
• знання Git, gitHub або інших систем контролю версій;
• аналітичне мислення і навички вирішення проблем;
• здатність залишатися зосередженим на різнопланових завданнях;
• англійська мова на середньому рівні та вище.

Як потрапити:надіслати резюме на сайті.

Умови:8-годиннийробочий день, гнучкий графік

Деталі:на сайтіабо пишіть на пошту yana.mandziuk@solid.softwareчи телефонуйте на +380508843646.

TraderEvolution

Напрям:робота Technical Support.
Місто:Дніпро.

Вимоги до кандидатів:

• технічна вища освіта / студент;
• рівень англійської — Intermediate.

Як потрапити:надіслати резюме на сайті, пройти співбесіди.

Умови:курс навчання — 1 місяць (2 заняття на тиждень, тривалість заняття — 2 години). Час навчання оплачує компанія. Після успішного закінчення курсів — стажування 1-2 місяці.Після стажування — робота за графіком: 8 нічних змін (з 00:00 до 8:00) + 4 денні зміни (з 9:00 до 18:00) на місяць.

Деталі:на сайтіабо пишіть на пошту v.ten@traderevolution.com.

Ubisoft

Напрям:робота Game Tester.
Місто:Одеса, Київ.

Вимоги до кандидатів:

• базові знання ігрового тестування / процедури звітності про помилки / життєвий цикл помилки;
• ігровий досвід, знання ігрової термінології;
• базові знання комп’ютерних і консольних ігор;
• знання Microsoft Office (Word, Excel, Outlook);
• середній рівень англійської, як письмової, так і усної;
• уважність до деталей;
• здатність працювати в команді.

Як потрапити:надіслати резюме на сайті.

Умови:робота з ААА ігровими проектами, медичне страхування, заняття з англійської або французької мови.

Деталі:Київ, Одеса, або пишіть на пошту hr_kiev@ubisoft.com.

[Дмитрий Скороход — iOS-разработчик, с 2012 по 2019 год работал в аутсорсинге, сейчас — в продуктовой компании Readdle. Автор проекта «Що має знати Senior» на DOU, в прошлом — автор iOS дайджеста]

Эта колонка для тех, кто мечтает о собственном проекте, но никак не может решиться на него. Ниже я поделюсь своими мыслями о том, почему все-таки стоит рискнуть, и предложу конкретные шаги, как это сделать. Если вы когда-нибудь мечтали о другой судьбе, мне бы хотелось подтолкнуть вас к размышлениям. Я искренне верю, что на почве ваших сегодняшних мыслей завтра может вырасти новый IT-продукт, а может быть, и произведение искусства.

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

Иллюстрация Ульяны Патоки

Преданные мечты

Если бы у вас был миллион долларов, вы бы не работали в аутсорсинге. И не эмигрировали на любых условиях. Я пробовал и то, и другое, потому что у меня тоже нет миллиона. И я не д’Артаньян, который хочет похвастаться и упрекнуть вас. Мы с вами выбрали более безопасный путь, потому что люди, которые вышли из бедности, боятся рисковать из-за страха оказаться в нищете. Да, я боюсь рисковать, и вы тоже, поэтому мы зарабатываем не созданием стартапов и продуктовых компаний, а продажей человеко-часов. А сколько стоит ваша человеко-жизнь?

Я готов поверить, что вы любите программирование. Я тоже. Но признайтесь сами себе: имея выбор, пилили ли бы вы свой проект? Аутсорсинговая индустрия забрала у вас этот выбор в обмен на стабильность. И вы выдохнули с облегчением. Все наши pet-проекты — это бизнесы, которые обречены по причине нехватки времени.

Ведь так страшно отказаться от стабильности и рискнуть! А потом рискнуть еще раз. Может быть, даже оказаться под мостом. Затем построить компанию, которая приносит прибыль, равную зарплате учителя. И наконец... понять, что деньги не главное.

Простая математика показывает, что, если продать человеко-время 200 тысяч программистов по 2000 долларов в месяц, к нам в экономику за год зайдет 4,8 миллиарда. Доход Facebook составляет 55 миллиардов при 40 тысячах сотрудников. Это шах и мат.

Компания, которая в 10 раз меньше Facebook, способна генерировать больше, чем вся IT-отрасль Украины, вместе взятая. Но у нас не появится такой компании, потому что наши руки связал аутсорсинг. Потенциальные фаундеры променяли бизнес на смузи и мохито, которые исправно поставляют заморские заказчики.

Я не просто ратую за развитие культуры предпринимательства среди IT-сообщества Украины. Я хочу сказать больше. Может быть, вы всю жизнь мечтали стать художником? В таком случае мне хотелось бы прочитать на DOU вашу историю, как программист стал художником и уехал в Сингапур по визе для творческих талантов. Зачем продавать свое время, если можно идти к своей мечте?

Кстати, о чем вы мечтаете? Может быть, это и есть ключ к вашему успеху? Например, человек, который мечтает похудеть, будет значительно счастливее, создавая приложение для похудения, чем разрабатывая банковское ПО. И неважно, заработает ли он на этом 237 миллионовдолларов.

Исследованияэкономистов показывают, что повышение уровня доходов не приводит к росту уровня счастья после определенного порога. Для США этот порог — 75 000 долларов в год. Нет смысла гнаться за деньгами, если ваша цель — счастье. Но есть смысл построить свой бизнес, сколько бы он ни приносил. Издание Inc. писало, что предприниматели более счастливы, чем наемные работники, и имеют меньше проблем со здоровьем — как соматическим, так и психическим. А если свое дело построено вокруг собственной мечты, то, я уверен, такой человек, будь он предпринимателем, художником или поэтом (ха-ха), будет еще более счастливым. И не нужен вам тот миллион, чтобы делать то, что вы бы делали, будучи миллионером. Дверь на самом деле и так открыта.

Проблема заключается в том, что стать крутым художником гораздо сложнее, чем плохим программистом. При этом любой плохой программист найдет рано или поздно свое место на рынке труда. Ни один слабый художник, поэт, писатель или предприниматель не сможет выжить на Земле. Чтобы достичь независимости, нужно стать в своем деле гораздо круче, чем вы есть сейчас. Буквально прыгнуть над своей головой. Когда все и так хорошо, для этого может попросту не быть мотивации. Ее нет у вас и нет у меня, вот почему мы с вами останемся до конца жизни наемными программистами. Или все-таки нет?

Четыре <не>простых шага

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

Следующий шаг — не опускать руки, делая свои pet-проекты. Однажды я вложил в личный проект около 5 тысяч, а получил на выходе доход в 5 долларов. Это очень разочаровывает. Даже разбивает. Сейчас я понимаю, что полученный опыт таки стоит потраченных денег.

Имея более тысячи загрузок в месяц, я не нашел способ, как монетизировать свои iOS-приложения. Но получил ценную информацию: поиск App Store способен дать органический трафик без вложений в рекламу. И я могу примерно оценить объем трафика для приложений, релевантных тем или иным поисковым запросам. Эти знания я использую, работая над своим следующим проектом. Мне нравятся нишевые вещи. Я верю, что в своей нише вы можете быть интересны. Если у вас не получилось, надо все равно идти вперед: вы не теряете деньги, а вкладываете их в получение опыта.

Третий шаг — купите квартиру. Никогда ее не закладывайте. А в будущем используйте для того, чтобы целый день работать над своим проектом. Почему большинство эмигрантов всю жизнь остаются наемными работниками в Эльфиях? Потому что вы не можете остановиться, пока выплачиваете ипотеку. Но в Украине с зарплатой программиста квартиру можно купить относительно быстро, необязательно в Киеве. И использовать ее для работы фултайм над своим проектом. Так что хватит смеяться над нашими бетоно-метрами! :)

Конечно, кроме жилья, вам понадобятся деньги, чтобы кормить себя и семью (если она есть). Но здесь все зависит от запросов. Зарплата джуниора находится в пределах 500-1000 долларов.Люди как-то живут на эти деньги. Если, будучи мидлом или синьором, вы зарабатываете 2-4 тысячи,вам достаточно отказаться от кафешек, одеться один раз на Седьмом километре, а потом год ходить в потертых джинсах; и вы сможете за этот год собрать денег еще на год такой жизни. Ваша мама не откажется от вас из-за потертых джинсов. Ваша жена будет даже более счастлива, если вы компенсируете экономию вниманием. А настоящие друзья всегда познавались в сложных ситуациях. Если же говорить еще более откровенно, то всем нам придется однажды выживать на государственную пенсию.

Четвертый шаг — саббатикал. У меня есть опыт перерывов в наемном труде от 2 месяцев до года для того, чтобы позаниматься самообразованием и поработать над своими проектами. Вы знаете, это сложно. Как организационно, так и финансово. Но реально.

Основная сложность — действительно работать. К сожалению, не сразу удается войти в рабочий ритм, не имея начальства. Отпуска в 2-3месяца хватает только на то, чтобы отдышаться, подумать и прочитать художественную книгу. Действительно эффективный отпуск — это год. Готовиться к такому перерыву в наемной работе нужно 1-2 года.Чем больше у вас сбережений, тем лучше, потому что, когда заканчиваются деньги, начинаются нервы и ваша эффективность падает.

То, что вы гарантированно приобретете, это дисциплина. Проекты имеют свойство не взлетать. Но вероятность успеха не нулевая. Допустим, 1%. Это значит, что, если хотя бы 2 тысячи программистов возьмут по саббатикалу, результатом станет возникновение 20 новых прибыльных продуктовых компаний. Для Украины даже это будет ощутимым успехом.

Драйв, кайф и счастье

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

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

Забудьте о деньгах настолько, насколько это возможно. Важны ваши чувства. Давайте доверять себе. И пусть для каждого из нас сегодняшняя мечта завтра станет делом всей жизни. А все остальное приложится.

Привіт, мене звуть Павло, я інжиніринг-менеджер у JustAnswer. Раніше — лід, перед тим — розробник. UMC, МТС, далі Conscensia й JustAnswer. Загалом уже майже 15 років в IT. Але маю дещо незвичний для розробника бекграунд: за освітою я соціолог. І це сильно допомагає під час роботи з продуктом — маркетинг, споживацька поведінка, розуміння бізнес-потреб. Останні чотири роки працюю в середовищі, де бізнес-рішення ухвалюються винятково після висування гіпотез та перевірки їх за допомогою A/B-тестування. Прилучився на стадії, коли складність гіпотез, які бізнес хотів перевірити, уперлася в стелю можливостей комерційної платформи A/B-тестування, що була в ужитку. І компанія постала перед вибором, куди рухатися далі.

Якщо ви задумалися про A/B-тестування на своєму ресурсі, то, імовірно, для вашого проєкту вже сформовано базові показники, які б ви хотіли поліпшити. Конверсія, фінансові метрики, поведінкові чинники — те, що актуально для вашого продукту або сервісу. Якщо таких метрик ще немає, то правильним кроком буде почати з їхнього визначення.

Стаття буде корисною, в першу чергу, розробникам, адже описує основні складники A/B-тестування й базові принципи побудови інструментарію їхнього проведення. Щоправда, тут зовсім не згадано про такий важливий складник, як готування тест-плану й аналізу даних. Однак це зовсім окрема тема, варта окремого допису.

Трошки конспірології

Чи бувало таке, що ви побачили дуже привабливу пропозицію на сайті перевізника, а коли наважилися бронювати квитки, пропозиція випарувалася? Або дуже вигідно взяли пробну підписку на музичний сервіс, а того ж дня ваші друзі не бачать такої опції. Чи, можливо, ви просто тепер бачите, що сайт Amazon на комп’ютері вашого колеги має інший вигляд, ніж на вашому? Можна припустити, що за вами стежить Старший Брат (як в Орвелла), що є велика змова проти простих користувачів Інтернету і ви стали її жертвою.

Але ймовірніше, ви просто стали учасником A/B-тестування. І так, за вами стежать!

A/B-тестування. Що це таке

Поняття «A/B-тестування» походить з традиційного маркетингу і є по суті методом дослідження, під час якого контрольні елементи (варіація A) об’єкта — пакування продукту, рекламного оголошення, вебсторінки тощо — порівнюються з подібними (варіація B), у яких один або кілька елементів змінено, для того щоб з’ясувати, які зі змін поліпшують цільовий показник (Wikipedia).

А можна простіше

Якщо зовсім просто, то для того, щоб дізнатися, чи насправді нову червону кнопку натискатимуть частіше, ніж стару синю, треба в той самий період часу одній половині відвідувачів показувати червону кнопку, а іншій — синю. І спостерігати. У такому разі контрольною групою будуть люди, які бачили стару синю кнопку (варіацію А). Мета тесту — порівняти їхню поведінку з поведінкою тих, хто бачив нову червону кнопку (варіацію B). Звідси й назва — A/B-тестування. Якщо одночасно хочуть перевірити більше варіантів змін, варіацій може бути більше. Тоді тест можуть позначати A/B/C/D/../N. Хоча найтиповішим усе ж є A/B. Кому показувати, які варіації та скільки спостерігати, теж не зі стелі беруть, але про це згодом.

Навіщо ті всі складності

В основі будь-якої зміни лежить гіпотеза — наприклад, люди частіше помічають і натискають кнопки червоного кольору. Думаю, ніхто не сперечатиметься, що зміни вигляду або функціоналу продукту впливають на поведінку споживачів. І, звісно, хотілося б, щоб цей вплив був максимально позитивний, але те, що хтось із «начальства» вважає гіпотезу правильною, зовсім не означає, що користувачі сервісу вважають так само.

Розробка певного функціоналу в повному обсязі з охопленням усіх можливих випадків і дотриманням відповідних стандартів може бути досить затратною справою. А з огляду на те, що фіча може не просто не принести додаткових вигід бізнесу, а ще й сильно нашкодити, подібний «стрибок віри» виявляється невиправданим і ризикованим.

На противагу традиційному підходу A/B-тестування дає змогу:

1. Змінімізувати ризики, тому що гіпотетичне поліпшення буде доступне мінімальній кількості відвідувачів, достатній для ухвалення рішення щодо корисності гіпотези. Тут стає в пригоді математична статистика, яка дає змогу підрахувати розмір вибірки. На ці теми не одну дисертацію захистили, але формули відлякують читачів, тому просто скажу, що в онлайні є чимало калькуляторів, за допомогою яких можна це підрахувати. Наприклад, можна почати з простого: A/B Test Sample Size Calculator.
2. Заощадити десятки людино-годин, бо є змога перевірити гіпотезу, опускаючи певні кейси або не імплементуючи фічу сповна. Наприклад, для тесту щось можна захардкодити на фронтенді, не імплементуючи колів на бекенд або не витягаючи якісь дані з бази, або не впроваджувати підтримку якихось екзотичних браузерів. Приклад:щоб перевірити гіпотезу, що продажі зростуть, якщо додати підтримку нової платіжної системи, перш ніж інвестувати саме в розробку такої можливості, можна додати саму кнопку «Заплатити через Х» і рахувати, скільки людей її натискають, щоб зрозуміти, чи це матиме попит. А тим, хто її натиснув, показувати повідомлення з вибаченням. Такий підхід ще називають Demand Test, або перевірка попиту.

А, B та їхні друзі

Перш ніж перейти до практики й уникнути плутанини, варто зупинитися на базовій термінології.

• Поняття A/B-тестування й експеримент взаємозамінні в контексті цієї статті.
• Вигляд сторінки до застосування змін називають контрольним (control) або нормальним (normal). Саме з ним порівнюватимуть тестовий, змінений вигляд (test).
  І control, і test — варіації (variation), що заведено позначати літерним індексом. Контрольна варіація А й тестова варіація B.
• Якщо гіпотезу підтверджено, і ми хочемо повністю замінити оригінальний вигляд сторінки виглядом варіації, що виграла, цей процес називають нормалізацією.
• Збір інформації про взаємодію користувача з елементами сторінки називають трекінгом (tracking). Наприклад, ми хочемо зафіксувати, якщо користувач натиснув кнопку. Нам треба зареєструвати унікальний ідентифікатор, пов’язаний із цією подією. Простими словами — додати трекінг.

Готуємо A/B-тест власноруч

Але досить голої теорії. Починаймо з’ясовувати.

На ринку є чимало достойних комерційних рішень зі своїми перевагами й недоліками для тих чи інших випадків і з різною ціновою політикою: Optimizely, VWO, Google Optimize, Adobe Targetтощо. Проте, якщо A/B-тестування стають невіддільною частиною процесу розробки й ухвалення бізнес-рішень компанії, згодом її потреби, безумовно, переростуть будь-який наявний продукт і потребуватимуть власних підходів. Тому в цьому матеріалі ми спробуємо з’ясувати, як воно працює, тримається купи та як можна розробити прототип платформи A/B-тестування, щоб ухвалити поінформоване рішення про вибір платформи.

Інгредієнти

Проаналізуймо складові процесу тестування й підготовлення експерименту.

Трафік

Потрібні користувачі. Без користувачів увесь цей задум не має сенсу. Користувачів треба багато. Але вони нам потрібні не всі, а особливі. Тому трафік загрібати бажано не весь, а таргетований. Наприклад, гіпотеза про розширення бізнесу в США — нам не дуже цікаво, як відреагують на зміни відвідувачі з Європи. Або нам цікаво, як поводяться люди, що перейшли з конкретної реклами чи переглядали наші сторінки з мобільного. Тобто трафік треба відфільтрувати.

Випадковість

Важливо рівномірно й випадково поділити трафік між варіаціями. Кому дістанеться досвід А, а кому — B (або C, або D тощо, залежно від кількості варіацій)?

Трансформація

Після розподілу користувачів на варіації, треба забезпечити коректне відображення користувачеві змін, що відповідають його варіації.

Відтворюваність

Той, хто був на варіації А, після перезавантаження сторінки або повернення на неї згодом не повинен отримати варіацію B. Користувач почуватиметься дивно, і ми не зможемо однозначно визначити, яка зміна вплинула на його поведінку.

Відстеження активності

Слід забезпечити збір і моніторинг даних. Повернімося до прикладу з кольоровими кнопками. Для підтвердження або спростування гіпотези про колір кнопки, потрібним мінімумом буде фіксувати факт потрапляння користувача на варіацію і відстежувати подію «натискання кнопки». Проте що більше різних даних ми збираємо, то ліпше можемо розуміти поведінку користувачів. Для прикладу, якщо додатково фіксувати розмір екрана чи вікна, ми можемо виявити цікаві закономірності. Може статися, що власники малих екранів рідше натискають кнопку. Поясненням такої поведінки може бути усвідомлення, що до тієї кнопки треба доскролити, що роблять не всі.

Гнучкість

Серед переваг A/B-тестування — гнучкість і динамічність. Запуск або зупинка тесту мали б відбуватися незалежно від релізу змін у продукті. Бажано навіть без участі інженерів. У процесі експерименту можуть виникнути обставини, коли тест тимчасово треба поставити на паузу або скоректувати параметри аудиторії.

Часом ранній моніторинг експерименту може засвідчити, що тест провальний і показники на тестовій варіації дуже погіршилися. У такі миті може виникнути спокуса зупинити тест негайно, щоб не втрачати гроші й зробити передчасний висновок, що гіпотеза була геть неправильна й нема сенсу перевіряти її на всій вибірці. Але це може бути лише інформаційний шум, статистичної значущості досягають тільки на повній вибірці. А гіпотетично втрачені гроші мінімізовано і які є платою за інформацію та висновки. З іншого боку, це може свідчити про помилку в коді чи логіці експерименту і варто додатково перевірити, чи користувачі бачать саме те, що передбачала гіпотеза, і нічого не поламано. У разі помилки треба зупинити тест, виправити помилку й розпочати спочатку.

Що під капотом

Є два принципово різні технічні підходи до розробки A/B-тестів на вебсторінках і, що очевидно, у кожного є свої переваги й недоліки. Тут ми говоритимемо про техніки, які можна застосувати до сторінок з будь-якою архітектурою. Очевидно, що знаючи все наперед, можна спробувати «заточити» або впровадити нову архітектуру сторінок під якийсь конкретний тип A/B-тестів, яка враховуватиме переваги обох підходів. Але подібний тюнінг робити дорого й заздалегідь усього не врахуєш.

Ці підходи можна умовно поділити на Client Side (або Postload) і Server Side (або Preload).

Client Side

У межах цього підходу спочатку користувач отримує оригінальну сторінку, а JavaScript-код нашого А/B-тесту визначає варіацію і максимально швидко вносить зміни, щоб користувач не встиг помітити підміни. Тобто у нас є оригінальна сторінка й код, який заточено вносити в неї точкові зміни — трансформації.

Архітектура

Є цільова сторінка. Сторінка завжди завантажує і намагається виконати JavaScript-файл, що хоститься окремо й може містити код A/B-тесту. Якщо ми тепер нічого не тестуємо, то файл просто буде порожнім.

Наша мета — виконати цей код якомога раніше в ході циклу завантаження сторінки й зробити трансформації до того, як завантажився оригінальний контент. Можна підписатися на DOMContentLoadedабо load-івенти, наприклад, залежно від структури оригінальної сторінки й складності тесту.

Код A/B-тесту робить таке:

1. Фільтрує трафік (опційно) — ухвалює рішення, чи є поточний відвідувач нашою цільовою аудиторією. Пристрій, браузер, розмір вікна, країна користувача, залогінений, історія покупок, чи вже є щось в кошику, на якому тарифному плані, які сторінки бачив перед тим тощо. На практиці це просто ifCondition, який виконує ряд перевірок і вирішує, чи застосовувати трансформації. Можна навіть додатковий запит на бекенд від імені користувача надіслати, щоб отримати деталі, потрібні для ухвалення цього рішення. Це може суттєво затримати виконання трансформацій, але деколи це єдиний спосіб перевірити гіпотезу.
2. Визначає, чи користувач уже був на нашому тесті і йому слід показати відповідні зміни, чи це новий користувач, і треба призначити варіацію. Робимо це через cookie і рандомізацію.
3. Виконує потрібні трансформації. Тобто перефарбовує, змінює розміри й положення елементів, усуває їх чи замінює на інші.
4. Додає трекінг (опційно). Тут варто наголосити, що як до експерименту ми не цікавилися взаємодією користувачів із цільовими елементами, то доведеться додавати трекінг цих елементів і до оригінальної варіації також, щоб мати змогу ці варіації порівняти.

Трансформації бувають дрібні й непомітні, але часом гіпотеза потребує кардинальної перебудови сторінки. Або перш ніж застосовувати трансформації, потрібно дочекатися завантаження певного елементу. У такому разі користувач може спостерігати процес трансформації, а подібні спецефекти довіри до сайту не додають.

Для таких випадків є компромісне рішення. Воно не ідеальне, але може допомогти. Назвімо це технікою «білого покривала».

Щойно сторінка завантажилася досить, щоб виконувати наш код, ми кидаємо поверх усього білий непрозорий елемент, який покриває собою все, що відбувається, — завантаження оригінального контенту й процес трансформації. Коли все відпрацювало, маскування знімають. З боку користувача це має вигляд ніби відкладеного завантаження сторінки, що з’являється миттєво.

На JsFiddle можна побавитися із прикладом A/B-тесту, побудованого за цим підходом.

У цьому прикладі, якщо потрапити на варіацію B, то повторне натискання кнопки Run наочно продемонструє побічний ефект, як перемальовуються елементи за складних змін. Щоб змінити варіацію, треба почистити cookie.

Щоб стартувати, зупинити тест чи змінити розподіл трафіку, ми просто передеплоюємо наш JavaScript у те місце, де він хоститься доступними нам засобами.

Підсумки за Client Side

Pros:

• Після завантаження сторінки ми маємо набагато більше інформації про користувача, що можна використати для точнішого таргетування або як частину зміненого експірієнсу.
• Часом простіше писати код експерименту — перефарбувати кнопку, наприклад, можна за допомогою одного рядка коду.

Cons:

• Залежно від серйозності змін у варіації, можуть бути побічні ефекти, коли користувач встигає побачити оригінальну сторінку й «дискотеку», коли все перемальовується. Для конкретних випадків можуть бути свої техніки боротьби з цим, але загалом це негативно впливає на швидкодію сторінки, і для користувачів на варіації сторінка відчуватиметься повільнішою, що вплине на їхню поведінку і, відповідно, на результати A/B-тестування.
• Повільні сторінки гірші для SEO.
• Якщо гіпотезу підтверджено, і ми готові застосувати зміни варіації-переможця для всіх, код тесту перевикористати не вдасться — доведеться правити код оригінальної сторінки.

Server Side

Тут, на відміну від Client Side, треба підготувати всі (у разі А/B їх буде 2) кінцеві варіанти сторінки (варіації) з можливістю доступу за окремими посиланнями. Варіацію визначають ще в процесі оброблення http-запиту, і користувач відразу отримує потрібний варіант сторінки без накладання змін поверх. Тоді вся архітектура А/B-тесту зведеться до раутингу й установлення cookie. Опційно, але бажано для швидкодії, сторінку можна кешувати.

Звісно, це можна адаптувати під реалії кожної конкретної інфраструктури, але ось приклад з використанням Cloudflare CDN і їхнього Service Worker. Service Worker, по суті, — JavaScript, що виконується на сервері й дає змогу перехоплювати та вносити зміни до оригінального http-запиту або перенаправляти його на інші адреси. І, що важливо, цей код можна динамічно змінювати через адмінку або API.

Який вигляд у такому разі має архітектура A/B-тесту

1. Користувач робить запит на URL і потрапляє на CDN Edge server, де крутиться наш Service Worker.
2. Передусім ми перевіряємо наявність cookie в заголовках, щоб зрозуміти: він уже був на певній варіації і йому слід показати ту ж саму чи це новий користувач і варіацію треба вибрати випадково.
3. Визначивши варіацію, прокидаємо запит на відповідний route. Якщо сторінка є в кеші, CDN віддає її звідти, якщо ні — запит надсилається на origin (наш web-server), а дорогою назад response кешується. Нагадаю, для кожної варіації повинна бути попередньо підготовлена сторінка.
4. Перш ніж віддати response на клієнт, додаємо до нього Set-Cookie-заголовок з ідентифікатором варіації, щоб наступні запити потрапляли на ту саму варіацію.
   
5. Вертаємо response з розміткою і cookie-варіації.

Приклад коду й пісочниця Cloudflare:

У такий спосіб ми досягаємо кінцевої мети — користувачі «випадковим чином» можуть отримати різний контент за тим самим посиланням. Лишається тільки простежити їхню реакцію.

Щоб стартувати, зупинити або внести зміни в розподіл трафіку, ми просто передеплоюємо наш JavaScript у Service Worker доступними нам засобами — з адмінки або через API.

Як ми пам’ятаємо, трафік A/B-тесту потрібно таргетувати (фільтрувати). У разі Server Side ми можемо використати лише ту інформацію, що є в оригінальному запиті. Наприклад:

• User Agent допоможе визначити браузер або пристрій;
• Cookie;
• IP дає змогу фільтрування за геолокацією;
• Host. A/B-тест зазвичай розробляють для однієї/кількох сторінок сайту, для решти експериментального раутингу робити не треба.

Підсумки за Server Side

Pros:

• Оскільки потрібна варіація завантажується відразу і без змін, такий підхід створює оригінальну швидкодію.
• Для сторінок зі статичним контентом кожну варіацію можна додати до кеша.
• Якщо гіпотезу підтверджено, нам досить перемкнути весь трафік на варіацію-переможця.
• Ідеально підходить для лендинг-сторінок.

Cons:

• Оскільки для таргетування A/B-тесту ми можемо використовувати лише дані з оригінального http-запиту, у нас нема достатньої гнучкості у визначенні аудиторії тесту.
• Для побудови простих A/B-тестів накладні затрати на розробку вищі, бо навіть мінімальна зміна потребує дублювання цілої сторінки для потреб варіації і внесення в неї змін.
• Така методика добре підходить для лендинг-сторінок, адже вони однакові для всіх. Якщо сторінку кастомізують під конкретного користувача або вона містить багато динамічного контенту, переваги нівелюють.

Відстеження активності

Головне, для чого це все затівали, — збір даних для подальшого аналізу. І що більше різних сегментів зберемо, то ліпше. Проте збирати треба не все підряд, а вдумливо, і варто обмежитися тими, що стосуються ключової метрики експерименту.

Якщо ще раз повернутися до наших синьо-червоних кнопок, то ключовою метрикою буде конверсія (натискання кнопки). Тобто нам треба фіксувати «натискання» і «ненатискання» як базовий мінімум. Цього досить, щоб порівняти вплив кольору кнопки загалом, але мало, щоб зрозуміти нашу аудиторію. Як додаткові датапоїнти (сегменти) ми можемо фіксувати контекст користувача. Браузер, пристрій, величина екрана, локація, валюта, платіжний метод, час доби — усе, що дасть змогу сегментувати аудиторію й аналізувати поведінку в межах цих сегментів чи на їхньому перетині. Персональної інформації не потрібно та це й протизаконно. Досить мати агреговані дані для виявлення поведінкових патернів або аномалій.

Маючи такі дані на руках, можна дійти висновку, наприклад, що червона кнопка працює ліпше для користувачів 4k-екранів з Техасу вночі.

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

Архітектура

Як це можна організувати технічно? Знову ж таки на ринку є великі гравці, як-от: Google Analytics чи Facebook Analytics — кожний зі своїм API, набором правил й аналітичних інструментів. І навряд чи хтось зможе конкурувати з ними на полі даних й аналітики. Проте організовано це всюди приблизно однаково.

Усе ґрунтується на подіях, які генерує користувач. Користувач зайшов на сайт, перейшов на іншу сторінку, натиснув, заплатив тощо. Події відбуваються в якомусь контексті, знову ж сесія, пристрій, регіон.

Події можуть генерувати за замовчуванням, як-то завантаження сторінки або перехід за посиланням. А можуть кастомізувати, і їх треба додавати окремо, наприклад натискання кнопки, наведення курсору на якийсь елемент, початок взаємодії з формою, скрол на сторінці — усе, до чого можна дотягтися в DOM і має значення для тесту.

На підставі якогось набору анонімних й унікальних даних, доступних на клієнті (IP, session, agent), генерують GUID, до якого ці всі події прив’язуватимуть, щоб дані можна було правильно агрегувати.

Тобто типовий пейлоад, який генерують і надсилають на аналітичну платформу, під час настання події має приблизно такий вигляд:

На практиці все зводиться до встановлення на свою сторінку JavaScript-сніпету вибраної трекінг-системи, проініціалізованого вашим акаунтом у тій системі. Події за замовчуванням надсилатимуться автоматично, а кастомні треба буде додавати в код сторінки або експерименту вручну.

До обмежень подібного трекінгу можна зарахувати плагіни, що блокують відомі трекінг-системи для збереження приватності. Браузери теж можуть вводити деякі обмеження на надсилання даних стороннім сайтам. Таких користувачів не зарахують до учасників експерименту, бо ми не можемо отримати дані про них. Це не критична проблема доти, доки відсоток цих користувачів у нас на сайті невеликий.

Якщо ж з якоїсь причини виникне потреба організувати свою внутрішню систему відстежування, підхід лишається таким самим. Генеруємо івенти, шлемо на бекенд, зберігаємо в базу й продумуємо, як аналітики працюватимуть з даними. Завдання далеко не тривіальне, але зрозуміле, і жоден браузер такі риквести не заблокує.

Замість висновків

A/B-тестування — це потужний маркетинговий інструмент, для eCommerce зокрема. Він допомагає зрозуміти поведінку аудиторії, ухвалювати неупереджені рішення на підставі гіпотез, підтверджених даними, і як результат збільшувати конверсію лендинг-сторінок, підбирати оптимальний користувацький досвід, поліпшувати SEO-показники тощо.

Ми живемо в час нової лихоманки — інформаційної. Дані — це нове золото, і ті, хто має їх у достатній кількості й належної якості, мають велику перевагу над конкурентами.

Всем привет! Меня зовут Святослав, работаю QA gangsta lead в EVO, а в тестировании уже более 8 лет. Ищу уязвимости свыше 4 лет, веду тренинги по тестированию безопасности, провожу независимые аудиты security и QA. Также у меня есть security QA-блогдля начинающих и Telegram-канал.

Cтатья будет актуальна для QA и в особенности для DEV, так как на их плечах лежит ответственность за безопасность приложения. Поэтому будет полезно узнать хотя бы косвенно, что могут быть такие-то и такие-то дыры при разработке мобильного приложения, так как все мы люди и человеческий фактор никто не отменял. Также расскажу об инструментах, с помощью которых можно базово определить слабые места проекта. И надо помнить: дополнительные знания не бывают лишними. Чем больше спектр ваших знаний, тем больше прибавки можно косить на проектах, так как вы частично можете перекрывать некоторые должности, беря на себя больше ответственности.

Вступление

В предыдущей статьея писал о том, как с Manual QA перешел к поиску веб-уязвимостей. К чему это я?! Когда занимаешься чем-то одним длительное время, оно надоедает, и я решил попробовать разобраться, как же происходят проверки на уязвимости в мобильных приложениях. Топик взял из списка OWASP TOP 10, только для мобайла. OWASP переехал, поэтому не смогу скинуть ссылку на официальный топик.

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

После того как я открыл список и ознакомился с мобильными топ-уязвимостями, понял, что половина из них полностью похожи на вебовские, то есть OWASP TOP 10 классический, который мы все так привыкли видеть. Так как, по сути, у нативных и веб-приложений один и тот же способ работы — по типу клиент-серверной архитектуры. То есть в мобайле клиентом является нативное приложение, а в вебе — браузер, но и у того, и у другого запросы поступают на сервер. Это и приводит к выводу, что половину техник можно взять из веб-уязвимостей, чтобы применить поиски дыр в нативных приложениях...

Начнем с того, какой набор инструментов нам нужен для проведения базового анализа защищенности приложения. Да, дополню: далее я буду рассказывать, как это применять для Android-приложений. У iOS немного другая специфика, об этом в другой статье.

Что нам понадобится

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

Мобильный девайс.Либо поднятый через эмулятор Genymotion, либо реальный, но обязательно рутированный, так как без рут-привилегий пенетретить не удастся.

Santoku Linux.Этот дистрибутив был создан специально для того, чтобы проверять Android-апликухи на уязвимости. В нем уже из коробки предустановлены все нужные приложения для взлома.

В принципе все.

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

А теперь, думаю, пора перейти к разбору каждой из категорий. Начнем рассматривать их не по порядку, а с M9 — Reverse Engineering, так как пентест начинается именно с нее.

M9 — Reverse Engineering

Реверс-инжиниринг мобильного кода — обычное явление. Это процесс простого и несанкционированного анализа:

• исходного кода приложения;
• библиотек;
• алгоритмов;
• таблиц и т. д.

Чтобы получить исходный код приложения, нужно на Santoku Linux закинуть установочный файл мобильного приложения, то есть APK, открыть консоль и выполнить нетрудные команды.

Выполняем команду unzip -d diva-beta base.apk. Как вы догадались, она разархивирует приложение и все файлы положит в папку, которую мы назвали diva-beta.

Далее нужно перейти в эту папку и в ней выполнить следующую команду: d2j -dex2jar classes.dex. С ее помощью мы совершаем декомпиляцию кода, который находится в этом файле. Если мы откроем этот файл без декомпиляции, то увидим в нем только кракозябры. После отработки этой команды в папке появится новый файл с именем classes-dex2jar.jar, в котором будет нормальный исходный код приложения, пригодный для чтения человеком.

Для того чтобы открыть этот файл и начать изучать код приложения, нам понадобится приложение Jadx, которое также установлено в нашем дистрибутиве Linux. Выполняем команду jd-gui classes-dex2jar.jar.

После отработки этой команды откроется приложение Jadx. Мы увидим в нем весь исходный код и сможем понять все его недостатки, то есть найти уже с его помощью какие-то уязвимости.

M1 — Improper Platform Usage

И с M9-категории перейдем к M1. К этой категории относится неправильное использование функции операционной системы или мер безопасности платформы. Это случается часто и может оказать существенное влияние на уязвимые приложения.

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

Мы видим, что разработчик при дебаге приложения использовал logcat, чтобы понимать, какие ошибки были в данном поле. Но при компилировании приложения в релизную сборку забыл убрать эту команду дебага. Что это может означать для пользователей приложения? То, что действия будут логироваться, если там будут какие-то ошибка или предупреждения. То есть, когда юзер будет писать в форму (а, допустим, это форма для принятия карточных данных), эти данные будут мелькать в логах приложения, если пользователь допустит ошибку при заполнении формы или получит предупреждение по заполнению. Нетрудно догадаться, что к этим логам злоумышленник может получить доступ. Подробнее — в этом видосе.

M2 — Insecure Data Storage

Этот риск в списке OWASP информирует сообщество разработчиков о небезопасном хранении данных на мобильном устройстве. Злоумышленник может либо получить физический доступ к украденному устройству, либо войти в него, используя вредоносное ПО.

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

То есть нужно помнить о двух моментах:

• конфиденциальные данные в приложении надо хранить в зашифрованном виде;
• приложения могут делиться данными с другими приложениями.

Как пример возьмем форму регистрации в мобильном приложении.

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

M3 — Insecure Communication

M3 — это еще один распространенный риск, о котором разработчики мобильных приложений забывают. Передача данных в мобильное приложение и из него обычно осуществляется через оператора связи или Wi-Fi. Известно, что злоумышленники добиваются успеха в раскрытии личной информации пользователей, если эта передача не защищена. Хакеры перехватывают данные пользователей в локальной сети через скомпрометированную сеть Wi-Fi, подключаясь к ней через маршрутизаторы, вышки сотовой связи, прокси-серверы либо используя зараженное приложение с помощью вредоносного ПО. При отправке запросов на сервер с данными, которые отправляет пользователь, некоторые из них иногда посылают по протоколу HTTP вместо HTTPS.

Пример эксплуатации такой уязвимости: злоумышленник создает скомпрометированную сеть Wi-Fi, к которой подключится пользователь. Затем этот man in the middle начинает анализировать весь трафик, который будет ходить через него. Соответственно, данные пользователя, которые отправляются к серверу по HTTP-протоколу, могут перехватываться. Злоумышленник будет видеть его креды в перехваченном пакете. Ниже приведены примеры, как передавать данные плохо и как — хорошо. Также можно посмотреть этот видосо перехвате трафика.

Плохо:

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

M5 — Insufficient Cryptography

Ладно, мы применили шифрование, о котором говорили в разделе о предыдущей уязвимости. Но если мы используем слабые процессы шифрования/дешифрования или допускаем огрехи в алгоритмах, запускающих их, то данные пользователей опять становятся уязвимыми. Есть три способа, с помощью которых злоумышленники пытаются использовать криптографические проблемы:

• получить физический доступ к мобильному устройству;
• следить за сетевым трафиком;
• использовать вредоносные приложения на устройстве для доступа к зашифрованным данным.

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

На картинке выше видим, что разработчик применил метод хеширования MD5, который прям так и кричит: «Ломай меня полностью!» Это один из самых легких методов.

При перехвате запроса от юзера мы увидим засекреченные на первый взгляд данные.

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

M4 — Insecure Authentication

Плохие схемы аутентификации позволяют злоумышленнику анонимно выполнять любые действия, доступные пользователю, в мобильном приложении или на сервере, используемом мобильным приложением. Слабая аутентификация для мобильных приложений довольно распространена из-за формфактора ввода мобильного устройства. Формфактор настоятельно рекомендует использовать короткие пароли, которые часто основаны на четырехзначных PIN-кодах. Требования аутентификации для мобильных приложений могут существенно отличаться от традиционных схем веб-аутентификации из-за требований доступности. Ожидается, что в традиционных веб-приложениях пользователи будут подключены к сети и будут аутентифицироваться в режиме реального времени.

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

Для примера: злоумышленник может использовать просто какой-то анализатор приложения, допустим тот же Burp Suite. Ему достаточно проанализировать, какие есть страницы у этого приложения.

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

В этом запросе можно:

• обратить внимание на урлы;
• обратить внимание на тип юзера;
• попробовать подменить токен, подобрав нужный (с доступом к админским функциям), и т. д.

О том, как настраивать анализатор к мобильному приложению, я писал в статье о M3 — Insecure Communication.

M6 — Insecure Authorization

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

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

Поиск можно делать также с помощью Burp Suite, пытаясь выполнить запросы, которые доступны админу, в качестве обыкновенного пользователя. Смотрите уязвимость M4.

M7 — Client Code Quality

Риск M7 возникает из-за плохой или противоречивой практики кодирования, когда каждый член команды разработчиков придерживается разных практик кодирования и создает несоответствия в конечном коде. Экономия для разработчиков здесь заключается в том, что, даже если распространенность этого риска общая, его выявляемость низкая. Хакерам нелегко изучить паттерны плохого кодирования, часто требуется непростой ручной анализ. Из-за плохого кодирования пользователь мобильного устройства может столкнуться с замедлением обработки запросов и невозможностью правильно загрузить необходимую информацию.

В пример можно привести историю с WhatsApp, когда его инженеры обнаружили возможность переполнения буфера путем отправки специально созданной серии пакетов. Для этого не нужно было отвечать на вызов, и злоумышленник мог выполнить произвольный код. Оказалось, что такая уязвимость использовалась для установки на телефон программ-шпионов. Эту услугу продала израильская компания NSO Group.

Не стоит использовать функции, которые могут переполнить буфер, вот так:

M8 — Code Tampering

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

• к другим приложениям в вашем телефоне;
• к поведению пользователя.

M10 — Extraneous Functionality

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

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

Увидим, что здесь разработчик оставил подсказку, что нужно ввести, чтобы получить доступ к необходимым нам данным. Видос здесь.

Подытожим

Теперь вы знаете:

• об OWASP Mobile Top 10;
• инструменты, с помощью которых можно искать уязвимости;
• программах, в которых можно попрактиковаться в поиске уязвимостей.

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

Всем привет! Так получилось, что я уже около семи лет занимаюсь машинным обучением. В последние несколько из них я как исследователь и CTO Neurons Lab часто работаю с финансовыми данными в рамках проектов, связанных с инвестиционным менеджментом и алгоритмическим трейдингом. Чаще всего клиенты приходят с текущими стратегиями, которые нужно оптимизировать, или идеями с альтернативными данными, которые потенциально могут прогнозировать рынок. Конечно же, анализ данных в таких задачах — наше все. Наряду с большой ответственностью за капитал инвесторов :)

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

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

На написание этой статьи меня вдохновили работы доктора Marcos Lopez de Prado. Для детального погружения в тему крайне рекомендую прочесть его публикации, презентации егосеминарови книги. Также ряд дополнительных полезных материалов по теме вы сможете найти в конце статьи.

Проблемы эконометрики

Реальные данные сложнее, чем «цены, спрос и предложение»

Стандартная процедура в финансовой математике — взять временной ряд каких-то цен, обработать его с помощью time series differentiation, после чего построить какие-то модели распределения и показать, что эта модель описывает эти данные (безотносительно того, будь это ARIMA или стохастическое дифференциальное уравнение Фоккера-Планка).

В чем тут проблема?

• Данные на рынках изначально не структурированы (отдельные заявки на торги, упоминания в новостях, финансовые отчетности), а эконометрические модели используют красивую последовательность цен (интересно, откуда они взялись?).
• Очень низкое отношение сигнала к шуму.
• Удаление памяти временных рядов (да-да, это про дифференциацию временных рядов, см. книгу).

Финансовые модели в большинстве своем работают с максимально неинформативными данными, еще и обрабатывая их неправильно и объясняя паттерны in-sample (об этом — дальше).

Корреляции и линейные зависимости ничего не объясняют

Из университета мы знаем, что корреляция объясняет меру линейной зависимости между двумя случайными величинами. Более того, мы даже слышали о том, что корреляция != причинно-следственной связи.

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

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

Самый простой пример того, как корреляция «лажает», виден на картинке ниже: очевидная нелинейная зависимость справа показывает корреляцию −0.008.

Image Source

Эконометрические модели объясняют прошлое, но ничего не предсказывают

Преимущественная часть финансовых моделей основана на объяснении вариативности данных внутри выборки. Мы привыкли в машинном обучении всегда считать ошибку на out-of-sample данных, и об этом создано много мемов, но в эконометрике, которая изначально позаимствовала свои методы из биологии, это просто не принято!

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

Только не показывайте этот мем эконометрикам

«Статистическая достоверность» недостоверна

Опять-таки, из университетского курса статистики мы знаем, что если мы получили p-value, достаточно низкое для какой-то переменной, то это значит, что мы отбрасываем нулевую гипотезу о неважности этой переменной и считаем ее «достоверной». Для того чтобы увеличить уровень достоверности, мы можем ставить границу для этого p-value. Часто оно равно 0.01 или 0.05.

Вот только это не совсем то, что нам нужно.

• P-values требуют сильных предположений о данных и моделях (не коррелированные переменные, residuals распределены нормально, и так далее), которые практически не встречаются в реальном мире.
• Нам вообще-то не так интересно опровержение гипотезы H0 in-sample, нас больше интересует подтверждение H1 out-of-sample.

Если что, то даже американская ассоциация статистиков не так-то положительно относитсяк этим p-values. Но расскажите об этом у себя на кафедре :)

Бэктестинг как способ исследований

Бэктестинг — это процедура проверки стратегии на исторических данных одного или нескольких финансовых инструментов, чтобы понять, как стратегия бы отработала «в прошлом», и на основе этого оценить риски ее поведения в будущем.

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

Более того, бэктестинг — это все один большой и красивый набор данных in-sample. Сделать модель, которая хорошо заработает в прошлом, — проще простого, вопрос только в том, как она отработает на живых деньгах.

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

Чем больше экспериментируем — тем лучше результат. Как удобно, да? (см. книгу)

Машинное обучение поможет?

С эконометрикой и финансовым моделированием вроде разобрались, понятны проблемы и как машинное обучение может помочь. Почему же тогда у многих попытки обучить модели на исторических данных ни к чему не приводят? Пройдемся по тем же пунктам, но уже с указанием проблем машинного обучения в них. Кому интересно углубиться в тему, 14 марта я буду проводить воркшоп по этой теме на конференции Data Science UA Conference.

Сложные данные надо еще приготовить

Неструктурированные данные сами по себе — еще не панацея. Даже с сырыми данными с рынка (ticks) или с альтернативными данными как sentiment нужно еще серьезно поработать.

Правильный семплинг данных

Зачем вы считаете свечи каждые N минут? Рынок ведь работает не по часам, а по ивентам: намного логичнее делать свечи каждые X долларов торгов или похожим образом (см. Bars).

Главная ценность альтернативных подходов заключается в том, что внутри каждой свечи у нас будет храниться не промежуток времени, а какой-то логический промежуток торговли. Это приведет к тому, что каждая свеча по отдельности будет более информативна, и во всех них будет схожее количество информации. Во временных свечах же вполне возможна ситуация, когда в одном часу не происходило ничего, а в следующем — рынок рухнул. Давайте посмотрим, что происходит, если мы будем строить свечи (комбинация из минимального, максимального, первого и последнего значений цен заявок за какой-то период времени) из разных периодов времени:

Примеры сырых цен, временных, «объемных» и «долларовых» свечей

Также можно увидеть, что свечи, созданные на основе периодов времени, имеют намного меньше вариативности, чем другие:

Вариативность цен внутри разных свеч

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

Правильная нормализация данных

Известное нам дифференцирование временного ряда напрочь удаляет всю память об эволюции цен (см. Fractional differentiation).

На помощь приходит не особо известная в широких кругах техника fractional differentiation. Оператор разницы математически обычно представлен целым числом, что и стирает память с лагом этого целого числа. А что, если мы могли бы использовать дробное число от нуля до единицы?

Пример работы fractional differentiation. Image Source

Анализ ADF-статистики (о стационарности временных рядов) и разные параметры fractional differentiation: от 0 до 1. Как видим, оптимальные параметры всегда меньше или равны 0.5!

Как видно, это преобразование все еще делает временной ряд стационарным, но одновременно и оставляет информацию о предшествующих трендах. Детали по реализации смотрите в источнике 1 и источнике 2.

Поправка на IID-гипотезу

Машинное обучение работает тогда, когда обучающая выборка сгенерирована независимо друг от друга, чего нельзя сказать об окнах временных рядов, которые не только пересекаются друг с другом, но еще и фичи с лагом вносят зависимости, которые только мешают обучению (см. Sampling).

В данном случае мы можем воспользоваться техниками подсчета «пересечений» окон, используемых для обучения. Если вкратце: чем больше одно окно пересекается с другими — тем меньший индекс «уникальности» мы ему присваиваем. Далее нам очень удобно использовать этот индекс в комбинации с алгоритмами на основе деревьев решений, как random forest: мы можем или взвешивать каждый обучающий пример на основе индекса уникальности, или использовать bootstrap в бэггинге, который будет сэмплить «не уникальные» примеры с меньшей вероятностью.

Скорее всего, получится так, что большая часть примеров в выборке будет «не уникальными».

Правильный выбор таргета для прогнозирования

В мире с stop losses и take targets прогнозировать цену через N часов — глупость. Наш таргет должен быть максимально похожим на принятие решения (см. Triple barrier labeling).

Техника triple barrier labeling позволяет размечать данные на основе «окна будущего». Например, если мы хотим открыть сделку в следующий час, нам нужно прогнозировать не что произойдет ровно через час, а каким будет максимальное движение цены и в какую сторону в течение этого часа (а вдруг ровно через час цена пойдет вверх на 1%, но в течение этого часа будет бОльший скачок на 5%?). Визуально эта техника представлена на иллюстрации ниже:

Пример того, как надо размечать данные в пределах одного окна «в будущем», Image source

Что делать с зависимостями?

Раз мы решили, что корреляция (или, что еще хуже, какие-то околоэвклидовые метрики) не подходит для определения зависимостей или меры схожести, что мы можем тут использовать? Я вижу два пути:

• «Литературный»: использовать меры на основе теории информации (например, mutual information ratio) или статистические расстояния (KL divergence, EMD и так далее).
• «ИИ-шный»: использовать подходы metric learning, возможно, на основе автоэнкодеров или сиамских нейронных сетей.

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

Как мы видим, метрики как information variation и max correlation, о которых можно детальнее прочесть тут, справляются намного лучше с выявлением нелинейных паттернов.

Кросс-валидацию тоже надо сделать правильно

Недостаточно просто тестировать работу алгоритмов на каком-то куске данных «в будущем». Стандартная K-Fold кросс-валидация будет точно прогнозировать «прошлое», а специализированная кросс-валидация для временных рядов будет нарушать IID-семплингвыборок, особенно если фичи считаются с лагом.

Есть несколько способов улучшить кросс-валидацию: например, чередовать окна для тренировки и тестирования в хронологическом порядке с «промежутками» между ними. Все для того, чтобы выборки были максимально независимы (пример на иллюстрации ниже). Второй способ — это комбинаторная кросс-валидация, о ней детальнее можно почитать в книге Dr. Lopez de Prado.

Image Source

Значимость факторов out-of-sample

Да, feature importance — это выход для замены p-values. Но его тоже нужно использовать out-of-sample. В идеале — совместить с вышеописанными методами кросс-валидации и считать распределение важностей на кусочках кросс-валидации. Таким образом мы сможем понять предсказательную значимость фич «по-настоящему». Более детально метод можно изучить и запустить код в этой статье.

Пример важности факторов для настоящего датасета с несколькими искусственными шумами для валидации метода

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

Бэктестинг — это не способ исследований

Гипотеза о финансовом рынке чаще всего включает предположение о какой-то зависимости, которую можно восстановить и прогнозировать с какой-то точностью в будущем.

Мы поговорили о том, как выбирать переменные, между которыми может быть зависимость, как ее считать и как проверять out-of-sample. Где-то посерединке будет алгоритм машинного обучения, который при адекватной постановке задачи и данных будет что-то прогнозировать. Бэктестинга в исследованиях нет!

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

Не надо подгонять модельки под бэктест. Сначала — исследования гипотез о зависимостях (то есть правильное машинное обучение), а потом постройка торговых стратегий. Плохой бэктест? Начинаем исследования сначала, и никак иначе.

Выводы

Я надеюсь, что теперь немного понятнее, почему машинное обучение «в лоб» в финансах не работает, но легче от этого точно не стало.

С другой стороны, вполне очевиден вектор исследований и улучшения компетенций.

Правильная «финансовая» постановка задачи:

• По возможности, используйте сырые данные о торгах, а не подготовленные «свечи» из публичных источников — они статистически содержат меньше ценной информации.
• Нормализуйте ваши данные так, чтобы они не удалили память и паттерны (касается не только финансов, но и всех других областей).
• Следите за тем, чтобы выборка была действительно независима, и не нарушалась ключевая IID-гипотезао распределении данных.
• Подготовьте целевую переменную соответственно вашей торговой логике, а не на основе «что будет через N времени».

Более глубокое понимание входных и выходных данных и выбор метрик:

• Когда делаете изначальный exploratory data analysis, визуализируйте зависимости не на основе корреляций, а на основе более сложных метрик: корреляции не отображают ничего сложнее простых линейных взаимосвязей, которые в реальной жизни практически не встречаются.
• Эта же идея важна и в других задачах, связанных с временными рядами: корреляция и эвклидовы метрики не оптимальны, попробуйте другие метрики, указанные в этой статье, или же специализированные, такие как dynamic time warping.

Детальный анализ обученных моделей:

• Обязательно исследуйте значимость факторов на кросс-валидации — это поможет понять настоящие драйверы рынка и очистить датасет от слабых или вообще случайных признаков.
• Точно такая же логика работает и в других задачах, особенно учитывая ремарку о том, что p-values в реальной жизни не могут определить качество переменных из-за нереалистичных ограничений к задаче.

Правильная валидация гипотез и разделение с бэктестингом:

• Не делайте ошибки эконометрического моделирования: ваши модели должны прогнозировать будущее, а не объяснять прошлое. Объяснение ваших моделей оставьте feature importance и детальному анализу обученных моделей.
• Правильная кросс-валидация: она должна учитывать IID-семплингвыборок и реалистичность постановки эксперимента (не предсказываем прошлое, и так далее). Обязательно попробуйте combinatorial cross-validation в других задачах, она дает более точную оценку точности сравнительно с K-Fold.
• Бэктестинг вообще не входит в исследование. Если ваши модели не могут торговать в плюс — не экспериментируйте с бэктестингом, проверяйте все описанные выше шаги, которые касаются только машинного обучения.

И да, все это — только об исследованиях, которые составляют от силы 10% работы над торговыми стратегиями. Еще более сложная работа вас будет ждать при внедрении и живых торгах, оптимизации, обновлении и поддержке, но об этом — в другой раз.

Список литературы

Базовая литература:

• Quantopian lectures for the basic information;
• Successful algorithmic trading;
• Advanced algorithmic trading;
• Python for Finance;
• Derivatives pricing in Python.

Прикладная литература:

• Advances in Financial machine learning;
• Dr. Lopez de Prado seminars;
• ML and RL in Finance;
• ASA guide on p-values;
• On feature importance in Finance;
• On data preparation and labeling;
• Machine learning in Finance library.