Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.

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

Первым делом вам стоит понять, на каком вы проекте

Накопив опыт от участия в проектах, я бы условно разделил их на 3 вида:

• проекты без тестирования;
• проекты с недобросовестным тестированием;
• проекты с тестированием.

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

Что такое Maturity Model

И тут я очень ловко вставлю цитату из «Википедии»:

Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности.

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

Собственно, с этого и началась разработка Maturity Model. В 80-хгодах министерство обороны США осознало, что не может точно оценить качество работы подрядчиков по разработке ПО. А так как это государственная структура еще и такого уровня, это неприемлемо. Деньги-то государственные, дедлайны четко очерчены, да и надежное ПО для вооружения позволит всем спать спокойнее. Исходя из этого, министерство поручило Software Engineering Institute заняться созданием подобной системы оценки и спустя год был создан первый опросник, а спустя 4 года была создана первая версия модели.

Уровни Maturity Model

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

Где в Maturity Model тестирование

Для тестировщиков есть своя особая ММ, ее называютТММi. Она также содержит 5 уровней, на которых я хотел бы остановиться детальнее и рассмотреть, что характерно для каждого из них.

Первый уровень — «Начальный»

На первом уровне тестирование происходит не структурировано и хаотично. Отсутствует стабильная среда для поддержки процессов тестирования. Команда не уделяет внимание планированию и стандартам.

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

Как результат:

• нет тестовой документации;
• продукт нестабилен;
• отказ от процессов во время проблемных ситуаций.
• Тестирование — не более чем помощь в отладке

Второй уровень — «Повторяемый»

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

Главная цель — убедиться, что продукт соответствует заданным требованиям.

Как результат:

• есть основные виды и типы тестирования (интеграционное, модульное, регрессионное, приемочное);
• внедрены тест-планы;
• тестовые активности мониторятся и контролируются;
• процесс задокументирован и может быть повторен.

Третий уровень — «Определяемый»

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

Как результат:

• тестирование начинается с этапа требований;
• добавляются активности, позволяющие работать более эффективно (внутренние тренинги, дополнительные ревью);
• внедряется нефункциональное тестирование.

Четвертый уровень — «Измеряемый»

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

Как результат:

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

Пятый уровень — «Инновационный»

На пятом уровне все подходы и процессы хорошо налажены. Команда не останавливается на этом этапе, а продолжает систематически улучшать процессы, постоянно пытаясь снизить время цикла тестирования и time-to-market без снижения качества проекта. Тестирование сфокусировано на превентивности. Добавляется автоматизация для более эффективного использования ресурсов.

Как результат:

• продолжение улучшения процессов;
• фокусировка на превентивности и оптимизации.

Каким образом помогает знание этой структуры

Кейс № 1. Недобросовестное тестирование

Однажды я попал на небольшой проект, где тестирование проводилось заказчиком, его друзьями или котейкой. Оценив ситуацию и взглянув на модель, мы можем понять, что мы находимся на уровне № 1 и нам стоит ориентироваться на уровень № 2 во время планирования активностей. После приведения в порядок Jira, где было огромное количество багов (из которых большинство — дубликаты или не воспроизводимы), я занялся составлением тестовой документации в виде чек-листов и налаживанием основных процессов тестирования. Таких как регрессионное тестирование и санити проверки во время крупных изменений.

Кейс № 2. Без тестирования

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

• проект только стартует;
• на проекте не было необходимости в тестировщике, пока был небольшой функционал;
• команда full-stack закрывала нехватку тестировщиков с помощью качественного code-review и dev-testing.

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

Кейс № 3. Тестирование было

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

Кейс № 4. Три в одном

Когда я пришел на свой проект в Provectus, я столкнулся с ситуацией, в которой было всего по чуть-чуть от трех кейсов, описанных выше. Как и в кейсе № 1, первым делом необходимо было привести в порядок Jira. Как во втором случае, было решено все делать сразу качественно, чтобы сразу руководствоваться вторым уровнем. Потому я сразу начал разрабатывать тестовую документацию и внедрять тест-менеджмент инструментарий. Также постарался выжать максимум из артефактов прошлых итераций, как было в третьем случае.
Спустя совсем короткий срок, я могу смело сказать, что мы уже целенаправленно идём на третий уровень — даже подключили тестирование на этапе бизнес требований :)

Выводы

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

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

За останні два роки кількість спеціалістів в топ-50 найбільших ІТ-компаніях виросла більше ніж на третину — з 43 тис. до 58 тис. Одразу дві компанії перетнули поріг «6 000 спеціалістів», а ще оновилася трійка лідерів рейтингу.

З липня по січень кількість фахівців зросла на 4 731 (11.6 %) в топ-25 та 5 797 (11%) в топ-50 порівняно з першим півріччям 2018-го. Темпи зростання топ-25 стали рекордними за останні п’ять років.

Зростання загальної кількості спеціалістів в 25 найбільших ІТ-компаніях України

Відносні показники темпів зростання

Якщо поглянути на річні показники, то в 2018-мукількість спеціалістів в топ-25 зросла на 18% порівняно з 2017 роком. Активніший ріст був лише в 2012 та 2013 рр. (19% і 24% відповідно).

Річні показники темпів зростання

Зростання «великої п’ятірки» за друге півріччя 2018 склало 12% (2 573 фахівці). Усього в топ-5 працює 23 865 спеціалістів, що складає 41% від загальної кількості топ-50.

Динаміка росту топ-5 компаній за період з серпня 2011 по січень 2019

За 6 місяців 2018 року лідер рейтингу EPAMвиріс на 900 спеціалістів і перетнув відмітку у «6 000 фахівців». Усього за минулий рік компанія виросла на 1 100 спеціалістів. Компанія пов’язує це з глобальним ростом частки проектів цифрових перетворень та комплексних рішень, на яких спеціалізуються українські офіси і, як наслідок, збільшенням кількості робочих місць. Топ-3 ІТ-спеціалізацій серед фахівців, з якими EPAM почала співпрацювати в 2018 році: Java/BigData, Cloud/DevOps і TestAutomation.

На другому місці — SoftServe, яка стала лідером за зростанням. За останні півроку компанія розпочала співпрацю з 954 спеціалістами. За результатами 2018 року у SoftServe +1 470 спеціалістів, і вона стала другим 6-тисячникомрейтингу.

GlobalLogicпродемонстрував стрімке зростання в 2018 році, в результаті чого компанія стала третьою найбільшою ІТ-компанією в Україні. За друге півріччя GlobalLogic виросла на 532 спеціалісти, а всього за рік — майже на 800. У компанії зростання пов’язують з розвитком тих, що вже існують, і появою нових проектів в усіх українських локаціях. За останні півроку компанія в Києві перетнула позначку у 2 000 фахівців, у Львові — 1 000 осіб, у Харкові — впритул наблизилася до цифри в 900 інженерів. Нові спеціалісти — це переважно розробники на Java, JS (React framework), C++, а також фахівці Java QA Automation і DevOps.

На четвертій сходинці — Luxoft. За минулий рік кількість спеціалістів тут залишилася без змін. Нагадаємо, що в січні DXC Technology купив Luxoft за $2 млрд. Останні зазначають, що в компанії роблять акцент на фахівцях з високим рівнем кваліфікації, а не беруть кількістю, оскільки сфокусовані на розробці рішень для клієнтів замість класичного аутсорсингу. Відсутність росту не пов’язана з угодою з DXC, і компанія працює в звичному режимі. Угода з DXC відкриває для Luxoft великі можливості в контексті нових проектів і напрямів бізнесу, в тому числі для України як найбільшого центру розробки в компанії.

Ciklumзамикає п’ятірку лідерів — за 2018 рік компанія виросла на 407 спеціалістів. І це рекордне зростання для Ciklum за всю історію рейтингів топ-50 (топ-25 в минулому).

За друге півріччя абсолютні прирости понад 200 чоловік показали сім компаній: SoftServe (954 спеціалісти), EPAM (900), GlobalLogic (532), Ring Ukraine (350), Nexteum (230), Intelliasі ZONE3000 (по 200).

Лідери росту, липень 2018 — січень 2019 (топ-12)

За останні півроку кількість спеціалістів в Ring Ukraine збільшилася на 70%. Збільшення команди київського офісу пов’язують з постійним зростанням кількості користувачів і розширенням лінійки продукції Ring. Йдеться про всі R&D, Engineering і Data команди. За даними компанії, активний найм буде здійснюватися і в 2019 році.

Також у 2018-мусуттєво виріс Intellias — на 400 спеціалістів. Компанія продовжує розвивати співпрацю із великими замовниками, зокрема HERE. За друге півріччя 2018 року було розпочато 16 нових проектів у сферах Automotive, Location Based Services, Fintech. 60% вакансій, закритих за цей період, стосуються рівня Senior+. В основному це Java, DevOps, JavaScript, C++ інженери. Компанія відкрила новий центр розробки в Харкові та планує подальшу географічну експансію.

Динаміка зростання топ-5 компаній-лідерів росту

Графіки побудовано для компаній, які потрапляли до рейтингу не менше 5 разів.

Суттєве зростання Genesisпов’язане з уточненням даних — раніше компанія подавала кількість працівників в Україні, не враховуючи віддалених.

В рейтингу з’явилося дві нові компанії — TicketsUA (38 місце) та G5 Entertainment (49 місце), а також на 48 сходинку повернувся Daxx BV.

13 компаній з ТОП-50 відкрили нові офіси у другому півріччі

За останні півроку вдвічі більше компаній з топ-50 відкрили нові офіси, ніж у січні-липні 2018 року (13 проти 6). Щодо українських локацій — нові офіси з’явилися в Києві, Львові та Рівному. Різноманітніша географія за кордоном — офіси відкривали в Малазі, Берліні, Варшаві, Кракові, Торонто, Турині, Лондоні, Бухаресті, Ейндховені, Шарлотт, Чикаго і навіть в Токіо й Сеулі.

43 компанії з топ-50 мають офіси в Києві. У Львові та Харкові офіси є тільки у 21 та 20 компаній відповідно. Найбільшою компанією Києва є EPAM (понад 2 800 спеціалістів), Харкова — NIX Solutions (1 700), Львова — SoftServe (понад 3 000).

Розподіл спеціалістів 50 найбільших ІТ-компаній по містах України

Без релокації та з активним ростом в 2019-му

40% компаній планують зростання більше ніж на 100 спеціалістів у першому півріччі 2019 року. Не планують збільшувати кількість спеціалістів тільки 2 компанії з 45, що взяли участь в опитуванні.

Плани компаній щодо розширення персоналу на найближчі півроку

Графік побудовано на основі відповідей 45 компаній з топ-50

З релокацією все без змін — більшість компаній не планує вивозити спеціалістів за межі України.

Плани щодо релокації спеціалістів за межі України в найближчі півроку

Графік побудовано на основі відповідей 45 компаній з топ-50

Повна версія топ-50 і дані минулих рейтингів доступні на сторінці jobs.dou.ua/top50.

Інфографіку підготував Ігор Яновський.

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

Привіт, Я Лідія Рудєва, Product Owner of HR & Recruitment Team в IT-компанії Hubber. У сфері загалом працюю понад 7 років. У цій статті спробую показати, що не все втрачено, якщо ваш співробітник хоче звільнитися. Є прийоми, за допомогою яких можна з’ясувати істинну проблему, яка виникла в людини, та вирішити її без звільнення.

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

«Мені потрібно з тобою поговорити»

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

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

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

Частина людей, які вирішують піти з компанії, не називають справжню причину через страх, сором, відчуття неможливості вирішити питання. Наприклад, коли ми робимо офер кандидату, а він чи вона говорять: «Дякую, але я не готовий/ва його прийняти», — то абсолютно звичним та закономірним буде питання: «Будемо вдячні за зворотній зв’язок. Що вас зупиняє? Чому вирішили відмовитися?». І тут розвертається безмежне поле варіантів та відповідей, а значить, і можливих варіантів дій:

• Маленька зарплата.
• Зате у нас є бонуси за успішні проекти!

• Офіс знаходиться далеко від дому.
• Але ж ми оплачуємо таксі.

• Я не встигаю на тренування.
• Ха, у нас є зал просто в офісі (або ж ми оплачуємо ваші тренування).

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

Незадоволеність матеріальною компенсацією

Саме про неї говорять найчастіше як про причину звільнення. Що ми можемо зробити?

• Ще раз переглянути актуальні зарплати на ринку та здійснити корегування в рамках компанії.
• Переглянути систему оцінки ефективності діяльності співробітників. Ідеально було б долучити до розробки оновленої системи і самих співробітників.
• Зробити прозорою залежність зарплати від результатів роботи компанії/команди/співробітника (залежить від ситуації в конкретній компанії).

В моєму досвіді близько 50% запитів про звільнення тим чи іншим чином стосуються грошей (у різних спеціалістів цей відсоток різний). У 8% випадків питання вирішувалося лише проясненням залежності зарплати від результатів. У 10% цього було недостатньо, але вдавалося утримати співробітників, спільно переглянувши систему мотивації, врахувавши інтереси усіх. Решту запитів можна було задовольнити саме підвищенням. Вдасться чи не вдасться позитивно вирішити питання, залежить від готовності компанії збільшувати не загальний бюджет, а бюджет на конкретного спеціаліста.

Втрата інтересу до самого змісту роботи

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

В Hubber ми використовували так звані «креативні user story», щоб вирішити пріоритетні задачі бізнесу і дати співробітникам проявити креативність. Так, щоб зменшити кількість відписок від наших розсилок в системі, команда запропонувала ідею разом з контентом використовувати персонажа — песика рассел тер’єра на ім’я Хаббі. Кількість відписок за перший же місяць зменшилася.

Песик Хаббі в розсилці

Відсутність зворотного зв’язку

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

• Визначити хоча б базові критерії ефективності. Якщо це складно зробити одразу для кожної конкретної позиції/ролі, то можна почати з критеріїв на рівні компанії.
• Розвивати культуру зворотнього зв’язку на рівні процесів, а краще корпоративної культури. Це може означати, що перед вами виникне додаткове завдання — навчити співробітників, які мають надавати зворотній зв’язок, робити це. Адже було б помилкою вважати, що це вроджена навичка.

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

Немає відчуття команди, підтримки зі сторони менеджменту

Звісно, це достатньо глибинні питання, але й на них можна впливати.

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

Особливо цінними є зустрічі з бізнес-team. Це зустрічі, які проводяться для окремих команд або для співробітників усієї компанії, де менеджмент близько години відверто відповідає на питання співробітників. Наприклад: «Коли ми переїдемо в новий офіс?», «Коли ми виходимо на новий ринок?», «Яким, у вашому розумінні, має бути ідеальний співробітник компанії?» і т. д.

Зустріч з бізнес-team

Дати можливість створення команд в рамках компанії, її продуктів чи проектів, які можуть стосуватися клієнтів або життя в самій компанії, її соціальної активності. Наприклад, команда-гільдія UI/UX дизайну. Або команда з формування бренду роботодавця — HR, рекрутери, scrum master, розробники, менеджери з продажів і всі, хто відчуває бажання розповідати про компанію як найкраще місце для розвитку кар’єри.

Відобразити в мотиваційній системі важливість саме командної роботи, а командність — на рівні цінностей компанії.

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

Відсутність кар’єрних можливостей

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

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

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

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

Бажання взяти перерву в роботі

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

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

Бажання розібратися в особистому житті.Нарешті дописати наукову роботу, потреба бути поруч з кимось із близьких, бажання отримати додаткову освіту.

Бажання зустрітися з собою.Необхідність переосмислити свої цінності, бажання вирушити у мандрівку. Людина ставить собі питання: «Що хочу робити, чим хочу займатися далі? Хто я? Чого я хочу тепер?». Я часто стикалася із такими темами під час One to One. Їх вдавалося вирішувати тривалішою відпусткою та контактами психотерапевта, однак досвід колег говорить про те, що цього не завжди достатньо.

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

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

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

І якщо все-таки прощання

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

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

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

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

[Виталий Малаховский, iOS Tech Lead в BetterMe. Более 7 лет в мобильной разработке, участник конференций, ментор. В свободное время замечен в музыкальной группе «Каменщики»]

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

Harold Abelson, Gerald Jay Sussman «Structure and Interpretation of Computer Programs»

В русском переводе — Харольд Абельсон, Джеральд Джей Сассман «Структура и интерпретация компьютерных программ»

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

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

Michael Feathers «Working effectively with legacy code»

В русском переводе — Майкл К. Физерс «Эффективная работа с унаследованным кодом»

Майкл Физерс пишет о работе с кодом, который вам достался (в том числе от самих себя). Главная идея: пишите тесты, а если без них, то делайте все предельно аккуратно. Книга полна примеров рефакторинга и реорганизации кода для последующего упрощения поддержки. В изобилии примеры из процедурного программирования. А после этого следует плавная подводка к ответу на вопрос, в силу чего ООП-код намного более поддерживаемый и более простой для восприятия.

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

Однозначно стоит прочитать инженеру ПО независимо от направления работы. По-хорошему стоило бы изучать в связке с Фаулеровским рефакторингом.

P. S. Даже не пытайтесь читать в русском переводе. Только оригинал.

Martin Fowler «Patterns of Enterprise Application Architecture»

В русском переводе — Мартин Фаулер «Шаблоны корпоративных приложений»

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

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

Eric Ries «The lean startup»

В русском переводе — «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»

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

Так как я не создавал собственный бизнес, мне было интересно прочесть и понять книгу как бы со стороны. Я не предприниматель и мне всегда было непонятно, почему же не все запариваются качеством продукта, начиная с первого шага? Или почему некоторые проекты закрываются, так и не успев пожить какое-то время? Этому в книге даётся логическое объяснение. Лучше плохая, но работающая идея — та, которая принесёт прибыль, с которой можно работать, улучшая её, и в конце концов сделать из неё суперкачественный продукт. А не сразу качественно сделанная идея, которая не работает и в итоге проваливается.

Jason Fried, David Heinemeier Hansson «Remote»

В русском переводе — Дэвид Хенссон «Remote: офис не обязателен»

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

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

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

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

Маленький Саблон — парк в центре Брюсселя. На заднем фоне церковь Богоматери

До переезда в Бельгию я работал в небольшом НИИ, маленькой фирме по разработке плат АЦП и небольшой компании по разработке GSM-шлюзов и «сопутствующих» товаров. Моя работа не связана с разработкой программного обеспечения, но и как инженеру-электронику мне удалось найти работу за границей по специальности. Я занимаю позицию Hardware Engineer в отделе по разработке ToF сенсоров. В мои задачи входит разработка схемных решений, выбор компонентов, постановка задачи и сопровождение трассировки печатных плат, моделирование поведения печатных плат в плане распределения токов, падения напряжения на цепях и прочее.

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

Бельгия — это страна в центре Европы с площадью 30,5 тыс. км² (чуть меньше Днепропетровской области) и населением 11.3 млн человек. До переезда я знал только, что здесь расположено много европейских институтов. Сыр и шоколад у меня больше ассоциировались со Швейцарией (CH — CHeese, CHocolate) или Голландией (голландский сыр), пиво — скорее, с Чехией или Германией. Тут я был не прав: BE = BEer.

Поиски работы

Моим продвижением в Бельгии занималась фирма Huxley. Она предложила мне работу в Softkinetic. На то время это был стартап по разработке ToF сенсоров и программного обеспечения для 3D сцен, поглощённый Sony. В связи с этим появилась возможность набиратьновых сотрудников. Моё резюме нашли на workindenmark.dk, где я разместил его после статьи на DOUоб успешном переезде одного нашего соотечественника в Данию. И хотя я не занимался научной работой, меня подкупила возможность устроиться со знанием английского без начального знания местного языка. И это сработало.

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

Собеседование

Первое интервью было вводным с моим нынешним начальником, и только после него со мной связалась HR компании. Затем мне прислали технические задачи. Некоторые вопросы в них я не решал со времён лабораторных в университете, и спустя 13 лет пришлось повторить некоторые моменты. К примеру, нужно было предоставить пример разводки печатной платы. Или рассчитать минимально допустимое количество конденсаторов в соответствии с данными потребления микросхемы (обычно у меня есть рекомендации производителя). Я постарался описать не только итоговый результат, а и ход расчёта и обосновать тот или иной выбор.

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

Река Мёз близ Динанта, вид с руин старой крепости

Оформление документов в Украине

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

