[Дмитрий Зиновьев — Software Engineering Manager в EPAM, 11 лет в IT]

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

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

Цель мы выявили остается дело за малым: менеджер должен реализовать потребность бизнеса прогнозируемо в установленные рамки. В этом ему способствуют компетенции, которыми он владеет:

• Account Management (работа с клиентом, pre-selling, ...);
• General Management (умение построить организацию, делегирование и распределение обязанностей, ...);
• Project Management (риски, планирование, оценка, ...);
• People Management (работа с людьми неизбежна ;)
• Relationship Management (эффективная работа с заинтересованными лицами, ...);
• еще много разных Management навыков;
• хотя бы базовые Engineering практики и подходы;
• понимание бизнес-сегмента;
• понимание ICT сегмента, инструментов, технологий, практик, тенденций и инноваций (Digital Skills);
• персональные навыки (Soft Skills).

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

За основу возьмем среднестатистический ICT проект. На рынке есть проект от 1-3специалистов и заканчивая проектами в 100-150 специалистов.Пусть в нашем проект будет команда порядка 20 специалистов:

• Account Manager — играющий эпизодическую роль;
• Solution Architect — главный творец;
• Business Analyst — человек, делающий мир проще;
• UX/Visual Design Team — жизненно необходимы;
• Full-stack Development Team — нужны;
• QA Team — жизненно необходимы;
• DevOps Team — нужны.

С такой командой можно горы свернуть. Клиент будет представлен тоже несколькими заинтересованными лицами:

• Sponsor — CFO, принимающий судьбоносные решения в отношении проекта;
• Product Manager — идеи творец;
• Client’s XXX Department — какой-то отдел, который будет работать с нашим продуктом;
• 3rd Party Vendor — наш конкурент.

Ну и интерфейс взаимодействие этих сторон, картинка ниже:

Где же менеджер?

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

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

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

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

Конфликты в команде и роль менеджера

Команда укомплектована и приступает к работе сроком в 1 год. В такой замечательной социальной группе высока вероятность возникновения конфликтов:

Рассмотрим возможные очаги их возникновения:

• Поменялся CFO и в поисках вариантов сокращения издержек решает закрыть наш проект, так как не видит в нем рентабельности в обозримой перспективе.
• 3rd Party Vendor не соблюдает последовательность работ, необходимых для соблюдения сроков нашего проекта.
• Отсутствие прозрачности между заинтересованной стороной и проектной командой, клиент не понимает, чем занимается команда последние 3 месяца, за которые было уплачено X00.000 USD.
• Команда дизайнеров/тестировщиков не может найти общий язык с разработчиками.
• Back-end и front-end разработчики не могут договориться за контракт взаимодействия.
• Отдельно взятые люди конфликтуют между собой в команде.
• (можете добавлять свои ситуации).

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

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

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

• 5-10персональных встреч с людьми;
• 10-30запросов в чате или почте;
• большинство из вышеперечисленных взаимодействий ждут принятие решения от нас;
• отчетность перед вышестоящим руководством/клиентом;
• управление проектом(-ми);
• анализ и принятие стратегических решений в контексте вашего отдела/проекта;
• анализ возможных рисков: ухода людей, накладок, проектных рисков, ...
• личная жизнь: отношения, дети, возможные бытовые проблемы, ...
• ...

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

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

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

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

Что же делать: начать пить или изменить себя?

Для тех, кто все-таки решил инвестировать в персональный рост, следующая часть статьи.

Что способно повлиять на рост эмоционального интеллекта:

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

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

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

Эмпатия.Ставите ли вы себя на место оппонента? Пытаетесь ли вы понять его эмоции и потребности? Проявить чуткость и тактичность. Это действительно черта независимых и самодостаточных личностей, которым не нужно утверждаться за счет других людей. Что вы делаете, когда клиент приходит с запросом в середине проекта: пытаетесь найти обоюдный компромисс или говорите: «В Scrum’е не добавляют изменения во время спринта!»?

Язык тела.Проанализируйте, какие мета-сообщения вы передаете вашими жестами, позицией, интонацией и поведением? Умеете ли вы распознавать истинные намерения оппонента или руководствуетесь исключительно сообщением, которое он вам адресует? Представьте, что ваш проект претерпевает изменения ввиду смены CFO со стороны клиента. Люди взволнованы и терзают себя домыслами. Вам нужно успокоить команду. И здесь важную роль играет не сообщение, а то, как вы его доносите: растеряно с опущенными глазами в углу комнаты или с поднятой головой, стоя в середине комнаты, как лидер. Подумайте, не играете ли вы роль капитана корабля, который кричит команде «Все будет хорошо!», отплывая на спасательной шлюпке :)

Умение слушать.Я говорю не про активное слушание, а про действительно умение услышать истинные потребности людей. Представьте, что вы ведете проект продолжительностью в 3 года из 20 человек и 3-мяключевыми специалистами (guru). Что вы будете делать, если один из ключевых людей придет с мыслью, что ему не нравится на проекте? В голове сразу всплывет череда рисков и их последствий, и менеджер начнет осыпать золотом и благами специалиста. Хорошо ли это? Не думаю, так как подобные действия могут не соответствовать уровню компетенции специалиста. На самом деле причина подобных мыслей могла быть вызваны небольшим конфликтом в команде или отсутствием понимания целей проекта.

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

Также рекомендую ряд литературы на данную тему:

• Emotional Intelligence (Daniel Goleman);
• Emotional Intelligence 2.0 (Travis Bradberry & Jean Greaves);
• 7 навыков высокоэффективных людей (Стив Кови);
• Думай медленно... решай быстро (Даниел Канеман);
• Поток. Психология оптимального переживания (Михай Чиксентмихайи);
• How to Win Friends & Influence People (Dale Carnegie);
• Body Language (Allan Pease & Barbara Pease);
• Сила Воли (Келли Макгонигал);
• The Monk Who Sold His Ferrari (Robin S. Sharma);
• Everything is Negotiable (Gavin Kennedy);
• От хорошего к великому (Джим Коллинз);
• Стратегия голубого океана (В. Чан Ким, Рене Моборн).

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

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

1. Оборудование и его стоимость

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

Давайте посмотрим на цифры. Согласно журналу PCgamer.com, «большинство людей воспринимает мерцающий свет, как постоянное освещение при частоте мерцания 50-60раз в секунду, или герц». Чтобы добиться такого же естественного эффекта в компьютерной графике, эту цифру нужно перевести в FPS (кадры в секунду), необходимый допустимый минимум для VR-приложений 60 FPS. Но при этом, «...периферийным зрением мы очень хорошо определяем движение. Отчасти поэтому VR-шлемы, способные работать на периферийном зрении, используют частоту до 90 Гц.» (PCGamer.com«How many frames per second can the human eye really see?»).

Атман Бинсток, главный архитектор в компании Oculus, объясняет: «Долгое время требования к 3D-графике реального времени для ПК были умеренными, достаточно было обеспечить 30-60 FPS. VR превращает графику в проблему жесткого реального времени, так как видимым становится каждый пропущенный кадр. Постоянно отсутствующие кадры создают эффект дрожания и дискомфорт. В результате графические возможности становятся критическими для нейтрализации неожиданных системных недочетов или провалов производительности контента».

Не удивительно, что с такими требованиями мы имеем дело с самым современным оборудованием, из-за чего передовые клиенты платят огромные суммы за ПК, пригодный для работы с VR (по мнению Logical Increments: «Без компромиссов — самый мощный пользовательский ПК на рынке, подходящий для VR-игр, стримминга, редактирования видео 4K и 3D-моделирования и анимации, будет стоить $5300»).

2. Внешний и внутренний трекинг

При внешнем трекинге (Oculus Rift, HTC Vive, PS VR) сенсоры размещаются в разных углах комнаты, чтобы обеспечить полное покрытие и определить положение устройства по отношению к окружающей среде. В реальной жизни это означает, что нам нужно будет выделить комнату, которая будет оснащена необходимым количеством камер, компьютером и шлемом, чтобы вы могли погрузиться в виртуальную реальность. Какова вероятность, что эта установка будет использоваться в обычном доме? Очень низкая. Поэтому прогнозируемый объем разработки приложений для шлемов с внешним трекингом навряд ли достигнет уровней масс-маркета.

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

Одно из наших любимых устройств с внутренним трекингом — HoloLens. Это устройство смешанной реальности с 1 камерой глубины и 4 камерами для определения окружающей обстановки, которые помогают визуализировать окружающую среду с большей детализацией. Опция прозрачности дает возможность видеть окружающую обстановку, хотя и немного туманно. Тем не менее, пользователь получает преимущества погруженности автономного голографического устройства, и в то же время, возможность преодолеть неудобство, связанное с изолированностью, как в случае с VR-шлемом.

С HoloLens у нас произошла интересная история. Sigma разработала приложение Interio для помощи дизайнерам, архитекторам и организаторам мероприятий в визуализации интерьеров и создании общего впечатления от будущего оформления помещения. Мы представили это решение на выставке VR Sci Fest, которая прошла в Королевском технологическом институте в Стокгольме в мае. К сожалению, после дня работы на выставке, HoloLens нас покинул и восстановить его не удалось. Посмотрим правде в лицо: продолжительность работы и обслуживание устройства — это важный фактор. Хотя мы все еще имеем дело с бета-версией и комплектом разработчика, не с финальным розничным продуктом. И все же, необходима уверенность в том, что финальным продукт будет стабильным и надежным, оправдывая свою ценность за вложенные в него деньги.

3. Оптимальное использование ресурсов

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

Согласно CNet.com«Электроприборы с большей производительностью, большей скоростью передачи данных, более высоким качеством видео и гейминга, более ярким и детализированным экраном развиваются со скоростью закона Мура. Питающие их литий-ионные блоки батарей, не могут за ними угнаться. Не удивительно, что ресурс аккумулятора — самая частая жалоба пользователей смартфонов!»

Учитывая это, а также необходимое количество кадров в секунду, которое должно быть минимум 60 (обычно для мобильных игр требуется 30 кадров/с или меньше), довольно просто понять, что мобильный VR «сожрет» заряд батареи за пару часов. Эту проблему можно частично решить с помощью эффективного программного кода, разумного и согласованного дизайна приложения, и графических ресурсов. Другую часть проблемы нужно решать глобально на аппаратном уровне.

4. Взаимодействие с пользователем

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

И подумайте о самом дисплее. Большинство привыкло работать с довольно маленьким дисплеем — в среднем для ноутбуков около 15 дюймов. Тогда как виртуальная реальность превращает в дисплей все пространство вокруг вас. Файлы или окна (это все еще будут «окна»?) могут открываться вокруг вас или только одно окно перед глазами и такого размера, который будет удобен для работы с его содержимым.
Постепенно переходя к новым VR/AR-интерфейсам, мы несомненно примем новую парадигму пользовательского интерфейса и работы с ним.

5. Сценарии использования

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

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

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

Когда готовилась эта статья, наша команда Unity-разработчиков получила возможность протестировать ARKit, который скоро будет доступен в iOS 11. И они в полном восторге! Мы считаем, что нас ждет всплеск AR-разработки сразу же после выхода ARKit. Мы уже видим, что ARKit значительно упрощает создание AR-приложений, благодаря великолепному распознаванию поверхностей, не говоря уже о широкой базе пользователей айфонов, на которых будет доступна эта SDK.

Всем привет! Меня зовут Виктор, и я работаю менеджером проектов в компании Cogniance. Делюсь дюжиной интересных материалов по управлению проектом и продуктом в очередном выпуске PM Digest’a!

Project Management

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

Цитаты, которые заставляют задуматься, из одной классической книги по менеджменту — Managing by Henry Mintzberg.

Многие слышали о Теории ОграниченийЭлияху Голдратта (кто не слышал, обязательно ознакомьтесь). Evan Leybourn, которого мы помним по его докладам в Киеве на Agileee, раскрывает понятие теории гибких ограничений — Theory of Agile Constraints.

An Introduction to Continuous Integration, Delivery, and Deployment — «must know» for a modern software Project Manager.

Советыпо проведению встреч 1:1 от Стратоплана.

Эффективные практикипо разрешению конфликтов.

Во многих компаниях период летних performance review уже, наверное, прошел. Для тех, кому еще предстоит регулярный performance review цикл, будет очень кстати этот материал: как ставят цели в google с помощью инструмента OKR. Мастрид!

Почему известную нам из PMBOK’a область знаний Stakeholder Management стоит переименовать в Stakeholder Engagement? Ответы в видео.

Как меняется рольпроектного менеджера в Agile проектах?

Agile, Scrum и все такое

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

Серия статей (1, 2) от Натальи Трениной про Appreciative Inquiry. Что это — коучинговый прием, социальная технология или система взглядов?

Многие компании при найме выставляют едва ли не требование: to have an Agile Mindset. Что же конкретно подразумевается под этим словосочетанием — What Exactly is Agile Mindset.

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

Есть ли что-то в SAFe для небольших проектов, где всего одна или несколько команд, или для них достаточно Scrum? 6 практик SAFe для небольших команд.

State of Scrum Report 2017от Scrum Alliance. Несколько интересных фактов из отчета, базированного на ответах 2113 человек в 76 странах:

• 89% респондентов заявляют, что в их организации используется Scrum;
• при этом 58% заявляют, что waterfall-ные методы тоже присутствуют (ох уж эти 146%!);
• 66% используют 2-недельныеспринты, всего 4% — недельные, 23% — 3- или 4-недельные;
• 77% ответили, что размер их команды соответствует рекомендуемому — 5-9 человек,вполне достаточно для двух пицц;
• интересная статистика по техническим практикам: 74% используют Definition of Done (надеюсь, не как забытый богом документ в Confluence), 58% — автоматизированное тестирование, 57% — Continuous Integration. Больше половины ответивших (54%) рефакторят, когда нужно, по 35% ответивших используют TDD и Pair Programming. Не многие (15%) используют практику, хорошо описанную Gojko Adzic’ем — Specification by Example, и (как я думал, более меинстримовую) — BDD (Behavior Driven Development) — всего 12%.

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

Product Management

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

Паттерныв рассуждениях, которые создают неудачные продукты.

Великолепная методичкапо дизайн-мышлению от команды Wonderfull. Обязательна к прочтению всем продактам.

Product Managers: Who are these ‘mini-CEOs’ and what do they do?

Темная сторонапрофессии продакта.

Захотелось войти в профессию продакт менеджера? Четыревозможных сценария.

Metrics that Matter to Product Managers.

Fun

Когда вписались в долгострой-путешествие по просторам галактики. Звучит как рациональный выход:

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

Пусть релизы ваших проектов проходят успешно:

Минута из жизни Product Owner’a (taken from Alexey Krivitsky)

Conference Call bingo — каждый слышал эти 25 фраз на онлайн митингах:

← Предыдущий выпуск: PM дайджест #3.

Всем привет! В июле было много горячих новостей, и мы хотим поделиться ими в нашем дайджесте.

Предлагаем вашему вниманию новости о Active Storage, подборки статей о принципе SOLID, машинном обучении и искусственном интеллекте с использованием языка Ruby, дискуссию о масштабируемости Ruby on Rails, а также множественные туториалы и кейсы на тематику Ruby/Rails. Не забудьте проверить, какие конференции проходят осенью и что вас ждет на курсах по изучению Ruby/Ruby on Rails от RubyGarage.

Почитать

Серия из пяти статей, где каждому SOLID принципу посвящена отдельная статья и приводятся примеры, как можно использовать эти принципы в Ruby:

• [S]OLID — Single Responsibility Principle by example — принцип единственной ответственности.
• S[O]LID — Open/Closed Principle by example — принцип открытости/закрытости.
• SO[L]ID — Liskov Substitution Principle — принцип подстановки Барбары Лисков.
• SOL[I]D — Interface Segregation Principle — принцип разделения интерфейса.
• SOLI[D] — Dependency Inversion Principle — принцип инверсии зависимости.

How to test Rails app using Mocha JS and Chai JS ?— рекомендации, как интегрировать JavaScript-библиотеки Mocha JS и Chai JS в приложение Ruby on Rails для еще более качественного тестирования.

The Ultimate Guide to Blocks, Procs & Lambdas — из этого туториала вы узнаете, как работают блоки в Ruby, какая существует разница между procs и lambdas и об эффекте «замыкание», который возникает каждый раз, когда вы создаете блок.

Graphing Benchmark Results in Ruby — иногда результаты сравнительного теста сложно читать из-за большого количества данных. Самый лучший способ показать статистику производительности через графики.

Running feature specs with Capybara and Chrome headless — в виду того, что Chrome позволяет запуск браузера в среде без графического пользовательского интерфейса, поддержка PhantomJS перестала быть необходимой. Как настроить запуск feature specs с помощью Capybara и Chrome без GUI, читайте в туториале.

Ruby on Rails Code Audits: 8 Steps to Review Your App — чтобы приложение было качественным, стоит обратить внимание на чеклист по контрольной проверке кода приложения на Rails.

Подборка статей за июль от PracticalAI.io. Как интегрировать машинное обучение и искусственный интеллект в проекты по разработке программного обеспечения с использованием языка Ruby:

• Implementing Simple Classification using a Neural Network in Ruby — реализация простой классификации с помощью нейронной сети.
• How to debug and diagnose Machine Learning problems — тестирование и отладка созданных моделей.
• Implementing classification using a SVM in Ruby — реализация классификации с использованием Support vector machine (SVM).

How to get your Rails data into your React component with webpacker — гем webpacker — это простой способ использовать библиотеки JavaScript на Rails с применением собственных инструментов JS, таких как Yarn и Webpack. В туториале вы найдете решение, как передать данные Rails в компонент React с помощью webpacker.

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

How to safely store API keys in Rails apps — советы, как безопасно хранить API ключи в Rails приложениях, автор рассматривает все за и против каждого из подходов.

nil?, empty?, blank? in Ruby on Rails — what’s the difference actually?— знаете ли вы разницу между методами ‘nil?’, ‘empty?’, ‘blank?’, ‘present?’? Это стандартные методы Ruby или они включены в Rails? В статье предлагается разобраться, какие методы и когда необходимо использовать.

How to quickly add graphs and charts to Rails app — статья о том, как быстро визуализировать данные в приложении Rails с помощью Google Charts.

Two Tests You Should Run Against Your Ruby Project Now — для вас важны безопасность и юзабилити проектов, над которыми вы работаете? В таком случае, узнавайте больше о тестах «Security audit» и «Licensing audit» для создаваемых Ruby приложений.

Споры о производительности фреймворка Rails не дают покоя сообществу RoR. Стоит ли выбирать фреймворк Ruby on Rails для разработки web-приложения или есть альтернативные варианты? Любые мнения имеют право на высказывание, лучше всего ознакомиться со всеми мнениями и принять самостоятельное решение:

• Is Ruby Too Slow For Web-Scale?— статья о масштабируемости Ruby on Rails и почему стоит выбрать этот фреймворк для создания веб-приложения.
• Rails Web-Scale is Expensive — взгляд на Rails с другой стороны и комментарии к предыдущей статье: да, RoR масштабируется, но в какой-то момент его использование обходится дорого.

A Few RSpec Helpful Hints — полезные советы, которые помогут упростить написание и чтение RSpec тестов и сэкономить время, которое тратится на исправление ошибок.

How I test Rails applications — если вы начинающий разработчик, эта статья о разных видах тестирования Rails приложений будет отличным гайдом. Автор делится лучшими практиками в тестировании, к которым он пришел за четыре года работы с RoR.

How to avoid inheritance in Ruby?— в статье описываются три варианта структурирования кода — inheritance, mixins и composition — узнайте, какой из них лучше подходит для вашего проекта.

Lint your Ruby code with Overcommit and static analysis tools — статические анализаторы кода помогают оптимизировать производительность и избегать проблем с безопасностью. Узнавайте в туториале, как с помощью git hooks контролировать качество кода для Ruby, RoR и Chef.

Implementing inheritance with params: CreateProducts < ActiveRecord::Migration[5.0] — из туториала вы узнаете, как выполнять наследование с параметрами и научитесь парочке интересных трюков в Ruby.

Fast CSV Report Generation with Postgres in Rails — альтернативные решения, как быстро сгенерировать пользовательские отчеты в формат CSV с помощью Postgres.

View Objects — The Way to Deal with Messy Rails Views — практические рекомендации почему стоит использовать подход View Objects.

