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

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

Что такое корпоративная культура

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

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

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

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

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

Компоненты корпоративной культуры

Корпоративная культура состоит из множества компонентов. Приведу некоторые:

• Система лидерства. В одних компаниях лидеру принято указывать своим сотрудникам, что делать, а самому стоять сзади и поплевывать в потолок. А в некоторых наоборот — лидер фигачит все сам, не подпуская к проекту практически никого. Весь в мыле, пока его сотрудники плюют в потолок. Возможна, конечно, и совместная работа — ну вы понимаете. Все зависит от корпоративной культуры и разделяющих ее людей.
• Стили разрешения конфликта. В одной компании принято общаться на уровне итальянского семейства, а в другой — не глядя эскалировать малейшие трения (то есть для решения привлекать руководство). И если в первой начать эскалировать, а во второй — скандалить, то вылететь с работы можно просто за пять секунд.
• Действующая система коммуникации. В одних компаниях устраивают бесконечные митинги на 100 человек, а в других — в поле СС любого письма указывают полфирмы. В компании, где я работал, было принято звонить друг другу по телефону даже в соседнюю комнату.
• Особенности гендерных и межрасовых взаимодействий. Тут я, пожалуй, обойдусь без комментариев.
• Принятая символика: лозунги, организационные табу, ритуалы. В некоторых компаниях такие странные табу бывают — не уходить в 18:00 с работы или не общаться с начальником, пока он тебя не вызвал.

Почему корпоративная культура важна для нас

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

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

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

Надеюсь, убедил. А теперь перейдем к тому, как устроена корпоративная культура.

Три уровня корпоративной культуры

В книге «Corporate Cultures: The Rites and Rituals of Corporate Life»выделяют три уровня корпоративной культуры:

1. Артефакты.
2. Провозглашаемые ценности.
3. Базовые представления.

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

Артефакты

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

Например, одна компания из ТОП-5 украинского IT располагается в... гм... in the middle of nowhere, скажем так. Когда коллеги говорят рекрутерам этой компании, что они не будут ездить в... эту самую середину, рекрутеры (кстати, очень настырные и странные) бодро отвечают: «Зато мы компенсируем это зарплатой».

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

Провозглашаемые ценности

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

Именно так это и работает. Провозглашаемые ценности превращаются в соответствующие артефакты, а потом проходят проверку рынком. Если рынок говорит: «Да! Ваше самое экологическое пиво — то, что надо», — все это закрепляется и постепенно превращается в самый нижний слой корпоративной культуры — базовые представления. Если же нет, то первое лицо компании выходит и говорит: «Наша компания „МайКулКомп“ — это инновации». Потом надевает шлем виртуальной реальности, и вы понимаете, что скоро по всему офису будут висеть футуристические хрени, сотрудников отправят изучать Data Science на очередную конференцию, всем будут часть зарплаты выплачивать биткоинами и так далее. Ну, вы поняли.

Базовые представления

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

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

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

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

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

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

Четыре типа корпоративной культуры

Типы корпоративной культуры изучали Robert E. Quinn и Kim S. Cameron из Мичиганского университета. В принципе вместо здоровенной статьи я мог бы ограничиться одной картинкой:

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

Клан

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

Адхократия

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

А на следующий день Вася — конструктор ракетных двигателей вместе с HR-директором. Так просто нужно рынку, а мы работаем так, как ему нужно.

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

Рынок

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

Мне лично в таких компаниях крайне неуютно. Но многие находят свой кайф и стремятся работать среди «самых лучших». У них мотивация — «меня взяли в компанию „А“, я стою много».

Иерархия

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

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

Реальность

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

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

Трансформация корпоративной культуры

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

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

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

Выводы

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

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

Удачи.

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

Как было раньше

Когда только начиналась промышленная разработка программного обеспечения, каждый разработчик был сам себе бизнес-аналитик, архитектор, верстальщик, девелопер, тестировщик, девопс и поддержка 24/7 в одном флаконе. Какие это таило в себе недостатки? Иногда получались достаточно корявые и не понятные для стороннего пользователя продукты. Трудно было представить, что творилось в голове того или иного индивида. И еще один минус — сосредоточение всех сакральных знаний в одной светлой голове, которая могла заболеть, уйти к конкурентам, да и просто уехать отдыхать на Гоа. Однако в этом были и плюсы. Инженер сразу задумывался о полном цикле жизни своего продукта. Тут не было надежды на всемогущего админа, который придет и все порешает за тебя. За любой косяк приходилось выгребать самому и расплата не заставляла себя долго ждать.

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

Почему появилась культура DevOps

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

Если первый фактор еще может показаться достаточно спорным, то второй — более однозначный. Это широкое развитие облачных сервисов, отказ от хостинга на своих серверах и поддержки своей инфраструктуры как таковой. Выбранная инфраструктура начала определять архитектуру приложения. AWS, Azure, Heroku, DigitalOcean начали делать за вас вашу работу. Теперь не надо без особой потребности придумывать 1001 вариант написания балансера или шардинга — это все доступно из коробки. Это снизило количество велосипедов на квадратный метр, но этот подход, в свою очередь, требует знания инфраструктуры сервисов и адаптации своих продуктов под них.

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

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

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

Практики DevOps

Теперь давайте поговорим о практиках DevOps. Они достаточно неплохо описаны в книге «DevSecOps The Road to Faster, Better and Stronger Software». Давайте рассмотрим главные из них.

«Automate everything» — автоматизируй все, что можно. Уменьшай количество «ручной» операционной работы. Делаешь, что-то два раза — придумай, как это автоматизировать. Это ускорит все процессы и сведет количество ошибок к минимуму. Работать должен робот, человек должен отдыхать и заниматься мыслительным процессом!

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

«Infrastructure as Code». Подразумевается, что подход к конфигурированию приложений должен быть таким же, как и к коду. Если раньше в конфигурации системы через консоль не было ничего зазорного, то сегодня стало уже плохим тоном не использовать для этих целей инструменты автоматизации, такие как Terraform, Chef, Puppet и т. д. Эта практика позволяет оптимизировать ресурсы, а также значительно ускорить время поставки.

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

«Application monitoring». Если раньше системы мониторинга представляли из себя различные способы «скирдования» логов, то теперь это мощный инструмент для мониторинга состояния вашего приложения. На анализ логов не надо тратить дни и недели, вы можете настроиться на ту или иную метрику и смотреть за изменениями в режиме реального времени. Мало того, кроме сугубо технических моментов, например количества запросов, перформанса, загрузки CPU, вы с помощью таких систем, как Prometheus, можете собирать и внутренние характеристики приложения, значимые для вашего бизнеса.

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

Выводы

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

Эта статья — нулевая в цикле материалов по DevOps практикам. В течение месяца я буду писать по одной статье, которая будет давать введение в культуру DevOps. Цикл будет включать такие темы:

1. Тестирование, все что вы хотели спросить, но стеснялись. Новый взгляд на TDD.
2. Bash. Знай друга в лицо.
3. Инфраструктура web-приложения в AWS на примере Node.js.
4. Docker. Контейнеры. Оркестрация. Docker Swarm. ECS. Kubernetes.
5. CI. Jenkins. Зачем напрягать роботов, или Когда разработчики глубоко спят.
6. IaC. Terraform, или Почему не надо менеджить инфраструктуру руками.
7. Application monitoring. AWS Cloud watch. Prometheus.

О культуре DevOps советую почитать:

• Quora: What is a DevOps role?
• Bash scripting — видео
• Docker: Get Started, Part 1: Orientation and setup
• What are the best Docker orchestration tools?
• Terraform from Hashicorp
• Jenkins getting started

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

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

Способы получения знаний и навыков

Какие же существуют пути поддержания актуальности своих навыков и знаний?

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

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

Что может дать миграция

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

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

Что нужно знать до миграции

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

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

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

В-четвертых, нужно уметь остановиться и понять, что миграция невозможна. Отсутствие результата — это тоже результат.

В-пятых, это частичная миграция. Категорично против такого, так как плодить зоопарк технологий, которые делают одну и ту же работу параллельно в разных классах/частях системы — это зло. Такое положение часто ведет к проблемам, которые сложно отловить, и необходимостью сопровождать два или более вариантов решения задач. Видел проект, в котором половина доменной области вытягивается при помощи дедовского JDBC, а вторая — Hibernate c кучей eager-связей, что вело к ежедневным падениям приложения с out of memory из-за неверного использования технологии.

Примеры из практики

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

Continuous integration tools.Если проект использует «no name» CI родом из конца 90-хс не user-friendly интерфейсом и проседающим перформансом, то можно перевести его на Jenkins, TeamCity или GitLab CI. Это позволит взглянуть на проект с более высокого ракурса и понять его модульность, найти узкие места и оптимизировать, если возможно. Попутно можно начать хранить артефакты в Nexus, если этого еще не произошло до 2018 года. Возможно, самый легкий пункт, так как результаты легче всего протестировать. Да и вряд ли найдутся люди, которые будут против такой миграции.

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

Build tools.Если у вас есть Ant, то можно мигрировать приложение на Maven или Gradle. Позволит избавиться от необходимости хранить библиотеки в проекте, плюс разобраться в тонкостях сборки. При такой миграции особых проблем возникнуть не должно, так как на все случаи жизни уже написаны плагины. А если ваш случай уникален — можно написать свой.

Хранение данных.Данные лучше хранить в естественной форме, что упрощает их запись и дальнейшую работу с ними. Не все данные хорошо ложатся на реляционную модель, поэтому можно рассмотреть вариант использования NoSQL баз данных. В одном из проектов была необходимость реализовать анализ логов поисковых запросов с большим количеством опциональных параметров. Писать их дальше в лог файлы было глупо, потому что анализировать это не просто. Поскольку к тому времени популярность набрала MongoDB, то лучшего варианта её применить не нашлось, как для хранения документов с переменным количеством атрибутов и анализа при помощи MapReduce. Сейчас бы такое решение не принял, а выбрал бы ELK stack. Да и мир, как по мне, охладел к NoSQL. Сделал такой вывод, потому что недавно продавал полтора десятка книг по программированию и только «MongoDB в действии» не ушла. Пишите в личку, кому надо :) Но все же знание NoSQL — это однозначно плюс. Такая миграция — одна из сложнейших с точки зрения сопротивления команды. Потому что внедрение принципиально новых хранилищ данных и их поддержка довольно сложны, а также заставляют мыслить о данных по-новому.

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

Spring/Spring Boot.Если у вас есть Spring, то можно мигрировать на Spring Boot. Это упростит настройку проекта при помощи замены самописного кода на автоконфигурации, в итоге даже кода станет меньше. Также за годы разработки могут возникнуть сложные решения с контекстами приложения и конфигурации фильтров, с которыми можно будет легче разобраться в процессе миграции. Миграция не особо сложная, но рутинная.

Java version.Каждая новая версия Java имеет ряд нововведений, которые значительно могут упростить жизнь, а по неумению — усложнить. Если брать во внимание позитивный вариант, то использование Streaming api может серьезно облегчить работу с данными, если над ними выполняется много вариантов фильтрации и трансформации при различных состояниях системы. Новый Date/Time api позволит упростить работу с датами, временными зонами и временем. Если ваш проект хотя бы частично покрыт тестами, то такой переход будет не особо сложным.

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

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

P. S. Умышленно пропустил тему frontend-а, потому что в реалиях 2018 года можно мигрировать на новую технологию и в конце миграции обнаружить, что она морально устарела.

P. P. S. Есть еще один вариант поддержания актуальности знаний, который упоминал в статье «Как выжить в круговороте современного IT, или Зачем изучать основы», но не всем он подойдет.

В этот раз DOU Ревизорпобывал в офисе Freetour.com Limited — продуктовой IТ-компании, которая предоставляет сервис бронирования туристических туров в более чем 100 странах мира. Freetour.com была зарегистрирована в Ирландии в 2015 году и входит в состав Viagio Group. В самой группе компаний Viagio Group работает более 200 сотрудников по всему миру, а офисы находятся в Праге, Берлине, Будапеште, Барселоне, Дублине и Киеве.

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

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

Офис Freetour.com находится во внутреннем дворе здания по адресу ул. Верхний Вал, 24 в 2-хминутах ходьбы от станции метро «Контрактовая площадь».

Поблизости можно найти заведение на любой гастрономический вкус и кошелек. Из ближайших:

• Beer Point — 75 грн (бизнес-ланч: суп, мясо с гарниром, салат, чай, кофе или компот);
• Habana — 65-80грн (суп, мясо с гарниром или салат, чай или кофе);
• «Пузата Хата» — 70-90грн (суп, картошка с грибами, узвар);
• «Тетя Клара» — до 70-80грн (салат, бульон, пара пирожков, сок);
• Salateira — 150-170грн (суп + салат или паста и напиток);
• Mafia — 90-120грн (суп + салат или паста и напиток).

Это далеко не весь список, ведь на улицах Верхний и Нижний Вал есть множество кафешек и ресторанов.

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

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

Весь офис Freetour.com — это 265 м² open space пространства. Зонированы здесь только кабинет основателя компании и митинг-рум, которые отделяет от основного пространства лишь стеклянная перегородка. Кстати, о митинг-румах — он пока всего один, и сами сотрудники отмечают, что это довольно неудобно (см. раздел DOU Ревизор спрашивает).

Официальный график работы в офисе — с 10:00 до 18:00. Но график гибкий, и, как правило, сотрудники «стартуют» в период 8:30-11:00,кому как удобно. По пятницам рабочий день сокращен на 1 час (по данным компании).

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

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

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

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

s.dou.ua/...​isor/freetour/3/s2/01.jpg
s.dou.ua/...​isor/freetour/3/s2/02.jpg
s.dou.ua/...​isor/freetour/3/s2/03.jpg
s.dou.ua/...​isor/freetour/3/s2/04.jpg
s.dou.ua/...​isor/freetour/3/s2/05.jpg

s.dou.ua/...​isor/freetour/3/s2/06.jpg
s.dou.ua/...​isor/freetour/3/s2/07.jpg
s.dou.ua/...​isor/freetour/3/s2/08.jpg
s.dou.ua/...​isor/freetour/3/s2/09.jpg
s.dou.ua/...​isor/freetour/3/s2/10.jpg
s.dou.ua/...​isor/freetour/3/s2/11.jpg
s.dou.ua/...​isor/freetour/3/s2/12.jpg

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

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

Артур, Android Developer, 2 месяца с компанией:

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

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

Роман, UI/UX Designer, 1 месяц с компанией:

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

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

Александр, PHP Developer, 2 месяца с командой:

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

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

Оля, Social Media Manager, 4 месяца с компанией:

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

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

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

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

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

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

Фото: Валерий Чубур.

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

Кирилл Латышработает СТО в американском стартапе Cools — это fashion-платформа, которая объединяет онлайн-медиа и шоппинг-агрегатор. У Кирилла очень разноплановый опыт: он участвовал в разработке новых проектов Genesis, пробовал запустить собственный продукт и в итоге нашел компанию, где сумел объединить два своих главных интереса: медиапаблишинг и нейросети.

О себе

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

Мой отец настраивал базовые станции UMC: там были первые UNIX-сервера, работавшие на таких здоровых дисках. Класса с 9-гоя ходил к нему на работу, мне нравилось ковыряться в железе.

После школы поступил в КПИ на физтех, специальность «Прикладная математика». Это направление заинтересовало меня тем, что там много программирования и дают обширный математический бэкграунд. Собственно, тогда я еще не понимал, куда попал :) Началась физика во всех ее проявлениях. Но мне это понравилось. Моя бабушка, учитель физики, математики и астрономии, еще с детства заинтересовала меня. Например, показывала что-то на небе и объясняла явления научным языком. В 7 классе подарила мне книжку «Занимательная ядерная физика». И затем, когда на 3-4курсе я начал это серьезно изучать, то удивился, насколько в той книжке все просто было объяснено.

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

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

Вызовы аутсорсинга и неудавшийся стартап

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

Что касается первой работы, сначала устроился администратором баз данных в компанию «Музыкальный центр», но быстро переквалифицировался в веб-разработчика. Мне нравилось, что в вебе ты сразу же видишь результат своей работы, и это очень мотивировало. Потом эта фирма закрылась, я перешел в другую компанию и занялся PHP. Затем было еще несколько компаний. В одной из них, Innovative Marketing of Ukraine, получил опыт работы с highload-проектами.

Затем я открыл для себя аутсорсинг. В 2011 году пришел в датскую компанию Kuadriga. Ребята поставили мне задачу: «У нас есть сайт, который собирает информацию о различных датских изданиях, журналистах, пресс-релизах. Есть проблема с полнотекстовым поиском — время ожидания превышает 30 секунд». А я как раз в то время развлекался со Sphinx. В итоге удалось снизить время ожидания в 1000 раз — до 30 миллисекунд.

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

Мы стали разработать свой продукт, ERP-систему Oversing. В нашей команде было до 10 человек, и у нас получилось поднять 2,6 миллиона инвестиций.

Если раньше я просто занимался программированием, наймом, чуть-чуть управлением, то теперь вся техническая часть компании лежала на мне. Я был Director of Software Development. К тому же мой партнер практически не говорил по-русски. Он знал пару слов из серии: «Привет», «Пока», «Один кофе, пожалуйста». Слово «один», кстати, его очень забавляло, так как оно созвучно с именем скандинавского бога :)

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

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

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

Эксперименты в Genesis

Закрыв стартап, я пришел в Genesis на позицию СТО. Это большая продуктовая компания, которая разрабатывает и поддерживает высоконагруженные медиаресурсы.

Здесь я систематизировал свои знания в плане найма. Раньше у меня был свой подход, представления о матрице скилов, но затем я понял, насколько эти вещи вторичны. На меня очень повлияла книга «Who: The A Method for Hiring»Джеффа Смарта и Рэнди Стрита — мне ее посоветовал Вова Многолетний, основатель Genesis. Читая, я узнавал свои ошибки и понимал, как расти.

