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

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

Итак, поехали.

1. Нативный epoll транспорт для Linux

Первая и самая мощная оптимизация — это переключение на нативный epoll транспорт под Linux вместо Java реализации. В нетти сделать это довольно просто — достаточно лишь добавить одну зависимость в проект:

<dependency><groupId>io.netty</groupId><artifactId>netty-transport-native-epoll</artifactId><version>${netty.version}</version><classifier>linux-x86_64</classifier></dependency>

и автозаменой по коду осуществить замену следующих классов:

• NioEventLoopGroup → EpollEventLoopGroup
• NioEventLoop → EpollEventLoop
• NioServerSocketChannel → EpollServerSocketChannel
• NioSocketChannel → EpollSocketChannel

В нашем случае мы получили прирост в 30 % сразу после переключения. Детали.

2. Нативный OpenSSL

Безопасность — ключевой фактор для любого коммерческого проекта. Поэтому все, так или иначе, у себя в проектах используют https, ssl/tls. Раньше в java.securityпакете все было плохо и, что самое главное, медленно (да и сейчас не намного лучше). Поэтому классический сетап продакшн сервера в яве часто включал в себя nginx, который обрабатывает ssl/tls и отдает дешифрованный трафик уже в конечные приложения. С нетти этого делать не нужно. Так как в нетти есть готовые биндинги на нативные OpenSSL либы.

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

Для подключения нужно добавить 1 зависимость:

<dependency><groupId>io.netty</groupId><artifactId>netty-tcnative-boringssl-static</artifactId><version>${netty.boring.ssl.version}</version><classifier>${epoll.os}</classifier></dependency>

Указать в качестве провайдера SSL — OpenSSL:

return SslContextBuilder.forServer(serverCert, serverKey, serverPass)
                .sslProvider(SslProvider.OPENSSL)
                .build();

Добавить еще один обработчик в pipeline, если еще не добавили:

new SslHandler(engine)

Для нас прирост производительности составил ~15%. Детали.

3. Экономим на системных вызовах

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

for (PinState pinState : pinStates) {
    ctx.writeAndFlush(pinState);
}

Этот код можно оптимизировать:

for (PinState pinState : pinStates) {
    ctx.write(pinState);
}
ctx.flush();

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

4. Алоцируем меньше с помощью ByteBuf

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

ctx.writeAndFlush(
    new ResponseMessage(messageId, OK)
);

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

ByteBuf buf = ctx.alloc().buffer(3); //direct pooled buffers
buf.writeByte(messageId);
buf.writeShort(OK);
ctx.writeAndFlush(buf);

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

Pooled Direct Buffer очень оправданы, хоть и увеличивают сложность

5. Переиспользуем ByteBuf

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

for (Channel ch : targets) {
   ch.writeAndFlush(hardwareState);
}

Проблема тут в том, что сообщение hardwareStateбудет обработано в пайплайне для каждого из сокетов. Это можно оптимизировать, создав массив байтов для отправки 1 раз:

ByteBuf msg = makeResponse(hardwareState);
msg.retain(targets.size() - 1);
for (Channel ch : targets) {
   ch.writeAndFlush(msg);
   msg.resetReaderIndex();
}

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

6. ChannelPromise

Так как нетти асинхронна и реактивна, каждая операция записи в сокет возвращает Future. В нетти это специальный расширенный класс — ChannelPromise. Всегда, когда вы используете:

ctx.writeAndFlush(
    response
);

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

ctx.writeAndFlush(
    response, ctx.voidPromise()
);

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

7. @Sharable

Многие хендлеры в нетти не хранят никакого состояния. Такие хендлеры обычно помечены через аннотацию @Sharable. Это означает, что вместо постоянного создания таких хендлеров для каждого соединения:

void initChannel(SocketChannel ch) {
    ch.pipeline().addLast(new HttpServerCodec());
    ch.pipeline().addLast(new SharableHandler());
}

вы можете переиспользовать один и тот же объект (как синглтон):

SharableHandler sharableHandler = new SharableHandler();
...
void initChannel(SocketChannel ch) {
    ch.pipeline().addLast(new HttpServerCodec());
    ch.pipeline().addLast(sharableHandler);
}

Это может быть особенно критично для не keep-alive соединений.

8. Используем контекст

Сразу рассмотрим небольшой пример «плохого» кода:

ctx.channel().writeAndFlush(msg);

Его недостаток в том, что у вас есть в наличии контекст, а значит, вы можете выполнить:

ctx.writeAndFlush(msg);

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

9. Отключаем Leak Detection

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

ResourceLeakDetector.setLevel(ResourceLeakDetector.Level.DISABLED);

или через среду переменных:

-Dio.netty.leakDetection.level=DISABLED

10. Переиспользуем пулы событий

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

new ServerBootstrap().group(
    new EpollEventLoopGroup(1), 
    new EpollEventLoopGroup()
).bind(80);
new ServerBootstrap().group(
    new EpollEventLoopGroup(1), 
    new EpollEventLoopGroup()
).bind(443);

Его недостаток в том, что вы создаете больше потоков, чем вам на самом деле нужно. А значит, увеличиваете конкуренцию между потоками и потребляете больше памяти. К счастью, EventLoop можно переиспользовать:

EventLoopGroup boss = new EpollEventLoopGroup(1);
EventLoopGroup workers = new EpollEventLoopGroup();
new ServerBootstrap().group(
boss, 
   workers
).bind(80);
new ServerBootstrap().group(
boss, 
   workers
).bind(443);

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

О проекте

Наш проект Blynk — IoT-платформа с мобильными приложениями. Текущая нагрузка на систему 11000 рек-сек. 5000 девайсов постоянно в сети. Всего периодически подключается около 40K девайсов. Вся система обходится в 60 $ в мес.

Проект опен сорс. Глянуть можно тут.

Меня зовут Евгений Моспан, и я в IT с 2003 года. Начинал стажером в продуктовой компании, и за время работы там прошел путь от интерна до исполнительного директора. Когда челленджи в компании закончились, я перешел в ЕРАМ, чтобы разрабатывать продукты для заказчиков из крупного международного бизнеса. Моя роль роль — Solution Architect — как нельзя лучше подходит для инженера. Сегодня я расскажу о своем опыте работы над одним из таких продуктов.

Один из крупных клиентов ЕРАМ — логистическая компания, функционирующая в более чем 220 странах и территорий по всему миру. End-to-end продукт, над которым мы работаем, должен заменить все ее многочисленные front-office системы на одну современную, быструю и понятную пользователям. Система включает несколько тысяч полноценных Use Cases и при этом должна быть гибкой как в плане статического контента, так и бизнес-правил, которые сильно отличаются в зависимости от стран. Более 10 команд были распределены по ряду локаций.

Глобальный проект — это огромная ответственность

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

Компоненты имплементированы с помощью Play! Framework, Spring MVC, Adobe Experience Manager (AEM), есть компонент на слое баз данных, компонент для логирования и так далее. Front-end инженеры работают в основном с Angular JS; Back-end — помимо Spring, Play, AEM — должны ориентироваться в Quartz Scheduler, Terracotta; DBA-инженеры работают с базами данных Oracle. Есть также DevOps-ы, которые автоматизируют деплоймент с помощью Ansible.

На проекте с таким широким спектром технологий успешно работать могут только подготовленные и технически подкованные Solution Architects (SA) и Delivery Managers (DM). Архитектор должен понимать, куда какая функциональность будет добавлена и как это повлияет на систему в глобальном контексте. Delivery Manager, в свою очередь, должен правильно организовать работу распределенных команд и не допустить, чтобы они блокировали друг друга. Вообще, связка SA-DM на этом проекте очень плотная, так как надо постоянно быть on the same page и следить, чтобы все компоненты были развернуты в нужном объеме, нормально масштабировались и так далее.

С точки зрения архитектуры на проекте есть много quality-атрибутов, которые наш заказчик попросил учесть. Задача непростая, так как их сложно даже увязать между собой из-за возникающих противоречий. Например, клиент просит, чтобы перформанс приложения был end-to-end не более трех секунд. Это означает, что вся сложная функциональность и ее конфигурация должна быть уложена в эти три секунды. При этом, помимо системы, которую разрабатывает ЕРАМ, у заказчика есть еще множество других систем, с которыми интегрируется наш проект и с которыми надо считаться.

Или есть еще один quality-атрибут — доступность приложения по всему миру 24/7 и определенные ограничения по развертыванию. У клиента есть собственные data-центры, в которых и должны деплоиться приложения, а между ними должна быть реализована active-active репликация для обеспечения failover. Чтобы удовлетворить это требование, нам надо реплицировать огромные объемы данных фактически в режиме реального времени, что накладывает свои ограничения на базу данных и на то, как она должна быть спроектирована.

Вызовы мотивируют нас

Например, Play! Framework, который мы используем в одном из компонентов, не только дает реактивный подход к написанию бизнес-логики «из коробки», но и вносит сложности в имплементацию функциональности. Логика у нас последовательная, так как бизнес интересует end-to-end транзакция, а реактивный подход как раз предполагает событийную модель, поэтому инженерам и архитекторам пришлось придумывать способы, которые позволяли бы использовать преимущества реактивного подхода и в тоже время адресовать бизнес-цели, которые ставятся перед той или иной транзакцией. Отдельным вызовом было свести воедино Play-фреймворк и Spring Security, Spring Integration, Spring Cashable, Spring Data и другие фреймворки этой экосистемы, которые мы активно используем на проекте.

Что касается интерфейса пользователя, то мы довольно долго искали золотую середину между тем, что должно покрываться непосредственно платформой по управлению контентом (AEM), а что должно было быть бизнес-кодом самого front-end приложения, которое имплементируется на AngularJS и изменяется исключительно FE-разработчиками. Такой баланс был достигнут за счет того, что страница была разделена на CMS-компоненты, которые получили названия «транзакционные» и «статические». В итоге контент-авторам был предоставлен доступ только к компонентам последнего типа для управления контентом, который отображался конечному пользователю. Эти требования были довольно жесткими, ведь для разных стран нужен был контент разного формата и направленности. Транзакционные компоненты стали source-кодом самой системы.

В этом продукте нет простых задач в принципе

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

Нам необходима экспертиза во многих областях: человек, который управляет процессом разработки фичи, должен понимать АЕМ и AngularJS, все тонкости и специфику Java и его фреймворков, Нibernate, слой базы данных Oracle... Уложить это в голове одного инженера практически невозможно. Для справки: самый большой use case на этом проекте касался процесса отправки посылки и был описан клиентом на 90 страницах, разбит на почти столько же подкейсов, которые декомпозировали на порядка 1000 stories. За простой, на первый взгляд, работой лежит колоссальный объем функциональности, которая должна чем-то конфигурироваться.

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

Задачи Solution Architect

В таких условиях вовлеченность Solution Architect-а и его тесное взаимодействие с Delivery Manager-ами необходимо на протяжении всего проекта. Архитектура была сформулирована на high level летом 2015 года и с тех пор претерпевала лишь итерационные изменения. В ходе такого огромного проекта оказалось, что не всегда low level дизайн можно поручить тимлидам. Они руководят десяткой команд, в которых разработчики параллельно делают разный функционал и разные бизнес-задачи.

Вопрос: а все ли ребята понимают, что происходит в глобальном масштабе? Ясно, что «сторю» они сделают, а вот как она повлияет на другие stories и наши quality-атрибуты — это понятно далеко не всем.

На все подобные вопросы должен кто-то отвечать. За это взялась группа Solution Architecture, которая, помимо дизайна, сложных функциональных задач, адресования quality-атрибутов, несет своеобразную просветительскую миссию, объясняя, как нужно имплементировать задачи с точки зрения большой и требовательной экосистемы. В группу вошли техлиды, присоединившиеся к компании с рынка, и ребята, которые выросли на этом проекте. Некоторые инженеры решили, что им интересно развиваться в направление архитектуры, и я стал их ментором в рамках программ SA Mentoring и SA School. Постепенно наша команда стала мостом между бизнесом и имплементацией, конвертируя бизнес-требования в технические. Теперь и заказчик интересуется у нас, как любая новая функция повлияет на систему в целом.

С точки зрения масштабов проекта обеспечивать CI/CD довольно сложно, потому SA и DM-ысоздали прозрачный процесс, по которому происходит delivery. Любое изменение кода проходит долгий путь от разработки на локальной машине до развертывания в окружении: после разработки девелопер должен покрыть свой код unit интеграционными тестами, чтобы убедиться, что он не сломает процесс CI (разработчиков много, и мы пытаемся минимизировать количество коммитов, которые будут ломать билд). Код также проходит статистический анализ с помощью Sonar, ревью в Gerrit, куда интегрированы чеки от Sonar, запуск unit-тестов и сборка билда, чтобы обойтись без рутины и отсекать явные gap-ы. После того, как код попадает на CI, проходит билд всех артефактов и развертывание системы в целом. На этой системе запускается весь набор интеграционных тестов и Smoke end-to-end тестов от наших автоматизаторов. Если артефакт успешно проходит все quality gates (в которые входят также и требования quality-атрибутов, security, performance issues), а SonarQube не показывает новых issues, то этот артефакт считается зеленым и попадет к QA-инженерам, которые проводят мануальное тестирование фичи и дают рекомендации по автоматизации ее регрессии. Только после этого артефакт готов к развертыванию на следующих энвайронментах. На окружение заказчика мы деплоим его еще во время первой итерации, чтобы убедиться, что ничего не ломаем, а в конце каждого раунда формируем релиз-кандидат по каждой итерации. Важным quality gate является отсутствие critical, blocker и major issues в рамках того кода, что написан. Таким образом, для девелоперов у нас условия достаточно суровые, но это сделано именно из-за осознания масштабности системы.

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

Преодоление сложностей

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

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

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

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

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

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

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

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

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

В конце разработки команду ждал еще один вызов

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

Никто не понимал в чем было дело. Чтобы найти причину, пришлось вовлечь шесть инженеров, провести множество экспериментов и ввести процесс обработки таких issues.

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

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

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

Вместо вывода

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

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

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

В своем предыдущем посте «Как получить стажировку в США»я поделилась своими советами по поиску стажировки/работы в США для дизайнеров.

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

80 % наших клиентов — это большие enterprise компании, поэтому продукты довольно сложные и data-heavy. За последние 13 месяцев я работала над такими проектами, как smart home приложение, infotainment system для одного из самых крупных производителей автомобилей (NDA), финансовая платформа (отрисовала 140 дизайн компонентов:) и другие.

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

1. Workshop with client / Воркшоп с клиентом (2-3 дня)

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

Creating Persona / Создание «персон»

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

Это первый и основной этап в UX-процессе. Определите как минимум 2-3 персоны,укажите их пол, возраст, где работают. Какие у него проблемы, связанные с тематикой продукта вашего клиента? В какое время суток пользователь заходит на сайт/пользуется приложениями? И так далее. После того, как у вас будут ответы на всевозможные вопросы, дайте персонажам имена и фото.

Мы документируем всю информацию в заготовленные шаблоны в Sketch. Кстати, вот ссылка Personas Templateна довольно хороший шаблон, который я нашла на Dribbble. Но вы можете проявить всю свою фантазию и создать что-то получше.

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

Определение основных функций продукта и анализ конкурентов

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

Card Sorting (карточная сортировка) & Information Architecture (IA)

Карточная сортировка — это техника, которая используется для того, чтобы проанализировать и выстроить информационную архитектуру продукта. Для разных типов информации удобно использовать стикеры разного цвета. Приведу пример из работы над smart home приложением. Во время брейнсторма с клиентом на карточках желтого цвета мы поместили фичи продукта, на карточках зеленого цвета — smart home девайсы, а на карточках синего цвета — кастомизированные actions тех самых девайсов. Все эти карточки мы прикрепили на борд, а после перенесли всю информацию в digital site map. Наши клиенты активно принимали участие в процессе.