Разрешение на работу пришло примерно через месяц. На форумах я прочитал, что этот процесс может занимать до трёх месяцев, но тут всё прошло гораздо быстрее. В 2016 году еще не было безвизового соглашения. Для трудоустройства в Бельгию мне нужно было получить визу типа D. Это одноразовая виза со сроком въезда до конца полученного разрешения на работу. На 8 дней со дня въезда, в течение которых нужно получить карту — вид на жительство. Несмотря на то, что в данной визе указан MULT в графе количество въездов, как меня проконсультировали в посольстве, второй раз по этой визе въехать было невозможно без бельгийской ID-карты.

В Украине для визы необходимы были:

• контракт;
• разрешение на работу;
• паспорт;
• справка о несудимости (перевод + апостиль);
• медицинский сертификат из признанной посольством больницы (~100$);
• заполненная анкета на визу (на английском);
• подтверждение оплаты за визу (SWIFT-платёж).

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

Еще совет — никогда не ходите за апостилем в конторы, которые рекламируются в центре выдачи справок. В моем случае компания, которая занималась переводом и апостилированием справки о несудимости, затянула сроки.

Текущие правила можно найти на сайте (link 1, link 2).

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

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

Атомиум — символ Брюсселя был возведен к всемирной выставке 1958 года

Оформление документов в Бельгии

В Брюсселе меня ждали арендованные компанией меблированные апартаменты. По договору компания предоставляла жильё на 1 месяц. Дальше можно оставаться жить в нём, но платить уже самому около 1700 € в месяц, что дорого.

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

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

В коммуне, в которой меня поселили, первое обращение исключительно по электронной почте. Это очень удобно, но вот на сайте нет шаблона документов, которые нужно подавать. Я подал всё, что у меня было: скан паспорта, разрешения на работу, адрес, где проживаю, фотографию. И получил первый ответ спустя месяц: «Ваши данные приняты в обработку, спасибо за обращение». За это время я посетил коммуну «пешком», но получил отказ и успокоение: «Ждите дальше, это нормальные сроки». Ещё через месяц мне пришло письмо с приглашением заполнить анкету в doc-файле и приложить файлы к письму. Всё это они получили два месяца назад, только без анкеты.

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

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

Разрешение на работу выдаётся сроком на 1 год. На его основании разрешение на проживание выдаётся на 1 год + 1 месяц. Примерно за два месяца до окончания срока действия разрешения на работу я должен поставить штамп в коммуне на заполненную анкету и отдать её работодателю. При этом в коммуне попросят купить в соседнем окошке «сертификат хорошего поведения». Работодатель отправляет все документы куда нужно. Через время приходит уведомление о том, что меня ждёт новое разрешение на работу в коммуне, не забудьте назначить rendez-vous.

Звучит страшно и сложно, но всё проходит быстро и не больно. Стоимость штампа на анкету — 5 €. Сертификат хорошего поведения — от 0 до 15 € (я не помню точно). Бланк разрешения на работу оплачивает работодатель. Изготовление ID карты — 25 € (до двух недель) и 90 € (до 5 дней). В этом году правила изменились и стоимость, должно быть, тоже.

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

Переезд супруги

Для того, чтобы моя жена Аня смогла приехать в Бельгию, мы должны были предоставить подтверждающие документы по статье 10bis. Безвизового режима ещё не было, а получение Шенгена мы не рассматривали, так как «я ж в течение 8 дней получу ID карту».

От супруги нужно:

• подтверждение личности, начиная со свидетельства о рождении;
• свидетельство о браке (перевод + апостиль);
• медицинский сертификат из признанной посольством больницы;
• справка о несудимости (перевод + апостиль);
• квитанция об оплате визового сбора (оплачено в Бельгии);
• отпечатки пальцев.

От меня нужно:

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

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

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

Первое, с чем мы столкнулись, — свидетельство о рождении супруги выдано в Казахской ССР. Апостиль на такое свидетельство невозможно поставить в Украине. Даже в посольстве Республики Казахстан. Во «Вконтакте» (тогда это ещё не было запрещено) мы нашли женщину, которая занимается оформлением документов, и за 2 месяца все сделали.

Затем в визовом центре нам сказали, что одного контракта с указанием зарплаты недостаточно, и мы должны предоставить справки о начислении зарплаты за несколько месяцев (от 3 до 9). Тогда у меня их уже было достаточно, так что проблем не возникло.

В середине февраля Аня подала документы на визу (отслеживали процесс сначала на украинском, потом на бельгийском сайте). Где-то за неделю до подписания безвизового режима в мае 2017 мы получили визу типа D. Срок въезда стоял 180 дней, такой же MULT и такое же ограничение на замену в течение 8 дней. Я заранее записал нас на приём в коммуну для оформления документов. В середине августа она получила свою карту «Titre de sejour».

Культурный центр Roge-Cloitre (Красный монастырь) в нашем районе. Под домом находилось водяное колесо и изначально тут была мельница

Аренда жилья

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

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

Для поиска квартиры можно воспользоваться такими сайтами: immoweb.be, immo.vlan.be, immoscoop.be.

Чтобы снять квартиру, нужно заключить контракт с арендодателем. Основные контракты — на три года или девять лет. Бывают исключения. Также необходимо открыть «депозит безопасности» в банке. Для квартиры без мебели это плата за два месяца. Так как желающих снять квартиру довольно много, то арендодатели могут собрать документы со всех желающих и выбрать самого благонадёжного. При этом критерии надёжности могут быть разными: кто-то ориентируется на зарплату, кто-то на бессрочный контракт, кто-то то на имя компании. Один из агентов мне сказал, что предпочитают сдавать квартиру людям с детьми, так как они выглядят более надёжно — привязаны к школе, им нужно кормить детей.

Квартиру я нашёл по объявлению на общем сайте, но размещенную агентством. Все бумаги по оформлению контракта с хозяйкой квартиры, на воду, электричество и газ за меня отправила агент, которая занималась квартирой. Её услуги оплачивала хозяйка (включены в стоимость арендной платы). Контракт на съём жилья типовой, оформлен на французском. Срок — три года с возможностью автоматического продолжения. В контракте указана пеня за выезд раньше срока. В первый год — 3 месячные арендные платы, во второй — две и в третий год — одна. Контрактом предусмотрен «депозит безопасности», оформленный на моё имя, но заблокированный на снятие хозяйкой квартиры, в сумме двух арендных плат на момент подписания договора. В случае нанесения ущерба квартире по моей вине, хозяйка по решению суда может возместить его из этого депозита. На сумму этого депозита ежегодно начисляют 0,11 % годовых.

Квартиру я нашел в 20 минутах ходьбы от работы и минут 5 от станции метро. За квартиру 52 м² с одной спальней, жилая комната объединена с кухней, душ, но без ванны я плачу 715 € + 50 € за обслуживание дома. Каждый год квартплата может быть пересчитана согласно индексу инфляции (начинали мы с 700 €). В 2018 году индекс инфляции составил 2,43%.

На поиск квартиры с момента получения ID карты у меня ушло примерно три недели. На подписание контракта — ещё неделя.

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

Так как в Брюсселе много желающих снять жильё, то и уровень цен относительно высокий. Не могу сказать, что есть единый критерий ценообразования. Кто-то задирает цену за район, кто-то — за близость к историческому центру, парку, Европарламенту или его комиссиям, НАТО, бизнес-центру, университету, станции метро или выезду на автостраде. По крайней мере такое впечатление создаётся, когда смотришь на состояние квартиры и цену аренды. Делить районы по нетолерантным признакам я бы не стал. Везде жить можно. И цена всё равно не отличается в разы.

Этажи тут считают с «0». Комнатность квартиры по спальням. Квартира-студия — это квартира с одной большой комнатой, но может быть с отдельной (закрывающейся дверью) кухней. 1-bedroom apartment — скорее, соответствует нашей двушке. Жилая комната часто соединена с кухней. Хорошо, если кухня подходит к окну. Часто она встроена в дальнем углу, и надеяться можно только на вытяжку. В старых домах кухонь не было, и их встраивают при ремонте как влезет. Иногда это кухня-ванная, где посуду моют в ванной рядом с унитазом, но это совсем исключение даже для квартир с фильтром цены до 450 € за одну спальню.

Цены в моем районе примерно такие (за жилье в нормальном состоянии, в моём понимании):

• Комната (снимать квартиру с кем-то, как в сериале «Друзья») — от 350 € в двушке.
• Квартира-студия (30-35м²) — 550 €.
• Одна спальня (наша двушка) — 650-800 €и выше.
• Две спальни — 800-1000 €.
• Дома — от 1000 € и до небес.

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

К ценам за квартиру нужно добавить обслуживание дома и что в него включено (может быть центральное отопление). Иногда это 30 €, а иногда — 300 €, но чаще 50-150 €.В высотных домах расходы делятся на всех участников и могут быть меньше, а в домах на 3-4квартиры — выше.
Парковочное место или гараж рядом с домом арендуется отдельно.

Наличие камина влечет ежегодную обязательную проверку дымохода. Сервисное обслуживание и проверка двухконтурного газового котла обошлась нам в 120 € и по контракту должна выполняться ежегодно. Если дома отапливаются мазутом (соляркой), то там нужно периодически проверять баки для мазута. Цен на эти услуги я не знаю. Привозит его бензовоз. И в старых домах иногда встречаются заливные горловины с крышкой внизу возле тротуара.

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

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

Типичное объявление о сдаче квартиры

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

О покупке своего жилья мне пока говорить рано. С точки зрения бельгийского закона я могу купить жильё, но первоначальный взнос в 30% (50к €) при минимальной цене за студию в 150 000 € мне ещё не доступен. Процентные ставки сейчас около 3,5% (в рекламной брошюре). Если жильё продать раньше, чем через 10 лет, то нужно платить высокий налог.

Коммунальные платежи

В целом за прошлый год мы заплатили 10 120 € за квартиру. Без учёта интернета и телефона.

Газ + электричество

Стоимость — 70 € в месяц, но раз в год делают пересчет по реальным показаниям, и так нам вернули около 180 €. Мы можем выбирать поставщика услуг по своему усмотрению, но по состоянию на прошлый год я не нашёл разницы между ними: engie.be, lampiris.be, luminus.be.

Вода

Стоит около 150 € в год. У нас счётчик, но тариф зависитот количества потреблённой воды в пересчёте на жильца в год. Так что выгодно регистрировать всех, больше путешествовать и ездить в командировки.

Страховка за квартиру ещё ~180 € в год. Цена варьируется от размеров квартиры, этажности, ветхости, района (спокойный, подтопляемый, сейсмоактивный и т. д.).

Мусор

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

Так как в Украине я жил в частном секторе и мы с соседями нанимали мусоровоз за свой счёт, то с сортировкой мусора проблем не было — бумага отдельно, пластиковые бутылки в сетку, пакеты отдельно, компост и бак загружается не так быстро.

Здесь вывоз мусора осуществляется путем сортировкипо пакетам разного цвета:

• Белый пакет — для общего мусора после сортировки.
• Синий — для пластика, тетрапака и алюминиевых банок.
• Жёлтый — для бумаги и картона.
• Зелёный — для газонной травы и растений.
• Оранжевый — для компоста (остатки еды без яичной скорлупы, костей и жиров).
• Чёрный — пакет для несортированного мусора, но он стоит дороже.
• Розовый — не знаю, но по моим наблюдениям это для частного бизнеса, возможно, для кафе и ресторанов.

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

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

Строительный мусор сбрасывают в специальные баки, которые заказывают в аренду. При этом получают (покупают) разрешение из коммуны/полиции на его установку.

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

Телефон, интернет и ТВ

Мобильный

Мобильная связь может быть контрактной или предоплаченной. У меня контракт за 15 € в месяц от «Оранж». За эти деньги предлагается 2 часа 30 минут на всех операторов, 1,5 ГБ интернета, неограниченное количество SMS и разговоров внутри семьи. У меня только супруга, и мы столько не разговариваем. С учётом Wi-Fi дома, на работе и в метро — мне хватает. Роуминг внутри ЕС бесплатный. В Швейцарии 2,4 €/ мин исходящего, 1 €/мин входящего, 6 €/МБ. Так что дешевле Швейцарию проехать в режиме полёта. В Японии стоимость роуминга такая же.

Домашний интернет и ТВ

Интернет и ТВ у меня подключены одним коаксиальным кабелем Docsis 3.0. Есть операторы VDSL, бывает подключение по оптике или 3G/4G модем в квартире. Минимальный тариф на интернет — 27 € в месяц, 75/4 Мбит/с и 200 Go. Средний тариф на интернет + ТВ — 57 € в месяц TV + NET 125/6.5 Mbps — безлимитный объём. Есть возможность настроить Wi-Fi подключение из любой точки, где у оператора есть устройства. Дополнительные пакеты телевидения стоят конских денег, но наверняка на них есть покупатели. Мой вариант — voo.be — я выбирал из того, что было в наличии на моей улице в момент переезда.

Другие операторы: 2.telenet.be, proximus.be, orange, scarlet.be, base.be. Как для маленькой страны, тут очень много виртуальных операторов, но, как и в наших тарифах, нужно много читать мелким шрифтом.

Транспорт

Метро-трамвай-автобус

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

Стоимость поездки — от 1,4 до 2,5 €. Проездной на месяц стоит 49 €, на год — 499 €. Мне компания возмещает стоимость проездного.

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

Брюссель обслуживает stib-mivb.be, Фламандский регион — delijn.be, Валлонию — infotec.be. В немецкоговорящие районы заезжают автобусы немецкой компании и соединяют маршрутами с Германией. Во Францию я ходил пешком и не знаю, как организовано автобусное сообщение на границе с Францией.

Музей трамваев в Брюсселе, в Льеже, в Антверпене.

Поезда

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

На выходные и праздники есть билет выходного дня за полцены. Можно купить 10 билетов за 77 €, куда нужно вписывать дату поездки. Иногда это дешевле, чем ехать по билету выходного дня. Для каждодневного катания дом-работа есть проездной. У нас проезд в поезде 2 класса компенсируется работодателем. Полезные сайты: belgiantrain.be, izy.com, thalys.com. Музей поездов в Брюсселе, в Валлонии.

Автомобиль

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

На рынке б/у авто дешёвых хороших машин нет. Компактные авто довольно популярны, и цены на них иногда держат выше, чем на авто классом выше. Постепенный запрет на использование дизельных и неэкологичных машин создал ценовую «пропасть» между автомобилями с разными нормами. И если ещё летом был разрыв между евро-3 и евро-4, то сейчас уже между нормами евро-4 и евро-5. Хотя до их запрета ещё относительно далеко.

Газовые авто менее распространены. Возможная причина — на большинство подземных парковок им въезд запрещён.

При покупке автомобиля через автосалон б/у машин вам будут впаривать всё, что угодно. И цену загнут как за «не бит, не крашен» тех же годов. Автосалоны должны давать гарантию, но могут сделать и «скидку». Из того, что я смотрел, — на 15 летний металлолом дают гарантию от двух недель до двух месяцев максимум, на машины во ещё вменяемом состоянии до двух лет ограниченной гарантии (8 лет 100 тыс. км пробег). У меня сложилось впечатление, что предпродажную подготовку тут делают только продавцы люксовых авто. Остальные как купили, так и продают.

У частных продавцов встречаются объявления «отдам даром», но со вставшей коробкой или стукнутым двигателем. Из особенностей рынка — скручивание пробега в Бельгии уголовно наказуемо, поэтому много авто с пробегом под 200+ тыс. км и относительно вменяемым салоном по сравнению с нашими 80+ тыс. км, но лично я не проверял реальность пробега. Сайты где можно посмотреть б/у авто: 2dehands.be — общая барахолка, не только про авто, gocar.be, autoscout24.be — автомобили, мотоциклы и запчасти.

У многих компаний есть фишка «company car». Это местная система, при которой компания берёт в лизинг автомобиль для работника. При этом после первоначального взноса компании возвращаются все деньги в виде налоговых льгот. И этой фишкой компании пользуются как дополнительным бонусом для работника. У каждой компании своя планка предоставляемого авто. К примеру, у нас нельзя взять SUV, кабриолет или минивен, но с нынешними классификациями авто можно найти что-то по душе. Выбор ограничен Volvo, Audi, Volkswagen, BMW, Renault, Peugeot, Citroen, Nissan и только дизельные авто. Есть потолок по годовому обслуживанию. На других фирмах могут быть доступны другие марки и авто классом выше, электро и газ. Месячные взносы платит работник сам. При этом стоимость лизинга также частично можно вычесть из налогов. И работников с высокой зарплатой это мотивирует к покупке более дорогих авто.

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

Водительское удостоверение и автошкола

Отучиться в автошколе дешевле в Украине. Тут это удовольствие стоит под 1000 €. Можно дешевле. Теоретические занятия — минимум 12 часов (около 100 € за курс), но по факту ни одна из посещённых мною школ не предлагает теорию. Теорию можно выучить по книге, подготовиться к экзамену на сайте. Если два раза не сдашь теорию, получишь направление на теорию в школе.

На теоретическом экзамене 50 вопросов. Нужно набрать минимум 41 балл. При этом есть вопросы на минус 5 баллов. Сдать с первого раза вполне реально. По идее с 2018 года можно сдавать экзамен на шести языках — французский, нидерландский, немецкий, английский, испанский и польский. В экзаменационных центрах должны быть подготовлены тесты на нужном языке, но по факту тест сдаётся в группе с переводчиком.

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

Цена экзамена 51 €, переводчик — 15 € с человека. Бланк временного удостоверения — ещё 25 €.

Электрический Twizy на службе полиции

Практика может быть минимум 6 часов, после чего можно водить машину в присутствии водителя со стажем не менее 8 лет (он будет записан в права). При 20 часовом курсе машину можно водить без сдачи экзамена. Достаточно подписи экзаменатора, чтобы получить временное удостоверение и готовиться самому к экзамену на дорогах общего пользования с буквой «L». Временное удостоверение выдается на 18 или 36 (после шестичасового курса) месяцев. Экзамен можно сдавать не ранее, чем через 3 месяца. С временным удостоверением нельзя пить за рулём, ездить ночью в выходные (пт, сб, вс) и праздничные ночи с 22 до 6 утра. Можно выезжать на автостраду, но нельзя выезжать из Бельгии.

В этом году ввели изменения в правила и добавили экзамен по оказанию первой помощи и дополнительный тест на внимательность к потенциальной опасности (велосипед, ребёнок, работы на дороге). Мне это ещё предстоит, так что подробностей не знаю.

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

Бензин стоит 95 около 1,3-1,4 €/л (в Брюсселе). Цена дизеля подбирается к отметке 1,5 €/л. На сайтах компаний иногда видны рекомендованные цены — carbu.com, total.be, lukoil.be, но в реальности они сильно зависят от расположения заправки.

Замена масла + фильтр + работа стоит 120 — 130 € в Брюсселе. Страховка считается индивидуально. У нас страховка от друга ~ 250 € в год. Он записан как основной водитель со стажем 10 + лет, моя супруга (стажем менее 2 лет) и я с временными правами. Если бы я купил автомобиль и записал себя как основного водителя, то страховка мне бы обошлась более 1000 € в год (не проверял).

Для поездок на работу и в популярные туристические места автомобиль не нужен. Достаточно поезда и велосипеда. Но на некоторые места, интересные для посещения, добраться автомобилем можно за час-полтора, а на поезде 3+ часов из-за неудобных стыковок. Парковки в городе есть платные (indigo, beparkи др.), а есть бесплатные в синей зонес максимальным ограничением по времени — 2 часа. Обычное ограничение длительности парковки — с понедельника по субботу с 9 до 18 часов. В своём районе можно получить парковочную карту за 25 € в год и парковать автомобиль без ограничения даже в синей зоне. Закрывающийся бокс или гараж в нашем районе стоит 120 € в месяц, но объявление в нашем доме висит с декабря. Когда мы только переехали, цена по району была 80-90 €. Car sharing: Cambio, DriveNow, Ubeeqo.

Велосипед

Велосипеды тут более распространены, чем два года назад в Днепре. Хотя сейчас модны разные скутеры. За последний год появилось несколько сервисов шеринга электроскутеров-самокатов как в виде табуретки на колёсах (мотороллер), так и для поездки стоя. Их бросают как попало поперёк тротуара в узких проходах и пр.

На улице встречаются техпосты с ключами, кронштейном и насосом, где можно вывесить велосипед и починить его или просто накачать колесо. Правда, некоторые уже разграблены. Складной велосипед можно перевезти на поезде бесплатно, для обычного это стоит 5 € в одну сторону или 8 € в две стороны. Система villo.beпозволяет взять электровелосипед в одной точке Брюсселя и оставить в другой, ещё одна система blue-bike.be. В других городах могут быть свои сервисы.