Ruby concurrency: in praise of condition variables — статья из серии concurrency в Ruby, в статье рассказывается о проблемах consumer-producer и о том, как их изящно решать с помощью condition variables.

Lessons Learned Integrating Rust with Ruby — слайды презентации Daniel P. Clarkна митапе Rust DC, как лучше интегрировать Rust в Ruby.

Серия статей, как используя Vue.js frontend и Rails API в едином репозитории создать MVP приложение для книжного магазина:

• Rails 5.1 API with Vue.js frontend, part 0: stack choices — введение в серию, где объясняется выбор технологий для приложения.
• Rails 5.1 API with Vue.js frontend, part 1: Setting up a Rails API app — установка Rails приложения и настройка Rails API.
• Rails 5.1 API with Vue.js frontend, part 2: Modeling reality — моделирование структуры приложения.
• Rails 5.1 API with Vue.js frontend, part 3: API versioning — управление версиями API.
• Rails 5.1 API with Vue.js frontend, part 4: Authentication and authorization — настройка аутентификации и авторизации.

The battle for auditing and versioning in Rails — Audited vs Paper Trail — гемы Audited и Trail регистрируют все изменения в моделях Rails. Решить, какой гем подойдет лучше для решения ваших задач поможет сравнение с примерами их использования.

A Few RSpec Helpful Hints — пару полезных советов которые помогут вам писать более читабельные и поддерживаемые RSpec тесты.

When distributed locks might be helpful in Ruby on Rails application — автор описывает в статье, как определить, может ли ваше Ruby on Rails приложение столкнуться с проблемой параллелизма, и как ее решить с помощью distributed locks.

Preventing security issues in Ruby on Rails — чеклист по потенциальным проблемам безопасности RoR и как их предотвратить.

Realtime with React and Rails — на примере создания приложения карты реального времени, которое позволяет транслировать ваше местоположение, в туториале предлагается освоить, как работает Action Cable, и как использовать WebSockets для внедрения функционала реального времени в приложение Rails.

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

Is it always a good idea to split long methods into smaller ones? An experiment — эксперимент по разбивке длинных методов на части для того, чтобы повысить читаемость кода. Автор предлагает три способа, как это можно сделать лучше.

Streaming Data with Ruby Enumerators — потоковая передача позволяет эффективно обрабатывать большое количество данных. Но по сравнению с Node.js Stream API, где потоки могут быть легко скомпонованы, работа с потоковыми данными в Ruby с использованием блоков неудобна. В статье объединяются идеи из Node.js Streams с Ruby enumerables для создания композиционных потоков в Ruby, чтобы масштабировать обработку веб-канала до впечатляющих темпов.

В июле анонс David Heinemeier Hansson (DHH)о новой функции для Rails 5.2 мало кого оставил равнодушным. Active Storage упрощает загрузку и привязку файлов в облачных сервисах, таких как Amazon S3 или Google Cloud Storage, и прикрепляет эти файлы к Active Records. Он также предоставляет дисковый сервис для тестирования или локального развертывания, но основное внимание уделяется облачному хранилищу. Хотя еще рано делать выводы, первые отзывы уже есть:

• Upcoming built-in Upload Solution for Rails 5.2 (ActiveStorage) — общее впечатление об использовании ActiveStorage.
• Introduction to Active Storage — короткий туториал, как настроить Active Storage.

How I Reduced my DB Server Load by 80% — решение и рекомендации, как улучшить скорость загрузки сервера базы данных.

What skills should a junior Ruby on Rails developer have?— хотите стать достойным RoR разработчиком, или вы ищете подходящего программиста в свою команду? Проверьте чеклист навыков, которые следует иметь начинающему специалисту, чтобы не только создавать программное обеспечение, но и быть важной частью команды, оказывая влияние на продукт, который вы создаете.

Tips to improve speed of your test suite — в статье вы найдете лайвхаки, как улучшить скорость автотестов, чтобы в дальнейшем выиграть время при разработке.

Making iOS & Android apps with Rails & Turbolinks — базовый гайд, как с использованием Ruby on Rails и Turbolinks создать кроссплатформенное приложение под iOS и Android.

Scope the Monkey: Refinements in Ruby — советы, как уменьшить количество манки патчей с помощью Ruby refinements.

Rails on Docker: Getting Started with Docker and Ruby on Rails — Docker — это открытая платформа для разработки, доставки и эксплуатации приложений. В этом туториале вы найдете практические советы, как подготовить базовое приложение Rails для использования в контейнере Docker.

API v2 Architecture and Hanami — кейс, как сделать трансфер новой версии API с Rails на Hanami.

Rails has passed 100 million downloads on RubyGems — чудесная новость для поклонников RoR: количество загрузок Rails на RubyGems уже превышает количество в 100 миллионов.

Shopify @ 80,000 requests per second on Rails — все еще есть сомнения на счет масштабируемости RoR? David Heinemeier Hansson (DHH) думает иначе.

Послушать

Продолжение пятого сезона на канале RWpod. Подборка подкастов за июль:

• 26 выпуск 05 сезона. Rails 5.1.2, Unicorn Unix Magic Tricks, Small Is Big, Browser module loading, React Native UI Kitten и прочее
• 27 выпуск 05 сезона. Upload Solution for Rails 5.2 (ActiveStorage), Real World Rails Background Jobs, Gatsby, Rebass и прочее
• 28 выпуск 05 сезона. Is Ruby Too Slow For Web-Scale?, Redis 4.0 GA, NodeJS: Constant HashTable Seeds Vulnerability и прочее
• 29 выпуск 05 сезона. Monitor and Debug Bottlenecks in Sidekiq, Enclose.IO, RenderReact, Popmotion, GPU.js и прочее

The Bike Shed — канал, где ведущие и их гости обсуждают свой опыт разработки и все, что привлекает их внимание касательно мира Ruby, Rails и JavaScript. В июле обсуждения затрагивают тестирование, сообщества разработчиков, уроки, извлеченные из прошлых проектов, и выступления на конференциях:

• The Bike Shed #117: S.A.L.T. (Justin Searls)
• The Bike Shed #118: Nonsense In, Nonsense Out
• The Bike Shed #119: Questions Are For the Weak (Caleb Thompson & Matt Mongeau)

MRuby and Language Security with Daniel Bovensiepen — интервью Daniel Bovensiepen — основного разработчика MRuby. Daniel рассказывает о Shopify и MRuby — упрощенной версии языка Ruby.

Мир Ruby/Ruby on Rails полон удивительных и талантливых разработчиков. Благодаря подкастам Ruby Rogue — My Ruby Story мы имеем возможность познакомиться с ними поближе:

• Ruby Rogues: My Ruby Story #010 — Dave Kimura — поклонникам популярного Ruby on Rails скринкаста и блога Drifting Ruby будет интересно узнать больше о его создателе Dave Kimura.
• Ruby Rogues: My Ruby Story #011 — Greg Baugues — гость Greg Baugues, уже ранее выступал в подкастах Ruby Rogues. В этом выпуске Greg рассказывает свою историю знакомства с языком Ruby и опыте работы в компании Twilio.
• Ruby Rogues: My Ruby Story #012 — Simon Moro — в этом эпизоде гость Simon Moro расскажет о самостоятельном изучении Ruby и о своем предпринимательском опыте.

Подкасты Ruby Rogue за июль, касающиеся программирования и сообщества и Ruby:

• Ruby Rogues #317: Computer Science at University and the Future of Programming with Dave Thomas — интервью с Dave Thomas, автором нескольких книг по программированию. Автор подкаста и гость говорят о курсе компьютерных наук, который Dave ведет в университете, языке Elixir и будущем программирования.
• Ruby Rogues #318: Metaprogramming with Jordan Hudgens — обсуждение метапрограммирования с несколькими экспертами в этой сфере.
• Ruby Rogues #319: Machine Learning with Tyler Renelle — эпизод посвящен машинному обучению, где своим мнением и опытом поделятся несколько участников подкаста — Charles Max Wood, Dave Kimura и Tyler Renelle.
• Ruby Rogues #320: Shrine and File Uploads with Janko Mahronic — гость подкаста Janko Mahronic расскажет о Shrine — инструменте, который предоставляет множество способов загрузки файлов.

Посмотреть

Everything You Need to Know About Ruby Constants — скринкаст с подробным описанием о том, что нужно знать о константах Ruby.

The Ultimate Guide to Ruby Sorting — из этого скринкаста вы узнаете, как использовать методы sort и sort_by для сортировки массивов и хэшей в Ruby разными способами. Также вы узнаете о различиях производительности и способах выполнения алгоритма быстрой сортировки.

Drifting Ruby #89 Creating Custom Ruby on Rails Generators — генераторы Rails помогают упростить и отчасти автоматизировать workflow разработчика. С помощью этого руководства вы изучите, как создавать генераторы и настраивать существующие.

GORUCO 2017 — 24 июня в Нью-Йорке прошла конференция GORUCO, которая объединяет лучшие практики и опыт сообщества Ruby. Предлагаем к просмотру видеозапись с конференции. Также, на канале Confreaksможно просмотреть отдельные выступления спикеров.

Go Rails #198 Debugging Ruby: How to Interpret a Stacktrace — стек-трейс — это список методов, которые были вызваны до момента, когда в приложении произошло исключение. Скринкаст объяснит, как анализировать и понимать Ruby стек-трейс, когда что-то идет не так в вашем приложении.

Codemy School: Rails API — подборка обучающих видео о Rails API от CodemySchool.

Релизы и библиотеки

Новости о релизах и доработках Ruby on Rails в июле — выход Active Storage в Rails 5.2, предотвращение недопустимых PostgreSQL UUIDs, улучшения, исправления ошибок и многое другое:

• This Week in Rails: Active Storage, telling secrets and time travelling!
• New releases, bugfixes and more!
• Rails 5.0.5.rc2 and 5.1.3.rc2 have been released
• New releases, bugfixes and more than 30000 issues/PRs!

RubyInstaller 2.4.1-2 released — в июле вышло обновление RubyInstaller для Windows.

mruby 1.3.0 released — вышла новая версия MRuby, который является упрощенным вариантом языка Ruby.

Ruby-Compiler — досрочный выход компилятора для Ruby, который позволяет очень быстро скомпилировать любой проект.

Maily — это Rails Engine для управления, тестирования и навигации по всем вашим шаблонам электронной почты вашего приложения.

ActiveStorage — вот так теперь будем хранить файлы в Rails приложениях.

Kbsecret — это библиотека / утилита, которая предоставляет интерфейс управления для KBFS и Keybase.

Genkan — механизм аутентификации для Rails.

Graphql-guard — простая авторизация для graphql-ruby.

Crank-Starter — одностраничное приложение, вдохновленное Kickstarter. Ruby on Rails backend, React / Redux frontend.

Down — утилита для потоковой передачи, гибкой и безопасной загрузки удаленных файлов.

Data-Science-With-Ruby — практическая Data Science с инструментами на основе Ruby.

Книги

Релизы:

The Rails 5 Way (4th Edition) — 27 ноября ожидается выход четвертого издания The Rails 5 Way, которое входит в Addison-Wesley Professional Ruby Series. Предзаказ уже доступен.

Mastering Ruby Closures: A Guide to Blocks, Procs, and Lambdas — 25 декабря выходит первое издание книги Mastering Ruby Closures: A Guide to Blocks, Procs, and Lambdas.Уже можно делать предварительный заказ.

Рекомендации:

Introduction to Programming with Ruby — онлайн версия книги Introduction to Programming with Ruby — пошаговое введение в программирование Ruby от Launch School.

Курсы

Курсы по Ruby/Ruby on Rails от RubyGarage — в начале октября стартуют Ruby/Ruby on Rails курсы от RubyGarage для тех, кто хочет освоить профессию «Web-разработчик». Регистрация на курс открыта. Тестовые задания принимаются до 1 сентября.

События

Rails Girls Rzeszów — митап Rails Girls в этот раз пройдет с 16 по 17 сентября в городе Жешув, Польша. На сайте уже есть расписание. Ивент бесплатный, но не забудьте зарегистрироваться.

RailsClub Moscow 2017 — в Москве 23 сентября пройдет Ruby/Ruby on Rails конференция — RailsClub. Среди множества выступающих будут присутствовать Richard Schneeman, Piotr Solnica и Nick Sutterer!

EURUKO 2017 — с 20 по 30 сентября в Будапеште, Венгрия пройдет ежегодная европейская конференция EuRuKo 2017. Расписание уже составлено. Среди многочисленных спикеров выступают Yukihiro «Matz» Matsumoto — создатель языка Ruby и один из разработчиков JRuby Charles Nutter.

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

С 2011 года мы ведем рейтинг крупнейших ИТ-компаний Украины. Сначала это был ТОП-25, но с этого годаон превратился в ТОП-50. За первое полугодие ТОП-50 достиг докризисных темпов роста, в рейтинге появилось 3 новые ИТ-компании, а на смену политической нестабильности приходит конкуренция.

Но обо всем по порядку.

В первом полугодии 2017 количество специалистов в ТОП-50 выросло на 2 953 человека (+7%) и на 2 104 (+6,2%) в ТОП-25. Нынешний показатель является рекордным c 2014 года.

Расстановка сил в ТОП-5 осталась без изменений. Компания EPAM, лидер рейтинга, вновь нарастила темпы после небольшого спада в январе — 200 специалистов против 100 соответственно.