За время моей работы в Genesis мы мигрировали все с WordPress на наш собственный движок. Добавили систему аналитики, которая рассчитывала LTV практически за день. Разрабатывали различные системы персонализации — пытались всеми доступными способами увеличивать вовлечение пользователей.

Было еще много экспериментов. Я инициировал разработку кластера, который масштабируется автоматически. Идея создать такой кластер мне пришла после того, как в Казахстане, где у нас крупный медиаресурс, произошли теракты. Все наши конкуренты легли, а наш сайт чудом остался жив — спас Amazon. Мы получили 10-кратныйприрост трафика, сделав квартальную выручку за один день. И если в Казахстане с населением 17 млн человек наши мощности выдержали нагрузку, то в 200-миллионнойНигерии, где у нас такой же ресурс, этот фокус бы не удался. В то же время, переплачивать за резервные мощности на постоянной основе — не выгодно. Так и был разработан кластер, мощности которого регулируются в зависимости от ключевых метрик, количества процессов и используемой оперативной памяти.

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

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

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

Тогда я решил пойти ва-банк и сделать спортивное media-publishing направление. Составил финансовую модель, бизнес-план, донес основателям Genesis свое видение, как собираюсь делать контент и маркетинг. Мне выделили несколько траншей инвестиций — суммарно 500 тыс. долларов. Так появилась LiveZone — дочерняя компания Genesis.

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

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

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

Cools — симбиоз медиапаблишера и e-Commerce

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

Такой компанией оказалась Cools, к команде которой я присоединился в июне этого года. Cools — это американская fashion-платформа, которая объединяет онлайн-медиа и шоппинг-агрегатор. Журнал и интернет-магазин полностью интегрированы друг в друга. Cools заключает сделки с различными брендами, в том числе Gucci, Yves Saint Laurent, и по партнерской программе продвигает их товары. Один из основных каналов трафика — платные привлечения через AdWords.

Проанализировав концепцию Cools, я понял, что если бы еще в LiveZone сделал монетизацию не за счет рекламы, а за счет e-Commerce, партнерских программ, то нам бы не пришлось закрываться после изменения политики Facebook.

Редакция Cools находится в Нью-Йорке, а техническая команда — в Киеве. Здесь нас 14 человек. Сейчас, кстати, ищем дизайнера.

Я занимаю позицию СТО: отвечаю за разработку, и ее влияние на бизнес. Помимо этого, участвую в принятии решений по вопросам монетизации, рекламных кампаний, SEO-стратегии, глобального улучшения наших продуктов. Пожалуй, в Cools реализовались 90% всех моих знаний и полученного опыта — наверное, все, кроме квантовой физики :)

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

Если говорить о технологиях, платформа представляет собой симбиоз PHP (новостная часть) и Python (агрегатор товаров). Используем Elasticsearch, постоянно экспериментируем с релевантностью поиска.

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

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

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

8:00.Встаю, завожу ребенка в садик, еду на работу. Если я не за рулем, то по дороге заглядываю в Google-аналитику, смотрю результаты вчерашнего дня, проверяю почту, отвечаю на срочные письма.

9:00-10:00.Приезжаю в офис. Как правило, появляюсь одним из первых :) Смотрю, что происходит на наших серверах в Amazon. Если там все стабильно, залажу в Search Console, смотрю, нет ли там каких ошибок. Дальше проверяю аналитику по части закупок и монетизации.

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

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

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

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

16:30.Созваниваемся с ребятами из Нью-Йорка. В Штатах работают наши редакторы, а также специалисты по рекламе и продвижению.

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

19:00.В конце дня проверяю трекинговые системы, где кто какие комментарии оставил по задачам.

19:30.После работы уделяю время семье, но нельзя сказать, что заканчиваю работать. У меня выработалась привычка всегда брать с собой ноутбук. С помощью телефона мониторю аналитику, заглядываю в рабочий чат. Мне понравилась статья Джефа Безосао том, что нет смысла искать этот work&life баланс — нужно просто найти работу, которая будет максимально интегрирована с твоей жизнью, органически станет ее частью.

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

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

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

Для коммуникации используем чат Discord. Разработку веду в PhpStorm и PyCharm. Для работы с данными очень нравится Tableau. Незаменим пакет от Google: Google-аналитика, инструменты AdWords, Google Data Studio. Также многое делаю прямо в консоли терминала — это быстро и удобно. Раньше часто использовал GitStats — приложение, которое позволяет анализировать и визуализировать статистику по разным репозиториям.

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

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

В том, что касается продуктивности команды, мне понравилось исследование командной динамики по Брюсу Такману — о том, как люди взаимодействуют друг с другом в закрытом пространстве. Каждая команда проходит 5 фаз:

1. Формирование команды. В это время каждый пытается казаться лучше, чем он есть на самом деле. Делает больше, чем нужно. Наивно полагать, что так будет всегда.
2. Шторм. Команда выясняет, по чьим правилам будет игра. В это время эффективность команды падает практически там до нуля. Это важный момент для руководителя команды. Его задача — отделить конструктивную критику от простых возмущений. На этом этапе важно уделять 80% времени тем людям, которые поставляют 80% результата.
3. Нормализация. Ребята понимают, зачем они нужны друг другу. Как команда они производят больше пользы, чем каждый из них по отдельности. Эффективность снова возрастает.
4. Работа. Команда срабатывается, минимизируются коммуникационные издержки. Важно сделать так, чтобы эта фаза длилась как можно дольше.
5. Реформация. Кто-то выгорает, кто-то уходит. С добавлением каждого нового человека команда проходит предыдущие фазы заново, но уже не так выражено, как в первый раз.

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

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

Сейчас читаю третье или четвертое издание «The Art of SEO» — хочу систематизировать свои знания по SEO. Эта книга нравится тем, что она максимально приближена к бизнесу.

Другие книги, которые недавно читал: «Легко не будет»Бена Хоровица и «Лекции по физике»Ричарда Феймана.

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

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

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

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

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

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

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

Если говорить о планах на будущее, мне бы хотелось, чтобы наш проект достиг максимального успеха. Меня вдохновляет опыт компании Ring, которая в результате миллиардной сделки была поглощена Amazon. Это очень крутой кейс. У них R&D в Украине.

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

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

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

Олексій Єгоров, 34 роки, Senior JavaScript Developer

З професією я визначився в 11 років. Коли батьки подарували мені ZX Spectrum, я вирішив стати програмістом. Попрацював у різних компаніях: був підрозділ Oracle, відомий ігровий гігант, пара фріланс-проектів, декілька «галер». Зараз працюю на ізраїльську компанію, яка займається розробкою SaaS-продукту для організації масових заходів (конференцій, концертів, виставок тощо).

Я закінчив технікум радіоелектронного приладобудування на Донбасі. Після цього збирався вступити до ХАІ, але не набрав балів на безкоштовне навчання, а з грошима в мене було тоді дуже погано, тому платне навчання я би не потягнув.

У 21 рік, у далекому 2005-му,я працював на вуглепереробному підприємстві системним адміністратором. Паралельно вивчав PHP та JavaScript. На підприємстві мені доводилося займатися всім і одразу: їздити за картриджами для принтера, лагодити Wi-Fi на даху цехових приміщень, програмувати в MS Access і в 1С та розробляти корпоративний сайт. Там вища освіта в принципі нікого не цікавила, а про досвід роботи я трохи прибрехав, бо взагалі такого не мав. Потім було дуже весело навчатися усього на місці. Старший адмін мені каже: «Попінгуй роутер». Я кажу: «Окей». Телефоную приятелеві (бо ж інтернету немає — роутер упав!) і питаю його: «Що таке роутер і як його попінгувати?». Утім, я швидко вчився. Треба сказати, що ця організація була напівлегальною, і порядки там були, як на піратській шхуні. Але той божевільний драйв був дуже корисним, бо довелося швидко опановувати величезну кількість технологій.

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

Тоді у Харкові я побачив, що крім піратських шхун існують досить пристойні компанії, де (о диво!) п’ятиденний режим роботи. І знов-таки, в ЗАО «Мета» мене ніхто не питав про освіту. Їх цікавили інші речі, а саме знання мов програмування, вміння вирішувати теоретичні задачі, досвід та портфоліо. Цього разу брехати не довелося. Портфоліо в мене вже було, я тоді написав портал пошуку роботи, дошку оголошень, свою невеличку CMS.

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

Щодо самоосвіти — першою моєю книжкою з програмування був «Бейсік для дітей» (С. Ватт, М. Мангада). Я був тоді малий, у мене не було комп’ютера, і перші програми я писав в зошиті. Потім у підлітковому віці було щось про Turbo Pascal, не пам’ятаю точно. Після цього викладач інформатики в технікумі дав мені підручник із С++ Герберта Шилдта, і це перевернуло мої уявлення про програмування. Потім було багато RTFM з різних галузей IT. З 2005-2010 яопанував JS, PHP (вже не пам’ятаю, за якими джерелами, їх було дуже багато — в основному онлайн-туторіали), MS Access, 1C, Linux, Node, Python та багато інших речей.

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

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

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

Ігор Вовк, 26 років, Software Engineer

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

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

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

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

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

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

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

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

Для вивчення основ програмування можу порекомендувати JavaRush, Learn Javascript. Гарні безплатні книги про функціональне програмування та Scala можна знайти на Underscore, розділ «Books».

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

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

Мене потім ще довго дивувало, що можна робити зовсім по-іншому — здобувати знання, коли тобі потрібно і які потрібні. Онлайн-освіта, менторство, конференції, юзер-групи — усе це сучасні інструменти для навчання в режимі «ad-hoc».

Диплому отримувати не планую, але все ж продовжив вчитися на психолога — у недержавній установі.

Игорь Бондаренко, 28 лет, Web Developer

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

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

Первую работу нашел, еще когда учился в колледже, порекомендовали знакомые, но там проработал не долго. Диплом не спрашивали, так как еще учился. Вот второе место, тоже было во время учебы в колледже... Там диплом спрашивали, но я объяснил ситуацию и как-то взяли без него. Сказали: «Закончишь учиться — принесешь» :)

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

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

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

Роман Севастьянов, 22 роки, Software Entrepreneur

Перший раз я зіткнувся з вебом років у 12, коли грав у онлайн-ігри, але тоді не дуже розумів технічну сторону. За відкладені на шкільних обідах 50 грн купив ігровий сервер GTA SA:MP — довелося розбиратися з PHP, MySQL, HTML/CSS, JS, Pawn — це в 13-14 років.Через декілька років я почав фрілансити, у 18 влаштувався в продуктову компанію Paymentwall. Через 3 роки почав віддалено працювати на американських замовників і створювати команди розробки в Україні для них. В 2017 році заснував онлайн-школу програмування doge.codes.

Вступив до ЧНУ ім. Юрія Федьковича на прикладну математику. Я не мав великих надій на виш, але варто було спробувати. Через 2-3місяці сумлінного навчання зрозумів, що система неефективна, і втратив мотивацію. Після першого курсу я переїхав у Київ і перевівся до НАУ. Відвідував пари рідко, аж поки не переїхав у В’єтнам з відкриттям там нового офісу Paymentwall. На наступній сесії мене виключили, бо я був за 10 000 км від університету :) Я вважаю, що зробив правильно. Досвід проектів з реальними фахівцями дав більше знань і знайомств, ніж університет.

Не враховуючи фріланс, я знайшов першу роботу у 18 років. Шукав на звичних сайтах з вакансіями. Співбесіди проходив спочатку по скайпу (бо жив у Чернівцях, а там півтори нормальних ІТ-компанії), виконував тестові і потім їхав у київський офіс знайомитись. За 2 тижні я отримав 2-3офери і вибрав Paymentwall. Мені було цікаво працювати над продуктом, інші компанії були веб-агентствами чи аутсорсом.

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

Я вивчав ІТ за допомогою всього: відеокурси, YouTube-лекції, задачі з програмування, книжки (точно пам’ятаю, що прочитав одну книгу по HTML/CSS і по Ruby on Rails). Не було якогось плану — читав і дивився все. За 1-2інтенсивні місяці я зміг зрозуміти основи веб-програмування і потім отримувати перші проекти на фрілансі. Вчився тоді по 8-12годин в день. Важко оцінити загальну тривалість мого навчання, бо я не перестаю вчитись і досі.

На мій погляд, більшості вища освіта не потрібна взагалі ні в Україні, ні за кордоном. Проблему вищої освіти за кордоном добре розкрив Пітер Тіль у відео Is Higher Education a Scam?. Наразі є величезна кількість ресурсів для самостійного вивчення будь-якої теми в програмуванні.

Я зустрічав багато дипломованих програмістів, навіть магістрів, які не можуть зробити прості неглючні фічі (наприклад, отримати текст з БД і покласти його назад). І також зустрічав таких, що без вищої освіти програмують складні Machine Learning системи, працюють у Facebook і Google, запускають свої стартапи і стають мільйонерами в 20+ років. Усе залежить від людини. Втрачати найкращі роки на здачу лабораторної викладачу, який не вміє програмувати і живе в 90-хя не збираюсь.

Андрей Ласкевич, 24 года, Junior PHP Developer

Свою карьеру в IT я начал в веб-студии SimplaMarket. Работаю в ней уже 8 месяцев PHP-разработчиком. Делаю back-end для интернет-магазинов на базе OkayCMS и SimplaCMS.

Я учился в Днепропетровской медицинской академии. Пошел туда потому, что так сказали родители, но, к сожалению, разочаровался в медицине. Всегда любил технологии, любил разбираться в компьютере и следил за новостями IТ, но не хватало духу сказать родителям, что хочу бросить университет. Удовольствия от обучения не было. На 6-мкурсе ушел из медакадемии, потому что понимал, что придется идти дальше в интернатуру на 2 года, а потом еще 3 года отработки.

После ухода из университета я нашел работу в call-центре аптеки. И параллельно обучался на курсах PHP в IMT Academy. Занятия проходили по выходным, а в будние дни я работал в call-центре. По началу мне было очень трудно, потому что нужно было учить frond-end вместе с back-end, и спустя месяц я хотел бросить обучение. Потом я понял, что должен идти до конца, и остался на курсах. У меня был хороший преподаватель — Александр Михайленко. Он давал на занятиях ту информацию, которая в будущем пригодилась мне на работе. Помимо обучения на курсах, я просматривал уроки на YouTube, читал статьи на Хабре и много практиковался.

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

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

Немного о себе, DOS и терпении

В IT я официально почти 13 лет, из них около 9 работаю Penetration Tester в разных компаниях. Неофициальный путь начался намного раньше. Все базовые компьютерные знания я добывал из библиотечных книг. Google тогда был таким себе помощником, а покупать IT-литературу в то время в Бразилии было непозволительной роскошью. Но однажды на свой день рождения я получил PHP Bible, с помощью которой написал свой первый шелл на PHP для эксплуатации Remote File Inclusion (RFI) уязвимостей.

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

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

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

Какой опыт поможет

Иногда меня спрашивают, какой бэкграунд больше подойдет для того, чтобы стать Security или Penetration Tester. Однозначного ответа дать не могу. Все зависит от того, в какую именно сферу безопасности вы переходите. Например, для исследования вредоносных программ хорошим бэкграундом будет знание ассемблера. С другой стороны, для Web Pentester неплохой стартовой площадкой станут Javascript-, HTML-навыки и, конечно же, понимание сетевых технологий. Не думайте, что установка Kali Linux на вашей машине волшебным образом делает вас пентестером. Этот процесс отнимает время, и, по-честному, очень много времени.

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

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

Ссылки и литература

Базовые знания

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

• администрирование Linux;
• администрирование Windows;
• какие-то навыки в языках программирования (Perl, Python, Ruby, JavaScript), также для веб-пентестов потребуется HTML;
• основные сетевые протоколы (TCP/IP, ICMP) / сетевые службы (Proxy, VPN, Samba, AD);
• протоколы: HTTP, FTP, DNS, SSH;
• базы данных SQL (DDL, DML и т. д.), MySQL, SQL Server, PostgreSQL, Oracle.

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

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

Далее самое главное — знать, как все работает.

Я знаю много «хакеров», которые могут удалить целые базы данных, но даже не подозревают, как работает оператор SELECT или CREATE TABLE. Или ребят, которые могут положить сервер, но даже не знают, что такое ICMP type 8. И даже не буду обсуждать тех, кто использует SET для захвата учетных данных Facebook.

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

Ресурсы для изучения

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

• Modern_Operating_Systems — Wikipedia;
• Computer Networks, by Andrew S. Tanenbaum, David J. Wetherall;
• HTTP: The Definitive Guide, by David Gourley, Brian Totty, Marjorie Sayer, Sailu Reddy;
• Introduction to Linux — course on edX;
• Linux Academy;
• linux-training.be — books;
• HTML&CSS design and build websites — book;
• Programming_Logic — Wikipedia;
• Python For Beginners;
• Beginning Perl — book;
• SQLCourse.com — online training.

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

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

• Web Pentesting;
• Network Pentesting;
• Mobile Pentesting;
• SCADA Pentesting;
• Reverse Engineering;
• Malware Analysis;
• Forensics;
• Security Research;
• Hardware Security;
• Exploitation.

Конечно, вы можете изучать и более одной темы одновременно.

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

Если вы планируете использовать Kali для начала учебы, стоит ознакомиться с официальной документацией. Рекомендую сделать это, прежде чем переходить на канал #kali-linux на Freenodeи задавать вопросы. Кроме того, можно использовать Kali Linux Forums. Дополнительно, поскольку Kali основан на Debian, неплохо бы проверять документацию Debian Linux, если вы не знакомы с этим дистрибутивом.

Еще Hacking Exposed series — очень хорошая серия книг, которая охватывает множество разных тем.

Серия книг, которая раскрывает темы по Mobile, Android, Cars и другим, а не только веб-приложениям — Hacker’s Handbook series.