Для велосипедистов разработаны маршруты разной сложности/протяжённости как во Фландрии, так и в Валлонии. По моим ощущениям, во Фландрии меньше перепады высот. Граничных пунктов с Голландией и Германией мы не видели, но при пересечении границы с Голландией велодорожка сразу становится двухрядной. Мои коллеги-велолюбители иногда с завистью смотрят в сторону соседнего королевства: там не встретится 4 км велодорожек на весь город с бигбордом посередине и припаркованными авто, как в Днепре.

К примеру, маршруты по провинции Лимбург — fietsparadijslimburg.beочень интересны. Я один раз выбрал 50 км маршрут, включающий бывшую шахту, парк солнечных часов, парк планет Солнечной системы, лесные маршруты и дорогу сквозь озеро. Он лёгкий в плане подъёмов спусков, но все достопримечательности подробно не рассмотреть за один день. Для Валлонии можно заглянуть на walloniabelgiumtourism.co.uk, но в Валлонии мы ездили «дикарями» куда глаза глядят.

Повсюду в музеях предлагают бесплатный перечень достопримечательностей с веломаршрутами — 365.be.

На работе у нас действует компенсация за приезд на велосипеде. Около 0,25 €/км в день приезда — это немного, но за два года можно накатать на ремонт или новый велосипед. Я этим не пользуюсь, так как у меня всего 1,5 км пешком или 2 км на велосипеде. При этом корпоративный транспорт и проездной никто не отбирает.

Еда

На еду уходит примерно 400 € в месяц, но я не очень притязательный и не чувствую вкусовой разницы между биокартошкой за 4 € за 0,5 кг и той, которая за 0,60 €/кг. И в биопакете попадается чёрная внутри картошка. Яйца тоже есть фасованы по 4 штуки и ценой 2,5 €, а есть 1,5 € за 12 штук. Это получается даже дешевле, чем 4,5 € за 30 шт. Очень часто в магазине рядом с ценой за упаковку пишется цена за кг или литр. Это очень удобно для расчёта экономической выгодности — не всегда большая упаковка выгоднее маленьких.

Хлеб есть разный по весу, составу и прочему. В магазине часто есть своя пекарня, и хлеб выпекают на месте. Цена хлеба может быть от 0,99 €/400 г — социальный, дальше идёт вес хлеба 600, 800, 1000 и 1200 г с типичной ценой 1,49 €/400 г, 1,99 €/600 г и 2,49 €/800 г. Из минусов — в некоторых местах хлеб бывает не пропёкшийся или отдаёт запахом дрожжей.

На сайтах основных сетей можно узнать о промоакциях, заказать карту клиента или чтобы продукты из вашего списка собрали в магазине к вашему приходу: carrefour.eu, lidl.be, fr.aldi.be, delhaize.be.

Летний фестиваль Оммеганг в честь короля Карла 5

Достопримечательности и путешествия

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

У некоторых городов есть официальный сайт, совпадающий с именем города и приставкой «visit» visit.brussels, visitezliege.beи другие.
В Брюсселе очень много парков и озёр. Рядом с городом находится Суаньский лес, к нему можно добраться на трамвае и автобусе в нескольких местах. О цветении гиацинтов весной в Хальском лесурассказывали на украинском телевидении.

В качестве других интересных мест можно посетить целые города, такие как Брюгге или Гент, с очень красочной исторической частью. Динант — родина Адольфа Сакса — изобретателя музыкальных инструментов. В Бельгии есть невысокие горы, где расположены кемпинги и базы отдыха. Есть местные золотые озёра, но мы там ещё не были. По берегу Северного моря ездит Береговой трамвайномер «0» от нидерландской до французской границы.

В соседние страны можно слетать на самолёте или съездить на автобусе. Брюссель — Париж на автобусе туда-обратно мы купили за 60 € за двоих, при заказе примерно за месяц. Если опоздаешь на обратный автобус, то за 99 € с человека можно быстро вернуться домой ближайшим Thalys. Автобусные фирмы которыми мы пользовались тут: global.flixbus.com, eurolines.eu. У Flixbus сейчас более современные автобусы.

Летом мы стараемся пару раз в месяц куда-нибудь поехать (например, посмотреть архитектуру). По Бельгии — это просто сел в поезд, посмотрел небольшой город и вернулся домой на последнем поезде. Заграничные поездки приходится планировать заранее.

В Украину летать можно напрямую в Киев МАУи Брюссельскими авиалиниями. В Днепр — через Киев или Вену, в Запорожье летает LOT.

Динант. На вершине горы Цитадель. Из Брюсселя сюда добраться можно на поезде

Зарплата и налоги

В Бельгии две 13-езарплаты. Одна летом, другая под Рождество. Так что сумма, озвученная HR за месяц, в годовом итоге не х12, а х13,92, но нужно быть готовым к тому, что в первый год работы у вас не будет оплачиваемого отпуска. Я устроился в сентябре 2016, и в 2017 мне положено было всего дополнительных 4 дня отпуска от компании, но это можно пережить за свой счёт.

Здесь есть целое искусство уменьшения налогов. Автомобиль компании, кредит на жильё, вклады в пенсионный фонд, акции, неработающий супруг, дети, пожилые родители и прочее.

По закону все работающие обязаны подавать налоговую декларацию. Сделать это можно либо в коммуне, либо заполнить декларацию на сайте. Для этого нужно использовать ID-картуи картридер. Можно через SMS, но нужно всё равно зарегистрировать номер в коммуне.

Налоговая декларация подаётся до конца июня. Примерно в октябре-ноябре приходит результат пересчёта. И если пересчитали в вашу сторону, то деньги на счёт поступят где-то в январе. У меня это примерно половина месячного оклада на руки. Люди на менеджерских позициях заполняют две декларации. Что они там пишут, я не в курсе. Более подробно можно узнать: eservices.minfin.fgov.be, financien.belgium.be.

Музей текстиля в Кортрике. Доллары США печатают на хлопчато-льняной бумаге (75/25) которая не размокает. Весь лён для печатания купюр выращивается в Бельгии

Пенсия

Чтобы получать полную пенсию в Бельгии, необходимо 45 лет стажа для людей моего возраста и 35 лет тем, кто успеет выйти на пенсию до 2025 года когда для мужчин возраст поднимут до 66 лет, а в 2030 году — до 67. Помимо обязательных отчислений, могут быть добровольные отчисления от работодателя и работника. Я имею право откладывать на добровольный персональный пенсионный счёт не более 940 € в год. При этом эти деньги возвращаются из налогов, но потом в конце рабочего срока на собранные проценты (или всю сумму) снимут 50% в виде налогов. Это будет ещё не скоро, и правила могут изменить.

Медицинское страхование

Медицинская страховкасейчас привязана к национальной электронной ID карте — её считывают в больнице/поликлинике и на дом высылают счёт. Частный доктор может сразу взять деньгами, и его чек нужно отправлять в страховую компанию для возмещения расходов. В аптеке считывают штрих-код с рецепта и выдают лекарства сразу со скидкой. Стоимость страховки в год — около 120 € на человека. Для неработающего супруга первый уровень страхования бесплатный.

Парад во время дня независимости Бельгии 21 июля

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

Бельгийская система здравоохранения считается одной из лучших в мире. Я обращался только в новую больницу, которую построили в нашем районе, и она оснащена «ну очень круто». Обратился к ЛОРу с сильным кашлем и болью в горле. Так он мне тут же засунул камеру в горло и снял кино: что творится у меня внутри. Кино показал, сказал не смертельно и дал рекомендации.

Стоматология у нас в Украине не хуже. Просто тут лечение покрывается дополнительной страховкой, протезирование нужно предварительно согласовывать, чтобы не выйти за лимит. Приём с консультацией стоит 25 € (около 18 € вернула страховая). Пломбирование — около 75 € (как и у нас, зависит от потраченного материала). Восстановление зуба мне обошлось примерно в 400 €, из которых около 380 € вернули по страховке.

Скорая помощь в Бельгии вызывается через службу 112. По умолчанию приедет только санитарная машина. Обычно это микроавтобус типа спринтера. В нём два санитара, которые не имеют права оказывать помощь, кроме как перенести больного в машину/в дом. Нужно чётко назвать причину вызова, сможет ли больной дойти до машины. Если это остановка дыхания или кровотечение, то на вызов дополнительно на всех парах выедет MUG — Mobiele Urgentiegroep. В ней будет дефибриллятор, бинт и сертифицированный для оказания помощи медперсонал.

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

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

Люди

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

Полиция на параде была представлена всевозможными вариантами

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

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

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

В целом люди везде люди. Они тоже едут работать за границу и точно так же, как и мы, собирают долгий пакет документов (если это не ЕС). Им тут тоже нужна виза, например в Китай.

Они жалуются на плохие дороги, на долгое оформление документов и при любом удобном случае можно услышать: «Это ж Бельгия». Им бы на трассу Днепр-Одесса.

Языки

Страну, так же как и нашу, пытаются делить по языковому признаку ещё с момента создания в 1830 году. Это меня немного пугает. В Брюсселе (19 коммун) двуязычие, но реально только 3% считают первым из официальных нидерландский, а остальные — французский. Во Фландрии говорят по голландски, но со своим акцентом. В Валлонии — французский, тоже с мелкими отличиями от академического. На востоке страны в приграничных районах официальный язык немецкий.

Самое первое отличие бельгийского французского, которое я узнал, это произношение числа 90. Во французском это «четыре по-двадцать и десять» в бельгийском «девятьдесят» (если перевести по аналогии с нашими 60, 70, 80). Больше отличий можно узнать из языковых курсов.

Для зарегистрированных жителей языковые курсыот нашей коммуны стоят 80 € за полугодовой интенсивный курс (4 дня в неделю по 3 часа). Если заплатить за год вперёд, то это будет 110 €. В других школах цены могут отличаться. Курсы от университетапредлагают не только местные языки. В конце курса экзамен, после чего выдают сертификат соответствующего уровня и справку для работодателя, по которой можно получить дополнительный выходной.

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

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

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

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

У нас на работе рабочий язык — английский и Python, но разговаривать на своём языке не запрещено.

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

Выводы

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

В личном плане есть много неопределённостей. Непонятно с планами на жильё, работой для супруги. Я так и не выучил ни один из местных языков за 2,5 года, хотя хорошо подтянул разговорный английский.

С точки зрения климата, то он отличается от Днепровского — здесь больше дождей, но меньше перепады температур, как суточные, так и годовые, но год на год не приходится. Одно лето было холодным, и мы почти всё лето проходили в куртках, а в прошлом году было очень жарко. Зима мягкая, и в Брюсселе почти бесснежная в этом году. В этом плане жить тут вполне комфортно, и пусть вас не пугают 200 дождливых дней в году. Если в этот день было солнце и 20 минут дождя — это считают дождливым днем.

Ещё полгода назад я бы сильно призадумался, а переехал бы я, если бы знал, сколько всего меня ждёт на этом пути. Была сильная усталость от ожидания документов, переезда, от новых правил, привыкания к местным продуктам. Сегодня я бы снова сказал: «Да». Даже в Бельгию.

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

P. S.В статье представлено исключительно моё мнение. Оно не отражает мнение моего работодателя и не является официальным заявлением от имени компании. Также оно может не совпадать с мнением читателей, редакции, социальных опросов и поисковых гигантов.

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

Володимир Агафонкін, Software Engineer в Mapbox

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

Особливо мені пощастило з індустрією, в якій я працюю. Уже 11-йрік я займаюсь інтерактивними картами та візуалізацією даних. Це сфера з нескінченною кількістю цікавих, ще не вирішених задач, великим простором для створення чогось нового. І особливо захоплює, що в ній безпосередньо бачиш результат своєї праці і те, як ним користуються мільйони людей у повсякденному житті. Також маю привілей присвячувати більшість свого робочого часу open-source-проектам, від чого є сильне відчуття приналежності до світової спільноти і праці над речами, які того по-справжньому варті.

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

Руслан Шевченко, Research Development Consultant в Garuda.АІ

Найбільше у роботі мені подобається:

• Те відчуття, коли після роздумів над якоюсь проблемою «все складається». Мабуть, тому я й занявся у свій час математикою та програмуванням.
• Бачити, як те, що раніше було неможливим, стає реальністю.
• Бачити, як люди починають щось розуміти.

Володимир Рожков, Software Architect/Engineer/Manager в Devlify

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

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

Никита Галкин, System Architect, Independent contractor

Я люблю программировать, потому что это не работа, а игра. Я учился программировать в школе на примере управления роботом черепашкой (вариант языка Лого). Поменялись языки, но осталось удовольствие, когда алгоритм делает то, что нужно — черепашка выходит из лабиринта. Я работаю с JavaScript/TypeScript, поэтому моя черепашка часто учит новые трюки, от чего мой внутренний ребенок просто захлебывается слюнями.

Дмитро Скороход, iOS Developer в Perfectial

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

Суспільство нав‘язує культ грошей, але часто статки — це просто безглуздий фетиш. На вашій могилі не напишуть: «Він заробляв 5k». Щоб відбутись в житті та бути щасливим, треба знайти улюблену справу. Для мене це програмування.

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

Владимир Симоненко, Front-end Developer в PyTeam

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

Юлія Шалева, Salesforce developer в CoreValue

За що тільки я не люблю свою роботу! Для мене писати код — це як складати конструктор. Люблю розділяти складні задачі на окремі частинки, кожна з яких максимально проста і зрозуміла — а якщо їх скласти, твій код починає «працювати» :)

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

У мене є можливість працювати і спілкуватися з людьми з усього світу. Я не прив’язана до офісу, можна водночас подорожувати.

Всеволод Дьомкін, Lisp developer в Franz Inc.

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

Олексій Марховський, Senior Software Developer в HERE Technologies

Раніше було враження, що технології — прогнозований набір інструментів. Зараз, із підключенням бюджетів окремих компаній, чисто технологічні рішення потерпають від зайвого піару, стрімко розростаються, трапляється, ламають сумісність власного API. Іноді вузькість планування самих користувачів призводить до таких бізнесово-технічних негараздів, як vendor lock-in. Але не дивлячись на той-таки хайп, програмування дає можливість зосередитись на формальних сторонах проблеми, не витрачати більшу частину енергії на такі речі, як бізнесове маневрування, конкуренція, пошук клієнтів, продажі та увесь цей стрес.

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

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

Що я найбільше люблю у роботі? Можливість працювати з адекватними, розумними людьми. Вирішувати завдання у власному темпі, мати розкіш зупинитися, проаналізувати проблему, вирішити, що краще — розв’язувати задачу «в лоб» чи виокремити час на підготовчий рефакторинг.

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

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

Володимир Кубицький, Head of AI в ЛУН

Свобода.

Андрей Литвинов, Senior Software Engineer, Independent contractor

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

Вадим Копанев, .NET Architect в Infopulse

Жизнь построена так, что все повторяется циклически: мы каждый день ходим на работу, проводим ритуальный митинг, проверяем почту и т. д. Если разбирать в деталях каждое действие, то и там найдется шаблон повторений, который практически не меняется со временем. Зачем же делать одно и тоже каждый раз? :) Возможно, кому-то нравится монотонное повторение знакомых действий, но не всем. Обычно все, что связано с использованием компьютера, можно автоматизировать и самому заниматься только тем, что нравится, оставив рутинные действия машине. Технологии и программирование — ключ к этому.

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

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

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

Сергей Сыроватченко, Senior SQL Server DBA в EPAM Systems

Если бы на этот вопрос меня попросили ответить лет так 5 назад, то я бы, с предсказуемостью Капитана Очевидности, сказал, как люблю писать код. Но, по правде, это все хрень, ибо самое интересное в работе — явно не рутинные задачи. Самое классное — это решать проблемы с перфомансом. Базы данных для этого как раз подходят идеально.

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

Для меня работа — это постоянное движение и поиск новых способов сделать что-то лучше.

Роман Гелембюк, Lead Software Developer в Storage Made Easy

Я люблю свою роботу, тому що я на роботі програмую. Я завжди любив програмувати. Вперше спробував у 4-мукласі кодити на бейсіку. І з того часу це моє улюблене заняття і хобі. Крім того, ця чудова робота має інші «бенефіти». Є відчуття свободи і незалежності. Якщо є потреба чи бажання, то можна виїхати в іншу країну практично в будь-який момент. Так само можна повернутися. І це не тягне за собою якихось великих змін в стилі життя сім’ї. Ще одна чудова річ — відчуття причетності до інновацій, перебування в авангарді на шляху до майбутнього.

В рубрике DOU Проекторвсе желающие могут презентовать свой продукт (как стартап, так и ламповый pet-проект). Если вам есть о чем рассказать — приглашаем поучаствовать. Если нет — возможно, серия вдохновит на создание собственного made in Ukraine продукта. Вопросы и заявки на участие присылайте на editors@dou.ua.

Привет! Меня зовут Ковтун Сергей, я студент 4-гокурса ОНАПТ и PR-manager MiRONAFT — научно-исследовательской лаборатории мехатроники и робототехники. Это крупнейшая инновационная FabLab лаборатория Украины и Европы, расположенная на базе Одесской национальной академии пищевых технологий (вторая по размеру лаборатория находится в Молдове на базе университета TUM).

Статья создана в соавторстве с Виктором Егоровым.

Идея

Инициатор и создатель открытого co-work пространства — к.т.н. Виктор Егоров, преподаватель кафедры автоматизации технологических процессов и робототехнических систем ОНАПТ, нынешний научный руководитель лаборатории.

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

MiRONAFT и стала местом, где каждый желающий горожанин вне зависимости от возраста, навыков, места учебы либо работы, при должной консультации со стороны сотрудников, сможет реализовать свою идею совершенно бесплатно. Каждому предоставляется рабочее место для разработки, сборки, тестирования прототипа, а также ручной инструмент, софт, специализированная литература и консультация со стороны сотрудников и резидентов co-work’a.

Существует одно условие — 20% проведённого времени в лаборатории добровольно посвятить помощи в организации и проведении мероприятий в лаборатории: фестивалей, выставок, мастер-классов, тренингов, субботников и т. д. Мероприятий мы организовываем и проводим огромное множество, так что помогать всегда есть с чем.

Среди основных активностей лаборатории — кружки робототехники для школьников, мастер-классы по основам современной робототехники (пневматика, гидравлика, электрические манипуляторы, программирование контроллеров, ЧПУ станки). Мы являемся организаторами ежегодного общегородского фестиваля робототехники «Robotronica», который каждый год посещают более 7 тыс. одесситов.

Кроме того, на базе нашей лаборатории проходит Всеукраинская олимпиада по мобильной робототехнике «RoboRace Odessa Grand Prix». Это, по сути, полноценный международный турнир/гонки среди машин с искусственным интеллектом. На огромной многоуровневой трассе машины инженеров со всей Украины и ближнего зарубежья состязаются в скорости, будучи абсолютно автономными. Причем соревнования проходят по всем правилам полноценных гонок: со своими квалификационными заездами, полуфиналами, финалом и штрафными кругами при нарушениях.

Помимо организации своих больших мероприятий мы также часто выступаем площадкой для других. Так, на базе нашей лаборатории проходили общегородские фестивали STEM образования, Odessa Mini Maker Faire и многое-многое другое.

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

Реализация

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

В Украине рассчитывать на поддержку государства не приходится. Лаборатория развивалась и развивается прежде всего благодаря компаниям-друзьям: Camozzi, Festo, Phoenix Contact и др., которые предоставляют наиболее современные виды оборудования для обучения и модернизации. Кроме компаний-партнеров, которые в нас заинтересованы профессионально, нам также помогает огромное количество наших друзей бизнес-ангелов, среди которых наиболее активные: Дмитрий Милютин (Parfum Galerie Moluar), Петр Обухов (Такси Бонд), Александр Плеве (компания SocTrade), Илья Босый (компания Biakom) и многие другие, за что мы им безмерно благодарны.

В декабре 2017 года лаборатория обрела статус «FabLab» и стала на тот момент единственной в Украине FabLab лабораторией, расположенной на базе УВО (учреждение высшего образования, бывш. вуз). FabLab (англ. fabrication laboratory) — это всемирная сеть открытых инновационных мастерских, которые предоставляют бесплатный доступ к своему пространству и всему, что расположено в нём. В их распоряжении есть всё необходимое оборудование и инструменты для создания всего из ничего.