Компания SoftServe, которая за прошлый год показала рост свыше 500 специалистов, в январе-июле`17 выросла на 114 человек. В компании спад темпов роста связывают с тем, что их фокус в первом полугодии был направлен на зарубежные ДевЦентры. В начале года SoftServe поглотилпольскую компанию Coders Center, за счет этого было увеличено число зарубежных офисов, выросло количество вакансий в Польше и значительную их часть перераспределяли внутри компании.

Luxoft, третья крупнейшая ИТ-компания Украины, в феврале`17 купилааутсорсинговую компанию IntroPro (по состоянию на январь`17 она занимала 25 место рейтинга с общей численностью специалистов — 535). По данным Luxoft, процесс интеграции еще не завершён, окончательные данные с результатами слияния будут опубликованы в следующем рейтинге.

По результатам первого полугодия компания GlobalLogic, 4-еместо рейтинга, перешагнула отметку 3 000 специалистов. На 5-омместе — компания Ciklum, которая в январе-июле показала отрицательную динамику роста (-33 специалиста). По словам представителей компании, в первом полугодии они активно росли в других локациях, в частности, в Польше и Испании.

За второе полугодие абсолютные приросты свыше 150 человек показали семь компаний: Lucky Labs (+318 специалистов), EPAM и Gameloft (+200), GlobalLogic (+173), ELEKS (+168), Luxoft (+165), Infopulse (+152).

Значительный рост Lucky Labs связан с уточнением подсчета количества специалистов.

Лидером среди относительного прироста стала компания Gameloft (Lucky Labs мы не учитываем по причине, обозначенной выше). Компания выросла на 31% за счет развития и роста проектов. Более чем на 10% в первом полугодии увеличили количество специалистов: Intellias (+20%), Playtika (+17%), N-iX (+17%), ELEKS (+15%), EVOPLAY (+13%), Infopulse (+10%).

Графики составлены для компаний, которые более 4 раз попадали в рейтинг ТОП-25 (ТОП-50)

Лидер по относительному приросту прошлого рейтинга — Terrasoft — в январе-июле показал отрицательную динамику (-150 специалистов). По словам представителей компании, снижение связано с тем, что в рамках реализации вендорской стратегии Terrasoft выделила департамент интеграции в отдельную бизнес-структуру — компанию «ТС Интеграция». Ключевой сферой деятельности новой компании стало внедрение продуктов bpm’online и реализация CRM-проектов. Разделение двух направлений бизнеса позволит каждой команде сосредоточиться на своих целях.

Кроме Ciklum и Terrasoft снижение количества специалистов произошло в Lohika (-50), Playtechи Win Interactive LLC (-20), а также CoreValue (-14).

Во втором полугодии в ТОП-50 появились три новые компании: ZONE3000 (12 место), Oracle (30 место) и Depositphotos (37 место). По данным ZONE3000, большинство специалистов компании — это Customer Support, однако у них наблюдается активный рост команды разработчиков.

8 компаний из ТОП-50 открыли новые офисы

В январе-июле 8 из 43 ИТ-компаний открыли новые офисы разработки в Киеве, Львове, Одессе, а также в Польше, Беларуси, Германии, Испании, Малайзии и на Мальте.

Во втором полугодии компании планируют снизить темпы роста

46% опрошенных компаний планируют умеренный рост, до 50 специалистов, во втором полугодии. Активный рост, свыше 100 человек, в планах лишь у 17% компаний. В январе`17 активно расти планировали 34% компаний.

*за 100% взяты 43 компании из ТОП-50, которые приняли участие в опросе

Январские прогнозы ИТ-компаний частично сбылись: рост 100+ специалистов планировали 13 ИТ-компаний, а по факту выросли 11; 7 компаний из 10 выросли от 50 до 100 специалистов.

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

*за 100% взяты 43 компании из ТОП-50, которые приняли участие в опросе

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

В июле 26% опрошенных участников рейтинга выбрали политическую нестабильность среди причин, замедляющих рост компании. В январе`17 и июле`16 об этом негативном факторе говорили 36% и 58% компаний соответственно.

*за 100% взяты 43 компании из ТОП-50, которые приняли участие в опросе

В 2017 году компании впервые стали вспоминать о конкурентах (январь — 7%, июль — 12%). Впрочем, для ИТ-специалистов такая тенденция скорее плюс, чем минус.

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

[Про автора: Дмитро Чаплинськийзахоплюється питаннями штучного інтелекту, обробкою природної мови (NLP), нейронними мережами. Працює з «Канцелярською сотнею», яка розробляє проекти в сфері прозорості та протидії корупції. Один із засновників lang-uk — спільноти фахівців з комп’ютерної обробки україномовних текстів. Спікер багатьох конференцій, зокрема PyCon, AI Ukraine, AI&BigData Day]

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

Ще в 2011 році я проходив курс з Natural Language Processing, і вже тоді було зрозуміло, що існує досить серйозна теоретична та практична база для використання цих інструментів. Можна було витягати згадки про персон, зв’язки між ними і навіть емоційне забарвлення текстів. Але проблема полягала в тому, що ці можливості були доступні для англійської мови. Для української мови, на жаль, критично не вистачало даних.

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

Отже, весною 2016 року я запропонував своєму товаришу Всеволоду Дьомкіну, який на той момент займався NLP у Grammarly, об’єднати зусилля, щоб назбирати потрібну кількість даних та потім оприлюднити їх з відкритими ліцензіями. Всеволод написав маніфестнашої групи та запропонував назву lang-uk.

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

З Всеволодом Дьомкіним (праворуч) на AI Ukraine

Розробка повнотекстового пошуку

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

Я трохи опрацював словник БрУК, а мій колега Дмитро Гамбаль зробив на його засадах плагін для ElasticSearch, який дозволяє робити повнотекстовий пошук. Повнотекстовий — це з урахуванням словоформ. Наприклад, ви шукаєте «живОГО та легітимнОГО», а воно вам знаходить тексти де є «живИЙ та легітимнИЙ». Або шукаєте в закупівлях «яйця», а воно вам знаходить ще й закупівлі «яєць».

Потім з допомогою Андрія Рисіна, одного із засновників БрУК, було реалізовано подібний плагін для Lucene — пошукового ядра, яке використовується в ElasticSearch, Solr та інших пошуковиках. Цей плагін увійшов до офіційної поставки Lucene, починаючи з версії 6.2.0.

Таким чином, ми отримали повноцінний безкоштовний Open Source пошук українською мовою.

Можливість використовувати ці дані ми також надали до PyMorphy2, відкритої бібліотеки для обробки текстів на Python. Раніше там були дані тільки з російської мови, а тепер можна використовувати цей інструмент і для української: наприклад, робити словозміни чи визначати теги.

Про побудову інфраструктури обробки української мови

Побудова власних наборів даних

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

Згодом з допомогою Олександра Швеця отримали і обробили корпус законів та нормативно-правових актів. Його можна використовувати як джерело статистичної інформації, можна на ньому тренувати вектори слів, будувати моделі юридичної мови.

Зібрали перший відкритий корпус нотацій, або іменованих сутностей (named entity recognition), — це особи, організації та локації, про яких є згадки в тексті. Наприклад: «В Києві пройшло Євробачення, яке відкрила Джамала». Тут Київ — локація, Джамала — особа, Євробачення — організація. Ми тоді взяли корпус БрУК, який на той час мав обсяг 217 тис. слів, та запросили волонтерів вручну розмітити кожне речення, виділяючи в ньому іменовані сутності. Далі Всеволод обробив ці дані як редактор, перевірив на правильність, виправив механічні помилки. На цьому датасеті ми натренували моделі, щоб в подальшому розпізнавати нотації в українських текстах автоматично.

Для пошуку іменованих сутностей обрали бібліотеку MITIE. Ця бібліотека є відкритою, її ліцензія дозволяє безкоштовне використання навіть у комерційних проектах. MITIE забезпечує високу точність завдяки поєднанню звичних features для тексту та CCA embeddings. Хоч MITIE й написана на С++, вона також має інтерфейси для C, Python, Java та Matlab.

Про побудову іменованих сутностей для української мови

Ми також побудували модель для пошуку іменованих сутностей російською мовою, використовуючи анотований корпус, підготовлений організаторами конференції Dialogue 2016. Для обчислення CCA embeddings ми використовували корпус статей російської Вікіпедії.

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

З допомогою Олександра Маріковського та В’ячеслава Тихонова отримали словник емоційного забарвлення, де було розмічено, чи є слово позитивним чи негативним. Наприклад, «прекрасний», «вродливий», «сонячний», «радісний» — позитивні слова, а «поганий», «ганебний», «зрадний» — негативні. Всеволод опрацював цей словник, а Олесь Петрів та Сергій Шеховцов побудували нейромережеву модельдля його розширення. Натренували модель на початковому корпусі, а потім додавали нові слова та вручну корегували результати. Таким чином, словник виріс більше ніж вдвічі: з 1,5 тис. слів до 3,5 тис.

Створення інструментів

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

Корисна властивість векторів слів полягає в тому, що слова, які використовуються в однакових контекстах, отримають схожі вектори. Наприклад, слова «чоловік», «батько», «син», «парубок» будуть мати приблизно схожі значення, і кут між відповідними векторами буде невеликим. Це дозволяє використовувати Word Embeddings як перший ступінь для роботи штучного інтелекту з текстами, написаними природною мовою. Векторні репрезентації слів використовуються майже в усіх сучасних Deep Learning моделях. Саме за допомогою цього інструменту можливе, наприклад, користування Google Translate, спілкування з Siri, рекомендації контенту від Google Music або Netflix.

З допомогою Тетяни Кодлюк ми побудували набір тестів, щоб оцінювати якість векторів. Провели тестування приблизно 20 моделей з використанням різних алгоритмів і виявили ті, що показують найкращий результат.

Для перевірки якості є два методи: Intrinsic та Extrinsic. Перший — це набір синтетичних тестів, що дозволяє оцінювати загальну якість та отримувати на виході єдину метрику. Другий — це те, як конкретні Word Embeddings працюють у «великих» задачах. Наприклад, є задача оцінювати тональність текстів чи твітів, для котрої ви використовуєте вектори. Змінюючи те, як вони були згенеровані, ви можете оцінити, наскільки це вплине на кінцевий результат у вашій конкретній задачі. Ця метрика більш наближена до реального світу, але слід розуміти, що для різних задач можуть підходити різні вектори (наприклад, згенеровані з різних даних або різними алгоритмами).

Ми зосередились на методі Intrinsic. Підготовлений нами словник з 23971 запитань містить 12 основних тематик, які представленні такими відношеннями: теперішній час до минулого, країна до національності, країна до столиці, однина до множини, дієслово до іменника, антоніми та ін. Самі тести виглядають приблизно так:

• король відноситься до королеви як батько до ... (матері);
• Лондон відноситься до Англії як Рим до ... (Італії);
• стрункий відноситься до стрункіший як бідний до ... (бідніший).

Цей підхід називають Analogical Reasoning. Тетяна провела низку тестів на усіх моделях, що ми обчислили, та зробила підсумкову таблицю результатів. Тести, скрипти для їх запуску та результати доступні на GitHub.

Про прикладне використання Word Embeddings та LSTM

Отже, за час проекту ми побудували такі сервіси:

• Токенізація та лематизаціяз використанням можливостей бібліотеки nlp_uk;
• Розпізнавання іменованих сутностейукраїнською, російською та англійською;
• Розпізнавання мовиз використанням можливостей бібліотеки WILD.

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

Подальші плани

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

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

Всі результати нашої роботи розміщені на GitHub.

Ми завжди відкриті до приєднання нових учасників для роботи над поточними проектами та потенційними новими напрямками.

[В серії «Огляд IT-ринку праці»ми розповідаємо про IT-індустрії в різних містах України]

В ІТ-індустрії Хмельницького зайнято понад 1000 спеціалістів. В місті працюють більше 30 ІТ-компаній, більшість з яких надає послуги веб-розробки. Щорічно виші міста готують понад 300 майбутніх ІТ-фахівців.

Середні зарплати програмістів у Хмельницькому:

• Junior — $300;
• Middle — $1000;
• Senior — недостатньо даних.

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

Компанії

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

AMC Bridge

Американська аутсорсингова компанія
75 спеціалістів у Хмельницькому, 364 в Україні

Компанія надає послуги з розробки ПЗ для систем автоматизованого проектування, конструювання та виробництва, співпрацюючи з такими відомими компаніями, як Autodesk, DS SOLIDWORKS, Microsoft, PTC та Siemens. Основні експертні області: математичне моделювання, аналітична геометрія, 2D і 3D графіка, високопродуктивні і паралельні обчислення, системи управління інженерними даними промислових виробів та інженерних споруд.

Можливості для початківців:компанія бере на роботу студентів 3-6курсів технічних спеціальностей. Окрім цього, AMC Bridge активно співпрацює з ХНУ, надаючи студентам можливість стажування у компанії з метою подальшого працевлаштування. Також компанія допомагає в розширенні навчальної програми.

SoftBistro

Американська аутсорсингова компанія
60+ спеціалістів у Хмельницькому, 80+ в Україні

Основні напрямки роботи: розробка, тестування та підтримка ПЗ для компаній зарубіжжя (зокрема, американського ринку). Діяльність компанії зосереджена у сферах освіти, здорового харчування та контролю витрат у сфері продажу. Технологічний стек: Java, PHP, JavaScript, Ruby on Rails, .NET, Front-End, iOS Development; DevOps, Big Data, QA Engineering.

Можливості для початківців:на базі SoftBistro проводиться безкоштовне стажування за напрямками Java Development, PHP/JS Development, Automation QA Engineering та SQL/Excel Engineering. Найкращі студенти отримують статус працівників та робочі місця.

Web-Systems Solutions

Українська аутсорсингова компанія
60 спеціалістів у Хмельницькому

Компанія надає послуги з проектування, розробки, підтримки та просування веб-сайтів, зокрема інтернет-магазинів, онлайн-каталогів, сайтів-візиток. Крім цього, Web-Systems створює мобільні та веб-додатки, CRM-системи як для місцевих, так і закордонних замовників. Основні технології: WordPress, OpenCart, 1C-Bitrix розробка; AngularJS; Ember.js; PHP; Yii2; Symfony.

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

Оutsourcing.team

Українська аутсорсингова компанія
30+ спеціалістів у Хмельницькому

Компанія створює проекти під ключ для бізнесу та стартапів. Сфери послуг: веб-розробка, графіка та веб-дизайн, інтернет-маркетинг та SEO. Основні технології: HTML, HTML5, CSS3, XML, XSL, JavaScript, JQuery, PHP, SQL, MySQL, Yii, Yii2.

​stfalcon.com

Українська аутсорсингова та продуктова компанія
30 спеціалістів у Хмельницькому, 40 в Україні

Студія розробляє переважно складні веб-сервіси та мобільні аплікації для технологічних стартапів і корпорацій. У списку клієнтів: MeinFernbus (вже FlixBus), Нова пошта, Київстар, NIC.ua. Крім цього, компанія створила і власний продукт — сервіс моніторингу якості доріг UARoads.com.

Основні технології: PHP (Symfony) та Python (AsyncIO) для бекенду, AngularJS та Vue.js для фронтенду, Kotlin, Swift та React Native для мобільних додатків. А також: GraphQL, Firebase, MongoDB, RabbitMQ, Elasticsearch, Docker, Puppet, AWS.

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

avivi

Українська аутсорсингова компанія
30 спеціалістів у Хмельницькому, 40 в Україні

Компанія спеціалізується на розробці Bitrix-рішень будь-якого рівня і складності: від завдання посунути логотип чи створити лендінг до розробки складного інтернет-магазину чи корпоративного порталу з нуля під ключ. Основна технологія — CRM Bitrix24.

Можливості для початківців:компанія відкрита для проходження стажування.

MassMedia Group

Українська аутсорсингова компанія
30 спеціалістів у Хмельницькому

Компанія розробляє мобільні та веб-додатки для американських, європейських та азіатських стартапів, а також створює рішення під ключ на базі актуальних фреймворків. Основні технології: PHP, Ruby, JS та їх фреймворки, Front-end, MySQL, MongoDB, PostgreSQL, інструменти для QA.

Можливості для початківців: MassMedia приймає на практику й стажування студентів IT-профілю з коледжів та університетів.

CoreValue

Американська аутсорсингова компанія
27 спеціалістів у Хмельницькому, 350 в Україні

Компанія надає послуги з впровадження хмарних CRM-систем включно з розробкою мобільних рішень у фармацевтичній, медичній, медійній, телекомунікаційній та маркетинговій галузях. Клієнти доручають компанії впровадження інфраструктурних сервісів в напрямках Data Science, Data Management, Database Services, Quality Assurance і традиційного програмування. Основні технології: .Net, Front-end інструменти.

Можливості для початківців:компанія бере участь у ярмарках кар’єри.

Blackthorn Vision

Українська аутсорсингова компанія
17 спеціалістів у Хмельницькому, 60+ в Україні

Компанія розробляє програмне забезпечення з використанням технологій Microsoft. Проекти здебільшого належать до індустрій Fintech, Healthcare, Oil & Gas, Retail, Machine Vision. Експертна кваліфікація — .NET технології та хмарні обчислення на базі Microsoft Azure.

Можливості для початківців:у 2018 році Blackthorn Vision планує набирати новачків і проводити для них курси.

Також в Хмельницькому є офіси таких компаній:

• Atwix — спеціалізуються на e-Commerce, зокрема Magento. Клієнтами є компанії світового рівня. Беруть на стажування талановитих студентів з можливістю залишитись працювати на постійних умовах.
• animal-id.info — розробляють міжнародну онлайн-платформу ідентифікованих тварин. Організація є членом найбільшої європейської асоціації баз даних тварин Europetnet.
• AXXOS Industrial Systems — розробляють систему моніторингу виробництва AXXOS OEE. Головний офіс компанії знаходиться у Швеції.
• Clarity AG — розробляють Clarity Communication Center, платформу, яка об’єднує сервіси телефонної інфраструктури. Інші продукти компанії: Clarity Contact Manager, сервіси на базі Voice over IP. Головний офіс знаходиться у Німеччині.
• Customhost — займаються веб- і мобільною розробкою в сферах Enterprise і e-Commerce. Основні технології — PHP, Symfony, Angular, React native. Також окремим напрямком бізнесу в Україні є хостинг (комплексні рішення: хостинг, домени, SSL-сертифікати).
• eLogic Commerce — створюють e-Commerce рішення на Magento та Magento 2. Експертні області: розробка на Magento, адаптивний дизайн в WordPress & Magento, Magento Performance Optimization, WordPress-плагіни та теми.
• Infoservice — надають послуги у сферах веб-розробки, iOS- та Android-розробки, розробки e-Commerce рішень, спеціалізуються на Microsoft-стеку технологій
• LE Consult Ltd.— розробляють продукти для російського ринку, серед яких AllRight.io — сервіс для вивчення англійської по скайпу та LiveExpert.ru — онлайн-консультації експертів з різних галузей.
• Onseo — створюють ігри для PC, web, iOS, Android, соціальних мереж. Основні технології: Java, JavaScript, .Net, PHP.
• RexSoft — надають послуги з розробки ПЗ. Переважну частину клієнтів складають американські стартапи. Основні технології: PHP, Java, Ruby on Rails, HTML/CSS, JavaScript, Canvas, WebGL, iOS, Android.
• TwinCore — спеціалізується на C#, .NET, ASP.NET. Працюють, як правило, з закордонними замовниками з фінансового сектору, рітейлу, сфери нерухомості тощо.

Див. також — Рейтинг ІТ-працедавців Хмельницького

Спільноти та події

Km Code’n’Coffee — щомісячні IT-конференції, мітапи та воркшопи на базі компанії stfalcon.com. Тематика зустрічей різноманітна: розробка, проектний менеджмент, дизайн, продажі.

Один із заходів Km Code’n’Coffee (image source)

Бізнес среда — майданчик підприємців для спілкування, обміну досвідом, розвитку і натхнення. Місія спільноти — підняти рівень бізнесу в місті, зробити Хмельницький привабливим для бізнес-інвестицій і професіоналів.

ІТ Академія від Stfalcon — періодично проводить безкоштовні заходи, присвячені ІТ.

Слідкувати за подіями у Хмельницькому запрошуємо в Календарі.

Освіта

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

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

Корпуси Хмельницького національного університету (image source)

Найбільші ІТ-школи:

• Dev Academy (Front-end, Web Development, Ruby on Rails);
• КА «Шаг» (розробка ПЗ, комп’ютерна графіка та дизайн, мережеві технології та системне адміністрування);
• ІТ Академія від Stfalcon (Front-end, Android, Swift, QA, IT Project Management, контекстна реклама AdWords).

Перспективи Хмельницького як ІТ-регіону

Степан Танасійчук, CEO компанії stfalcon-studio:

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

Серед переваг для ІТ-сфери варто відзначити низьку вартість купівлі/оренди нерухомості при збереженому рівні зарплат в ІТ в інших містах. Ми вже кілька років на першому місці в Україні за темпами будівництва (вартість 1 м²житла в новобудові складає 7-8 тис.гривень).

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

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

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

В’ячеслав Кравчук, CEO Atwix:

Приємно бачити, що в останні роки в Хмельницькому з’являється більше нетехнічних спеціалістів. Галузь ІТ розвивається розміреним темпом. Досить великий університет (ХНУ) забезпечує стабільний притік людей з регіонів, які здебільшого залишаються в місті.

В місті представлені компанії різного рівня, що працюють з абсолютно різними технологіями. Ми спеціалізуємось на Magento, також знаю компанії, які використовують PHP, Ruby, Java, .NET і т. д. — тобто всі ці спеціалісти є в місті. Таке різноманіття дає можливість початківцям знайти першу роботу та рости далі, не покидаючи Хмельницький.

Одним з основних недоліків можна назвати інфраструктуру. Аеропорти Києва та Львова знаходяться досить далеко, що створює незручності в зустрічах з іноземними замовниками.

Олександр Волік, CCO MassMedia Group:

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

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

Стек технологій в Хмельницькому на сьогодні охоплює всі напрямки — від розробки простих сайтів на базі готових рішень (WP, Magento тощо) до стартапів різних напрямків.

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

Вадим Синах, операційний директор AMC Bridge:

Коли ми шукали локацію для нового офісу AMC Bridge, одним з ключових критеріїв була наявність профільних вищих навчальних закладів та перспектива розвитку IT-галузі у регіоні. Хмельницький виправдав очікування щодо підготовки профільних кадрів та став першим містом, де ми ризикнули відкрити другий в Україні центр розробки.

Хмельницький є дуже комфортним містом для життя і лідером за рівнем задоволеності працівників IT-галузі, як видно з результатів опитуванняна DOU.

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

Павло Уманець, Director of Оperations, CoreValue:

Ринок ІТ у Хмельницькому — особливий. Перш за все, тут небагато великих компаній — потужних гравців, так би мовити. Більшість — це маленькі фірмочки, які спеціалізуються на Web Development і Front-end технологіях. Знайти професіоналів з необхідними навичками насправді непросто: дається взнаки нестача спеціалізованих навчальних закладів/курсів, а також велика плинність кадрів в інші міста і країни, де є ширші можливості для розвитку.

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

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

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

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

Ідея

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

Команда

Іларіон Солтис — Senior QA, засновник проекту EcoBot;
Денис Зайцев — Senior QA, програміст;
Андрій Коцеловский — інженер-конструктор;
Юрій Стеців — QA, Android developer;
Юлія Солтис — маркетинг.

Іларіон Солтис та Денис Зайцев на виставці MiniMaker Kyiv

Реалізація

В конструкторі використовуються плати, які є аналогами Arduino. Електроніка програмується на С. Також особливістю конструктору є керування зібраними власноруч моделями. За допомогою програмної частини для управління використовується планшет чи смартфон. Наразі керувати можливо тільки з OC Android. Додаток був створений за 2 місяці і вже доступний в PlayMarket.

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

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

Зібрана модель і деталі конструктора

Основними складовими Buggy є Arduіno плата, асинхронні двигуни, LEDs (передні та задні фари), динамік, H-міст (плата керування двигунами), серводвигун, Bluetooth , дерев’яні дощечки.

Модель і механіка конструктора розроблена в програмі Solidwork Composer. Фанеру для конструктору ми використовуємо українську і ріжемо її на лазерних верстатах з ЧПК.

Для розробки інструкції, коробки конструктори ми найняли freelance дизайнера. Також ми найняли на freelance працівників, які займаються паянням і комплектацією дротів для конструктора.

На початку своєї діяльності компанія Ecobot зробила значні ставки на виставкову діяльність, а також проведення майстер-класів. Зокрема участь у заходах: MiniMaker Lviv, MiniMaker Kyiv, Robocamp, Космовізія та інші.

Виставка MiniMaker Kyiv

Сьогодні конструктор від Ecobot можна купити на Rozetka.ua, Panama.uaта інших інтернет-магазинах.

Також одним з основних напрямків є розробка smart версії конструктора. Ця версія буде відрізнятися можливістю самостійного програмування в графічному середовищі Snap. Snap — це продовження і вдосконалення легендарного Scratch. Це графічне середовище програмування як для дітей і підлітків, так і для студентів. За допомогою графічних блоків, без використання коду, без складного програмування Snap дозволяє складати набори команд, алгоритми для створення власних програм. А його адаптована версія Snap4Arduino підходить для Arduino-сумісних контролерів.

Snap4Arduino ще більше розширює можливості, оскільки дозволяє керувати платою в режимі реального часу, передаючи команди і їх послідовності прямо з ПК на контролер, таким чином позбавляючи необхідності влазити в написання складного коду для мікроконтролера. Snap4Arduino містить усі блоки і набори графічних команд, які містяться у Snap i Scratch.

Ті, хто вже знайомий зі Scratch’ем запитають: «Чому саме Snap4Arduino?», тож ми відповідаємо. Суттєвою відмінністю Snap4Arduino від Scratch є розширені базові можливості, зокрема можливість використовувати будь-які цифрові виходи, а також змінювати їх властивості — встановлювати їх як для вхідних даних (з сенсорів, кнопок), так і для вихідних сигналів (для керування іншими пристроями: LED’ами, двигунами і т. д.). На жаль, у Scratch’i є жорстка прив’язка конкретно заданих виходів: тільки певні піни можуть бути вхідними, а інші — вихідними і немає можливості це змінити. В цьому відношенні Snap4Arduino дає нам простір для фантазії, з його допомогою ми маємо набагато більше можливостей для керування Arduino-сумісною платою і всіма її пінами, змінюючи при цьому їх стан на довільний!

Результати

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

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

Фото нашого клієнта з Японії

У планах компанії: створення нових моделей конструкторів, залучення коштів за допомогою краудфандінгу (Kikstarter), створення гуртків на базі smart версії, а також утворення власного виробництва і, звичайно, розширення ринків реалізації.

В этот раз DOU Ревизорпобывал в офисе Depositphotos — продуктовой IT-компании, которая разрабатывает известный международный фотобанк. Это коммерческая платформа для авторов и покупателей стоковых фотографий, векторной графики и видеороликов. Коллекция фотобанка насчитывает более 67 миллионов файлов. С компанией Depositphotos сотрудничают 45 тысяч поставщиков визуального контента со всего мира. Сегодня Depositphotos работает с 4,8 млн клиентов в 192 странах мира.

Компания была основана в Киеве серийным предпринимателем Дмитрием Сергеевым в 2009 году. Кроме Киева, офисы фотобанка есть также в Нью-Йорке (США), Москве (Россия), Лондоне (Великобритания), Берлине (Германия), Милане (Италия) и Варшаве (Польша). Глобально в компании работает 370 специалистов. В киевском офисе — 350 сотрудников, около 100 из них — технические специалисты.

В округе и поблизости

В 2014 году офис Depositphotos переехал в бывшее помещение мебельной фабрики «Лагода», а ныне делового центра «Лагода»по адресу ул. Полевая, 21. Ближайшая станция метро — «Политехнический институт», что в 15-20минутах ходьбы от офиса. Кстати, путь к офису пролегает через территорию студгородка и парк КПИ.

Поблизости нет большого выбора кафе и общепитов. На территории делового центра есть собственное кафе с летней террасой (стоимость обеда ≈ 70-80 грн),а в 30-тиметрах — ланч-холл Grandal (стоимость обеда ≈ 60-70 грн)и пиццерия Parmiggiano (средний чек ≈ 120-150 грн).На расстоянии одной трамвайной остановки находится Very Well Cafe (бизнес-ланч — 70 грн) и торговый комплекс «Аркадия» с недорогими общепитами и супермаркетом «Сильпо», а около сквера «Поляна» — кафе Happy Cake (круассаны — от 7 грн, стоимость обеда ≈ 50-60 грн).

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

Рабочее пространство

Основные рабочие зоны в офисе Depositphotos — это два больших open space помещения на втором и третьем этажах. На втором этаже работают отделы продаж и контент-команды, а на третьем — команды разработки фотобанка. Непривычно то, что во всем офисе есть лишь один отдельный митинг-рум. Остальные зоны для стендапов и скайп-коллов находятся в том же open space: это овальный стол посередине помещения и зона с диванами ближе к выходу. Если командам необходимо большое помещение для встреч, чаще всего используют лекторий в недавно открывшейся фотостудии Lightfield (см. раздел «Отдых и вдохновение»).

Офис открыт круглосуточно 24/7. График работы специалистов — свободный, рекомендованный — с 10:00 до 19:00. По факту большинство работают с 11:00 до 20:00 +/- полчаса (по данным компании).

Количество квадратных метров на человека в рабочем помещении составляет 8 м² (по данным компании).

Отдых и вдохновение

Весной этого года Depositphotos открыли самую большую фотостудию в Восточной Европе. Lightfield Productions — это 2500 м²креативного пространства для фотографов, 14 различных локаций для съемки, 1 зал-лекторий для проведения мероприятий, а также отдельное офисное помещение, где работают стилисты, визажисты, реквизиторы, location-менеджеры, собственный кастинг и постпродакшн. Lightfield находится в том же деловом центре «Лагода» напротив здания с офисным помещением Depositphotos.

В обоих open space пространствах есть кухни, которые отделены от основной рабочей зоны только небольшими перегородками. Кроме всей необходимой бытовой техники там установлены GUD Food Bar, холодильник со свежей едой и десертами и еще один холодильник с мороженым. А вот микроволновку и кофемашину поставили в отдельной комнате рядом, чтобы шум от них не мешал людям работать.

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

DOU Ревизор спрашивает

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

Роман, Full-Stack Developer, работает с 2013 года:

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

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

Юрий, Head of Sуstems Engineering Team, с компанией с 2009 года:

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

Что улучшить, даже сложно сказать. Раньше, когда мы работали на Подоле, у нас была проблема с парковкой. Сейчас такой проблемы нет. У этого пространства разве что есть небольшой недостаток с вентиляцией в зимний период. Зимой тут достаточно большой уровень СО2 в помещении, работать чуть-чуть дискомфортно. Летом открываем окна, есть кондиционеры и все такое. А зимой вынуждены время от времени делать проветривания, потому что тяжело находиться здесь, но это все уже на уровне «хотелок». А так больше проблем нет, все нормально. Это лучший офис, где я работал. Я с компанией, конечно, давно, но мы переезжали не раз. Одно время в подвале работали — нет, там очень хороший офис был :) Но без окон все-таки дискомфортно, а тут вообще классно.