Полезна книга SQL Injection Attacks and Defense, by Justin Clarke.

В целом в Гугле есть большое количество книг, если вбить в поиске «pentest Kali Linux». Выберите одну и начинайте обучение.

Дополнительно

Еще несколько ссылок:

• How to become a pentester — отсюда можно взять кусочки.
• Vulnhub — множество уязвимых машин, чтобы потренироваться.
• securitytube.com — множество видеороликов и руководств по безопасности.
• cybrary.it — еще больше видеороликов о безопасности.
• Pentester Lab — различные упражнения для пентестинга.
• Hacking: The Art of Exploitation — низкоуровневая эксплуатация.
• owasp.org.
• Awesome Penetration Testing — подборка ресурсов на GitHub.
• 22 Hacking Sites, CTFs and Wargames To Practice Your Hacking Skills.

Международные сертификаты:

• Offensive Security
• Kali Training
• eLearnSecurity
• Sans
• EC-Council

Два часто задаваемых вопроса

Сколько времени может занять переход в пентестеры?Я бы говорил о годах. При должном стремлении — 4 или 5 лет. Честно говоря, не могу подсчитать, сколько встреч с друзьями мне пришлось отменить, чтобы успеть написать код или проэксплуатировать какой-то сложный кейс. Здесь по классике — под лежачий камень вода не течет.

Что насчет денег? В силу опыта, могу дать информацию по Польше. Насколько я анализировал рынок, в сфере security средняя зарплата находится в диапазоне от 7-8 тыс.злотых до 22 тыс. злотых (или же $1,5-5 тыс.). К тому же можно брать фриланс-проекты.

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

...
— Достало меня это «внутри нет деталей, обслуживаемых пользователем». Хочется посмотреть, что же там есть.
...
— Русская матрешка до самой глубины. Правда, Ороско? Хуан не стал смотреть, что такое русская матрешка.
— Да это же мусор, профессор Гу. Кому оно надо — с таким возиться?

«Конец радуг»Виндж Вернор

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

Немного теории и истории

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

Допустим, мы любим и умеем писать свои велосипеды. И что мы получим в результате:

• что-нибудь типа обратной пересылки из C++ кода подписавшимся;
• управление обработкой в нативном коде, то есть мы можем не загоняться по поводу расчетов, когда нет подписчиков и некому их отправлять;
• может понадобиться и пересылка данных между разными JVM;
• и чтобы два раза не вставать, заодно и пересылка сообщений внутри потоков проекта.

Реализация

Попробуем в лучших традициях DIY, так сказать, «помигать светодиодом». Если вы используете JNI, в мире Android NDK вы можете запросить метод Java асинхронно, в любом потоке. Это мы и используем для построения своего «Наблюдателя».

Демопроект построен на шаблоне нового проекта из Android Studio.

Это автосгенерированный метод. Он комментирован.

// Used to load the 'native-lib' library on application startup.
static {
    System.loadLibrary("native-lib");
}

А теперь сами. Первый шаг — метод nsubscribeListener.

private native void nsubscribeListener(JNIListener JNIListener);

Он позволяет C++ коду получить ссылку на java-код для включения обратного вызова к обьекту, реализующему интерфейс JNIListener.

public interface JNIListener {
    void onAcceptMessage(String string);

    void onAcceptMessageVal(int messVal);
}

В реализацию его методов и будут передаваться значения.

Для эффективного кэширования ссылок на виртуальную машину сохраняем и ссылку на объект. Получаем для него глобальную ссылку.