Сейчас в этой сети более 1500 лабораторий по всему миру. При этом заметно наличие корреляции между уровнем развития экономики страны с количеством таких лабораторийя: Италия — 134, США — 173, Франция — 157. Тем отраднее, что в Украине за последние несколько лет количество FabLab лабораторий удвоилось и стало равным 8 (3 в Киеве, 3 в Одессе, 1 в Харькове и 1 в Сумах). Кроме того, на подходе еще как минимум 5 лабораторий: Львов, Харьков, Северодонецк и две в Киеве. Это, конечно, не может не радовать и вселяет надежду перестать рассматривать Украину не как сырьевой придаток, а как европейский современный центр инноваций, технологий и робототехники.

Сейчас лаборатория насчитывает более 350-тирезидентов, включая 30 сотрудников. Большая часть резидентов — это студенты разных одесских вузов. Еще примерно одну треть посетителей составляют дети и взрослые.

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

Разработка роботизированного манекена

Из наиболее успешных разработок хочу отметить RAIM (Robotics Artificial Intelligence Mind) — роботизированный манекен.

Работа над проектом началась в 2017 году по заказу одного из крупнейших аутлет-магазинов одежды Одессы. Со стороны заказчика был предоставлен манекен женского пола черного цвета. От нас же требовалось сделать так, чтобы обыкновенный манекен превратился в настоящего человекоподобного робота. Согласно ТЗ, робот должен был иметь не менее 6 степеней свободы. Проанализировав существующие на тот момент модели подобных изобретений, решили сделать по одной степени свободы в плечах и локтях, в голове расположили 2 степени. Все суставы для робота являются уникальной разработкой лаборатории. После реализации механической части, была написана программа, задающая последовательность движения конечностей манекена. Затем были испытания.

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

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

Из других интересных проектов, которые разрабатываются в лаборатории есть SA1 — Smart Assistant — робот домашнего присутствия с искусственным интеллектом, позволяющим распознавать голосовые команды и вести диалог, распознавать собеседников и оказывать информационную поддержку. Также есть беспилотники самолетного типа, мультироторные системы вертикального взлета, системы автоматического управления промышленной робототехникой и многие другие.

Оборудование

Лаборатория MiRONAFT FabLab располагает парком 3D-принтеров состоящим из 13 машин (FDM декартовые, FDM дельты, фотополимерные). Кроме того в строю 4- и 3-осевыеЧПУ фрезера, а также 2 ЧПУ лазера разной мощности и размера рабочей площади. Вакуумный формовщик, токарный станок, зона электроники и пайки, оборудование тестирования, программное обеспечение, ручной инструмент и многое другое. Во время реализации одного из проектов также удалось закупить первых в Украине уникальные промышленные коботы (коллаборативные роботы) компании «Universal Robots».

Одно из основных преимуществ статуса FabLab — доступное программное обеспечение компаний, которые сотрудничают со всемирной сетью «FabLab». Компании Autodesk и Solidworks предоставляют грант в качестве корпоративных лицензий. В программный комплекс входят продукты AutoCAD, Inventor, SolidWorks, Fusion 360 и др.

Развивая идею открытой лаборатории, мы приняли участие в конкурсе проектов «Социально активный гражданин». Это муниципальная онлайн-платформа, которая включает в себя 5 направлений по взаимодействию власти с территориальной громадой и участию одесситов в управлении городом. Выбрав направление «общественный бюджет», мы подали проект «MiRONAFT FabLab — лаборатория для каждого».

В начале 2018-гогода, исходя из результатов голосований одесситов, MiRONAFT стала проектом-победителем и заняла второе место в рейтинге среди 118 претендентов. Вся смета проекта (а это 4,3 млн грн) сводится к приобретению большего количества инструментов, оборудования и станков для развития пространства. На данный момент мы находимся в активной фазе реализации проекта, а именно ведется закупка оборудования через систему «Prozorro». Покупаем все необходимое для противопожарной сигнализации и комплекты ручного инструмента.

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

Есть также CNC-лазерная/фрезерная — помещения для лазерной/фрезерной обработки материалов либо объектов. Столярная — для обработки изделий из дерева или на его основе.

Помещение портативной робототехники обустроено 3D-площадкой (платформа периферийных устройств, преобразующих цифровые 3D модели в физические объекты) и зоной полиграфии по изготовлению печатной продукции. Также в аудитории расположена трасса для тестирования машинок, которые перемещаются с помощью искусственного интеллекта, без вмешательства человека.

Компьютерный класс — оборудован современными мощными машинами, которые были закуплены в рамках проекта «Городской бюджет 2018». Есть также серверная, зона отдыха и кабинет научного руководителя.

Планы

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

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

Приглашаем всех в гости, чтобы попробовать всё своими руками!

Ви вже чули про новий підхід JAMstack? Нарешті з’явилася можливість створювати веб-додатки на улюбленому React, мати зручну адмінпанель для керування контентом, а на виході отримувати повністю валідні HTML-сторінки, побудовані згідно з останніми рекомендаціями SEO, PWA та a11y.

Цікаво? Тоді ось список тем, розглянутих у статті:

• Що це за новий стек і навіщо він потрібен?
• Як запустити перший проект на Gatsby?
• Contentful для керування даними.
• Як зв’язати Contentful з Gatsby, використовуючи GraphQL?
• Налаштування автоматичного деплойменту з Netlify.

JAMstack

Як відомо: «Все нове, то давно забуте старе», і ось ще одне підтвердження ― статичні сайти повертаються. Що таке web десять років тому? Це був PHP сервер-рендер, який при кожному запиті з клієнта підставляв дані з БД у HTML-шаблони і віддавав сторінку.

На зміну цьому підходу прийшли JavaScript-фреймворки, які в останні роки представлені святою трійцею вебу React, Angular, Vue, амінь. У чому була кардинальна відмінність? У швидкості і чутливості інтерфейсу, адже тепер вся логіка сайту перебудовується на клієнті. І на будь-який рух мишею можна викликати красиву анімацію з одночасною зміною контенту та відправкою запитів на сервер.

Що далі? JAM пропонує:

• ніякого server-side рендерингу, та й взагалі прибрати сервер;
• ніякого client-side рендерингу, ніякого більше <div id ="root"></ div>;
• компілювати сайт у звичайний HTML код один раз, лише в момент зміни контенту;
• розміщення сайту на будь-якому файловому хостингу.

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

Інструменти

JAM — це лише підхід, засобів для якого на ринку вже достатньо. Як відомо, цвяхи можна забивати чим завгодно, але я пропоную використовувати молоток.

Список найкращих інструментів на 2019 рік:

Gatsby― це генератор статичних сайтів з React + GraphQL додатків. Чому саме такий вибір, а не Angularабо Vue,я не знаю. Найімовірніше справа у статистиці, яка говорить, що незважаючи на всі суперечки, React — найпопулярніший фреймворк останніх трьох років (не закидайте мене камінням в коментарях за це твердження, насправді мені заплатили). Для більш наочного уявлення: create-react-appкомпілює код в JavaScript білд для подальшого рендеру під час старту сторінки. Gatsby генерує повноцінні HTML-сторінки, які показуються як є, навіть з вимкненим JS.

Contentful― система управління контентом на статичних сторінках. Це WordPress, який не зберігає зв’язки між шаблонами і даними в БД, а замість цього змінює дані безпосередньо в HTML-файлах.

Netlify― це дуже проста у використанні система деплойменту, яка дозволяє зв’язати більшість популярних файлових хостингів з JAM додатком та ще й на HTTPS-протоколі.

До справи

Тепер, коли визначилися з інструментами, можна починати.

Contentful

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

У цілому система управління базується на двох сутностях — Content model, що описує структуру і типи даних, і сам Content. Для початку створимо просту модель для нашого блогу. Content model складається з типів даних, наприклад, для блогу типами даних будуть: Article, Person.

Звичайно ж, можна вибрати рівень абстракції, який здається кращим. Наприклад, можна замість Personвказувати дані про автора всередині Article, як Article.author_name

  article/├── title (Short text)
  ├── text (Long text)
  ├── banner (Single media)
  └── publishedAt (Date & Time)

  person/
  ├── fullName (Short text)
  └── avatar (Single media)

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

Gatsby

Відкриваємо термінал і створюємо робоче середовище:

## Встановлення
npm install --global gatsby-cli

## Створення проекту
gatsby new personal-blog

## Для любителів мінімалізму можна встановити Hello World проект
## gatsby new minimal-gatsby https://github.com/gatsbyjs/gatsby-starter-hello-world

## Переходимо в теку
cd personal-blog

Структура згенерованого проекту

## Запуск проекту с hot-reloading
gatsby develop

Що вийшло? React + GraphQL додаток, який збирається за допомогою Gatsby. Це означає, що можна будь-який старий проект, який довго рендериться, перевести в статичний HTML-сайт і отримати приріст у швидкості в кілька разів.

Gatsby+Contentful

## Встановлення додаткових пакетів
npm install gatsby-source-contentful dotenv

Створюємо файл .envв кореневій теці додатку з таким змістом:

/* 12-и значный ключ з Contentful → Settings → API keys → Example key 1→ Space ID */
CONTENTFUL_SPACE_ID=xxxxxxxxxxxx
/* 64-х значный ключ з Contentful → Settings → API keys → Example key 1→ Content Delivery API - access token */
CONTENTFUL_ACCESS_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Розширюємо конфігурацію в gatsby-config.js:

if (process.env.NODE_ENV === "development") {
  require("dotenv").config();
}
module.exports = {
  /* other settings */
  plugins: [
    /* other plugins */
    {
      resolve: `gatsby-source-contentful`,
      options: {
        spaceId: process.env.CONTENTFUL_SPACE_ID,
        accessToken: process.env.CONTENTFUL_ACCESS_TOKEN,
      },
    }
  ]
}

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

Gatsby+GraphQL+Contentful

Якщо ви ще не знайомі з GraphQL, то не переймайтесь, бо це досить просто. Сайт зараз знаходиться за адресою:

http://localhost:8000

Але поки що залишимо його і відкриємо другу вкладку:

localhost:8000/___graphql

Перед нами IDE для GraphQLпрямо в браузері. З ним дуже зручно будувати запити і тестувати їх. Натисніть на Docs у верхньому правому куті, щоб розгорнути сайдбар з документацією. Але сюрприз, це не документація до GraphQL, це документація вашого API. Розгорніть список Query, щоб побачити всі доступні схеми для запитів, з їхніми типами даних.

Схеми, які нас цікавлять, мають приблизно такі назви:

• contentfulВашТипДаних — один екземпляр
• allContentfulВашТипДаних — список з екземплярів

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

  {
    contentfulPerson {
      fullName
      avatar {
        file {
          url
        }
      }
    } 
    allContentfulArticle {
      edges {
        node {
          title
          text {
            text
          }
          banner {
            file {
              url
            }
          }
          publishedAt
        }
      }
    }
  }

Що можна відзначити зі структури запитів:

• щоб отримати URL для файлу, потрібно звертати на шлях typeName.file.url;
• щоб отримати текст з типу Long text, йдемо по шляху typeName.typeName;
• щоб отримати список екземплярів якогось типу, потрібно використовувати шлях allContentfulName.edges.

Переносимо схему запиту до проекту і рендеримо відповідь як звичайні дані в React-додатку. Загальноприйнятим Best Practice вважається використання <StaticQuery /> компонента, з пакета gatsby, який вже встановлений в проект.

  import React from "react"
  import { StaticQuery, graphql } from "gatsby"

  import Layout from "../components/layout"
  import Article from "../components/article"

  const IndexPage = () => (<Layout><StaticQuery
        query={graphql`
          {
            allContentfulArticle {
              edges {
                node {
                  id
                  title
                  text {
                    text
                  }
                  banner {
                    file {
                      url
                    }
                  }
                  publishedAt
                }
              }
            }
          }
        `}
        render={({
          allContentfulArticle: {
            edges
          }
        }) => (
          edges.map(({ node }) => (<Article key={node.id} content={node} />
          ))
        )}
      /></Layout>
  )

  export default IndexPage

Як це працює? Вqueryпередається схема запиту GraphQL, а в render — наш улюблений JSX. Використовуйте деструктуризацію, щоб зробити код більш читабельним.

  import React from "react"

  const Article = ({
    content: {
      title,
      text,
      banner: {
        file: {
          url
        }
      },
      publishedAt
    }
  }) => (<div><h2>{title}</h2><img src={url} alt={title}/><p>
        {text}</p><h5>{publishedAt}</h5></div>
  )

  export default Article

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

Розмістимо наш проект на GitHub, звідки його можна буде публікувати в наступному кроці.

  ## Находясь в папке с проектом инициализируем пустой репозиторий
  git init

  ## Сделаем первый коммит
  git add .
  git commit -m “initial commit”

  ## Создаем репозиторий на GitHub и подключаем
  git remote add origin git@github.com:yourname/my-repository-name.git

  ## Публикуем изменения
  git push origin master

Налаштовуємо Netlify

Створюємо аккаунт, використовуючи той сервіс, на якому планується розміщення проектів. Я вибрав GitHub, тому після успішної авторизації налаштуємо новий проект з New site from Git. Підключаємо наш репозиторій, а Netlifyавтоматично визначить, що це Gatsbyпроект, і налаштує всі скрипти для збірки.

Вибираємо потрібну гілку і не забуваємо про змінні оточення. Для цього відкриваємо меню Advanced settings і додаємо змінні з локального файлу .envта підтверджуємо налаштування.

Кілька хвилин магії, і сайт на місці: https://tender-liskov-ce3ad0.netlify.com

Залишилося додати хук на оновлення контенту. Переходимо в налаштування:

Deploy settings → Build hooks → Add build hook

Встановлюємо будь-яку зрозумілу назву, для прикладу «Contentful hook», вибираємо гілку, з якої будемо робити білд, і підтверджуємо. Результатом буде посилання, копіюємо його і переходимо в панель Contentful:

Settings → Webhooks

Шукаємо на правій панелі темплейт для Netlifyі за кілька кліків пов’язуємо дві системи. Пробуємо змінити контент і дивимося, як нові дані з’являються на сайті.

Висновок

JAM-stack поєднує в собі рішення проблем попередніх підходів і, схоже, претендує на захоплення влади і всесвітню популярність. Але чи це революція? Нічого нового і особливого немає, але це найбільш передова методологія останніх двох років там, на чужині, а у нас? Ми тільки-тільки почали переводити проекти з WordPressна React,і це однозначно прогрес. Але, може, щоб не залишитися за бортом, як легендарний індійський аутсорс, нам час робити більш рішучі кроки?

Репозиторій з проектом

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

Сегодня существует огромное количество библиотек для машинного и глубокого обучения. Чтобы облегчить задачу выбора для новичков, мы рассмотрим только самые популярные и необходимые библиотеки, которые покрывают все базовые потребности для начала работы с ML и DL.

Язык программирования: Python или R?

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

Именно поэтому в последние пару лет Python набрал огромную популярность и стал lingua franca в сообществе машинного обучения. Практически любая современная ML или DL библиотека предоставляет Python API.

Поэтому сейчас задача выбора сильно упростилась: используйте Python и не ошибетесь.

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

Jupyter Notebook: работа с данными, кодом и графиками

Если в традиционном программировании большую часть времени вы проводите в текстовых редакторах или IDE-шках, то в Data Science большая часть кода пишется в Jupyter Notebook.

Это простой и мощный инструмент для анализа данных. Он позволяет писать код на Python, R и других языках, добавлять текстовые описания в Markdown, встраивать графики и диаграммы непосредственно в интерактивную веб-страницу.

Плюс ко всему, Google выпустил бесплатный сервис Google Colab, который предоставляет облачную версию Jupyter Notebook и дает возможность производить вычисления на CPU и GPU. Все нужные питоновские ML библиотеки уже установлены, так что можно начинать сразу там, если лень устанавливать все локально.

Scikit-learn: лучшая библиотека для классических ML алгоритмов

Scikit-learn — одна из самых популярных ML библиотек на сегодня. Она поддерживает большинство алгоритмов обучения, как с учителем, так и без: линейная и логистическая регрессия, метод опорных векторов (SVM), Naive Bayes классификатор, градиентный бустинг, кластеризация, KNN, k-средние и многие другие.

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

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

Pandas: извлечение и подготовка данных

Анализ и подготовка данных зачастую занимает большую часть времени при решении ML задач. Данные могут быть получены в CSV, JSON, Excel или другом структурированном (или не очень) формате, и вам нужно обработать их для того, чтобы использовать в ML моделях.

Для этих целей используется библиотека Pandas. Это мощный инструмент, который позволяет быстро анализировать, модифицировать и подготавливать данные для дальнейшего использования в других ML и DL библиотеках, таких как Scikit-learn, TensorFlow или PyTorch.

В Pandas можно загружать данные из различных источников: SQL баз, CSV, Excel, JSON файлов и других менее популярных форматов.

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

Jupyter Notebook также поддерживает Pandas и реализует красивую визуализацию его структур данных.

Сайт Pandas содержит очень подробную документацию. Но начать можно с 10-минутноготуториала, который показывает все основные фишки и возможности библиотеки.

Библиотека NumPy: многомерные массивы и линейная алгебра

Основной функционал NumPyзаключается в поддержке многомерных массивов данных и быстрых алгоритмов линейной алгебры. Именно поэтому NumPy — ключевой компонент Scikit-learn, SciPy и Pandas.

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

Для этого отлично подойдет вводный туториал по Numpy, а также основы NumPy.

Matplotlib и Seaborn: построение графиков и визуализация данных

Matplotlib — это стандартный инструмент в наборе дата-инженера. Он позволяет создавать разнообразные графики и диаграммы для визуализации полученных результатов.

Графики, созданные в Matplotlib, легко интегрируются в Jupyter Notebook. Это дает возможность визуализировать данные и результаты, полученные при обработке моделей.

Для этой библиотеки создано множество дополнительных пакетов. Один из наиболее популярных — это Seaborn. Его основная фишка — готовый набор самых часто используемых статистических диаграмм и графиков.

Традиционно, обе библиотеки имеют раздел с туториалами на их сайтах, но более эффективным подходом будет зарегистрироваться на сайте Kaggleи посмотреть в разделе «Kernels» готовые примеры использования, например, Comprehensive Data Exploration with Python.

Tensorflow и Keras: библиотеки глубокого обучения

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

В Tensorflow, библиотеке глубокого обучения от Google, отлично реализованы все три компонента. Наряду с CPU, она поддерживает вычисления на GPU и TPU (тензорных процессорах Google).

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

Keras — это надстройка над Tensorflow, которая решает множество юзабилити-проблем последней. Ее главная фишка — это возможность строить архитектуру нейронной сети с использованием красивого Python DSL. Для Keras также написано множество обучающих материалов, поэтому разобраться с ней несложно.

PyTorch: альтернативная библиотека глубокого обучения

Пожалуй, PyTorch — это вторая по популярности DL библиотека после Tensorflow, которая создана в Facebook. Ее сильная сторона в том, что она была разработана для Python, и поэтому использует его стандартные идиомы. По сравнению с Tensorflow, здесь порог входа намного ниже, а любую нейронную сеть можно построить с использованием стандартных ООП классов и объектов.

Также ее легче отлаживать, потому что код исполняется как обычный Python код — нет этапа компиляции, как в TensorFlow. Поэтому можно пользоваться даже питоновским отладчиком.

Если сравнивать с Keras, PyTorch — более многословный, но менее магический.

У PyTorch тоже есть своя надстройка — это библиотека fastai. Она позволяет решить большинство стандартных DL задач в пару строчек кода. Но что делает fastai действительно особенной — это их невероятный онлайн-курс Practical Deep Learning for Coders.

На что обратить внимание

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

Чтобы сделать процесс обучения более гладким, есть смысл начать эксперименты с классических задач ML и сфокусироваться на использовании Scikit-learn и Pandas. И после этого уже двигаться в сторону глубокого обучения.

Если вы задаетесь вопросом, какую DL библиотеку лучше выбрать: TensorFlow/Keras или PyTorch, то лучшим ответом будет найти онлайн-курс, который вам нравится, и курс сделает выбор за вас.

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

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

Компенсація

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

«Зарплати на нашому проекті нижчі за ринкові. Для підвищення зарплатні доведеться змінювати проект або компанію».

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

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

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

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

«Компенсация труда не пересматривается. Много лет „стабильности“».

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

«За 6 месяцев работы я получил зп вовремя 3 раза!».

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

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

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

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

«Всего лишь 15 дней отпуска в году».

«14 дней отпуска — наименьшее количество, которое я видела среди компаний. Медстраховка — только после года работы. Оплата овертаймов — сидеть на работе до 22:00 не считается овертаймом в компании».

«Єдине, що надає компанія — відпустка. Це важко назвати соцпакетом :) Все інше треба узгоджувати із кастомером. Кастомер і буде платити за додаткові „плюшки“».

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