Алексей, Front-End Developer, работает с 2009 года:

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

Анна, Project Manager, работает с 2014 года:

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

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

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

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

Ну что, мы поехали дальше... А если вы хотите, чтобы DOU Ревизор приехал к вам, пишите нам — revisor@dou.ua

Мы катаемся по Украине в поисках самых креативных и нестандартных офисов ИТ-компаний. Вместе с нами вы сможете заглянуть за кулисы офисной жизни. Но решать, хороший этот офис или нет, будете только вы!

Следите за нами на Facebook — www.facebook.com/dourevisor

Смотрите закулисные кадры того, что не проходит нашу цензуру на Instagram — instagram.com/dourevisor

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

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

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех).

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

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

Требования к оценке проекта

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

• честность;
• прецизионность;
• точность.

Честность

Как можно измерить честность оценки? Честность — что это вообще значит?

Честность в первую очередь перед самим собой.

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

Прецизионность

Прецизионность — это значит, что если вы оценивали 3 похожих проекта, то вы должны получить 3 похожие оценки. Если одна CMS-ка средней руки займет 1 человеко-год имплементации, то разработка другой CMS-ки схожего функционала никак не может занять 3 собако-недели или 5 рабо-лет.

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

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

Точность и условия оценивания проекта

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

И точность оценки — это очень крепкий орешек. В основном это вызвано:

• Временным ограничением. У вас обычно очень мало времени на оценку проекта. Особенно если вы работаете напрямую с сейлз-командой. Этим ребятам нужно все и сразу. Без исключений.
• Недостатком информации. У вас нет полной информации о списке функционала, целевой аудитории и т. д. Иногда все, что у вас есть, — это полпараграфа текста. А временами и исписанная вашим боссом салфетка из бара напротив. GoogleIT©может помочь. Но в основном вам придется работать в условиях крайне ограниченной информации о проекте.

А чтобы получить больше информации, вам нужно больше времени. Которого у вас нет.

Добавьте к этому следующее:

• Точность оценки в зависимости от трудозатрат растет логарифмически.
• Трудозатраты на повышение точности оценки проекта растут экспоненциально.

Это значит, что даже при наличии относительно большого количества времени на оценку проекта, ваш результат все равно будет содержать в себе погрешность. И достаточно большую.

Вероятностная сущность оценки сроков проекта

Это приводит нас к вероятностной сущности оценки сроков проекта.

Едва ли вы можете выразить предполагаемый срок проекта в одной цифре и быть при этом честными, прецизионными и точными одновременно.

Оценка срока реализации проекта — величина вероятностная.

Честный, прецизионный и точный способ представления оценки проекта звучит примерно так: «Проект займет 6 недель с вероятностью успеха 95 %. Или он займет 4 недели с вероятностью уложиться в срок 65 %». Можно еще представлять оценку проекта в виде диапазона значений с учетом 95 % вероятности успеха: «Скорее всего, проект займет от 4 до 6 недель».

Единица измерений

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

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

Как следствие, в этой статье я буду использовать Average Working Day (AWD)как единицу измерения.

Считайте, что 1 AWD — это количество работы, которую 1 программист в среднем может сделать за день, состоящий из 5 часов написания кода и 3 часов, потраченных не у монитора.

Вдобавок мы обычно не работаем в одиночку. Мы работаем в команде. И существует вековая проблема масштабирования команды согласно ожидаемого/желаемого срока разработки проекта. См. «9 женщин не могут родить ребенка за 1 месяц» и закон Брукса.

Но для простоты мы опустим эти детали и будем считать, что 2 человека могут справиться с задачей на 2 AWD за 1 день, 4 — за полдня и т. д.

Расчет диапазона срока выполнения проекта

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

Трехкратный метод

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

• B — best case (оптимистическая) оценка срока, 95 % вероятности не уложится в срок.
• N — nominal (номинальная) оценка срока, 50 % вероятности уложится в срок.
• W — worst case (пессимистическая) оценка срока, 5 % вероятности не уложится в срок.

Считайте, что уложиться в оптимистичный срок можно, только если сам Один сядет за лэптоп и всей своей мудростью и силой затянет проект прямо в Вальхаллу. Оптимистичная оценка — это минимально необходимое время для реализации проекта при наилучших обстоятельствах. Задача наверняка будет выполняться дольше, чем рассчитано по best case. Также можете считать это вашей Big-Omegaоценки срока.

Номинальная оценка — наиболее реалистичный срок. Это самое важное значение, так как оно имеет наибольший вес в дальнейших расчетах. Эта оценка должна быть умеренно оптимистичной при ваших обычных условиях работы. Считайте, что у вас есть 50%-ная вероятность не уложиться в номинальный срок. Также можете считать это вашей Big-Thetaоценки срока.

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

Очевидно, что

B < N < W

Ваша пессимистическая оценка не может быть меньше номинальной. Извините.

Давайте рассмотрим трехкратный метод на примере.

Пример требований к проекту

The web-service should allow a user to log in to an existing account.
Buy the product from the predefined list of commodities.
And review its purchase history.

Предположим мы разбили требования на 3 задачи:

Пример трехкратной оценки задач

Расчет СКОи среднего арифметического взвешенного

Среднее значение срока выполнения задачи (mean) рассчитывается как:

M = (B + 4N + W)/6

Почему коэффициент 4 для номинальной оценки? Потому что она наиболее реалистичная. И мы хотим выделить ее по сравнению с другими оценками. Почему именно 4, а не 6 или 8? Потому что Rocket Science.

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

И получаем:

Теперь давайте рассчитаем СКО (Standard Deviation) для каждой задачи:

S = (W — B)/6

И общее СКО для всего проекта:

Project Standard Deviation = SQRT(SUM(S)^2)

Для нашего проекта имеем:

СКО показывает вариативность вашей оценки. Чем оно больше — тем больше будет диапазон вашей оценки. Не говорите об СКО проекта людям с гуманитарным образованием :)

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

Бета-распределение

Для получения вероятности успешного выполнения проекта в оцененный срок я использовал бета-распределение. Потому что его применяли в PERT.

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

В общем мы рассчитываем вероятность успеть в срок исходя из среднего значения и СКО проекта.

Для нашего проекта получаем следующую функцию распределения:

Читается график так: «Проект будет завершен за 177 AWD с 95 % вероятностью».

Вот небольшая табличка шансов проекта на успех:

Если вы сравните со средним значением продолжительности проекта (102 AWD), то поймете, почему не следует просто использовать среднее.

Вот мы и получили вероятностную оценку срока выполнения проекта.

Диапазон оценки

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

The 95 % confidence interval for the true project work time is approximately:Project Total Mean ± 2 × Project Standard Deviation

Коэффициент 2 основан на правиле 68-95-99.7.

Для нашего проекта получаем: «Проект займет от 21 до 183 дней».

Можем опустить нижнюю границу диапазона и сказать: «Проект займет от 102 до 183 дней».

Конечно, можно использовать коэффициент 1, получая:

Project Work Time = Total Mean ± 1 × Project Standard Deviation

Но следует учитывать, что в этом случае мы говорим о вероятности окончания проекта в срок, равной 68 %.

Excel Workbook для проекта

Здесьнаходится Excel Workbook с примером расчетов для нашего проекта. Юзайте с миром :)

Дополнительные требования

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

Вывод

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

P. S.

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

У меня есть подозрение, что это не совпадение. Разработка программных продуктов — крайне волатильный процес. Очень редко в конце мы получаем то, что планировали изначально. Это делает расчет точности оценки практически невозможным. Для отдельных задач это еще реально, но для проекта в целом — едва ли.

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

Андрей Ясинецкийустроился в Google со второй попытки, переехав в Кремниевую долину в 2011-м.Через 4 года он не смог устоять перед предложением Uber и стал частью команды Marketplace. В интервью Андрей рассказал о том, как устроены «мозги» Uber, специфике найма и корпоративной культуре в компании, известной своими подрывными инновациями.

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

— С каким бэкграундом ты приехал в Штаты шесть лет назад?

Учился я в КПИ, на факультете электроники, на кафедре систем автоматизированного проектирования. Работать начал еще во время учебы, сначала в веб-студии «Аксиома» вместе с дизайнером Николаем Апостолом, потом занимался стартапом JeraSoft, где разрабатывал систему биллинга для IP-телефонии, а в 2007 году пришел в EPAM. Какое-то время еще работал вместе с командой 908над созданием продукта Audiko. Через несколько лет решил поехать работать по контракту в офис Google. Мне нужно было пройти стандартный процесс сложных интервью с гуглерами, разве что цикл был более короткий и не нужно было ждать фидбэка полгода. Кстати, это довольно распространенная практика среди IT-компаний в Долине — сначала нанимать человека по контракту, а потом переводить в штат. Нужно учитывать, что хайринг здесь обходится очень дорого. Нанять одного разработчика на фултайм стоит около 20 тыс дол.

— До этого ты уже пробовал попасть в Google напрямую, но не прошел собеседование.

Да, я подавался в лондонский офис в Developer Relations Team. Дело в том, что в Киеве я был соорганизатором Google Developers Group. Такие комьюнити существуют по всему миру для продвижения инженерного бренда Google. Мы провели несколько ивентов, вырастили группу до 150 человек, я организовывал tech talks, ездил на конференции, участвовал в хакатонах. На Google Developer Day в Москве я презентовал проект, который мы сделали на киевском GDG хакатоне. Мы провели его вместе с Michael Mahemoff, который тогда был Chrome/HTML5 Developer Advocate Lead в EMEA регионе. У меня было большое желание развиваться в этом направлении, помогая сторонним разработчикам использовать технологии Google. Именно на позицию Developer Relations я и подался в Лондон. Как потом выяснилось, во время телефонного интервью меня подвели коммуникационные навыки, так как не было достаточно опыта публичных выступлений на английском, а для такой должности требования к презентационным скиллам выше, чем для обычного девелопера. Сейчас я думаю, что это было довольно спонтанное решение не податься на инженерную позицию сначала, я просто потерял время.

Google Developer Day

— Во время работы контрактором какими проектами в Google ты занимался?

Сначала я работал в команде Google Analytics, а потом меня рекомендовали в экспериментальное подразделение Google[X]. Я занимался созданием системы для анализа аномалий в данных полетов в рамках Project Loon. Целью этого проекта было обеспечить интернет-покрытие с помощью запускаемых в стратосферу шаров размером с теннисный корт, которые транслируют LTE-соединение от наземных станций между шарами и обратно на устройства пользователей.

— Как ты получил предложение перейти в Uber?

На самом деле я следил за этим стартапом еще с 2013 года, когда там работало меньше ста человек. Моя машина больше года простояла на паркинге без дела. В конце концов, я не смог ее завести, и мы с другом просто вытолкали ее с паркинга и продали за углом у китайцев. Несмотря на мою любовь к автомобилям и вождению, иметь собственную машину было нецелесообразно. Я жил недалеко от офиса Google в Маунтин-Вью и любил ходить пешком или ездить на велосипеде, а для дальних поездок арендовал машину. Uber я рассматривал как удобную опцию для быстрого передвижения по требованию. Нужно сказать, что до эры Uber система такси в США в целом была ужасной. Например, в Майами по закону ты мог сесть в такси только через два часа после вызова, в Орегоне — через час, что исключало спонтанные поездки. В Сан-Франциско такси просто не хватало, а в Нью Йорке с 50-хгодов количество желтых кэбов почти не увеличилось (сейчас около 30 000 машин на весь город), а сам город значительно вырос с тех пор. Это вело к монополии на рынке и, как следствие, высоким ценам проезда. К примеру, от моего дома в Маунтин-Вью до аэропорта Сан-Франциско около 50 км, и проезд на такси стоил 100$, а на Uber около 25$.

Лично получив классный опыт с сервисом Uber, я также понимал, насколько серьезные вызовы с технологической точки зрения стоят перед проектом. Я мониторил Uber полтора года, следил за их развитием, общался с людьми из компании, которые были близки к руководству. Привлекало то, что проект молодой, есть уникальная возможность прийти и построить что-то большое с нуля. Ведь такой шанс возникает нечасто, компании, которые меняют устоявшиеся парадигмы в мире, появляются, может быть, раз в 10 лет. И так совпало, что кто-то из команды Google[X] зареферил меня продакт-менеджеру Uber. Он прочитал профайл в LinkedIn и написал, что впечатлен моим опытом и хочет встретиться на кофе пообщаться. У меня в LinkedIn было шутливое упоминание, что я готовлю отличный борщ, и он добавил, что хотел бы узнать больше об этом. На самом деле борщ — это такая ловушка для большинства рекрутеров больших компаний, чтобы отсеивать тех, кто не читал профиль, а просто автоматически агрегировал все по ключевым словам.

Uber HQ, Image Source

— До этого ты планировал уходить из Google?

На самом деле нет, у меня был оффер от Google с открытой датой, поэтому я не собирался менять работу. Но я согласился приехать в офис Uber, где кроме продакт-менеджера со мной общался Райан МакКиллен, который был вторым инженером в компании. Мы обсуждали разные челленджи, которые стоят перед новой командой, в которую меня хотели нанять. Я был очень воодушевлен тем, что это интернет-компания третьей волны, то есть она использует биты, сеть, вычислительные мощности, алгоритмы, чтобы влиять на офлайн, трансформировать физические состояния в реальном мире. Хотя в процессе я еще немного колебался, так как незадолго до этой встречи я побывал на закрытом ужине с кофаундерами и первыми инженерами Instagram, который они устраивали для небольшой группы инженеров, которых потенциально хотели нанять. Однако меня очень впечатлило грандиозное видение будущего Uber, которым они со мной поделились, и роль, которую я могу сыграть в создании этого будущего. В то время Instagram был уже более сформировавшимся продуктом. На момент нашего разговора Uber только стал «единорогом» (частная компания с оценкой, превышающей 1 миллиард) и был еще сравнительно мал. В течение следующего года с момента, когда я подписал оффер, оценка компании выросла до 45 миллиардов и в последствии до текущих 68. Не последнюю роль в моем решении стать частью Uber сыграло и то, что в финансовом плане предложение было намного привлекательнее, чем в Google и Instagram, учитывая также и потенциал роста акций, хотя для меня этот вопрос никогда не был самым главным.

— Как развивалась твоя карьера в Uber?

Мне посчастливилось прийти в компанию в такой уникальный период, когда свои отпечатки можно было оставить практически везде. Вначале мне предстояло работать над экспериментальным проектом в спектре communication and policy в проблемных для Uber регионах. Одна из самых простых вещей, которую мы сделали буквально за неделю, — это платформа петиций наподобие Change.org, где пользователи оставляли подписи в поддержку Uber. Там были интересные механизмы, как эти петиций потом отправлялись муниципальным властям. Когда подписей собиралось много, это становилось довольно мощным фактором, с которым нельзя было не считаться.

Вскоре произошла реорганизация, и большинство инженеров уровня senior и выше перераспределили на более значимые проекты. Я присоединился к команде, которая занималась динамическим ценообразованием. Тогда там было всего 15 человек. Это модель, которая основана на поведенческой экономике. У нас работает несколько профессоров из Колумбийского и Йельского университетов, которые занимаются разработкой различных статистических линейных моделей, а также моделей machine learning. На основе их исследований мы строим системы, которые рассчитывают оптимальную цену в реальном времени. Первое, что мы имплементировали, — это усовершенствовали алгоритм surge pricing (введение коэффициента на поездку в зависимости от спроса), который до этого строился на старых моделях, старых геозонах и с трудом масштабировался. Для запуска новой версии пришлось построить новую инфраструктуру почти с нуля, которая бы масштабировалась на весь мир. Нам нужно было в глобальном масштабе пересчитывать состояние всей логистической системы каждые две минуты, учитывая множество внешних факторов. Тем не менее это по-прежнему была реакционная модель, просто более точная и быстрая, так как у системы существовала задержка во времени, ей нужно было несколько итераций, чтобы отреагировать на спрос и уравновесить его. В последствии мы заменили «surge» на более сложно устроенную модель динамического ценообразования, которая учитывает множество внешних и внутренних факторов.

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