Пример Карточной сортировки, photo by Jessica Ivins

User Journey Map

Пользовательская карта — это анализ поведения пользователя во время первого знакомства с продуктом. Цель построения JM — помочь понять основные pain points юзера, какие эмоции он испытывает на определенных шагах. Основываясь на этой информации, можно улучшить опыт пользователя (UX) на самых ранних этапах разработки продукта.

Например, возьмем все тот же smart home application. Для JM мы взяли flow «Регистрация в приложении и настройка смарт девайсов». Мы предположили, что для некоторых пользователей будет довольно сложно настроить девайсы, следуя только инструкциям, которые шли в комплекте со смарт хабом. Поэтому мы добавили скрины с подсказками, фото и видео. Также добавили иллюстрации, чтоб создать более friendly настрой.

Ниже пример шаблона, который мы используем для Journey Map.

Пример шаблона для Journey Map

2. Backlog

После проведения воркшопа, у нас уже обычно имеется примерный список скринов продукта, фич, компонентов и т. д. Всю эту информацию мы добавляем в Backlog — Google Sheet документ, и выставляем приоритеты и estimates. В нем же мы и обновляем статус этих компонентов. Клиент также имеет доступ к этому документу.

Скриншот Backlog для финансовой платформы (140 компонентов)

3. Navigation Concept / Навигационный Концепт

Далее разрабатываем шаблоны/паттерны для разного типа скринов, которые возьмем за основу при разработке прототипа. Например, скрин Profile page будет иметь один паттерн, скрин со списком продуктов — другой, а скрин Edit mode — третий.

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

4. Wireframing / Прототип

Следующий шаг и один из ключевых — это разработка прототипа. Мы очень редко пропускаем этот этап. Единственный раз, когда мы его пропустили, — это был проект по разработке Infotainment system для автомобиля. У нас были очень сжатые сроки, поэтому мы основывали наш visual дизайн на паттернах, что я описала выше.

Существуют два типа прототипов:

Low fidelity прототипы — намного быстрее создаются и, как правило, являются инструментом для облегчения командной работы над проектом. Это могут быть наброски на бумаге или на whiteboard.

Low Fidelity прототип (travel app)

High fidelity прототипыотличаются более актуальным контентом, конкретными вариантами шрифтов и могут содержать более точную информацию о размерах изображений и даже стиле кнопок. Играем с оттенками серого, чтобы показать тонкости, которые можно увидеть только применив различные оттенки цвета, стиль навигации. В большинстве проектов мы разрабатываем именно high fidelity прототипы. Это в дальнейшем ускоряет разработку visual дизайна.

High Fidelity Wireframes & User Flow (приложение по производству шоколада)

5. Clickable prototype / Кликабельный прототип

Далее используем всем известное приложение InVision для создания кликабельного прототипа. Это очень облегчает объяснение взаимодействия и навигации внутри продукта еще до создания UI и верстки. Также это отличный способ коммуникации с клиентом. Можно в режиме оффлайн вести обсуждение, получать фидбек с помощью комментариев. InVision регулярно делает обновления и добавляет новые фичи, которые облегчают работу дизайнеров :)

6. Visual Design

Прежде чем приступить к разработке visual дизайна, мы показываем клиенту несколько типов Moodboards — Light, Medium and Dark. Получаем фидбек, в каком направлении им бы хотелось двигаться и уже начинаем работать над visual дизайном.

Dark Moodboard

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

7. Interaction Animations / Интерактивные анимации

Если мы предусматриваем нестандартный interaction между элементами, то в таком случае делаем анимацию в приложении Principle. Показываем ее не только клиенту, но и разработчикам при верстке продукта.

Interaction animation made in Principle app

8. Style Guide

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

Style Guide for Travel platform

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

P.S. Кому интересно, оставляю ссылку на свой Dribbble.

Привет! Я — Алексей Науменко, .NET Developer в Plarium Kharkiv. Я хочу рассказать о том, как начинал свою карьеру, и посоветовать, с чего разработчику начать изучение Unity.

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

Как я начал программировать

Я учился в ХАИ по специальности «Телекоммуникации». У нас был преподаватель, который конструировал беспилотники. Благодаря ему уже на 4-мкурсе я начал писать простой код на С для микроконтроллеров, которые управляют передачей данных с земли на БПЛА. Тогда я решил, что нужно выучить какой-то актуальный язык программирования, чтобы писать на нём постоянно, а не только для решения узких задач.

Выбирал я между С# и Java: читал книги по этим языкам, но потом просто открыл Visual Studio и Java IDE и сделал выбор в пользу первого по «обертке». Не самый правильный способ анализа преимуществ и недостатков, но о выборе я не жалею.

Почему пошел в геймдев и выбрал Unity

В 5–7классах мы с другом пытались сделать игру. И хотя получилась ерунда, романтика процесса осталась со мной. К тому же я люблю играть, особенно в древние RPG.

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

Многие разработчики используют Unity и Unreal Engine, но я хотел изучить все варианты. Поэтому я стал разбираться, на чем написаны популярные проекты. Оказалось, что это либо самописные движки, как, например, у Naughty Dog, либо движки, о которых очень мало информации в интернете — чтобы работать с ними, нужно, скорее всего, некоторое время работать в индустрии и знать хотя бы общие принципы построения игровых движков.

Я вернулся к выбору между Unity и Unreal Engine. И так как на тот момент я уже 4 года программировал на .NET, выбор был прост: в Unity есть C#, а в Unreal Engine — нет. Еще один плюс Unity: я погуглил некоторые интересные мне вопросы и почти на все из них нашел попытки ответить. Пусть не всегда профессиональные, но информация была, и было с кем ее обсудить.

У Unity есть аналог StackOverflow — Unity Answers. Там очень просто найти ответы на конкретные вопросы на начальном этапе, поэтому порог входа очень низкий, особенно если человек понимает хотя бы общие принципы программирования.

С чего начать обучение

Я изучал уже решенные задачи, похожие на те, что интересовали меня. Однажды я искал конкретное решение, но не нашел его в Asset Store. Поэтому начал мониторить форумы и наткнулся на парня, который делал именно то, что мне было нужно, но в Store его решение не пропустили по каким-то требованиям. Я написал ему сообщение и предложил купить его наработку. Он очень обрадовался возможности подзаработать — это был румынский десятиклассник. Чуть ли не лучшее мое вложение в изучение движка: 10$ плюс столько же за Swift-платеж.

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

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

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

Нет смысла изучать Unity просто так — стоит начинать с решения конкретных проектных задач. Лучше сразу определиться: «Я хочу сделать Pac-Man». Начинаешь думать, что для этого понадобится: например, нужно реализовать управление персонажем. Желтое существо ест белые точки. Существо должно понимать, что наткнулось на съедобный объект — значит, нужно начать с определения соприкосновения съедобной точки с Пакменом. Тогда появляется конкретная проблема и необходимость искать пути ее решения — а это, по-моему, и есть лучший способ изучения технологии.

Переход с .NET на Unity на практике

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

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

Иногда мы собеседуем Senior или Middle+ .NET программистов, которые не знакомы с Unity вообще. При этом человек не переходит на позицию Junior, потому что в Plarium, да и в работе с движком, нет понятия Unity Junior. Если с .NET всё хорошо, освоить движок будет очень просто.

Что почитать

Кроме Unity Answers есть еще UnifyWiki. Можно декомпилировать код и посмотреть результат (он не обфусцирован).

На старте очень пригодились форумы (answers.unity3d.comи forum.unity3d.com). Также я читал книгу Game Engine Architecture Джейсона Грегори. Автор в ней не говорит конкретно о Unity, но подробно рассматривает составные части и особенности игровых движков в целом. Он в деталях описывает, из чего состоит движок, какая математика нужна, как устроен рендеринг. Эта книга расширяет представление о Unity: я начал понимать, что в этом движке есть или должно быть, что с него спрашивать. Единственная трудность — для прочтения этой книги нужно быть очень мотивированным: она не нудная, но достаточно объемная.

Преимущества работы с Unity

Большие компании любят Unity за кроссплатформенность. Если ты что-то написал, оно билдится и под iOS, и под Android — пусть и с надстройками, но зато сразу работает без особых плясок. Конечно, если это не касается платежки :)

В нашем случае преимущество также в том, что Plarium — официальный партнер Unity с поддержкой уровня Enterprise Support. Нам не только быстро отвечают на запросы, но и предоставляют больше открытого кода, и мы можем сами что-то вскрыть и допилить.

Надеюсь, информация будет полезна тем, кто планирует работать с Unity. Успехов!

[Роботу опубліковано в рамках конкурсу статей на DOU]

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

З часу створення «Версії» пройшла чверть століття — привід згадати історію цього клубу з одним з його творців Раїсою Краєвою.

Нас було обрано часом

Раїса Краєва Image source

— Отже, з чого все починалося?

Як це часто буває, з випадковості. Так сталося, що 1992-гороку одразу п’ять проектів одеських громадських організацій пройшли попередній відбір в Фонді Сороса (нині «Міжнародний фонд «Відродження») і очікували одержати комп’ютерну техніку. А оскільки в Одесі завжди була актуальною ситуація: «це не світ тісний, це прошарок вузький», — то і зібралися вузьким колом лідери цих організацій: Борис Херсонський, Леонід Мендельсон, Олександр Моховиков, ми з Михайлом Кордонським та іншими членами тодішнього об’єднання «Перехрестя».

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

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

І ось тут мені спало на думку: «А що заважає нам все це робити разом з дітьми?»

— Але ми ж самі ще не особливо розбираємося.

— Так разом і будемо вчитися, тим більше, що це в наших традиціях!

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

Зараз, озираючись на чверть століття назад, я думаю, що не ми вибирали час і ситуацію, а навпаки, це Час обрав нас. У нашому суспільстві фактично було сформовано «соціальне замовлення» на «покоління IT» зразка 1990-х,і ми потрапили в потрібний час, в потрібне місце. Суджу про це хоча б тому, що практично одразу після рішення, що ми будемо робити «щось комп’ютерне», знайшовся Юрій Семенов, ідеолог і практик руху відкритого програмного забезпечення, який став першою серйозною професійною підтримкою нашого з Кордонським клубу, і з ним — дітям та підліткам. Незабаром підтяглися фідошники (прім. ред. — активні користувачі мережі Фідонет, яка була популярна у 90-хрр.)на чолі з Олегом Левченком і Олександром Івановим, які прямо-таки горіли бажанням допомогти «дивовижним дітям і їх дивним керівникам».

Михайло Кордонський — відомий одеський педагог та вихователь Image source

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

Дісталися аж до Білого дому

— А які це були вимоги?

Наприклад, Кордонський одразу поставив жорстку умову: ніяких ігор! (Батьки сьогоднішніх любителів гаджетів, ау!) Але як це забезпечити, не порушуючи прийняті у нас традиції відкритості. Знайшли оригінальне рішення. Спершу — повна довіра і «соціальний договір» з учасниками проекту (а це були діти 11-16 років).Але, якщо в логах знаходили сліди ігор, то «карався» комп’ютер строком на два тижні. А це — для всіх — втрата не просто можливості тикати по клавішах, а й реальних заробітків через зупинку робіт.

— І що це були за роботи?

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

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

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

Фідошники проводили в нашому клубі навіть цілі ночі (особливо, коли нас прихистила дитяча Театральна школа, що розмістилася в будівлі колишнього райкому партії). Налаштувати нашу примітивну техніку — було і для них викликом. Те, що зараз може зробити навіть підліток-програміст, тоді доводилося винаходити. Коли ми традиційно по середах виходили в IRC (текстовий чат, можна сказати), то бувало, що зв’язок рвався кожну хвилину. Зате скільки було щирої радості від того, що відкривається світ нових можливостей! Який кайф ми ловили, відстежуючи, як від сервера до сервера йшов сигнал: Одеса — Київ — Амстердам — ​​і через океан — кудись у Каліфорнію...

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

Доросле життя дитячому клубу

— Тобто все було по-дорослому?

Різниця у віці в нашому клубі не мала значення (і це в комп’ютерному світі зберігається донині); підлітки відразу потрапляли до великого світу захоплених людей, професіоналів, де діють певні правила, а головне, цінності, чого так не вистачає сьогодні «всеядному» Інтернету.

— А які були вимоги до тих, хто бажав потрапити до «Версії»?

А не було у нас ніякого відбору, крім природного. Прийти могла будь-яка дитина, але ми одразу давали зрозуміти, що правила клуба потрібно виконувати, в тому числі, і такі, як виносити сміття, підмітати і мити підлогу.

— А як проходило осягнення комп’ютерних наук?

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

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

Продукція клубу «Версія», 1996 рік

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

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

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

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

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

— Якщо підвести підсумки: що дала «Версія» IT-сектору?

За п’ять років активної роботи в клубі побувало мінімум 400 підлітків. Приблизно 70 з них так чи інакше використовували потім отримані навички для заробітку в дорослому житті. Близько 30 наших учнів стали професіоналами ІТ-сектору, бізнесменами.

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

Звичайно, цю розмову хотілося б проілюструвати фотографіями. Але у Раїси Краєвої їх немає:

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

Чверть століття потому дитячий комп’ютерний клуб «Версія» вже здається легендою. Як, втім, і вся історія становлення в Україні IT-сектору, яка чекає своїх дослідників і популяризаторів. Бесіда з Раїсою Краєвою — наш внесок до цієї Історії.

В рамках iForum 2017 года сооснователь и СТО сервиса для планирования путешествий TripMyDreamТарас Полищук рассказал, как и для чего они с коллегами перевели codebase проекта с PHP на Hack. Для читателей DOU, которые не присутствовали на конференции, Тарас изложил этот опыт в авторской статье.

В 2015 году мы запустили beta-версию TripMyDream — сервиса для поиска путешествий без агентств. Суть продукта — подбор выгодных комбинаций «перелет плюс отель» под бюджет пользователя. На первый взгляд задача не выглядит как rocket science, но на деле реализовать ее очень сложно. В этом нам помог язык Hacklang. Но прежде чем рассказывать о нем, объясню, какие задачи мы решали и почему искали именно такой язык.

Предыстория: какие задачи решал TripMyDream

Итак, мы начали тестировать идею и бизнес-модель, запустили beta-тестирование продукта. Много трафика привлекать не планировали, но сервис заинтересовал СМИ, и после ряда публикаций посетители стали заходить на сайт активным потоком. Посещаемость была такой, что каждый день в пиковые часы нагрузка на 8 серверах держалась на уровне 500%. Чтобы понять причины перегрузок, нужно немного углубиться в логику работы сервиса.

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

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

Почему не справился PHP

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

Отсутствие нативной асинхронности

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

Для асинхронизации могут быть использованы воркеры, работающие с очередью задач: например, Gearman или RabbitMq. Такой подход существенно улучшает ситуацию, но при этом вы все равно ограничены в количестве потоков. Каждый воркер скоро будет «съедать» по 30 MB оперативной памяти, и даже если взять сервер с 32 GB оперативной памяти, этих ресурсов хватит на сотню воркеров. Увеличивая объем памяти, проблему решить не получится: вы упретесь в процессорное время. Получается, что для выполнения длительных задач на PHP на одном сервере возникает ограничение в 100 параллельных потоков, если говорить про долгие потоки, блокирующие I/O.

Чрезмерный расход памяти

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

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

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