Умови праці

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

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

«Влажность воздуха ниже критической нормы (ниже 15%), опенспейс на несколько сотен людей — постоянные болезни. Очень мало переговорок и конференц-залов, поэтому 90% митингов проходят за рабочими местами — безумно шумно, как на вокзале. Кухни очень маленькие — бывает, что просто нет места для того, чтобы сесть и пообедать».

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

«Канцтоваров иногда не хватает. Чтобы третий монитор поставить, пришлось пройти несколько кругов бюрократии и договоренностей с коллегами».

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

«Для тестов на Сафари есть только один Мак, и приходится специально за него садиться, чтобы протестить. Нет возможности протестить на рабочем месте. Хотелось бы ПО для тестов в разных браузерах».

«Дуже туго з технікою, якщо маєш свої вподобання та звички».

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

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

«Железо очень печальное. Если нужно поднять несколько Java проектов, комп не тянет. Чтобы добиться нормального оборудования, нужно либо попасть в правильный отдел, либо купить свое нормальное».

«Ну этот вот „дизайн“ а-ля больница. Все белое, красивостей и растений почти нет. Парковка во дворе — только для избранных (по какому критерию?). Можно было бы общий ресурс парковки шарить более справедливо. Либо квоты с бронированием, либо еще как-то».

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

«Ты обязан сидеть бесплатным охранником своего монитора от звонка до звонка (бывало, даже до 3 ночи). Бесплатным — потому что простой в работе не оплачивается. То, что тебе не дали текущие задачи или у тебя стопперы из-за других сотрудников — никого не волнует. В итоге ты будешь вымотан непредсказуемым графиком, за который получишь копейки».

«Неудобная система подсчёта времени, где чувствуешь себя рабом на галере. Система трекает 9 часов, и ты должен быть это время в офисе. Бывает такое, что делаешь весь свой обьём работы за 6 часов, а раньше уйти не можешь. Будет меньше в конце месяца — получишь разговор с HR/лидами. Вот и приходится имитировать работу либо „досиживать“, если уходил раньше».

Кар’єра

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

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

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

«Легше зістаритися, ніж отримати підвищення. Підвищення повинні бути відповідно до знань і досвіду, а не через рік».

«Навчання для девів дуже мало (практично нема). Безкоштовні конференції лише за умови проведення доповіді (брєд). Зміни напрямку взагалі нема».

«Я не получал конструктивной критики в свой адрес о проделанной мной работе. Либо это лицимерное „все хорошо“, либо тишина. На таком топливе далеко не поедешь. Нужно четко говорить, что хорошо, а что плохо, чтобы человек мог это исправить».

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

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

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

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

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

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

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

Проект

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

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

«Тяжелая процедура „выхода“ из какого-то аккаунта. Непонятно, из чего можно выбрать».

«Проект неинтересный, много легаси. Работаю совсем с другим стеком технологий, чем обещали при трудоустройстве».

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

«Ребята уставшие и морально, и физически. Есть чувство общей депрессии».

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

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

«Все время спешка, так как нет правильного менеджмента и ведения учета времени работы над задачами, четких задач нет. 30% описывалось в багтрекинговой системе, остальные 70% — на словах, это ужас... А после выполнения в поставленные сроки (из кожи вон лез, чтобы успеть) говорили, что уже не нужно, решили отложить на неопределенное время... И так с каждыми условными спринтами».

«Специфіка проекту не дозволяє використовувати сучасні технології, фреймворки і т. д.»

«Проекту 10 років, про сучасні технології тут не йдеться».

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

«Абсолютна більшість менеджменту — не компетентні у своїй галузі».

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

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

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

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

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

Ізюм

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

«Местами график сильно гибкий, не в пользу работника».

«Ну, я люблю поспать, а команда работает с самого утра. Дикие прям :) Я их не виню, я виню свою лень xD».

«Проще уволиться и прийти опять, чем выбить повышение более чем на 10%».

«Зарплата, сравнимая с доходом работника фастфуда без опыта. И так все 4 месяца. Где вы такое еще увидите?».

«Централизовать выдачу канцелярии через HR отдел, а не завхоза (храни, господь, её нервы)».

«Тумбочку... хоть маленькую, хоть ящичек... Пожалуйста».

«Из техники только монитор и коврик».

«Хотілося би більший стіл. Ще й постійно ноги б’ються об людину навпроти».

«Бесят немцы с Друпалом».

«Команда нравится, но атмосфера в связи с нездоровым дедлайном нездоровая :)».

«Есть впечатление, что менеджеры больше пьют чай и общаются, пока остальные работают».

«Есть лоси в коллективе, но как же без этого».

«Я перестал понимать своего менеджера».

«П’янки створюють непрофесійну атмосферу».

«Коворкинг, иногда соседи из других офисов на кухне раздражают».

Нагадаємо, що більшість ІТ-спеціалістів все ж таки задоволені своїм місцем роботи. Але сподіваємося, що коментарі співробітників допоможуть компаніям стати ще кращими.

Привет, меня зовут Галина Олейник, я занимаюсь решением задач в сфере natural language processing в компании 1touch.io. Сегодня я хотела бы рассказать об актуальной теме работы data scientist’а с фреймворком TensorFlow, а также углубиться в детали решения наиболее частых проблем, которые возникают при взаимодействии с ним.

Когда речь заходит о написании кода на TensorFlow, зачастую это заканчивается его сравнением с PyTorch, разговорами о том, насколько сложен этот фреймворк и почему некоторые части tf.contribработают так плохо. Более того, я знаю многих data scientist’ов, которые взаимодействуют с TensorFlow только как с зависимостью уже написанного Github’овского репозитория. Причины такого отношения к этому фреймворку очень разные, и они заслуживают написания еще одного лонгрида. Сегодня я предлагаю сфокусироваться на более прагматичных проблемах: дебаг кода на TensorFlow и понимание его основных особенностей.

Ключевые абстракции

Вычислительный граф

Первая абстракция, которая делает фреймворк таким сложным для понимания и позволяет взаимодействовать с парадигмой lazy evaluation — это вычислительный граф tf.Graph. По сути, этот подход позволяет разработчику создавать тензоры tf.Tensor (грани) и tf.Operation (ноды), которые не вычисляются сразу же, а только когда граф выполняется. Такой метод создания моделей машинного обучения распространен во многих фреймворках и имеет различные недостатки и достоинства, которые становятся очевидными во время написания и запуска кода.

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

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

Оговорюсь, что в этой статье не будут рассмотрены возможности tf.enable_eager_execution(), поскольку хоть этот режим и является встроенной возможностью TensorFlow, он в какой-то мере противоречит самой сути вычислительного графа и его дефолтным возможностям.

Более того, до тех пор, пока мы не выполнили граф, мы также не можем оценить приблизительное время его выполнения.

Основные компоненты вычислительного графа, которые стоит упомянуть, — коллекции графа и структура графа. Строго говоря, структура графа — это определенный набор нод и граней, упомянутых ранее, а коллекции графа — это наборы переменных, которые могут быть сгруппированы логическим образом. К примеру, распространенный способ получения тренируемых переменных графа: tf.get_collection(tf.GraphKeys.TRAINABLE_VARIABLES).

Сессия

Вторая абстракция тесно связана с первой и имеет чуть более сложную трактовку: сессия TensorFlow tf.Sessionиспользуется для связи между клиентской программой и C++ runtime. Почему С++? Ответ заключается в том, что математические вычисления, реализованные с помощью этого языка, могут быть очень хорошо оптимизированы. В результате операции графа могут быть обработаны с высокой производительностью.

При использовании стандартного низкоуровневого TensorFlow API, сессия вызывается в качестве контекстного менеджера: использован синтаксис with tf.Session() as sess:. Если не передать в конструктор ни одного аргумента, сессия использует только ресурсы локальной машины и дефолтный глобальный TensorFlow граф. Если передать в конструктор сессии какие-то аргументы, она также может иметь доступ к удаленным устройствам с помощью распределенного TensorFlow runtime. На практике, граф не может существовать без сессии (без сессии он не может быть выполнен), и сессия всегда имеет указатель на глобальный граф.

Углубляясь в детали запуска сессии, отмечу, что основным пунктом является его синтаксис: tf.Session.run(). Он может иметь fetch в качестве аргумента (или их список), который может быть тензором, операцией или производным от тензора объектом. К тому же feed_dict может быть передан вместе со списком необязательных опций. Этот необязательный аргумент является мэппингом (словарем) объектов tf.placeholder к их значениям.

Возможные проблемы и их наиболее вероятные решения

Загрузка сессии и создание предсказаний с помощью натренированной модели

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

Что мы имеем в виду, когда говорим о загрузке модели? Сперва мы ее тренируем и сохраняем. Последнее, как правило, достигается с помощью функционала tf.train.Saver.save. В результате мы имеем 3 бинарных файла с расширениями .index, .metaи .data-00000-of-00001, которые содержат в себе все необходимые данные для восстановления сессии и графа.

Чтобы загрузить сохраненную таким образом модель, мы должны восстановить граф с помощью tf.train.import_meta_graph() (аргументом является файл с расширением .meta). Если следовать описанным шагам, все переменные (включая так называемые «скрытые»), будут портированы в текущий граф. Чтобы получить определенный тензор, имея его имя, выполняем graph.get_tensor_by_name(). Как мы помним, имя может отличаться от того, которое было использовано при инициализации в зависимости от скоупа и операции, результатом которой тензор является. Это первый подход.

Второй подход — более явный и сложный для реализации. В случае архитектуры модели, над которой я работала в последний раз, мне не удалась его использовать. Его основная идея — сохранить грани графа (тензоров) в .npyи .npz файлы. Будущая их загрузка обратно в граф происходит вместе с присваиванием должных имен в соответствии со скоупом, где они были созданы. Такой подход также не лишен недостатков. Во-первых, когда архитектура модели становится сложной, нам тяжело контролировать и держать на своих местах все матрицы весов. Во-вторых, есть определенный вид «скрытых» тензоров, которые создаются без их явной инициализации. К примеру, когда мы создаем tf.nn.rnn_cell.BasicLSTMCell, она создает все необходимые веса и байесы «под капотом». Названия переменных также присваиваются автоматически.

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

Создание тензора с таким же именем дважды без какого-либо предупреждения (с помощью автоматического добавления окончания _index)

Эта проблема не настолько важна, как и предыдущая, но она результирует во множество ошибок выполнения графа. Чтобы объяснить ее лучше, приведем пример.

Допустим, мы создаем тензор с помощью tf.get_variable(name='char_embeddings', dtype=…), а после сохраняем его и загружаем обратно в новую сессию. Мы забыли о том, что эта переменная была тренируемой, и создали ее еще раз с помощью такого же функционала tf.get_variable(). Во время выполнения графа мы получим следующую ошибку: FailedPreconditionError (see above for traceback): Attempting to use uninitialized value char_embeddings_2. Все дело в том, что мы создали пустую переменную и не портировали ее в соответствующем месте в модели, хотя она может быть портирована, поскольку уже содержится в графе.

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

Сброс графа вручную при написании unit-тестов и другие проблемы с ними

Тестировать код, написанный на TensorFlow, всегда сложно по ряду причин. О первой — и наиболее очевидной — уже шла речь в начале этого раздела. Из-за того, что по умолчанию существует только один TensorFlow граф для всех тензоров всех модулей, к которым есть доступ во время runtime, невозможно тестировать тот же функционал, к примеру, с разными параметрами, без того, чтобы сбрасывать граф. Это всего одна строчка кода tf.reset_default_graph(). Учитывая, что она должна быть написана наверху большинства методов, это решение превращается в monkey job и есть явным примером дубликации кода.

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

Есть еще одна особенность кода на TensorFlow, которая меня беспокоит. Когда граф был создан, но не должен быть выполнен (он имеет неинициализированные тензоры внутри, потому как модель еще не была натренирована), никто не может сказать, что мы должны тестировать. Я имею в виду то, что аргументы к self.assertEqual() не ясны. Мы должны тестировать имена выходящих тензоров и их форму? Что, если формой является None? Что, если имя тензора или его форма — не достаточное условие, чтобы заключить, что код работает соответствующим образом? В моем случае, я просто делаю assertдля имен тензоров, их форм и размерностей. К сожалению, я уверена, что в случае, когда граф не был выполнен, недостаточно проверить только эту часть функционала.

Запутанные названия тензоров

Многие люди скажут, что этот комментарий по поводу работы TensorFlow является изощренным видом недовольства или нытья, но никто наверняка не может сказать имя результирующего тензора после выполнения над ним определенной операции. Достаточно ли понятно для вас имя bidirectional_rnn/bw/bw/while/Exit_4:0? Для меня — нет. Я понимаю, что этот тензор — результат определенной операции, сделанной над backward ячейкой динамической двусвязной RNN, но без того, чтобы дебажить эту часть кода, порядок и названия произведенных операций неочевиден. Кроме того, окончания в форме индексов также не понятны. Чтоб разобраться, откуда появилось число 4, необходимо прочесть документацию TensorFlow и углубиться в детали работы вычислительного графа.

Такая же ситуация и для «скрытых» переменных, упомянутых ранее: почему имя kernel? Как по мне, такие случаи для дебага крайне неестественны.

tf.AUTO_REUSE, тренируемые переменные, рекомпиляция библиотеки и другие неприятные моменты

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

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

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

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

И в-третьих, хочу поделиться трюком для оптимизации кода. Часто используя библиотеку, установленную с помощью pip, мы видим предупреждение по типу Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX AVX2. В таком случае лучше всего удалить TensorFlow, а потом перекомпилировать его с помощью Bazel с нужными опциями. В результате получаем преимущество в виде увеличенной скорости вычислений и общей производительности фреймворка на нашей машине.

Выводы

Я надеюсь, что этот лонгрид будет полезным для тех data scientist’ов, которые разрабатывают свои первые TensorFlow модели и сталкиваются с трудностями в понимании неочевидного поведения частей фреймворка. Основная идея, которую я хотела донести: делать много ошибок во время работы с этой библиотекой — совершенно нормально, как и задавать вопросы, углубляться в документацию и дебажить каждую строчку кода.

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

[В рубрике «Как я работаю»мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах и лайфхаках]

Роман Шрамковсотрудничает с EPAM больше 8 лет, прошел путь от обычного программиста до Technology Director. Его главная обязанность — растить архитекторов, которые смогут решать любые архитектурные задачи и находить свежие решения самостоятельно.

Роман возглавляет и развивает центр компетенций Java. В рамках этого проекта он проводит консультации для клиентов ЕРАМ, посещает международные конференции, в том числе форум глав центров компетенции в Минске и Global Solution Architecture Team Gathering.

О себе

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

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

Университет я закончил в 2000-мгоду. Решил, что с физикой связывать жизнь не буду: несмотря на сильную школу, в этой области в Украине не было перспектив. Тогда я задумался о программировании — меня всегда привлекала эта компьютерная магия. О деньгах речь не шла, программирование еще не было распространенной, популярной и высокооплачиваемой профессией. В то время разработкой ПО занимались всего несколько компаний, а платили программистам максимум $100.

Я устроился на работу в государственную организацию и по ночам зубрил языки программирования, чтобы подтянуть прикладные навыки. Спустя год-полтора получил первую работу в маленькой конторе. Мы разрабатывали систему учета для школ, использовали Visual Basic и продукты Microsoft Office.

Дальше — первая «промышленная» работа в продуктовой компании, где делали биллинговую систему и всерьез говорили о терабайтах данных. Сначала я разрабатывал базы данных, писал запросы и хранимые процедуры. Затем попал в R&D-отдел и перешел на Java. После стека Microsoft этот язык мне понравился своей открытостью, наличием Open Source и сильного сообщества.

Затем я сменил еще 3-4компании и в 2010 году устроился в EPAM на позицию Lead Software Engineer. С ходу попал на интересный проект. Мы дорабатывали систему для бронирования отелей. Предыдущая платформа заказчика была настолько плохого качества, что когда мы втроем с коллегами одновременно зашли на сайт, он упал. И нам дали карт-бланш на то, чтобы все переделать. Мы разрабатывали продукт и показывали заказчику графики роста производительности и надежности, а он нам в ответ — графики роста прибыльности. И это давало понимание, что мы все делаем правильно.

Роль и обязанности

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

Затем в 2014 году EPAM начал развивать дисциплину Solutions Architecture, которая впоследствии трансформировалась во внутреннюю школу для Solutions Architects. В отличие от Software Architect, Solutions Architect отвечает не за код, а за общение с заказчиком, прояснение требований и формирование высокоуровнего решения для всей системы. Он выбирает, какие технологии использовать, почему именно их — исходя из того, чтобы инструменты соответствовали бизнес-целям разрабатываемого продукта. Если над проектом работают несколько команд, этот специалист синхронизирует понимание архитектуры между ними.

После того, как я около 10 лет работал только с кодом, работа с людьми стала новым вызовом и полем для роста. Было интересно разобраться, понять, как это делать правильно.

Затем я задумался, как можно распространить свой опыт управления процессами с уровня одного проекта на больший масштаб. В прошлом году EPAM предложил мне позицию Technology Director. Как и прежде, я выступаю в роли посредника между бизнесом клиентов и техническими командами, но только на уровне всей компании. Общаюсь с заказчиками, консультирую внутренние процессы, внедряю best practices.

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

Ещё одна моя роль в компании — руководитель центра компетенций Java. Я поставил себе цель сформировать пул экспертов, которые могли бы выезжать к заказчику и грамотно обсуждать технические решения. Чтобы построить процессы, изучал примеры компаний Oracle и IBM, где центры компетенций по некоторым темам работают как выделенные структуры.

Ядро нашей команды — 5-6 архитекторов,которые занимаются пресейлом, консалтингом и кейсами, в которых необходима серьезная инженерная поддержка. Я как руководитель центра компетенции возглавляю архитектурную группу. Через меня проходят большинство «красных», сложных и важных кейсов.

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

Типичный рабочий день

8:00.Я рано прихожу на работу. Обычно в это время в офисе нет никого, кроме охранника и уборщицы, и я могу почитать технические новости и статьи, посмотреть какие-то технологии, написать прототип. В общем, занимаюсь обучением, которое позволяет расти как специалисту.

10:00.Начинаются стендапы с командами и созвоны с заказчиками из Европы.

11:30. Занимаюсь работой по проектам: подготавливаю какие-то документы, заполняю артефакты.

12:30.Иду на обед. Считаю, что очень важно делать перерыв на отдых, немного отвлечься от работы. Если человек перестает ходить на обед — это первый признак, что он перегружен. Я часто обедаю с командой, мы болтаем на отвлеченные темы, обсуждаем новости. Получается что-то вроде тимбилдинга :)

13:30.Еще час-полтора работаю над проектами и своими задачами.

15:00. Просыпаются заказчики из США и начинают бомбить запросами и созвонами :)

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

18:30.Заканчиваю работу. Стараюсь уходить из офиса не позже 19-тичасов, чтобы успеть отдохнуть и провести время с женой и детьми, у меня их четверо. В молодости было время, когда зависал на работе днями и ночами. Но когда появилась семья, принял решение ограничить рабочее время.

Получается, я провожу в офисе 10-11часов с учетом обеда. Но не все это время занимают исключительно рабочие задачи. На сфокусированную техническую работу уходит примерно 3-4 часа.Остальное — общение и самообразование.

Инструменты и продуктивность

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

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

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

Помимо краткосрочных целей, я записываю и средне- и долгосрочные — на квартал, год и 3-5 лет.Это помогает развиваться, а не топтаться на одном месте. Подхожу к этому гибко: моя цель не обязательно имеет четкую формулировку и дедлайн. Скорее, она просто задает направление движения. К примеру, несколько лет назад я поставил себе цель возглавить центр компетенций Java. Для этого узнавал, как это работает, какие нужны навыки и знания, чтобы попасть на эту позицию. Я не ставил конкретные сроки, просто держал цель в фокусе и выделял время на подготовку. По такой же схеме подхожу и к личным целям — например, похудеть: за последние полгода сбросил около 10 кг.

Мне очень нравится методика Getting things done. Я обязательно фиксирую все задачи, которые ко мне приходят. Для этого использую Outlook, так как большинство запросов поступает в виде писем, заметок или follow-ups по митингам. Периодически просматриваю свой список задач, чтобы не забыть о делах, которые имеют дедлайн.

Для кодирования использую IntelliJ IDEA, для трекинга задач — Jira. Информацию по проектам веду в Excel — это очень универсальный инструмент, который удовлетворяет все мои запросы. Например, планирую там задачи, обозначаю open issues, которые надо обсудить с заказчиками, расписываю SWOT-анализ.