Java_ua_zt_mezon_myjnacallbacktest_MainActivity_nsubscribeListener(JNIEnv *env, jobject instance,
                                                                   jobject listener) {

    env->GetJavaVM(&jvm); //store jvm reference for later call

    store_env = env;

    jweak store_Wlistener = env->NewWeakGlobalRef(listener);

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

jclass clazz = env->GetObjectClass(store_Wlistener);
jmethodID store_method = env->GetMethodID(clazz, "onAcceptMessage", "(Ljava/lang/String;)V");
jmethodID store_methodVAL = env->GetMethodID(clazz, "onAcceptMessageVal", "(I)V");

Данные о подписчике хранятся как записи класса ObserverChain.

class ObserverChain {
public:
    ObserverChain(jweak pJobject, jmethodID pID, jmethodID pJmethodID);

    jweak store_Wlistener = NULL;
    jmethodID store_method = NULL;
    jmethodID store_methodVAL = NULL;

};

Сохраняем подписчика в динамический массив store_Wlistener_vector.

ObserverChain *tmpt = new ObserverChain(store_Wlistener, store_method, store_methodVAL);

store_Wlistener_vector.push_back(tmpt);

Теперь о том, как будут передаваться сообщения из Java-кода.

Сообщение, отправленное в метод nonNext, будет разослано всем подписавшимся.

private native void nonNext(String message);

Реализация.

Java_ua_zt_mezon_myjnacallbacktest_MainActivity_nonNext(JNIEnv *env, jobject instance,
                                                                jstring message_) {
    txtCallback(env, message_);
}

Функция txtCallback(env, message_);рассылает сообщения всем подписавшимся.

void txtCallback(JNIEnv *env, const _jstring *message_) {
    if (!store_Wlistener_vector.empty()) {
        for (int i = 0; i < store_Wlistener_vector.size(); i++) {
            env->CallVoidMethod(store_Wlistener_vector[i]->store_Wlistener,
                                store_Wlistener_vector[i]->store_method, message_);
        }
    }
}

Для пересылки сообщений из С++ или С кода используем функцию test_string_callback_fom_c

void test_string_callback_fom_c(char *val)

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

if (store_Wlistener_vector.empty())
    return;

Легко увидеть, что для посылки сообщений используется все та же функция txtCallback.

void test_string_callback_fom_c(char *val) {
    if (store_Wlistener_vector.empty())
        return;
    __android_log_print(ANDROID_LOG_VERBOSE, "GetEnv:", " start Callback  to JNL [%d]  \n", val);
    JNIEnv *g_env;
    if (NULL == jvm) {
        __android_log_print(ANDROID_LOG_ERROR, "GetEnv:", "  No VM  \n");
        return;
    }
    //  double check it's all ok
    JavaVMAttachArgs args;
    args.version = JNI_VERSION_1_6; // set your JNI version
    args.name = NULL; // you might want to give the java thread a name
    args.group = NULL; // you might want to assign the java thread to a ThreadGroup

    int getEnvStat = jvm->GetEnv((void **) &g_env, JNI_VERSION_1_6);

    if (getEnvStat == JNI_EDETACHED) {
        __android_log_print(ANDROID_LOG_ERROR, "GetEnv:", " not attached\n");
        if (jvm->AttachCurrentThread(&g_env, &args) != 0) {
            __android_log_print(ANDROID_LOG_ERROR, "GetEnv:", " Failed to attach\n");
        }
    } else if (getEnvStat == JNI_OK) {
        __android_log_print(ANDROID_LOG_VERBOSE, "GetEnv:", " JNI_OK\n");
    } else if (getEnvStat == JNI_EVERSION) {
        __android_log_print(ANDROID_LOG_ERROR, "GetEnv:", " version not supported\n");
    }

    jstring message = g_env->NewStringUTF(val);//

    txtCallback(g_env, message);

    if (g_env->ExceptionCheck()) {
        g_env->ExceptionDescribe();
    }

    if (getEnvStat == JNI_EDETACHED) {
        jvm->DetachCurrentThread();
    }
}

В MainActivity создаем два TextViewи одно EditView.

<TextView
    android:id="@+id/sample_text_from_Presenter"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_weight="1"
    android:padding="25dp"
    android:text="Hello World!from_Presenter"
    app:layout_constraintBottom_toTopOf="parent"
    app:layout_constraintEnd_toStartOf="parent"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toTopOf="parent" /><TextView
    android:id="@+id/sample_text_from_act"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:layout_weight="1"
    android:text="Hello World from_ac!"
    app:layout_constraintBottom_toTopOf="parent"
    app:layout_constraintStart_toStartOf="@+id/sample_text_from_Presenter"
    app:layout_constraintTop_toTopOf="parent" /><EditText
    android:id="@+id/edit_text"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"

    android:text="Hello World!"
    app:layout_constraintBottom_toTopOf="parent"
    app:layout_constraintStart_toStartOf="@+id/sample_text_from_act"
    app:layout_constraintTop_toTopOf="parent" />

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

mEditText = findViewById(R.id.edit_text);
mEditText.addTextChangedListener(new TextWatcher() {
    @Override
    public void beforeTextChanged(CharSequence charSequence, int i, int i1, int i2) {

    }

    @Override
    public void onTextChanged(CharSequence charSequence, int i, int i1, int i2) {
        nonNext(charSequence.toString());
    }

    @Override
    public void afterTextChanged(Editable editable) {

    }
});
tvPresenter = (TextView) findViewById(R.id.sample_text_from_Presenter);

tvAct = (TextView) findViewById(R.id.sample_text_from_act);

Заводим и регистрируем подписчиков.

mPresenter = new MainActivityPresenterImpl(this);
nsubscribeListener((MainActivityPresenterImpl) mPresenter);

nlistener = new JNIListener() {
    @Override
    public void onAcceptMessage(String string) {
        printTextfrActObj(string);
    }

    @Override
    public void onAcceptMessageVal(int messVal) {

    }
};
nsubscribeListener(nlistener);

Выглядит это примерно так:

Код примера лежит здесь: github.com/NickZt/MyJNACallbackTest

В общем пока все, sapienti sat.

За підсумками першого півріччя 2018 року ТОП-50 досяг нової відмітки — 52 тисячі спеціалістів, з яких 41 тисяча — технічні фахівці. Уже друга ІТ-компанія в Україні переступила відмітку 5 000 спеціалістів, а одна з компаній з ТОП-50 на ринку майже 30 років.

Із січня по липень 2018 року кількість фахівців зросла на 2 913 осіб (5,8%) в ТОП-50 і на 2 252 (5,8%) в ТОП-25 порівняно з другим півріччям 2017 року. Темпи зростання ТОП-25 майже ті ж самі, що й у першому півріччі 2017 року — 5,8% проти 6,2%.

Зростання «великої п’ятірки» за перші півроку 2018 склало 6% (1 186 фахівців). Усього в ТОП-5 працює 21 292 спеціалісти, що складає 40% від загальної кількості ТОП-50.

Лідер рейтингу — EPAM — з січня по липень продемонстрував помірне зростання — 200 осіб. Нагадаємо, що за 2017 рік компанія виросла на 900 осіб.

Компанія SoftServeза підсумками першого півріччя виросла на 516 осіб та стала другою ІТ-компанією в Україні, яка переступила відмітку 5 000 фахівців.

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

Високі темпи росту демонструє GlobalLogic — компанія за перше півріччя збільшилася на 250 осіб. За даними компанії, у 2018 році ріст був у всіх локаціях. Кількість фахівців у Києві впритул наблизилася до позначки 1900, центр розробки у Львові скоро перевищить позначку 900 фахівців, а офіс у Харкові зовсім недавно відсвяткував досягнення кількості 800 консультантів. Зростання компанії пов’язане з інтенсивним розвитком існуючих і стартом нових R&D-проектів в області телекому, мультимедіа, медицини, автомобільних технологій тощо.

Також у першому півріччі 2018-гоCiklumпоказує високі темпи росту — за шість місяців компанія виросла на 8% (або на 215 осіб). Нагадаємо, що минулого року у компанії була негативна динаміка зростання в Україні через завершення роботи з SBTech та активний розвиток офісів в Іспанії та Польщі.

За друге півріччя абсолютні прирости понад 200 чоловік показали шість компаній: SoftServe (+516 спеціалістів), GlobalLogic (+250), EVOPLAY (+250), Ciklum (+215), EPAM (+200), Intellias (+200).

Лідерами серед відносного приросту стали: Tap Media (+28%), Dev-Pro.net (+26%), Intellias (+20%), Genesis (+17%), AMC Bridge (+16%), Innovecs (+15%), Ring Ukraine (+11%), SoftServe (+10).

Нагадаємо, у лютому стало відомо, що Amazon купує стартап Ringз R&D-центром у Києві за $1 млрд. Незважаючи на деякі побоювання щодо подальшого зростання київського офісу, у першому півріччі Ring Ukraine виріс на 11%.

За даними Dev-Pro.net, одного з лідерів за відносним приростом, найактивніше розвивалися їх київський та харківський офіси. У попиті були JavaScript та .NET спеціалісти, а також бізнес-аналітики та менеджери проектів.

Наймолодша — Ring Ukraine, найстарша — Miratech

Більшість ІТ-компаній з ТОП-50 знаходяться на українському ринку від 10 до 20 років. Наймолодшою компанією в списку є Ring Ukraine — працює лише 2 роки в Україні. Найстаршою — Miratech — майже 30 років на ринку.

43 компанії з ТОП-50 мають офіси в Києві

Переважна більшість компаній з ТОП-50 присутня у столиці. 13 компаній мають офіси тільки в Києві. Цікаво, що у Львові працює більше ІТ-спеціалістів з ТОП-50, ніж у Харкові. Проте точну цифру, наскільки більше, надати важко, бо не всі компанії поділилися даними з розподілу спеціалістів.

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

За перші 6 місяців 2018-гомайже вдвічі менше компаній відкрили нові офіси, ніж у липні-січні 2017 року (6 проти 11). Також не дуже різноманітна географія — нові офіси з’явилися у Києві, Харкові, Львові та США.

Більшість компаній планують помірне зростання до кінця року

54% компаній планують збільшити кількість спеціалістів у межах 20-100осіб у другому півріччі. Активно зростати (більш ніж на 100 спеціалістів) планує кожна четверта компанія. Про скорочення до кінця року не згадав жоден роботодавець.

Як і минулого року, більшість компаній не планують вивозити спеціалістів за межі країни.

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

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

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

Уcім привіт! Мене звуть Максим Волошин, я живу і працюю в Чехії. Хотів би поділитися своїм досвідом влаштування в Amazon нетехнічним спеціалістом, а також життя у Празі.

Я народився в Кривому Розі, навчався в НТУУ КПІ на факультеті електроніки. Під час навчання тимчасово працював інженером з упровадження нових технологій на заводі Procter & Gamble у Покрові (Дніпропетровська обл.), а також був віце-президентом молодіжної організації AIESEC Україна у сфері вихідних стажувань. Після закінчення університету поїхав на стажування до Швеції в компанію Husqvarna, потім знайшов позицію менеджера з поставок матеріалів на заводи у Procter&Gamble і переїхав до Варшави.

Після двох років праці вирішив шукати перспективнішу роботу — зімпонував Amazon, бо компанія стрімко розвивається. Варіанти на позицію Transportation Program Manager, на яку подавався, були в Лондоні і Празі. Вибрав останню, оскільки з Польщі було зручніше переїхати до Чехії. Працюю тут із жовтня минулого року.

Співбесіди

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

Я орієнтуюся більше на цінності і репутацію компанії, ніж на специфічну позицію. Тому спочатку визначаю, в якій компанії я би хотів працювати. У великих компаніях необхідні спеціалісти з різних сфер, тому завжди для себе можна знайти щось цікаве. Я обрав саме компанію Amazon, а вже потім дивився всі вакансії і знайшов ту, що цікава мені — Transportation Program Manager.

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

В Amazon усі сервіси централізовані в певні хаби. У Празі, наприклад, є величезний HR-хаб (на 700-800 людей),які працюють на Європу. Людина, яка мене підбирала, — з хабу HR, розташованого у Британії.

Перша моя співбесіда була з ейчаром по телефону. Розмова зайняла десь 50 хвилин, результат повідомили через кілька днів. Потім було цілоденне інтерв’ю з чотирма представниками відділу, де працюватиму (двоє на один рівень вище за той, на який подавався, і двоє — на два рівні вище). На це інтерв’ю був вибір: поїхати до Праги або до Лондона, тому що наш офіс розділений між цими двома локаціями. Вибрав Лондон, оскільки ще мав візу туди. Було чотири співбесіди, кожна тривала по 40-50 хвилин.Питання були дуже різноманітні — про емоційний інтелект і професійну сферу, але всі відповіді потрібно обґрунтовувати прикладами з досвіду. Як на мене, нічого складного, але енергії потребує багато. Подався у середині лютого 2017-го,панельне інтерв’ю було у середині березня, а офер отримав наприкінці березня.

Документи

Почав готувати документи на візу — і тут почалося найскладніше. До Чехії дуже важко своєчасно отримати візу. Власне довготривалої робочої візи тут, на відміну від тієї ж Польщі, практично не видають. На довготривалу роботу відразу дають work permit, але оформлення може зайняти багато часу. Я подав усі документи (з допомогою партнерської компанії Amazon, яка займається такою роботою) у середині квітня, а дозвіл отримав у середині вересня — п’ять з половиною місяців довелося чекати. Торік у травні моя дівчина теж знайшла роботу в Чехії і подала документи. Але вже минуло понад рік — і досі не отримала відповіді від чеської влади. Якщо компанії менші, ніж глобальні корпорації, то процес подачі документів може зайняти більше часу. Працедавці тут не дуже зацікавлені в людях з-за меж ЄС, бо їм треба чекати робітника до року. На мою думку, через це не вистачає кваліфікованої робочої сили. Надто довго все перевіряють.

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

Вимагають неймовірну кількість документів. У тому числі в мене просили виписку з поліції з України (хоч три роки там не жив), з Польщі, Чехії (хоч я там раніше навіть не жив) та зі Швеції (навіть апостильовану). Якби робив усе сам, то довелося б їхати до Швеції, брати там довідку з поліції, потім ще чекати на апостиль. Допомогла партнерська компанія Аmazon. Тамтешній працівник зі шведського офісу ходив у поліцію і потім надсилав документи в головний офіс компанії.

Ще, як і всюди в Європі, потрібна реєстрація місця проживання, щоб отримати дозвіл на роботу. Та в Чехії незрозумілий порядок від початку. Реєстрація потрібна ще на моменті подачі документів, тобто ти ще не перебуваєш там, а вже треба бути зареєстрованим. Це нереально, бо неможливо зняти житло для реєстрації без дозволу на перебування. Тому в основному тут роблять частково фіктивну реєстрацію. Уже потім приїжджають, знаходять житло і переробляють карту. Знову треба йти в офіс служби, а це коштує додаткові 30-50 євро.

Робота

За 9 місяців роботи я змінив три відділи і трьох менеджерів. Спершу я працював Transportation Program Manager в Network Operations Center, який відповідає за те, щоб вантажівки з товарами приїжджали на склади Аmazon своєчасно і ефективно.

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

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

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

IT-ринок і податки

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

У Чехії створені IT-проекти глобального рівня (Avast, JetBrains). Ще у Празі є хіпстерські райони, де відбуваються IT-тусовки. Там молоді люди спілкуються про крипту, займаються 3D-друком. Українських айтішників я тут не зустрічав. Можливо, тому, що я не в тусовці.

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

Загалом айтішники у Чехії не виглядають особливо багатшими, ніж неайтішники — все якось рівніше. Усі сплачують схожі податки, аналогів українських ФОПів тут в IT часто не використовують.

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

Житло

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

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

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

Перші два місяці знімав квартиру на Airbnb. Якщо винаймати на такий тривалий термін, іноді дають знижку 25-50%.Ще одна перевага — маєш час оцінити ринок, підібрати варіанти, зрозуміти, який район подобається. Тому я рекомендував би всім шукати таке тимчасове житло.

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

У середньому місячна оренда двокімнатної квартири коштуватиме від 16 до 20 тисяч крон, компослуги — 3-4тисячі крони (одна чеська крона = 1,2 гривні). Тобто в сумі буде десь 780-950 євро.

Наше помешкання розташоване у районі метро Petriny, це вважається віддаленим районом. Але від дверей квартири до дверей офісу — 28 хвилин, станція метро — за 30 метрів від дому. До центру їхати 12 хвилин на метро. Спальні райони тут гарно влаштовані, комфортні: метро, транспорт, дитсадки, безпека, немає умовної Троєщини.

Іпотека

Коли переїжджали, хотіли брати житло в іпотеку. Але є не одне «але». По-перше, ринок дуже перегрітий через експатів. Багато німців та інших іноземців купують житло тут, щоб здавати в оренду або на перспективу мати для себе, бо Прага — місто, яке розвивається. А житло все ж не надто активно будують. Тому в середньому найслабший варіант двокімнатної квартири коштуватиме від 3 до 4 мільйонів крон (120-150 тис.євро) залежно від району. У новобудові або кращому районі — до 5,5 мільйонів (приблизно 170 тис. євро).

Відсотки нараховуються в залежності від того, які в тебе зв’язки з Чеською Республікою. Якщо не маєш дозволу на проживання або робочого дозволу, то треба відразу заплатити 40-50%від загальної суми. І відсоток буде високим — 3,9-4,9%.У мене з робочим дозволом відсоток складав би 2,6% (не до порівняння з українськими), але все одно багато. Перший внесок для мене має бути 30-40%.Для чехів або тих, хто має громадянство / постійну посвідку на проживання, кредитний відсоток ще нижчий — 1,8%. А перший внесок — 15-20%.Є сенс брати іпотеку, якщо прожив певний час і маєш посвідку або громадянство.

Медицина

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

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

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

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

Мова

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

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

Люди

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

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

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

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

Транспорт

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

Разова поїздка тривалістю до півгодини коштує 24 крони (~1 євро), на півтори години — 36 крон (~1,5 євро). Я купив річний абонемент на всі види транспорту (навіть на паром і фунікулер) за 3 650 крон (~140 євро). Якщо їздиш двічі в день, одна поїздка виходить 7 крон (27 єврокопійок відповідно).

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

Є поїзди між країнами: на Варшаву, Берлін — європейська лінія досить активна. Але в основному всі їздять автобусами: FlixBus на багато напрямків. Я для закордонних подорожей беру машину в оренду, виходить 35-40євро в день (зі страховкою). Прага зручна для подорожей автомобілем: 8 годин до Італії, 3 до Берліна, 4 — до Вроцлава. З Польщі або з Німеччини вже можна летіти лоукостом.

Літати з Чехії незручно, є багато напрямів, але всі дорогі. Практично немає дешевих напрямів лоукостів, у Ryanair — достатньо напрямків, але дорогі, у Wizz Air раніше було 6-7,зараз залишилося 2 (Англія, Італія). Полетіти кудись лоукостером обійдеться від 60 до 100 євро. Є один лоукостер, який літає в Ейндховен (за 30 євро можна знайти квиток).

Вартість життя

Продукти тут у середньому на 20% дорожчі, ніж у тій же Польщі. Як на мене, вони гірші за якістю, і вибір менший. Є багато супермаркетів: Kaufland, Lidl, Albert Heijn, Billa — аналог нашого АТБ. Купівля продуктів і похід раз-двічі у тиждень до ресторану обійдеться приблизно в 10-12тисяч крон (390-470 євро)у місяць. 20 тисяч достатньо, щоб зняти однокімнатну квартиру і нормально харчуватися на двох людей (але не шикувати, а вибирати, що купуєш, і готувати вдома). Усе інше витрачаємо на подорожі.

Компанія надає працівникам мультиспорт картку, використовуємо я і моя дівчина. Коштує приблизно 1500 крон (58 євро) на місяць. З цією карткою можна безкоштовно відвідувати різні спортивні заклади: спортзали, басейни та інші.

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

Національна кухня

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

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

Весна у Празі

Висновки

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

Рік-два ще поживу тут, а там буде видно. Можливо, переїду кудись південніше: Іспанія, Італія, де сонце і гарний настрій. З іншого боку, поживши вже в трьох країнах, можу зробити висновок, що гарно там, де нас нема. У будь-якій країні є свої плюси і мінуси, головне — не втікати від себе, знати, хто ти є, і отримувати насолоду від будь-якої країни і її культури.

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

Дякуємо за участь у підготовці матеріалу Ярославі Тимощук.

Підписуйтеся на наш Telegram-канал про релокацію, щоб не пропустити цікаві вакансії, події, статті.

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

Всем привет! Меня зовут Андрей Кияновский, и я активный пользователь интернета с тех пор, когда он был еще по модему, а знакомство с владельцем BBS-борды считалось за привилегию. Свою первую серьезную программу я написал в школе на СМ-2М (это компьютер размером с комнату). Потом работал девелопером, системным администратором, бизнесменом, менеджером проектов и сейчас зарабатываю на жизнь как certified Atlassian administrator. Оглядываясь назад и сравнивая удовольствие от работы девелопером и головняк от работы менеджером, решил заняться проектом tabXpert — расширением для управления вкладками в браузере. Проект появился частично как ностальгия по программированию, а частично как попытка сделать работу таких же людей, как я, проводящих всю жизнь за компьютером, немного более эффективной.

Идея

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

На рынке уже существует несколько расширений для Chrome, пытающихся упростить жизнь активного интернет-пользователя, так или иначе сохраняя состояние вкладок и окон браузера. Просмотрев существующие предложения, такие как OneTab, Session Buddy, Tabs Outliner, я понял, что в этом «так или иначе» и есть основная загвоздка. Мой идеальный менеджер вкладок должен уметь:

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

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

Реализация

Скоро сказка сказывается, да не скоро дело делается. Я был очень наивным, полагая, что смогу осуществить этот проект за три-четыре месяца и $15-20К денег. Уже прошло полтора года и бюджет превышен многократно. Начинал я один, потом нашел частного инвестора, и теперь у нас есть еще один девелопер.

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

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

Синхронизация в реальном времени

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

Состояние окна с другого компьютера не получится просто «применить» в силу асинхронности событий, необходимо объединять изменения на уровне вкладок. Но как понять, с какого компьютера состояние вкладки более новое? Идея использовать время обновления вкладки сразу отпала, потому что при загрузке браузера вкладки сразу обновятся и изменения с удаленного компьютера не будут применены. Дабы не изобретать колесо, мы решили реализовать three-way merge, как сделано в Git. Перед перехватом управления над окном другого компьютера, состояние окна сохраняется как родительское (как ветка в Git). При сравнении двух разных «версий» одного окна легко определить какая вкладка изменилась, сравнивая ее состояние с родительским. В редких случаях конфликта открывается дополнительная вкладка, так что пользователь гарантированно ничего не теряет при синхронизации.

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

Для хранения данных на клиенте (Chrome под Windows, macOS и Linux) была выбрана база данных NoSQL PouchDB (хранилище на IndexedDB) — тонкий клиент для сервера на CouchDB, сильной стороной которой является синхронизация данных. База данных работает в Worker, чтобы не замедлять UI.

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

Устойчивость к перезапускам и падениям браузера

Для избежания появления дубликатов сохраненных окон после перезапуска браузера, tabXpert должен уметь сопоставлять окна между разными сессиями, когда включена опция Chrome, «запускать ранее открытые вкладки». Не существует простого способа сопоставить окна в разных сессиях — не сохраняется ни id вкладок, ни id окон. Решили считать хеш по URL вкладок и по его значению сопоставлять окна в разных сессиях. Так как запись в DB производится только в idle режиме (для оптимизации), мгновенное сохранение состояния окна, включая хеш вкладок, происходит в local storage, который достаточно быстрый и не сохраняет историю.

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

• вкладки могут не восстановиться, если они загружались в момент завершения работы браузера или при его падении;
• вкладки могут добавляться при старте и при восстановлении после падения браузера;
• chrome:// вкладки теряются, если открыть ранее нормальное окно в инкогнито-режиме.

Для решения этой проблемы tabXpert производит сопоставление окон старой и новой сессий, учитывая все возможные изменения. Для каждого окна вычисляется два вида хеша — постоянный для данных, сохраненных в DB, и мгновенный для текущего состояния, сохраненного в local storage. Также в local storage хранится два состояния окна — текущее и предыдущее, так как иногда Chrome успевает сохранить новое состояние в local storage, но восстанавливает при этом предыдущее состояние. Для окна, которое надо сопоставить после перезапуска браузера, хеш просчитывается для всех возможных вариантов изменений. В случае частичного сопоставления, tabXpert восстанавливает недостающие вкладки. Для синхронизации текущего и сохраненного окна используется тот же механизм, что и для сетевой синхронизации.

Интерфейс пользователя

При написании UI мы прошли через Angular, Vue и остановились на React. Angular оказался слишком тяжелым для относительно простого интерфейса. Vue не сильно распространен, и специалистов по нему я не нашел. В общем проблему выбора окончательно решило наличие опытного девелопера, который смог решить все вопросы с использованием React.

Клиентская часть расширения работает на связке React + Redux. За сборку проекта отвечает Webpack, а транспиляцией самых свежих конструкций JavaScript в рабочий код занимается Babel. Часть ошибок в коде превентивно ловим инструментом semistandard.

Каскадные таблицы стилей написаны на любимом многими SCSS, реализация тем оформления — на Styled Components. Из коробки доступны две цветовых схемы: светлая и темная.

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

Для реализации большинства элементов интерфейса используем библиотеку компонентов React Material UI. С решением проблемы медленного рендеринга больших списков нам помогла библиотека React List. Многоязычность реализована с помощью компоненты react-i18next.

Расширение имеет два режима работы: в обычной вкладке и в попапе, всплывающем при нажатии на иконку расширения на тулбаре Chrome или по горячей клавише. Для устранения постоянной подгрузки и моргания favicon (в DB хранятся только URL) мы реализовали кэширование и храним их памяти в виде data URL. Для поиска по вкладкам используем Elasticlunr.

Для ускорения скорости загрузки попапа мы используем server-side rendering, генерируя HTML-разметку для попапа в фоновой странице каждый раз при изменении данных активного окна. Благодаря этому экран попапа отображается практически мгновенно, после чего подгружается основной скрипт, который добавляет интерактивность.

Результат

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

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

tabXpert также поможет решить проблему нехватки памяти при большом количестве открытых вкладок. Уже существует достаточно популярное расширение The Great Suspender, которое автоматически замораживает неиспользуемые вкладки, выгружая их из памяти (и загружая, когда вы возвращаетесь на эту вкладку). tabXpert понимает, когда вкладка заморожена, и запоминает ее состояние. В следующий раз, когда вы открываете сохраненное окно, tabXpert загружает вкладки в том состоянии, в котором они были на момент закрытия окна. Таким образом, вы не только экономите память, но и время, так как окно с замороженными вкладками восстанавливается гораздо быстрее, чем в обычном режиме.

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

Следующий минутный проморолик показывает основную идею tabXpert в действии:

Также есть много других возможностей, таких как перетаскивание вкладок между окнами, разъединение и объединение окон, открытие нормального окна в инкогнито режиме и наоборот, тип секретности по умолчанию для инкогнито-окон, светлая и темная темы, быстрое отключение звука, экспорт и импорт, включая импорт из OneTab и Session Buddy. Есть также возможность быстро скопировать HTML-ссылку вкладки (название и URL одновременно) для того, чтобы вставить ее в письмо или документ, как например эта ссылка, по которой вы можете скачать tabXpert и попробовать его в действии: tabXpert — Chrome Web Store.

В ближайших планах у нас:

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

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

А что было бы интересно вам? Пишите в комментариях ваши впечатления. Буду рад ответить на любые вопросы.

Меня зовут Виталий Марусяк, я Project Manager в компании Provectus. В IT-сфере работаю уже 11 лет, и это всегда была full-time занятость в офисе. Путешествия составляют важную часть моей жизни. За время работы мне удалось посетить более 60 стран, некоторые по несколько раз.

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

В кабине борта FlyDubai

Work-travel balance

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

Наверное, это самый жизнеспособный вариант, так как компания предоставляет 20 дней отпуска, и я как раз вкладываюсь в это количество. В совокупности с праздниками и выходными днями выходит примерно 35 travel-дней в году. Это немного, поэтому, если вы хотите увидеть максимум, придется ограничить отдых в поездках до 1-2часов поздно вечером перед сном, а также научиться использовать бесценное время поездки максимально эффективно.

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

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

Инструменты и лайфхаки

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

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

1. Общее планирование поездки

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

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

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

2. Визы

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

3. Перелеты

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

Поиск

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

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

Если у вас один город прилета-вылета, где вы собираетесь провести все ночи, а также необходим автомобиль, я бы рекомендовал expedia.com — у них часто бывают хорошие комплексные предложения.

Покупка

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

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

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

4. Стыковки, лоукосты и возможность посидеть в кресле пилота

При длительной стыковке некоторые топовые авиакомпании, например, Emirates, предлагают бесплатный отель с трансфером. В аэропорту на стыковке нужно подойти к стойке hotel-desk, показать свой boarding pass, и вам предоставят эту услугу. Кроме этого, есть множество плюшек, специфических для разных авиакомпаний. Например, Turkish Airlines предоставляет своим пассажирам бесплатную экскурсию по Стамбулу во время стыковки.

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

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

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

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

5. Бронирование отелей

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

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

Я пользуюсь сервисом booking.com, у него самая обширная база гостиниц и хостелов по всему миру, а еще очень приятная программа поощрения частых путешественников. Кроме того, у Mastercard есть постоянная акция — 5% кэшбэк за бронирование на booking.com, зарегистрироваться можно здесь.

Для поиска отелей в Азии я бы посоветовал agoda.com. Этот сервис составляет хорошую конкуренцию booking.comв этой части света.

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

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

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

Обязательно в комментариях к бронировке по максимуму пишите свои пожелания. Я обычно прошу при возможности предоставить категорию номера выше, более высокий этаж и бесплатный завтрак (если он не входит в стоимость). В случаях, когда преобладающий поток клиентов в отеле приходит из онлайна, администрация легко идет на уступки за хороший отзыв. Например, в Баку нам дали номер категории Junior Suite вместо оплаченного стандарта, а в Бразилии, в Фос-де-Игуасу, предоставили бесплатный трансфер в аэропорт. Такого рода кейсы, конечно, не частые, но скопировать заранее подготовленный текстовый шаблон в поле «Comments» во время бронирования вам ничего не стоит, а внезапно получить нечто превышающие ваши ожидания в поездке всегда приятно.

6. Аренда автомобиля и навигация

Для бронирования машин я всегда использую метапоисковики, так как это, в большинстве случаев, на порядок дешевле прямого бронирования на сайтах провайдеров. В отличие от перелетов, оба процесса — и поиска, и покупки — происходят прямо на сайте метапоисковика. Обычно я выбираю holidayautos.com, они ни разу меня не подводили. Лучше выбирать из числа известных провайдеров, таких как Sixt, Hertz, Avis, Budget, Enterprise. У них есть стойки в аэропорту, онлайн-чат и другие полезные услуги.

Если по какой-то причине по прилету у провайдера не окажется забронированного вами автомобиля, компания обязана предоставить вам машину такого же класса либо выше. Я рекомендую в таких ситуациях требовать машину классом выше, ссылаясь на то, что очень хотели именно ту, которую бронировали, и вам нужна компенсация. То же самое касается ситуаций, когда со стороны провайдера были и другие огрехи в сервисе, например, по прилету на стойке не было сотрудника и вам пришлось долго его ждать и т. д. Обычно работники хороших компаний-провайдеров без проблем выдают машины классом выше забронированного при их наличии. Например, в Лиссабоне нам выдали новый Mercedes C вместо оплаченной по $18 в сутки малолитражки Volkswagen Up.

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

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

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

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

Всегда полезно иметь запасной вариант, поэтому скачайте на телефон 2-3навигационных приложения. Я отдаю предпочтение Maps.me. Оно бесплатное, работает офлайн, позволяет скачать отдельную страну или регион. Эти карты очень помогли мне в иранском городе Йезд, где часть старого города состоит из глинобитных сооружений, на которых нет номеров. В Maps.me была доступна вся сетка этих закоулков, благодаря чему я легко нашел правильную дорогу.

Нетривиальные случаи и troubleshooting

Как-то раз в Испании, находясь на вершине горы Монсеррат, я обнаружил, что в кармане нет кошелька. Как я понял позднее, его вытащил карманник в электричке. Билеты назад до Барселоны были в другом кармане. Тут повезло, но от Барселоны нужно было как-то преодолеть без денег 90 километров до Тоссы-де-Мар, где в отеле находились вещи, резервные деньги и документы. Сейчас бы эта проблема решилась за 3 минуты звонком домой родственнику или другу, который перевел бы нужную сумму на карту через Приват24. Но дело было 8 лет назад, карты в поездки тогда я с собой еще не брал, только кэш. Western Union тоже не вариант, так как паспорт был в отеле, без него денег не снять. Пришлось искать помощи среди местных жителей. Каталонцы с английским не особо дружат, поэтому у меня ушло целых 4 часа, чтобы найти на барселонском автовокзале Nord доброго человека, готового одолжить деньги на билет. В конце концов индус, продавец в сувенирном магазине, выдал мне долгожданные 26 евро под залог моих часов. На следующий день, по дороге в Андорру, я завез индусу долг и получил назад свои часы, которые ношу до сих пор :)

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