Мы пришли к выводу, что на PHP не получится решить поставленную задачу. Пришлось искать другое решение. При этом нужно было учитывать два важных обстоятельства. Первое: мы — стартап, а значит, не можем потратить пару месяцев на смену стэка. Каждый день — драгоценный. Второе: у нас была команда PHP-разработчиков, и решить задачу предстояло им. Я много общаюсь с нашими партнерами, коллегами, конкурентами, и знаю, что большинство решает подобные задачи либо с помощью node.js, либо с помощью Java. Но для перехода на node.js нам потребовалась бы новая команда из nodejs-девелоперов, т. к. в реальности PHP и node.js — это две параллельные вселенные.

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

Знакомство с Hack

Hack, он же Hacklang — это полноценный язык программирования, разработанный компанией Facebook. Начиналось все с трансляторов кода, когда лет пять назад Facebook представил HipHop Virtual Machine (HHVM), а ВКонтакте — транслятор Kitten PHP (kPHP). Спустя два года Facebook зарелизил полноценный язык программирования, разработанный под виртуальную машину HHVM, полностью совместимый с PHP.

Декларируемые цели языка — быстрая разработка без багов, быстрый runtime, масштабируемость, положительный опыт в написании кода. Утверждение о «быстрой разработке без багов» кажется фантастическим, но на деле оно очень даже похоже на правду. Hack предусматривает статический анализ кода, который и помогает избежать 99% ошибок еще до runtime. Я подробнее расскажу о нем позже.

Синтаксис Hack очень похож на PHP. Можно сказать, что Hacklang — это как PHP с дополнительным синтаксическим сахаром и новыми возможностями.

Пять преимуществ в пользу Hacklang

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

Типизация

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

Примитивные типы полностью пересекаются с PHP, за исключением типа void, который позволяет в коде просто написать return с точкой с запятой. При этом в Hack есть другие типы: mixed, nullable, arraykey, num и noreturn. Внимательные PHP-девелоперы могут возразить, что в PHP всегда был тип mixed, но на самом деле это псевдо-тип, используемый для описания языка.

Акцент в Hack ставится на разработку сильно типизированных и масштабируемых систем, в то время как PHP акцентируется на скорости разработки.

Коллекции

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

Map — типичный key-value контейнер, ключ которого может быть строкой или целым числом, а значение — любым.

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

Vector — самый типичный стэк. По сути, это массив, ключ которого является строго числовым и автоинкрементым.

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

Дженерики

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

Встроенный тайпчекер

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

Hack поддерживает три режима. Partial modeпозволяет совмещать codebase на PHP и Hack одновременно. Strict mode — это режим строгой типизации всего кода. В этом режиме тайпчекер проверяет абсолютно все файлы проекта и говорит об ошибках. Даже если в одном из сотни файлов будет ошибка, то весь проект в runtime выполняться не будет — идентично со строго типизированными языками. Мы принципиально пишем весь код именно в этом режиме. И, наконец, режим declarative modeполностью отключает тайпчекер.

JIT, just-in-time компиляция

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

Реализация асинхронности в Hacklang

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

Следует понимать, что это не многопоточная асинхронность, а однопоточная, так называемая однопоточная многозадачность. Работая в едином потоке, Hack позволяет запускать ряд задач параллельно. Для этой цели служит встроенный планировщик. Кроме того, между этими параллельными задачами можно переключаться. Используется парадигма async/await, которая позволяет декларировать функции асинхронными (с помощью async) и получать указатель на их выполнение (с помощью await). Разберемся, как это работает.

Существует ряд неблокирующих компонентов, встроенных в язык: AsyncMysql, Memcached, cUrl и потоки. Под определением «неблокирующие» имеется в виду время ожидания результата, время простоя, которое может быть использовано для выполнения других задач.

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

Для примера приведу задачу, которую легко решить на Javascript — с помощью обычных коллбеков — и достаточно сложно решить на PHP. Она нестандартная, но хорошо демонстрирует возможности Hacklang. Итак, допустим, необходимо каждую секунду отправлять параллельно ровно три API-запроса. Представим, что мы платим деньги за неограниченный доступ, но имеем всего три запроса в секунду. Четыре запроса в секунду отправить нельзя: это блокирует запросы следующей секунды. При получении ответа результат необходимо обрабатывать и сохранять. Время ответа API — от 0,5 до 5 секунд. И все должно работать в едином потоке одного процесса.

Как же это решается на Hack? На минуту вперед создается массив со слотами для async-функций каждого запроса — и запускается одновременно. На каждую секунду мы имеем по 3 функции. Итого, 180 слотов для выполнения функций. Каждая async-функция запускает асинхронный cURL со своим заданным callback. В каждой функции есть проверка, настало ли ее время выполнения. Когда планировщик попадает в async-функцию, время которой еще не пришло, он ставит её выполнение в конец очереди. Плюс небольшой слип, чтобы не перегружать процессор лишними циклами.

Дополнительные возможности для разработчика на Hack

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

Тип shape

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

Мемоизация

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

Constructor parameter promotion

Объявление свойств класса можно реализовать с помощью аргументов в конструкторе. Достаточно добавить к аргументам конструктора их видимость (private, protected, public).

Операторы Lambda, Null-safe, Pipe

Оператор Lambda ( ==>) для лямбда-функций. Помимо синтаксического сахара, он дает возможность использовать текущий scope в лямбда функциях без использования use.

Оператор Null-safe (?->) позволяет избежать дополнительных проверок на null-ность объекта, предоставляя возможность безопасного доступа к методам.

Оператор Pipe (|>) — синтаксический сахар, позволяющий избежать избыточного вложения вызовов функций.

Режим Repo Authoritative

Стандартно HHVM ведет себя так же, как PHP-движок: загружает и компилирует ход на лету. Режим Repo Authoritative позволяет сразу скомпилировать весь код в бинарный репозиторий, что сильно ускоряет работу на пиковых нагрузках.

Типы серверов FastCGI и Proxygen

В HHVM можно использовать два типа серверов: FastCGI и Proxygen. В первом случае мы видим стандартное использование, схожее с nginx + php-fastcgi. HHVM запускается независимо от web-серверов (apache, nginx и других). Во втором варианте виртуальная машина HHVM имеет встроенный полноценный web-сервер, который позволяет принимать запросы напрямую, исключая промежуточный web-сервер (например, nginx).

Встроенный шаблонизатор

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

IDE, фреймворк и другие «организационные моменты»

Когда мы начинали писать на Hack, еще не существовало полноценного IDE. Мы использовали phpStorm и допиливали в нем распознование Hack как PHP. Сейчас все стало гораздо проще: для знакомого многим компонентного IDE Atom существует компонент Nuclide, созданный Facebook. Он применяется для разработки на ряде языков, включая Hack. Безграничные возможности самого Atom превращают разработку на Hack в приятное времяпрепровождение.

Сейчас в числе слабых сторон можно назвать то, что в Hack отсутствует менеджер расширений и возможность устанавливать внешние экстеншены как таковые. При этом можно добавлять любые PHP-библиотеки через composer или совершать полуавтоматическую конвертацию в Hack-код. Собственно, мы так поступали с клиентами для Google Adwords, Mailchimp, Mandrill. Еще есть вариант скомпилировать свой код на C++ вместе с виртуальной машиной HHVM.

Еще один недостаток — отсутствие полноценного Framework. Если нужно написать плюс-минус стандартизированное MVC-решение,лучше использовать PHP с Yii2/Symfony. Если же вы хотите построить сервис или микросервис, где логика фреймворка заканчивается на роутере и коннекторах, стоит попробовать свои силы в написании на чистом Hack в strict mode. В partial modeвы можете смело совмещать и Hack, и PHP код.

Экосистема Hacklang не такая огромная, как у PHP, но она постоянно развивается. Еще два года назад документация была очень слабая, по многим пунктам просто перекидывала на документацию PHP. Сейчас подобных проблем нет. Можно рассчитывать на полноценный релиз каждые 8 недель, ночные сборки, хороший фидбек. Например, если вы нашли какой-то issue и запостили его в GitHub-репозитории Hack, ответ от одного из девелоперов, скорее всего, появится в течение суток. Если найти что-то стоящее и предложить коммит — его с радостью примут.

Полезные ресурсы: активный GitHub, 280 вопросов на Stackoverflow, официальная документация.

Что касается установки, для Ubuntu, Debian есть установка из готовых пакетов и возможность скомпилировать исходники с GIT. Для OSX — установка через brew и, опять же, возможность скомпилировать исходники с GIT. В случае с OSX бывают сложности установки (если делать это нативно без Docker), однако они длятся недолго, релизы с исправлениям выходят с постоянной частотой. Для других Linux-системы тоже возможно скомпилировать исходники. Существуют образы в Docker Hub, которые можно использовать для контейнеризации HHVM. Для Windows установка пакета пока невозможна, в разработке портирование с помощью MSVC.

Напоследок скажу о миграции. Если вы задумались о переходе на чистый Hack (без использования legacy php кода), то, опираясь на опыт TripMyDream, вам скорее всего придется писать код с нуля. Также для Hack существуют инструменты автомиграции кода из PHP в Hack, однако, используя их, вы можете не ощутить всех преимуществ разработки на чистом Hack. Для разработчиков процесс миграции происходит довольно легко. Уже через несколько недель PHP Developer свободно пишет на Hack, а совсем скоро он проектирует и пишет код полноценно, с измененной парадигмой.

Представляем вам новости из мира Ruby/Rails в нашем дайджесте за июнь!

Ознакомьтесь с последними обновлениями и функционалом Ruby/Rails, выясните, какие есть отличия языка Руби в американском и японском вариантах использования. Для тех, кто хотел, но не смог побывать на конференциях RubyC 2017 и RedDotRubyConf 2017 предлагается подборка видео докладов. Интервью с DHH о бизнесе, а с Aaron Patterson о будущем Ruby и BBQ. Эти и многие другие полезные новости специально для вас.

Почитать

5+1 Ruby Gems Which Can Cause You Troubles — список Ruby-гемов, с которыми нужно быть осторожным при разработке проекта, по мнению команды RUBYROIDlabs.

Working with Facebook using Devise, Omniauth, Koala and Rails 5 — сегодня социальные сети облегчают процесс авторизации на многие сайты. Как сделать простейшую аутентификацию через Facebook в приложении Rails расскажет эта статья.

On code readability in object-oriented languages — статья объясняет, как объектно-ориентированные языки помогают более четко выражать мысли и идеи в ограниченный набор слов.

Common Table Expressions in ActiveRecord: A Case Study of Quantiles — пример решения задачи Quantiles на стеке технологий Ruby on Rails 5.1, Arel, PostgreSQL 9.6. У автора получился подробный кейс стади с большим количеством примеров.

A Tale of Slow Pagination — у вас медленно работает pagination в приложении? Если вы пытались что-то с этим делать, но безрезультатно, рекомендуем к прочтению эту статью.

Продолжение сериистатей о Ruby 2.4, которые держат разработчиков в курсе о новом функционале и обновлениях в Ruby.

Ruby 2.4 added Hash#transform_values and its destructive version from Active Support

• Ruby 2.4 allows to customize suffix of the rotated log files
• Ruby 2.4 has deprecated toplevel constants TRUE, FALSE and NIL
• In Ruby 2.4, IPAddr#== and IPAddr#<=> do not throw exception for objects that can’t be converted to IPAddr

Why you should probably avoid mixins — статья объясняет, почему следует избегать использования примесей (mixins) в программировании.

How to deal with major Ruby on Rails upgrades (like moving from 4.1 to 5.1) — статья полезна для тех, кто до сих пор не обновил свои ‘Рельсы’. Вы сильно рискуете ребята. Команда gemnasiumделится опытом, как безболезненно выполнять такие обновления.

DeviseInvitable + Rails API — практический пример того, как использовать DeviseInvitable в Rails API без HTML шаблонов.

Power Moves: SQL Server on Linux, Rails, and Docker — в прошлом месяце Microsoft объявил предварительный показ следующей версии SQL Server. Это значительно упрощает работу с Docker, и Rails 5.1 также повышает интеграцию с SQL Server до рекордно высокого уровня. Учимся как все настроить.

Implementing Linear Regression using Ruby — основы машинного обучения. Пост о том, как реализовать Linear Regression на Ruby. Создаем модель, обучаем, и делаем прогнозы.

Implementing Classification using Logistic Regression in Ruby — и дальше основы машинного обучения. Туториал объясняет, как решить задачу классификации с помощью Logistic Regression, и да, примеры на Ruby.

How can I protect a user’s file uploads in Rails?— для сайтов, которые предоставляют платный цифровой контент важно иметь возможность давать доступ только тем пользователям, которые за него заплатили. Статья о том как с помощью Ruby on Rails и Paperclip реализовать такой функционал.

Add option for class_attribute default — предложение от David Heinemeier Hansson, как добавлять default значение для class_attribute в Rails.

Rails’ CurrentAttributes considered harmful — в этой статье, с множеством отсылок на другие ресурсы, автор бросает вызов коду DHH. CurrentAttributes код написанный DHH против явного Ryan Bigg кода.

GraphQL Ruby Error Handling — работа с ошибками в GraphQL.

Introduction to Scala for Rubyists — переход от Ruby way к Scala way.

Managing Rails tasks such as ’db:migrate’ and ’db:seed’ on Kubernetes while performing rolling deployments — решение, как развернуть приложение Rails на системе управления контейнерами Kubernetes.

Rails Development: Coding Conventions & Best Practices — статья с актуальными советами для начинающих по оформлению кода, именованию методов, процесса рефакторинга.

Validate Ruby objects with Active Model Validations — подключаем ActiveModel::Validations к не ActiveRecord объектам.

Helpful Resources for Your Rails App Upgrade — в продолжение темы обновления Rails приложений, в статье собраны некоторые из лучших чек листов, инструментов, руководств и статей по обновлению до разных версий Rails.

Learning Rails in 2017 — гайд, как лучше изучать Ruby on Rails, с множеством ссылок и закладок на полезные ресурсы.

7 ways to evaluate gems, and 1 crazy idea — добавляем в проекты только лучшее. В статье описывается 7 шагов для оценки гема.

Using prettier and rubocop in Ruby on Rails application to format JavaScript, CSS and Ruby files — туториал, как с помощью гемов prettierи rubocopв приложении Ruby on Rails поддерживать в порядке JavaScript, CSS и Ruby файлы.

Rails 5.1’s form_with vs. form_tag vs. form_for — сравнение ‘form_tag’, ‘form_for’ и ‘form_with’ с примерами кода.

Surveying gemspec file specifiers — вы все еще правите Gem::Specification#files руками? Тогда мы идем к вам :).

The 3 Tenets of Service Objects in Ruby on Rails — Активно используете Service Objects для того чтобы уменьшить количество кода в Controllers и Models? Тогда добро пожаловать в мир fat services [folder]! Автор книги Building a SaaS Ruby on Rails 5 поднимает это проблему в своей статье.

Rails 5.1 has dropped dependency on jQuery from the default stack — хорошие новости, Rails прощается с jQuery :).

Rails Quiz: XSS Edition — Думаете, вы знаете все о XSS? Все же проверьте свои знания, тест на 5 минут.

Faster Rails: Indexing Large Database Tables Without Downtime — статья является частью серии Faster Rails. В этом выпуске речь идет об индексировании больших таблиц базы данных без простоя.

Design Patterns & Ruby: The Template Method Pattern — поговорим про паттерн Template Method который позволяет определить ‘скелет’ алгоритма, оставив конкретную реализацию классам наследникам.

Creating a Heroku-like Deployment Solution with Docker — Как с помощью Docker, без каких либо дополнительных инструментов, создать решение для развертывания, подобное Heroku.

Building and Deploying Ruby Docker Images with CircleCI and Heroku — в статье рассматривается, как настроить Ruby приложение для развертывания в качестве контейнера Docker на Heroku с использованием CircleCI.