Книжки и самообразование

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

Новости об украинском сегменте IT читаю на DOU и AIN. Об инновациях и всемирных стартапах — на TechCrunch. Много интересных материалов для архитекторов выходит на InfoQ.com.

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

Что касается фундаментальных книг для архитекторов, я советую почитать:

• «Software Architecture in Practice» by Len Bass, Paul Clements, Rick Kazman;
• «Documenting Software Architectures» by Paul Clements, Felix Bachmann, Len Bass;
• «Software Systems Architecture» by Nick Rozansk;
• «Just Enough Software Architecture» by George Fairbanks;
• «97 Things Every Software Architect Should Know» by Richard Monson-Haefel.

Ретроспектива и планы на будущее

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

В моих ближайших среднесрочных планах — построить в EPAM Украина организацию, которая будет заниматься технологической частью delivery. Ее зона ответственности — подсказывать коллегам, как правильно применить инновации под задачи клиента в каждом конкретном проекте. Это творческий вызов, и мне интересно разобраться, как правильно выстроить процессы такого уровня.

Всем привет, я Лубчак Алена, CEO & SAFe Program Consultant в компании E5. Я работаю с SAFe (Scaled Agile Framework) на практике с 2014 года. В конце 2015 прошла сертификацию и обучение как SAFe Program Consultant. Сейчас в качестве консультанта помогаю компаниям внедрить Scaled Agile Framework и повысить продуктивность работы.

В этой статье я не ставила перед собой цель предоставить исчерпывающее объяснение SAFe. Для этого существуют специализированные тренинги, книги, вебинары, встречи и т. д. Моя задача — дать минимальный обзор, осветив самые важные, на мой взгляд, аспекты фреймворка. Сосредоточимся на базовой конфигурации Essential SAFe.

Лидер среди других фреймворков

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

12th Annual State of Agile Reportот VersionOne.

Scaling Agile Reportот cPrime

Scrum Master Trendsот Scrum.org

Эту же картину я наблюдаю и в Украине по значительному росту интереса за последние 3 года не только к открытыми тренингам по SAFe, но и по корпоративным запросам. Все больше аутсорсинговых компаний сталкиваются с требованием вести проект по SAFe от своих заказчиков и приходят за помощью в обучении и внедрении этого фреймворка.

Давайте рассмотрим фреймворк в деталях.

Определение

SAFe^® is a freely available knowledge base of proven, integrated principles and practices for Lean, Agile, and DevOps.

Другими словами, это бесплатная база знаний из проверенных принципов и практик. Каждая иконка на сайте scaledagileframework.comкликабельна, и по ней открывается целая статья с детальным пояснением роли, церемонии или артефакта и дополнительным списком литературы для углубления в тему. Это не то, что внезапно появилось в 2011 году, а, скорее, результат работы многих людей и собрание воедино лучших идей. Человек, который это все оформил в фреймворк, — Dean Leffingwell. Он является творцом этой базы знаний и главным методологистом SAFe. Конечно же, ему помогали и помогают многие люди. С их вкладом и ролями, а также с внушительным списком литературы, на которой все базируется, вы можете ознакомиться тут.

Сам фреймворк достаточно обширен и напоминает конструктор, где вы выбираете нужную себе конфигурацию. На сегодня есть 4 доступных варианта фреймворка (Essential, Portfolio, Large Solution, Full Configuration), которые покрывают компании и проекты от 50 до 20 000 человек. Эти цифры являются ориентировочными, поэтому если у вас меньше 50 или больше 20 000 человек, это не повод отказываться от SAFe :) Я начинаю смотреть в сторону этого фреймворка при командах от 30 человек.

SAFe Essential — это самая простая конфигурация, которая покроет вам от 50 до 125 человек.

Она состоит из 2 уровней — уровня команды и уровня программы.

Уровень команды

На уровне командывы выбираете тот фреймворк, который вам подходит больше всего для работы в команде — Scrum, Kanban, XP или что-то на ваш вкус. Главное требование — все команды должны работать в едином ритме с общими точками для синхронизации.

К примеру, если у вас из пяти команд, две работают с 2-недельнымиспринтами по Scrum, две — с 3-недельнымии одна — по Канбан, то у вас разные ритмы. Вместо трех точек для синхронизации в течение 6 недель (начала 2-хнедельного спринта) остается только одна. Команды с 3-недельнымиспринтами успеют одновременно с другими командами начать спринт всего лишь один раз на 6 недель. Это приведет к тому, что если в процессе работы одной команде что-то понадобится от другой, то надо ждать 6 недель, чтобы добавить ей это в спринт, вместо 2 недель.

Также на уровне команды, кроме привычных и хорошо знакомых user story, вводится понятие Enebler. Это технические инвестиции в разработку продукта. Тут могут быть какие-то архитектурные изменения, исследования, spike, инфраструктурные задачи и т. д.

Теперь переходим на уровень выше.

Уровень программы

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

Роли

В Scrum есть три роли: Product Owner, Scrum Master & Development team. В SAFe на уровне программы вводятся аналогичные три роли с соответствующими обязанностями, но с поправкой на масштаб: Product Management, RTE (Release Train Engineer) & System Architect/Engineer.

Product Management — это человек или люди (в больших продуктах зачастую больше чем один менеджер продукта), главная задача которых — ответить на вопрос: чтомы делаем с точки зрения продукта, его стратегии, видения и т. д. Взгляд этого человека направлен вовне, на рынок и клиентов. Вот детальный перечень обязанностей.

RTE (Release Train Engineer) — это Scrum Master Scrum Master-ов, или же человек, отвечающий за координацию, фасилитацию и организацию процесса работы программы. Лидер, ментор, коуч. Главный вопрос: какс точки зрения процесса будет все происходить? Именно он/она помогают устранять препятствия на уровне программы, организовывают церемонии уровня программы и т. д. Детальнее тут.

System Architect/Engineer — это роль, необходимая для общего технического и архитектурного виденья разработки продукта. Именно эта роль появляется при масштабе, так как в Scrum полнота технических решений отдается на откуп команде. Если у вас 100 человек, то им будет проблематично выделить время и договориться о единых технических решениях. Для этого и вводится элемент централизации — роль, обеспечивающая техническое направление. Главный вопрос: как техническимы это будем реализовывать? Детальнее по ссылке.

Кроме того, вводится понятие Architectural Runway — это технические инвестиции в код, инфраструктуру, архитектуру, необходимые для внедрения ближайших бизнес-фич без значительных технических переделываний. Наполнением такого технического беклога в частности и занимается System Architect/Engineer. Детальнее тут.

Аналогом Development Team на уровне программы будет ART (Agile Release Train) — это долго живущая команда команд, которые разрабатывают продукт. Обычно это 5-12 команд,50-125+ человек.

Церемонии

Аналогично Scrum, в котором есть планирование, выполнение спринта и его завершение, на уровне программы вводятся свои события.

Артефакты

Причем тут поезд?

Вы наверняка заметили, что SAFe вводит много терминологии, которая так или иначе намекает на поезда: ART (Agile Release Train), RTE (Release Train Engineer), Architectural Runway. И это не случайно. Метафора поезда вводится с тем, что у поезда есть предсказуемое стабильное расписание. Если вы пропустили один поезд — не беда, через известное время будет следующий и вы на него сядете. Аналогично с нашей продакт-командой и фичами: если в текущий PI не влазит какая-то фича, то она обязательно влезет в следующий :)

Еще что-то важное?

Безусловно :) Это все «не заведется» без нескольких важных вещей.

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

Во-вторых, весь процесс создания продукта — это непрерывное следование:

• Continuous Exploration (исследование рынка, наших пользователей, валидация продуктовых гипотез, нарезание MVP и т. д.);
• Continuous Integration (постоянная интеграция нового кода в существующий, проверка, поддержания качества на высоком уровне);
• Continuous Deployment (постоянное доставление функционала на продакшн, без включения неполных фич и т. д.);
• культуре DevOps.

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

Эти вещи достаточно философские, но их внедрение колоссально трансформирует вашу компанию.

В-третьих, Develop on Cadence. Release on Demand. Одним из типичных мифов является утверждение, что SAFe говорит релизиться раз в квартал. Тут попрошу отделять процесс планирования, когда мы высокоуровнево (на уровне фич) планируем работу 5-12команд на ближайший PI (8-12 недель)и процесс релиза на продакшн, который должен быть, согласно SAFe — по требованию бизнеса. Если ваш бизнес требует релизы по 30 раз на день — пожалуйста, релизьтесь. Другой вопрос, что для этого вам нужны Build-in quality, XP practices, DevOps культура и т. д.

Таким образом, с помощью определенных наборов правил Essential SAFe можно организовать синхронную работу до 125+ человек, которые будут планировать, выполнять и улучшать свои продукты и процессы постоянно.

Внедрять или нет?

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

• У вас 4-5+ команд,между ними есть зависимости, которые необходимо отслеживать. Они работают над одним продуктом или несколькими взаимосвязанными. У вас есть необходимость в синхронизации работы, много людей, но не понятно, кто чем занимается, и нужно оптимизировать систему в целом. Тогда я однозначно рекомендую обратить внимание на SAFe.
• Если у вас 4-12 команд,между ними нет зависимостей, но хочется одинаково высокого уровня качества, единых практик по управлению проектами, тогда вам целесообразнее рассмотреть классический РМО (Project Management Office).
• Если у вас 3-4 команды,которые работают над одним продуктом, то, вероятнее всего, обычный Scrum of Scrums уже упростит вам жизнь и решит проблему синхронизации. А какой-то дополнительный фреймворк по масштабируемости будет слишком дорогим с точки зрения усилий/затрат и получаемой выгоды.

Это был краткий обзор базовой конфигурации Essential SAFe. В следующих статьях я расскажу о других уровнях SAFe и более детально пройдусь по PI Planning и Inspect & Adapt workshop — интересных практиках для планирования, синхронизации и улучшения на масштабе.

Материал создан в соавторстве с Александром Макеевым, Machine Learning Engineer в R&D MEGOGO

Мы начинаем серию статей о том, как наша команда R&D с чистого листа создает рекомендательную систему видеосервиса. В первой части опишем продвинутый рекомендательный алгоритм, который базируется на данных о просмотрах видео.

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

Акцент в статьях будет смещен с математической составляющей в сторону процесса создания полноценного продукта, использующего machine learning алгоритмы. Мы пройдемся по всему рабочему процессу, начиная от сбора требований, сквозь все шаги нашего data pipeline, до развертывания на серверах.

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

Будем очень благодарны, если в комментариях вы поделитесь своим опытом создания machine learning проектов и их эксплуатации в боевом режиме.

Постановка задачи

В самом начале разработки классической рекомендательной системы на основе лайков и дизлайков пользователей было очевидно, что охват зрителей будет не более 5% от общего количества. Чтобы предлагать рекомендации для всех наших зрителей, нам был необходим другой источник данных о пользовательской активности. Таким источником стала внутренняя система трекинга фактических просмотров контента — WatchStat.

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

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

• CRR — коэффициент удержания клиентов;
• LTV — пожизненная ценность клиента;
• среднее количество часов просмотра на пользователя;
• процент пользовательских сессий без просмотров контента;
• процент рекомендованных и просмотренных единиц контента из всего каталога.

Использование неявных сигналов

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

Такой подход оставил множество вопросов без ответов. Если пользователь смотрел видео в течение 20 секунд, что это должно нам сказать? Видео понравилось или нет? Может он решил отложить просмотр на вечер? Или вспомнил, что уже однажды смотрел этот фильм и не хочет смотреть его во второй раз? А если пользователь просмотрел 45 минут видео и ушел? Когда нет данных о факте просмотра — это позитивный или негативный сигнал?

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

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

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

Кстати, подобные данные мы предоставляем участникам нашего онлайн-хакатона.

Немного математики: факторизация матриц

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

Входные данные представляют собой сильно разреженную матрицу вида:

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

Далее производится разложение исходной матрицы на две матрицы Uи V с некоторым выбранным количеством факторов. Эти матрицы представляют собой сжатую проекцию большей части всего распределения данных с некоторыми потерями, конечно. В нашем случае факторы в сжатой форме отражают всё многообразие «вкусов зрителей». Матрица U — проекция зрителей на вкусы. Матрица V — проекция контент-объектов на вкусы. Матрицы факторов должны содержать в себе такой набор значений, чтобы умножение U x Vдавало в результате матрицу с близкими к исходным значениями.

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

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

Главная сложность этого метода — как вообще найти факторы? И тут на помощь приходит машинное обучение в виде метода оптимизации Gradient Descent. Для его работы необходима дифференцируемая метрика (функция потерь), которую мы будем минимизировать. Очевидно, что метрика должна показывать ошибку приближения произведения матриц факторов к исходной матрице. Базовая формула выглядит так:

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

Существует ряд алгоритмов поиска факторов. Один из них — SGD (Stochastic Gradient Descent), работающий на семплах данных, обеспечивая хорошую масштабируемость, но не гарантирующий сходимость. Основной алгоритм в нашей статье — ALS (Alternating Least Squares), который также выполняет градиентный спуск. Его особенность состоит в том, что каждая итерация спуска происходит в два этапа (частное дифференцирование с поочередной фиксацией матриц факторов пользователей и фильмов) и гарантирует плавную сходимость.

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

Теперь исходная матрица P_ui — это бинарная матрица фактов просмотра контента, а дополнительная матрица C_ui — это уровень доверия факту просмотра. Плюс L2 регуляризация.

Ключевой момент здесь — расчет матрицы уровней доверия C_ui. В простейшем случае он выполняется по формуле C_ui = 1 + αR_ui, где R_ui — исходная матрица с процентами досмотра, α — эмпирически подбираемый коэффициент. Авторы публикации рекомендуют проводить эксперименты с преобразованием имеющихся данных в уровень доверия. В ходе дальнейшей оптимизации гиперпараметров в формулу расчета была добавлена нелинейность и ещё один оптимизационный параметр. Подробнее об этом мы расскажем в соответствующем разделе статьи.

Учитывая, что сложно реализовывать подобные алгоритмы, способные переработать наш «очень большой» объем данных, мы используем готовую реализацию Apache Spark ALS (как и всю платформу в целом).

С алгоритмами разобрались, можно углубиться в разбор непосредственно реализации.

Hard&Soft

В нашей команде основной язык программирования — Python. Некоторые шаги data pipeline реализованы на Scala в угоду скорости работы на платформе Apache Spark. Для исследований используется Jupyter Notebook. Расчеты производятся, очевидно, тоже на Apache Spark. Базы данных: MongoDB и MySQL.

Все исходные данные собираются и хранятся на in-house серверах в датацентрах Megogo. На них же работает API, раздающий пользователям предварительно рассчитанные рекомендации. Работает API на стандартном стеке: Python, Flask, MongoDB, Memcached, NGINX.

Исследования, разработка и тренировка моделей, запуск production data pipeline производятся на AWS EC2 серверах. Данные, необходимые для расчета моделей, хранятся на AWS S3. Обмен данными между корпоративными подсетями и серверами на AWS производится по защищенным туннелям.

Сырые данные

Нам сильно повезло в том, что система трекинга WatchStat начала свою работу задолго до того, как мы начали использовать собранные ею данные. Как следствие, в нашем распоряжении было «очень много» (мы и сами не знаем полный объем) исторических данных, собранных за несколько лет. Для любого Data Scientist это фантастический старт. Потому что мы сразу перепрыгнули мучительные этапы создания трекинговых систем, бесконечных исправлений багов и долгосрочного сбора первоначального объема данных с приемлемым качеством.

С другой стороны, данные были собраны в «очень много» гигабайт текстовых CSV, разбитых на две раздельные сущности, которые необходимо было объединить по ключу. Данные хранились на HDFS, и у наших бизнес-аналитиков была возможность работать с ними через Hadoop+Hive, но скорость обработки каждого запроса была крайне низкой. Поэтому было принято решение создать ETL (extract, transform, load) процессинг для извлечения из CSV полезных для нас данных и сохранения их в удобном для дальнейшего использования формате.

Исходные данные разбиты на ежесуточные архивы. Каждый архив состоит из:

• данных о сессиях (старты проигрывания видео), включающие в себя информацию о пользователе, видео-объекте, устройстве и другую мета-информацию;
• данных о тиках (периодические сигналы о том, что сессия проигрывания видео всё ещё активна), посчитав которые можно узнать фактическую продолжительность каждой сессии.

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

ETL

Этот этап состоит из извлечения и преобразования сырых данных в пригодный для дальнейшего использования формат.

Во-первых, с помощью Apache Spark один раз в сутки производится чтение и разбор информации из CSV формата. На этом шаге сырые данные из CSV:

• проходят предварительную очистку;
• сессии с информацией о начале просмотра видео и событиях продолжения просмотра соединяются в единый датасет;
• по идентификатору сессии записи группируются;
• производится ряд манипуляций для получения последовательностей событий в рамках каждой сессии;
• самое главное: производится расчет длительности сессии и «процент досмотра», который используется для работы рекомендательного алгоритма ALS;
• записываются на S3 в Parquet-формате.

Таким образом мы получаем посуточную статистику в интересующем нас формате.

Далее мы берем рассчитанную статистику за длительный период и конвертируем в формат входных данных для алгоритма Spark ALS. По-факту, мы рассчитываем три модели, используя различные промежутки исторических данных (суммарно за 14 месяцев) и на одном из финальных этапов делаем микс результатов. Но подробнее об этом позже.

Стоит отметить, что этап ETL практически линейно масштабируется при увеличении количества процессорных ядер, доступных Apache Spark. Первоначально преобразования выполнялись скриптом на Python. Это влекло за собой необходимость сериализации и передачи данных между Spark и Python-процессами, которые занимались фактической обработкой данных. Несмотря на то, что скорость работы была приемлемой, было очевидно, что процесс можно значительно ускорить. Поэтому задача для Spark была переписана на Scala, что сразу дало прирост скорости выполнения в 2-3раза на тех же вычислительных ресурсах.

Предварительный анализ данных

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

Перед тем как создавать модель, необходимо понять данные, с которыми мы будем работать. Все исследования производятся в Jupyter Notebook, интегрированными с Apache Spark. Основная цель — выяснить качество данных и на раннем этапе выявить мусор, пропуски и аномальные выбросы. К примеру, попадаются сессии просмотра продолжительностью целые сутки. Есть зрители, высматривающие сотни видео за месяц, и данные о них превращаются в белый шум. Часто в случае сбоя проигрывателя стартует новая сессия просмотра и с точки зрения нашей системы получается два просмотра с низким процентом досмотра.

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

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

Метрики качества рекомендаций

На данный момент у нас нет полноценной возможности проведения А/Б тестирования. Как следствие, мы вынуждены опираться исключительно на оффлайн-метрики качества. У нас их пять:

• MAP@10 — самая жесткая метрика, отражающая точность попадания рекомендаций в видимую область рекомендательной ленты;
• MAP@50 — точность попадания в рамках всей рекомендательной ленты;
• процент пользователей, для которых было хотя бы одно попадание рекомендаций;
• процент каталога контента, предложенного в рекомендациях.

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

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

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

Тренировка модели на базе алгоритма ALS

Мы собрали данные и определились с метриками. Наконец можно рассчитать рекомендации.

Используя классический подход ML, из имеющегося объема данных мы удаляем всех пользователей, у которых меньше 2 просмотров, и разбиваем датасет на две части: тренировочную и проверочную. Конечно, можно использовать технику cross-validation, но учитывая, что один просчет ALS алгоритма даже на очень серьезном железе может занимать несколько часов, для базовых экспериментов мы решили ограничиться разбиением выборки на две.

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

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

Поиск оптимальных значений гиперпараметров

У алгоритма ALSесть несколько важных для нас параметров:

• rank — количество факторов (об этом шла речь в математической части статьи);
• maxIter — количество итераций (напоминаем, что алгоритм у нас итеративный — градиентный спуск);
• alpha — эмпирический коэффициент, влияющий на расчет степени доверия (которая в нашем случае считается на основании процента досмотра);
• regParam — коэффициент регуляризации, позволяющий управлять переобучением модели.

Кроме того, в ходе исследований мы выяснили, что оригинальный процент досмотра не дает достаточного разделения результирующей степени доверия к просмотру между «скорее всего, нравится» и «скорее всего, не нравится». Например, средний процент досмотра хорошего фильма — 0,8-0,9;не интересного контента — 0,1-0,2.Использование только коэффициента alpha показало, что пользователи продолжают получать на верхних строчках рекомендации фильмов, которые они действительно смотрели, но процент досмотра крайне низкий. Говоря проще, ALS считал позитивными результатами всё, что насмотрел пользователь, несмотря на низкий процент досмотра.