К этому выводу, я, конечно, пришел позже. Ситуация выглядела так: автобус остановился посреди дороги (на высоте почти 4000 метров над уровнем моря), ко мне подошел водитель, разбудил и жестами показал, что пора выходить, вроде как приехали. Я, сонный, вышел с чемоданом из автобуса, после чего он сразу же уехал. Была ночь, кромешная тьма, температура 0 градусов и никакого намека на то, что рядом есть хоть какой-нибудь город. После длительных попыток остановить редкие в тех краях машины, все-таки получилось за неприлично большую сумму договориться с одним водителем довезти меня до боливийской границы. Водитель был очень удивлен, когда я достал оговоренные для расчета деньги из кроссовок :) Ну а что делать, места небезопасные, нужно соблюдать меры предосторожности. Граница оказалась закрыта... Через несколько часов ее открыли, я получил визу и испытал то чувство, когда переходишь границу между двумя государствами в одиночестве и пешком :) После чего уже без проблем нашел боливийского таксиста и доехал до заветной Копакабаны.

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

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

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

Выводы

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

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

И для этого не нужно увольняться с работы. Проверено на себе!

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

Поколение миллениалов

Теория поколений сохраняет популярность с начала 1990-хгодов. Первая же книгаее авторов У. Штрауса и Н. Хоува произвела неизгладимое впечатление на маркетологов, бизнесменов и политиков. Теория описывает особенности общества, характерные для определенных исторических циклов, и пересказывает историю, сначала США, а потом и других стран, как набор биографий целых поколений людей. Всех, кто родился с 1981 по 1995 год, называют миллениалами или поколением Y. Уверен, именно к нему относятся многие читатели этой статьи.

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

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

Counter Strike 1.6

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

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

Поэтому одиночная игра часто оставалась для геймеров начала 2000-хосновным режимом Counter Strike, а боты — их единственными оппонентами. Алгоритмы ИИ того времени еще не были такими сложными, поэтому со временем игрок привыкал к тактике компьютера и даже на самом высоком уровне сложности играть становилось не так интересно. Это даже побудило сообщество на создание плагинов и модов (POD-bot, Z-bot, RealBot), совершенствующих стиль игры ботов. Несмотря на это, продолжительная игра вне сети не позволяла стать экспертом Counter Strike.

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

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

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

Cossacks

В начале 2000-хзапустились многие игровые серии, а жанр Real Time Strategy (RTS) занял особое место. Сердца многих игроков на постсоветском пространстве тогда завоевала игра Cossacks. Во всяком случае ее первая часть с последующими дополнениями. Сеттинг мира давал возможность почувствовать себя полководцем любого из наиболее многочисленных народов средневековой Европы. До сих пор тяжело определить причины успеха этой игры на фоне других представителей жанра. Возможно, секрет состоял в колоссальном масштабе сражений. Цель почти каждой миссии сводилась именно к военной победе, которая определялась превосходством вашего войска. Развитие поселения, модификация юнитов, вариативность и масштаб построек оставались вторичными.

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

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

Вспомните, какие игры вашего детства запомнились лучше остальных? Ставлю на те, которые было очень трудно пройти с первого раза. Battletoads до сих пор на пике популярности, несмотря на ненавистный уровень (помните его?). Теперь задайте себе вопрос, есть ли трудности в вашей карьере сейчас? Есть? Хорошо. Это один из важнейших признаков развития.Если вам слишком комфортно в вашем проекте, вы не испытываете особенных трудностей, решая проектные задачи, и тратите на это меньше времени, чем планировалось, скорее всего, развитие вашей карьеры замедлилось.

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

Neighbors from Hell

Один из первых представителей смешанного жанра — «аркадный стелс», аналогов которому было крайне мало. Графика, декорации и сама идея показались большинству игроков очень интересными. Да, эту игру вряд ли бы кто-то назвал лучшей в любой из существующих сейчас номинаций. Зато ее простой, но не слишком грубый юмор и непредсказуемость сюжета пришлись по душе многим. А поскольку играли в нее обычно дома — сейчас она способна вызывать особенную ностальгию. Главной фишкой этой аркады была вариативность. Ты никогда не знал наперед, что найдешь в закромах квартиры соседа и как тебе удастся применить этот предмет. Более того, находки можно было использовать по-разному — например, бусы рассыпать на полу в комнате или ванной. Если предварительно наполнить ванну и положить туда фен, сосед, поскользнувшись, запросто угодит в еще одну ловушку. Для тех, кто в Neighbours from Hell не играл, такой сценарий может прозвучать жутковато. Но игра точно не страшнее классических мультфильмов вроде «Тома и Джерри» или «Ну, погоди!».

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

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

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

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

SimCity 4

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

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

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

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

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

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

Warcraft III

Третья часть игры увидела свет в 2002 году — к этому моменту серия уже приобрела статус культовой. Мир игры настолько вырос, что стал местом развития сотен сюжетов, жительства несметного числа уникальных персонажей, взаимодействия массы игровых механик. На его основе позже появились и несколько самостоятельных игр. Warcraft III — еще один яркий представитель жанра стратегий в реальном времени (RTS). Не меньше удовольствия, чем сама игра, доставляет наблюдение за ее издателем. Бывалый игрок знает, что есть Blizzard, а есть остальной игровой мир. Эта компания создала неповторимое сообщество фанатов — важно помнить, что она же выпускает и куда более популярный StarCraft. При этом Blizzard каждый раз выпускает продукт, не хуже предыдущего.

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

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

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

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

Выводы

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

Від редакції: у рубриці DOU Booksспеціалісти розповідають про 5 своїх улюблених книжок — ті, які змінюють світогляд та корисні читачам-колегам.

[Олег Фаренюк — викладач факультету прикладних наук УКУ, консультант компанії EdPro, провідний інженер Інституту фізики конденсованих систем НАН України]

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

Тому я вирішив запропонувати вашій увазі п’ять книг, які дозволять розібратися у роботі комп’ютера.

Andrew Tanenbaum, Herbert Bos «Modern Operating Systems»

У російському перекладі — Эндрю Таненбаум «Современные операционные системы»

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

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

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

Детальніший відгук на неї писав у своєму блозі: «Розповіді про операційні системи від Таненбаума».

David Patterson, John Hennessy «Computer Organization and Design: The Hardware/Software Interface», 4th Edition

У російському перекладі — Дэвид Паттерсон, Джон Хеннесси «Архитектура компьютера и проектирование компьютерных систем. Классика Computers Science»

Операційна система працює поверх «заліза». Апаратура комп’ютера багатоманітна, однак одним із найважливіших та, певне, найскладнішим компонентом є центральний процесор, CPU. Звичайно, їх розробники знають, що далеко не всі користувачі будуть просунутими — сяк-так процесор опрацьовуватиме будь-яку програму. Однак, щоб використовувати його ефективно та безпечно (згадайте хоча б недавні баги Meltdown I Spectre!), краще розуміти, як процесори влаштовані і на які трюки йдуть для підвищення ефективності.

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

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

Існує також більш ґрунтовна їхня книга, розрахована на професійнішого читача: John Hennessy, David Patterson «Computer Architecture: A Quantitative Approach».

David Harris, Sarah Harris «Digital Design and Computer Architecture»

У російському перекладі — Дэвид М. Харрис, Сара Л. Харрис «Цифровая схемотехника и архитектура компьютера»

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

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

Noam Nisan, Shimon Schocken «The Elements of Computing Systems: Building a Modern Computer from First Principles»

При всіх перевагах книги Паттерсона-Хеннесі та Харрісів — достатньо складні. Вони, безумовно, корисні людям, які тісно працюють із мікропроцесорами або планують їх проектувати, але для любителя, який просто хоче розібратися та створити свій аматорський комп’ютер, доступнішою буде ця книга, написана авторами для свого курсу «From Nand to Tetris».

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

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

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

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

Преимущества автоматизации тестирования

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

Уровни тестирования

Существует несколько уровней тестирования:

• Unit tests;
• Integration tests;
• GUI tests;
• Manual tests.

Unit и Integration tests оставим разработчикам, с Manual тестами все понятно. Давайте остановимся более подробно на GUI-автоматизации, набирающей популярность огромными темпами.

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

Место автоматизации GUI в процессе разработки

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

Инструменты для автоматизации GUI

Путем проб и ошибок мы в Ukad пришли к следующему инструментарию для GUI автоматизации:

• Java — как язык для написания тест-скриптов.
• Maven — для сборки проекта.
• Selenide — как фреймворк для написания GUI тестов.
• TestNG — как фреймворк для управления запуском тестов.
• Selenoid — для непосредственного управления сессиями браузера.
• Allure — для создания и эффектной презентации отчета.
• Jenkins — для непрерывной интеграции тестов в процесс разработки.

Более подробно об инструментах и причинах, почему мы выбрали именно этот набор:

• Java.Мы используем Java, так как это путь наименьшего сопротивления ведь сообщество просто огромно, что дает доступ к большому количеству готовых решений для тестирования и не только. Это в свою очередь позволяет не тратить много времени на исследование и решение часто возникающих проблем, так как очень велика вероятность того, что решение уже найдено.
• Maven.Можно использовать любой другой сборщик. Для автотестов это не принципиально, но лично мне Maven ближе.
• Selenideпозволяет не изобретать свой велосипед для решения стандартных проблем Selenium (таких как ожидания и поиск элементов на странице, добавление «мягких» проверок и т. д.) и значительно повысить скорость разработки и стабильность тестов.
• TestNG. Мы перешли с Junit на TestNG для использования наборов на основе .xml файлов, а также возможности объединения тестов в группы.
• Selenoid.Мы используем Selenoid вместо Selenium Hub, так как он более стабилен и позволяет запускать сессии браузеров в Docker контейнерах, плюс добавляет такие приятные бонусы, как просмотр выполнения конкретного теста и запись видео его прохождения.
• Allure.Позволяет значительно расширить возможности стандартного TestNG отчета, эффектно и удобно презентовать всю информацию о пройденных сценариях. В репорте каждый член команды сможет найти для себя полезную информацию. Начиная от времени и количества пройденных сценариев с результатами прохождения, до прикрепленного видео прохождения и скриншотами для упавших тестов.
• Jenkins.Мы используем Jenkins для сборки некоторых своих проектов, поэтому мы решили использовать его же для сборки тестов. Также с Jenkins удобно интегрировать Allure репорты при помощи дополнительного плагина.

Пример использования GUI автоматизации

Создаем проект с тестами

Рассмотрим, как используется GUI автоматизация на примере простого теста. Для этого создадим Maven-проект и подключим необходимые зависимости для Selenide, TestNG и Allure. Добавим простой тест, который будет открывать главную страницу сайтаи проверять, что футер отображается. Для написания теста используется PageObject паттерн. Для управлением драйверами браузера используется WebDriverManager.

Актуальный pom.xml и исходный код проекта доступен по ссылке.

Проект может быть запущен командой "mvn test" (Maven должен быть установлен и добавлен к системным переменным). Все работает, но тест будет запущен в локальном браузере, а нам необходимо запускать на тестовом стенде. Самые популярные варианты удаленного запуска тестов — Selenium hub и Selenoid. Остановимся подробнее на Selenoid.

Selenoid

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

Снова запустим наш проект командой “mvn test”.

Тест работает. Но что если мы хотим видеть выполнение теста? Для этого достаточно добавить дополнительный параметр в создание браузера и использовать Selenoid контейнеры с поддержкой VNC, например “selenoid/vnc:chrome_66.0”для 66 версии Chrome. Также нужно добавить дополнительную Capability к созданию браузера “browser.setCapability("enableVNC", true);”.

Вот так выглядит browser.json после обновления. Для простоты я оставил только Chrome 66 версии.

Также добавим дополнительную Capability к созданию драйвера “browser.setCapability("enableVNC", true);”.

Запустим наш тест еще раз и перейдем на вкладку «Session». Теперь мы можем следить за выполнением теста.

Но для эффективного использования автотестов необходима непрерывная интеграция с процессом разработки. Для этого мы используем Jenkins.

Jenkins CI

Jenkins — проект для непрерывной интеграции с открытым исходным кодом, написанный на Java. Используется для сборки и поставки программного обеспечения. У нас есть возможность использовать Jenkins для запуска тестов для каждой новой сборки тестируемого продукта. Для создания тестовой сборки нам необходимо установить дополнительные плагины:

• Maven Integration — для более удобной интеграции с Maven.
• Allure Jenkins Plugin — для генерации и отображения отчета.

Создадим новую Jenkins job с типом «Maven project».

Добавим наш репозиторий с тестами в секцию «Source Code Management».

Для генерации Allure отчета добавим «Post-build Actions» -> «Allure report».

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

А вот и Allure отчет.

Финальная стадия интеграции — связываем нашу тестовую сборку со сборкой нашего тестируемого приложения путем добавления в «Build Triggers» — > «Project to watch».

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

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

• официальная документация Selenide;
• официальная документация TestNG;
• официальная страница Maven;
• официальная документация Selenoid;
• официальная документация Allure;
• официальная документация Jenkins;
• Иван Крутов «Selenoid: запускаем Selenium тесты в Docker контейнерах» — обзорный доклад о Selenoid от одного из разработчиков;
• Allure 2: new gen test report tool — обзорный доклад по Allure 2 от разработчика.

Вывод

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

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

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

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

Тестирование и требования

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

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

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

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

Первый класс — это функциональные требования. Они предусматривают, как должна работать система. Хороший пример функциональных требований — описание того, что при нажатии на кнопку «Submit» должна появляться надпись «Ok». Это требование говорит, что должна делать система. Однако в таких требованиях ничего не сказано про то, как, скажем, быстро должна появиться эта надпись. Поэтому появился второй класс — нефункциональные требования. Они говорят, как это должна делать система.Если приходит требование, что запись должна появляться не менее чем за 1 секунду — это типичное нефункциональное требование. К нефункциональным относится все, что касается юзабилити, производительности, дизайна и т. д.

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

Типы автотестов

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

Мы будем сравнивать автотесты по следующим параметрам:

• парадигма, исповедуемая тестами Black Box / White Box / Grey box тестирование;
• скорость прохождения сферического единичного теста в вакууме;
• затраты на разработку;
• зависимость от среды исполнения.

Итак, автотесты делятся на следующие типы: Unit, Integration, End-To-End.

Unit

Это тесты, проверяющие public-интерфейсы отдельно взятого модуля. Они исповедуют концепцию white box testing, при которой человеку, который тестирует систему, доступен весь ее исходный код. Сразу оговорюсь, white box в некоторых случаях превращается в полноценный black box из-за того, что иногда модули рассматриваются именно как черные ящики с входящими и исходящими данными.

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

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

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

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

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

Integration

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

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