Build your first server-side rendered React app with Rails — замечательный tutorial по созданию Rails-React server-side rendering приложений.

Upgrading Shopify to Rails 5 — история обновления Shopify monolith — одного из старейших и крупнейших приложений на Rails — от версии Ruby on Rails 4.2 до 5.0.

Speeding Up Rendering Rails Pages with render_async — предложение от Semaphoreci, как ускорить рендеринг страниц в Rails приложении.

Speed up bundle install with this one trick — автор предлагает способ ускорения загрузки гемов с помощью специфических настроек bundler.

Making a Rails App Move Faster: A Tale of Lessons Learned — иной подход, как найти медленные запросы в Rails и сделать так, чтобы они перестали быть медленными.

A Story of Passion and Hash Tables — как создавалась адресация для хэш-таблиц в Ruby 2.4.0 для получения дополнительной скорости.

Private files for your Rails app using S3 — настраиваем S3 для Paperclip.

Adding Read Replicas in a Production Ruby on Rails System with Zero Downtime — когда все запросы к БД оптимизированы и все необходимые индексы к таблицам добавлены но этого все равно недостаточно, чтобы выдерживать нагрузку на систему, необходимы координальные изменения того, как данные проходят через эту систему. Автор делится опытом, который приобрел при решении такой задачи.

RSpec — туториал о RSpec matchers, пользе их применения и каким образом они облегчают работу.

Making RSpec Feature Tests More Semantic By Dividing Scenarios Into Sections — туториал о том, как делать функциональные тесты на RSpec более семантичными, разбивая сценарии на разделы.

Test critical paths in your app with ease thanks to Dependency Injection — с помощью шаблона программирования Dependency Injection можно протестировать потенциально неудобный для тестирования код. В статье рассматривается сценарий теста.

Headless Capybara Feature Specs with Chrome — рекомендации, как значительно ускорить процесс тестирования с помощью ChromeDriver. Автор предупреждает, что использование ChromeDriver все еще находится на экспериментальном этапе.

Testing cookies in Rails — пример, как писать тесты на cookies в Rails приложении.

Unit testing ActionCable channels with RSpec — Rails 5.1 не имеет официальной поддержки для тестирования ActionCable. Автор дает пример как писать unit тесты на single channel action.

Acceptance testing using actors/personas — пример того, как можно креативно подходить к написанию приемочных автотестов, автор делится интересным опытом, статья достойна внимания.

Rails Helper Testing Made Simple — советы с примерами, как не нагромождать Rails helpers при разработке web-приложения и быть организованным в процессе их тестирования.

Are you Spying on me? A quick overview of Spies in RSpec — Автор демонстрирует как внедрить ‘шпиона’ в труднодоступный код с целью протестировать его.

Ruby on Rails отчеты в июне

This Week in Rails: class_attribute default, mini_racer and more!

This Week in Rails: default option for mattr_accessor, write_multi and more!

This Week in Rails: mailer configuration, perf improvement, and bug fixes!

This Week in Rails: 5.1.2.rc1 released and faster fixtures

RubyC 2017 reviews

RubyC 2017 video highlights!— 13 видео с докладами спикеров RubyC 2017.

RubyC-2017 photo review — фотоотчет RubyC 2017 на официальной странице в Facebook.

RubyC 2017 review — личные впечатления участника конференции от докладов.

Random

INTERVIEW: Aaron Patterson, Rack, Github and BBQ — интервью с Aaron Patterson — одним из самых уважаемых и высоко оцененных разработчиков в мире Ruby. В интервью он освещает разнообразные темы, начиная с ответов на вопросы о будущем Ruby и заканчивая своим любимым рецептом барбекю.

Developers Who Use Spaces Make More Money Than Those Who Use Tabs — бесконечный спор среди разработчиков, что лучше пробелы или табуляция, который является предметом многих дебатов и шуток. Статья проливает свет почему разработчикам стоит использовать пробелы вместо табуляции и предлагает инфографику того, как ситуация влияет на зарплаты разработчиков.

How is Ruby Different in Japan?— язык Ruby появился благодаря японцу Yukihiro Matsumoto, но оказывается американский стиль использования Ruby отличается от японского. Разбираемся, что общего и какие есть отличия.

David «DHH» Heinemeier Hansson: The Entrepreneurial and Unstoppable Stoic — интервью с David «DHH» Heinemeier Hansson, создателем Ruby on Rails, основателем и техническим директором Basecamp.

Послушать

The Bike Shed # 114: Reasonably Thread Safe — авторы подкаста The Bike Shedобсуждают возникновение крошечной DOS системы во время обновления сайта thoughtbot.comдо версии Rails 5.1. А также, в подкасте обсуждается, как Rails может лучше обрабатывать предупреждения, которые происходят только в конфигурации продукта.

Ruby Rogues # 313 Do I need a Front-End Framework?— авторы подкаста Ruby Rogues обсуждают frontend фреймворки в связке с Rails.

Ruby Rogues # 314 DynamoDB on Rails — DynamoDB — это облачная NoSQL база данных. Потратьте немного времени, чтобы узнать больше о DynamoDB и какие задачи можно решать с помощью этого инструмента.

Подборка подкастов от RWpodза июнь:

• 22 выпуск 05 сезона. Exploring Sinatra, Rails DB, Goodbye PNaCl, Hello WebAssembly, Amplitude.js, Timeline.js и прочее
• 23 выпуск 05 сезона. Node v8.1.0, V8 Release 6.0, ESLint v4.0.0, Rendering Rails Pages with render_async, N + 1 Control и прочее
• 24 выпуск 05 сезона. MJIT, Atom 1.18, From Rails to Hanami, Full Stack Automation with Ruby, Spected и прочее
• 25 выпуск 05 сезона. Upgrading shopify to rails 5, Webpack 3, Service Worker gotchas, Rufo, Bojler, Sonar и прочее

Посмотреть

AmberCasts #1 Ruby on Rails development environment with Docker and docker-compose — скринкаст с инструкциями, как настроить среду локальной веб-разработки с помощью Docker и docker-compose.

From Rails to serverless, via DDD and microservices by Andrzej Krzywda — выступление Andrzej Krzywda, основателя и исполнительного директора компании Arkency, на митапе #pivorak. Andrzej говорит о бессерверной архитектуре приложений и как она связана с Rails, DDD и микросервисами.

RedDotRubyConf 2017 — видео выступлений с конференции RedDotRubyConf 2017, которая проходила с 22 по 23 июня в Сингапуре. Среди выступающих звезды Ruby-сообщества — Yukihiro Matsumoto, Tim Riley, Aaron Patterson и многие другие.

GoRails: Charts with Chartkick and Groupdate — очередной скринкаст от GoRails о добавлении различных типов диаграмм в приложение Rails с помощью Chartkick и использовании Groupdate для упрощения групповых запросов в SQL.

GoRails: Analytics with Segment | Preview — еще один скринкаст от GoRails. Скринкаст о том, как отслеживать пользователей и действия, которые они предпринимают в вашем Rails приложении, а затем, используя Segment, отправлять их различным сторонним службам.

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

Ruby on Rails релизы в июне:

• Rails 4.2.9 — полное исправление ошибок. Теперь версия Rails 4.2 будет получать новые релизы только в случае серьезных проблем с безопасностью. Изменения для каждого гема представлены в ченджлогах на GitHub. Все коммиты на GitHub дают полный список изменений.
• Rails 5.0.4 — релиз Rails версии 5.0.4. Все изменения, которые произошли с момента выпуска Rails 5.0.3 можно проверить на GitHub.
• Rails 5.1.2 — версия Rails 5.1.2. Полный список изменений можно найти по ссылке на GitHub.

Rubygems Monthly: Sinatra 2, Bundler 1.15, Rubocop, CanCanCan 2, Devise, Puma and ActsAsTaggableOn 5 — команда gemnasiumнедавнозапустила рубрику Rubygems Monthly, где делится подборкой релизов Ruby-гемов.

RubyInstaller 2.4.1-1 released — обновление для RubyInstaller на Windows.

JRuby 9.1.12.0 Released — последнее обновление для JRuby.

GitHub::Palkan: N_plus_one_control — RSpec и Minitest matchers для предотвращения проблем с запросами N + 1.

GitHub::Palkan: Anyway_config — библиотеки Ruby и настройки приложений на Steroids, инструмент, который позволяет загружать параметры из разных источников: YAML, Rails secrets, environment.

GitHub::BaseSecrete: Redis_dashboard — web-приложение для Sinatra, отображающее информацию о серверах Redis, которое можно запускать самостоятельно или внутри приложения Rails.

GitHub::Jakewmeyer: Ruby-Scripts — собрание скриптов Ruby.

GitHub::Boazsegev: Iodine — быстрый веб-сервер с поддержкой многопоточности для real-time приложений Ruby.

Книги

Релизы:
Rails 5 Test Prescriptions: Build a Healthy Codebase — 25 ноября выйдет первое издание книги Rails 5 Test Prescriptions: Build a Healthy Codebase. Уже можно делать предварительный заказ.

Agile Web Development with Rails 5.1 — также 25 ноября выходит первое издание книги Agile Web Development with Rails 5.1. Предзаказ уже открыт.

Обновления:
Testing with RSpec book updated for 2017 — книга Everyday Rails Testing with RSpecбыла недавно переиздана. В обзоре перечислены все обновления и доработки, актуальные на 2017 год.

События

Ruby Meditation #16 — митап пройдет 15 июля в Одессе. Уже известны некоторые спикеры. Продажа билетов заканчивается 14 июля, для студентов есть скидка по промокоду, поторопитесь.

Rails Girls Bratislava — пятая конференция Rails Girls пройдет 22 июля в Братиславе, Словения. На сайте уже есть расписание. Не забудьте зарегистрироваться.

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

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

← Предыдущий выпуск: Ruby дайджест #6
<—Следующий выпуск: Ruby дайджест #8→ —>

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

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

IBM and Lightbend Announce Initiative to Build New Platform for Cognitive Development. IBM хочет выглядеть модно, стильно, молодежно.

Вышел Play 2.6.0.

Вышел Gradle 4.0.

Вышел Apache Commons Lang 3.6. Основная ценность релиза в поддержке Java 9.

Proposed Final Draft of Bean Validation 2.0.

JetBrains elected to the JCP Executive Committee. И начали они с голосования против.

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

Architect — это роль, а не должность.

Continuous Integration fundamentals.

Getting Started with Contract Tests.

A Basic Programming Pattern: Filter First, Map Later.

Develop and Deploy Microservices with JHipster. Проект уже давно не новый. Есть ли тут люди, которые его используют в продакшне? Как ощущения?

Language Framework Popularity: A Look at Java, June 2017от RedMonk.

Kotlin’s hidden costs. Вроде бы давно не было бенчмарков.

10 tips for migrating from Maven to Gradle.

What’s new in JPA 2.2 — Stream the result of a Query execution.

Java 9

JDK 9: Pitfalls For The Unwary. Все так волновались про модули, что даже забыли, что вывод версии Java поменял формат. Вангую много сообщений в стиле «установите джава 8 или выше» :)

jhsdb: A New Tool for JDK 9. Попытка собрать основные JDK-туллинг для траблшутинга в один флакон. Не уверен, хорошо это или плохо.

Oracle Defends the Java Module System.

Java Module Platform System (JSR 376) Passes the Public Review Reconsideration Ballot.

Proposed schedule change for JDK 9.

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

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

С 12 июня по 12 июля 2017 года мы проводили очередной анонимный зарплатный опрос, в котором приняли участие 8704 человека.

Исходные данные в CSV доступны на GitHub. Все зарплаты указаны в долларах США (по курсу межбанка), чистыми (после уплаты налогов). Для оценки зарплаты в выборках используется медиана. Статьи с результатами прошлых опросов здесь.

Портрет участников опроса

16,7% женщин, 83,3% мужчин.

Распределение анкет по возрасту, медиана — 27 лет:

Топ-7 городов: Киев (43,9%), Харьков (15,5%), Львов (11,4%), Днепр (7,6%), Одесса (5,4%), Винница (1,9%), Запорожье (1,4%). Удаленно работает 2,4% респондентов.

Уровень знания английского

Популярность должностей

Должности женщин

Должности студентов

Должности тех, кто работает удаленно

Средний возраст для разных должностей

Распределение возрастов Junior- и Senior-разработчиков:

Средний опыт работы для разных должностей

Популярность языков программирования

У Perl 7 анкет, Erlang и Flex/Flash — 5, Haskell и ABAP — 4, APL — 1.

См. также рейтинг языков программирования.

Среди тех, кто работает удаленно:

В стартапах программируют на:

Средний возраст разработчиков в зависимости от языка

Популярность вузов

См. также рейтинг вузов.

Распределение анкет по типам компаний

Распределение по предметным областям

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

Зарплаты по городам показаны для должностей, у которых 10+ анкет:

Киев (развернуть)

Харьков (развернуть)

Львов (развернуть)

Днепр (развернуть)

Одесса (развернуть)

Зарплаты Java, C# и C++ разработчиков

В Киеве (развернуть)

В Харькове (развернуть)

Во Львове (развернуть)

Зарплаты Java не-Android и Java Android разработчиков

В Киеве (развернуть)

Зарплаты Objective-C и Swift разработчиков

В Киеве (развернуть)

Зарплаты PHP, Python и Ruby разработчиков

В Киеве (развернуть)

Зарплаты JavaScript разработчиков

Зарплаты QA

В зависимости от специализации (Киев)

Зарплаты сисадминов и DevOps-инженеров

Зарплаты менеджеров

Есливыбрать только тех PM-ов, у которых 5+ лет опыт работы и английский выше среднего или продвинутый:

Зарплаты выпускников вузов

По всем городам и должностям, учитываются анкеты тех, кто уже закончил учёбу, показываются вузы с 40+ анкет:

Зарплаты студентов вузов

Показываются вузы с 10+ анкет:

Тип компании

Следующий график построен для Киева:

Предметная область и зарплата

Senior Software Engineer, Киев:

Software Engineer, Киев:

Junior Software Engineer, Киев:

Динамика

Лучше всего смотреть страницу Динамиказарплатного раздела с интерактивными графиками. Вот несколько графиков оттуда (по всем городам):

Java

C#/.NET

PHP

JavaScript

QA

Менеджмент

Уже много месяцев подряд больше всего откликов приходит на PM-вакансии. Возможно, это и приводит к снижению зарплат PM’ов.

Подробную информацию с данными о количестве вакансий и откликов смотрите в разделе Тренды.

Интерактивный зарплатный виджет:

Альтернативные виджеты: doustatistic.byethost7.com, devua.seektable.com

Раздел Зарплаты с подробной информацией: jobs.dou.ua/salaries.

[Про автора: Юрій Савка — має 8+ років досвіду роботи в ІТ, наразі працює на посаді Senior Software Engineer в ResearchGate в Берліні, веде блог]

Уяви, що завтра тебе викинуть на вулицю

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

Коли востаннє ти був на співбесіді? Говорив з людьми не з позиції мега-архітектора, а простого смертного? Коли розбирався з чимось незнайомим, не пов’язаним з улюбленим десятирічним проектом?

Уяви, що завтра твій основний інструмент заіржавіє

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

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

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

Уяви, що завтра зникне твоя професія

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

Сьогодні уже щось запідозрили водії-далекобійники, але до декого доходить довше: нові і нові студенти влізають у стотисячні борги, щоб отримати диплом лікаря чи юриста в університеті Ліги плюща. Дві найповажніші професії з найвищою зарплатою — і два найперших кандидати якщо не на повне зникнення, то на зрізання вакансій десь на три чверті. Експертні системи можуть робити брудну паперову роботу, якою в більшості зайняті лікарі та юристи, набагато швидше і у рази дешевше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уяви, що зникне саме поняття професії

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

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

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

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

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