Традиционно Uber использовал Google Maps, но полтора года назад Uber купил у Microsoft их подразделение по созданию Bing Maps, а также их дата-центр в Колорадо. Потом к нам пришел бывший вице-президент Google по геопродуктам Брайан МакКлендон, основатель Google Earth. С тех пор мы строим свои карты, они сейчас запущены у большинства водителей в Штатах. Эти карты специально адаптированы под логистические и транспортные свойства внутри городов и этим отличаются от традиционных, которые в основном адаптированы просто под передвижение из точки А в точку Б. Google Maps, к примеру, может проложить самый оптимальный маршрут с учетом трафика и прочих данных от Сан-Франциско до Гранд-Каньона, но для Uber-карт это не актуально. Никто не вызывает Uber на такие расстояния, нам интересен локальный опыт внутри городов, который связан с местами, куда ездят люди в течение дня или ночи. С какой стороны улицы стоит пассажир, где разрешено подбирать пассажиров и как предложить пассажиру пройти 20 метров до угла другой улицы, чтобы водитель не объезжал целый квартал, и таким образом сохранить время обоим — это более актуальные задачи для Uber в рамках Maps и логистики.

Основная сложность в построении карт — это не картография сама по себе, а сбор и обновление данных в реальном времени. В густонаселенных городах инфраструктура меняется каждый день: появляются новые объезды из-за ремонтов, открываются новые улицы или закрываются старые, меняются знаки и правила передвижения. Google тратит почти 1 миллиард в год на поддержание и развитие карт и развивает сам продукт уже 12 лет. Это очень дорогие и сложные операционная и инженерная задачи. Мы начали два года назад, и со временем этот сервис будет совершенствоваться по всему миру, в том числе и в Киеве.

— Уже два года ты работаешь в структурном подразделении Marketplace. Расскажи о нем детальнее и за что отвечаешь ты?

Сейчас команда Marketplace насчитывает около 400 человек, это инженеры и продакты. Мы занимаемся всем, что касается dynamic pricing, geospatial positioning, machine learning, большими данными и аналитикой. Marketplace — это большая распределенная логистическая система, «real-time decision making framework», который постоянно получает какой-то инпут из реального мира, просчитывает эти данные, делает прогнозы либо готовит данные и выдает их в реальный мир. Система получает фидбэк, коррелирует себя и снова отдает данные. Это мозги Uber. Я рассказывал о том, как устроен Marketplace, в своем недавнем выступлениив Киеве на конференции, посвященной распределенным вычислениям.

Я лидирую несколько проектов. Один из них в Marketplace Efficiency, который связан с data science и алгоритмами для распределенного расчета логистической эффективности и динамики всей сети. Второй связан с Marketplace Data — это по сути большой storage c геоиндексами, который используют все системы в Marketplace для аналитики и также в real-time расчетах. Так как мы очень быстро растем, то необходимо его постоянное масштабирование. За сутки хранилище осуществляет миллиарды записей, собирает около 4 TB и суммарно хранит больше триллиона событий. Также я работаю над тем, чтобы инженеры могли создавать на основе данных из этого хранилища свои собственные метрики для аналитики. Для этого нужно оптимизировать данные, продумать интерфейс так, чтобы дата-аналитики могли описывать на очень высоком уровне, какие вычисления им нужны, а storage мог бы быть «self-service».

— Как у вас устроен knowledge sharing?

Когда кто-то работает над новой системой, дизайном, сервисом или алгоритмом, он пишет дизайн-док и делает рассылку на всех инженеров. Эту рассылку читает в том числе и CTO компании. Любой может оставить комментарий, начинается обсуждение. Например, сейчас ребята в Дании работают над новыми стореджами, которые отвечают нашим уникальным требованиям и нагрузке. Одна из новых систем баз данных — это более усовершенствованная версия CockroachDB с примесью Google Spanner, другая позволяет оптимальнее проводить аналитические вычисления, используя GPU. У нас довольно много уникальных требований к данным, их распределению, к менеджменту этих данных, поэтому нередко оптимальнее разработать собственный продукт, чем внедрять опенсорс-решение. Например, в разных странах существует разное законодательство по поводу того, где должны храниться данные. Поэтому любое опенсорс-решение потребует существенной доработки и дополнительной инфраструктуры поверх. Также мы имеем дело с реальным человеческим опытом, это сложнее, чем просто пересылать биты по Сети, поэтому вопросы, касающиеся надежности и безопасности, имеют критическое значение.

Нужно понимать, что Uber — не только инжиниринговая, но и наполовину — операционная компания. У нас операционные офисы в каждом крупном городе, где работает Uber. И у всех свои различия, в том числе культурные. Даже система рейтингов имеет свои особенности, связанные с разницей менталитета. Скажем, в США, если что-то пошло не так в поездке, то пользователи склонны ставить довольно справедливую оценку и писать отзыв. В Украине я опрашивал некоторых знакомых, как они реагируют на плохую поездку, например, если в машине было накурено. Люди чаще склонны ставить более положительную оценку: «Человек же старался». Конечно же, есть отличия и в типе сервиса. Например, в Бразилии в UberX ездят довольно старенькие машины, а в США может приехать автомобиль высокого класса. В Украине многие жалуются, что приезжают ланосы. Но на это есть понятные причины: спрос превышает все ожидаемые прогнозы, и, чтобы его покрыть, нужно расширять требования к машинам, учитывая особенности рынка. Если не масштабировать бизнес, тогда 90 % пользователей будут не удовлетворены, потому что никто никуда не сможет уехать из-за нехватки машин и выросших цен. Uber — это часть транспортной и экономической экосистем города, где также существует публичный транспорт, традиционное такси, личный автотранспорт, велосипедные и пешеходные зоны. Чем больше опций передвижения в городе, тем лучше.

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

Недавно в Marketplace появился свой вице-президент по инжинирингу. Им стал Кевин Томсон, в прошлом — VP в Youtube. Это очень важный этап, которого все давно ждали и в котором была большая потребность. Но структурно за эти два года ничего кардинально не изменилось, хотя, возможно, должно было бы. Ни одна организация в истории Долины не росла такими темпами, поэтому нельзя опереться на чей-то опыт и точно сказать, как делать правильно. Постоянно нужно внедрять какие-то инновации, чтобы каждое решение способствовало продвижению продукта. Это влечет за собой необходимость в изменениях, например, на инженерном уровне, потому что те системы, которые запустились в продакшн, уже через полгода требуют обновления из-за возросшей нагрузки. С точки зрения менеджмента и организации работы, тоже все нужно масштабировать. Если количество людей в команде вырастает до 25 человек, а инжиниринг-менеджеров не хватает, то происходит их перегрузка, когда они не успевают делать со всеми one-on-one, следить, чтобы все были удовлетворены и имели карьерный рост. Еще один челлендж — это найм людей в Долине, особенно уровня senior и выше, в которых есть постоянная потребность.

— Ты как техлид участвуешь в процессе собеседований кандидатов. Расскажи, пожалуйста, про рекрутинг специалистов в Uber.

На самом деле хайринг в Uber почти ничем не отличается от найма в Google, Facebook и другие топовые компании в Долине. Требования такие же высокие, структура собеседований тоже похожа. Если речь идет о людях уровня junior или недавних выпускниках, то даже если они работают в Facebook или Google, захайрить их проще, потому что они открыты к изменениям. А вот senior, staff и principal из топовых компаний переманить практически нереально. Они, конечно, мотивированы не только компенсацией и бонусами, но главное, они морально инвестировали в свои компании и продукты на долгий период. Опытный специалист, как правило, уже что-то серьезное построил, заработал авторитет в индустрии, поэтому переход в другую организацию повлечет за собой необходимость во многом заново подстраиваться.

— По поводу уровней в Украине существует некоторая путаница и неопределенность в понимании того, когда специалист становится senior. Есть такое мнение, что для этого нужно просто какое-то количество лет отработать в компании.

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

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

Еще один аспект, который очень страдает, — это системный дизайн. На этом многие проваливаются. Я говорю кандидату: «Представь, что у нас есть какое-то количество данных, которые не помещаются в память на одном компьютере, нужно их распределить. Давай подумаем про архитектуру на абстрактном уровне, как бы это могло быть спроектировано». И с этим часто не справляются, потому что это вопрос, на который нет однозначного ответа, так как есть много вариантов решения и каждое имеет свои сильные и слабые стороны. У меня просто есть мой опыт, и я смотрю, как бы мне работалось с этим человеком, если бы нам вместе нужно было решить такую задачу. Мне важно, как человек мыслит, как он умеет объяснить свое решение, как он отстаивает свое мнение. Когда мы создаем что-то инновационное, мы ведь не знаем, как правильно, потому что раньше никто это не делал, в этом и смысл новаторства. Это то, что отличает девелопера от инженера. И на интервью моделируются такие ситуации. С этим также связаны высокие требования к коммуникативным навыкам, важность которых в Украине часто недооценивают.

— Насколько глубоко разработчику нужно разбираться в доменной части продукта?

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

— Есть ли шанс у ребят из Украины попасть на работу в Uber в Сан-Франциско, спонсирует ли компания визы?

Пройти собеседование вполне реально, хотя нужно предупредить, что по уровню сложности наши интервью вторые после Google (согласно недавнему исследованию Glassdoor). Но с H1B визами слишком много сложностей, во-первых, это лотерея, во-вторых большинство квот забивается аутсорсинговыми компаниями или крупными игроками типа Facebook, Google и т. д. Поэтому более распространенный вариант, когда мы нанимаем людей в один из европейских офисов, а потом можно сделать трансфер в Штаты, если человек захочет. Так что я бы рекомендовал отправлять резюме, например, в Амстердам.

— В последнее время на фоне скандалов вокруг Uber все говорят, что в компании сформировалась токсичная «пацанская» культура. Что ты можешь сказать по этому поводу?

На самом деле, я не совсем понимаю, что имеют в виду под понятием bro culture, мне кажется, этот термин не всегда используют в правильном контексте. Когда я пришел в Uber из Google, то первое, что бросилось в глаза, — большое количество женщин. В моей команде из 14 человек шесть девушек. В компании есть сотрудник, который отвечает за diversity and inclusion, — это Бернард Коулман. Он до этого работал в штабе Хиллари Клинтон.

Что касается конкретно тех случаев, которые вызвали резонанс, то первой была история со Сьюзан Фаулер. Она работала в команде SRE, и я никого от туда не знаю, поэтому ничего прокомментировать не могу. Вообще о таких историях за все время работы я никогда не слышал. Предполагаю, что это локализованная проблема, а учитывая, что Uber всегда находился под пиар-давлением, когда был обнародован этот клейм, он выступил катализатором скандалов. Дальше начался протест, связанный с тем, что будто бы Трэвис Каланик поддерживал Трампа, хотя он был такой же приглашенный советник, как, например, Элон Маск. Это совпало с акцией в нью-йоркском аэропорту против решения о запрете въезда в Штаты гражданам некоторых мусульманских стран. Тогда Uber отключил динамическую цену, как это происходит всегда во время каких-то экстренных ситуаций, терактов, катастроф и т. п. В итоге это было трактовано как то, что компания таким образом пытается помешать протесту, потому что поездки стали дешевыми, и все могли разъехаться. После этого раскачали хэштег #DeleteUber, из-за чего у нас какое-то время была кризисная ситуация.

В Долине многие компании гонятся за цифрами, чтобы просто статистически продемонстрировать, что они поддерживают diversity, так как это очень резонансная тема здесь. Все конкурируют за «талант», а это один из способов набрать себе очков и выглядеть привлекательным местом работы для потенциального кандидата. К сожалению, большинство этих компаний лишь публикуют красивые цифры «diversity», но никто не говорит о том, насколько «inclusive» атмосфера в компании, сколько тех кандидатов потом уходят через год и т. д. А ведь diversity — только одна часть проблемы, главное — «inclusion», без чего это просто PR. При этом есть проблема реального харрасмента, который действительно случается в Долине в целом, хоть и редко, и все компании заинтересованы с этим бороться, в том числе и Uber.

Rami Malek (right), Elliot in Mr. Robot

— Какие привилегии предлагает Uber своим сотрудникам? Как обстоят дела с work-life balance?

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

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

В Uber есть Employee Resource Group, они объединяют людей по национальному признаку, есть группы для сотрудников с детьми, для ЛГБТ, комьюнити по интересам. Они проводят ивенты, встречи, это место, куда люди могут прийти пообщаться с единомышленниками, найти поддержку. Что касается бонусов, то у нас их очень много: есть кредиты на поездки на Uber, купоны в кинотеатры, скидки в разных магазинах, бюджет на книги у каждого сотрудника, возмещаются затраты на спортзал. У нас проходят занятия с инструкторами по йоге и медитации, оплаченная медицинская страховка, в офис часто приходят разные знаменитости на Q/A или просто выступить, в офисе бесплатная еда — обед и ужин. Есть также бюджеты на команду, которые можно потратить, чтобы сходить вместе в ресторан или устроить какое-то интересное развлечение.

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

Мне фотография была интересна с детства. Мой дедушка был геодезистом и использовал фотоснимки в работе. У него была своя фотолаборатория, и когда я впервые туда попал и увидел, как на бумаге проявляется изображение, то был просто потрясен этой магией. Лет в 15 у меня появилась первая камера, я фотографировал на пленку. Когда я переехал в Штаты, спустя несколько месяцев мы с друзьями отправились в классический трип по Калифорнии, объехали все каньоны. И я не взял с собой фотоаппарат, только телефон. Я так впечатлился масштабами этой природной красоты, что твердо решил вернуться, чтобы сфотографировать все это. Так я начал заниматьсяпейзажной фотографией, посвящая этому свободное время. Я совершаю 15-20поездок в год в национальные парки. Я получил несколько наград на профессиональных конкурсах EPSON International Pano Awards и International Photography Awards. В 2013 году во время Google Talks я познакомился с известным американским фотографом Родни Лоу Джуниором (некоторые его работы отобраны в Smithsonian Museum of Natural History). С тех пор мы продолжаем общаться, и он стал моим ментором. Мы вместе путешествовали в Glacier National Park в Монтане и в некоторые места в Орегоне, где он живет. Недавно я приобрел у него его легендарную камеру Arca Swiss с Phase One IQ180 — 80-мегапиксельнымсреднеформатным задником, который дает возможность использовать все 16-битцвета в широком формате. Это позволит мне делать снимки галерейного масштаба и качества. Заработанные деньги с продажи работ отправляются в фонд национальных парков.

Я осознал, что способен успешно совмещать в себе инженерное математическое мышление, карьеру и творчество. Я получаю максимальное удовлетворение от обеих областей и не вижу себя лишь в чем-то одном. Для этого, кажется, даже есть термин — polymath. Пару лет назад Google купил несколько моих работ, и теперь они висят в разных зданиях кампуса в Mountain View. Когда я вижу свои работы на стене, ощущаю, что создал что-то физическое, а не только виртуальное. Как бонус, фотография и походы в горы по-настоящему дают возможность разгрузить голову за пару дней и потом снова вернуться в активный рабочий процесс. В Долине бешеный темп и нагрузка. Я убежден, что наука и творчество — это две части одного целого. Одно не может существовать без другого.

— В Долине все пропитано духом предпринимательства. Не думал ли ты уйти из найма и создать свой стартап?

Я начинал делать свой проект еще во время работы в Google вместе с тремя моими коллегами. Но в итоге вышел из него, хотя ребята продолжают его развивать. Также немного занимался ранним инвестированием в несколько стартапов. Один из них из области car sharing, он был в свое время конкурентом Getaround, и в итоге стартап купила компания FOX Rent a Car.

В регулярном подкасте California Today (аудиоверсия доступна в iTunes) мы с Андреем Хорсевым рассказываем о многом, что происходит в Долине, со взглядом изнутри, в том числе о предпринимательстве, трендах, технологиях и в целом индустрии.

Людям, которые приезжают сюда с целью запустить стартап, все сложнее, чем тем, кто живет в Долине. Нужно обрастать знакомыми, искать правильных людей, в конце концов, это потребует больших финансовых затрат. Любое стоящее дело требует времени, а время в Долине очень дорогое. У меня уже есть большой опыт в индустрии, связи среди технических талантов и среди VC, какой-то капитал, так что начать свою компанию в этом смысле проще. К тому же здесь есть весь сервис — инфраструктура, продажи, юридическая часть. Можно автоматизировать свой бизнес до такой степени, чтобы максимально сконцентрироваться над работой над продуктом. Среди моих коворкеров текущих и бывших я вижу потенциальных партнеров, с которыми я мог бы что-то делать вместе. Так что я задумываюсь над тем, чтобы запустить что-то свое в области, где технологии влияют на физический мир, как в случае с Uber. Меня очень привлекают инфраструктурные проекты, например такие идеи, как Stripe или что-то, что позволяет решать проблемы офлайн с помощью технологий автоматизации. В следующие 10-15лет мы увидим грандиозный рост в этой области, будет появляться большое количество компаний, автоматизирующих устаревшие процессы и решающих более реальные проблемы, чем фильтры в Snapchat. Хотя последнее делает людей счастливее, что тоже важно.

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

[Всеволод Дёмкин — инженер-исследователь и преподаватель. Лисп, обработка природных текстов, машинное обучение. Причастен к lang-ukи m8nware. Больше информации тут]

Когда меня просят дать рекомендации книг, я обычно затрудняюсь ответить, потому что в последние годы очень мало читаю именно книги. В основном это отдельные главы, статьи, блог-посты и переписки. Такой вот ADHD. Или просто формат книг отживает свое, так как трудно собрать столь большой объем текста, чтобы он был равномерно полезен и интересен. Но когда-то ведь жизнь была более размеренной и можно было позволить себе почитать книжку... :) Так или иначе, несколько книг за свою жизнь я таки прочел и даже, если покопаться, оказывается, могу порекомендовать кое-что.

Practical Common Lisp. Peter Seibel

Доступна бесплатно

Можно сказать, что эта книга во многом предопределила мою специализацию в программировании, поскольку встретил и прочитал я ее тогда, когда как раз находился на этапе поиска: будучи глубоко разочарованным тем, что предоставлял на тот момент мейнстрим, я знакомился с его альтернативами (например, популярные тогда скриптинговые языки TCL, Perl и Python). И парадигма, которую открыла мне эта книга, не только оказалась именно тем, что я искал: «естественной» для меня и дающей ответы на те проблемы, которые меня волновали,— она еще и вернула мне веру в программирование и дала вдохновение, которое я продолжаю ощущать до сих пор. Так сказать, вернула «The Joy of «Programming», как называется популярная серия книг по разработке от издательства Manning. И хотя книга была написана больше 10 лет назад, она, как и многое связанное с Лиспом, сохраняет свою актуальность до сих пор, о чем я могу судить по отзывам, которые слышал даже в этом году. Еще про нее есть хороший анекдот, рассказанный одним из технических директоров компании ITA Software (поисковик авиабилетов на Lisp’е, который был куплен Google за $1 млрд): что их способ найма Lisp-разработчиков заключался в том, чтобы найти программиста с хорошей базой, дать ему эту книгу и через 2 недели вовлекать в работу над продакшн-системой.

Beautiful Code — Leading Programmers Explain How They Think. Andy Oram, Greg Wilson

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

Lisp Hackers — Interviews with 100x More Productive Programmers. Vsevolod Dyomkin

Доступна бесплатно

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

The Daemon, the Gnu, and the Penguin. Dr. Peter Salus

Доступна бесплатно

Это книга об эволюции, пожалуй, самого значительного явления в истории нашей индустрии — Unix (и сопутствующего ему движения Open Source). Как и любая грандиозная история, она очень занимательна и полна перипетий, порожденных человеческой глупостью, жадностью и завистью. Тем важнее изучать ее, чтобы не повторять тех же ошибок, а, наоборот, «стоять на плечах гигантов». Я размышлял о книгах по Unix, которые мог бы порекомендовать (например, The Art of Unix Programming), и пришел к выводу, что ценность Unix не только, и не столько в конкретных технологических решениях (о некоторых из которых, кстати, можно прочитать в Beautiful Code, а о некоторых — со знаком минус в The UNIX HATERS Handbook). А именно в истории человеческого взаимодействия и того, как на его основе создаются серьезные программные проекты. И урок Unix’а в этом смысле, пожалуй, интересней того же Mystical Man-Month или Peopleware.

Бхагават-Гита как она есть. А.Ч. Бхактиведанта Свами Прабхупада

Доступна бесплатно

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

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