Разработка этого вида тестов уже не занимает столько времени, как нужно для Unit`ов. Однако эти тесты более хрупкие, потому что большое количество факторов влияет на их работу. Их прохождение занимает больше времени, нежели у юнит-тестов за счет взаимодействия с третьесторонними API. Теперь уже разработчик не может запускать эти тесты после каждого сохранения, потому как такой тест длится порядка нескольких секунд.

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

End-To-End

Это тесты, проверяющие всю функциональность в целом. Такой вид тестов использует концепцию черного ящика, при которой приложение представляет собой неведомую вещь, с которой мы взаимодействуем посредством публичных интерфейсов. Почему-то всегда Е2Е-тесты ассоциируются у большинства разработчиков с Selenium, хотя тестирование REST API средствами http-запросов — также типичный образец Е2Е-тестов, которые полностью укладываются в концепт черного ящика.

Е2Е-тесты проверяют работоспособность системы в целом. Прогон занимает достаточно много времени, поэтому их не гоняют локально. Я бы даже не рекомендовал запускать их после каждого пуша в центральный репозиторий. Тесты идеальны для запуска после слияний веток или относительно окружений sandbox или staging — для того, чтобы контролировать состояние приложения в ветках и на окружениях. Также при использовании микросервисной архитектуры приложения тесты могут покрывать сразу несколько микросервисов, что приведет к лучшему покрытию кода тестами.

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

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

Покрытие кода тестами

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

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

Существуют такие метрики покрытия кода тестами:

• По линиям.Описано выше.
• По классам или методам. Класс или метод считается покрытым, если он хотя бы раз был вызван тестами. Эту метрику любят менеджеры, потому что обычно она показывает самые впечатляющие результаты.
• По логическим веткам.Ветка считается покрытой, если в нее хоть раз заходил тест. То есть если у вас есть if с else — и тест попал только в одну из его логических ветвей, то покрытие такого кода будет равняться 50%. Эта метрика очень удобна для оценки того, насколько детально вы просчитали все варианты развития событий в ваших тестах. Имейте в виду, что ветками считаются if-else, switch-case, try-catch. Тернарники не считаются элементами, разветвляющими код.
• По выражениям. Выражение считается покрытым, если оно выполнялось хоть раз при проходе тестом. Вот тут и считаются тернарники, так как они идут на одном уровне с обычными операторами.

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

DevOps и стратегия тестирования

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

DevOps-культура предлагает свести к минимуму ручную QA-работу, дабы иметь возможность релизиться как можно чаще, что безопаснее и стабильнее. В DevOps-культуре роль QA-инженеров смещается от тестеров к людям, которые следят за качеством проекта и помогают разработчикам в написании автоматических тестов, вырабатывают стратегию тестирования. Тут уже мало места для QA, которые не разбираются в технологических аспектах приложения, CI/CD процессах.

Стратегия тестирования — это план, который позволит вам работать с минимальной затратой времени, а следовательно, и денег. Стратегия тестирования для DevOps не должна звучать: «Мы используем Protractor и Jenkins». Это не план. Это всего лишь перечисление инструментов, которые используются вами. Главное вопросы, на которые должен отвечать план, — почему и зачем.

Мы должны ответить себе на следующие вопросы:

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

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

При пуше кода в фича бранч должны прогоняться сьюты integration- и unit-тестов. Они определяют статус билда и возможность смерджить его в главную dev-ветку. При поломанном билде не должно быть возможности мерджа, а коммитер должен быть оповещен, что его коммит сломал ветку. Далее идет мердж в master или stage brunch и сборка там. При этом требуется прогонять все тестовые наборы, включая E2E.

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

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

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

Выводы

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

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

Вітаю! Мене звати Володимир Воробйов, я CEO компанії RubyGarage і автор щомісячного Ruby/Rails дайджесту на DOU. Цією статтею хочу розпочати серію матеріалів про Ruby.

Я сам колись займався програмуванням і обрав цю мову. І, як можете судити з назви компанії, команда RubyGarage у своїй роботі здебільшого спирається на технології Ruby. Але чому ми й сотні команд у всьому світі обрали саме Ruby? А також які можливості пропонують Ruby-розробникам українські компанії, де вивчати Ruby й Rails початківцям та шукати натхнення зрілим і досвідченим розробникам і, зрештою, які roadmaps й прогнози розвитку Ruby — про все це поговоримо в статті.

Ruby

Ruby у світі

Перша стабільна версія мови Ruby з’явилася понад 20 років тому в 1996-му.Незважаючи на виникнення й розквіт нових мов і серйозну конкуренцію (зокрема з боку PHP, Go, Python, Scala), Ruby не втрачає своєї актуальності. Це підтверджують самі розробники в усьому світі.

У дослідженні HackerRank 2018 року, у якому взяли участь близько 40 тис. розробників, ідеться про технології, яким розробники віддають перевагу та які планують вивчати в майбутньому. За результатами дослідження, Ruby посідає 5-темісце серед 23 найцікавіших для програмістів мов.

Джерело: HackerRank

Актуальність Ruby підтверджують і результати інших опитувань: згідно з рейтингом RedMonkта індексом TIOBE, Ruby входить до 15 найпопулярніших мов програмування. Також про неослабний інтерес до Ruby з боку ІТ-спільноти свідчить і статистика Stack Overflow, у рейтингу якої мова Ruby посіла 13-темісце, та GitHub, де 2017 року Ruby увійшла до п’ятірки мов, що мають найбільшу кількість pull requests.

Джерело: GitHub, RedMonk, TIOBE

Джерело: Stack Overflow

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

Світ Ruby

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

У 2018-муйого послідовники й прихильники Ruby поділяють натхнення від роботи з цією технологією:

Andy Croll, доповідач на конференції GORUCOу Нью-Йорку, червень 2018

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

Нижче — детальніше про ключові принципи культури, на які спирається світова Ruby-спільнота.

Принцип 1: Ruby створено для розробників

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

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

Розгляньмо приклад.

Прочитайте вголос ось такий вираз:

5.times { print "Odelay!" }

В англійській мові пунктуація в реченнях (крапка в кінці, знак оклику, дужки) свідчить про паузу. Пунктуація додає значення словам, допомагає зрозуміти, про що саме автор намагається сказати в конкретному реченні. Тож, якщо прочитати наведений вище вираз саме як речення, вийде: «Five times print „Odelay!“» (дослівно: «П’ять разів надрукуй „Odelay!“»).

Цей вираз означає буквально те, що виконує ця невеличка Ruby-програма: на моніторі п’ять разів буде надруковано вигук «Odelay!» змішаною іспанською мовою.

Ще один приклад. Прочитайте також цей вираз:

exit unless "restaurant".include? "Aura"

За допомогою цієї програми ми перевіряємо реальність фактів. Програма здійснює команду exit (завершиться), якщо тільки слово «restaurant» не міститить в собі іншого слова «aura». Знову, якщо прочитати вираз як звичайне речення, вийде: «Exit unless the word „restaurant“ includes the word „aura“» (дослівно: «Заверши програму, якщо тільки слово „restaurant“ не містить у собі слова „aura“»).

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

Об’єктно-орієнтоване програмування

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

Динамічна типізація

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

Метапрограмування

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

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

Інструменти, як-от Chef і Puppet, пропонують просту мову для конфігурування серверів. Це, власне, і є приклад DSL — мови, створеної за допомогою Ruby задля того, щоб спрощувати життя DevOps-фахівцям.

Розгляньмо елегантність DSL на прикладі самого коду Ruby, зокрема на виведенні CSV-даних:

csv_string = CsvShaper.encode do |csv|
  csv.headers :name, :age, :gender, :pet_names

  csv.rows @users do |csv, user|
    csv.cells :name, :age, :gender

    if user.pets.any?
      csv.cell :pet_names
    end
  end
end

Принцип 2: Якість коду — понад усе

Якість коду значною мірою залежить від дотримання єдиних стандартів і кращих практик. В екосистемі Ruby норми й стандарти написання та структурування коду затверджено світовою спільнотою розробників і зафіксовано в Ruby style guide і, відповідно, Rails style guide.

Прекрасний приклад ефективної стандартизації в Ruby — механізм створення бібліотек, або інструментів, які називають гемами (gems). Усі бібліотеки Ruby мають однакову структуру і зберігаються в єдиному репозиторії — Ruby Gems. Це зумовлює швидкість одержання потрібних бібліотек і можливість легко орієнтуватись у нових інструментах.

Екосистема Ruby пропонує повноцінний toolkit для тестування: Ruby-спільнота створила безліч фреймворків та інструментів, зокрема для здійснення автотестування. Серед них фреймворки (RSpec, Capybara та Cucumber) і бібліотеки (Minitest), що підтримують підхід BDD та є зручними для написання різних типів тестів; численні інструменти для створення тестових даних (Factory_bot, WebMock); веб-драйвери, що дозволяють писати й здійснювати автотестування (Selenium WebDriver, Watir) та інші інструменти (детальніше — далі в цій статті в розділі «Інструменти»).

Крім того, Ruby приділяє багато уваги перевірці, наскільки код відповідає нормам і стандартам. Наприклад, в екосистемі цієї мови чимало інструментів, що дозволяють здійснювати автоматичне code review, виявляти code smells та потенційно вразливі частини коду (RuboCop, SimpleCov, RubyCritic, Rails_best_practices), а також дотримуватись якості завдяки підходу Continuous Integration (Travis CI).

Приділяючи значну увагу якості, і розробники, і (що не менш важливо) бізнес та product owners одержують чимало переваг. Ось лише деякі з них:

• Програмування без багів: чистий код забезпечує рівномірну та стабільну продуктивність і, як наслідок, зумовлює чудовий користувацький досвід.
• Простота в підтримці: завдяки інтуїтивності Ruby-розробники легко розуміють, як саме працюють застосунки, і швидко орієнтуються в новому для них коді й проекті.
• Можливість швидко додавати новий функціонал: наявність чітких єдиних стандартів щодо імплементації змін дозволяє дотримуватись високої якості коду.
• Можливість масштабувати процес розробки й кількість людей у команді: стандарти, яких дотримується спільнота Ruby, поширюються й на організаційні процеси, зокрема зумовлюють швидкий і зрозумілий процес онбордингу нових розробників та гнучкість у масштабуванні кількості людей у команді залежно від обсягу роботи.
• Простий дебагінг: чудовий toolkit для написання автотестів (зокрема інструменти Pry, Pry-byebug, awesome_print), практика code review.

Принцип 3: Жива культура Ruby

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

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

Упевнений, що вам знайомі найпопулярніші з щорічних Ruby-конференцій:

• RubyKaigi — головна конференція в Японії, батьківщині Ruby;
• RubyConf — конференція, що об’єднує видатних ентузіастів з усього Ruby-світу;
• EuRuKo — щорічна європейська конференція, де учасники можуть дізнатися про останні оновлення у світі Ruby.

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

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

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

Принцип 4: Постійна підтримка з боку спільноти

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

Чудовий приклад — Ruby on Rails, найпопулярніший і найвідоміший фреймворк Ruby, за допомогою якого з’явилися й досягли успіху тисячі проектів. Ruby on Rails спирається на угоду писати менше коду й уникати повторів. Цей фреймворк існує у форматі open source — відкритого й безкоштовного ПЗ для використання навіть з комерційною метою.

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

Rails — не єдиний фреймворк Ruby, але він найпопулярніший, а отже, вартий окремої уваги.

Ruby on Rails

Ruby on Rails несправедливо називають застарілим і повільним фреймворком. Ясна річ, я не погоджуюся з такою думкою і маю відповідні аргументи. Оновлені версії Rails, зокрема з 5-ї,підтримують сучасний фронтенд і пропонують надійний швидкий інструментарій, працювати з яким зручно й приємно.

Продукти та платформи на Rails

Згідно зі статистикою Built With, існує понад 1 млн веб-платформ, побудованих на Ruby on Rails. Напевно, вам траплялися в мережі статті про найвідоміші з них:

А ось яку саме цінність, на думку засновників цих бізнесів, вносить у їхні проекти Ruby on Rails:

Twitter

Shopify

GitHub

Airbnb

SoundCloud

Rails — чудове рішення для стартапів

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

• Швидка розробка. Ruby on Rails має безліч готових плагінів і модулів, використання яких прискорює процес розробки приблизно до 30-40%,з мого досвіду. Подібно до Ruby, у Rails також існує угода щодо стандартів програмування: код має залишатися структурованим і зрозумілим для читання та підтримки. Архітектурні шаблони, зокрема MVC (Model—view—controller), — ще один чинник, що прискорює розробку. Щоб продукувати більш зрозумілий та готовий до кращого масштабування код, у Rails є можливість створювати додаткові шари абстракцій.
• Економічна доступність.Швидший процес розробки дає змогу зменшити відповідні витрати. Але є й інші чинники, що сприяють заощадженню. Rails — відкритий фреймворк, за який не потрібно платити. Крім того, спільнота Rails пропонує приголомшливу колекцію вільних для використання гемів (бібліотек, що містять вирішення для будь-якої потреби — від авторизації користувача до плати за послуги й товари). І, нарешті, завдяки кращим практикам програмування, на які спирається Rails, розробники продукують код найвищої якості, а отже, витрачають менше часу на його тестування і, зрештою, на загальний процес розробки.
• Безкомпромісна якість. Ruby on Rails приділяє значну увагу автотестуванню, а також спирається на підходи, за допомогою яких досягають якості, консистентності та структурованості коду, — це KISS (коротше і простіше), DRY (не повторюй себе) та інші патерни.
• Масштабування. У Rails чудовий потенціал, що дозволяє закласти надійний фундамент в архітектуру продукту для його подальшого масштабування. Зрозуміло, що масштабування не є привілеєм якогось одного окремого фреймворку, утім модульність Ruby on Rails додає йому балів у цьому контексті.
• Підтримка. Поки що Rails — найпопулярніший фреймворк екосистеми Ruby. Наразі кількість контриб’юторів, що зробили свій внесок у розвиток і поліпшення фреймворку Rails, сягнула 5 тисяч.

Як щодо Rails для Enterprise?

Ruby on Rails виник як фреймворк саме для стартапів. Але з часом команда Rails осягнула ключові бізнес-потреби, притаманні також і великим компаніям, та зосередилася на них:

• Надійність.Щонайменше впродовж останнього десятиріччя Rails довів свою надійність і продемонстрував усі можливості для послідовного масштабування будь-якого продукту. Тож цілком справедливо визначати цей фреймворк як надійну основу для більшості найуспішніших платформ різного масштабу — від стартапів і зростаючих компаній до великих enterprise-підприємств.
• Продуктивність.Рівень продуктивності (зокрема швидкість, ефективність і кількість ресурсів ПЗ, що витрачаються) Ruby on Rails для enterprise — цілком достатній. Насправді це не велика новина: Rails демонструє досить високу продуктивність ще з часів 1.9 версії Ruby та Rails 3 і продовжує розвиватися й пропонувати щодалі вищі показники.
• Інтеграції. Завдяки зусиллям Rails-спільноти й активності IT-лідерів (зокрема Apple та Microsoft) інтеграція різноманітного enterprise ПЗ на базі Ruby/Rails відбувається набагато швидше й ефективніше, ніж, наприклад, 5-7років тому. Крім того, Ruby може інтегруватись й ефективно співіснувати з Java, .NET та іншими платформами.
• Digital transformation. Rails цілком придатний для розв’язання актуального нині питання диджиталізації enterprise-компаній. Він пропонує готові «рішення з коробки» буквально для будь-якої потреби великого бізнесу: від автоматизації операційних процесів до поліпшення обробки користувацьких замовлень і налагодження процесів керування працівниками, фінансовими ресурсами й усіма типами даних, які збирає та обробляє компанія.

За допомогою Ruby/Rails можна швидко «зібрати» й кастомізувати безліч вирішень:

• ERP-системи — Compass;
• CRM-системи — Fat Free CRM;
• управління проектами — Redmine,GitLab,OpenProject,Hours, Travis CI;
• дискусійна платформа — Discourse;
• керування фінансами — Open Source Billing;
• платформи електронної комерції — Spree,Solidus,Sharetribe;
• керування контентом — Refinery CMS, Locomotive CMS;
• і ще безліч готових open source Rails-рішень та Ruby-гемів.

ТОП-десятка компаній Ruby on Rails

За версією ClutchТОП-десятка (з майже 200) IT-компаній, які розробляють проекти на Ruby on Rails, виглядає так:

Слід зауважити, що, на відміну від класичних аутсорсерів, у Ruby/Rails-компаніях переважає культура «бутиковості» (boutique). Вони зосереджуються на вирішенні конкретних завдань замовників і працюють з продуктом клієнта як з власним. Культура Ruby/Rails-компаній — від розроблення до технічного вузькоспеціалізованого консалтингу — ґрунтується на сервісно-орієнтованому підході.

Ruby/Rails і тенденції українського IT-ринку

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

Звісно, на кожному ринку (Нідерланди, Велика Британія, Австралія тощо) попит на певні технології різний. Утім, наведу тенденції ринку США, які здаються мені цікавими. За версією LinkedIn, кількість пропозицій для Ruby/Rails-розробників у США — понад 27 тис. вакансій. Для порівняння: Python — більш як 70 тис. вакансій, PHP — майже 55 тис., Scala — (до речі, попри підвищену цікавість з боку розробників, якщо згадаєте першу діаграму) — лише близько 9 тисяч.

Які висновки треба зробити на основі цих даних? Високий попит на Ruby/Rails у США зумовлюється тим, що там саме Rails — ключовий фреймворк для створення стартапів. Гадаю, із часом тенденції США щодо потрібності Ruby/Rails серйозно вплинуть на інші локальні labor markets, зокрема на український ринок IT.

Що пропонують Ruby/Rails розробникам українські IT-компанії

Загальна кількість Ruby/Rails вакансій в Україні в липні 2018 року сягає близько 90 (85 та 83 за даними LinkedIn і DOU відповідно). Це значно менше, ніж попит на Python (331 — LinkedIn, 158 — DOU) та PHP (456 — LinkedIn, 371 — DOU).

Джерело: LinkedIn, DOU

Ситуація з вакансіями в ключових містах:

Джерело: DOU

Відносно невеликий попит на Ruby/Rails-фахівців частково зумовлюється саме тією «бутиковістю», про яку я згадував вище. Ruby/Rails-розробники значно менше працюють з legacy-кодом та значно більше — із цікавими проектами й складними завданнями. Крім того, професійний розвиток Ruby/Rails працює both ways: перейти на Ruby з іншої мови програмування відносно легко, як і навпаки — вивчення нових додаткових мов і технологій на базі та культурі Ruby дає переваги та дозволяє «перестрибнути» сходинку junior у новій технології.

Рівень доходу Ruby/Rails-розробника

Цікаві тенденції спостерігаються і щодо фінансових показників. Згідно з результатами нещодавнього (червень — липень 2018 р.) опитування DOU, рівень доходу Ruby/Rails-розробників вищий за дохід PHP- та Python-програмістів.

Досягнувши рівня Middle, Ruby/Rails-розробник має чудові перспективи професійного й фінансового зростання.

Джерело: DOU

Інструменти

У цій статті я чимало згадував про високу культуру програмування Ruby/Rails і маю декілька аргументів на користь цього твердження. Хочу навести стислий огляд ключових інструментів екосистеми Ruby.

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

• Ruby on Rails — ідеальний фреймворк для стартапів;
• Hanami — новий веб-фреймворк, який фокусується на enterprise-компаніях;
• Sinatra — сервісно-орієнтований фреймворк.

Style Guides

• Ruby style guide;
• Rails style guide.

Тестування та якість

Фреймворки:

• RSpec — BDD-фреймворк із простим синтаксисом, що дозволяє писати тести «людською» мовою;
• Capybara — інструмент для написання приймальних тестів;
• Cucumber — інструмент, який підтримує BDD-підхід і допомагає узгодити всі специфікації, тести й проектну документацію;
• Minitest — бібліотека для написання unit-тестів, простіший аналог RSpec;
• Shoulda-matchers — набір додаткових matcher-методів для RSpec.

Створення тестових даних:

• Factory_bot — бібліотека для створення тестових об’єктів, потрібних для тестів;
• Faker — бібліотека для створення тестових даних;
• WebMock — бібліотека, що дозволяє створювати й використовувати відповіді на HTTP-запити для прискорення виконання тестів.

Веб-драйвери:

• Selenium WebDriver — інструмент для написання автотестів, які наслідують принцип взаємодії з веб-сайтом і поведінку реальних користувачів;
• Poltergeist — драйвер до Capybara, що дозволяє проводити тести на базі браузера WebKit;
• Watir — інструмент для здійснення автотестування.

Аналіз коду та відповідність нормам

• RuboCop — відстежує порушення синтаксису та стежить за відповідністю до code style;
• Simplecov — відображає відсоток покриття коду тестами;
• RubyCritic — допомагає знайти проблемні частини в коді, різноманітні code smells;
• Rails_best_practices — інструмент перевірки відповідності коду Rails нормам;
• Brakeman — інструмент, який сканує код і визначає потенційно вразливі місця;
• bundler-audit — дозволяє перевірити наявність вразливостей у бібліотеках, які використовуються в застосунку.

Зневаджування

• Pry — інтерактивна консоль з додатковою функціональністю;
• Pry-byebug — інструмент для дебагінгу коду;
• awesome-print — бібліотека, яка дає змогу поліпшувати виведення різноманітної інформації на екран: вкладені масиви, хеші тощо.

Автентифікація та авторизація

• Warden — бібліотека для реалізації функціональності автентифікації;
• Devise — бібліотека для побудови автентифікації будь-якої складності;
• JWT — впровадження стандарту JSON Web Token у Ruby;
• Doorkeeper — OAuth2-провайдер для Rails;
• OAuth2 — бібліотека для роботи з протоколом OAuth 2.0;
• CanCanCan — використовується для реалізації функціональності авторизації;
• Pundit — ще одна альтернатива, подібна до CanCanCan, але яка витрачає менше ресурсів та пам’ яті;
• Rolify — корисна бібліотека, яка дозволяє реалізувати функціональність ролей користувачів.

API

• ActiveModel::Serializers — інструмент для генерування JSON у Rails-застосунку;
• GraphQL-Ruby — бібліотека для роботи зі специфікацією GraphQL;
• Grape — мікрофреймворк, що дає змогу створити REST-подібні API;
• JSONAPI::Resources — бібліотека для роботи з форматом JSON API;
• Apipie — інструмент для ведення документації API;
• Swagger — більш розвинений інструмент для створення документації API.

Організація коду та абстракція даних

• Dry-rb — набір бібліотек для програмування на Ruby у функціональному стилі;
• Trailblazer — фреймворк, який дозволяє краще структурувати архітектуру Rails-застосунку;
• Waterfall — дозволяє писати код у Rails-підході;
• Interactor — дозволяє структурувати бізнес-логіку.

Assets

• Sassі Less — одні з найпопулярніших розширень стандартного CSS;
• Asset_sync — дозволяє синхронізувати активи із сервісом Amazon S3;
• Autoprefixer — в автоматичному режимі додає CSS-властивості для забезпечення кращої крос-браузерності.

Розгортання ПЗ

Веб-сервери:

• Pumaі Unicorn — веб-сервери для Ruby.

DevOps:

• Chefабо Puppet — інструменти для оркестрації інфраструктури програмного продукту;
• Capistrano — бібліотека для реалізації процесу розгортання;
• Vagrant — дозволяє керувати віртуальними машинами;
• Backup — дає змогу створювати резервні копії бази даних.

Continuous integration:

• Travis CI — сервіс для автоматичного запуску та моніторингу різноманітних тестів.

Керування пакетами та середовищами

• RVM — утиліта для керування версіями бібліотек Ruby;
• RubyGems — репозиторій бібліотек Ruby;
• Bundler — менеджер залежностей бібліотек.

Data Persistence

Об’єктно-реляційне відображення (ORM):

• ActiveRecord — реалізація об’єктно-реляційного відображення (object-relational mapping) у Rails;
• Sequel — простий, гнучкий і потужний набір інструментів для реалізації ORM, має велику кількість плагінів;
• ROM-rb — ще одна реалізація ORM.

Клієнти для баз даних: MongoDB, Redis, Elasticsearch, DynamoDB:

• Mongoid — реалізація об’єктно-документного відображення (object-document mapping) в Ruby з використанням бази даних MongoDB;
• Redis-rb — бібліотека для роботи з базою даних Redis;
• Redis Store — бібліотека, яка дозволяє зберігати різноманітну інформацію в базі даних Redis, як-от: Cache, I18n, Session, HTTP Cache тощо;
• Dynamoid — реалізація ORM для роботи з сервісом Amazon DynamoDB.

Створення HTTP-клієнта

• HTTParty — дозволяє працювати з HTTP-запитами в зручнішому вигляді;
• Faraday — бібліотека, яка надає єдиний інтерфейс для роботи з різноманітними адаптерами, наприклад: NET::HTTP;
• GraphQL-client — бібліотека для роботи із запитами GraphQL.

Створення інтерфейсів командного рядка

• Rake — бібліотека, що дозволяє створювати різноманітні утиліти подібно до утиліти Make;
• Thor — набір інструментів, який дає змогу будувати різноманітні застосунки для роботи в консолі;
• GLI — парсер аргументів консольних команд.

Обробка зображень і відео

• MiniMagickабо RMagick — «обгортка» до консольних утиліт ImageMagick або Graphics Magick;
• Streamio FFMPEG — «обгортка» до консольної утиліти FFMPEG, яка дає змогу виконувати різноманітні маніпуляції з відео (кропінг, процесинг тощо).

Оброблення черг даних і фонових завдань

• Sidekiqабо Resque — інструмент для реалізації відкладених завдань;
• Delayed_job — ще один інструмент для оброблення фонових завдань, який зберігає інформацію про черги в базі даних; цей інструмент витягнуто з Shopify;
• Daemons — дає змогу запускати Ruby-застосунки як системні сервіси та керувати ними;
• Foreman — ще один інструмент для запуску Ruby-застосунків, які описуються у Procfile;
• Whenever — дає можливість керувати cron-завданнями.

Пошук

• Elasticsearch-ruby — бібліотека для інтеграції та роботи з базою даних Elasticsearch;
• Mongoid Search — бібліотека для інтеграції та роботи з базою даних MongoDB;
• Pg_search — бібліотека, яка дозволяє реалізувати функціональність повнотекстового пошуку.

Адмін-інтерфейс, керування контентом, блогінг, Wiki

• ActiveAdminабо RailsAdmin — фреймворк, який дає змогу створювати адмінпанелі дуже зручно й швидко;
• RefineryCMS — розширення фреймворку Ruby on Rails, яке реалізує CMS;
• Discourse — платформа для реалізації різноманітних спільнот, форумів тощо;
• Publify — CMS-платформа;
• Gollum — бібліотека для реалізації wiki-системи, яка ґрунтується на утиліті Git;
• Jekyllабо Middleman — платформи для реалізації статичних сайтів і блогів.

Мобільна розробка

• RubyMotion — набір бібліотек для крос-платформного розроблення (iOS, OS X та Android) на Ruby;
• Ruboto — платформа для розроблення повноцінних Android-застосунків на базі мови й бібліотек Ruby;
• Ruby Push Notifications — інструмент для реалізації push-повідомлень у застосунках iOS, Android і Windows Phone;
• Rpush — ще один сервіс для реалізації push-повідомлень.

Робототехніка

• Artoo — Ruby-фреймворк для програмування в галузі робототехніки, обчислювальної техніки та Інтернету речей.

Машинне навчання

• Machine-learning-with-ruby — список бібліотек, фреймворків, методів, алгоритмів, а також статей, презентацій та інших ресурсів для роботи в галузі машинного навчання Ruby.

Штучний інтелект (AI)

• ai4r — проект для дослідників AI за допомогою мови Ruby: алгоритми для різних призначень та індустрій.

Список вийшов чималенький, утім він ще далеко не повний. Більше інструментів — у колекції Awesome Rubyта в статті RubyGarage, присвяченій гемам.

Обмеження Ruby

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

Ось декілька параметрів, за якими Ruby поступається іншим мовам:

• Швидкість виконання. Попри високу швидкість розроблення, Ruby демонструє не найвищу швидкість виконання. З одного боку, Ruby виконує чимало операцій для зручності розробника, зокрема здійснює керування пам’яттю для динамічної типізації. З іншого — звісно, обсяг таких операцій впливає на швидкість виконання. Цей критерій не є найпроблемнішим, утім міг би бути кращим.
• Багатопотоковість. Ruby підтримує багатопотоковість, але цей алгоритм реалізовано не найкращим чином, що може призводити до проблем з продуктивністю. Крім того, алгоритм багатопотоковості Ruby дещо непередбачуваний: він може перемикатися від одного потоку до іншого у будь-який момент, який складно передбачити чи контролювати. Це впливає на результат обробки даних та внесення змін і в цілому на швидкість усього процесу. Наразі розробники Ruby-спільноти працюють над вирішенням цієї проблеми.
• Домінування Rails. Ще одне обмеження Ruby стосується його фреймворків. Багато було сказано про Rails, це чудове рішення. Утім, його популярність послаблює та уповільнює розвиток інших фреймворк — Sinatra та Hanami.

Де вивчати Ruby/Rails

Початківцю

Відносно нещодавно на DOU було опубліковано статті Ruby для початківцівта Поради сеньйорів: як прокачати знання junior Ruby. У цих статтях є чимало посилань на корисні ресурси для навчання. Трохи доповню цей список онлайн- та офлайн-курсами й стажуваннями:

Онлайн-ресурси

Ruby:

• Codecademy
• Pluralsight
• Learn Ruby Online
• Team Treehouse
• One Month
• RubyMonk

Rails:

• Codecademy
• Udemy

Курси та стажування в компаніях

* офлайн-курси та стажування, на які ще триває прийом заявок

Добірка матеріалів для досвідчених Ruby-розробників

Найцікавіші матеріали з усього світу Ruby та Rails, що їх відбирає команда RubyGarage, публікуємо для вас у щомісячному дайджесті (свіжий випуск тут), утім окремо пораджу декілька ресурсів і посилань на Ruby/Rails opinion leaders, за якими стежу сам:

Корисні email-розсилки

• Ruby Weekly;
• RubyFlow;
• Official Ruby on Rails blog;
• Everyday Rails;
• Rubyland.

Telegram-канали

• Gaar4ica — канал з щоденними оновленнями про Ruby;
• proRuby — чат для Ruby та Rails-розробників;
• @evilmartians — неофіційний канал Evil Martians, де йдеться про стартапи, веб-розроблення, онлайн-бізнес, бекенд (у тому числі про Ruby та Rails), фронтенд (JavaScript) і мобільну розробку (#iOS), а також DevOps і Data Science.

Експерти

• David Heinemeier Hansson (DHH) — засновник Basecamp та автор Ruby on Rails.
• Robert C. Martin — автор принципів SOLID, провідний доповідач Ruby/Rails-конференцій, культовий розробник.
• Aaron Patterson — відомий розробник, частий доповідач на конференціях, регулярно публікує оновлення у власному Ruby-блозі.
• Sandi Metz — «ветеран» розробки, викладачка, доповідачкана конференціях, авторка Practical Object-Oriented Design in Ruby, 2013 року одержала нагороду Ruby Hero.
• Avdi Grimm — розробник, ведучий вебкасту Ruby Tapasі співведучий подкасту Ruby Rogues, автор Objects on Rails, володар нагороди Ruby Hero 2016.
• Sarah Mei — розробниця Ruby, архітекторка в Salesforce, співзасновниця RailsBridgeі директорка Ruby Central, 2015 року одержала нагороду Ruby Hero.
• Jason Fried — співзасновник Basecamp, співавтор «Rework: Ця книжка змінить ваш погляд на бізнес» і «Remote: Офіс не обов’язковий».
• Michael Hartl — підприємець, викладач, має репутацію «суперлиходія», автор @RailsTutorial, засновник @LearnEnoughта @TauDay.
• Sam Ruby — автор Agile Web Development with Rails 5.
• David A. Black — автор Well-Grounded Rubyist.

Подкасти й скринкасти

• Go Rails;
• Ruby Tapas;
• Greater Than Code.

Roadmaps: чого чекати найближчим часом у 2018-му

• Ruby: Спільнота Ruby працює над оновленою версією 2.6, реліз якої заплановано на кінець грудня 2018 року.
• Rails: У квітні 2018 р. відбувся реліз версії Rails 5.2.0, у якій з’явився додатковий функціонал (Active storage, Built-in Redis cache store) і декілька поліпшень (підтримка pg 1.0, recycle cache keys, freeze_time тощо). Наразі команда працює над версією 6.0. Тимчасом доповідачі на світових конференціях (зокрема Eileen M. Uchitelleз GitHub і Prem Sichanugristіз CookPad) уже діляться своїми думками щодо можливостей оновленої версії та майбутнього Rails 6.0.

Ключові думки

Кілька ключових думок замість підсумків до цієї статті:

• Ruby однаково гідно приймає виклик як від «прямих конкурентів», приміром, Python чи PHP, так і від новостворених мов, що набувають популярності й інтересу.
• У Ruby є свої обмеження, над якими варто попрацювати або віднайти рішення.
• Екосистема технологій Ruby пропонує широкі можливості для втілення всього розмаїття функціоналу, включно з мобільною розробкою і такими провідними галузями, як машинне навчання, робототехніка та штучний інтелект. Список численних інструментів Ruby зростає далі завдяки активній Ruby-спільноті.
• Фреймворк цієї екосистеми Rails «тримає» на собі понад 1 млн веб-платформ і залишається одним з найкращих і найбажаніших для стартапів у 2018 році.
• Серед платформ, збудованих на Ruby, — найпопулярніші ресурси й сервіси для навчання, проектної роботи, подорожей, онлайн-продажів, світові медіа та продукти ще в безлічі індустрій.
• Ситуація на локальному IT-ринку в Україні в певному розумінні сприятлива для Ruby-розробників: компанії пропонують вакансії не лише в столиці, але й у провідних IT-містах України. Вакансій небагато, але вони здебільшого в проектах-продуктах і передбачають цікаві завдання. Крім того, рівень доходу Ruby-розробників досить високий, зокрема, перевищує доходи Python- і PHP-розробників.
• Ruby пропонує початківцям відносно «низький» поріг входу й безліч корисних ресурсів для навчання та натхнення як для тих, хто лиш починає знайомитися з цією мовою, так і для досвідчених Ruby/Rails-розробників.

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

Запрошую до обговорення! Буду вдячний за ваші коментарі й запитання!

Задача для рекрутера

Задача найти толкового менеджера может показаться тривиальной, потому что ИТ в Украине — очень маленькая деревня, в которой так или иначе все знают друг друга, и найти того самого(-ую) для рекрутера не должно составить труда. Это дело техники и мастерства самого рекрутера. Если ищем в пределах одного города, узнать отзыв про любого сотрудника — раз плюнуть, а про менеджера — тем более. Важный факт: менеджерских вакансий не так много, а количество «менеджеров» растёт постоянно. Более того, каждый менеджер, так или иначе хочет промоушен на проект с большим количеством людей. Отсюда любовь к власти, желание быть в центре внимания и как результат — стремление получать большую ЗП.

Но как только рекрутер получает задачу найти менеджера, начинается больное приземление в реальность жизни и бытия. Задача с дедлайном в 1-2месяца превращается в полугодичную череду собеседований. «Этот не разделяет ценности компании», «этот технически не тянет», «этот недостаточно мотивирован», «у этого фокус только на кастомера, а значит команда разбежится», «этот вообще странный какой-то, с суждением, что кастомер — царь и бог, остальные ничтожества» и т. д. И никто не может гарантировать, что после всех этих кругов собеседований найдётся тот, кто будет этим самым идеальным кандидатом. Есть, конечно, отличные ребята, можно перекупить, но челлендж в том, чтобы найти «в бюджете». Добрая часть тех менеджерских CV, что есть на Джинне, поисковиках с соискателями работ, — болтается там с завышенной ЗП по принципу «а вдруг?!».

А ведь действительно, откуда взяться толковому менеджеру, который бы с заказчиком договорился и команду смотивировал. А ещё смог бы принести пользу компании помимо проекта и работал за вменяемые деньги. Под вменяемыми деньгами я имею в виду опыт = ожидания ЗП, a не с двумя годами манагерскими и запросом в 4К+... WTF?!

Кто виноват

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

С другой стороны, в отсутствии толковых менеджеров виноваты сами менеджеры :) Да-да, мы в большей своей части и есть первопричина этого. Дело в том, что каждый из менеджеров в той или иной степени, обязательно переживает страхи. Это ТОП-5 лично моих. У вас они могут быть в другом порядке.

1. Мне намного проще сделать всё самому. Так будет быстрее и менее затратно по времени, чем по сто раз объяснять кому-либо.

У меня это было в период начинаний менеджерской стези 8 лет назад. И мне действительно было гораздо проще делать всё самому, чем растить кого-то и объяснять, как нужно. Всё это ещё хоть как-то работало, пока у меня была команда из 4 человек. Когда проект начал расти и я чувствовал себя, как загнанная борзая, я начал осознавать, что не справляюсь. Более того, прилетел ещё волшебный мотивирующий пендель от начальства: «Ты или учишься ими управлять, или на предыдущую ступеньку карьеры. Выбирай сам». Научился очень быстро. Повезло.

2. Я потеряю контроль над проектом.

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

Возьмём среднюю команду на наших просторах — 50 человек. Встреча 1 на 1 длится до 20-30минут (пусть будет 20) и проводится 1 раз в 2 недели. Итого 20 минут умножаем на 50, получаем 16 часов 40 минут из 80 часов — только на то, чтобы убедиться, что атмосфера в команде отличная и народ не собирается покинуть сей замечательный проект. А если некоторые встречи затянутся, а если нужен follow up и т. д.? Но благодаря самой же команде и удачно подобранным людям даже намёка на эту проблему не возникало.

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

3. У меня будет меньше власти над проектом.

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

4. Мой менеджемент не увидит результатов моей работы.

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

5. If I try and something go wrong, I`ll be punished.