Уяви, що майбутнє настане вже завтра

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

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

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

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

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

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

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

Немного предыстории

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

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

Детально я все это описывал в моей предыдущей статье — на этом мы останавливаться не будем. Однако при взгляде на этот график резонно появляется вопрос: а что же делать сениору, который «взобрался» на плато 95/5?

Такой вопрос я слышу очень часто, но простого ответа у меня на него нет. Давайте есть этого слона по частям.

Эффект эскалатора

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

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

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

Я называю это эффектом эскалатора. Когда-то все было понятно и происходило практически само по себе: джун дорастал до мида, а мид — до сениора. Эскалатор двигался. У кого-то быстрее, у кого-то медленнее, но у всех только вверх. И тут — «плато»! Оказалось, что на определенном этапе эскалатор заканчивается. И когда приходит осознание этого факта, инженер чувствует, что отсутствуют две привычные ему ранее вещи:

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

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

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

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

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

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

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

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

1. Если сложностей нет — надо их создать! А потом решить! И часто это может выглядеть вполне обоснованным. Например: «А давайте перейдем на новый фреймворк, так как старый себя уже изжил». (Изжил ли?)
2. С другой стороны, инженер может через какое-то время просто потерять интерес к проекту и работать на уровне мида. (Получая при этом, конечно, как сениор).
3. И самый неприятный случай — потерявший интерес инженер, не развиваясь сам, не дает развиваться остальным членам команды. «Ничего не трогайте. Вы ничего тут не смыслите. Никто не знает, как оно работает». (Или просто он уже забыл).

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

• как удержать/заменить ценного сотрудника?
• как поднять производительность команды на прежний уровень?
• как исправить климат и наладить командную работу?

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

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

Рука помощи

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

К счастью, менеджеру это вполне по силам, так как, по своей сути, его должность предполагает видение более целостной картины, а именно:

1. Менеджер должен понимать, куда именно хочет двигаться «готовый к полету» сениор.
2. Менеджер также должен правильно оценивать реальный профессиональный уровень специалиста: знать, насколько его хард- и софт-скиллы востребованы.
3. Менеджер должен видеть потенциальные потребности своего проекта. Например, пора ли вводить новую экспертизу.
4. Менеджер также должен понимать потребности своей компании. Об этом мы поговорим далее.

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

Примеры

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

Рост в лида / PMа

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

Новая экспертиза

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

Консультирование

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

Presale-активности

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

Тренинги / конференции

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

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

Фруктовый сад

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

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

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

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

Весь мир сегодня следит за тестированием беспилотных автомобилей — с одной стороны, беспилотный автомобиль выглядит фантастически, а, с другой стороны, практически все задумки фантастов уже тестируются, беспилотные системы управления реализуются, идеи и фантазии становятся реальной жизнью. Беспилотная тематика составляет значительную часть инновационных программ как международных концернов-гигантов — Volvo, BMW, General Motors, Toyota и др., так и инновационных IT-компаний — Uber, Google, Tesla.

Практические результаты появились и у украинских разработчиков, ориентированных на наукоемкие высокотехнологичные перспективные задачи. Тематика беспилотных наземных транспортных средств (БНТС) в течение последних нескольких лет является значительной частью работ нашей компании ИНФОКОМ ЛТД. Исследования в этом направлении базируются на 20-летнемопыте работ в области автоматизации промышленных процессов и позволяют квалифицированно и эффективно решать задачи роботизации, суть которых та же: собрать информацию, обработать («осмыслить»), выработать управляющее воздействие в объеме заданных ограничений (условий).

Идея

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

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

Реализация

За два с половиной года работы мы добились значительных результатов. Уже в 2015 году представили первую версию беспилотной системы управления. Первым тестовым вариантом был беспилотный ZAZ Lanos:

В силу особенности текущих обстоятельств для Украины — первоочередными прикладными задачами БНТС стало обеспечение реализации заданий по уменьшению рисков гибели человека в зонах военных действий, а также зонах чрезвычайных ситуаций, зонах стихийных бедствий — где действия машины обоснованы, выполнимы, минимизируют опасности для исполнителя:

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

Изначально заложенная масштабируемость и адаптируемость системы управления позволила эффективно применить ее к построению БНТС на базе Jeep Cherokee и военному КрАЗ Спартан:

За счет применения накопленного в области промышленной автоматизации опыта, где, собственно, требования к безопасности, надежности системы управления ответственными технологическими операциями, ничуть не меньше, чем в системах управления БНТС, были реализованы шаги подбора оборудования, приборов, IT-техники, разработки оригинального алгоритмического и программного обеспечения (ноу-хау разработчиков).

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

Технически система предусматривает дистанционное управление до 5 км с операторской станции (стационарной или мобильной), управление с планшета/смартфона или при помощи квадрокоптера (новый функционал).

В условиях прямой видимости БНТС (UGV) можно управлять при помощи определенных жестов, голосом и Smart-перчаткой.

Система управления разбита на следующие отдельные функциональные компоненты:

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

SmartRoad — компонента для работы в среде «умная дорога». Суть алгоритма заключается в идентификации дорожных знаков, уличного движения, направления движения благодаря установленным на них RFID-меткам, которые помогают системе быстро ориентироваться на местности, передают информацию об ограничениях. Это существенно упростит и скоординирует движение беспилотников по установленным маршрутам (особенно полезно для городского транспорта).

PilotDrive — система-помощник для водителя, непосредственно влияющая на ускорение/торможение, повороты.

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

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

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

• планшета, смартфона,
• умной перчатки (Smart glove),
• определенных жестов,
• голосовых команд.

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

Tech-in-Drive — часть программы, отвечающая за «обучаемость» системы управления.

Новый, последний по времени разработки, функционал — управление БНТС через квадрокоптер:

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

Результаты

В настоящее время система управления БНТС адаптирована для ZAZ Lanos, Jeep Cherokee, бронеавтомобиля КрАЗ Спартан. Но пока активный интерес к технологии проявляет только военная промышленность.

Наше украинское БНТС создано с учетом реалий украинских дорог — в перспективе какой-то особенной дороги для него не потребуется (хотя разработчикам больше нравится хорошая дорога). Сенсоры беспилотника имеют охват 360˚, что позволяет исключить «мертвые зоны» и видеть полную картину происходящего. Погодные условия также не помеха — сенсорные системы автомобиля надежно защищены от дождя и тумана. Датчики беспилотного автомобиля распознают дорожные знаки, ширину дороги, пешеходов, препятствия, животных — реакция на препятствие мгновенная. Система анализа позволяет реагировать в течение доли секунд. Работаем над распознаванием выбоин и прочих «сюрпризов» в пути.

Беспилотное будущее

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

Слева: беспилотный грузовик Volvo (без кабины водителя). Справа: боевая роботизированная платформа «ЛАСКА»

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

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

Что касается ИНФОКОМ ЛТД, в ближайших планах развития — компонента SmartTip в качестве отдельного приложения для смартфона (Android). Приложение будет работать как «умный видеорегистратор», помогающий водителю и контролирующий окружающую среду.

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

Александр Шевченко, Sr Dev Manager и Product Owner, 11 лет в Serena Software/Micro Focus

Непосредственно перед Serena Software/Micro Focus работал в компании «Интеллект-Сервис». Но не над M.E.Doc, который недавно прославился в истории с вирусом Petya, а над ERP-системой IS-PRO (конкурент 1С, Парус). Основной специализацией был C++ и SQL. На момент ухода был Lead’ом по разработке модуля «Управление персоналом».

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

Сперва попал на достаточно древний проект ChangeMan DS — это простенькая система контроля версий. По большей мере это была поддержка продукта, чем развитие. За первый год существования офис в Украине насчитывал всего около десяти разработчиков, и нам еще не спешили давать серьезные проекты. Думаю, присматривались к нашей квалификации. Спустя год с небольшим мне доверили руководить разработкой ChangeMan DS в Киеве. Кроме C++ пошла Java, и стали привлекать на проекты с использованием C#.

Через несколько лет нас «допустили» к разработке одного из флагманских продуктов компании — Dimensions CM, где я тружусь до сих пор.

Примерно в 2008 компания серьезно взялась за усовершенствование процессов и переход на Agile. Где-то с тех пор я стал «подрабатывать» Scrum Master в добавок к обязанностям тимлида и активному участию в разработке. Продолжал разбираться в тонкостях продукта, проявлял инициативу, брал ответственность и со временем перекочевал из Scrum Master в Product Owner. Примерно в то же время начал сдвигать акцент от разработки к управлению. В данный момент совмещаю роли Sr Dev Manager и Product Owner, но не упускаю возможности время от времени залезть в код.

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

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

Недостатки.Мне кажется, тут всё индивидуально. На собеседованиях, глядя на резюме «попрыгунов», у которых каждый год новая компания, я сразу предупреждаю, что карусели проектов у нас не будет. Каждый выбирает, что ему нравится. Некоторые любят небольшие проекты на год, максимум два, кому-то подавай только стартапы, Big data, AI. Мне нравятся долгоиграющие солидные проекты, нравится работать именно в продуктовой компании, нравится осознавать, что твой продукт используют такие монстры, как Lockheed Martin, BAE, Intel и многие другие.

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

Желал ли я поменять работу?Конечно, такие мысли бывали. Но, оценив все за и против — я всё ещё здесь :) Считаю, что менять ради того, чтобы лишь поменять, потому что уже 3-4-5 лет на одном месте — это неверно. Кстати, очень положительным знаком считаю то, что частенько покинувшие компанию коллеги возвращаются назад. Это заставляет задуматься: так ли хорошо там, где нас нет?

Продукт, который мы разрабатываем, просто огромен и продолжает разрастаться. Я бы не сказал, что за 9 лет на нём я его знаю досконально, как со стороны исходных текстов, так и со стороны пользователя. А разбираться в деталях я люблю. Так что ещё много интересного впереди ;)

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

Алексей Ильченко, Team Lead, 8 лет в CodeIT

До CodeIT по специальности работал в ООО «Хартэп», компании, ориентированной на госсектор. Там разрабатывал web-интерфейсы: получил интересный опыт, написал диплом. Но предприятия такого типа в Украине — не то место, где хочется задержаться программистам. В то же время брался за любые подработки в области web-разработки, в основном через знакомых.

В CodeIT пришел как Junior Web Developer или около того. Разделения по уровням у нас тогда не было. Начиналось все с типичных для Junior-разработчика подсобных задач. В то время web-разработчиков редко разделяли на Front-end и Back-end, так что была и верстка, и PHP. Позже стал вести проекты самостоятельно.

С ростом компании начал на некоторых проектах исполнять обязанности Dev Lead.
Пару лет назад мы запустили программу обучения в отделе Back-end разработки, которую я начал курировать. На данный момент развиваюсь в направлении Team Lead.

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

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

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

Желал ли я поменять работу?Нет, тут я пока нашел хороший баланс для себя. Иначе что б я тут так долго делал :)

В планах на ближайшее время — развиваться как Team Lead, расширять свой стек технологий.

Антон Чеботарев, C++ Software Architect, 9 лет с Materialise

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

До этого еще 2,5 месяца проработал младшим Java-разработчиком в запорожском «Укртелекоме». Первые полтора месяца работы мне ставили задачи по анализу данных, статистике и построению всяких графиков, а затем «идеи» по видам графиков у начальника закончились, и через месяц меня уволили. Как оказалось, это такой способ обойти совковые плановые увольнения: нанять студентов, чтобы уволить их перед Новым годом.

Сотрудничество с Materialise я начал будучи Junior C++ Software Engineer. Задачи, которыми я занимался, сейчас попадают под DevOps направление, от того, что делает Software Engineer там было совсем мало. Через полгода, на очередном follow-up c HR, я пожаловался, что мне не нравится то, чем я занимаюсь, и через неделю уже работал над другим проектом с настоящими C++ задачами :)

Дальше все пошло довольно динамично: больше опыта, больше задач, больше ответственности. В 2011 году я вырос до Professional уровня, в 2012-2014стал Lead-ом на проекте, консультировал по продукту, обучал новичков, отвечал за архитектуру.
В это же время пробовал себя в роли Project Manager на своем продукте, вроде успешно.

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

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

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

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

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

Желал ли я поменять работу?Когда у меня было желание что-то поменять — менял в работе с текущей компанией. Менять компанию — это не самоцель для меня.

Дальше буду развиваться в сторону Software Development и Architecture. Пробовал себя в роли Project Manager — но это пока что не мое.

Олександр Лукавий, PM, 10 років в InterLink

В студентські роки я фрілансив і розробляв дизайни для сайтів.

В InterLink починав з Junior QA Engineer. Проте мені це вдалось не з першого разу :) Після першої співбесіди мені порекомендували список літератури і побажали сил та натхнення. Жага до самовдосконалення зробила свою справу: пройшовши ще одне інтерв’ю, я потрапив на випробний термін.

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

Якось непомітно прийшло усвідомлення, що в моїх силах змінювати ситуацію навколо. Я спробував заповнити прогалину в процесі і вирішив спробувати себе в ролі бізнес-аналітика. Було важко. Але життя весь час вносило свої корективи, і я змушений був пильнувати команду, щоб не допустити помилок, котрі я вже раніше бачив, чув чи читав. Непомітно для себе я почав допомагати менеджеру в роботі з командами. І мені це подобалось, що не кажіть. Час йшов, проекти змінювались, я акумулював знання і змінив свій підпис в листах на Project Management Assistant, а згодом скоротив його до Project Manager :)

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

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

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

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

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

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

Алексей Тимченко, Technical Lead, 11 лет в TeamDev

До TeamDev я работал в небольшой харьковской компании «Алло-Контент», совмещая это с посещением первого и второго курсов университета. Программировал на Delphi, немного на PHP/Perl.

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

На моем первом проекте я работал рядовым членом команды. Со старта меня учили плавать без надувных утят: задачи были небольшими, но с самостоятельной проработкой. В первый месяц моего трудоустройства в TeamDev я писал плагины в wiki-подсистему. Все сложилось неплохо — через месяц я показал proof-of-concept, и мой испытательный срок был успешно пройден.

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

За последние годы изменился только масштаб. Я по-прежнему Technical Lead. Хотя к моим обязанностям периодически добавляются и другие — я отвечаю за Delivery, за коммуникацию с заказчиками, за архитектуру и прочее. При этом у меня всегда есть время заниматься прикладным программированием.

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

Преимущества.Компания для меня — семья. Без преувеличения.

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

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

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

Профессиональных планов много. Например — подружить Event Sourcing и Machine Learning в рамках текущих практических задач, выпустить несколько новых продуктов (в TeamDev есть продуктовые направления), научиться не издеваться над студентами на занятиях.

Андрей Чумаченко, CMO and Managing Partner, 10 лет в Netpeak

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

Спустя некоторое время штат компании расширился, и я стал руководителем отдела копирайтинга. Позже занялся SMM, сформировал свою команду под эту услугу. Затем какое-то время управлял услугами Usability и Landing Pages. После этого занял пост директора по развитию компании, потом был креативным директором, и вот сейчас — директор по маркетингу и управляющий партнер.

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

Мне нравится, что я делаю. За счет того, что раз в год-полтора меняю сферу обязанностей, мне не скучно, всё время идет развитие. К примеру, заняться SMM — это была моя инициатива. Ну а последние лет 5 менял должности не сколько по личному желанию, сколько по необходимости: в компании возникала потребность в развитии такого-то направления, и кому-то надо было «затыкать дыры». Так как я рос как широкопрофильный специалист, я мог это делать.

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

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

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