Я Lead Software Engineer, занимаюсь проектами по виртуализации для автомотив-сектора в GlobalLogic. Эта статья подготовлена на основе моего выступления на Root Linux Conference 2017, и является продолжением темы, которую недавно раскрыл Ларс Курт.

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

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

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

Другой компьютер (в обычной жизни водитель взаимодействует с ним редко) отвечает за систему зажигания, сервисы экстренного оповещения при аварии и т. п. Этот компьютер работает под управлением операционной системы реального времени (real-time OS, RTOS), как правило, закрытой и/или проприетарной (впрочем, бывают и исключения, например, FreeRTOS или QNX). Главные требования к такой системе — стабильность, надежность и отзывчивость, поскольку это устройство обслуживает запросы, время выполнения которых очень ограничено и очень критично.

Также в автомобилях премиум-класса отдельный компьютер отвечает за работу кластера (приборная панель над рулем автомобиля). Как правило, такой компьютер работает под управлением какой-либо узкоспециализированной Linux-системы с композитным менеджером Weston. Главное требование к такой системе — быстрый и высококачественный рендеринг изображения. В противном случае показания спидометра или тахометра будут отображаться на панели с задержкой, что сделает их бесполезными для водителя.

Один за всех

Теперь рассмотрим типичную автомобильную платформу. Как правило, это очень производительная система: 8-ядерныйпроцессор: четыре А57, четыре А53, высококлассный PowerVR GPU от Imagination, 4 Гб оперативной памяти, огромное разнообразие разных шин. Для решения каждого конкретного набора задач — будь-то кластер или информационно-развлекательные системы — ее возможности явно избыточны. Поэтому мы решили, что можно совместить несколько физических компьютеров в одном за счет использования виртуализации. Какие преимущества мы получаем от такого использования?

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

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

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

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

Почему Xen?

Во-первых, Xen — это гипервизор так называемого первого типа (type 1), что позволяет его использовать на «голом железе» и стартовать практически любую операционную систему в качестве гостевой. Уже, как говорится, «из коробки» Xen поддерживает множество гостевых операционных систем: Windows, Linux, FreeBSD, QNX и еще много чего другого, пускай даже с некоторыми ограничениями.

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

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

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

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

Как это работает?

Итак, у нас есть несколько операционных систем, которые управляются из так называемого Dom0. Это привилегированный домен, который может управлять аппаратной платформой почти без ограничений. В основном он ответствен за создание гостевых операционных систем, за их модификацию и удаление. Также очень эффективно, чтобы в Dom0 «бежал» Watchdog, который поддерживается Xen через специальный механизм. Так, если упадет какой-либо из гостевых доменов, Watchdog его легко поднимет без влияния на работу остальных систем.

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

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

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

Проблемы и решения

Ранее уже упоминалось, что в Xen есть поддержка архитектуры ARM. Что нужно, чтобы операционная система «бежала» на основе гипервизора на ARM? На ARM операционная система «бежит» в режиме EL2 на AArch64, а гостевые домены у нас в EL1-режиме. Основная проблема для автомотива и не только — это проблема перевода бутлоадера перед стартом гипервизора в нужный режим.

В общем случае для решения этой проблемы используется U-boot. Но это далеко не обязательно, есть достаточно много исключений. Плюс иногда этот перевод не общедоступен, поскольку иногда это достаточно проприетарная информация. Но тем не менее U-boot с 2016 года поддерживает автоматический перевод ARM архитектур в Virtualization mode. Т. е. мы прыгаем на само ядро, в данном случае на гипервизор уже в Virtualization mode. Поэтому основной проблемой является отсутствие стандартизированного подхода в общем случае и некоторая закрытость инфраструктуры, особенно если мы говорим о закрытых архитектурах, например, Qualcomm.

Память

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

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

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

По умолчанию Xen создает RAM base начиная с 0×80000000, но это можно изменить. И по факту это больше механическая работа, потому что это нельзя сделать в один проход. Вам надо править в нескольких местах, начиная с конфигурации конкретного домена, заканчивая конечным device tree. Но тем не менее это имеет право на жизнь — на схеме можно увидеть, что Xen выделил память для драйвера домена с 0xB0000000 — 0xBFFFFFFF, но сама операционная система драйвер-домена думала, что она бежит по адресам начиная с 0×80000000. Однако мы поправили стартовый адрес, и теперь у нас домен один в один замаплен.

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

Вторым подходом является набор памяти по частям. Xen изначально оперирует достаточно большими кусками памяти, и не всегда их можно «нарезать» таким механизмом. Нам, например, надо 766 МБ в драйвер-домене. Если не ошибаюсь, ближайшее целое значение памяти, которое мы можем выделить одним куском, — 1 ГБ, после этого будет уже мелкими кусочками по 2MB. Нам никто не мешает, в принципе, эти кусочки натягать из разных частей оперативной памяти и сделать так, чтобы каждый из них был один в один «замаплен». Это нам позволит переложить работу по трансляции адресов на ядро. Да, хорошо, у нас будут какие-то дырки, у нас будет и непрерывный кусок, но вся трансляция проходит на стороне Linux. На данный момент это наиболее эффективный подход, который мы используем.

Наиболее правильным и эффективным методом решения проблемы с DMA будет использование SMMU (IOMMU) (SMMU — system mmu, IOMMU — input/output mmu) — в этом случае трансляция адресов будет выполняться на аппаратном уровне, прозрачно для устройства. Но, к сожалению, его наличие в SoC зависит от производителя (и наличия поддержки этого устройства в BSP для данного SoC). А также поддержки со стороны Xen — но сообщество работает над этим решением.

Графика и прошивки

Следующая проблема, с которой можно столкнуться, — это проблема с прошивками. Например, у нас есть какой-то DSP-процессор (узкоспециализированный процессор, предназначенный для решения задач цифровой обработки сигналов), который обрабатывает видео и, как правило, использует резерв памяти в device tree для ARM. В общем случае доступ к этим прошивкам есть только у производителей устройств. И проблема в том, что нам надо получить доступ к функциональности этих прошивок, не смотря на то, что процессор использует резерв. К сожалению, эта проблема сложно решаема. Одно из банальных решений, к которому приходилось прибегать, — это бинарный патч в runtime. Мы знаем, по каким адресам у нас бежит домен, и мы в runtime просто патчим адреса, на которые настроена прошивка для DSP. Это очень грязный хак, но тем не менее иногда он имеет право на жизнь.

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

По своей сложности топовые GPU (например, A72 Mali) уже превосходят привычные вычислительные процессоры. Это создает разработчикам дополнительные проблемы — сложность самого графического «железа», жесткие проприетарные лицензии, проблемы с документацией, которую очень непросто получить от производителя.

Также на данный момент в 99% GPU отсутствует поддержка аппаратной виртуализации, поэтому приходится искать какие-то отдельные варианты и механизмы для решения этих задач.

Один из способов использования GPU виртуализированными операционными системами, который мы реализовали, — это программный context switch. На каждый switch домена мы сохраняем состояние и набор регистров GPU и восстанавливаем с другого домена. То есть процесс повторяется: сохранили-восстановили; сохранили-восстановили. Этот механизм достаточно прост в создании, но проблема, как минимум, в том, что GPU весьма сложное устройство, и все эти операции — не мгновенные.

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

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

Если говорить о производительности решений, то первое решение, конечно, менее производительно, потому что мы должны все это прогнать через CPU, что весьма долго. Так, потеря производительности в первой платформе составляет порядка 5-10%.На второй платформе — всего 3% в трехдоменной конфигурации. Самым правильным является использование полной графической поддержки виртуализации. Но, насколько нам известно, это существует буквально в нескольких чипах, и в автомотиве они пока не используются, но может найдут свое применение уже через пару лет.

PV-драйвера

Как уже говорилось ранее, PV-драйвера — это некий специальный подход к распределению возможностей реального железа между несколькими доменами. У нас есть какой-то backend, который взаимодействует с аппаратным программным обеспечением через настоящий драйвер в Linux и какой-то frontend, который предоставляет не обязательно полный доступ ко всей функциональности.

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

Поначалу «из коробки» были доступны только основные драйверы — PV-блок, который используется для виртуализации блочных устройств. Паравиртуальные драйверы для сети и PCI, SCSI и Frame buffer, а также USB (pvUSB) были доступны только на архитектуре x86. PvUSB было изначально доступно и в более старых версиях, но производительность была очень низкой, как и переносимость, но вот в 4.7 добавили базовую поддержку pvUSB. Однако коммюнити продолжает разрабатывать другие PV-драйвера.

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

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

Тренды и перспективы

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

По умолчанию Xen использует scheduler, который weight-based, то есть рассчитан на работу с весами. Он не гарантирует отзывчивость операционной системы. Есть также механизм RTDS scheduler, который предоставляет мягкое реальное время, но он на данный момент еще в разработке. Интересен для автомотива ARINC653 scheduler: он позволяет предоставить жесткое реальное время, но не имеет поддержки многоядерности. В дальнейшем, возможно, это будет исправлено, возможно, нет.

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

Однако на данный момент полноценной поддержки в Dom0 нет. Есть поддержка со стороны MiniOs, но пока что это не совсем честная поддержка. Это запуск нескольких операционных систем из Xen в момент его старта. То есть это не дает нам поддержки libxl-стека. Если мы захотим вручную создавать домены, то нам понадобятся другие механизмы.

Также нами была разработана частичная поддержка QNX в качестве гостевого домена DomU. Это позволило нам воспользоваться его преимуществами для дальнейшей сертификации. Кроме того, в качестве Dom0 можно использовать Linux с реал-тайм патчами. Но он, конечно, не предоставит механизм жесткого реального времени. Этого будет недостаточно для каких-то критичных по времени исполнения задач.

В целом можно сказать, что виртуализация для автомобильной промышленности — достаточно сложная область, и здесь хватает задач, для которых пока еще нет готовых решений. Но именно поэтому это очень интересная тема для всех, кто хочет попробовать себя в R&D и заняться созданием решений, которые, возможно, станут стандартом для целой индустрии. В любом случае это очень перспективное направление. Если оно интересно и вам — присоединяйтесь. Больше про Xen и все, что с ним связано, вы можете узнать на странице wiki.xen.org/wiki/Main_Page

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

Учитывая, что .NET Core может быть вручную установлен на любую современную серверную ОС, в обзор не были включены поставщики VPS/VDS сервисов. В этом обзоре рассматриваются исключительно облачные провайдеры, которые предоставляют возможность разворачивать .NET Core проекты в рамках IaaS или PaaS, где необходимое окружение уже заранее сконфигурировано.

Фреска Микеланджело Сотворение Адама

Azure

Поддерживаемые модели: IaaS, PaaS / Документация

Azure — самая динамично развивающаяся облачная платформа. Кроме того, это родная платформа для .NET проектов, поскольку ее разработчиком является компания Microsoft.

В Azure можно размещать .NET Core проекты как в службах WebApps, так и в виртуальных машинах. При этом в случае использования WebApps вам не нужно заниматься администрированием сервера, все, что от вас требуется, — это только задать необходимые параметры быстродействия. Также WebApps позволяет автоматизировать процесс развёртывания проекта путём интеграции с различными системами контроля версий (GitHub, Bitbucket, Visual Studio Team Services etc).

Amazon Web Services

Поддерживаемые модели: IaaS, PaaS / Документация

На данный момент Amazon Web Services — лидер рынка облачных технологий и самый крупный поставщик облачных решений. Используя AWS, вы можете разворачивать .NET Core проекты в рамках сервисов EC2 (IaaS, виртуальные серверы) и Elastic Beanstalk (Paas, аналог WebApps в Azure). Кроме того, у AWS есть специальный набор инструментов для Visual Studio, который позволяет значительно облегчить процесс развертывания проекта.

Digital Ocean

Поддерживаемые модели: IaaS / Документация

Digital Ocean — наверное, самая простая в изучении и использовании облачная платформа и одна из самых доступных с финансовой точки зрения. В Digital Ocean развернуть проект на .NET Core можно в специально подготовленном дроплете, который включает в себя не только установленный и настроенный .NET Core, но также PowerShell, nginx и LetsEncrypt. Стоит отметить, что все дроплеты Digital Ocean работают на быстрых SSD дисках. Студенты могут пользоваться Digital Ocean бесплатно в рамках GitHub Student Pack.

Google Cloud

Поддерживаемые модели: IaaS, PaaS / Документация 1,
Документация 2

Вслед за Amazon и Microsoft, Google тоже решил выйти на облачный рынок. После своего запуска, довольно длительное время Google Cloud не развивался и предоставлял для работы ограниченное количество сервисов и сильно устаревшее программное окружение. Но в последнее время в компании началась активная работа как над самой платформой, так и над средствами разработки. Сегодня в облаке от Google проекты на .NET Core можно разворачивать как на виртуальных машинах, так и в специализированных контейнерах. У Google, также как и у Amazon, есть свой набор расширений для Visual Studio, который позволяет значительно облегчить процесс развертывания проектов под эту облачную платформу.

IBM Bluemix

Поддерживаемые модели: IaaS, PaaS / Документация

IBM Bluemix — облачная платформа, разработанная компанией IBM. О ней пишут не так много, как о AWS и Azure, но тем не менее, платформа заслуживает внимания и имеет достаточно хорошие перспективы развития. Размещение .NET Core проектов в ней возможно в рамках как коммерческого тарифного плана, так и бесплатного пробного тарифного плана на 30 дней.

Open Shift

Поддерживаемые модели: IaaS / Документация

OpenShift — это облачная платформа от компании RedHat, занимающейся разработкой одноименного дистрибутива Linux. Платформа .NET Core будет развёрнута как раз на базе дистрибутива Red Hat Enterprise Linux 7.

Сводная таблица по платформам

P.S.Если вы заинтересовались разработкой под .NET Core и хотите быть в курсе новостей и тенденций платформы, приглашаю
вас присоединиться к сообществу украинских .NET Core разработчиков — .NET Core Ukraine User Group.
В сообществе можно обмениваться полезной информацией и сообща находить ответы на возникающие вопросы.

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

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

Игорь Рябец, Account / Business Development Manager, 20 лет в Softengi

До прихода в Softengi я работал программистом и руководителем группы разработки в американской компании, разрабатывающей ПО для предприятий лёгкой и текстильной промышленности. Офис компании находился в Майами, и у нас была действительно интернациональная команда: Украина, Индия, Сальвадор, Мексика.

В Softengi начал работать на должности старшего менеджера проектов.

Я так долго и с удовольствием работаю в одной компании, потому что здесь постоянно происходит что-то интересное, не дающее скучать. Либо приходит клиент из новой отрасли, либо с нестандартной задачей, либо в новой стране. В Softengi я работал с мобильными и web-приложениями, с самыми различными технологиями; с клиентами в сфере страхования, кредитования и управления рисками; с онлайн ноутбуками, системами массовых нотификаций и интернет-магазинами; с RFID-оборудованием, системами кардиомониторинга, камерами видеонаблюдения и системами для «умного дома»; мы разрабатывали системы дополненной реальности и занимались 3D-визуализациями.

Сейчас я работаю на должности руководителя подразделения европейских проектов. Моя задача — развивать бизнес компании в странах Европы.

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

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

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

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

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

Мирослав Бараненко, Central Art Development Director, 15 лет в «Перша студия» / Wargaming.net

Я начинал карьеру в крошечной игровой студии White Linx. Там проработал полгода, пока у ребят не начались финансовые трудности. Затем перешел в Persha Studia, которая на тот момент также была маленькой и начинающей. Тогда я учился на 3 курсе в НАУ на специалиста компьютерных систем и технологий. Специальность совершенно не привлекала, в отличие от компьютерных игр, которые увлекли меня по-настоящему.

В Persha Studia я пришел в конце 2002 на должность 3D-художника. В то время еще существовало разделение на моделлеров и текстурщиков, мало кто мог делать и то, и то одновременно. Тем не менее, со временем мы пришли к тому, что уметь нужно все.

До 2005 года я работал 3D-художником на разных проектах — как внутренних, так и аутсорсинговых. В 2005 году мне выпала возможность попробовать себя в роли Lead Artist. Это был довольно важный проект, в котором мы просели как по срокам, так и по качеству. Спасти весь проект не удалось, но тем не менее во мне увидели потенциал. В 2008 году я стал арт-директором и работал в основном над аутсорсинговыми проектами студии.

В 2009 году я получил должность Head of Art и стал менеджером всех артовых ресурсов компании. Когда в 2011 году мы стали частью Wargaming, я продолжил работать Head of Art. В 2013 году в Persha Studia был создан отдел Central Art, который создает 2D и 3D контент для игр Wargaming. Я занял позицию Development Director, чем и занимаюсь до сих пор.

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

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

Недостатки.За 15 лет я успел поработать над более чем 100 абсолютно разными проектами. Поэтому возможности закиснуть по причине однообразия работы у меня просто не было.

Желал ли я поменять работу?Мысли сменить работу бывают, но они появляются в период накопившейся усталости и уходят сразу после отпуска.

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

Михаил Чуб, Senior Test Manager / Head of QA Practice, 12 лет в Infopulse

До того как устроиться в Infopulse, я учился на 3-мкурсе ДГУ и работал в крупной IT-компании в Днепре — ISD. Меня взяли на позицию Junior Tester в команду, задачей которой было проведение тестирования интеграции между большими самодостаточными медицинскими системами. Зарплата поначалу была копеечная (40$), а команда — очень дружная.

В Infopulse пришел в 2004 году. По результатам собеседования мне предложили в 3 раза больше денег, позицию Middle Tester и командировку в Париж. Далее проекты менялись с периодичностью в год-два, и в большей части этих проектов я принимал участие в качестве Test Lead, Test Manager или руководителя группы.

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

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

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

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

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

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

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

Алексей Коваль, Head of Service Delivery, 11 лет в Cogniance

До Cogniance я работал в компании Sonopia, которая в какой-то момент плавно перетекла в компанию Cogniance :) В Sonopia пришел на 3-мкурсе университета на позицию Junior QA.

Карьера развивалась планомерно: QA инженер, Senior QA инженер, QA Lead. Затем осознал, что мне больше нравится общение с клиентами на уровне бизнеса и продукта в целом, чем техническое развитие, например, в автоматизацию тестирования, и потому стал расти как Project Manager, потом Program Manager и вот сейчас — Head of Service Delivery.

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

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

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

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

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

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

Андрей Яковенко, Team Lead, 10 лет в Exadel

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

Со временем мне захотелось поработать с иностранными заказчиками, и в 2007 году я перешел в донецкий офис Exadel на позицию Middle Java Developer. Офис только недавно открылся, на тот момент нас было всего 6 человек, и все мы работали на одном проекте для крупного банка.

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

Четыре года назад меня пригласили на проект Appery.ioв роли Team Lead. На нем я работаю и сейчас. Это самый крупный и сложный проект за всю мою карьеру: постоянный рост функциональности, огромное количество технологий, которые накладываются на сложности работы в распределенной команде. По мере роста было понятно, что следует оптимизировать организационные процессы, и мы начали внедрять Scrum.

Преимущества.Работа — это треть нашей жизни, и мне удалось сделать так, чтобы работа была для меня настоящим вторым домом: когда чувствуешь себя частью коллектива, когда приятно приходить на работу, когда митинг — это не рутина, а полезное занятие. Есть ли в этом моя личная заслуга? Наверное, есть. Я с удовольствием вспоминаю АМИ, у которой была своя неповторимая особенность (надеюсь, и сейчас сохранилась): не имеет значения, откуда ты и какая у тебя должность — к тебе всегда относятся, как к коллеге за соседним столом. Это именно то, что я пытался привнести в Exadel, и, как мне кажется, успешно.

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

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

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

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

Ярема Грицишин, Senior Customer Manager / Customer Experience Manager in Europe, 9 років в Lohika

До Lohika я працював Senior C++ Developer на InterObject. Lohika робила мені пропозицію двічі. Першого разу моє тодішнє керівництво переконало залишитись, а через рік я прийняв пропозицію.

Отже, я прийшов у компанію Lohika у вересні 2008 року Python-розробником, та через три місяці повернувся до С++. Після кількох проектів став керівником команди. В цій ролі я був ще на кількох успішних проектах. Пізніше на одному з акаунтів мені запропонували стати Customer Manger. Я не зустрічав такої позиції в інших компаніях. Вона об’єднує відповідальність Engineering Manager та Account Manager. Це був доволі складний, але цікавий час. У найгарячіший момент я відповідав за 7-хзамовників, для яких Lohika робила близько 15 проектів і було залучено приблизно 80 інженерів.