В ту же копилку, «а что вдруг?». В таких случаях так и хочется процитировать песню Семёна Слепакова «А что вдруг, если да?» и всё получится. Но, страх и желание оставаться в зоне комфорта играют злую шутку с кандидатами.

Так откуда же взяться толковым менеджерам

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

Во-первых, компания должна быть готова вкладывать в своих менеджеров. И я не про сертификацию PMBoK/SCRUM т. д. (хотя без них никуда) — я бы сказал это must have хотя бы для того, чтобы понимать разницу и нюансы разных подходов. Я больше о том, чтобы давать своим менеджерам понимание, «а как те или иные практики работают в других компаниях, почему в одном енвайроменте оно работает отлично, а схожем — совершенно не применимо». К примеру, что такое бирюзовые компании? Или почему холакратия важна для продуктовых компаний и что это такое? Делят ли менеджеры между собой такую информацию, как lessons learned и т. д.? Список можно продолжать до бесконечности. Всё же я считаю, что менеджерская работа — творческая. Иначе нас давно можно бы было заменить на скрипт :)

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

В третьих, очень важно, чтобы менеджер преодолел свои страхи и начал заниматься делегированием и empowerment’ом в своих командах. Это позволит «выращивать» будущих менеджеров и лидеров внутри компании/проекта. Для этого можно использовать подход «The Seven levels of Authority». В идеале нужно вести такую схему для каждой из своих команд. Очень помогает отслеживать их зрелость. Почему я считаю, что менеджеру нужно это делать? Менеджер ответственный за развитие своей команды, он же отвечает за процессы в команде. Если же менеджер не пытается выполнять роль незаменимого звена команды, без которого она не может работать, то в его отсутствие (отпуск/болезнь/командировка и т. д.) с командной и процессами ничего не должно произойти.