Работать в одной компании хорошо, когда она проходит разные циклы жизни. У меня так и получилось: я пришел, когда компания только зарождалась, и в тот момент застал «семейный» тип компании. С развитием Netpeak развивался и я. Сейчас мы международный холдинг (Netpeak Group), который в корне отличается от первоначальной системы корпоративного управления. И это круто. Поэтому, по сути, я работал в «разных» компаниях.

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

Сергій Бучнев, Software Developer, 8 років у MacPaw

Фактично MacPaw — моя перша робота. Я прийшов в компанію на 4-мукурсі університету. До цього трохи підпрацьовував: адміністрував мережу в гуртожитку, але нічого серйозного.

В MacPaw я влаштувався на позицію Software Developer. В компанії тоді працювало приблизно 10 людей: здебільшого всі друзі та знайомі.

В перші дні роботи я переважно сидів та натискав на клавіші, оскільки до цього не працював з macOS, і треба було розбиратися. Але згодом освоївся. Починав з проекту MacHider, потім долучився до робити над першим CleanMyMac. Далі був додаток Gemini та інші проекти.

Також був період, коли я 2 роки прожив у Львові та працював на MacPaw віддалено. Це був складний для мене час, адже на той час у місті майже не було розвиненої спільноти Mac-розробників, і я відчував деяку ізоляцію.

Якоїсь формальної градації посад у нас немає, тож моя позиція і досі називається Software Developer. Але, звичайно, на різних проектах — різна специфіка задач.

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

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

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

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

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

Марат Каменщиков, Team Leader, 10 лет в Svitla Systems

Перед Svitla Systems я учился и работал на небольшом проекте компании Panasonic Java-девелопером. Проект закрыли, и мой преподаватель сказал мне, что если я выучу RoR, у меня будет работа. Через три месяца меня взяли в Svitla: в 2007 я пришел на должность Junior RoR Developer. Профессионалом я себя почувствовал намного позже.

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

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

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

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

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

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

Евгений Биренбаум, HR-менеджер, 10 лет в Gameloft

До Gameloft я работал HR-менеджером в другой IT-компании. У нас была очень большая команда, которая занималась исключительно оценкой персонала. В 2007 году я увидел объявление, что в Украине открывается офис Gameloft, отправил резюме, прошел собеседования и таким образом попал в студию. Заинтересовало, что это продуктовая компания, и, как оказалось, мир GameDev сильно отличается от корпоративной разработки.

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

За эти 10 лет название моей должности осталось прежним — HR-менеджер, — но с ростом компании увеличивается круг и объем обязанностей, разнообразие задач.

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

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

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

Что касается дальнейшей карьеры, тут я не загадываю. Главное — держать руку на пульсе. Как известно, чуть больше года назад Gameloft был выкуплен гигантом развлекательной индустрии, компанией Vivendi. Постепенно мы вливаемся в их систему, и это открывает новые возможности и перспективы — не только для студии, но и для личного профессионального роста. Так что мое главное желание — черпать новые знания :)

Уявіть собі ситуацію, що вам потрібно за півроку відкрити два девелоперських центри чисельністю 130 ІТ-спеціалістів на ринку, де працюють R&D центри Amazon, Boeing, Intel, Lufthansa, Thomson Reuters, а ваш бренд роботодавця на ньому взагалі невідомий. З чого починати? Чим приваблювати спеціалістів? Які нюанси ринку праці потрібно знати?

Вроцлав

Саме в такій ситуації опинилася я зі своєю командою, коли у 2015 року у Ciklum було прийнято рішення відкрити два нових девелоперських центри у Гданську і Вроцлаві з початку 2016. Причому до цього я мала досвід у пошуці й підборі персоналу виключно на українському ринку. Я, як старший консультант з рекрутингу, мала адаптувати наші рекрутинг-процеси й практики до реалій польського ринку.

Ціль було досягнуто: команди було сформовано впродовж півроку з дня відкриття офісів у Гданську і Вроцлаві. Чи справді це так важко? Відповідь очевидна для тих, хто розуміє, що таке підбір сініорних Java, Scala, SAP/ABAP, JavaScript та Full-Stack .NET девелоперів у компанію з високими вимогами та зовсім невідомим брендом роботодавця на ринку Польщі. Ситуація ускладнювалась високою конкуренцією зі сторони потужних R&D центрів всесвітньо відомих продуктових компаній, вказаних вище.

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

Різниця між польськими та українськими IT-фахівцями

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

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

Юридичні відмінності, які важливо врахувати на етапах планування, бюджетування й управління очікуваннями клієнтів

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

У Польщі все зовсім по-іншому. Є варіант співпраці через B2B контракт, що передбачає реєстрацію ІТ-спеціаліста як підприємця, який надає послуги компанії-замовнику і за це отримує винагороду. З цієї винагороди фізична особа-підприємець обов’язково сплачує фіксований внесок у Фонд соціального страхування на рівні 1100 польських злотих (це приблизно 7 700 грн) в місяць на 19% подохідного податку (ставка може відрізнятись в залежності від обраної форми підприємницької діяльності). Бухгалтерія і звітність по такій діяльності здебільшого ведеться самостійно. З переваг, можна при купівлі ПК чи бензину віднести їх на баланс свого «підприємства», це дає змогу відшкодувати 23% ПДВ з вартості відповідного товару. Це свого роду форма підтримки малого підприємництва Республікою Польща, якою користуються і ІТ-спеціалісти. Тут, правда, відразу варто відмітити, що для іноземців, які потребують дозволу на роботу та візу відповідної категорії, це не варіант, бо нема підстав для реєстрації своєї підприємницької діяльності.

Саме тому більш детально зупинюсь на умовах працевлаштування по трудовому договору. Схема загалом складна, тому існують он-лайн калькулятори для вирахування фінальної суми, яку працівник отримує на руки. Наприклад, ось цей: www.pit.pl/...​kalkulator-placowy-14553.

В Польщі прогресивна система оподаткування: чим більше заробляєш, тим більше платиш. Відсоток подохідного податку, який стягується з працівника, коливається від 18% до 32% в залежності від суми окладу. Окрім цього, соціальні внески до різних фондів в сумі забирають ще 13,71% від зарплати брутто, якщо річний дохід до 118 770 польських злотих (це приблизно 830 000 грн). Від річного доходу понад цю суму соціальні внески вже будуть мінімальними.

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

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

Отже, податкове навантаження суттєво вище як на роботодавця, так і на працівника. Це впливає на середньостатистичний рівень зарплат в ІТ-галузі. Якщо ви — програміст, який хоче переїжджати до Польщі, то розраховуйте на зарплату брутто десь на 20% меншу за той рівень винагороди, який ви маєте в Україні. І ще врахуйте, що з окладу 30% піде на податки.

Це «ціна» громадського транспорту, який у Польщі ходить строго за графіком, та хорошого дорожнього покриття.

Культурні особливості рекрутингу

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

Працюючи у Польщі, також довелось змінити канали комунікації, перейти з онлайн режиму 24/7 у Skype на корпоративний мобільний зв’язок та ділову поштову переписку в робочі години. Беззаперечно останнє має свої переваги та водночас вимагає більшої включеності, сконцентрованості в робочі години та детального планування наперед. Пізнім пташкам також доведеться перебудувати свій біологічний годинник, оскільки найзручнішою годиною для співбесід з боку кандидатів була 8 ранку.

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

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

Прочитав серию от Adam Geitgey Machine Learning is fun, захотелось написать свою Hello World программу, которая может и не является настолько весёлой как та, что получилась у Адама, но достаточна познавательна в плане алгоритмов машинного обучения, проста в реализации и, надеюсь, будет интересна тем, кто посматривает в сторону машинного обучения.

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

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

В качестве алгоритма мы будем использовать старый добрый (и в тоже время достаточно простой) HOG алгоритм, предложенный Dalal and Triggs в 2005 году. Алгоритм долгое время носил почётное звание state-of-art и, будучи обученным даже на небольшом наборе данных, показывает впечатляющие результаты. Сейчас свёрточные нейронные сети (CNN) позволяют более качественно распознавать объекты, но они гораздо сложнее и требуют серьёзных вычислительных ресурсов, что для нашего простенького Hello World приложения, конечно же, не подходит.

Краткое описание алгоритма

HOG (Histogram Oriented Gradients) алгоритм является классическим алгоритмом обучения с учителем (supervised learning) и состоит из двух этапов: обучения модели (learning) и применение полученной модели к новым данным (prediction). Алгоритм использует слайдинг окно, которое, перемещаясь по изображению, генерирует вектор признаков (feature vector). На этапе обучения модели сгенерированный вектор признаков используется в качестве входных данных для SVM классификатора. Участки изображения, обрамленные в красные прямоугольники, представляют наш целевой объект — автомобиль (positive labels), вся остальная часть изображения — negative labels. Далее, на этапе prediction, обученная модель для каждого положения слайдинг окна формирует число (score), описывающее вероятность того, что участок изображения, ограниченный координатами окна, является изображением автомобиля и если это число превышает некое пороговое значение, то автомобиль найден.

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

За основу нашего приложения мы возьмём пример программы на Питоне из библиотеки DLIB (с косметическими изменениями), а именно object_detector.py, программа выполняющая распознавание лиц на изображении.

Подготовка данных для программы

Первым делом подготавливаем набор данных. Для обучения модели алгоритма нам понадобятся изображения и разметка (labeled images). В качестве изображений подойдут обычные фотографии, сделанные с вебкамеры или смартфона. Для разметки изображения библиотека DLIB предоставляет инструмент — imglab, простая программа, позволяющая тот минимум, который нам необходим — обозначить объекты на наших изображениях (найти её можно в папке tools/imglab). Результатом работы imglab является XML файл, с набором координат прямоугольников, обрамляющих наши автомобили.

Итоговый набор данных для нашей программы включает: 16 фотографий, с общим числом автомашин на фотографиях 90, для обучения модели и тестового набора данных — 4 фотографий и 39 автомашин. Кроме это нам нужны два XML файла: один с разметкой для тренировочных данных, второй — для тестовых. Разметка для тестовых данных нужна для того, чтобы оценить качество работы алгоритма. Оба этих файла генерируются программой imglab, описанной выше.

Запуск программы

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

Лог выполнения программы:

$ python car_detector.py car_images
…
…
objective:     5.09864
objective gap: 0.0208394
risk:          0.0422724
risk gap:      0.00520985
num planes:    105
iter:          424

Training complete.
Trained with C: 4
Training with epsilon: 0.01
Trained using 4 threads.
Trained with sliding window 84 pixels wide by 76 pixels tall.
Upsampled images 1 time to allow detection of small boxes.
Saved detector to file detector.svm

Training accuracy: precision: 1, recall: 1, average precision: 1
Testing accuracy: precision: 0.975, recall: 1, average precision: 0.996795
Showing detections on the images in the examples folder...
Processing file: car_images/test-market-car-park.jpg
Number of cars detected: 21
Hit enter to continue
Processing file: car_images/test-cars-park-1.jpg
Number of cars detected: 15
Hit enter to continue
Processing file: car_images/test-image-1.jpg
Number of cars detected: 2
Hit enter to continue
Processing file: car_images/test-image-5.jpg
Number of cars detected: 2
Hit enter to continue

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

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

Precision = TP/(TP+FP) Recall = TP/(TP+FN)

TP — количество корректно распознанных объектов (True Positive)
FP — количество объектов распознанных ошибочно (False Positive)
FN- количество нераспознанных объектов (False Negative)

Более подробно почитать по этим метрикам можно на Википедиии на Quore. Возвращаясь к результатам программы, мы видим, что Precision = 0.975 и Recall = 1, что выглядит очень достойно для того объёма обучающих данных, который мы использовали, и время выполнения программы занимает считанные секунды (!), это вам не дни и недели необходимые для обучения CNN :) Теперь разберёмся, как получились эти числа:

Precision = TP/(TP+FP) = 39/(39+1) = 0.975

Recall = TP/(TP+FN) = 39/(39+0) = 1

Как мы видим, решетка на крыше автомобиля (на изображенни вверху), была распознана как автомобиль, что и привело к ухудшению Precision метрики (FP=1). Пофиксить эту проблему можно увеличением количества данных для обучения или тюнингом SVM классификатора.

Исходный код и данные для программы можно найти на гитхабе.

Описание HOG алгоритма

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

Слайдинг окно и image pyramid

Для анализа изображения алгоритм использует слайдинг окно размером 128×64 пикселей. Окно перемещается по изображению и формирует вектор признаков для каждого положения окна. Это отлично работает для случаев, когда наш объект идеально вписывается в окно, что встречается далеко не всегда. Для решения этой проблемы используется так называемая пирамида изображений (image pyramid). Слайдинг окно сканирует изображение несколько раз, после каждого прохода изображение сжимается, при этом размер окна остаётся неизменным — 128×64 пикселей. Визуально это можно представить как пирамиду из изображений.

Вычисление градиента изображения

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

(1) −1 0 1

(2)
-1
0
1

Слева оригинальное изображение, по центру применён фильтр по вертикали-2, справа фильтр по горизонтали-1

Первый фильтр формирует градиент по горизонтали, второй — по вертикали, для получения модуля и направления вектора градиента используем стандартные вычисления:

Вычисление гистограммы градиентов

Изображение разделяется на ячейки размером 8×8, то есть 64 пикселя в ячейке, с каждым пикселем ассоциировано 2 значения, описывающие градиент: направление вектора градиента и его модуль. С учетом размеров слайдинг окна у нас получается 17*8=128 ячеек на окно, для каждой ячейки формируется гистограмма градиентов, которая представляет собой обычный массив, состоящий из 9 элементов (9 bins), другими словами, происходит распределение модулей 64-хградиентов на 9 элементов массива. Выполняется это следующим образом: 9 элементов массива пронумеровываются с 0 до 160 с шагом 20, т.е. 0, 20, 40 и т. д. Величина модуля градиента распределяется между двумя соседними ячейками пропорционально вектору направления градиента. Например, если вектор направления градиента 90 градусов и модуль равен 120, тогда в ячейки 80 и 100 добавляются по 60.

Наверное, сразу же возникают вопросы, почему диапазон 0-180,ведь направление вектора может быть в диапазоне 0-360 (или другими словами 0-/+180), зачем нужна гистограмма градиентов и т. д. По первому вопросу короткий ответ — из практики. После массы тестов, проведённых авторами алгоритма, следует, что если используется диапазон 0-180,т. е. знак вектора игнорируется, то величина ошибки распознавания минимальна. По второму вопросу, преобразование градиентов для пикселя в гистограмму градиентов преследует 2 цели: уменьшить размерность вектора признаков (feature vector), что должно благотворно сказаться на SVM классификаторе, и основная цель — повысить generalization нашего вектора признаков. Что под этим имеется ввиду, если изображение подвергается небольшой геометрической деформации, то это слабо сказывается на гистограмме градиентов, в том числе и благодаря нормализации гистограммы градиентов, описанной ниже.

Нормализация

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

Результирующий вектор:

Этот подход будет работать, но авторы алгоритма предложили идею, которая работает лучше, а именно, нормализовать не отдельную гистограмму, а блок размером 2×2, состоящий из 4 ячеек. Работает это следующим образом: блок перемещается по изображению с перекрытием (см. Пример ниже), для каждого положения блока выполняется конкатенация гистограммы градиентов для ячеек в блоке и выполняется нормализация результирующей гистограммы.

В итоге для каждой ячейки формируется 4 гистограммы, и общая размерность вектора признаков для слайдинг окна составляет: 15*7*9*4 = 3780

Пример визуализации HOG дескриптора для фронтальной части автомобиля:

Надеюсь, статья получилась достаточно интересной и сподвигнет читателя на дальнейшее изучение ML.

Полезные ссылки:

1. Navneet Dalal and Bill Triggs: Histograms of Oriented Gradients for Human Detection
2. DLIB library
3. Adam Geitgey: Machine Learning is Fun!
4. Google releases Object Detection API

В рубриці DOU Labsми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на editors@dou.ua.

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

До плюсів такого підходу можна віднести:

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

Мінуси, відповідно:

• необхідність наявності персоналу достатньої кваліфікації для обслуговування інфраструктури;
• необхідність проведення регулярного обслуговування.

Мережева архітектура

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

Логічна структура мережі виглядає наступним чином:

IP-адреси в діапазоні 192.168.2.1-10зарезервовані для мережевого обладнання. Діапазон 192.168.2.11-200зарезервований для статичних IP-адрес, які отримують фізичні та віртуальні клієнти. Все що більше 200 — діапазон динамічних адрес, що автоматично присвоюються мобільним пристроям, які тестуються в лабораторії (роутер також має окрему точку доступу Wi-Fi).

Всі фізичні машини в мережі пронумеровані по порядку і кожна така машина отримує статичну IP-адресу, останній розряд якої завжди кратний 5. Віртуальні машини, розміщені на даній фізичній машині, мають статичні адреси в діапазоні [192.168.2.x+1, 192.168.2.x+4], де x — адреса їхнього фізичного хоста. Тобто, один хост може вміщати не більше чотирьох віртуалок з «реальними» адресами. Дана закономірність також відображається в іменах хостів. Так, якщо фізична машина називається node1, то її віртуалки отримають імена node11, node12, ... Така структура дозволяє спростити задачу по отриманню IP-адрес машин для автоматизованих скріптів, що виконуються в мережі. Також сам роутер надає можливість для клієнтів отримувати інформацію про конфігурацію мережі та про клієнтів (IP/MAC-адреси, імена хостів) через власний API.

Hardware-компоненти

Лабораторія включає в себе як Mac-, так і PC-сервери. В якості перших були вибрані Mac Mini, а другі — портативні юніти на платформі Intel NUC. Для всіх машин була вибрана конфігурація з 16 і більше GB оперативної пам’яті та процесором Intel Core i5 або i7. Також рекомендується використовувати SSD або хоча б Fusion Drive у випадку з Mac Mini. Інакше будуть сильно відчутні «просідання» в продуктивності віртуалок, особливо якщо їх більше однієї. Дуже важливо наперед продумати правильне підключення машин до електромережі та розрахувати навантаження. Одночасне включення усіх серверів після збою живлення або їхня одночасна робота з повним завантаженням запросто може «відрубати» автомат на електрощитку.

Wire має окремі native-аплікації для Android та iOS. Для автоматизованого тестування на платформі Android ми використовуємо реальні пристрої з множини популярних серед користувачів. Для автоматизованих iOS-тестів використовується симулятор, і тільки невелика їх множина виконується на реальних пристроях в силу обмежень властивих для симулятора (наприклад, відсутність камери, фреймворка CallKit і т. д.). Усі мобільні пристрої постійно підключені через USB-конектори до фізичних серверів. Кожен сервер в свою чергу містить статичну таблицю, де вказується, якій віртуальній машині належить той чи інший підключений пристрій. Тобто кожен віртуальний хост «бачить» не більше одного фізичного пристрою.

Переваги віртуалізації

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

Проблеми та рішення

В процесі роботи лабораторії ми стикнулися з кількома проблемами. Так, основною був перегрів мобільних пристроїв, постійно підключених до джерела живлення. Тепер ми знаємо, чому виробники мобільних телефонів не рекомендують на тривалий час залишати їх в режимі заряджування підключеними до електромережі. В деяких лабораторних пристроях через два-три місяці роботи акумуляторні батареї буквально роздувались до такого розміру, що видавлювали тач-скрін і задню кришку (які були, до речі, приклеєні). Першим рішенням було перемістити все обладнання в серверну кімнату з середньою температурою 19℃ . А для особливо «гарячих кандидатів» був придбаний просунутий USB хаб Acroname з можливістю програмного управління подачею живлення на кожен з підключених пристроїв через власний API. Далі був написаний скріпт, що автоматично переключає стан лінії живлення на підключених пристроях кожні дві години, що дозволяє уникнути небажаного перегріву. До речі, цікавий факт — хаб має можливість відключити тільки лінію живлення, залишаючи лінію даних включеною, але це все одно призведе до зникнення відповідного пристрою зі списку видимих для ОС.

Друга проблема спостерігалася на підключених пристроях та віртуалізованих ОС внаслідок тривалої роботи в режимі високого навантаження. Особливо діставали проблеми викликані «втіканням» пам’яті та ресурсів (memory and resources leaks). Це призводило до несподіваних «зависань» без видимих на те причин або неочікуваних помилок в роботі тестів. Допомогло примусове перезавантаження усіх підключених пристроїв та віртуальних машин за розкладом.

Третя проблема — робочі станції з Mac OS автоматично відключають прискорення графіки, якщо до машини не підключено жодного фізичного дисплею. Це створює великі незручності при роботі з віддаленим екраном по протоколу VNC, а також унеможливлює нормальне функціонування аплікацій, що вимагають OpenGL (в тому числі iOS Simulator). Звичайно, можна було взяти монітор, підключити до нього купу кабелів і створити строкате накопичення, в якому сам дідько ногу зламає. А можна придбати заглушку для виходу HDMI або Display Port, наприклад, fit-Headless від компанії Compulab, що і було зроблено.

Висновки

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

[От редакции: автор статьи попросил сохранить его анонимность. Материал опубликован в рамках конкурса статей на DOU]

Image Source

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

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

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

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

Сам военный компьютер представлял собой переделанный гражданский компьютер ПК-01 «Львов», выполненный в виде сдвоенной платы в металлическом корпусе, блок питания и монохромный дисплей, который, как ошибочно считали, умеет показывать только буквы и цифры. ПК был основан на КР580ВМ80А, это была единственная причина, по которой меня и направили в «компьютерную роту» — я успел выучить ассемблер этого процессора в журналах «Радио». Выпущенный полностью на отечественной базе, с тридцатью двумя килобайтами ОЗУ, он подходил под суровые требования военных, но даже этого было мало. Каждый раз, когда со склада выдавали новый взамен сломанного, а запас их был там очень приличный, то карательная тройка вандалов выполняла одну и ту же экзекуцию — корпус вскрывался, микросхемы ПЗУ с заводской прошивкой выкусывались и уничтожались при помощи молотка, затем припаивались микросхемы с собственной прошивкой ПЗУ, после чего корпус собирали и пломбировали, вносили запись в журнал, потом в журнал учета записей и, наконец, записывали все в журнал учета журналов.

Гражданский компьютер ПК-01 «Львов» (Image source)

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

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

Чтоб его запустить, нужно было выбрать режим связи с ЭВМ, ввести пароль (одинаковый для всех, был в ПЗУ), далее шла утомительная загрузка данных от Ески, которая имитировала считывание записи с магнитофонной кассеты, потом проверялась контрольная сумма с эталонной, если все было ОК — нажималась клавиша ВВОД и эта программа запускалась.

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

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

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

Как дедушка над духом шутил

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

А было дело так: однажды один старослужащий хитро прищурился и стал мне вопросы задавать:
— Эй, салага, а ты-то хоть ассемблер хорошо знаешь?
— Да.
— А машинный код можешь писать без ассемблера?
— Могу, но со справочником и тетрадкой.
— За сколько времени сможешь написать программу, которая пошлет в цикле 200 байт со значением 255 и паузой в 20-30тактов на порт C4, а по окончании — нулевой байт?
— Ну, минут за пять. Надо просто код записи в порт посмотреть и такты в нопы перевести, а циклы я на память умею.
— Вот это да! А у нас никто меньше чем за полчаса не справлялся. Покажешь на автономке?
— Ладно...

И вот я ввел эти команды, запустил программу, и дальше, правильно — меня дернуло током. Не сильно, но ощутимо. И все вокруг засмеялись, а я заплакал.

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

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

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

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

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

Служба

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

Все данные о радиочастотах передаются от ЭВМ операторам устно, а это опасно — враги могут подслушать и гонять на частотах дезу. Это два.

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

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

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

И вот я начал изучать доверенный мне компьютер. Так как автономный режим был убог и неправильно введенный символ нельзя было изменить, то, прежде всего, я стал изучать возможные варианты. Самым оптимальным было адаптировать готовый «Монитор» от РК-86.

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

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

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

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

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

На умняке

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

IBM PC/XT (Image source)

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

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

В бой!

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

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

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

Я сообщил об этом Андрущенко. Он внимательно на меня посмотрел и спросил:
— Кому ты еще рассказал об этом?
— Никому.
— Правильно. И мне ты тоже ничего не рассказал. Понимаешь, почему?
— Догадываюсь...
— Даже не догадывайся. Разведчик должен уметь все забывать. Повтори, что я сказал?
— Я не запомнил.
— Молодец!

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

Мифы о дисплее

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

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

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

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

Улучив момент, когда я остался наедине с одним из разработчиков военного ПЗУ, я спросил, под что, мол, расходуется такой большой кусок, где ни данных, ни кода. Разумеется, я знал, под что, просто хотел услышать его ответ:
— А это символы для знакогенератора.
— Это как?
— Ну каждый знак состоит из точек, байт — это восемь точек по вертикали, а стопка из восьми байтов — изображение одного знака восемь на восемь точек.
— А все говорили, что можно только буквы на дисплее отображать...
— Я этого не говорил!
— И я тоже не буду.
— А ты молодец, хлопец, далеко пойдешь!

Фальшивая нота

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

Естественно, что выдавать звук на динамик и считывать его с микрофона научились задолго до меня. Диапазон был широк и можно было считывать/записывать звук с дискретностью байт/нота, то есть — 256 нот! Но использовали всего три. Почему? Вопрос был без ответа.

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

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

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

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

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

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

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

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

Это могло означать только одно — несмотря на различие ПЗУ, в чем-то они совпадают. Но в чем? Наверное в регистрах, потому что больше не в чем. Я долго и безуспешно искал решение, пока не дошел до глубины глубин — подсчета контрольной суммы. И тут я нашел первую закладку безопасности в военном ПЗУ: если контрольная сумма была ошибочна, но при этом равнялась 01FF, то программа переходила по этому адресу.

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

И вот я просто сидел и втыкал в нотный перелив загрузки с магнитофона, когда один из из старослужащих вдруг сказал, что последняя нота фальшивая!
— Чего?
— Последняя нота — фальшивая, слишком высокая.
— Точно?
— Сделай громче, да сам послушай!
— Я не услышу — мне медведь оба уха оттоптал.
— Да ладно! Прислушайся лучше!

Да, фальшивая нота там определенно была, это я услышал, подключив наушники и врубив звук погромче. И это определенно давало мне однозначную точку отладки — преобразование потока бит из порта АЦП в байты кода. Именно там и оказалась последняя закладка. При проверке верного сигнала, которым являлось многократное повторение одного и того же байта-ноты, был обработчик ошибок. Если сигнал не соответствовал нужному, то возникало переполнение регистра, проверяющего вывод с порта, потом осуществлялся переход в ПЗУ на адрес сообщения об ошибке. Именно там и стояла закладка — если регистр переполняется, то есть нота выходит за размер байта, то происходит переход по адресу регистра переполнения и последнего кода ноты. Не сложно было понять, что значение переполненного регистра становилось 01, а последняя нота естественно была FF. Наш знаменитый 01FF. А по адресу 0100 была размещена та самая программа с сообщением об ошибке, которая при загрузке копировалась туда из ПЗУ.

Программу с ЭВМ я получил. Дальше уже было не сложно написать загрузчик версии оригинального ПЗУ, в формате которого я записал программу ЭВМ на магнитофон. Скорость загрузки увеличилась вдвое.

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

Несколько дней я не знал, чего мне и ожидать — медали или трибунала. Получил я не то и не другое, а лист купонов на 50 купонокарбованцев и 65 рублей рублями. Премия!

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

Свой

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

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

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

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

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

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

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

Deus ex machina

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

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

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

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

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

— Что тебе нужно из обеспечения, человеческой силы и времени? — спросил, наконец, начальник военчасти.
— Шесть месяцев, запись модифицированного ПЗУ, магнитофон, детали для усилителя, провода.
— А для автоматизации дешифровки?
— Дополнительные ПЗУ со статическими данными по типичным наборам последовательностей, которые представляют собой наиболее часто встречающиеся слова. И их дополнительная обработка.
— Сделаешь за четыре месяца. Потом со мной в центр поедешь — за последовательностями и на повышение. Понятно, товарищ лейтенант?
— Так точно! Рад стараться! Служу Советскому Союзу! Ой...
— Отставить «ой». Мы с тобой оба все еще служим государству, которого уже нет.

Это была правда. СССР уже не существовал, а оскудевший поток финансирования показывал, что и независимой Украине мы сами не особо нужны.

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

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

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

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

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

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

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

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

Я тогда распечатал всякие глупые бумажки и наклеил их у себя над нерабочими клавишами — «Старт на Луну», «Десант на Марс» и тому подобное. Не обошлось без «Ракеты на Америку».

Как-то полковник Андрущенко зашел и стал читать надписи. Стал хохотать, а потом дошел до «Ракеты на Америку» и погрустнел:
— А это убери. С Америкой мы больше не враги, да и ракет у нас нет.
— Как это? Не может быть! Как нет ракет?
— Пусковые шахты бетоном заливают...
— Все?!
— Все.

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

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

Все бумажки я потом поубирал.

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

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

Между прочим, теперь распознание шло в графическом режиме. Каждый сигнал передавался битами — 00: пауза, 01: точка:, 10: тире, 11 — конец блока. Четыре сигнала формировали яркость точки на монохромном дисплее — бит. В остальном я пользовался вызовами оригинальной программы от ЭВМ — с помощью стрелок курсора менялись системы декодирования, если была выбрана правильная — экран очищался и можно было передавать текст. Не видя его самого, текст отображался у меня на дисплее, а я уже передавал его дальше, если все было нормально. Это позволяло здорово экономить память и работать с длинными передачами.

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

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

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

Спецбезопасник посмотрел на меня как на идиота и раздраженно сказал:

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

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

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

Гостайна, которой нет

На ЖД вокзале стояли трое: начальник военчасти, полковник и лейтенант. Начальник что-то сказал, дал денег и остался в одиночестве — полковник с лейтенантом пошли покупать пару ящиков водки и закуску. Не ради пьянство окаянного, а... Кого мы обманывали? Конечно, ради пьянства. Полковник сразу велел купить только две бутылки и закуску и остался ждать меня за углом. Потом мы выжидали, когда поезд начнет давать пары, бегом бежали и заскакивали на последнем моменте

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

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

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

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