Близько двох років тому, мене підвищили до позиції Senior Customer Manager, і відповідальність змістилась більше до розвитку команди Customer Mangers у львівському офісі. Також до сфери відповідальності Senior Customer Managers входило розвиток і керівництво львівським інженерним офісом загалом. Близько року тому я також почав відповідати за Customer Experience Management у Європі по усіх наших локаціях. З моменту приєднання Lohika до Altran Group я також беру активну участь у взаємодії компаній у Європі.

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

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

Недоліки. Завжди є світлі і темні смуги в житті, і на роботі також.

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

Щодо подальших планів, наразі на ІТ-ринок України через Lohika заходить потужний гравець — Altran Group. За рік ми навчились працювати в новому середовищі і налагодили процеси залучення партнерів Altran Group в Україну. Це виклики зовсім нового рівня, які вимагають нових підходів. Хочу взяти у цьому активну участь.

Александр Кузьменко, Lead C# Developer, 9 лет в SimCorp

В SimCorp я пришел в 2008 году практически сразу после окончания университета. В то время IT-сфера только начинала развиваться и не была настолько популярна, как сегодня, и реального опыта программирования я не имел.

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

Спустя два года работы с языком APL я прошел обучение языку C# и пришел на проект, связанный с развитием Front office модуля. Изначально мне было довольно тяжело переключиться с функционального программирования на объектно-ориентированное, но все приходит с опытом. Позже мне удалось поучаствовать еще в одном интересном проекте — запуске круглосуточной поддержки клиентов. Я работал в немецком офисе компании над одними задачами с коллегой, который находился в Сиднее.

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

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

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

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

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

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

Влад Володин, Product Manager, 8 лет в EVO

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

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

Карьера развивалась очень активно, все-таки стартап :) За первые 4 месяца попробовал себя в роли контент-менеджера, редактора каталога, модератора и сотрудника службы поддержки пользователей, при этом оставался штатным эникейщиком. Через 4-5месяцев у меня был выбор, кем стать в рамках компании дальше: руководителем отдела модерации/саппорт или идти по пути развития в админы. Сделал выбор в пользу руководителя отдела модерации. В дальнейшем этот отдел стал департаментом, в котором было 7 отделов с 55 сотрудниками.

Еще через 2-2,5года стал руководителем отдела «Развитие каталога». Начал больше взаимодействовать с маркетингом и командой разработки. Со временем произошел плавный переход в Product, я начал подменять менеджера по продукту одной из команд во время отпуска или на части встреч. Поэтому когда открылась вакансия Product Manager, я попробовал заняться новым для себя направлением.

За все время было много вызовов. Был забавный случай, связанный с задачей по созданию моделей товара. У нас был показатель «успешности» этого направления. Руководство спрашивало нас, когда же мы добьемся выполнения этого показателя, и мы заявили что-то похожее на: «Осталось чуть-чуть, недели две. Мы уверены в этом так, что даже бриться не будем, пока не достигнем цели». По факту не брились мы месяца 3-4.Тогда весь офис смеялся с наших кривых бород :)

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

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

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

В планах — сделать поиск на портале лучше :) Это вызов самому себе.

Николай Харчевин, Team Lead, 8 лет в FilmOn

До того как прийти в FilmOn / 111 PIX UA, я костылял драйвера TDM для Sangoma и Digium, писал модули под Asterisk и OpenPBX, фрилансил на индусов, упражнялся в реализации SIP-стека для «Фарлеп».

В 111 PIX UA я должен был выполнять роль QT Application Developer (C++ программист). Буквально через пару месяцев так случилось, что эта роль трансформировалась лишь в малую долю должностных обязанностей.

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

В данный момент я исполняю обязанности лидера команды Web-разработки продукта FilmOn. За это время я выполнял роли разработчика встроенных систем, UNIX администратора, HR, QA, PM, TL. В одной конторе за 9 лет можно выучить 9 технологий, поработать с 9-юразличными проектами и командами — как кошка, прожить 9 жизней. Само собой, при условии, что вы не сидите на одной должности все 9 лет, а пытаетесь еще как то развиваться.

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

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

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

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

Мои профессиональные планы — получить CCA Spark & Hadoop. Построить вокруг дома забор. Купить выфер и уехать на Байкал :)

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

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

Сложность

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

Сразу скажу, я не претендую на какие-либо академические познания. Я — обычный руководитель небольшой софтверной компании. Однако я в этом бизнесе давно (уже больше 20 лет) и информацию искать вроде бы умею. Более того — я вообще интересуюсь Computer Science. В любом случае так я вижу ситуацию. Если я ошибаюсь, можете меня поправить — я открыт к новой информации.

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

В бизнесе все еще хуже. Со сложностью здесь никто не борется. Ею даже в чем-то гордятся — у нас тут все так сложно! Более того, если вы придете к вашему руководству и начнете объяснять, что сложность — это плохо, с ней надо бороться, упрощая и стандартизируя все и вся, вам скорее всего скажут: «Ты что, НЕ ТЯНЕШЬ?!». Да, у нас сложно. Но мы СПРАВЛЯЕМСЯ.

Проблема усложняется тем, что Enterprise-приложения растут как трава при дороге — без единого плана и вообще без какого-либо видения общей картины. Нам потребовался вот такой функционал — мы его запилили прямо здесь и сейчас, не думая о том, что этот функционал понадобится еще в нескольких других местах и там его придется либо делать заново, либо банально копипастить. Вынесение чего-либо в общие части (shared services) в большинстве случаев затруднено, так как выходит за пределы компетенции руководителей отделов заказчика — такая часть уже непонятно кем должна сопровождаться. В смысле — была часть системы, относящаяся к компетенции одного отдела и часть, относящаяся к другому отделу. А к чьей компетенции должна относиться общая часть? Уже непонятно.

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

Итак, что же я предлагаю делать с этой проблемой:

1. Взять цель на упрощение предметных областей, стандартизуя термины и их определения, отбрасывая дублирующие понятия и определяя все термины максимально жестко, без возможности многозначного трактования. Я понимаю, что компании привыкли работать в понятийном хаосе (не верите — почитайте документацию IBM, там ад виден прямо сразу), однако необходимость таких изменений даже не назрела, а перезрела.
2. Выделение ответственных. Я, как человек, который более 20 лет занят в разработке и более 15 лет руководит программистами, могу сказать точно одно: если для какого-то дела не назначены ответственные, то это дело с места не сдвинется НИКОГДА. И вопрос не в том, что люди плохие. Вопрос в том, что у всех есть своя работа, за которую с них и спрашивают. А за работу по упрощению предметной области, стандартизации, обмену информации и т. д. — ни с кого не спрашивают. Значит никто ею и не занимается, потому что всегда есть более важная работа. Так вот. Надо наконец признать проблему и выделять отдельных специалистов (группы специалистов), отвечающих именно за систему в целом. Только в этом случае мы можем рассчитывать на позитивные изменения.
3. Поддержание актуальности и полноты архитектурных документов. Если есть на свете что-то, что программисты любят меньше, чем писать юнит-тесты, — так это написание документации. Как часто шутят в Enterprise — программа отлично документирована на языке Java. Так вот, эта ситуация недопустима. Документирование системы должно стать важнейшей частью ее разработки. Архитектурные документы, особенно UML-диаграммы (с любой степенью детализации — от саб-систем до уровня кода) должны быть легко доступны любому разработчику и быть единственным источником информации по архитектуре приложения. Естественно, такой подход потребует разработки массы дополнительных правил и методик. И это дело не одной статьи. Однако начинать этим надо заниматься именно сейчас, а лучше — вчера. А не тогда, когда системы перестанут справляться с нагрузкой.
4. Стандартизация — одно из самых простых и отлично зарекомендовавших себя средств для борьбы со сложностью и гетерогенностью. Каждый, я думаю, прекрасно помнит, как 10 лет назад, входя в офис, кричали: «А у кого зарядка от маленькой нокии? Нет, плоская не подходит». Ничего, как-то стандартизовались — живем. Всем вроде бы удобнее стало. Меня же, честно говоря, несколько обескураживает то, что в нашей сфере процесс идет в обратную сторону. Вот, например, история интеграции. Вместо стандартной до скрежета зубовного CORBA, пришли более мягкие, но все же стандарты SOAP, а на смену им — REST, про который единственное, что можно сказать: «Это не протокол и не стандарт, а архитектурный стиль». Стиль такой. В смысле «я художник, я так вижу». И если интеграция REST с JS мордой или мобильным приложением выглядит ок (преимущества JSON для этой интеграции очевидны), то участившиеся в последнее время случаи интеграции В2В приложений с помощью REST выглядят совершенно не лучшим вариантом. Ну в любом случае стандартизация — наше все.
5. Обмен информацией — краеугольный камень решения самых тяжелых и неприятных проблем в разработке. Как показывает моя практика, разработчики крайне редко общаются на производственные темы с коллегами не из смежных проектов. Да и с коллегами из смежных — только по необходимости. Что я предлагаю сделать для исправления ситуации:
   
   • Кросс-командные митинги. Работа над любым проектом практически не бывает полностью ровной — чаще случается то густо, то пусто. Так вот, было бы хорошо тратить время, когда «пусто» на то, чтобы подготовить короткую презентацию архитектуры и основных технических решений для смежников. И обратиться к ним: «Хотите, мы вам расскажем про свой проект? Коротенько — на час-полтора, больше не надо». А потом попросить, чтобы вам презентовали свой проект. Слушатели будут заинтересованные — в конце концов, всем интересно, над чем работают коллеги из соседней комнаты, тем более если у вас еще есть и интеграция. Можно набраться каких-то знаний по типовым решениям, да плюс еще — блеснуть своими знаниями. Если проводить такие встречи достаточно часто, то обмен информацией внутри компании улучшится в разы.
   • Общие вики. В любой компании со временем накапливаются тонны информации по взаимодействию с легаси софтом заказчика, по правильному использованию сложившейся инфраструктуры с учетом ограничений секьюрити. Неприятно, что большинство этих мелких решений так и остаются в голове того, кто их нашел. Ну максимум — в своей команде. Естественно, такие знания надо аккумулировать и делать общедоступными (в рамках компании, конечно). Как по мне, самое удобное на этот момент решение — это движок вики. Насколько мне известно, во многих компаниях такие вики стоят, однако используются они крайне редко, и информация там бывает уже давно не актуальной. Как обычно, решение такой задачи упирается в отсутствие ответственных. Я бы предложил подчинить вики специалисту (или группе), отвечающему за общую архитектуру (я рассказывал об этом в пункте 1).
   • Обучение корпоративным стандартам. Никакая стандартизация невозможна, если непосредственные исполнители не знают о существовании стандарта. Вообще, я, как специалист по обучению, с грустью вынужден констатировать практически полное отсутствие работы в разработческих компаниях над образованием сотрудников. Обучение, которое проводится, часто делается для галочки, средствами собственных сотрудников и результат назвать, кроме как «из вторпродукта и палок», сложно. А если говорить о собственно обучении корпоративным стандартам... Ой, а они вообще в каждой компании существуют?

Монолитность

Монолитность в последние годы — любимый объект для борьбы (про страсть искать не там, где потерял, а там, где светло, я уже писал). Ну так вот. Тут место, где светло, точнее золотой молоток (прибегая к другой аналогии) нашелся. Это были... вы уже догадались? Да-да. Микросервисы, конечно.

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

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

1. Возникает дополнительная гетерогенность. В большинстве своем на SOA/микросервисы переводят не все Enterprise-приложение, а только небольшую его часть, а чаще всего — только один модуль. В результате монолитность всего приложения никуда не девается (от монолита откусили только маленький кусочек), а вот гетерогенность всей системы увеличилась. Нельзя сказать, что это так уж хорошо. Ну и мы можем прогнозировать, что с появлением новых подходов части проекта, сделанные на SOA/микросервисах так и останутся жить памятниками своего времени, как и кучи наслоений, сделанных на золотых молотках своего времени.
2. От введения дополнительной архитектуры в проект, сложность всего проекта явно не уменьшится. Более того, само приложение на микросервисах часто оказывается сложнее для понимания, чем монолитное.
3. Последняя проблема микросервисов и при этом самая важная, на мой взгляд, — такая архитектура не решает проблему монолитности сама по себе. Если архитектура микросервисного приложения не продумана, то на самом деле все проблемы просто поднимаются на сетевой уровень и прячутся от взгляда разработчиков. То есть если раньше разработчики вынуждены были думать над архитектурой хотя бы своего модуля, то теперь, когда модуль распался на кучу микросервисов, над их общей архитектурой можно не задумываться — так как непонятно, кто за все это вообще отвечает. Да, в теории должен отвечать тимлид или архитектор, однако я видел полно команд, где архитектора не было, а тимлид этим не волновался. Ну и все, уже модуль начинает расти как трава под забором, принимая все проблемы, перечисленные в первой статье.

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

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

Мои предложения по борьбе с монолитностью:

1. Официальное разделение частей бизнеса. Сложно добиться модульности Enterprise-приложения, если оно является полным отражением запутанного, как клубок ниток, бизнеса. В идеале необходимо добиться, чтобы интеграция между частями Enterprise-приложения, относящимися к ведению разных департаментов, происходила точно так же, с такой же глубиной документирования и стандартизацией, как интеграция с внешними системами.
2. Стандартизация способов интеграции. Вы уже, наверное, заметили, что я предлагаю все стандартизовать. И это действительно так. Если нам необходимо бороться с монстром в виде запутанного клубка взаимодействий разнородных частей, то давайте хотя бы добьемся, чтобы части были относительно стандартные и взаимодействие их было однотипным. Я имею в виду, если у вас все части интегрируются по SOAP, например, то давайте и новую интеграцию сделаем на нем же. Даже если SOAP тут явно избыточен.
3. Единый реестр микросервисов. Эту идею мне рассказал один слушатель во время выступления. Он сказал, что в их компании считается, что микросервис готов только тогда, когда автор завел его в общий реестр микросервисов компании. С полным описанием — что за сервис, какие у него интерфейсы, что он возвращает и что делает. Идея кажется мне просто гениальной. С одной стороны, сервис описывает сам автор, что предотвращает неверную трактовку (автор-то точно знает, что он написал... я надеюсь на это). Плюс к этому мы достаточно хорошо понижаем риск того, что готовая функциональность будет разрабатываться еще раз. Повышаем реюз готовых сервисов и еще много всякого хорошего. И все это ценой небольшого нытья программистов, что «неохота всю эту ерунду писать». Рекомендую делать также. Меня еще спрашивали: может, лучше сделать систему автоматического дискавера сервисов? Я считаю, что нет, не лучше. Как минимум вы потратите тонну времени на эту систему. Но программисты все равно напишут такой сервис, который будет дискавериться неверно. Плюс к этому — вы не получите комментариев от автора сервиса, а они часто — самое важное.
4. Даже если вы не хотите вести общий реестр микросервисов, в любом случае необходимо на уровне организации утвердить список необходимой информации, которая должна быть в документации по каждому микросервису.

Гетерогенность

Как я уже писал в первой части статьи, гетерогенность в большинстве случаев игнорируется и часто даже приветствуется как фича, а не баг, а то и ставится в заслугу. У нас тут столько всяких технологий на проекте!

А вообще мы знаем, как программисты борются с проблемой гетерогенности: у нас есть новый золотой молоток (new shining thing, по меткому выражению Роберта Мартина), так давайте все сделаем этим новым золотым молотком. А поскольку сейчас у нас любимый золотой молоток — микросервисы, так давайте все сделаем на микросервисах. Но о проблемах этого решения я писал в прошлой главе, повторяться не буду.

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

• Спринг навязывает стиль архитектуры. Сделать, например, rich domain model на спринге практически нереально (правда, как и на стеке Java EE). Эта проблема достойна отдельной статьи, если вам интересно, о чем я — напишите в комментариях, я тогда выдам свои мысли по поводу того, как современные Enterprise-стеки фреймворков издеваются над ООП.
• Spring настойчиво пытается проникнуть во все части приложения. Имейте в виду, если у вас завелся один фреймворк из стека Spring, то скоро все у вас будет на спринге, иначе вы замучаетесь все это увязывать. С одной стороны, хорошо — стандартизация же. А с другой — выглядит, как весьма некрасивый способ конкурировать.
• Spring становится все более монструозным. Изначально он делался как более простая и легкая альтернатива стеку Java EE. В результате получилось, что Java EE уже в разы проще.

Мои предложения по борьбе с гетерогенностью:

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

Интеграция

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

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

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

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

Объемы данных

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

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

Как у любого инструмента, у решений Big Data есть и свои проблемы:

• Внося в большую Enterprise-систему еще и решения на Big Data, мы увеличиваем что? Естественно, гетерогенность. Мы же не можем всю систему переписать на Big Data и не можем стандартными средствами работать с большими данными. Значит в наш зоопарк завезли нового бегемотика.
• И, естественно, добавляя новый массив решений, мы повышаем сложность всей системы.

Поймите меня правильно, я не против никаких решений. Тем более таких новых, красивых, блестящих, да еще и расширяющих наши возможности обработки данных, как Big Data. Я против бездумного использования чего бы то ни было. И я против того, чтобы в любом инструменте видеть Silver Bullet.

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

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

Мои предложения по использованию технологий Big Data:

• Не каждая задача должна решаться на Big Data. Наоборот — на Big Data должны решаться только те задачи, которые ТОЛЬКО на ней и можно решить. Соответственно, на уровне системы должен быть определен список данных, с которыми мы будем работать инструментами Big Data. Эта часть должна быть четко инкапсулирована и защищена от всей остальной системы четко прописанным интерфейсом интеграции. Чтобы, не дай бог, другие части системы не лазали грязными руками в данные или вызывали не описанные в интерфейсе методы.
• Нужно для любых данных определить принцип устаревания, чтобы не хранились уже совершенно потерявшие актуальность терабайты не пойми чего, которые можно было заменить просто консолидированными данными. Тут полезно, наверное, вспомнить историю о том, как мы писали систему анализа посещений WAP сайта (да, это было очень давно). Так вот, вся аналитика, которую мы показывали, строилась на основе raw-данных. И делалось это чудовищно медленно, да еще плюс к этому данные забивали нашу реляционную базу. Слава богу, что в тот момент еще не было технологий Big Data, а то мы бы их безусловно использовали. Но это было давно, и мы были вынуждены пойти путем логики, а не грубой силы. И стали в результате вместо грязных данных хранить в базе консолидированные. Мало того, что мы теперь не забивали базу тоннами ненужных грязных данных, так и вся система начала работать практически мгновенно и перестала зависеть от времени накопления данных. К чему я все это? К тому, что иногда надо еще и пытаться обдумать задачу. А не бросаться решать ее в лоб, методом грубой силы.

Общие рекомендации

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

Итак, это своеобразный манифест здравого смысла.

Коммуникации — важнее технологий

Весь мой опыт приучил меня, что если в разработке проблема, то крайне редко это технологическая проблема. Да, так, конечно, бывает, и это благословенный момент, когда программист может развернуться во всю мощь своих сил. Однако в большинстве случаев проблема лежит в плоскости передачи и обработки информации. И как мы знаем по правилу Парето — 20 % усилий дают 80 % результата. Сосредоточиться надо именно на этих проблемах, чтобы получить более существенное улучшение в целом. Если мы посмотрим на список основных причин провалов IT-проектов, то практически все они тем или иным способом относятся к коммуникации между людьми. Вот это и надо исправлять.

Архитектурные решения — важнее используемых средств

Честно говоря, принятие решения о используемом стеке технологий ДО того, как приняты хоть какие-нибудь архитектурные решения, бич современного Software Engineering. Самое неприятное, что, если мы возьмем список тем любой разработческой конференции, мы увидим темы «о новых возможностях фреймворка Х», «использование нового языка Y в ... системах» и «новое API библиотеки Z». Но никогда не увидим «сложные случаи декомпозиции предметной области» или «определение подходящей технологии под готовые архитектурные решения». И надо сказать, что ситуация эта возникла не на ровном месте. Если мы вспомним, например, сверхпопулярный сейчас стек технологий Spring, то увидим, что именно стек технологий диктует нам архитектуру, а не наоборот: мы сможем использовать его на уже построенной архитектуре. И это, по-моему, дорога в тупик.