Здесь мне нравится подход Генри Форда, который в один прекрасный день собрал менеджеров на совещание и прямо с совещания они все поехали то ли в командировку, то ли на тимбилдинг на 1 неделю. Те менеджеры, у которых произошёл сбой (без них не принимались решения и их команды/департаменты не могли работать самостоятельно) — были уволены, другие получили хорошую прибавку и бонус.

В четвертых, есть такая хорошая пословица «рыба гниёт с головы». То есть если менеджер требует от своих подчиненных, чтобы у них был роадмап развития, то и у самого менеджера должно быть понимание, куда он развивается и зачем. Для этого отлично подойдёт навык планирования. Начните с себя. Вот какой у вас роадмап на ближайшие 2-3 года?Какие навыки нужно приобрести/прокачать? Какие сертификации необходимо получить? MBA? Если да, то где, почему именно там и зачем это нужно именно вам? Список может быть бесконечным. Но умение планировать и строить роадмапы для себя позволит применять эти же навыки для своих команд и подопечных. Более того, гораздо проще что-то требовать, показывая это на своём примере. Иначе это выглядит так же нелепо, как если бы менеджер требовал от своих команд/подопечных вовремя приходить на митинги, при этом опаздывая на все митинги самостоятельно.

Выводы

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

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

Статья создана в соавторстве с Владиславом Колбасиным (Lead Software Engineer, Consultant, GlobalLogic) и Игорем Манжосом (Consultant, GlobalLogic).

Несколько лет назад в харьковском офисе GlobalLogic был создан инновационный инкубатор BrainMade — для развития практики в BigData, Industrial, IoT, Augmented Reality, Machine Learning и других технологиях. Здесь все созданные нами Proof-of-Concepts (PoCs) получают свое продолжение и возможность практической реализации. Так была создана умная железная дорогаи климатическая система с дополненной реальностью Meteologic.

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

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

Идея проекта

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

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

В переводе на английский «родинка» — «nevus». Так мы и назвали наш проект.

Команда Nevus

Предшественники

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

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

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

Именно в этом ключе мы и начали работу над проектом.

Задачи проекта

Точность

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

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

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

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

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

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

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

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

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

Реализация проекта

В проекте были задействованы два разработчика, использовались технологии: TensorFlow, Angular, Node.js, Nginx.

Загрузка фото

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

Обработка данных

Каждый случай — это фотография родинки и мета-информация: название, описание и существующий диагноз (если он известен).

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

Отделенная от фона родинка передается на обработку в нейронную сеть Inception V3. Эта сеть содержит 311 слоев и около 25 миллионов параметров.

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

Пользователь — доктор

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

Например, ниже доктор отметил, что данная родинка — просто родинка, выбрав значение «Nevus» в выпадающем списке «Labeled by Doctor as:», значение по умолчанию — «Unknown»:

Вся информация, включая автоматический диагноз и его верификацию (о ней — ниже), отображена на панели для данного случая:

Галерея

В галерее можно увидеть все случаи, отфильтровать их по диагнозу, дате и названию:

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

Алгоритм определения диагноза

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

Рассмотрим случай, описанный следующими вероятностями:

• Melanoma Risk: 0.4052
• Seborrheic keratosis Risk: 0
• Simple nevus: 0.5948

Из этого Nevus делает вывод, что перед нами — обычная родинка, то есть «Simple nevus». Ее вероятность равна 0.5948, что больше двух других вероятностей (0.4052 для меланомы и 0 для кератоза).

Под заголовком «Probably it is a»отображается вывод, в нашем случае — «Nevus».

Сбор базы данных

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

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

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

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

Работа с данными

Обучение

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

1. Брали сеть, уже обученную для классификации изображений из набора ImageNet.
2. Отбрасывали последний слой этой сети, ответственный за окончательные предсказания, и добавляли новый слой для решения нашей задачи.
3. Несколько начальных слоев «замораживали» (их веса не изменялись).

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

Тестирование модели

Важные метрики медицинского теста — это специфичность (она же точность, precision, specificity) и чувствительность (она же recall, sensitivity). Эти метрики вычисляются по следующему алгоритму: тест на меланому классифицирует каждый случай как имеющий меланому (положительный результат) или не имеющий ее (результат отрицательный). Возможны четыре исхода:

• Истинный положительный результат, true positive:тест показал меланому, и она действительно есть.
• Истинный отрицательный результат, true negative:тест показал отсутствие меланомы, и ее действительно нет.
• Ложный отрицательный результат, false negative:тест показал отсутствие меланомы, а на самом деле она есть.
• Ложный положительный результат, false positive:тест показал меланому, а на самом деле ее нет.

Эти исходы можно представить в виде «матрицы неточностей» (confusion matrix):

Специфичность и чувствительность — это статистические показатели эффективности теста, вычисляемые по формулам:

Специфичность = количество истинных отрицательных результатов ÷ (количество истинных отрицательных результатов × количество ложных положительных результатов)

Чувствительность = количество истинных положительных результатов ÷ (количество истинных положительных результатов × количество ложных отрицательных результатов)

Идеальный тест получает 100% по обеим метрикам.

Сравним результаты

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

В результате на тестовом датасете получилось решение с такими метриками:

• Precision (Specificity) = 0.8238
• Recall (Sensitivity) = 0.8044
• F1 score = 0.8138
• Accuracy = 0.89

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

Например, согласно этой статье, исследователи получили:

• Precision (Specificity) = 0.713
• Recall (Sensitivity) = 0.866

Как видим, у нас Recall чуть лучше, но Precision — чуть хуже.

Матрица неточностей Nevus

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

Нормализованная матрица:

Результаты проекта

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

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

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

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

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

Евгений Власюк, Delivery manager в EPAM Ukraine

ЕРАМ — мое первое место работы. До него у меня был опыт научно-технических разработок при университетах. Сотрудничая с компанией более 6 лет, я прошел все позиции от Intern до Team lead.

Последние 1,5 года выполняю обязанности Delivery Manager. До того как стать DM, я работал тимлидом на Financial Services проектах. Занимался всеми уровнями девелопмента, которые только возможны, начиная с фиксирования багов и заканчивая проектированием архитектуры проекта, на котором работаю сейчас — это структура, дизайн, разработка с нуля. То есть полный спектр всех необходимых действий для успешного стартап-проекта.

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

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

О переходе.За 6 лет в ЕРАМ я работал на 4 проектах, на последнем проекте изменилась моя роль. Переход от тимлида к DM был постепенным и органичным. Это не произошло за один день. Я рос вместе с проектом. У нас численно увеличилась команда, стали поступать новые задачи от клиента, соответственно, начали появляться новые вызовы для delivery.

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

Безусловно, разница между тимлидом и DM есть. Во-первых, тимлид больше концентрируется на управлении командой и работе с людьми для достижения поставленных задач. Если говорить про наш текущий проект, мы начинали одной командой, но на данный момент это 4, а иногда и 5 команд. Реальный вызов для delivery — это синхронизировать работу всех команд между собой и сфокусировать их на достижении глобальной цели, но при этом сохранить автономность работы.

Вторым существенным отличием является степень ответственности DM. Ты должен понимать проект шире, но уровень погружения не должен становиться меньше.

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

В моем арсенале есть скиллы проектного менеджмента: могу переиграть планы, передоговориться с клиентом. Повлиять на архитектурное решение, например, что-то упростить. Могу задействовать People management скилы. Работу DM можно сравнить со швейцарским раскладным ножиком: у тебя есть многофункциональный набор инструментов, какой из них применять прямо сейчас — зависит от тебя.

Об обучении.Мне очень помогли внутренние образовательные программы ЕРАМ. Я принимал участие в Team Lead Grow и Managers’ Mentoring Program.

Дополнительно занимался самообразованием. Вот некоторые книги, которые я рекомендую: «Principles: Life and Work»Рэя Далио, «Delivering Happiness: A Path to Profits, Passion, and Purpose»Тони Шея, «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения»Тома де Марко и Тимоти Листера.

С чего начать?Самое главное — это желание и отсутствие страха проявлять инициативу. Старайтесь выходить за рамки своей зоны ответственности, смотреть на задачи шире. Если вы Back-end разработчик, посмотрите, как устроен DevOps. Если вы Front-end — интересуйтесь, как устроен сервер. Если вы тимлид — применяйте практики проектного менеджмента.

Вы должны быть экспертом в своей области, но нужно постепенно расширять свои профессиональные горизонты. Delivery manager не будет настолько хорош в архитектуре проекта, как Solution architect, но знания позволят ему говорить с командой на одном языке.

И, конечно, важна работа с людьми — people management. Больше общайтесь с коллегами. Они такие же, как и вы.

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

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

Евгений Васьковский, Project Manager в Astound Commerce

Мой профессиональный путь начался еще со студенческой скамьи, и он не был полностью связан с IT-индустрией. Около пяти лет я работал системным администратором, затем следующие пять лет — QA и QA Team Lead.

Наконец, последние четыре года занимаю должность PM-а в винницком офисе Astound Commerce.

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

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

О переходе.Мой переход из QA Team Lead в Junior PM происходил в виде цепочки собеседований, нацеленных в основном на оценку soft skills. Считаю, что мой предыдущий опыт сыграл большую роль в развитии коммуникативных навыков, организаторских способностей и командной игре, что так необходимо для работы проектного менеджера.

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

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

Об обучении.Я изучал теоретическую основу (PMBoK, материалы на PMI) всего того, с чем приходилось сталкиваться. Также очень сильно помог недельный курс от Влада Березина, который организовывала компания для всех сотрудников PMO (Project Management Office) приблизительно в самом начале моей РМ-ской карьеры.

К тому же на момент моего «свитча» уже существовал PMO со своим рабочим SDLC (Solution Development Life Cycle). Поэтому, приступив к работе, я имел возможность пользоваться уже существующими наработками, шаблонами, процессами и опытом всех проектных менеджеров компании.

На мой взгляд, вот необходимая база для будущего РМ-а:

• PMBoK;
• корпоративные стандарты и наработки, best-practices;
• развитая коммуникация, навыки переговоров, бизнес-переписка, хороший уровень английского и прочие soft-skills;
• доменные знания;
• общее развитие в смежных и не очень областях.

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

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

Дмитро Ярмак, Release Train Engineer в SimCorp Ukraine

Ще під час навчання в університеті я майже рік працював інженером на одному великому державному підприємстві. Як мене вистачило майже на рік? Не знаю, напевно, коли молодий, то дуже витривалий :) Після цього потрапив до SimCorp, починав як девелопер фінансового ризик-менеджменту на APL та С#.

За 10 років у компанії я працював у чотирьох відділах на п’яти різних позиціях: розробник, тестувальник, тімлід, менеджер і зараз Release Train Engineer.

Остання позиція немає нічого спільного з потягами (майже) :) У Scaled Agile Framework (SAFe) ця роль нагадує Delivery Manager або Scrum Master of Scrum Masters. Зараз я відповідальний за delivery десяти Scrum-команд: чотирьох у Києві, п’яти у Копенгагені і однієї у Бад-Хомбурзі (Німеччина). Ці команди об’єднані у Agile Release Train, який є окремим value stream нашого продукту.

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

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

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

Про перехід.Мій перехід у менеджери відбувся з позиції тімліда — у тій самій компанії, де я вже працював 4 роки. Це був відкритий процес, де всі охочі могли спробувати свої сили. Я спробував, і данський керівник вирішив, що в мене є потенціал бути лідером. Так у 28 років я став Group-менеджером.

Про відмінності у роботі.Як я вже казав, мої задачі в компанії більше відносяться до позиції Delivery Manager. У процесі розробки ПЗ ми використовуємо Scaled Agile Framework, який передбачає самоорганізаційні та самодостатні Scrum-команди. І такий самий принцип застосовується до лідерських команд. Немає боса, який скаже, як тобі працювати. Натомість на всіх нечисленних ієрархічних рівнях є команди, які приймають рішення.

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

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

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

Про навчання.На мене книги мають більший вплив, ніж курси. Можу порадити стару і гарну «7 Habits of Highly Effective People»Стівена Кові, «Turn The Ship Around»Девіда Марке, «Good To Great» Джима Колінза, «The Phoenix Project»Джина Кіма, «The Five Dysfunctions of a Team»Патріка Ленсіоні, «The Soft Edge: Where Great Companies Find Lasting Success»Річа Карлгаарда.

Також раджу відвідувати конференції, спілкуватися, ділитися досвідом. Наприклад, київські друзі зі ScrumGuides проводять дуже якісні курси, конференції та інші заходи.

З чого починати?Почитайте про Servant Leadership. Також необхідно опанувати Agile-методи розробки та принципи Lean.

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

Николай Ткач, Project Manager в KeepSolid

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

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

Как PM работаю уже в общей сложности полтора года.

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

Об обучении.У меня начиналось все стандартно. Закончил курс по управлению проектами. Читал PMBoK, «Сто правил руководителей проектов NASA»Джерри Мэддона, «Критическая цепь»Элияху Голдратта, «Deadline. Роман об управлении проектами»Тома ДеМарко.

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

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

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

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

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

Анатолий Кочетов, Delivery Director в Sigma Software

Еще в университете я начал карьеру как своего рода фрилансер: делал на заказ лабораторные, курсовые и дипломные работы :)

На втором курсе один из преподавателей меня заметил и предложил присоединиться к компании, в которой он был учредителем и руководителем. Так я стал Junior разработчиком. Писал сначала на C++ и Delphi, после на C# — освоил его дома в свободное время на pet-проектах.

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

Затем я перешел в Sigma Software на позицию руководителя проектов, которая включала в себя полную ответственность за весь проект и его аспекты, удовлетворенность клиента, стейкхолдеров, команды. Это подразумевало вовлечение в весь цикл от А до Я, когда необходимо погружаться в разбор проектной ситуации достаточно глубоко. В 2009 году я стал менеджером Microsoft Solutions департамента, а в 2017 перешел на позицию Delivery Director.

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

О переходе.Изначально я перешел в рамках одной компании. Это были кризисные 2008-2009 годы.Однажды я понял, что нашел зону комфорта и больше не развиваюсь. Решил, что нужно искать компанию, где у меня будет пространство для принятия решений и применения моего опыта с одной стороны, и сильный management institute для развития с другой.

Помню, что проходя собеседование в Sigma Software (тогда еще Eclipse SP), я ощущал странное чувство, когда непонятно, кто кого больше интервьюировал :) Но в итоге я был приятно удивлен вопросами, которые мне задавали, и понял, что хочу руководить проектами именно в этой компании. Здесь я получил совсем новое понимание международного проектного менеджмента. Это была новая планка, к которой нужно было тянуться.

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

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

Если сравнивать позиции разработчика и руководителя, то, как говорил Uncle Ben, «With great power comes great responsibility» :) Это важное отличие. Необходимо помнить и оценивать, насколько человек кайфует от ситуаций, в которых есть факторы неопределенности и большая ответственность за принимаемые решения. Это также характерно и для architect-позиций: ответственность за решения очень высока и порой на кону сотни тысяч долларов.

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

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

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

Затем попросите в рамках текущего проекта дать вам ответственность за полный цикл, скажем, одной feature: выяснение требований, дизайн, координация работы front-end, back-end, контроль качества, демо и так далее. Постепенно можно развивать квалификацию, шаг за шагом получать и закреплять новые знания и опыт, приходить в PM постепенно — от ответственности за одну фичу к ответственности за все более крупные команды и проекты. Инкрементально-итеративно :)

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

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

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

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