Я объяснил, что мне нужно записать самые повторяющиеся фразы из передач. Желательно в виде морзянки, упакованной по два бита. В ответ я получил вопрос, который меня поставил в тупик:
— В какой операционке работаешь?
— Эээ... ни в какой. Я данные переведу в сжатый формат и запишу в ПЗУ. Для быстрого сравнения в автоматическом режиме.
— А сколько у тебя там памяти?
— Много, целых 32k ОЗУ и 32k ПЗУ, правда 8 уходит под код и знакогенератор, но все равно хватит.
— Понятно. Для нормальной работы тебе понадобится 386 или выше, принеси пачку дискет — запишу операционку на них, сам поставишь, я думаю. Если что, запроси у руководства — вышлем, у нас есть лишние. А базу я тебе скину в архиваторе, потом распакуешь на жесткий и вольешь в базу, оттуда сможешь экспортировать в нужном тебе формате.
— Разрешите поинтересоваться — вмешался начальник военчасти — А вот это у вас считается нормальным, хранить такую информацию на враждебном оборудовании, да еще и передавать на дискетах?
— А у вас считается нормальным, что у моей жены зарплата стала в долларовом эквиваленте меньше пятнадцати баксов?
— Да при чем тут это!
— При том. Сейчас у нас других проблем хватает, а компьютеры не враждебные. Их нам американцы подарили. И у вас, наверное, скоро тоже будут такие. Не фирменные, конечно, но IBM-совместимые, на отечественной базе. Про компьютер «Поиск» слышали?
— Никак нет!
— Пройдитесь по магазинам, посмотрите. Все равно вам потребуется нормальный компьютер для работы с базой данных. И диск сразу на 240 метров как минимум берите.

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

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

Обратно мы ехали серьезные и трезвые. Командование обсуждало методы относительно честного добывания дисплея, жесткого и прочих компьютерных потрошков, которые я предусмотрительно записал в тетрадку. Я же начал читать руководство, которое оказалось на английском языке, что, впрочем, меня особо не смутило. Кто дампы в армии дизассеблировал — тот операционку одной левой освоить сможет. Руководство пугало безумно непонятным названием «Introduction to Sco’s Unix System V/386». Заканчивалась эпоха хакинга ПЗУ, и начиналась эпоха программирования в «Скотине».

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

Победитель

Скотину я установил и окунулся в глубокий и неизведанный мир командного интерфейса Unix. К старому компьютеру интерЭВМ угасал, но все же я реализовал задуманное.

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

Предположим, у нас есть фраза «экстренный вызов», которая будет в виде морзянки записана так: ··—·· —·— ··· — ·—· · —· —· —·—— ·——— —···— ·—— —·—— ——·· ——— ·——
Выкидываем все паузы и получаем: ··—··—·—···—·—··—·—·—·——·————···—·———·————··———·——
Переводим в сжатый бинарный формат (0 — точка, тире — 1): 00100101000101001010101101111000101110111100111011
Что, в свою очередь, будет представлять набор байтов со значением 9452ADE2EF3B.

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

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

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

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

Адаптировал свои игры под гражданский вариант ПК-01 и писал новые, пытаясь продавать их. Покупали мало — компьютер отжил свое.

По знакомству меня устроили работать кладовщиком на промрынке «Седьмой километр», где стоял компьютер, и мне разрешалось на нем работать. Собственно, ради этого я и пошел, так как денег было мало, хотя на вторую же зарплату я купил свой жесткий диск для опытов. Я много работал в бетонной каморке и заработал ревматизм в правом колене, так как обогреватель грел только слева. Потом я как-то купил журнал CHIP, в котором был диск с Linux Caldera, наследником Sco Unix, который и поставил на своем жестком диске, и проводил с ним время в свободные от работы часы.

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

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

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

Project Management

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

Практическое управление крупными проектами по разработке ПО в двух частях (1, 2).

Чеклисты от Стратоплана для health-check’a своего проекта:

• 90 вопросов для оценки проекта (pdf)
• 39 признаков Agility (pdf)

Статьяо том, как на смену операционному управлению приходит проектное управление.

Project Weekly Status Reports that Stakeholders are reading.

Советы для работыс главным инструментом ПМ-а — электронной почтой.

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

The more of Less in projects. Quote: «The author has caused me to think about the clutter in my projects. Do I really need all the stuff? Are all the meetings necessary? How can I simplify my projects?»

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

Product Backlog Refinement или Груминг митинг — как проводить его правильно?

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

Эволюция роли продакт-овнера в статье от Ron Eringa.

Напоминание о простых советах, которые делают Scrum рабочим инструментом, а не набором фейковых практик.

9 Best Practices for Your Dailys Scrum Meeting.

Что должен сделать Скрам-мастер, прежде чем идти в отпуск? Ответ от Майка Кона, автора лучшей, по моему мнению, книги про Scrum.

10 эффективных советов для мотивации спортивных команд: на 100% применимо для скрам-команд разработчиков!

Common Dysfunctions of «Scrum» Teams (1, 2)

Product Management

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

Чеклистдля успешной работы с продуктами. Пункт 19: Держите руку на пульсе своего эмоционального состояния. В нашем деле главное — не перегореть. Work hard, party hard.

8 критериевкачественной оценки рынка.

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

Free customer journey map templates от UXPressia — налетай!

Распространенные заблужденияо разработке продуктов.

Микро-курспо основам UX-проектирования на русском языке.

Product Manager at Microsoft. How does it feel?

Fun

У этого критикала свои планы на твой вечер пятницы:

Когда пытаешься выяснить у разработчика статус по задачам:

Agile применим в любом виде деятельности, говорили они:

«Just a few things you may hear from your everyday project manager...» Узнаем себя? :)

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

И, напоследок, хочу поделиться плюшкой! Осенью в Киеве пройдет конференция PM framework days — ивент для тех, кто работает в команде, кто управляет командой и хочет создавать лучшие по качеству и срокам проекты.

Билеты по лучшей цене еще в продаже: goo.gl/TS2TLq. Многих спикеровзнаю лично — эти ребята мастера своего дела!

Всем читателей дайджеста организаторы дарят промо код 10% на покупку билетов: pm-digest.

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

[Материал опубликован в рамках конкурса статей на DOU]

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

Первая работа

Когда ушел в свой первый рейс — очень радовался, ведь вырвался из-под родительской опеки. Радовался тому, что начну зарабатывать ощутимые деньги. Приятное состояние, когда узнаешь о своих первых 500 долларах на счету. Работать приходилось много, линия была в Северном и Балтийском морях.

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

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

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

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

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

От рейса отказался, другой назначили через 3 месяца. Очень радовался, казалось, что смерти избежал. Но «песочные часы» никуда не исчезли. До вылета оставалось 1,5 месяца. Появилось желание успеть до отъезда как можно больше. Начал плотнее общаться с давними знакомыми, которые, как оказалось, были завязаны с IT сферой. Вдавался в подробности и интересовался, как это работает. Когда назначили дату вылета, последние 2 вечера ходил сам не свой. Пришло ощущение безысходности.

Я задумался о том, что можно изменить? Следующий рейс стал последним. Мне надоело! Не хочу заниматься скучной работой, быть вдалеке от родных и близких. Хочу другого будущего. Мне 25 лет, и, если я сейчас не решусь что-то менять, потом мне будет тяжелее в разы. Не хочу отдавать ответственность за свою жизнь в руки других людей. Надоело жить отрывками по 3-4 месяца,пока ты дома, а потом снова ставить все на паузу, выключая отношения, и уходить в рейс. Надоело пропускать интересные мероприятия, забывать, кто как выглядит. Не хочу, в будущем приезжать и не узнавать своих детей, потому что они быстро и незаметно выросли. Хочу жить полноценно, вникая в каждую деталь этой интересной жизни, решая повседневные проблемы, а не заливая их алкоголем, перекладывая на чужие плечи. Не хочу чувствовать себя отчужденным, упустившим что-то важное, не попробовавшим пойти за своим желанием. Словно озарение. В тот день я твердо решил, что в море больше не вернусь. От предложения отказался, чем, как оказалось в дальнейшем, ввел многих близких в шоковое состояние.

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

Поиск работы

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

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

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

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

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

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

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

Дни проходили, я отправлял резюме, заходил на сайты, ходил на собеседования — около 25 за 1,5 месяца. На одном только DOU я отправил около 60 резюме, при том, что каждую вакансию я вычитывал и писал письмо-обращение от себя, не используя шаблоны.

Прочитав о курсах, которые проводятся в городе, нашел несколько ИТ-школ. Меня заинтересовал Front-end. Но я не был уверен, что это правильный выбор. Знакомые посоветовали такой ресурс, как htmlacademy.ru. Засел на входных и, не вставая, начал проходить задания, вроде втянулся, начало получаться. Взвесил все за и против, понял, что ничего не теряю, а, наоборот, только приобретаю. Записался на курсы и начал ходить, учиться, смотреть ролики, читать статьи, выполнять задания.

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

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

Выписал себе цели на месяц, что мне необходимо сделать (почему я сразу не оценил эффективность такого метода), набралось примерно 30 пунктов из категории «должно быть сделано».

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

Резюме, вакансии и шансы на успех

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

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

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

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

Важно! Не зря есть много рекомендаций по тому, как не стоит писать. Вкратце, что обязательно:

• Фотография — повышает доверие, часто без фотографии пишут даже не присылать, так что стоит потратиться и сделать одну нормальную в цифровом формате, потом много где пригодится.
• Если в вакансии требуется знание английского языка — стоит все резюме заполнить на нем. Покажете, что как минимум умеете работать со словарем, даже если совсем все плохо. А вообще без английского сейчас никуда, хотя бы минимально разговорного.
• Все резюме необходимо поместить на одну страничку, вот как хочешь, надо писать кратко.
• Обязательно разбить все резюме на четкие блоки: образование, опыт работы (последние несколько мест, а не включая подработку официантом на 2 месяца на каникулах. Хотя если другого опыта нет, можно оставить и подработку), о себе (хобби, интересы, личные проекты), если есть возможность что-то показать в интернете, ссылку прикреплять (на словах хорошо, а когда есть доказательство — еще лучше), скилы (то, что вы считаете своими сильными сторонами).
• Контакты — ссылку на почту, лучше @gmail.com, и желательно, чтобы можно было распознать имя фамилию, так будет удобно, и пускай эта почта будет только для работы (примерivansusanin@gmail.com), ссылки на соцсети, только желательно проверить не отпугнет ли содержимое работодателя, и как хороший плюс аккаунт в LinkedIn.

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

• Если в вакансии требуется 5 пунктов, а ты знаешь 2-3,стоит пробовать, покажи свое рвение к обучению и желание работать.
• Встречаются совсем неизвестные понятия или процессы — гугли, потрать вечер, чтобы понять хотя бы теорию.
• Не стоит врать о том, что разбираешься в чем-то, если у тебя нет хотя бы базовых знаний. Это 100% всплывет наружу и репутация подпортится.
• Требуется знать на 100%, а у тебя 50% — говоришь, что надо чуть почитать и глубже разобраться, ну или можно аргументировать, что не хватает практического навыка, при наличии теории.
• Если вакансия висит долго, есть несколько вариантов: либо мало людей откликнулось, так как многие пугаются списка требований, который часто составляет 10+ пунктов, либо компания слишком тщательно отбирает людей и многих отсеивает.

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

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

Нельзя опаздывать. Всегда приходи вовремя.

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

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

Среднее время интервью примерно 30-60 минут.Но у меня бывали исключения с собеседованием на 1,5 — 2 часа.

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

Дальше необходимо быть готовым к трём этапам:

1. Собеседование с HR — первоначальный отбор, «проверка на вшивость», создание общего впечатления (могут скинуть форму с вопросами: «кем вы себя видите через полгода, к чему стремитесь и т. д.»).
2. Тестовое задание, если оно применимо для вакансии, иногда кидают перед первым собеседованием.
3. Собеседование с руководителем фирмы или старшим менеджером. После этого, скорее всего, нужно будет ждать около недели пока компания примет решение, и потом вы получите фидбек.

Комфорт

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

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

Следующая трудность — финансы. Когда бросаешь работу, сразу понимаешь, что приток денег исчез и на момент поиска, ты будешь их только тратить. Я могу посоветовать: выписать все расходы и посчитать, сколько минимум уходит денег в месяц, если кажется, что учел все, то накинуть еще 10-15%на непредвиденные (если есть ребенок, то стоит взять больше). Имея определенный бюджет, подсчитать, на сколько хватит данной суммы. С одной стороны этот срок может морально давить, с другой — он будет подстегивать/мотивировать, чтобы не прохлаждаться и не успокаивать себя, мол мне хватит еще на полгода.

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

Итог

Project Manager, 8 месяц работы, интересной, различных задач, общения с живыми людьми, с возможностью выбрать день удаленно, где без проблем отпускают, если куда-то необходимо отъехать, улыбаются по утрам и желают хорошего дня. Не могу пока сказать, что это моя dream job, но якорь бросил, денег заплатить за квартиру и купить еды хватает, появилось внутреннее спокойствие, отсчет времени до непонятного момента исчез.

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

У меня получилось — и у тебя получится!

В выпуске: про предстоящее возрождение .NET, еще одна статья на тему зависимостей, технический roadmap сетевого стэка, анонс TypeScript 2.4, Майкрософт присоединяется к Cloud Foundry Foundation.

.NET

Неявный boxingпри сравнении enum в качестве параметра типа в generic.

Еще одна заметка про предстоящее Возрождение .NET.

Как динамически конфигурировать зависимостина старте приложения в .NET Core 2.0 на примере ApplicationInsights.

Еще одна статья на тему зависимостейи немного больше деталей.

Улучшения производительности в .NET. И те же тесты с BenchmarkDotNet.

Еще одна статья Alt.NETо том, почему .NET Core — хорошо.

Технический roadmap сетевого стэка.

Анонс .NET Core 2.0 Preview 2.

Использование памятивнутри CLR.

Небольшая статистика использования C# от JetBrains.

Улучшения в Environment Tag Helpersв ASP.NET Core 2.

Profile-guided optimizationв .NET Core 2.0.

Моделирование

Садим события на диету.

Микросервисы: композиция интерфейса.

Инструменты

Поддержка ValueTuple в OrmLite.

Производительность DI контейнеров.

Большой рефакторинг с R# и Custon Code Inspections.

Малоизвестные приемы отладки в VS 2017.

Rider Release Candidate.

NCrunch 3.10 AtomicAttribute.

Интерфейсы

Реализация обновления токенав OpenID Implicit Flow и Angular.

Анонс TypeScript 2.4 (dymanic imports и string enums).

Производительная анимация expand и collapseэффектов.

Вариант сохранения глобального состояния в Polymerбез Redux.

Использование Polymer с Reduxв реальных приложениях.

Использование Polymer с Webpack.

Разное

Майкрософт присоединяется к Cloud Foundry Foundation.

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

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

Про уровни логирования:

One of the biggest challenges with centralized logging is establishing consensus about what log levels actually mean. Here’s a quick primer. pic.twitter.com/5UeFnfiq1h

— Dylan Beattie 🇪🇺 (@dylanbeattie) July 19, 2017

Книги

Historical Modeling — о том, как моделировать состояние системы на основе фактов и предыдущих фактов. И сравнение с EvenSousing.

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

События

.NET Conf — 19-21 сентября, online.

.NET Fest 2017 — 28 октября, Киев.

Веселости

Секция, как запустить под вендой в любом open-source проекте:

The «Windows» section of every open-source project’s «how to compile and install» file: pic.twitter.com/82szh0Tj0q

— Elan Ruskin (@despair) December 22, 2015

Анимация из капель воды:

Water droplets create amazing human-like animations in this @Gatorade ad pic.twitter.com/hy0S4oLrAS

— Business Insider (@businessinsider) June 17, 2017

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

Все под контролем:

pic.twitter.com/ICyUAp2bHO

— PUNS (@ThePunnyWorld) July 10, 2017

Как правильно создавать секурные вопросы:

Wut. pic.twitter.com/7Dc5BMzdEX

— Phabricator (@phabricator) July 18, 2017

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

When you don’t stop at a unit test and go all the way to integration tests for «done» pic.twitter.com/4tJqO7LCCr

— Jimmy Bogard (@jbogard) July 19, 2017

CSS tips & tricks:

Механический двоичный счетчик:

Mechanical Binary Counter pic.twitter.com/S1znJ0m2mF

— Fermat’s Library (@fermatslibrary) July 20, 2017

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