Стандартизация — важнее идеального соответствия инструмента задаче

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

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

Удачи!

[Про автора: Василь Милько, R&D директор SoftServe, створює нові технології для розумніших програм і машин. Працює з AR, VR, AI, NL, IoT, wearable biometry, security. За 15+ років в SoftServe створив Design Office, Технологічний Консалтинг та Консалтинг з Безпеки Інформації. Вплинув на дизайн одного з найпопулярніших у світі смартфонів, ко-дизайнив Embedded Java і .NET WPF]

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

Ми створили новий тип інтелекту, подібний і водночас значно відмінний від людського. Назвемо цей штучний інтелект Іншим. Інший інтелект здатен розпізнати та ідентифікувати більше мільярда людських облич. Це щось, чого людина точно не може. Скільки облич людський мозок може розпізнати та запам’ятати? Кілька тисяч? Менше ніж десять тисяч точно (такі собі розміри невеличкого містечка). Тож 1 000 000 000 супроти 10 000 — це не просто вражаюче. Це Інший тип інтелекту.

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

Чоловік без мозку

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

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

Тож чи правильну структуру мозку ми моделюємо з допомогою глибоких нейронних мереж?

Структура і функція

Numentaпрацює над репродукцією нової кори головного мозку (неокортексу) вже протягом десятиліття. Їхня технологія штучного інтелекту побудована на власній комп’ютеризованій теорії неокортексу, пов’язаній з ієрархічною тимчасовою пам’яттю, розрідженою розподіленою пам’яттю (SDM), розрідженими розподіленими представленням інформації (SDR), самоорганізаційною картою (SOM). Топологія комп’ютерних мереж відрізняється від основних глибинних перцептронів.

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

Блискавичне навчання

Зазвичай людині достатньо один раз побачити символ незнайомого алфавіту, щоб надалі впізнавати його. Навіть коли він змішаний з іншими відомими і невідомими знаками. Якщо людина один раз побачить такі нові предмети, як сеґвей чи говерборд, вона впізнаватиме їх завжди. Це називається блискавичним навчанням (One-Shot Learning). Ви один раз стикаєтеся з чимось, розумієте, що це нове для вас, запам’ятовуєте і в майбутньому завжди розпізнаєте. Достатньо один раз побачити, щоб запам’ятати. Лише один раз.

Пропоную ознайомитися з науковою працею про концептуальне навчаннячерез сеґвей чи будь-який невідомий символ з Omniglot. Нейронним мережам потрібні мільйони спроб, в той час як навчитися можна вже після першої. То ми моделюємо наш мозок по-іншому? Чи створюємо Інший інтелект на шляху створення штучного мозку?

Бог не будує прямими лініями

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

Подивіться на ці глибокі нейронні мережі GoogLeNetі MS ResNet. Зліва — моделі, створені [сконструйовані] людиною. Уявіть, як би вони виглядали, якби їх розробив [виростив] комп’ютер ...

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

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

Верховний алгоритм

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

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

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

До речі, темі штучного інтелекту буде присвячена частина виступів конференції IT Weekend Ukraine 2017, яка відбудеться наступного місяця в Києві.

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

Меня зовут Николай Антонов, я основатель и COO компании Provectus. Хочу поделиться с читателями DOU новостью об очень важном событии, которое произошло в жизни одесского IT-сообщества.

Мы открыли Atom Space, совместный социальный проект компании Provectusи IT2School. Это пространство для цифрового творчества и развития подростков возрастом от 14 до 18 лет, где будут все условия для изучения и освоения современных технологий.

Здесь подростки смогут бесплатно совершенствовать и применять свои знания в сферах Technology, Engineering и Math.

Идея

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

Мы хотим, чтобы дети прочувствовали, что IT — интересно и перспективно. Что здесь, в свои 14, они уже могут участвовать в проектах, создавать игры, приложения, собственные web-сайты, научатся работать в команде.

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

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

Ремонт частично тоже делаем своими руками

Реализация

Atom Space разделен на три зоны:

• Лекторий — место где будут проходить бесплатные лекции, семинары, мастер-классы и встречи с менторами. В том числе занятия по программе CodeClubUA и разработки преподавателей IT2School.
• Коворкинг — пространство с оборудованными рабочими местами для самостоятельного обучения и развития, где резиденты могут посвящать время самообучению до 4-хчасов в день.
• IT-Bootcamp — возможность обучаться и даже получить первый опыт на собственных проектах.

Первый проект в рамках IT-Bootcamp уже известен. Им станет известная видеоигра Arkanoid, куда будут добавлены интересные фишки и авторская графика. Команда собрана и уже готова приступать. Менторить ребят будет Дима Сафонов — С++ Developer компании Luxoft, по совместительству преподаватель-волонтер в IT2School.

Первая команда IT-Bootcamp

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

Собеседования резидентов проводила Анна Деревянко, СЕО в IT2School и PM в Atom Space. Они проходили 20, 21 и 24 июля. К нам поступило около 80 заявок, в основном это студенты КА «ШАГ», выпускники IT2School и учащиеся общеобразовательных школ.

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

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

Резидентом Atom Space может стать любой подросток, который стремится развивать свои знания и проявить себя.

Для этого необходимо:

• заполнить заявку резидента на сайте;
• пройти собеседование и получить карту резидента.

Карта резидента выдается сроком на 1 месяц и предоставляет право на бесплатное посещение всех мероприятий Atom Space, занятия в коворкинге и работу над проектами в IT-Bootcamp.

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

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

Для этого необходимо:

• заполнить заявку резидента на сайте;
• представить описание формата и тематики, а также указать желаемую дату и время проведения;
• получить подтверждение Atom Space и провести мероприятие/занятие.

Результаты

1 августа состоялся первый открытый Family Day для резидентов Atom Space и их родителей.
Мы вручили ребятам карты резидента, презентовали родителям наш проект, рассказали, как и чем он будет полезен, какие возможности он дает.

5 августа состоялось долгожданное официальное открытие, к которому мы так долго готовились. Свои карточки уже получили первые 40 резидентов и готовы приступить к обучению, еще 10 будут отобраны после 25 сентября.

Уже обновлен сайт, оборудованы места для занятий.

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

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

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

Открытие Atom Space

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

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

Мы находимся: Одесса, Обсерваторный пер., 2/6

По вопросам сотрудничества:
Анна Деревянко
+38 099 554 27 10

[«Fail review» — это сборник историй о рабочих провалах: что произошло, как исправляли и какие выводы сделали. Если есть, чем поделиться — приглашаем присылать свои истории на valentina@dou.ua]

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

Татьяна Гайдамака, Project Manager

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

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

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

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

Я немного растерялась. Странное начало интервью... Но все же ответила, что не всегда. То, что обычно я хожу в футболках, я на всякий случай умолчала.

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

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

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

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

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

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

— Ну, рассказывайте, что у вас там по компьютерам? — весело спросила она.

Вот именно так и сказала — «по компьютерам». Мне это «по компьютерам» потом еще долго вспоминалось.

Я уточнила, будет ли техническое собеседование здесь и с ней же.

— Ну, конечно! — удивленно воскликнула моя интервьюер. — Что я там не знаю в этих ваших интернетах, в этих ваших компьютерах? Ну, рассказываете.

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

Девушка откровенно скучала и в какой-то момент перебила и сказала:
— Ладно, расскажите, в каких программах вы умеете работать.
— Программах? — переспросила я, и тут же поняла, что базами данных её не удивить. Надо иметь еще какие-то скиллы, которые бы выделили меня среди кандидатов.
— В институте мы работали в 3D Max и Autocad, но я не много вынесла для себя из этих лекций.
— А еще?
Я стала заметно нервничать, так как совершенно не понимала, что именно ее интересует.
— Ну, редактор скриптов? — рискнула я.
— Блокнот что ли? — переспросила девушка.
— Ну, можно и блокнот, — ответила я, — но есть много более удобных программ.
— А нормальные офисные программы? — нетерпеливо спросила она.
— Я знаю практически весь пакет Microsoft Office (зачем-то у нас была практика в институте по всем этим программам, когда-то на первом курсе).

Тут девушка пристально посмотрела мне в глаза и зло прошипела:
— Зачем вообще вы сюда пришли? Вы же ничего не знаете! Вы совершенно не подходите! И даже сумочки у вас нет! (вот оно, ружье из первого акта).
— Чего я не знаю? — пропищала я.
— Ну как же! Ворд и Эксель! — она их так и произнесла, кириллицей. — Это же обязательно!
— Но я же сказала, что я знаю программы из пакета Microsoft Office, — возмутилась я.
— При чем тут пакеты! И вся та ерунда, про которую вы говорили! Как это поможет вам в работе? Вы понимаете, на какую ответственную должность вы претендуете?!
— Разработчика баз данных — ответила я. Ответ на этот вопрос я знала точно.
— Это кто? — она округлила глаза.
— Программист, — уточнила я более общим популярным словом.

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

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

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

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

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

Артем Кривокрисенко, Software Development Engineer

В далеком 2013 году, еще в Украине, я собеседовался в одном из лидеров рынка.

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

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

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

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

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

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

— В общем, я предлагаю вам XXX долларов в месяц (озвучил сумму, которая не окупит даже разовой поездки на метро) на испытательный срок, а после испытательного срока еще +XX долларов. Как вы смотрите на это предложение?
— Это, конечно, немного ниже, чем я рассчитывал, но думаю, что могу такой вариант рассмотреть, — я только сделал вид, что соглашаюсь, чтобы без палева можно было покинуть офис и добраться в безопасное место.
— Отлично, тогда пойдемте сейчас подпишем контракт, и вы через 2 недели выходите.

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

У чувака лицо вытянулось так, будто я отказывался от служебного Роллс-Ройса, и он выдал:
— Хорошо, но учтите, я не могу ждать долго! У меня тут очередь желающих поработать.

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

Ярослав Науменко, Freelance Project/Product Manager

Это было в мае 2011 года. Я тогда увольнялся с должности Head of IT department в Lafarge Gypsum Ukraine — это очень известная французская компания с мировым именем, крупнейший в мире производитель цемента и вообще стройматериалов. Они тогда продавали свой бизнес в Украине.

В поисках новой работы собеседовался в Microsoft Ukraine на должность Technical Account Manager. Там я общался с Алексеем — он как раз занимал эту должность раньше и, переводясь в другой департамент, рекомендовал меня, как passionate, strong and mature IT-менеджера :)

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

У меня было 3 собеседования: одно по скайпу и два в офисе на Жилянской. Часа по полтора каждое. Спрашивали немного по технологиям, но достаточно поверхностно, например, сколько у вас там было майкрософтовского в компании. Про проекты, опять же, только в разрезе технологий Microsoft. Оговаривали различные кейсы, как разруливал, почему так, а не иначе — в общем, стандартный набор при найме менеджера. С технологиями у меня все было ок, без вопросов. Но вот с технологическим стеком Microsoft беда — я переехал на Android и Mac, а от Windows отказался в любом проявлении, так как были обоснованные претензии в плане безопасности, удобства и т. д.

И вот, когда я к ним во второй раз приехал, вышел их главный Technical Account Manager, который меня второй раз собеседовал, сел на кресло и заявил:
— Что-то у тебя как-то passion мало... Не подходишь.

Напомню, девиз Microsoft: «Your potential — our passion».

А я же евангелист Android :) Даже на столе в переговорке лежал мой телефон первый Galaxy S и планшет Galaxy Tab. Вот он на них посмотрел и, видать, принял решение. Мне потом HR прислала официальное письмо с отказом.

Параллельно у меня велась серия собеседований на должность IT Project Manager в украинский филиал Honda. Тоже было 3 собеседования, на третье прилетал IT-менеджер Honda Europe Мартин. Мы с ним часа полтора проговорили: о планах, о виденьи, порядках в Lafarge (моем прошлом работодателе). Через пару дней HR-менеджер Honda перезвонила и сказала, что я был настолько идеальным кандидатом, что они не рискнули меня взять. Мол, будет скучно, через 3 месяца сбегу... В чем-то они были правы.

Апофеозом моей корпоративной жизни было интервью на позицию CIO в GlobalLogic Ukraine. Поговорил с HR, потом час с лишним с тогдашним CEO Владимиром Шаровым, отличный мужик :) И мне потом опять написал HR с отказом: мол не релевантный должности опыт, бла-бла, скучно в общем. После этого я понял, что перерос статус employee, и мне пора идти в свои проекты. Чем я последние 5,5 лет и занимаюсь с разным успехом.

Анастасия Свердлова, PCB Design Engineer

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

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

Сначала стандартные вопросы по резюме, а после начался треш: дают схему, тыкают пальцем:
— Что это?
— Это резистор.
— А это?
— Конденсатор...
— Невероятно! Она знает, как выглядят резисторы и конденсаторы! — это было сказано с таким восторгом и хлопаньем в ладошки, будто я сделала что-то невообразимое. И после каждого моего ответа были такие возгласы. Вопросы были банальные и очень простые, но я совсем сдулась к концу.

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

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

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

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

Стандартное обсуждение, но я объясняю, что специализируюсь на проектировании электроники, документацию оформляю, но не фанат, чтобы это делать 24/7. Менеджера все устраивает, и я приезжаю в конце недели на собеседование. Мне было очень интересно, ибо профиль разработок как раз по моей специализации. Но я же победитель по жизни :)

Мне рассказали о корпоративной культуре, показали устройства и начали демонстрировать чертежи всякие, 3D-модели. «Что это, блин, такое? Зачем мне показывают чертежи, я же не конструктор, я без понятия, как делать всякие ребра жесткости и прочую ерунду! Ладно, без паники, покажи ему свое портфолио».

Я вежливо старалась перетянуть тему на то, что в моей компетенции, начала показывать портфолио и объяснять, но после второй страницы собеседующий опять начал о своем... И это длилось 2 часа.

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

«Хьюстон, сос, сматываемся». Далее я все-таки рассказала о себе и начала объяснять разницу между инженером-электронщиком и инженером-конструктором, что теоретически я знакома с работой конструктора и умею делать некоторые вещи, но меня интересует вообще-то именно проектирование (о чем я говорила по телефону). Конечно, им просто нужна была девочка, чтобы документацию оформлять, но они потратили свое время и мое.

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

Я приехала и что вы думаете? Почти то же самое.
— Как это вы этого не знаете и этого не знаете? А почему вы только этим занимаетесь? Да неужели кому-то это нужно, нам же не выгодно держать человека, чтобы он только трассировал платы? Мы хотим, чтобы человек в офисе работал.
— Подождите-подождите, у меня указано гибкий график или неполная занятость. Вы хоть читали резюме?
— Да-да, мы оформляем по КЗоТ...

Я ушла и решила больше вообще не ходить на личные собеседования: хотят — пусть в скайп стучат.

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

Артем Быковец, Agile Coach & ScrumMaster

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

Кейс № 1. Мы искали Senior/Lead Automation QA, перебрали довольно много кандидатов. Тут HR приносит резюме еще одного человека, говорит, мы нашли его, вот он точно подойдет. Пригласили его на собеседование, с нашей стороны участвовали двое технических специалистов и я как Скрам-мастер.

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

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

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

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

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

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

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

Кейс № 2. Совсем недавно мы искали Senior/Lead JavaScript Developer на React. Знаю, у коллег такие поиски занимали по 5-6 месяцев.Да и мы потратили много времени. И вот, на нас вышел очередной кандидат. Хотел очень много денег — по верхнему краю вилки из статистики на DOU. Мы уже были готовы на всё, что угодно, лишь бы наконец закрыть вакансию.

Кандидат попросил, чтобы первое собеседование было по скайпу. С нашей стороны присутствовали 2 техлида и я. И вот, сидим втроем, к беседе подключается наш потенциальный коллега. Мы попросили:
— Включите, пожалуйста, камеру.
— Камеру? Мы о таком не договаривались. Я не одет.
— Ну ладно. Давай мы немного расскажем о проекте.
— Нет, давайте я сначала расскажу о себе.
— Окей.

По его словам, он такой весь из себя ниндзя в JavaScript. Не любит бэкендеров:
— Они вечно какую-то дрянь напишут, а ты сиди, разбирайся. Я люблю писать свое MiddleWare и с него брать данные. Сейчас покажу вам свой проект, — шарит нам на экран исходники, как он что-то там оптимизировал, как подключал библиотеки. И это при том, что до этого даже отказался назвать, в какой компании работал, сославшись на NDA.

Дальше мы начали спрашивать его какие-то базовые вещи о технологиях, и слышим, что он, кажется, гуглит. Упрекать его явно не хотелось: мало ли, вдруг он просто отвечает кому-то в чате. Говорим:
— Нам слышно, что вы клацаете по клавиатуре. Не могли бы вы не делать это?
— Нет, я тогда не смогу гуглить ответы на ваши вопросы.
— Здорово, вы претендуете на зарплату 4К+, и мы бы хотели, чтобы вы отвечали то, что вы знаете.
— А что, по-вашему, я должен всё это знать? Я же могу всё это быстро нагуглить — разве вам не подойдет такой человек?
— Когда будете работать, то, конечно, никто вам не запретит пользоваться гуглом. Но сейчас нам хотелось бы понимать ваш нынешний уровень, чтобы знать, за что вы хотите столько денег.

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

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

Кроме этих историй, были и другие веселые случаи. Как-то HR рассказывал о кандидате, который очень нервничал во время интервью. Ему дали маленькое тестовое задание, он отказался решать. Его начали уговаривать: «Ну попробуйте, вашего опыта должно хватить». А он: «Нет, я не буду, не давите на меня». Затем встал, взял стул, разбил стулом стекло в переговорке, вышел через дырку и ушел домой :)

Следующий выпуск рубрики «Fail review»будет посвящен взаимоотношениям с менеджментом. Если вам когда-то не повезло с менеджером со стороны компании или заказчика, расскажите нам об этом. Приглашаем присылать свои истории на valentina@dou.ua.

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

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

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

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

Кто мы?

Основной вопрос для каждой команды. Без понимания своей команды очень сложно сопоставить ожидание и реальность от ее действий.

Вы можете спросить себя:

• Сколько нас в команде?
• Насколько высок наш уровень подготовки?
• Каковы наши мотивы?

Этот вопрос помогает понять свою команду, ее возможности и ограничения. Если вы группа JS-девов, то вам вряд ли стоит браться за embedded-разработку. Так же как не имеет большого смысла отправлять человека с 15 годами опыта С++ разработки на разработку сайта для продажи кошачьего корма.

Если вы в команде единственный сеньор, а вокруг вас вертится стайка неокрепших морально джунов, то стоит придерживаться консервативных, хорошо известных техник и фреймворков. А не браться за самый новый стек технологий и загонять свою команду на пустынную страничку в Stack Overflow с вопросом без ответов: «A как же эта новая мегаштука должна парсить JSON?».

Где мы?

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

Необходимо понять тип проекта/продукта, над которым вы работаете. И на каком этапе разработки он находится. А также понимать состояние компании, в который вы работаете.

Попробуйте спросить себя:

• Мы делаем продукт?
• Мы работаем как аутсорс/аутстаф?
• Мы позиционируем себя как IT-consulting?
• Мы большая компания?
• Мы маленькая компания?
• Мы в начале/середине/конце большого/среднего/маленького проекта?
• Мы на этапе поддержки продукта?

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

Куда мы идем?

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

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

К примеру:

• Ожидается ли в ближайший месяц major release новой пачки фич?
• Должны ли мы как можно быстрее выпустить MVP?
• Когда ближайшее демо для стейкхолдеров?
• Должны ли мы за короткое время выйти в лайв и ожидать пачки багов для экстренного фикса от реальных клиентов?

Если все, что вас ожидает, это внутреннее демо для команды, то не стоит тратить слишком много времени на CI/CD и документацию. Но если вы делаете major release вашей библиотеки, который поломает половину старых API, — следует отнестись к документированию изменения как можно более серьезно.

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

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

Профит

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

К примеру, рассмотрим следующую ситуацию:

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

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

С другой стороны:

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

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

Еще один пример:

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

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

Сравните с такой ситуацией:

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

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

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

Итеративность

Процесс разработки ПО имеет итеративный характер, иногда. Соответственно, следует задавать себе 3 главных вопроса перед каждой итерацией.

Ответственность и лидерство

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

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

Вывод

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