Для решения этой проблемы были проведены эксперименты с исходными данными, в ходе которых мы выяснили, что наилучший результат обеспечивает возведение процента досмотра в степень от 2 до 3. Таким образом, начальная формула преобразования получила вид: C_ui = 1 + α(R_ui)^N, где N стал еще одним гиперпараметром модели.

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

Приведем несколько примеров зависимости значений выбранных метрик от гиперпараметров модели.

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

Здесь продемонстрировано аномальное поведение модели при небольшом значении alpha=1. Более привычно выглядит следующий график, который мы разберем подробно.

Единственное отличие этих экспериментов от предыдущих — в увеличенном значении alpha=10.

С ростом значения регуляризации происходит следующее:

• падение на 20% количества пользователей с совпадениями предсказаний и реальных просмотров на тренировочной выборке, но при этом незначительные изменения на проверочной выборке;
• падение на 0,08 значения метрики MAP@10 на тренировочной выборке и рост на 0,05 на проверочной выборке.

Эксперименты показывают, что оптимальное значение регуляризационного параметра равно 1,0.

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

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

На графике легко заметить рост точности на тренировочной выборке с 0,1 до 0,34 и процент пользователей с совпадениями с 66% до 93%. При этом для проверочной выборки точность растет с увеличением количества факторов до 20 и потом плавно падает. Это яркий пример процесса переобучения модели, который необходимо контролировать другими гиперпараметрами.

Поэтому мы фиксируем количество факторов 70, количество итераций 10, alpha=20 и пробуем подобрать необходимый уровень регуляризации.

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

Отдельно хотелось бы сказать об охвате каталога. Чтобы разместить значения метрики на графике, нам пришлось конвертировать абсолютные цифры количества контент-объектов в относительные.

В абсолютных значениях цифры выглядят примерно так:

• в худшем случае охват каталога не превышает 300 фильмов;
• в лучшем случаем — 4800 фильмов.

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

Что касается метрики MAP@10, то цифры такие:

• худшая модель — 0,012;
• лучшая модель — 0,050.

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

Подведение промежуточных итогов

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

Читайте также:Архитектура видеосервиса Megogo: варианты решений и переход от монолита к микросервисам

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

Говоря о рекрутинге как таковом, хочу отметить, что процесс и длительность найма в Америке значительно отличаются от штата к штату. К примеру, некоторые штаты (Северная Каролина, Массачусетс, Мэриленд и т. д.) стали стремительно развиваться в направлении информационных технологий только последние 5-7 лет,и рынок труда просто не успевает готовить или перепрофилировать достаточное количество квалифицированных специалистов. Как результат, работодатели сталкиваются с дефицитом кадров. В таких условиях опытному и грамотному специалисту найти работу не составит большого труда.

В этом плане Калифорния сильно отличается и стоит обособленно, поэтому большая часть моих наблюдений будет касаться именно ее.

Ниже привожу основные особенности, которые я наблюдаю, находясь по обе стороны баррикады (как кандидат и как рекрутер).

Выбирайте стартап, в идею которого вы сами верите

Калифорния в целом и Силиконовая долина, в частности, — это родина идейных стартапов. Стартапы создаются не для зарабатывания денег как самоцели, а как способ решения личных или бизнес-проблем. Например, основатели Airbnb не могли осилить аренду своей квартиры в Сан-Франциско и просто стали сдавать за деньги отремонтированный чердак. Так, они создали свой сайт, где опубликовали фотографии своего чердака с тремя надувными матрасами и опцией завтрака, который входил в стоимость — airbed&breakfast.

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

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

На мой взгляд, появление большого количества стартапов (только в 2017 году их прибавилось на 34 000) имеет очень положительный результат — здесь огромное множество вакансий. Статистикаговорит, что в 2018 году было опубликовано 2.8 млн IT-вакансий, так что есть из чего выбрать и опытный специалист, скорее всего, не будет чувствовать дефицита в изначальных предложениях рассмотреть вакансию.

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

Если говорить о языках программирования и провести параллели с украинским IT-рынком труда, бросается в глаза тот факт, что те тенденции, которые мы наблюдаем в Украине (см. рейтинг языков программированияна DOU) — прямое отражение того, что происходит в США. Это не удивительно, так как именно эта страна является «законодательницей мод». JavaScript и Java здесь также востребованы. Более детально о востребованных в США языках программирования можно почитать в этой статье. А еще можно ознакомиться с результатами исследованияпопулярных языков программирования, ежегодно проводящееся компанией GitHub.

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

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

Будьте готовы к высокой конкуренции и суровому отбору

Для того, чтобы выжить и преуспеть, стартапу крайне важно создать высокоэффективную и идейную команду, которая будет разделять его миссию и ценности. То есть, помимо сильных технических скиллов, кандидату важно обладать специфичным набором софт скиллов и личностных качеств. Многие из таких стартапов идут ещe дальше и фокусируются в своем поиске на A-players или, как принято говорить на просторах СНГ, топ-перформерах, массовая доля которых составляет коло 5-7%всего рынка.

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

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

Описание процесса отбора в американские технологичные стартапы заслуживает отдельной статьи. Если кратко — то помимо технического собеседования, вас, скорее всего, будут ожидать несколько этапов интервью с разными представителями компании. Начиная от менеджера команды и нескольких ее членов, и заканчивая топ-менеджментом. Например, в одном из стартапов из сферы здравоохранения у меня был телефонный звонок (pre-screen), затем собеседования с director of talent, VP of engineering, затем телефонное интервью с People Operations Manager (в Украине — это HR People Partner). А потом должны были быть собеседования с Chief People Officer и Chief Financial Officer.

Скорее всего, такой процесс будет сильно отличаться от найма в аутсорсинговую компанию, но продуктовые стартапы и в Украине придают большое значение не только техническим скиллам кандидата, но и его soft skills и ценностной системе. Соответственно, такое количество участников собеседования позволяет оценить кандидата под разными углами зрения и удостовериться в том, что он/она будет прекрасным culture fit. Об этом ниже.

Помните, что culture fit — критичное требование для стартапа

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

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

Для того, чтобы ознакомиться с ценностями компании, можно зайти в раздел About Us на сайте работодателя. Чтобы для себя понять, что ценности — это не пустое слово, стоит посмотреть, какие социальные инициативы берет на себя компания, как сотрудники отзываются и работе в ней (например, на Glassdoor) или пообщаться лично с несколькими сотрудниками.

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

Научитесь быть толерантным

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

Американские работодатели стремятся поддерживать такую атмосферу, где каждый человек будет чувствовать безопасность и принятие, вне зависимости от таких факторов, как пол, возраст, вес, сексуальная ориентация, этническое происхождение и пр. Для вас это будет означать одно — быть толерантным, гибким и открытым для взаимодействия с людьми разных рас, культур, взглядов на жизнь. Это значит, что надо забыть выражение «индусский код», «женщины — плохие программисты» и стереотип, что люди после 40 лет учатся медленнее. После огромного количества судебных исков, многие работодатели пересмотрели свои стратегии найма и ввели специальную должность Diversity Recruiter.

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

Здесь ценится life learning

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

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

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

Сегодня завершающая часть трилогии (предыдущие: Часть 1, Часть 2) о создании мультисервисного web-приложения на базе технологии Docker. В этой статье мы окончательно «сложим пазлы» в единую картину работающего приложения.

Уточним, что нам осталось сделать согласно постановки задачи:

1. Реализовать WebSocket сервер на http://localhost/ws; (используем Python-Sanic).
2. Написать простейший чат http://localhost/ (используя VueJs) который будет авторизироваться через http://localhost/api, реализованный в Части 2. Получим некий token, при помощи которого можно будет подключиться к чату на базе WebSocket-сервера из п. 1.

Этап 1. WebSocket server на Sanic

Небольшое отступление.Асинхронный фреймворк Sanic позволяет реализовать WS-сервер на базе созданного еще во 2-йчасти API. Я решил создать отдельный процесс, чтобы, с одной стороны, не смешивать код из разных частей статьи, с другой, чтобы наглядно продемонстрировать простоту микросервисной архитектуры.

Итак:

# Из корня проекта выполняем:
  mkdir ws

Добавляем файл ws/Dockerfile

FROM python:3.6.7-slim-stretch
WORKDIR /app
RUN apt-get update
RUN apt-get -y install gcc
COPY requirements.txt /tmp
RUN pip install -r /tmp/requirements.txt
VOLUME [ "/app" ]
EXPOSE 8000
CMD ["python", "run.py"]

Здесь мы «просим» docker создать нам контейнер, взяв за основу образ с python:3.6.7. Нужно доустановить в него некоторые системные библиотеки и необходимые для работы приложения python-пакеты из ws/requirements.txt:

# содержимое ws/requirements.txt
sanic
asyncio_redis

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

import os
from time import time
from sanic import Sanic
import ujson
import asyncio_redis
from websockets.exceptions import ConnectionClosed

app = Sanic('websocket')

conn = {}
CONN_CACHE_TIME = 10 # sec

@app.listener('before_server_start')
async def start(app, loop):
    app.redis = await asyncio_redis.Pool.create(host='redis', poolsize=10)


@app.listener('after_server_stop')
async def stop(app, loop):    
    app.redis.close()


async def check_token(request):
    token = request.args['token']   
    

async def checkTokenAlive(ws, token):
    if time() - conn.get(ws, 0) > CONN_CACHE_TIME:
        token_exists = await app.redis.exists(token)
        if token_exists:
            conn[ws]=time()            
        else:
            return False
    return True

@app.websocket('/')
async def feed(request, ws):                      
    token = request.args['token'].pop()
    if token:
        isAlive = await checkTokenAlive(ws, token)
        while isAlive:
            try:
                data = await ws.recv()            
                if data:                
                    if data=="/out":
                        await ws.close()
                    await ws.send(f'I\'ve received: {data}')                            
            except  ConnectionClosed:
                pass
            isAlive = await checkTokenAlive(ws, token)
    await ws.close()


if __name__ == "__main__":                
    debug_mode =  os.getenv('API_MODE', '') == 'dev'   

    app.run(
        host='0.0.0.0',
        port=8000,
        debug=debug_mode, 
        access_log=debug_mode
    )

В сервере предусмотрена периодическая (10 секунд) проверка token на «наличие» в Redis. Напомню, данный токен — это то, что получит наше SPA в случае успешной авторизации на localhost/api/v1.0/user/auth (реализация в Часть 2). Дополнительно реализована инструкция «/out» для самого чата, которая при отправке с клиента, закрывает текущее WebSocket-соединение.

Дополняем docker-compose.yml новым сервисом:

services:    
  ws: 
    container_name: test_ws
    build: 
      context: ./ws
    tty: true
    restart: always
    volumes: 
      - "./ws:/app"    
    links:      
      - "redis"     
    networks:      
      - internal
    env_file:
      - .env

Корректируем конфигурацию nginx сервера таким образом, чтобы все запросы, которые приходят на localhost/ws, проксировались к контейнеру «ws»:

services:    
       location /ws {            
        rewrite /ws$     /    break;  
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";        
        proxy_redirect     off;
        proxy_set_header   Host                 $host;
        proxy_set_header   X-Real-IP            $remote_addr;
        proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto    $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://ws:8000;
    }

Так как мы пишем SPA-приложение, работающее в браузере, нам необходимо получить самый что ни есть «классический» JavaScript, который гарантированно будет выполняться на подавляющем большинстве браузеров, установленных у пользователей. В силу очевидных причин, развитие JavaScript как языка программирования (ES5, ES6 и т. д.) сильно ушло вперед по сравнению с тем, что могут предложить существующие браузеры. По этой причине для того, чтобы воспользоваться всей мощью языка на клиенте, нам необходимо «преобразовать» наш «современный» синтаксис в («старый») понятный для браузера код.

Для этой цели как нельзя лучше подходит пакетный статический анализатор кода Webpack, к которому в качестве плагинов можно подключить конвертеры: Browserify, TypeScript, Sass, Less, css-minify, js-minify и многие другие, облегчающие web-разработку клиента. В общем случае — Webpack представляет собой демон (работающий процесс), который в зависимости от конфигурации отслеживает изменение кода и «налету» преобразовывает «удобный и современный» js-код в аналогичный по функционалу, но подходящий для работы в большинстве браузеров. В общем случае текст кода, который мы пишем, последовательно преобразовывается подключаемыми к демону плагинами и сохраняется в виде одного/двух файлов в директории /dist.

Настройка Webpack (установка и конфигурирование плагинов) — весьма муторное занятие, но существуют «утилиты-помощники», позволяющие выполнить эту затратную по времени операцию. Так как мы пишем фронтенд на VueJs, то в качестве такого «помощника» воспользуемся утилитой vue-cli, которая, кроме разворачивания Webpack, создаст базовое тестовое приложение на Vue, которое мы изменим под свои цели.

Этап 2. Создаем «SPA demo» при помощи vue-cli

Итак, нам нужно:

• запустить контейнер с Node (версии LTS 10.5);
• сгенерировать при помощи vue-cli demo-приложение;
• запустить его в контейнере;
• настроить маршрутизацию запросов сервера nginx.

Выполним из корня нашего проекта команды:

    # Переменной GID присваиваем идентификатор группы хост-машины
    echo "GID=$(id -g)" >> .env
    # Переменной GID присваиваем идентификатор текущего пользователя
    echo "UID=$(id -u)" >> .env

Cоздаем файл app/Dockerfile:

# За основу выбераем последний стабильный (LTS) образ версии Node
FROM node:10.15.0-alpine
WORKDIR /app
VOLUME ["/app"]
# инсталируем vue-cli согласно https://cli.vuejs.org/guide/installation.html
RUN npm install -g @vue/cli

В docker-compose.yml добавляем:

services:
  app:
    build: ./app
    tty: true
    user: "${UID}:${GID}"
    container_name: test_app
    volumes:
      - "./app:/app"
    networks:
    - internal    
    env_file:
      - .env

Хочу обратить внимание на 5-юстрочку в сервисе app. Предварительно мы сохранили в файл .env ID пользователя и группы хостмашины в силу особенности устройства ядра Linux. Даём указание docker запустить контейнер от лица этого юзера и группы. Это сделано для того, чтобы файлы, которые мы будем сейчас создавать внутри контейнера, можно было редактировать/создавать извне, то есть из хостмашины, не меняя владельца (chown) всех файлов.

Далее выполняем:

# из корня нашего проекта, перестраиваем и перезапускаем контейнеры
make upb
# или, если нравится традиционный способ, то:
docker-compose up -d --force-recreate --build

Мы запустили контейнер с Node версии 10.15.0, c предварительно установленным vue-cli.

Теперь:

  # подключаемся к sh-консоли работающего контейнера c Node  (в docker-compose его имя test_app)
docker exec -it test_app /bin/sh
# в консоли контейнера переходим в корневой каталог
cd /
# создаем demo приложение при помощи уже установленной во время создания контейнера vue-cli
vue create app
# Мастер, сообщаем что директория не пуста.. Выбираем "Merge"
# Затем в  меню "Manually select features" выбираем пакеты которые бы мы хотели установить для нашего приложения
# Выбираем нужные пакеты, я оставил:
# ◉ Babel
# ◉ Router
# ◉ CSS Pre-processors
# ◉ Linter / Formatter
# Далеее, на все вопросы установщика, можем соглашаться по умолчанию.
# В конце установки пакетов, мастер выдает сообщение
# $ cd app
# $ npm run serve

Выполнив последние 2 команды, мы увидим, что webpack по умолчанию запустился на 8080 порту.

Отключаемся от контейнера (Ctrl+С) и видим, что на хост-машине (ls -la app/ ) в папке фронтенда контейнер сгенерил «кучу» файлов, которые благодаря механизму Volumes, теперь являются общими для хост-машины и для контейнера. Самое интересное здесь то, что благодаря GID и UID сгенеренные из контейнера файлы принадлежат текущему юзеру host-машины, хотя внутри контейнера юзер имеет другое имя. Более исчерпывающую информацию о пользователях/группах в контейнерах можно почерпнуть здесь.

Так как у нас уже есть готовый рабочий код, все, что нам осталось сделать, — это подправить наш app/Dockerfile таким образом, чтобы контейнер при запуске выполнял команду запуска демона, то есть npm run serve.

# окончательный вид app/Dockerfile
FROM node:10.15.0-alpine
RUN apk add --no-cache bash
RUN npm install -g @vue/cli
WORKDIR /app
VOLUME ["/app"]
RUN npm install 
EXPOSE 8080
CMD ["npm", "run", "serve"]

Этап 2.1. Настраиваем nginx для vue-приложения

В конец конфигурационного файла nginx/server.conf вставим:

location / {                    
        rewrite /(.*) /$1  break;          
        proxy_redirect     off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header   Host                 $host;
        proxy_set_header   X-Real-IP            $remote_addr;
        proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto    $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://app:8080;
    }

Теперь перезапускаем все созданные контейнеры:

make upb

и заходим на http://localhost. Должны увидеть demo-страницу vue.

Важно! Demo-приложение, которое генерит vue-cli, по умолчанию для mode dev подключает интегрированный плагин vue-hot-reload-api, который через WebSocket-соединение «узнает» от демона webpack об изменениях на сервере и автоматически перезагружает страницу приложения в браузере, подтягивая новые данные. По этой причине, в конфигурации nginx, заложена поддержка проксирования WebSocket-заголовков.

  # Если нужно видеть вывод консоли работающего WebPack, 
  # цепляемся к контейнеру командой
docker attach test_app

Этап 2.2. Пишем клиентское приложение

Немного поговорим о том, как будет работать наш SPA-клиент:

1. При заходе на localhost проверяем, есть ли в localStorage значение для ключа «token». Если есть, пробуем установить WebSocket-соединение с ws://localhost/ws?token=xxx с сервером. Если сервер закрыл соединение (token отсутствует в redis), сбрасываем приложение на страницу /login.
2. На странице /login находится форма авторизации, которая отправляет данные на api (http://localhost/api/v1.0/user/auth), и в случае успеха сохраняет token в localStorage с последующим редиректом на главную.
3. В случае неудачной авторизации, отрисовываем повторно форму авторизации с отображением ошибки валидации.

К сожалению, объем кода SPA-приложения довольно большой, что неминуемо приведет к тому, что объем статьи будет огромный. Все изменения кода в этой статье, я выполнил в отдельной ветке на GitHub. Их можно посмотреть в виде pull request, которые я выполнил по сравнению с состоянием кода по окончании 2-йчасти.

Итоговый результат

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

  cd ~
git clone git@github.com:v-kolesov/vue-sanic-spa.git
cd vue-sanic-spa
docker-compose up  -d

После запуска всех контейнеров в браузере вбейте http://localhost. Вы должны увидеть, нечто похожее. В моем случае, в правом нижнем углу — 2 терминала, которые подключены непосредственно к контейнерам test_app, test_ws (нужно в целях отладки и дебагинга).

Читайте также:

Создаем приложение: Docker, VueJs и Python-Sanic. Часть 1

Создаем приложение: Docker, VueJs и Python-Sanic. Часть 2

Мене звати Сергій Тятін, я в IT більше 20 років. За цей час адмінив юнікс-сервери, паяв і дизайнив залізо, створював продукти, був хакером, займався геймдевом і мобільною розробкою, стартапами, а зараз працюю програмістом на enterprise-проектах. Сьогодні я хотів би розказати про те, як починав розбиратися з Machine learning, а саме зі сферою Computer Vision. І в результаті створив систему, яка визначає швидкість пропускання авто зеленим коридором на кордоні з Польщею.

Ідея

Моє захоплення комп’ютерним зором розпочалося із статті на Хабрі «Нейрореволюция в головах и сёлах». Світ змінився, системи комп’ютерного зору можуть в ріалтаймі розпізнавати об’єкти на відео, і це на звичайному залізі! Відрізняти стовп від пішохода, тротуар, розмітку на відео, знятому камерою в авто. Можливості вражають, і водночас ці технології доступні.

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

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

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

У мене виникла ідея використати Computer Vision для підрахунку машин, які перетинають кордон. Це не мало би бути складно, і було би корисно.

Камера на кордоні

Реалізація

Мої очікування щодо складності були на рівні написання «hello world» у новій мові. Вибираю готовий інструмент, читаю рідмі і налаштовую для використання. Реальність виявилася значно суворішою. Рішення оформлені у вигляді pdf-документів, де самі формули, і без підготовки туди ніяк.

Єдиним готовим інструментом, який мені вдалось знайти був YOLO. Це феймворк для створення систем комп’ютерного зору. Проста інсталяція, працююче демо, саме те, що треба. Git clone, make, додатково скачати файл, і YOLO вже розпізнає мене як людину на зображенні з камери ноутбука.

Розпізнавання зображення з камери ноутбука

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

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

Ситуація нагадала мені програмування на PHP на початку 2000-х.Документація з PHP закачана локально у вигляді великого HTML-файлу. В документації переважно перелік аргументів функцій без опису і прикладів. Інтернет повільний, і майже нічого не знайдеш. Як робити — незрозуміло.

Зробити «hello world» не вийшло, і я відклав цю справу. Але бажання зробити залишилось. Час від часу я повертався до цього питання і нарешті знайшов статтю з дієвим описом тренування нейронної мережі — «How to train YOLOv2 to detect custom objects».

Мені вдалося успішно повторити описані кроки — натренувати на зображеннях, зазначених у статті. Крім того, автор пояснив, як розуміти, чи процес тренування проходить успішно чи ні. І до того ж з’явився інструмент Yolo_mark, створений для розмітки зображень спеціально для Yolo. Можна було братися до зображень з камери на кордоні.

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

Зображення підготовлене для розмітки

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

Розмічене зображення

Запустив тренування. За годину побачив, що мережа навчається, і продовжив тренування на добу.

Для тренування було використано:

• 481 зображення для тренування;
• 48 тестових зображень;
• GeForce GTX 1070.

Навчена мережа точно бачила авто, навіть за стовпом і вночі. Я був приємно вражений.

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

Що для цього треба:

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

Хоча Yolo написано на C, цей фреймворк також може бути використаний як бібліотека в Python. Отже, весь процессінг зображень було розроблено на Python, благо він для цього чудово пасує.

Відеострім без проблем зчитується за допомогою бібліотеки Machine Learning CV2. Підрахунок машин виконується простим алгоритмом, розробленим «на колінці»: відслідковуємо, як рухається, коли зникло в зоні виходу і якщо нема деякий час, то +1 в базу даних (Firebase).

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

З малюванням рамок знов допомагає CV2, а ось зі стрімінгом на YouTube було непросто. Довго шукав, який мені треба інструмент, пробував різні варіанти, і все ніяк. YouTube був досить скупий на підказки, що йому не подобається. Просто казав, що нема стріму. Вдалось налаштувати FFmpeg, аби подружитися з YouTube Live.

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

Результат

Що вийшло можна побачити тут: https://carcount.github.io.Це статична сторінка, на яку дані зчитуються із Firebase. Відображається миттєва швидкість пропускання авто зеленим коридором. Графік швидкості за сьогодні і за вчора, а також YouTube Live із відміченими авто. Бекенд працює на майнінг фермі, навантаження на GPU зовсім непомітне (на CPU це не працює в realtime).

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

На реалізацію проекту я витратив приблизно тиждень, але це все розтягнулося майже на рік. Було би цікаво знайти інші сфери для використання Machine Learning і Computer Vision.

Які навички потрібно розвивати, щоб претендувати на роль Senior PHP Developer? Чи відрізняються вимоги в Україні та Каліфорнії, яка є Меккою програмування?

Щоб з’ясувати це, я проаналізував 100% відкритих вакансій на DOU в Україні та LinkedIn в Каліфорнії. На мої радари потрапили серед інших вакансії компаній Facebook та Dell. Для кожної технології було підраховано відсоток вакансій, у яких вона вказана як обов’язкова, і окремо як «бажана, але не обов’язкова».

Картина в Україні та Каліфорнії багато в чому схожа, але прослідковується низка відмінностей. Щоб можна було побачити «розклад сил» наочно, Ігор Яновськийстворив для нас інтерактивний віджет.

Англійська мова вирішує

Знання англійської мови в Україні вказується в більшості вакансій та поступається лише MySQL та JavaScript. Ясно, що без MySQL PHP-розробника бути не може. Відсоток англійської, співставний з MySQL, показує, яку роль відіграють іноземні замовники, та розвіює міф про роботу пехапешників на внутрішній ринок.

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

Я звернувся до альтернативного зарплатного віджету, щоб побачити різницю в компенсації залежно від рівня англійської для Senior PHP-розробника. Вона колосальна.

Pre-Intermediate& Intermediate — 79 анкет, середня компенсація 3 036доларів США після податків.

Upper-Intermediate — 45 анкет, 3 361 долар.

Advanced — 12 анкет, 3 791 долар.

Небажання вчитись та підтягнути свій рівень до Advanced коштує (3 791 — 3.036) x 12 = 9 060 доларів на рік.

Не знаннями єдиними: Soft Skills

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

Але які конкретно вимоги стоять за узагальненим формулюванням «soft skills»?

Dell: «Excellent written and verbal communications skills — communicate to engineers, managers, and senior leadership».

Ciklum: «Ability to relate positively to and engage with a wide range of people».

DevBranch (Луцьк): «You are a strong team player with very good communication skills».

Фреймворки: є явні лідери

Symfonyта Laravelє абсолютними лідерами серед фреймворків. Для Symfony в Україні часто конкретизують версію, і видно, що найпопулярнішою є Symfony 3.

Розповсюджені в Каліфорнії CodeIgniterта CakePHP — це фреймворки епохи фараонів Єгипту. В Україні лише в 1 вакансії як as a plus було згадано Kohana, що є відгалуженням CodeIgniter. Те, що ми не отримуємо такі проекти на аутсорсинг, може свідчити про відсутність актуальних проектів на цих технологіях. Можливо, їх вказують у вакансіях, щоб дати шанс розробникам, що загубилися в часі.

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

А от майже відсутність російського Yii, який є повноцінним фреймворком, свідчить про його непотрібність в Україні. Yii є дуже популярним в Росії, але, як ми бачимо, не в нас.

Що буде плюсом?

Плюсом для кандидата найчастіше є знання Docker, NoSQL та AWS, а також Python та Node.js.

Amazon Web Servicesскладно назвати бездоганним рішенням. Наприклад, AWS може віддавати помилку без жодного інформативного коду, назви чи опису. Але існуючи з 2006 року, має історично-обумовлені сильні позиції.

Концепція NoSQLлежить в основі таких технологій, як MongoDB, Redis та Memcached. Розуміння принципу NoSQL відкриває можливість опанування будь-якої з NoSQL-технологій. Їх тільки як вагомі Вікіпедіяназиває 45. Серед них є як технології персистентності, так і засоби кешування в оперативній пам’яті.

Існує термін LAMP Developer. У цій абревіатурі перші три літери мають сталу розшифровку: Linux, Apache, MySQL. Але остання символізує відразу 3 мови програмування: PHP, Python та Perl. Вони розглядаються як ідеологічно близькі та взаємозамінні, і в Америці є нормальною практикою залежно від задачі переключатись з PHP на Python, залишаючись при цьому LAMP-розробником. Саме з цим пов’язана висока частка побажань знати Python, хоча вимагати цього ніхто не стане.

Особливості України

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

Хоча російський сервер Nginxв Україні вказують частіше, перевага більш старої технології Apacheв Каліфорнії вказує на те, що є сенс її вчити.

Continuous Integrationта Unit Testsна масштабному проекті критичні. Але у нас ці знання нерідко бувають terra incognita навіть для досвідченого PHP-розробника. Раніше на DOU виходила статтяпро досвід впровадження Continuous Integration в PHP-проекті та статтяпро PHPUnit.

SOLIDвимагають 14% вакансій в Україні, але жодна в Каліфорнії. Про українську любов до SOLID цікаво писав у своїй статтіОлександр Скакунов, що повернувся з Данії: «Каждую букву из слова „SOLID“ мы использовали на практике, но расшифровывать аббревиатуры и именовать виды полиморфизма — seriously?»

В Україні люблять вказувати багато конкретики у вимогах, тоді як на Заході домінує думка, що є багато таких речей, які за потреби здібній людині буде нескладно вивчити. Ніхто не скаже «Не Redis-эксперт да не войдёт!».

Цікавинки, знайдені у вакансіях

Компанії Synergeticaта Teamworkпропонують у Києві компенсацію до $5 000.

Низка вакансій передбачають відрядження: до Берліна, Мюнхена та Чикаго.

Дуже відверто розповідаєпро свій проект компанія 12go.asia: «У нас сложный код, который писали разные разработчики, тестами не покрыт, не используются ООП, фреймворки».

Думки технічних експертів

Владислав Щербина, Senior Software Engineer в Adobe, Лос-Анджелес

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

По стеку, по моему мнению, нужен опыт работы с одним из распространенных фреймворков и глубокое понимание его структуры и работы, умение воспроизвести его компоненты, опыт работы с MV* паттернами. Также досконально знать одну из популярных реляционных БД (MySQL, PostgreSQL) и опыт тюнинга запросов, опыт работы и знания noSQL-решений (какие типы бывают и для чего используются). Конечно, нужно хорошо знать и применять на практике разные парадигмы программирования там, где это уместно.

Знать JavaScript помимо PHP. Чистый JS сейчас уже практически не встречается, обычно в навесок идет фреймворк, поэтому знать, как современные JS-фреймворки работают, нужно. Контейнеризация давно уже не в новинку и используется в проектах командами, поэтому пользоваться Docker надо уметь. Умение работать в UNIX-системах и знание bash — это то, без чего не обойтись. Уметь правильно определять границы сервисов.

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

Нужно уметь писать тесты, используя PHPUnit. Знать про существование разных типов тестов, selenium. Нужно уметь пользоваться разного рода вспомогательными тулами: XDebug, Blackfire (или XHProf). Уметь правильно писать и читать логи. Знать о существовании стандартов PHP, внедрять в проектах. Не везде, но нужно умение писать технический дизайн. Нужно уметь доносить свое видение. Умение разбить задачи и уточнить требования так, чтобы попадать в эстимейт. Уметь интегрировать решение с различными системами.

Александр Тумановский, Tech Lead в Beetroot

PHP-сеньор должен понимать конечную цель использования того или иного пакета, фреймворка или части фреймворка, чтобы выбрать оптимальное решение. Для этого очень важно уметь задавать вопрос «зачем?». И в первую очередь задавать его самому себе: «Почему я выбираю именно это решение поставленной задачи?», «Является ли это решение самым оптимальным?», «А правильно ли само требование, которое я пытаюсь решить?».

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

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

Александр Скакунов, Senior Software Engineer в Perfectial

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

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

Усім привіт! Мене звати Дмитро Лопушанський, мені 16 років. Я — МАНівець і учень 11 класу СЗШ № 8 м. Львова з поглибленим вивченням німецької мови. Займаюся програмуванням майже 3 роки і за цей час створив уже декілька проектів. Зараз розвиваю NewsKit — чат-бот у Telegram, який надсилає добірку свіжих фільтрованих новин у зручний час з обраних новинних веб-сайтів.

Ідея

Під час навчання в IT-школі GoITeens на курсах Back-End та Front-End розробки 1 рік тому в мене з’явилася ідея створити помічника, який би сортував новини, які я люблю читати з цікавих мені сайтів. Я читаю переважно про нові гаджети, технології та ІТ-світ. Щоденне відвідування безлічі сайтів, які публікують цікаві новини на ці теми, стало вже моєю звичкою. Але постійний моніторинг новинних сайтів і блогів забирав багато часу. Часто траплялося так, що на цих веб-сайтах з’являлися зовсім недоречні або просто нецікаві статті. Тоді виникла ідея створити проект, який би вирішував цю проблему і допоміг багатьом іншим людям, які теж хотіли б читати всі найцікавіші для них новини з різних сайтів в одному місці.

Так виникла ідея NewsKit, і головною фішкою мого майбутнього проекту стала ідея фільтрації. Марк Ластовський, 16-річнийучень 11 класу Львівської академічної гімназії, з яким ми разом вчилися на IT-курсах, теж приєднався до проекту.

Марк Ластовський і Дмитро Лопушанський

NewsKit — чат-бот у Telegram, який надсилає добірку свіжих фільтрованих новин у зручний час з обраних новинних веб-сайтів.

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

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

Як працює бот

Спочатку користувач обирає мову спілкування, їх є поки що три: українська, російська та англійська, скоро стане доступна також німецька. Далі юзер має вибрати тематику новин, яка його цікавить (якщо цікавить щось особливе, то всі такі ключові слова можна одразу додати до свого переліку). Після цього обирається мова новин (мова статей, які надсилаються і які користувач може зрозуміти, новини не перекладаються). Потрібно також обрати сайти, з яких ви хочете читати новини. Наприкінці вибираєте час отримання новин. У звичайній версії NewsKit — це 9:00,12:00, 21:00, щогодини та одразу після публікації.

Цей бот буде також мати платну Premium-версію, яку ми випустимо вже незабаром. Детальніше про неї буде далі.

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

Фічі

Запросивши 2-хдрузів, можна отримувати новинні добірки в будь-яку годину. Можна вказати 07:21, 09:15, 22:10 — немає ніяких обмежень.

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

Теми

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

Або припустимо, що бухгалтеру важливо постійно відслідковувати останні зміни у чинному законодавстві. Достатньо зайти в NewsKit та обрати потрібні теми.

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

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

Premium-підписка

Зараз відбувається важлива розробка, яка стане основою платної Premium-підписки, яка буде коштувати 29 грн/міс. Це сортування та аналіз контенту соцмереж та платформи Telegram. Як це буде виглядати?

Багато людей підписані на велику кількість Telegram-каналів, Facebook-сторінок, які постійно «спамлять» стрічку. Проте відписуватися від них не хочеться, бо інколи трапляються цікаві пости. Що ж тоді можна буде зробити? Користувач з Premium-підпискою NewsKit зможе надіслати боту посилання на потрібні канали чи сторінки, і весь контент звідти почне аналізуватися. NewsKit надішле людині лише ті пости, які підійдуть їй за обраними темами і ключовими словами. Це значно зекономить час і полегшить життя.

Також Premium-підписка дасть можливість користувачам читати 70% новин офлайн, отримувати новини в особисто встановлений час та змінювати вигляд новинної підбірки (наприклад, отримувати одним повідомленням). Ціна є досить невеликою, тому всі, хто хоче підтримати розробників і кому подобається NewsKit, зможуть собі дозволити Premium :)

Реалізація

NewsKit ми розробляємо вже майже 1 рік. Бот написаний мовою Python 3. Ми використовуємо базу даних Postgres та бібліотеку psycopg2 для роботи з нею. На нинішньому етапі код NewsKit складається з чотирьох частин:

• bot.py — відповідає за роботу самого бота у Telegram. Відбувається постійна взаємодія з Telegram Bot Api. Програма отримує запити методом getUpdates і відповідає на них.
• parse.py — кожні 10 хв парсить всі сайти, які ми підтримуємо, визначає нові статті на цих сайтах, записує їх у базу даних та розсилає деяким користувачам (час отримання яких — «Одразу»).
• timesend.py — щохвилини перевіряє, кому потрібно надіслати новини, переводячи час отримання новин кожного користувача у локальний час (NewsKit підтримує різні часові зони, тому ми написали спеціальні функції, які визначають локальний час).
• app.py — наша Flask-аплікація для переадресації під час переходу на новинну статтю та форми для переадресації на оплату Premium-підписки.

Для парсингу статей використовуємо бібліотеку bs4, яка дозволяє швидко витягувати контент зі статичних сайтів. Зараз працюємо над додаванням підтримки динамічних сайтів, парсинг яких відбуватиметься через Selenium та Chrome webdriver. Сподіваємося незабаром додати можливість парсингу основних соцмереж (груп та профілів користувачів).

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

Premium-підписка реалізована через сервіс LiqPay.

Піар-кампанія

Над NewsKit ми працюємо вже майже рік, проте лише декілька тижнів тому ми почали активно розкручувати та поширювати бот.

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

Конкуренти

Ми вважаємо, що це додатки Flipboard, Google News, Apple News, Feedly, сайт ukr.net та RSS-стрічки. На ринку ботів та новинних асистентів нам вдалося знайти лише боти, які спеціалізуються суто на певному сайті (наприклад, TechCrunch асистент та бот ABC News). Вони не є прямими конкурентами, адже працюють лише в межах одного веб-ресурсу.

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

Але такі можливості має сайт ukr.net. Як NewsKit може конкурувати з українським медіагігантом? Персоналізація новин. Укрнет — це довга стрічка новин, розсортованих за тематикою. Прочитати всі новини, які пропонує укрнет до цікавих тем, неможливо, оскільки статей надто багато. NewsKit, залежно від поставленого ліміту, обиратиме головні новини і надсилатиме їх користувачеві, щоб той не лише не пропустив важливого, але й одночасно не був перенасичений хвилею новин (ми постійно покращуємо цей алгоритм).

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

Плани на майбутнє

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

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

Також думаємо над виходом з платформи Telegram та створенням сайту, звичайно, зі збереженням нашого функціоналу.
Плануємо монетизовувати проект через трафік, який ми спрямовуємо на новинні сайти, а також через Premium-підписку.

І насамкінець...

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

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

Можливі шляхи співпраці можна обговорити особисто з нами або ж командою /feedback безпосередньо в боті.

NewsKit доступний за посиланням: t.me/newskit_bot

Съемочная группа DOU Ревизоруже была в офисе Jooble осенью 2014 года (см. выпуск). С тех пор компания переехала в новый просторный офис, куда мы и направились.

Jooble — продуктовая компания, сервис которой с 2007 года помогает соискателям найти подходящие вакансии. Это поисковик, который находит вакансии на джоббордах, объявлениях, сайтах компаний и рекрутинговых агентств.

Сегодня сервис действует в 71 стране, при этом офис у Jooble один — в Киеве. Всего в компании работает 213 человек, 70 из которых — технические специалисты. Из них в офисе находятся 143 человека. Еще 70 работают удаленно.

В округе и поблизости

Прошлой осенью компания переехала в новый офис на 1–3этажи ТЦ «Шоколад» по адресу ул. Константиновская, 71, всего в 5 минутах ходьбы от станции метро «Тараса Шевченко». Для Jooble это уже пятый офис.

Цены на обед в районе демократичные, а перечень мест — исчерпывающий:

• «Подольский колорит», расположенный в здании ТЦ. Комплексный обед ≈ 60 грн.
• Ресторан Amarant — в минуте ходьбы от офиса. Комплексный обед ≈ 60 грн.
• В пяти минутах ходьбы от офиса находится «Буглама», где можно заказать бургер или шашлык за 100-120 грн.
• Пицца в Pizza Verona обойдется ≈ 120 грн.

Также пообедать можно в соседних Craft Café, «Введенской усадьбе» или кошерном ресторане «Таки Да». Иногда специалисты компании покупают что-нибудь в кулинарии «Сільпо» или магазине АТБ, которые находятся в том же ТЦ, что и офис.

Возле офиса есть две парковки: перед ТЦ и с внутренней стороны здания. Места на бесплатной парковке перед ТЦ занимают быстро, поэтому, чтобы гарантированно было где оставить машину, на работу нужно приехать в районе 8–9 утра.Во внутреннем дворике ТЦ всего 10 паркомест. Тем, кому удалось получить закрепленные за собой места, их оплачивает компания.

Рабочее пространство

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

В дизайне просматривается космическая тематика: часто встречается надпись «per aspera ad astra» («через тернии к звездам» на латыни). Митинг-румы, их в офисе 16, названы в честь планет и их спутников, а кладовки обозначены, как черные дыры. Возле рядов столов open space установлены экраны, на которые выводят цели на день и текущий результат работы команды.

В компании 8-часовойрабочий день. По словам представителей компании, время начала работы специалисты могут выбирать на свое усмотрение.

Количество квадратных метров на человека в рабочем помещении составляет 12 м² (по данным компании).

Отдых и вдохновение

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

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

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

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

В офисе не сортируют мусор, но принимают на утилизацию батарейки.

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

DOU Ревизор спрашивает

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

Сергей, QA Engineer, 4 года в компании:

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

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

Артём, Front-end Developer, 3,5 года в компании:

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

Дмитрий, Backend Developer, 4 года в компании:

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

Дмитрий, Head of IT Support, 4 года в компании:

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

Ну что, мы поехали дальше... А если вы хотите, чтобы DOU Ревизор приехал к вам, пишите нам — revisor@dou.ua

Мы катаемся по Украине в поисках самых креативных и нестандартных офисов ИТ-компаний. Вместе с нами вы сможете заглянуть за кулисы офисной жизни. Но решать, хороший этот офис или нет, будете только вы!

Следите за нами на Facebook — www.facebook.com/dourevisor

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

Фото: Леся Коверега.