Майже 24 тисячі користувачів GitHub вказали своїм місцем проживання Україну, ми вирішили дізнатись про найбільш популярних та професійних. Для аналізу використовувався пошук по GitHub, відкриті набори даних за квітень від GHTorrentта GitHub Archive, а також LinkedIn. Дані містять інформацію переважно про публічні репозиторії.

ТОП-10 користувачів GitHub

Найбільше в рейтингу представлені JavaScript, Android та PHP розробники. Близько 50 % учасників рейтингу проживають в Києві, по 15 % в Харкові та закордоном, 10 % — Львів та інші міста. Щодо типу компанії 70 % працюють в продуктових компаніях, 30 % — в аутсорсі.

Учасників ми оцінювали за такими критеріями, як кількість зірок, підписників, «коммітів», закритих issues та «форків».

Stars

Star (аналог Like на Facebook) — це якісна характеристика репозиторіїв на GitHub, будь-який користувач може поставити зірку проекту, який йому подобається. Найбільше зірок мають JavaScript/TypeScript розробники, які займають 7 з 10 місць у рейтингу. Детальніше на графіку:

Рейтинг рахувався як сума зірочок власних репозиторіїв авторів

Перше місце з кількістю 24 тис. зірок посідає Дмитро Семенов (dimsemenov), який працює на фрілансі та відомий таким проектом, як галерея картинок на JavaScript PhotoSwipe.

На другому — Володимир Шацький (vlad-shatskyi), який працює в компанії Railsware, з кількістю зірок 16 тис.

На 3 місці Дмитро Данилик (dmytrodanylyk), який працює в Atlassian, з результатом 10 тис. та проектом Сircular progress buttonдля Android.

Followers

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

Рейтинг рахувався як сума зірочок власних репозиторіїв авторів

1 місце в рейтингу займає Володимир Агафонкін (mourner), автор всесвітньо відомої бібліотеки Leafletдля роботи з інтерактивними картами. Зараз він працює на позиції Lead JavaScript Engineer в Mapbox, більше можна прочитати в інтерв’ю з Володимиром.

2 місце з мінімальним відривом займає Paul Miller (paulmillr). Між іншим Paul зробив власний GitHub-рейтинг — git.io/top.

3 місце — Дмитро Данилик (dmytrodanylyk), про якого уже згадувалось вище.

Commits

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

Кількість коммітів вказана за час існування дата сету з 2012 по 04.2017. Рахуються комміти, зроблені лише до публічних репозиторіїв

Неочікувано, але по кількості коммітів перше місце займає Rada data bot. Цей бот зберігає всі версії змін та поправок до законів України і вніс їх понад 173 тис. за весь час існування з 2015 року.

1 місце серед програмістів займає людина під ніком Coderaiser, особистість якої встановити не вдалось.

2 місце — Сергій Яковлєв (sergeyklay), який працює Senior Software Engineer в PDFfiller.com, відомий своєю участю в розробці PHP-фреймворка Phalcon.

3 місце — у Максима Котляра (makasim), Lead System Architect в Forma-Pro. Максим є автором бібліотеки Payumдля обробки інтернет-платежів, написаної на PHP.

Closed issues

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

Кількість завдань вказана за час існування дата сету з 2012 по 04.2017

1 місце впевнено посідає Ігор Малиновський (uglide), відомий розробкою графічної оболонки для СУБД Redis — RedisDesktopManager.

2 місце — Володимир Агафонкін (mourner).

3 місце — Михайло Бондарчук (DavertMik), який працює PHP-розробником в Codegyre.

Forks

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

1 місце — Дмитро Семенов (dimsemenov) з результатом 3584, який також займає 1 місце за кількістю зірочок.

2 місце — Сергій Пименов (olton) з кількістю форків 1863, який працює СТО в Internet Invest. Також ним було створено Front-End framework Metro-UI-CSS.

3 місце — Дмитро Данилик (dmytrodanylyk). Він набрав 1240 форків.

Підсумки

ТОП-3 користувачі, які мають найбільші значення в сумі по всім критеріям, відображені в таблиці нижче:

Стабільно сильні позиції за всіма характеристиками у Володимира Агафонкіна (mourner). За зірочками та форками лідирує Дмитро Семенов (dimsemenov), але відстає за кількістю сommits. Це зумовлено меншими масштабами проекту порівняно з Агафонкіним та більшими розмірами коммітів. Дмитро Данилик (dmytrodanylyk) впевнено тримає за собою 3 місце за кількістю зірочок, форків, підписників.

Публічні акаунти ІТ-компаній

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

1 та 2 місця займають компанії Yalantisта Cleveroadз Дніпра, які спеціалізуються на мобільній розробці під Android. Найпопулярніший репозиторій Yalantis — бібліотека для обрізки зображень uCrop, у Cleveroad — це проект бібліотеки для створення анімованих туторіалів додатків SlidingTutorial-Android. 3 місце в івано-франківської компанії Devlight.

Детальніше по технологіям

Загальна картина кількості прихильників open source виглядає так:

На графіку зображені мови, які мають більше 200 користувачів

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

JavaScript

1 місце традиційно в Дмитра Семенова (dimsemenov).

2 місце — Денис Луков (nexts), який працює Front-End розробником в Snap Inc. Найбільш відомий проект Дениса — Clusterize.js (JavaScript-плагін для відображення великих даних).

3 місце — Дмитро Воронянський (voronianski).

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

Java

1 місце — Дмитро Данилик (dmytrodanylyk).

2 місце — у Ярослава Шевчука (yarolegovich) з проектом DiscreteScrollView.

3 місце — Олександр Мельников (makovkastar).

Усі 10 учасників програмують під Android.

Python

1 місце — за розробником бібліотеки для функціонального програмування Fn.py — Олексієм Качаєвим (kachayev).

2 місце — Ігор Олександров (ihodev).

3 місце — Сергій Сторчай (r8).

Ruby

1 місце — Ігор Галета (galetahub) CEO компанії Fodojo.

2 місце — Ігор Касянчук (igorkasyanchuk) з SoftServe, автор проекту Rails Database Viewer.

3 місце — Леонід Шевцов (leonid-shevtsov), який працює в Railsware.

Objective C

1 місце — Денис Тележкін (denheadless).

2 місце — Пилип Васильченко (artfeel) з проектом утиліти для анімації трясіння AFViewShaker.

3 місце — Артем Гординський (ArtemGordinsky) з додатком для Mac OS Spotifree, який автоматично блокує аудіорекламу в Spotify.

Контриб’ютори популярних проектів

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

• Богдан Гусєв (CТО в Talkable) — коммітив в Rails;
  
• Інгвар Степанян (JavaScript Performance Engineer в Cloudflare) — коммітив в Node.js;
  
• Назар Мокринський (Open Source Enthusiast) — коммітив в Polymer;
  
• Артем Білан (Principal Software Engineer в Pivotal) — коммітив в Spring framework;
  
• Дмитро Сікорський (CEO в Ubrainians) — коммітив в Ext JS;
  

На завершення

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

Кілька корисних топіків:

• Кто пилит опенсорс и какой профит?
• Open source по-украински

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

Начнем с известного факта, что аутентификация Kerberos основана на запросах. То есть каждый запрос к удаленной системе должен содержать действующий мандат Kerberos в HTTP-заголовке Authorization. Вроде бы это не такая уж и большая проблема: мы живем в 2017 году, и пару лишних килобайт данных (да, мандаты Kerberos не столь маленькие, как кажется, и могут достигать 16 Кб) большой роли не сыграют. На самом деле проблема не столько в размере передаваемых данных, сколько в необходимости проверять входящий мандат Kerberos для каждого запроса — что, конечно же, не очень хорошо масштабируется. На всякий случай имейте в виду, что размер мандата и сам по себе может приводить к проблемам, поскольку http.sys может не принимать HTTP-запросы больше 16 килобайт.

Поэтому, чтобы избежать снижения производительности, специалисты из Майкрософт добавили в IIS специальную настройку, которая называется authPersistNonNTLM и позволяет проводить аутентификацию Kerberos только один раз для каждого TCP-соединения. Любопытного читателя может заинтересовать прекрасный пост в блоге, в котором описываются все детали этой настройки. Кто-то скажет: эй, так давайте же просто включим эту настройку и пойдём пить пиво? Не так быстро, дорогой друг, не так быстро — у нас здесь устаревшая система! :) Если точнее, «устаревшая» в данном случае означает систему, которая поддерживает только HTTP 1.0. А это значит — никакой поддержки HTTP keep-alive, что, в свою очередь, приводит к невозможности использовать одно TCP-соединение для нескольких HTTP-запросов. Следовательно, увы и ах — настройка authPersistNonNTLM становится совершенно бесполезной.

Возникает вопрос: а можно ли все-таки что-то оптимизировать при таких печальных обстоятельствах? И, как оказалось, ответ положительный: мы можем добиться повышения производительности, используя метод под названием «пре-аутентификация». Основная идея этого метода крайне проста: вместо дополнительного обращения к серверу после получения ответа 401 Unauthorized, мы заранее добавляем действительный мандат Kerberos к каждому исходящему запросу, избавляясь, таким образом, от лишних обращений к серверу по сети. И все было бы просто, если бы WCF поддерживал пре-аутентификацию по умолчанию. К сожалению, по какой-то странной причине, такой поддержки в WCF «из коробки» нет, и мы остаемся один на один с задачей получения действующего мандата Kerberos и добавления его в качестве правильно сформированного заголовка Authorize. Желательно, не обращаясь к низкоуровневым SSPI API — потому что, вы же знаете, там обитают драконы :)

После множества проб и ошибок мы пришли к следующему:

public dynamic CallSoapMethod<TService>(Func<TService, Task<dynamic>> func, string endPointName)
{
    dynamic service = Activator.CreateInstance(typeof(TService), endPointName);
    using (new OperationContextScope(service.InnerChannel))
    {
        HttpRequestMessageProperty requestMessage = new HttpRequestMessageProperty();
        var contextChannel = (IContextChannel)service.InnerChannel;
        var remoteAddressUri = contextChannel.RemoteAddress.Uri;
        ICredentials credentials = CredentialCache.DefaultCredentials;
        NetworkCredential credential = credentials.GetCredential(remoteAddressUri, "Kerberos");

        KerberosSecurityTokenProvider tokenProvider = new KerberosSecurityTokenProvider(
            "HTTP/your-service-SPN",
            System.Security.Principal.TokenImpersonationLevel.Impersonation,
            credential);

        KerberosRequestorSecurityToken securityToken = tokenProvider.GetToken(
            TimeSpan.FromMinutes(1)) as KerberosRequestorSecurityToken;

        var securityTokenRequest = securityToken.GetRequest();
        string serviceToken = Convert.ToBase64String(securityTokenRequest);
        
        requestMessage.Headers["Authorization"] = "Negotiate " + serviceToken;
        OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = requestMessage;

        return func.Invoke(service);
    }
}

ВАЖНО:В web.config веб-сайта / веб-сервиса, который обращается к устаревшей системе, должно быть следующее:

<system.web><authentication mode="Windows" /><identity impersonate="true" /></system.web>

иначе делегация идентификатора Kerberos работать не будет.

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

Разница в мышлении бизнеса и программиста. Типичные ошибки с обеих сторон и как их исправить?

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

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

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

Какие ошибки совершили обе стороны, и что можно сделать лучше?

Чужая проблема

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

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

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

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

Что делать?

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

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

Круг общения

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

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

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

Что делать?

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

Личный контакт

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

Что делать?

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

Разная детализация

бизнеc> Выдержит ли наша система стократный рост количества пользователей?
прогр> Я провел нагрузочное тестирование. У нас сервер падает при 300 запросах на авторизацию в минуту.
бизнеc> А сколько сейчас запросов?
прогр> Не знаю, но можно добавить балансировщик.
бизнеc> Мы собираемся делать рекламную кампанию. Мы можем это делать? Или серверы лягут?
прогр> Ну, если будет 300 запросов в секунду...
бизнеc> Если серваки упадут, то первое впечатление нельзя сделать дважды. Может быть конфуз.
© утрированный диалог. Даже не диалог, а два монолога.

Что видит капитан? Штурвал, острова на горизонте, макушку гребца. Бизнес видит KPI, ROI, инвестиции, стратегическое видение, переговоры, конкурентов, бюджет и макушку программиста. Если он начнет уделять всё своё время вниканию в задачи и проблемы программиста — он сдохнет. Времени на всё не хватит, бизнес и так обычно живет в диком ритме. Поэтому как в шутерах — железо не тянет? Снижаем детализацию!

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

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

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

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

Что делать?

• Балансировать и нырять туда-сюда. Смотрите на ситуацию со всех точек зрения. Предугадывайте реакцию обеих сторон.
• Не ждать, что бизнес поймет очевидные вещи без детальных объяснений. «А почему нельзя просто скопипастить этот модуль? Зачем тратить время на написание общего класса?»

Конфликт ценностей

Что думает бизнес?

Что думает программист?

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

Что делать?

• Знайте, что важно для другой стороны. Максимальная эффективность? Бог? Деньги? Семья? Если у вас для всех получается один ответ, значит, что-то не так. Люди разные.
• Уважайте чужие ценности и требуйте уважения к своим. Чужие ценности не нужно принимать, их достаточно уважать. «Ты веруешь, а я атеист. Ок, я не смеюсь над купанием в проруби, а ты не проповедуй мне без моего запроса».
• Уважение к чужим ценностям имеет ограничение — если для другого важно «я отжимаю, что хочу», то я это уважать не буду. Правила для сотрудничества и правила для войны разные. Можно перечитать про овертаймы.

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

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

• «Какую проблему бизнеса я могу решить?»
• Общайтесь с бизнесом больше.
• Бизнесу некогда вникать в детали.
  
  • Если сможете его от этого избавить — будет хорошо.
  • Если сможете говорить на его уровне детализации — будет еще лучше.
• У бизнеса — другие ценности. Уважайте их и требуйте уважения к своим.

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

Якщо ви маєте інформацію про інші безкоштовні курси/стажування/інтернатури, яких немає в дайджесті, пишіть на zlot.dima@gmail.com, і ми додамо їх до статті.

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

CoreValue

Напрям:курси Salesforce.
Місто:Полтава.
Дедлайн подачі заявок: 4 серпня.

Вимоги до кандидатів:

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

Як потрапити: заповнити анкету, пройти співбесіду.

Умови: 8-10серпня 2017 року, 3-деннийінтенсивний курс Salesforce з досвідченими викладачами і програмістами в офісі компанії CoreValue. Щодня по 3 години. Заняття включають в себе: теорію, практичні завдання, майстер-класи, тестування по закінченню курсу.
Деталі: надсилайте запитання info@corevalue.net.

EPAM

Напрям:курси QA, .NET.
Місто:Львів (QA, .NET).
Дедлайн подачі заявок: 11 серпня (QA), 18 серпня (.NET).

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

Як потрапити:надіслати заявку на сайті, пройти тестування та інтерв’ю.

Умови:навчання проводиться 2-3рази на тиждень, в залежності від напрямку та групи. Більше інформації на сайтітренінгового центру компанії.

UNIT Factory

Напрям:курси програмування.
Місто:Київ.
Дедлайн подачі заявок: 15 вересня.

Вимоги до кандидатів: особливих вимог немає, спробувати себе може кожен бажаючий віком від 17 до 30 років.

Як потрапити: зареєструватись на сайті, пройти онлайн-тестування, співбесіда.

Умови: навчання проходить peer-2-peer, тобто в режимі колаборації — тут немає викладачів, студенти вчаться самі, допомагаючи один одному. Немає ні оцінок, ні лекцій, ні конспектів. Навчання відбувається у вигляді роботи над проектами.
Деталі: на сайті.

Samsung R&D Institute Ukraine

Напрям:інтернатура по C/C++ (Augmented Reality | Virtual Reality, Artificial Intelligence | Robotics, Security).
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• Cтуденти технічних вузів: 4, 5, 6 курсів, аспіранти;
• Академічні базові знання C/C++.

Як потрапити:надіслати англійскою мовою резюме на srk.hr@samsung.comз темою листа: «SRK Internship 2017-2018 | Name Surname», отримати запрошення, пройти тестування (4 години), мови програмування: C/C++, успішно пройти технічне та HR інтерв’ю.

Умови:тривалість інтернатури: 6-12 місяців,групи по 10-15 чоловік,у кожній з яких є власний ментор, графік роботи: 40, 30, 20 годин на тиждень (на вибір інтерна), інтернатура оплачується.
Деталі:надсилайте запитання на пошту srk.hr@samsung.com.

Sigma Software

Напрям:інтернатура DevOps, Software Testing, .NET.
Місто:Київ, Харків.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів: детальніше по кожному напряму на сайті університету.

Як потрапити: заповнити форму.

Умови: повний робочий день.
Деталі: на сайті.

CHI Software

Напрям:інтернатура Node.js, Android.
Місто:Харків.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:
Node.js

• Розуміння основних принципів ООП;
• Базові знання Promises;
• Базові знання ES6;
• Гарне знання SQL, а також розуміння, що таке реляційні та нереляційні бази даних і яке їх призначення;
• Добре знання нативного JavaScript, включаючи методи OOP;
• Розуміння протоколу HTTP, request/response, DNS, повний життєвий цикл запиту;
• English level intermediate+.

Android

• Знання англійської мови на рівні Upper-Intermediate;
• Гарне знання ООП;
• Студент 2+ курсу технічого ВНЗ;
• Знання Android SDK
• Досвід роботи з Git.

Як потрапити: відправити CV у Skype: Anastasiia Zhuravlova (nastia9115) або на пошту careers@chisw.com, пройти співбесіду англійською мовою з викладачем, виконати тестове завдання, пройти співбесіду в офісі з технічним фахівцем.

Умови:оплачувана інтернатура протягом 2-3 місяців,з понеділка по п’ятницю, гнучкий графік. Під час інтернатури кандидати будуть працювати над тестовими завданнями і реальними проектами під керівництвом менторів. Залучатися до участі у заходах і житті компанії.
Деталі: надсилайте запитання на пошту hr@careers@chisw.com.

Авто Газ Глобал

Напрям:стажування 1С розробник.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• Вік починаючи зі студентів старших курсів і старше;
• Базові знання механізмів Платформи 1С: Підприємство 8;
• Проходження курсів (онлайн / офлайн) з програмування на платформі 1С 8 або рівноцінний досвід буде плюсом.

Як потрапити: надіслати резюме на it@autogas.in.ua, виконати тестове завдання, пройти співбесіду.

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

Exadel

Напрям:стажування Full Stack (.NET + JS).
Місто:Вінниця.
Дедлайн подачі заявок: 10 серпня.

Вимоги до кандидатів:

• Англійська (розмовний, письмовий) на рівні intermediate або близький до нього;
• Знання OOP / OOD;
• Знання C # і платформи .NET;
• Вміння користуватися середовищем розробки MS Visual Studio;
• Знання SQL та баз даних;
• Мати уявлення про ORM;
• Знання ASP.NET MVC / Web API.

Як потрапити: надіслати резюме на job-vinnitsa@exadel.com , пройти співбесіду.

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

Riff Point

Напрям:стажування PHP/ Drupal.
Місто:Харків.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• Початківець developer з бажанням навчитися добре і якісно «кодувати»;
• З теоретичним бекграундом;
• Англійським не нижче intermediate.

Як потрапити: надіслати резюме на job@riffpoint.com з темою «Стажировка PHP / Drupal», виконати тестове завдання, пройти співбесіду.

Умови: стажування курирують фахівці рівня Seniors, Team Leads. Навчання триває від 1 до 3 місяців. Лекцій не буде, тільки практика і аналіз / виправлення помилок. Навчання побудовано на внутрішніх продуктах компанії.
Деталі: надсилайте запитання на пошту.

Zeus Electronics

Напрям:стажування Junior Sales manager.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів: cтуденти останніх курсів ВНЗ. Випускники ВНЗ.

Як потрапити:надіслати резюме на пошту aivchenko@zeuselectronics.eu.

Умови:повний робочий день.
Деталі:надсилайте запитання на пошту.

3Shape Ukraine

Напрям:робота С#.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• ІТ освіта (Computer science is a big plus);
• Досвід в розробці на C# 1+ рік (OOP, generics, linq, multithreading);
• Гарні знання OOD (design patterns, SOLID etc.);
• Гарні знання дискретної математики;
• Гарні знання основ системного аналізу;
• Розуміння методів розробки та аналізу алгоритмів;
• Вільна розмовна та письмова англійська;
• Гарні знання математики вітаються.

Як потрапити:надіслати СV англійською, пройти телефонне інтерв’ю, потім тестування та співбесіду.

Умови:повний робочий день.
Деталі:надсилайте запитання на recruit-ua@3shape.com.

Intetics

Напрям:робота розробником на функціональній мові та Robotic Process Automation (RPA).
Місто:Київ, Харків.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:
Функціональне програмування

• Досвід програмування на будь-якій мові;
• Аналітичний склад розуму;
• Англійська рівня Intermediate;

Robotic Process Automation

• Досвiд роботи з продуктами провiдних RPA вендорiв (UiPath, BluePrism, Automation Anywhere, WorkFusion та iншi);
• Обiзнанiсть в Microsoft технологiях (VB, .NET, Windows, Internet Explorer, SQL Server, Web Services, MS Office);
• Розуміння принципів кібербезпеки;
• Англійська рівня Intermediate.

Як потрапити: надiслати резюме, пройти спiвбесiду з рекрутером та менеджером проекту, виконати тестове завдання.
Деталі: на сайті.

Sombra

Напрям:робота Java, Front-End.
Місто:Львів.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

Java

• Хороше знання мови програмування Java;
• Англійська мова не нижче Intermediate low;
• Розглядатимуться кандидати тільки зі Львова і області;
• Профільна освіта — буде плюсом;
• Знання Java фреймворків Spring, Hibernate etc — буде плюсом;
• Наявність власних проектів — буде плюсом;

Front-End

• Гарне знання HTML5 та CSS3;
• Знання Javascript, JQuery, AJAX;
• Знання AngularJS буде плюсом;
• Важливим є здатність обирати та реалізовувати гарні компоненти UI, як з дизайнером, так і без нього;
• Знати та вміти застосовувати адаптивну верстку;
• Досвід роботи з Git та/або SVN;
• Англійська мова не нижче Intermediate.

Як потрапити:подати заявку, пройти співбесіду, виконати тестове завдання.

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

Цієї весни нам вдалося цілий день провести в центральному офісі Facebook в Менло-Парк (штат Каліфорнія, США). Але найважливіше, що екскурсію проводили двоє наших українських хлопців, котрі давно працюють в компанії. Немає більше сил тримати це в собі, тому на честь третього Дня народження проекту DOU Ревізорми вирішили показати вам штаб-квартиру найбільшої соціальної мережі у світі.

Нині Facebook входить до п’ятірки найбільш відвідуваних сайтів світу. Станом на червень 2017 року місячна аудиторія мережі складала 2 мільярдилюдей. Щодня понад 175 мільйонів людей діляться реакцією «Love — ❤», і в середньому понад 800 мільйонів лайкають («Like — 👍») щось на Facebook. Офіси компанії розкидані по всьому світу, їх зараз більше 45. Найбільші інженерні центри знаходяться в Менло-Парк (США), Сіетлі (США), Нью-Йорку (США), Бостоні (США), Лондоні (Велика Британія), Дубліні (Ірландія) і Тель-Авіві (Ізраїль).

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

До того як Facebook викупила територію колишнього бізнес-парку компанії Sun Microsystems, яку 2010 року поглинув Oracle, офіси соціальної мережі були розкидані по всьому Пало-Альто. Під час проектування нового офісу архітектори вирішили зберегти таку присутність міста в житті компанії. Тепер штаб-квартиру Facebook важко навіть назвати офісом. Вона більше схожа на окреме місто з власною інфраструктурою, де між корпусами курсують автобуси, на стінах рясніє стріт-арт, а на центральних вулицях — неймовірний вибір кав’ярень і перекусних.

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

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

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

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

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

Помітно, що під час облаштування приміщень було використано мінімальну кількість «інтер’єрних» матеріалів: видно бетон, фанеру, нічим не прикриті комунікації. Робочі зони в обох корпусах виконані в стилі open space (на жаль, нам не дозволили фотографувати робочі місця). До речі, Facebook встановила рекорд: open space компанії вважається найбільшим у світі. Марк Цукерберг відзначає, що прагнув створити робоче середовище з таким же духом спільності, комунікації між людьми, як і в самій соціальній мережі. Для цього й був створений «найбільший open space у світі — одна кімната для розміщення тисяч людей», — написав CEO у своєму постіпісля відкриття нового західного кампуса в 2015 році. Цікаво, що робоче місце самого Марка майже не відрізняється від інших, це не окремий кабінет.

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

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

➠ Стріт-арт

У штаб-квартирі Facebook співробітників усіляко заохочують до творчого самовираження. Коли був відкритий перший східний кампус, вони отримали балончики з фарбою — так з’явилися перші графіті на офісних стінах. Для створення малюнків у новому західному кампусі запросили художників з різних куточків земної кулі. Напевно, найбільш яскравий і незвичайний — це робота бруклінської художниці українського походження Майї Гаюк. Її роботи нагадують геометричні орнаменти на традиційних українських ремісничих виробах.

➠ Кав’ярні, перекусні та ресторани

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

➠ Інфраструктура внутрішнього міста

Увесь простір нагадує вулиці міста з пожвавленим рухом. Тут є майстерня для ремонту велосипедів, столярна майстерня, поліграфічний центр, де можна просто так взяти яскравий плакат або власноруч зробити магніт напам’ять. На території штаб-квартири навіть є власний сувенірний магазин, де за $40 можна купити собі худі або за $10 — пляшку для води з логотипом Facebook. На даху західного кампуса створили парк площею 36 тис. м2, звідки відкривається вид на затоку. Тут є місця як для прогулянок, так і для роботи. До того ж, коли ходиш парком, заледве усвідомлюєш, що знаходишся на даху будівлі.

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

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

Юрій Брунець, останні три роки працює в команді Facebook і в даний момент розробляє Facebook News Feed:

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

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

Остап Коркуна, програміст у відділі інфраструктури компанії Facebook з 2009 року:

«Що найбільше подобається в офісі? Насправді важко виділити якусь одну річ. Коли приводжу друзів в гості показати офіс, у них емоції, як від „Діснейленду“. Але для мене офіс в першу чергу — це місце роботи. І в ньому найважливіше для мене все те, що допомагає ефективно витрачати свій робочий час. Наприклад, велика кількість кафе на кампусі дозволяє не витрачати час на роздуми, де поїсти. Різноманітність кухонь завжди дозволяє знайти страви до вподоби і повернутися до роботи ситим і в хорошому настрої. Ігрову кімнату відвідую лише тоді, коли приводжу гостей. Але от лаундж-зони з великими телевізорами використовували з колегами не раз для перегляду футбольних матчів. Дуже подобається наявність різних неформальних робочих (і не дуже) зон як в приміщенні, так і на вулиці — часто надаю їм перевагу перед своїм робочим столом. Зміна обстановки добре стимулює роботу мозку. Ну і загалом подобається все, що спрощує чи оптимізує робочі процеси в офісі: від автоматів з дрібною електронікою (клавіатури, миші, кабелі) до мостів, які з’єднують сусідні будівлі і дозволяють швидко пересуватися між ними.

Що б хотілося покращити або змінити? Чесно, жалітися на умови роботи важко. Але водночас працівники постійно змінюють простір навколо себе. У нас це називається „space hack“ — коли береш і якось видозмінюєш, прикрашаєш робочий простір. Починаючи з муралів на стіні і закінчуючи лаундж-зоною для команди — компанія вітає ініціативи, які роблять робочий простір комфортнішим для працівників. Саме через це люблю той кампус, в якому працюю: він переповнений артефактами та історією, створеною самими працівниками, інженерами. Якщо ж у когось є конструктивні пропозиції щодо вдосконалення і покращення офісу, їм є куди звернутися. Команда Facilities з радістю приймає відгуки і побажання. Тому не можу сказати, що є щось таке, що хотілося б змінити, але незрозуміло як, адже завжди є можливості для здійснення змін».

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

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

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

Дивіться закулісні кадри того, що не проходить цензуру, в Instagram — instagram.com/dourevisor

Підписуйтесь на відеоканал DOU Ревізор на YouTube — www.youtube.com/...​/UCYyiAq3Bn1w1V5T7y0f-Uzw

[DOU Hobby — рубрика о нетехнических проектах IT-специалистов: творчество, интересное хобби и другие lifestyle-достижения. Если вам есть о чем рассказать — пишите на valentina@dou.ua]

Женя Пак, системный администратор в компании Sigma Software, уже 3 года занимается кардистри — это артистичное манипулирование картами. В Жениных руках карты оживают, выстраиваются в невероятные фигуры, появляются и исчезают, как по волшебству.

— Женя, как вы заинтересовались кардистри?

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

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

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

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

Публикация от Eugene Park (@k1rbis)Июн 21 2017 в 6:27 PDT

— Чем кардистри отличается от карточных фокусов?

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

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

— Помимо карт, занимаетесь фокусами с другим инвентарем?

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

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

— Как вы обучались мастерству кардистри?

В интернете очень много информации: есть обучающие книги, видео. Некоторые движения просто видел и пытался повторить. Иногда разбирал видео по кадрам.
Более серьезно заниматься кардистри я начал где-то 2-2,5года назад. С тех пор значительно продвинулся вперёд.

— Сколько времени уделяете увлечению, тренировкам?

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

Упражняюсь в автобусе и метро, пока еду на работу или с работы. На работе, когда руки (или даже одна рука) свободны. Дома, когда читаю или смотрю фильмы. А еще друзья часто просят показать что-нибудь при встрече.

Думаю, держу карты в руках в среднем часа четыре в сутки.

Так тренируются кардисты :)

— Сколько колод у вас в коллекции?

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

— Кардистри как-то помогает в работе? Какие-то навыки оказываются полезными?

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

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

— Насколько кардистри распространено в Украине и в мире? Есть какие-то сообщества, чемпионаты?

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

Харьковские кардисты и фокусники

Чемпионаты по кардистри​ проходят каждый год. Совсем недавно закончился Cardistry-Con в Лос-Анджелесе. Я с удовольствием наблюдал за этим событием. Когда видишь выступления чемпионов — сам вдохновляешься.

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

Маленький видеоотчет с Cardistry-Con

— Что можете посоветовать новичкам? С чего начинать? Что важно?

Я сам себя еще новичком считаю! :) Наверное, начинать нужно с копирования, а после того, как наберешься опыта, творить что-то своё.

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

— Какие у вас планы на будущее? Планируете ли где-то выступать?

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

Выступать пока не планирую. Для меня это всё просто хобби. Не хочу, чтобы это перерастало в работу. Компьютеры я все же люблю больше, чем карты :)

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

Чтобы ответить на популярные вопросы начинающих программистов о том, стоит ли учить такой-то язык и связывать с ним карьеру, мы задали разработчикам на Java, JavaScript, PHP, C#, C++, Python и Swift/Objective-C три вопроса:

1. Посоветовали ли бы вы новичкам начать изучение программирования с вашего языка?
2. Насколько сейчас востребован этот язык? Легко ли найти работу?
3. Какие он имеет перспективы? Будут ли расти количество вакансий и зарплаты?

Ниже представляем их ответы.

Дмитрий Думанский — про Java

[Дмитрий Думанский — Co-Founder в Blynk, колумнистна DOU]

1) Java идеально подходит как первый язык в связи с большим количеством вакансий и культурой кодописания вокруг этого языка: я имею в виду build tools, continuous integration, style checkings и т. д.

2)Из того, что я сейчас наблюдаю: интерес к Java ослабевает в связи с появлением новых, простых и удобных инструментов на любой вкус и под любую задачу. Условно говоря, любой язык, в котором проще запустить «Hello, World!», чем в Java, имеет определенные шансы.

Я бы выделил 4 языка, на которые переходят с Java.

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

Во-вторых, все так же активно развивается и набирает популярность NodeJS, особенно за счет full-stack разработчиков. Когда пишешь много UI, довольно логично писать и Back-end на JavaScript.

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

И, наконец, Scala, судя по всему, вышла на плато и будет по чуть-чуть сдавать позиции Kotlin. Хотя ядро из функциональщиков будет поддерживать в ней жизнь еще довольно долго.

Если бы мне пришлось выбирать сейчас, то вместо Java я бы сделал ставку на Go (так как мне нравится его простота) или NodeJs (так как это JavaScript, который есть на всех проектах так или иначе). У Kotlin мало шансов стать мейнстримом, так как рано или поздно, через 3-5 лет,в Java перекочуют все его фичи: некоторые уже в todo-листе 10-йверсии. Тем более, что после релиза 9-кицикл мажорных релизов в Java должен сократиться.

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

3) Java на сегодняшний день все еще язык номер один. Это значит, что если Java завтра умрет, то даже через 30 лет будет огромное количество проектов, которые будут требовать доработки, улучшений и даже багфиксов. Так что, если вас волнует пенсия, Java — ваш выбор :)

Александр Литвиненко — про JavaScript

[Александр Литвиненко — Full-stack Web Developer, Team Lead в Pro Code, преподаватель курсов Pro Code]

1)Что касается обучения, требования к новичкам повысились за последнее время. Учить JavaScript стоит — это по-прежнему самая легкодоступная область веб-программирования для новичков. Однако на голой теории уже трудоустроиться не выйдет.

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

Почему? Сам по себе React — не фреймворк, а просто очень хороший шаблонизатор. Настолько хороший, что его можно применять и в ванильном коде без каких-либо библиотек, но так делают редко. В любом случае вам понадобятся некоторые вещи для работы с поставщиками данных — это то, что в Angular зовется provider, factory и service. Потому React соединяют с библиотекой, дающей такие возможности (например, Redux).

2)Сейчас React используется чаще других. У React больше, чем у Angular, звезд на GitHub (70 против 56 — это говорит о личном отношении разработчиков к продукту), больше скачиваний на сайте пакетного менеджера npm (4,8 млнпротив 950 тыс. за последний месяц).

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

В данный момент в Украине количество вакансий Angular и React примерно одинаково.

3)Если говорить о перспективах JavaScript, нельзя не упомянуть о Node.js. Технология появилась в 2009 году благодаря Райану Далу. Спустя 3 года о Node знали все, это очень повысило популярность и спрос на JavaScript. Начали появляться новые библиотеки, фреймворки, вышло 2 новых стандарта ES5 и ES6. Сейчас на Node делают все: от мобильных приложений до редакторов кода для программистов. Хороший пример — известный редактор Atom.io.

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

Юрій Савка — про PHP

[Юрій Савка — Senior Software Engineer в ResearchGate GmbH, колумністна DOU]

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

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

PHP в цьому сенсі трохи відлякує переліком побічних технологій, які доведеться тягнути (в основному SQL, CSS і JavaScript), але в той же час приваблює набором готових рішень на кшталт WordPress, які можна видати за програмування і таким чином заробити першу копійку. Є в цьому і свої недоліки: захопившись легкими грошима можна втратити мотивацію розвиватися і залишитися на рівні «вебмайстра» назавжди. Але, зрештою, навіть «вебмайстер», думаю, краще, ніж «менеджер із продажів, який вміє вивести „Hello, World!“ на Java».

2)Вакансій не просто багато — їх навалом. Єдине, що якість проектів, особливо на аутсорсі, залишає бажати кращого.

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

Посередині — студії веб-дизайну «Тяп-ляп і в продакшн», древні CMS на глиняних костилях десятирічного сапорту, інтернет-магазини, банерні мережі. Навіть, збав Боже, Бітрікс! Якщо не проскочити свій період мідлування десь у відносно безпечній конторці, лишається два шляхи: або міняти мову і йти з нуля на Java, Python чи всілякі новомодні Go, або відключати мозок і проводити шість із восьми годин за приставкою і настільним тенісом.

Якщо ж перетерпіти і додати собі скілів у паралельних секторах, тут уже починаються золоті роки. Можна влаштуватися архітектором і ганяти бідних джунів, попиваючи чай, можна влаштуватися у стартап, які на 90 % починають на PHP, бо MVP через місяць, а не за рік, як у джавістів. Можна релокейтнутися у Європу: німці тягнуть більше PHP-програмістів, ніж будь-кого іншого. Та що там, можна і в ААА-компанії подаватися, там зазвичай індиферентні до мов і технологій, якими користувався, а важливо, щоб системний дизайн був на рівні. Головне, не застрягнути на забутому богом проекті за чотири штуки і личку тімліда. Але це ж не тільки для PHP вірно, чи не так?

3)В Україну загальносвітові тенденції доходять трохи пізніше, коли стартапи починають віддавати своє легасі на аутсорс. Враховуючи бум на Symphony серед теперішніх стартапів, недостачі в проектах чекати не доведеться. Java-сервлети, ASP.NET, навіть Ruby/Rails давно і безповоротно мертві, бекендівський JavaScript лишається вузьконішевою забавкою для обраних, тому нові сайти в абсолютній більшості будуть писатися на PHP.

Після виходу сімки стало зрозуміло, що PHP — чи не єдина мова, яка рухається в адекватному напрямку, і поки що тенденції доста оптимістичні. Шаленими кроками рухається екосистема Symphony, на хвості вперто сидить Laravel. Drupal і Zend радше мертві, ніж живі, але я би не списував старичків із рахунків. Це вам не Ruby, де окрім Rails — випалений ліс, і перші проблеми фреймворка практично викосили усю екосистему.

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

Андрей Губский — про C#

[Андрей Губский — CTO в Торф ТВ, автор статейна DOU]

1)Безусловно, я бы посоветовал новичкам изучать C#. На мой взгляд, это идеально сбалансированный ООП язык, который позволяет достаточно легко начать с ним работать, используя простые и лаконичные конструкции в начале, и в будущем постепенно перейти к таким мощным инструментам, как Linq и лямбда-выражения.

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

В этом плане у C# есть ряд преимуществ:

• Это строго типизированный язык, что означает, что программисту, который начинает свое обучение на этом языке, гораздо проще понять, что такое тип данных и какие типы данных бывают. Это выгодно отличает его от Python и JavaScript.
• Это .NET-язык, что означает, что программист будет работать в рамках управляемой среды CLR, и ему не придется работать с выделением памяти и освобождением памяти. Он сможет сосредоточиться непосредственно над решением алгоритмических и бизнес-задач, не отвлекаясь на поиск причин утечек памяти и внезапных исключений.
• Это С-подобный язык (что очевидно уже из его названия). Его синтаксис гораздо изящнее и лаконичнее Pascal, который долгое время был основным языком, использующимся для обучения программированию. При этом человек, знакомый с одним С-подобным языком, с легкостью сможет понимать и читать код других языков этого семейства.

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

При этом очень важно понимать, что сферы применения этого языка очень широки:

• разработка REST API и веб-сервисов — ASP.NET MVC, ASP.NET Web API;
• разработка игр — Unity;
• разработка мобильных приложений — Xamarin;
• разработка десктопных приложений — WPF, Windows Forms;
• разработка кроссплатформенных приложений и сервисов — .NET Core, Mono;
• разработка облачных сервисов — под C# имеются SDK от всех крупных облачных платформ;
• разработка хранимых процедур для SQL Server.

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

Грамотный специалист может найти работу где-то за неделю-две.

3)С учётом того, что Microsoft активно развивает платформу .NET Core, я думаю, что в ближайшее время увеличится количество вакансий именно в этом направлении. Рынок же по классической версии .NET уже сформирован, и каких-то глобальных изменений на нем, скорее всего, в ближайшее время происходить не будет. Большого роста или падения зарплат ожидать не стоит. Но не следует забывать также и то, что С# входит в десятку самых «высокооплачиваемых» языков программирования. В целом же можно с уверенность сказать, что этот язык успешно завоевал себе крепкие позиции на годы вперед и перспективы у него исключительно позитивные.

Ростислав Дзинько — про C++

[Ростислав Дзинько — Technical Director в Frag Lab, автор C++ дайджестівна DOU]

1)Якщо говорити саме про C++, то як першу мову його можна порадити у випадку, коли метою є відбити будь-яке бажання вчитися програмування.

А якщо серйозно, то тут я б розділив цільову аудиторію на дві великі групи:

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

В першому випадку, на мою думку, варто починати з чистого С і завершувати на С++.

Що стосується самонавчання, тут часто на передній план виходить проблема мотивації. Людина зазвичай, чимось займаючись, хоче якомога швидше побачити реальні результати своєї роботи, а цього набагато легше досягнути на C#, Python чи JavaScript, ніж на C++. На своєму невеликому досвіді викладання C та C++ в КПІ прийшов до того, щоб пропонувати виконання лабораторних робіт у вигляді класичних 2D-ігор на базі фреймворка Qt 5. Такий підхід дещо згладжує цю проблему, проте повністю не вирішує.

Зрештою, своїм студентам я мотивую вивчення C++ як знання uber-мови програмування, після якої значно легше освоїти будь-яку іншу мову чи технологію.

2)Якщо відкрити розділ «Робота»на DOU, бачимо, що проблем з вакансіями, де основною вимогою є знання C++, немає. Єдине, що зазвичай на C++ легше знайти роботу досвідченим спеціалістам, ніж молодшим. І тим більше складно знайти першу роботу на C++. Якщо провідні IT-компанії пропонують безліч курсів на Java, C#, PHP, JavaScript, то з C++ тут тугіше, рівно як і вакансій для Junior.

3)Перспективи C++ я оцінюю в розрізі історії цієї мови програмування. У 80-хроках C++ був фактично єдиною популярною мовою програмування, займаючи істотну частку практично у всіх предметних областях. З часом з’являлись мови, які відбирали свої ніші: наприклад, Java та C# практично повністю поглинули корпоративний сектор, а PHP, Python та Ruby — web.

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

Що ж до кількості вакансій, думаю, що вона буде змінюватись рівненько разом зі зміною розміру ринку, але навряд чи буде якийсь значимий ріст чи падіння, пов’язані з іншими факторами. В той же час зарплати на C++ проектах сильно залежать від предметних сфер (які досить різняться за специфікою і вимогами), тут я б не став прив’язуватись саме до C++ як мови. Наприклад, С++ спеціалісти в VR/AR коштуватимуть дорожче, ніж розробники інтерфейсів прикладних програм і т. д.

Илья Батозский — про Python

[Илья Батозский — Python developer в CHI Software, автор статьина DOU]

1)Понимаю, что каждый разработчик хвалит свой язык программирования, но, тем не менее, постараюсь быть максимально объективным в оценках и суждениях. Итак, стоит ли новичкам изучать Python и подходит ли он для первого языка? Однозначно да, на оба вопроса. И тут я основываюсь не на теоретических догадках, а на практическом опыте. Достаточно долгое время я работал в школе и там проводил, скажем так, эксперименты с разными языками программирования и могу с уверенностью сказать, что Python в этом вопросе показал себя очень хорошо. Старшеклассники осваивали его легко: гораздо быстрее, чем Javascript и, не к ночи будет упомянуто, Pascal.

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

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

2)На данный момент Python более чем востребован. Если посмотреть любые исследования на GitHub, StackOverflow etc, то вы всегда найдете его в первых строчках рейтинга популярности. И эта популярность продолжает расти. Если обратиться все к тем же исследования, то Python один из немногих языков программирования, который не снижает темпов роста популярности за последние годы.

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

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

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

Так что я вижу все предпосылки к тому, что запросов на Python-разработчиков будет становиться все больше. А если обратиться к законам экономики: когда спрос растет быстрее, чем предложение, то цены тоже растут. Значит, и зарплаты не будут стоять на месте.

Дмитро Скороход — про Objective-C та Swift

[Дмитро Скороход — iOS Developer в Perfectial, автор iOS дайджестів та статейна DOU]

1)Програмування під техніку Apple включає, по-перше, розробку Desktop-аплікацій під macOS, по-друге, розробку під iOS, watchOS (годинник Apple Watch) та tvOS (приставка Apple TV). Нативними є дві мови програмування — Swift та Objective-C. Більшість вакансій вимагає знати саме їх, хоча під Apple можна розробляти й з використанням інших мов.

Я раджу новачкам починати з мови програмування Swift. Вона є інтуїтивно зрозумілою та перспективною. Swift існує усього 3 роки, але вже встигобігнати Objective-C за використанням в якості основної мови.

2)Попит на програмістів macOS та iOS стабільно високий, адже техніка Apple має віддану та забезпечену аудиторію. Крім того, власники пристроїв Apple частіше платять за аплікації, ніж користувачі інших ОС.

Дороговизна техніки є вхідним бар’єром, що захищає програмістів під Apple від напливу конкурентів. Саме тому зарплати iOS розробників на 10-20 %вищекомпенсацій їхніх колег, що програмують під Android. Однак той, хто дуже хоче, може стартувати, і не маючи техніки Apple. Я знаю розробника, що починав з віртуалки, а тепер став CTO в стартапі.

3)Як правило, на Swift пишуть нові проекти, а Objective-C використовується у підтримці старих. Хоча є виключення: деякі замовники досі просять робити нові проекти на Objective-C. Це пов’язано з тим, що щороку виходить нова версія Swift, і необхідно виділяти додаткові ресурси на оновлення проектів. Не всіх це влаштовує.

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

Зарплати Objective-C розробників наразі дещо перевищують зарплати їхніх колег, що пишуть на Swift. Це пов’язано з тим, що успішні старі проекти мають більше грошей, ніж нові стартапи. А також із тим, що в Swift більше новачків. Однак мова іде про різницю в $100-200, це не аргумент проти старту саме зі Swift.

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

Розповім трішки про себе. З 2004 року я почав працювати у сфері освіти в IT, ще будучи студентом Львівської політехніки. Я почав із викладання апаратного забезпечення та адміністрування операційних систем, тому що зрозумів, що викладання закріплює знання швидше, ніж навчання у виші. Зараз я Senior Test Engineer, консультант GlobalLogic, директор Tech School у LITS, і загалом я маю понад 12 років досвіду у комерційних проектах.

То з чого все ж таки почати?

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

Обираєте роль програміста?

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

Вибір мов програмування загалом залежить від ваших уподобань. Якщо ви навчаєтеся на спеціальності «Комп’ютерна інженерія», або на чомусь схожому, скоріш за все ви вивчаєте C чи C++. Це хороший початок, хоч вам може здаватися, що ці мови складніші для вивчення, ніж інші. Однак, якщо ви будете знати на хорошому рівні хоча би одну із них, вам буде значно легше опанувати й інші. Та й можливості ваші будуть доволі широкими: C++, для прикладу, застосовується в написанні коду як для Linux, так і для Windows. Лабораторних у виші буде недостатньо, щоб опанувати цю мову на хорошому для практичного застосування рівні. Спробуйте порозв’язувати усі завдання з того джерела літератури, яке ви використовуєте, знайдіть додаткову літературу, безкоштовні онлайн-курси тощо.

Давайте коротко розглянемо ще декілька мов, які наразі не менш популярні (у контексті великої кількості вакансій), наприклад .NET і Java. Вивчаючи ці мови, потрібно детально ознайомитися з їхніми бібліотеками та використанням цих бібліотек. Java-програміст повинен добре володіти загальними принципами роботи родини операційних систем Linux. Також йому необхідні навички використання таких наборів готового функціоналу (фреймворків), як Spring та Hibernate. Для опанування ж .NET слід ґрунтовно ознайомитись із технологіями Microsoft та особливостями роботи родини операційних систем Windows. Зовсім не зайвим стане паралельне вивчення C#, ASP тощо.

Якщо хочете рухатися у популярному зараз напрямку веб-розробки (створення веб-сайтів), тут є декілька варіантів. Найчастіше зустрічаються такі типи веб-розробки, як front-end, back-end і full stack. Front-end (фронтенд) — це розробка візуальної частини сайту; це те, що ми бачимо, зайшовши на будь-який сайт. Цю частину іще часто називають клієнтською. Back-end (бекенд) розробка залишається «за лаштунками» візуальної частини. Код бекенду розміщений на сервері і відповідає за відправлення правильних даних у браузер для відображення на сайті. А full stack (фулстек) розробка об’єднує два описані вище типи, тобто фулстек-програміст має вміти писати код як фронтенду, так і бекенду.

Як ви вже могли здогадатися, мови програмування на фронтенді та бекенді — різні. Розробка фронтенду здійснюється на мовах, які живуть у браузері — HTML, CSS і JavaScript. Перші дві дуже прості, і про них можна знайти вдосталь інформації в інтернеті. А почати вивчати JavaScript, наприклад, можна з книги Девіда Фленегана (David Flanagan «JavaScript: The Definitive Guide»), розв’язуючи усі зазначені там практичні завдання. Також для того, щоб стати фронтендщиком, потрібно мати розуміння фреймворків (Bootstrap, Foundation, Backbone.js, AngularJS, EmberJS) та JS-бібліотек (jQuery and LESS).

Для бекенду потрібно знати якусь із серверних мов (а то і декілька): PHP, Ruby, Python, Java або .Net, а також вміти використовувати такі системи, як MySQL, Oracle та SQL Server для знаходження, зберігання, зміни даних, які потім відправляються у фронтенд. Ви також повинні на глибокому рівні розуміти, як працює браузер та як відлагодити (debug) код у консолі розробника. Загалом, дуже важливо постійно навчатись, цікавитися різними технологіями, новинками і пробувати їх застосовувати на практиці. Веб не стоїть на місці і існуючі фреймворки оновлюються раз на декілька місяців. Не менш часто можна зіткнутися і з появою нових фреймворків, які не слід боятися застосовувати. Знання нових методик може показати вас із вигідного боку.

А для загального розвитку кожному розробнику я рекомендую почитати книгу Стіва Макконнела (Steve McConnell «Code Complete»).

Віддаєте перевагу тестуванню?

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

Можна стати інженером, що проводить тестування вручну (Manual QA Engineer, скорочено: QA Engineer чи просто QA) або інженером, що автоматизує тестувальний процес — тестувальником-автоматизатором (QA Automation Engineer, Automation QA). Це означає, що він пише скрипт-код для тестів, які автоматично будуть перевіряти програму швидше, ніж людина.

Що саме потрібно знати та вміти, щоб стати Manual QA Engineer? Насамперед, потрібно мати ґрунтовну теоретичну базу технічних знань. До технічних знань відносять розуміння циклу розробки програмного забезпечення, видів та рівнів тестування, знання основних інструментів тестування. Тим, хто починає вчитися на інженера з якості, раджу почитати книгу С. Мюллера «Модернізація і ремонт ПК» (Scott Mueller «Upgrading and Repairing PCs») та Н. Оліфер і В. Оліфера «Комп’ютерні мережі» (Natalia Olifer, Victor Olifer «Computer Networks: Principles, Technologies and Protocols for Network Design»).

QA Automation Engineer — це вже наступна стадія професійного зростання. Крім навичок ручного тестування, QA Automation Engineer повинен володіти базовими навичками програмування на одній або декількох мовах (Python, JavaScript тощо). Зараз сфера автоматизованого тестування стрімко розвивається, тому це перспективний напрямок для QA-спеціаліста.

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

Що потрібно, щоб спеціалізуватися у певному напрямку?

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

Програмування вбудованих пристроїв (embedded) — до прикладу, медичних апаратів, спортивного спорядження тощо;
Для початку тут підійде знання C/C++, загальне знання апаратного забезпечення та операційних систем.

Розробка програмного забезпечення для носимих пристроїв (wearables) — розумних годинників, фітнес-браслетів тощо;
Тут потрібні ті ж знання, що і для embedded-розробки, але додатково слід розібратися і в апаратному забезпеченні для носимих пристроїв.

Розробка мобільних веб-додатків (applications) для таких операційних систем, як iOS, Android, Windows etc.
Для того, щоб почати розробляти iOS-додатки, потрібно вміти писати код на мові Objective-C або ще краще — на Swift. Для розробки Android-додатків потрібно володіти Java, рідше — C/C++. Для Windows — C#, .NET.

Розробка програм для настільних персональних комп’ютерів — у цій сфері знадобляться знання C/C++, Python, Java (залежно від операційної системи), загальне розуміння структури операційних систем, основи знань про мережі.

Проекти зі сфери «Інтернету речей» (IoT = Internet of Things) — такі проекти передбачають тісну взаємодію між пристроями. Концепція «розумного будинку» є яскравим прикладом «Інтернету речей». Тут крім володіння мовами програмування потрібні ще базові знання мереж та їхнього апаратного забезпечення, розуміння мережевих моделей і мережевих протоколів.

А які перспективи спеціаліста у компанії?

Програміст чи тестувальник-початківець без практичного досвіду розпочинає свій шлях у компанії з позиції початкового рівня — це може бути роль Trainee (так вона називається у GlobalLogic, наприклад) або Intern. На цій позиції початківець перебуває від трьох місяців до року. За цей час майбутній спеціаліст із допомогою ментора та HR-консультанта адаптується до компанії, своєї ролі у ній, багато вчиться і здобуває досвід та необхідні навички для переходу на вищий рівень. Далі рух кар’єрними сходинками виглядає приблизно так:

Junior — Middle — Senior — Lead

Рівень Middle може мати назву Intermediate або Medior, а Lead — Leader.

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

У спеціаліста на позиції Lead з’являється можливість рухатися у бік технічної експертизи — бути Technical Lead (і стати Area Expert або Architect) або у бік менеджменту — бути Team Lead (і згодом обійняти посади Project Manager чи Delivery Manager).

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

Що ще я маю знати?

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

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

Об авторе: Ларс Курт — увлеченный менеджер сообщества Xen с длинной историей сотрудничества с open-source-сообществами, такими как Symbian, Symbian DevCo, Eclipse и GNU. Он имеет девятилетний опыт работы по построению и управлению инженерными командами, а также 16-летнийопыт работы в сфере вспомогательных программных средств и мобильных телефонов в компаниях ARM, Symbian Ltd., Symbian Foundation и Nokia.

Эту статью Ларс подготовил на основе своего выступления на Root Linux Conference 2017 — ежегодной конференции embedded- и Linux-разработчиков.

Автор перевода: Юрий Коноваленко, Associate Manager, GlobalLogic.

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

Зачем нужна виртуализация?

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

Облако/серверы

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

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

Приложения для обеспечения безопасности

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

1. Таблицы грантовуправляют доступом к памяти, которая выделена для каждой VM, а также позволяют контролировать распределение памяти между виртуальными машинами, создавая более надежную границу безопасности вокруг них и делая невозможным переход эксплойтов с одной виртуальной машины на другую.
2. Дезагрегирование Xenпозволяет вам изолировать определенные основные функции гипервизора в отдельной виртуальной машине (мы почти всегда используем VM как процессы, в качестве следующего уровня изоляции). Особый вариант использования — это так называемый «Secure I/O», который позволяет запускать отдельные драйверы устройств на виртуальных машинах.
3. Функция самодиагностики виртуальной машины (VMI), которая является эксклюзивной для Xen, обнаруживает новые классы угроз безопасности системы и уже используется в ряде различных коммерческих продуктов.

Встраиваемые системы / автомобилестроение

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

Примечание о схожести сценариев использования виртуализации в разных областях

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

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

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

Что отличает гипервизор Xen Project?

В традиционном гипервизоре типа 1 драйверы устройств встроены в сам гипервизор. В Xen существует специальная VM под названием Dom0, которая запускает ядро Dom0 и позволяет Xen по умолчанию использовать драйверы устройств ядра Dom0. Вот пример того, как работает эта модель:

1. VM1 обращается к внешнему драйверу.
2. Внешний драйвер обращается ко внутреннему драйверу в Dom0 через протокол PV.
3. Внутренний драйвер обращается к драйверу исходного устройства в Linux или другой ОС, поддерживающей Dom0.
4. Затем драйвер исходного устройства уже обращается к самому аппаратному оборудованию.

Предположим, мы рассматриваем сетевой трафик: тогда VM1 будет обращаться к фронтенду виртуального драйвера сети (netfront driver), который, в свою очередь, обращается к бэкенду виртуального драйвера сети (netback driver), который уже обращается к исходному сетевому драйверу (native driver). (Это также называется паравиртуализацией). И, конечно же, вся модель повторяется на нескольких разных виртуальных машинах. Кроме того, Dom0 также является вашим интерфейсом во внешний мир: так называемый компонент Toolstack позволяет вам управлять всей системой.

Рисунок 2.Гипервизор Xen типа 1 стоит поверх аппаратного обеспечения, а Dom0 VM позволяет Xen использовать исходные драйверы устройств ядра Dom0

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

Варианты использования: облако/серверы

Еще в конце 2014 — начале 2015 года две уязвимости в Xen привели к тому, что Amazon перезапустил 10 % своего облака. Важно отметить, что ни одна часть облака во время облачной перезагрузки не подверглась атаке уязвимости нулевого дня, поскольку провайдеры облачных вычислений устранили основные проблемы Xen до того, как информация стала общедоступной. Однако это был важный урок, который мы выучили, и он заключался в том, что допускать причинение неудобств пользователям облачных вычислений по причине перезагрузки просто неприемлемо.

Поэтому вместе с Amazon, Alibaba, Citrix, Oracle, SUSE мы разработали решение, которое позволило нам патчить гипервизор во время его работы, чтобы избежать перезагрузки Xen после применения исправлений к любым уязвимостям. Подход к этому новому решению патчинга на лету (Live Patching) заключался в разработке инфраструктуры гипервизора, которая бы позволяла нам загружать бинарный код (то есть обновление), который бы заменял существующий код с гранулярностью в функции гипервизора. Мы также разработали инструменты для создания обновлений и инструменты для применения и удаления обновлений, а также перечень тех обновлений, которые были применены в прошлом.

Чтобы создать новое обновление, вам нужно иметь информацию о базовой структуре Xen с уникальным идентификатором сборки. Это важно, поскольку двоичные файлы Xen зависят от исходного кода, параметров компиляции и точной версии компилятора, используемых для его создания. Если вы хотите использовать патчинг на лету, вам нужно сохранить полную базовую структуру Xen, чтобы вы могли создавать обновления в будущем. Чтобы сделать это, примените патч к своей базовой структуре и используйте инструменты Live Patch для создания обновления. Затем вы можете применить обновление с помощью инструментов командной строки Xen. Обратите внимание, что обновления могут быть накопительными. Вы можете применить несколько обновлений. Вы также можете удалить ранее примененные обновления.

Мы смогли реализовать Live Patching всего за девять месяцев благодаря тесному сотрудничеству многих компаний. Эта функциональность была выпущена в коммерческом продукте всего шесть месяцев спустя, и сегодня Amazon, Rackspace и другие облачные провайдеры — все используют Live Patching.

Дополнительные ресурсы

• xenbits.xen.org/docs/unstable/misc/livepatch.html
• wiki.xenproject.org/wiki/LivePatch
• bit.do/live-patch-detailed-pptbit.do/live-patch-detailed-video
• bit.do/live-patch-short-pptbit.do/live-patch-short-video

Xen в контексте безопасности

Если вы погуглите «Xen», то обнаружите, что каждый второй результат поиска связан с уязвимостями Xen. Вы не увидите подобного количества негативного освещения в средствах массовой информации по KVM или VMware, что может натолкнуть вас на мысль о том, что Xen не очень безопасен. Однако подобные отзывы о Xen на самом деле свидетельствуют об обратном, ведь большие облачные сервисы, такие как Amazon, Alibaba, Tencent и SoftLayer, продолжают использовать Xen, в то время как другие гипервизоры остаются в стороне.

Учитывая вышесказанное, давайте рассмотрим некоторые точные данные об уязвимостях. На рисунке 3 вы можете видеть количество уязвимостей для Xen, Linux и QEMU (как прокси для KVM). В 2015 году мы столкнулись с большим количеством уязвимостей Xen — прямым следствием упомянутого ранее перезапуска облака (Cloud Reboot), и это побудило многих небезразличных к безопасности активно искать ошибки в Xen.

Рисунок 3.Сравнение количества уязвимостей, обнаруженных в Xen, Linux Kernel и QEMU (как прокси для KVM)

Интересно, что тенденция по Xen идет вразрезс тенденциями по Linux и QEMU. За последние два года количество уязвимостей Linux и QEMU действительно растет, а количество уязвимостей Xen остается стабильным или уменьшается. Рассматривая это в контексте встроенных систем, в котором Xen на ARM является самой важной платформой, вы заметите, что у Xen на ARM очень мало проблем с безопасностью. В 2016 году только 2 из 33 уязвимостей повлияли на Xen на ARM. Годом ранее было около шести. Большая часть упоминаний об уязвимостях Xen в средствах массовой информации касается исключительно Xen на x86.

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

Важно отметить, что программное обеспечение всегда будет иметь уязвимости. Независимо от того, сколько раз вы тестируете или сколько проверок кода вы выполняете, уязвимости всегда будут. Поэтому важно иметь процедуру, которая бы позволяла пользователям Xen устранять уязвимости, прежде чем они станут общеизвестными. Это делается с помощью процесса контроля уязвимостей. Давайте рассмотрим процесс устранения уязвимостей Xen в сравнении с OpenStack, Linux Kernel, QEMU и Jailhouse (рис. 4).

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

Синие столбцы

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

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

Зеленые столбцы

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

В этом разделе рассматривается одно из ключевых различий между Xen и Linux или QEMU: каждый, у кого есть продукт или услуга, построенная на Xen, будет проинформирован об уязвимости до того, как она станет общедоступной. Это значит, что они могут немедленно патчить свои системы или продукты. Поскольку Linux и QEMU раскрывают информацию по безопасности исключительно пользователям из списка дистрибутива Openwall, только очень небольшое число потребителей (обычно пользователи дистрибутивов Linux) получают привилегированную информацию, связанную с уязвимостями. Конечно, это также означает, что Xen Project должен бороться с уязвимостями, в том числе Linux и QEMU, в случае, если это влияет на наших пользователей. Если бы мы этого не делали, в зоне риска перед уязвимостью нулевого дня оказались бы некоторые из наших крупных пользователей, потому что мы бы не имели права информировать их об уязвимостях в частном порядке.

Текущая разработка

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

Самодиагностика виртуальной машины (Virtual Machine Introspection)

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

История

VMI была впервые разработана и интегрирована в Xen в 2007 году, а LibVMI позже была построена поверх нее как абстракция интерфейса. В то время считалось, что VMI слишком подвержена вмешательствам для того, чтобы использовать ее в коммерческих целях, но затем в 2014-2015годах ее развитие возобновилось. Дело было в том, что Intel добавила аппаратную поддержку, которая сделала VMI достаточно эффективной, чтобы использоваться в облачных вычислениях. С тех пор участники сообщества Xen начали активно сотрудничать с целью улучшить VMI, включая переработку всей подсистемы, чтобы она могла быть использована в коммерческих целях.

Как работает VMI

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

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

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

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

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

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

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

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

Коммерческие приложения

• Решение VMI от Bitdefender: известное решение VMI, которое сразу же внедряет исправление в зараженную виртуальную машину, удаляет угрозу и очищает систему, а также предоставляет консоль, для того, чтобы системный администратор мог видеть, какие атаки произошли и как были устранены проблемы.
• Решение VMI для Zentific: продукт похож на решение от Bitdefender, но с дополнительными интегрированными функциями для экспертного анализа и анализа данных (на которых специализируется компания).
• AIS: стратегически важное исследование требований к технологиям виртуального пространства ВВС и Министерства обороны.

Дополнительные ресурсы

• wiki.xenproject.org/wiki/Virtual_Machine_Introspection

Дезагрегация и модули безопасности Xen

Модули безопасности Xen (XSM) являются эквивалентом SELinux и дезагрегации. Эта функциональность была включена в кодовую базу Xen очень рано, но до недавнего времени, до того, как были значительно переработаны и дополнены компоненты, она особой популярностью не пользовалась.

Дезагрегация

Как я упоминал ранее, драйверы устройств в архитектуре Xen всегда запускаются в Dom0. На приведенной ниже диаграмме дезагрегации (рис. 7) мы удалили эти драйверы из Dom0 и поместили их в сетевой домен (Network Domain). Таким образом, мы получили сетевой драйвер (Network Driver), работающий в обычной виртуальной машине, не имеющей привилегий. Это означает, что Dom0 был удален из пути передачи данных для работы в сети. Если бы на сетевой драйвер была совершена атака, это повлияло бы только на сетевой домен. Поскольку в этом домене работает только драйвер устройства, эксплойт должен был бы перепрыгнуть через дополнительную границу VM, чтобы нанести какой-либо ущерб. Та же модель может применяться для доменов хранилищ. В Dom0 остается только функциональность, которая управляет всей информацией о конфигурации в системе Xen (например, QEMU или демон Xenstore). Опять же, вы можете просто запустить их в другом домене Xen, который создает то, что мы называем сильно дезагрегированной системой.

Рисунок 7.В дезагрегированной архитектуре драйверы устройств удаляются из Dom0 и помещаются в сетевой домен (Network Domain)

Рисунок 8.Эта же модель может применяться для доменов хранилищ. В Dom0 остается только функциональность, которая управляет всей информацией о конфигурации в системе Xen

Модули безопасности Xen

Еще одна действительно интересная функциональность — это то, что мы называем «модули безопасности Xen (Xen Security Modules — XSM)» или FLASK. XSM владеет всеми теми же инструментами, что и SELinux для разработки и проверки политик безопасности. Для каждого типа виртуальной машины мы определяем политику безопасности, которая контролирует, к какому набору гипервизоров (hypercall) или API разрешено обращаться данному типу виртуальной машины. Если одна из этих виртуальных машин вызывает API, на который у нее нет разрешения, вызов завершится с ошибкой. Представьте, что граница API — это стена, а эксплойт — это злоумышленник пытающийся перелезть через нее. Функциональность наподобие XSM как бы увеличивает высоту стены, что затрудняет ее преодоление.

Рисунок 9.Модули безопасности Xen увеличивают высоту пограничной стены API, что затрудняет задачу эксплойтов

Коммерческие приложения

• Qubes: ОС, которая по своей архитектуре очень похожа на то, что сейчас используют компании на рынках автомобилестроения и встроенных систем.
• OpenXT от BAE (оборонная компания) и AIS (охранная компания): платформа FOSS, построенная на Xen и OpenEmbedded для исследований в сфере безопасности, приложений безопасности и интеграции встроенных устройств. Несмотря на то, что она похожа на Qubes, этот проект с открытым исходным кодом, который является гибким и расширяемым, нацелен на более широкий ассортимент устройств.
• Crucible Defense от Star Lab: платформа виртуализации для защиты технологий, улучшения противостояния кибератакам и целостности системы для аэрокосмических и оборонных систем.

Я хотел бы подробнее рассказать о Qubes OS, которая использует всю эту расширенную функциональность Xen, чтобы создать то, что мы называем «архитектура с защитой в глубину». На приведенной ниже диаграмме (рис. 10) показан пользовательский интерфейс операционной системы Qubes. В правом верхнем углу вы видите несколько виртуальных машин разных типов в диспетчере VM. Эти виртуальные машины используются в качестве защищенных песочниц для приложений и компонентов системы. Меню слева позволяет запускать различные приложения в отдельных песочницах.

Рисунок 10.Пользовательский интерфейс Qubes OS использует виртуальные машины в качестве защищенных песочниц для приложений и системных компонентов

На следующей диаграмме (рис. 11) компоненты Xen, используемые Qubes OS, накладываются поверх пользовательского интерфейса. Как вы можете видеть, гипервизор и Dom0 специально привязаны к диспетчеру VM и другим функциям интерфейса Qubes OS. Существует также сетевой домен (Network Domain) и домен брандмауэра (Firewall Domain), которые обеспечивают соблюдение всех ваших сетевых политик, а также домен USB, который изолирует вашу систему от любых угроз, которые могут быть вызваны взломанным USB-устройством.

Рисунок 11.Компоненты Xen, используемые операционной системой Qubes, накладываются поверх пользовательского интерфейса: гипервизор, Dom0, сетевой домен (Network Domain), домен брандмауэра (Firewall Domain), домен USB

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

Дополнительные ресурсы

• wiki.xenproject.org/wiki/Dom0_Disaggregation
• wiki.xenproject.org/wiki/Xen_Security_Modules_:_XSM-FLASK

Xen для встроенных систем / автомобилестроения

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

Планирование

Xen может устанавливать планировщик на разные процессоры, также вы можете выделить виртуальную машину специально для виртуального процессора без внедрения планировщика. В приведенной ниже таблице (рис. 12) рассматриваются два основных планировщика Xen: Credit и Credit 2. Они оба используются в облачных вычислениях, хотя Credit 2 является улучшенным вариантом Credit. Xen также поддерживает жесткий планировщик реального времени (ARINC 653) и мягкий планировщик реального времени (RTDS).

Рисунок 12. Xen поддерживает несколько разных планировщиков с различным набором свойств

Xilinx Xen, продукт, разработанный компанией, специализирующейся на военных и встроенных системах, дает возможность реализовать гибкость при участии Xen. Чипсет Xilinx содержит четыре A53 ядра ARM, которые могут быть виртуализированы, и четыре R5, которые не могут быть виртуализированы (у него также есть FPGA). Xilinx Xen содержит интересную функцию, называемую контейнерами Bare Metal Xen, которые позволяют помещать традиционное изображение ARM ELF в контейнер. Затем вы запускаете этот контейнер непосредственно в виртуальной машине, которую вы должны привязать к определенному виртуальному процессору. Эта настройка позволяет включать старый встроенный код в систему на основе Xen с помощью одного из этих контейнеров. Xilinx Xen также содержит драйверы и библиотеки для доступа к FPGA из виртуальной машины или контейнера Bare Metal.

Рисунок 13.Распределение Xilinx Xen демонстрирует некоторую гибкость с Xen

Задержка

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

Поддержка устройств

Разработчики встроенных продуктов также нуждаются в поддержке различных устройств ввода/вывода. Xen обеспечивает поддержку многих устройств в своей базе кода (например, консоль, мышь, USB, совместное использование GPU), а в настоящее время разрабатывает поддержку для многих новых устройств. Разработка новых драйверов PV в Xen относительно проста (в зависимости от сложности устройства), и есть много примеров созданных драйверов PV (примеры доступны под лицензиями GPL v2 или BSD). Драйверы PV могут жить в пространстве ядра, а также в пространстве пользователя, которое применяется как к пользовательскому интерфейсу PV, так и к серверной части.

Коммерческие приложения

Встроенные системы

• ARLX от Dornerworks: высокозащищенный продукт для приложений безопасности, который соответствует требованиям различных сертификатов безопасности.
• Xilinx Xen Zynq от Dornerworks: полностью программируемый гетерогенный MPSoC, который обеспечивает масштабируемость 64-битногопроцессора, одновременно сочетая управление в реальном времени с мягкими и жесткими движками для графики, видео, временных диаграммы и обработки пакетов.
• NXP Xen от Dornerworks: позволяет разработчикам запускать несколько операционных систем на NXP i.MX 8.
• Crucibleи Crucible Defense от Star Lab: аналогичные продукты для ARLX, но с использованием MiniOS вместо Linux в Dom0.
• FreeRTOS port от Galois: минимальная ОС для микроконтроллеров, которая работает, как гость Xen на ARM Cortex A15.
• Haskell Lightweight VM от Galois: позволяет разработчикам запускать программы Haskell на «голом» (виртуальном) железе внутри домена Xen без хостовой операционной системы.

Автомобилестроение

• Nautilus Platform от GlobalLogic: набор автомобильных акселераторов решений для информационно-развлекательного ПО (IVI), которые включают в себя архитектурные концепции, модифицированный дистрибутив ОС Android и улучшенный пользовательский интерфейс.
• Cloud Fusion Platform от EPAM: автомобильная платформа с сетевыми возможностями, которая позволяет функциональности автомобиля подключаться к облаку.
• XenGT от LG: планирование графиков в реальном времени для автомобильных встроенных систем.
• Решение для защиты виртуальных систем от Perseus: отделяет исходный домен автомобиля с сетевыми возможностями от других доменов и защищает ОС автомобиля от вредоносных программ и DDoS-атак.

Давайте подробнее рассмотрим продукт GlobalLogic Nautilus, который будет внедрен в транспортные средства, запланированные к выпуску уже в первом квартале 2018 года. Nautilus поддерживает много различных аппаратных платформ, операционных систем и устройств ввода/вывода. Как вы можете видеть на архитектурной схеме ниже (рис. 14), Nautilus использует Xen для управления несколькими операционными системами на одном SoC, чтобы транспортные средства могли запускать настраиваемое информационно-развлекательное программное обеспечение без риска повлиять на критически важное программное обеспечение автомобиля. Xen позволяет производителям автомобилей и разработчикам программного обеспечения достичь лучших результатов без ущерба для обеих систем, и все это при минимальных требованиях к аппаратному обеспечению.

Рисунок 14.Платформа Nautilus от GlobalLogic использует Xen для запуска нескольких ОС на одном SoC, безопасно отделяя информационно-развлекательное программное обеспечение (IVI) от критически важного ПО автомобиля

Вывод

Итак, зачем использовать Xen для виртуализации? Xen является гибким и надежным, предлагает инновационные функции и может быть сертифицирован на соответствие различным требованиям безопасности. Сообщество Xen также чрезвычайно успешно и активно развивается, и за последние несколько лет количество вкладов в разработку значительно увеличилось. 48 % вкладов пришло от Citrix в 2015 году, но всего через год эта цифра сократилась до 33 %, поскольку все больше и больше вкладов поступало также от разных компаний, занимающихся встроенными системами, и экосистемы ARM. Таким образом, мы видим, что сообщество Xen постоянно растет и становится все более разнообразным. Благодаря этому мы становимся участниками разработки потрясающего нового функционала и появления новых вариантов использования.

Рисунок 15.Сообщество Xen активное и разнообразное. За последние несколько лет его вклад вырос в десять раз

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

Я маю чималу історію переїздів. Народився у Києві, виріс в Азербайджані та у Сибіру. Вчився у Петербурзі та Києві. Працював у Донецькій області, у Києві та в Латвії. Але у грудні 2016 року я прийняв пропозицію львівської компанії Perfectial. Так збулася моя давня мрія жити у столиці Західної України. Тепер я раджу Львів своїм друзям як майже ідеальне місто для IT-спеціаліста.

Згідно з дослідженням EY 56 % кандидатів, яким подобаються IT-роботодавці, готові до релокації. І в якості найбільш бажаного міста для переїзду більшість із них розглядають Львів. Я можу назвати 7 причин для IT-спеціаліста переїхати саме до Львова.

JavaDay Lviv 2015

Можливості для старту кар’єри в IT

Я завжди вважав: заради першої роботи треба бути готовим змінити місто. Тому свого часу у 2009 році розсилав резюме по всій Україні, а коли мене запросили на роботу в Макіївку, погодився. Якщо ви шукаєте свою першу роботу зараз або хочете перейти в IT, як мінімум варто розглянути вакансії компаній казкового Львова. У Junior-дайджестіна DOU за кількістю вакансій, стажувань та інтернатур для початківців Львів ділить з Харковом друге місце після Києва.

Можливості для розвитку кар’єри

За кількістю вакансій на DOUЛьвів посідає третє місце в Україні після Києва та Харкова. Згідно з дослідженням Львівського IT-кластера, у 2015 році у Львові налічувалося 192 IT-компанії — від аутсорсингових гігантів до розробників власних продуктів. Це означає широкий спектр можливостей для тих, хто хоче змін у своїй кар’єрі: перейти на вищу посаду, змінити аутсорсинг на продукт, попрацювати з новими для себе технологіями тощо.

IT-продукти світового рівня

Тільки 2 %збуту львівських IT-компаній припадає на Україну. Найбільшим замовником є США — це 50 %. На другому місці країни Європи — сумарно 35 %. 8,4 % IT-компаній Львова створюють власні продукти. Також у місті працюють R&D центри Oracle та Siemens. Отже, робота у Львові — це, як правило, робота над глобально значущими проектами.

Калюжа у формі серця

Львівська IT-тусовка

У 2015 році я мав честь представляти на JavaDay Lviv корпорацію Accenture, IT-аутсорсера № 2 у світі. Так почалося моє знайомство з львівською IT-спільнотою, багатою на яскраві особистості. У Львові живуть десятки IT-шників, відомих на всю Україну за свої досягнення та активну життєву позицію.

Львів є містом-господарем близько двох десятків IT-конференцій. З повним переліком можна ознайомитися в огляді IT-праці Львова. Деякі з IT-подій міста мають значення для всієї Центральної та Східної Європи. Наприклад, GDG DevFest Ukraineє найбільшою в регіоні конференцією по Google-технологіях, в тому числі по Android. Lviv IT Arenaпозиціонується як найбільша IT-подія у Східній Європі.

Найбільший у країні IT-парк

Правда, поки що він тільки в проекті. 24 червня було анонсовано, що вже цього року у Львові розпочнеться будівництво Innovation District IT Park. У проект буде інвестовано 95 мільйонів доларів. Комплекс займатимерозміститься на площуі 10 гектарів. Окрім офісних приміщень, розрахованих на 10 тисяч працівників, IT Park включатиме навчальну інфраструктуру, зокрема тут будуть вчитися студенти Українського кКатолицького університету, що опановуютьвивчають Computer Science.

Серед перших резидентів IT-парку — GlobalLogic, SoftServe, N-iX та компанія, де я працюю — Perfectial.

Близькість до Центральної Європи

IT-шники люблять подорожувати. А зі Львова за одну ніч автобусом чи автівкою можна потрапити до Польщі, Німеччини, Чехії, Угорщини, Литви, Австрії, Словаччини. Згідно з даними сайту Busfor, час у дорозі зі Львова до Кракова на автобусі — 6 годин; Варшави — 7 годин; Дрездена — 15; Берліна, Будапешта, Вільнюса, Праги — по 16; Відня — 17; Братислави — 19.

Крім того, з аеропорту «Львів» можна полетіти прямим рейсом у Мадрид, Мюнхен, Рим, Стамбул, Тель-Авів та інші цікаві міста. Повний розклад можна побачити тут.

Новий трамвай у старому Львові

Розвинена інфраструктура

Хоча у Львові немає метро, на схемі львівського трамвая 11 ліній: їхня загальна довжина перевищує довжину ліній київського метрополітену.

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

Висновок

Історичний центр Львова — всесвітня культурна спадщина ЮНЕСКО. Це те, чим ніколи не зможе похвалитися Кремнієва Долина: міста такого значення немає в континентальній частині США. Але сучасний Львів — це більше, ніж історична архітектура та культурне життя. Львів — це сотні вакансій в IT, зокрема і для початківців. Це близько 200 IT-компаній, що створюють програми для ринків США, Канади, Європи та Азії. Це конференції та події, відомі в IT особистості. А незабаром у Львові з’явиться найбільший в Україні IT-парк.

У випуску: як захистити сайт за допомогою Zip бомби, бенчмарк Twig vs Smarty, навіщо вчити Symfony у 2017 році, реліз PhpStorm 2017.2.

Статті

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

It Turns Out, 2017 is the Year of Simply Secure PHP Cryptography — якщо на твоєму проекті не обновляють PHP 5.x, бо проблеми з криптографією, то тобі обов’язково треба прочитати цю статтю.

Introducing Laravel Horizon — Laravel Horizon — це дешборд для керування Redis чергами. Повністю безкоштовний і open source.

Бенчмарк Twig vs Smarty — Twing набагато швидше.

A programmer’s cognitive load

Type-Hint All The Things!

Hackermoon.com: Why you should learn Symfony in 2017

How to Analyze Tweet Sentiments with PHP Machine Learning

8 Must Have PHP Quality Assurance Tools (2017 Update) — As you write your PHP code, you’ll need to verify that everything is working as expected and that the code follows all style and formatting requirements. In this list from the SitePoint PHP blog they give you a list of eight tools you can use to ensure all of these criteria are met.

Релізи

PhpStorm 2017.2 is now released!

PHP 7.2.0 Alpha 3 released

PHPStan 0.8 released — static analyser for discovering bugs in your code!

Цікаві бібліотеки

Flyimg — Dockerized PHP7 application runs as a Microservice to resize and crop images on the fly.

Pterodactyl/Panel — Pterodactyl Panel is the free, open-source, game agnostic, self-hosted control panel for users, networks, and game service providers.

Php-must-watch — list of interesting conference talks and videos on PHP.

Різне

Toxic Drupal community — Drupal вважається одним з найбільш diversity open source community (там є сексуальні меншини, представники майже всіх релігій). В жовтні з’явились чутки, що Larry Garfield, один з топ контриб’юторів Drupal, полюбляє БДСМ (master/slave relationships). В березні він прийшов на конференцію зі своєю жінкою-рабинею, і це образило деяких інших людей. The Drupal Association публікує лонгріді виганяє Larry з комьюніті.

Laravel допоміг мені знову полюбити программування — найпопулярніший тред на Reddit за минулий місяць.

Secure Code Delivery Stream Updates to a Chronicle — Plan to bring Secure Code Delivery (Cryptographic Signatures and more) to Packagist and, in turn, Composer.

ThePHP.cc: Why Developers Should Not Code

Івенти

PHP Friends Club meetup #2 (openair) — вже друга зустріч PHP розробників! Вже сьогодні на відкритому повітрі!

Дякую, з вами був Рома Севастьянов.

← Попередній випуск: PHP дайджест #5

У випуску: Python 3.6 швидший за Python 3.5. Стартап Kite експлуатує опен сорс бібліотеки. Еволюція процесу деплоїв в Reddit.

Новини

Python 3.6.1 becomes default Python runtime on heroku — починаючи з 20 липня 2017 року дефолтною гілкою Heroku стає python-3.6.1, що замінить python-2.7.13

NumPy receives first ever funding, thanks to Moore Foundation — NumPy отримує фінансування в розмірі $645,020

Python 3.6.2 released

What’s new in Cython 0.26?

Нові релізи

PyCharm 2017.2 — додані Docker Compose on Windows, SSH Agent, Amazon Redshift

Mypy 0.521 Released

wxPython 4.0.0b1 Released

Nuitka Release 0.5.27

Цікаві бібліотеки

Quart — мікрофреймворк на базі Asyncio з API ідентичним до Flask. За словами має пітримувати Flask extensions.

Cook — modern build system written in Python.

kolors 0.0.4 — дозволяє виводити інформацію з вашого коду в кольорі до терміналу.

PyO3 — бінгдінги Python для Rust.

Cppyy — Python-C++ бінгдінг бібліотека.

Статті/ресурси

The Evolution of Code Deploys at Reddit — стадії, що пройшла компанія, перед тим як почати деплоїти 200 разів в тиждень.

Make the world better? Remove some Javascript.

Advanced Python Features — генератори, collections module, itertools та інші фічі Python, які Ви можливо ще не використовували.

FAT Python : the next chapter in Python optimization — огляд PEPпів від Victor Stinner, що мали б вирушувати проблеми „static optimizers” в Python.

Back-end engineer interview questions — тред на Reddit, може бути цікаво тим, хто хоче перейти до вебу або шукає першу роботу в Python.

Parsing In Python: Tools And Libraries — набір бібліотек для парсінгу.

Let’s Create Our Own Cryptocurrency — прикольний варіант розібратись в криптовалютах — це побудувати свою.

Revisiting Unit Testing and Mocking in Python — dependency injection, inversion та інші модні словечка.

The rise of Python for Embedded Systems.

Pythonbooks — 100 книжок по Python відсортованих по складності та темам. Приймаються ревью до книжок через GitHub :)

How to use transfer learning to create an image classifications engineна прикладі розпізнавання застібок від блискавки.

Refactoring with tests in Python: a practical example.

Рейтинг моввід IEEE Spectrum — Python переходить на перше місце, Swift входить в першу десятку.

How a VC-funded company is undermining the open-source community — як стартап Kite брав під своє крило проекти з опен сорсу і додавав туди свою рекламу або намагався використовувати у власних цілях. Цікава історія, в якій засвітився відомий пакет для Atom — autocomplete-pythonвід українського розробника @sadovnychyi. Цікаву дискусію контриб’юторів проекту можна почитати issueна GitHub.

Rationalizing Python’s C APIs — стаття про ,наразі, „не нумерований” PEP, що пропонує приховати деталі імплементації в середині C API. Цікаво, що Victor Stinner допускає, що дана модифікація може відкрити шлях до експериментів з:

• Indirect Reference Counting
• Remove Reference Counting, New Garbage Collector
• Remove the GIL
• Tagged pointers

Why ’d = {}’ is faster than ’d = dict()’

Відео

Optimizations which made Python 3.6 faster than Python 3.5

PyData Sieattle 2017

← Попередній випуск: Python дайджест #14

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

Николай Палиенко — интернет-предприниматель, в далеком прошлом Java программист. В 2008-мгоду совместно с Денисом Горовым и Тарасом Мурашко создал торговую площадку Prom.ua (и ее аналоги в Беларуси — Deal.byи Казахстане — Satu.kz). Сейчас руководит EVO.Company, которая объединяет Prom.uа и другие проекты: Bigl.ua, Zakupki.prom.ua, Crafta.ua, Kabanchik.ua, Vchasno.com.ua. В компании работает более 800 сотрудников, в том числе более сотни технических специалистов.

До создания своего бизнеса Николай работал на позициях Software Engineer и Software Architect в IT-компаниях Cogniance, Sonopia, Flextronics Design Ukraine, а также в нескольких других.

Возраст и опыт: 36 лет, 16 лет работает в IT.
Текущая должность: CEO and Co-Founder EVO.Cоmpany.
Модель смартфона: iPhone 6.
Модель ноутбука: Macbook Pro.
Суперспособности:строить экосистемы, которые призваны помогать людям и организациям проще и удобнее взаимодействовать; создавать и мотивировать команду, которой по плечу любая задача.

— Как проходит ваш типичный рабочий день?

Встаю рано, перед работой бегаю или плаваю. Около 9 утра приезжаю в офис. В 10 у нас обычно начинается 15-минутныйутренний стендап с ключевой командой. После этого занимаюсь непосредственно работой, провожу встречи. В середине дня выделяю минут 40 на обед, стараюсь обедать вне офиса и с кем-то из команды. Затем возвращаюсь к работе — обычно ухожу между 18-юи 19-ю,иногда задерживаюсь. Потом дом, семья, друзья — всё как у всех :)

— Какие гаджеты, девайсы используете ежедневно?

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

— Как выглядит ваш воркспейс? Какими инструментами пользуетесь?

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

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

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

— Используете ли какие-то практики по тайм-менеджменту?

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

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

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

— Как часто проверяете почту, соцсети, мессенджеры?

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

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

— Ваш любимый to do менеджер?

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

До Trello я и вовсе не использовал менеджеры задач, а обходился списками в Google Spreadsheets и почтой — незавершенные задачи помечал как непрочитанные письма. Trello более удобный и продуманный для этих целей инструмент. От его использования получаешь удовольствие: приятно перетаскивать задачу в Done или в моем случае еще и в Delegated. Кроме того, он всегда под рукой и на ноутбуке, и на смартфоне.

— Сколько часов в неделю работаете?

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

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

— Что вас вдохновляет?

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

— Что помогает быть продуктивным?

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

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

— Вы экстраверт или интроверт?

Наверное, 50/50. Когда глубоко погружаюсь в задачу, то становлюсь невосприимчивым к внешнему миру. В то же время как предприниматель и CEO много общаюсь с людьми.

— Что последнее прочитали или читаете сейчас?

Сейчас читаю «Укрощение амигдалы. И другие инструменты тренировки мозга» Джона Ардена. До этого я прочитал «Эссенциализм» Грега МакКеона, а еще до этого — «Як ви збудуєте своє життя?» Клейтона Кристенсена. Такие вот все разные книжки, про менеджмент, принятие решений, личную жизнь, психологию, нейрофизиологию. Мне интересны вещи, связанные с поведением человека, менеджмент уже давно строится не на подчинении, а на лидерстве.

— С кем из известных личностей хотели бы встретиться? Что бы спросили?

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

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

— Что бы посоветовали себе 10 лет назад?

Вести дневник :) Очень забавно читать свои старые записи. Это помогает рефлексировать.

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

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

— Кем себя видите через 5 лет?

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

Совсем недавно мне посчастливилось провести пять недель в США — я проехала с восточного побережья на западное, посетив Нью-Йорк, Северную Каролину и уже давно любимую Калифорнию. Почти как герои книги «Одноэтажная Америка», только по воздуху. В моем жизненном плане, однако, есть пункт повторить этот путь на автомобиле. Или как девушка, речь о которой пойдет в этом материале, — на мотоцикле.

На фото автор статьи, Анна Скумина, в библиотеке университета Беркли, где в полной тишине атмосферных комнат, как из романов о Гарри Поттере, готовятся к экзаменам студенты университета

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

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

Long story short: глядя на кампусы престижнейших университетов мира, представить себя их студентом невозможно. Но слушая Юлю, я поняла, что учиться в топовых бизнес-школах выходцам из Украины более чем реально. Хочется поделиться этим знанием, возможно, оно вдохновит тех, кто задумывался, но пока не решался даже мечтать о таком.

Итак, знакомьтесь — Юля Нечаева, выпускница Харьковского национального университета радиоэлектроники, студентка бизнес-школы университета Беркли, создательница продуктов в компаниях Innova Systems, Yandex, а теперь и Amazon.

— У тебя была успешная карьера, что послужило для тебя толчком все бросить и снова стать студентом?

Я все время думаю про то, что будет дальше, и в какой-то момент поняла, что еще лет пять — и все, моя карьера перестанет быть мне интересна, если я останусь здесь. Я построила отдел тестирования в геймдеве, перевела и издала книгу, запускала приложения для детей в App Store, руководила перезапуском продукта в Yandex. Мне не хочется расти в general management. Я хочу перемещаться горизонтально, запускать команды и продукты. Поэтому я хочу жить там, где в индустрии много всего происходит, где развитая среда и много больших технологических компаний. Кроме того, я очень люблю большие американские города. Когда все отправлялись в отпуск в Таиланд, я летела в Нью-Йорк.

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

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

Вторым толчком была поездка в Сан-Франциско на Новый 2015-йгод. В квартире Airbnb случайно оказалась книга What they teach you in Harvard Business School. Я прочитала ее запоем. Там очень кинематографично описан опыт человека, который закончил HBS. Такие истории, как «моя одноклассница из Сингапура, руководящая большим медицинским центром, каждый раз краснеет, когда профессор обращается к ней на лекции», помогли представить эту атмосферу, очеловечить ее. Я решила, что хочу оказаться в этой среде, вернулась и распланировала подготовку.

У моего выбора именно MBA есть еще одно обоснование. Я менеджер, собираю команды, настраиваю процессы так, чтобы команда выдавала результат. Этот опыт, в отличие от технологических навыков, не «переводится» напрямую. То, что я могу построить команду здесь, не значит для рекрутеров, что я могу построить команду там, мне это говорили на интервью прямым текстом. А за два года в американской бизнес-школе я смогу показать, что умею собирать мультинациональные команды. К тому же, например, Amazon нанимает продакт-менеджеров с ‘MBA strongly preferred’.

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

— Известно, что образование в Америке стоит немалых денег. Но интернет говорит, что можно получить его почти бесплатно. Это правда?

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

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

В Беркли я знала, что мне дадут need-based грант. На остальное я взяла кредит у Prodigy, это кредитная организация, в которую инвестируют выпускники MBA. Обычно такой кредит возвращают за 5-6 лет.Понятно, что для этого нужно получать соответствующую зарплату, и это следует учитывать заранее. Как? Например, на сайте школы есть зарплаты выпускников по областям и профессиям. Если речь об Америке, то есть сайт glassdoor.com, где тоже можно оценить будущую зарплату в определенной компании.

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

— Как ты выбирала школу? Расскажи про свои критерии.

У меня было три основных критерия: рейтинг, локация и культура.

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

Я хотела жить в Сан-Франциско или Нью-Йорке или хотя бы очень близко.

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

В итоге я поступала в пять школ. Две калифорнийские — Стэнфорд и Беркли, две нью-йоркские — Колумбийский университет и школа Стерна в Нью-йоркском университете, и еще в Йель, недалеко от Нью-Йорка. Меня взяли в Стерна и Беркли, и я выбрала Беркли.

— Насколько сложно было подготовиться? Сколько это заняло времени? Что было самым сложным?

От начала подготовки до первого application у меня ушло 6 месяцев. Два месяца активно готовилась к TOEFL, где максимум 120 баллов, а проходной в Беркли — 100. Я сначала сдала на 101. Потом я поехала в Нью-Йорк на трехнедельные летние курсы английского в Колумбийский университет, вернулась и пересдала на 108.

Два месяца активно готовилась к GMAT. Математику я сразу писала на максимум, а вот с вербальной частью было сложно. Я брала усиленные курсы в MBA Strategy для тех, кто хочет высокий балл. В результате сдала на 730. Хотя знаю ребят, которые готовились две недели и написали на 720.

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

— Что ты посоветуешь тем, кто собирается готовится самостоятельно?

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

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

Я бы посоветовала сдать тестовые экзамены на TOEFL и GMAT, чтобы понять свой текущий уровень. У школ разные требования, некоторым не нужны очень высокие баллы.

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

Еще есть хорошая книга How to get to top MBA Schools. Там описано, как тебя оценивает приемная комиссия. У каждой школы свои критерии: для одной школы у тебя может быть недостаточно социальной активности, а для другой это не так уж и важно.

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

Поступать лучше в первом раунде (это сентябрь). Больше шансов, что людей с похожим профайлом еще не приняли.

— А если не успел к сентябрю, попробовал в следующий период и тебя не взяли, можно ли пробовать еще или стоит подождать какое-то время?

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

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

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

— Насколько комфортно быть студентом в Калифорнии? Приходится ли себе в чем-то отказывать?

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

Я почти не покупаю вещи. Перед переездом я полностью перебрала гардероб. В итоге приехала с двумя чемоданами. Потом друзья привезли мое электропианино и три коробки книг. Это все, что у меня есть. Никаких зимних вещей, оставленных у родителей, или телевизора у друзей. Самая крупная покупка здесь — мотоцикл. Они здесь дешевле (намного!), чем в Украине или России.

Здесь много крутых outdoor-развлечений в близкой доступности. Можно виндсерфить и учиться управлять парусной лодкой в Беркли Марина. Это 15 минут езды от кампуса, мы туда между классами иногда ездим. Большое количество hiking-маршрутов. Много куда можно съездить на выходные: Форт Росс, Сакраменто, Монтерей, посерфить в Санта-Крузе, побродить по Йосемите.

На зимних каникулах (они у нас длятся месяц), мы с бойфрендом проехали 4000 км на мотоцикле по Аризоне и Неваде, потом еще проехали столько же на машине по центральным штатам. Катались на снегоходах мимо бизонов в Йеллоустоуне, на горных лыжах и на упряжке с хаски. Всего семь штатов за несколько недель. На все путешествие у нас ушло по 2000 долларов на каждого. В ближайших планах ездить по странам, куда мне не нужна виза: Мексика, Коста-Рика, Эквадор.

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

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

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

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

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

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

Если ты понимаешь, что хочешь подтянуть, то находишь необходимые для этого ресурсы. Например, первый год я была одной из старост в моей когорте (60 человек). Это посредник между классом, профессорами и деканатом (Program Office). Очень прокачала коммуникацию.

Еще это замечательный опыт работы в мультикультурных командах. Представь, у тебя проектная группа, 5-6 человек.Один хорошо знает финансы и может построить финансовую модель за полчаса, но не может научить этому других. Другому этот предмет вообще неважен, он готов написать final paper, чтобы все от него отвязались. Третьему все это очень интересно, и он все время пытается расширить границы проекта. Все из разных стран, с разным опытом. Кто-то хочет разделить все задачи поровну. Кто-то хочет, чтобы все было эффективно, и говорит: «Я могу быстро, давайте я сделаю сам». А тут еще и ты со своим «офигенным» английским и полным непониманием, как пишут академический paper. После такого уже ничего не страшно.

У нас очень крутые soft-skills классы. Ты можешь прекрасно знать, например, маркетинг, но если ты не понимаешь, какими глазами на тебя и твою работу смотрят люди, принимающие решения, ты не сможешь убедить их. Здесь не только рассказывают, какие предубеждения есть у людей, но и демонстрируют их у тебя и твоих одноклассников. Есть классы, которые через storytelling учат, как понять свои силу и слабости. И не отрицать их, а спокойно признавать.

— Что больше всего, по твоему мнению, отличает образование, которое ты получила в Харькове, от того, которое ты получаешь сейчас?

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

Первый день стажировки в Amazon. Юля (справа) с одноклассниками из Бразилии, Таиланда и США

— А что дальше?

Этим летом стажируюсь в Amazon, в Сиэтле. Потом еще год учиться. Буду помогать профессору преподавать маркетинг, организую Speaker Series курс, поработаю над своим проектом в Lean Lanchpad, буду делать воркшопы по product-менеджменту. Доучусь ездить на мотоцикле, чтоб колесить по Штатам уже не пассажиром. Параллельно буду изучать другие карьерные возможности, кроме стандартного пути product-менеджера в большой компании. Главное, что я знаю свой вектор.

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

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

• 5 лет опыта в техрайтинге лучше, чем 0 лет опыта;
• приятный в общении кандидат лучше, чем неприятный;
• внимательный к деталям лучше, чем невнимательный;
• и т. д.

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

Какому образованию отдать предпочтение?

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

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

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

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

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

Как оценить компетентность кандидата в требуемых программах?

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

Я не включала в таблицу такой распространенный soft как Word, Outlook, Internet Explorer и прочее — я думаю с ними все понятно. В таблице собраны только более узкопрофильные программы.

Какие дополнительные вопросы следует задать?

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

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

• создание видеообзоров;
• работа с Google Analytics;
• улучшение UX;
• работа со стилистикой текстов и терминологией;
• улучшение CSS;
• оптимизация рабочих процессов внутри команды;
• и т. д.

Расскажите работодателю о смежных интересах кандидата, и возможно обнаружиться, что кандидат обладает полезными для компании знаниями, о которых не упомянули в вакансии (обо всем же не напишешь). Например, если кандидат любит аналитические задачи, ему обрадуются в компании, где давно хотят настроить Google Analytics и проанализировать источники трафика на сайте. Если у компании нет своего UX эксперта, кандидат даже с базовыми знаниями UI и UX придется очень кстати. Возможно, компания планирует снимать видеообзоры, тогда преимущество логично отдать кандидату, который интересуется видеосъемкой, и имеет хорошо поставленную речь.

Что обязательно надо выяснить?

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

Какое дать тестовое задание?

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

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

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

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

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

Привет, я Евгений Шнайдер, мне 26 лет, с детства увлекался программированием, в старших классах создал сайт, посвященный смартфонам, тогда еще под Symbian 9 (пик посещаемости составил 25 000 посетителей в день). Для этого сайта нужен был хостинг, с тех пор хостингом и занимаюсь.

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

Идея

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

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

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

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

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

Реализация

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

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

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

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

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

Было еще много задач на стыке программирования и дизайна. Например, запуск фоновых процессов на сервере. Пользователь хочет запустить процесс — установка MySQL на сервер. Этот процесс занимает около 10 минут. Но РНР не дает следить за этим процессом в реальном времени, и программа после запуска может сразу сказать «OK», а сам процесс будет завершаться в фоновом режиме или же РНР (панель) будет ждать пока процесс выполнится. В таком случае пользователь не будет понимать, что происходит и будет нажимать на все кнопки, перезагружать сервер и т. д. В результате у нас получилось, что после запуска задачи пользователь видит весь процесс установки, и панель показывает, на каком этапе процесс. Задача не была очень сложной, но мы с ней повозились.

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

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

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

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

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

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

Какие выводы я сделал

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

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

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

Результаты

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

С помощью BrainyCP сокращается время настройки даже у опытного админа сервера до 90 %. Наше программное обеспечение сразу создает все необходимое «окружение» для любого сервера, который может быть использован для самых разных задач. Например, в любом сервере будет необходим: веб-сервер, база данных MySQL, почтовый домен, сервисы почты, почтовые ящики, PHP. Все что нужно для работы уже есть в нашем решении сразу, при установке пользователем. Это не говоря уже о многом другом, что у нас устанавливается или активизируется в один клик: сертификаты, приложения СМS, файловый менеджер, FTP-сервер, SHH-сервер, антивирус и многое другое, что доступно сразу и не требует никаких дополнительных плагинов. Из коробки, автоматически, ставится антивирус на сервер, удобно настраиваются бекапы, есть возможность сделать/вернуть бекап, снепшоты и многие другие возможности, которые на данный момент доступны только в платных решениях.

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

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

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

Наша цель — создать и поддерживать удобное и доступное всем программное обеспечение для управления сервером и хостинг-услугами.

Проработав 6 лет на позициях Front-end Developer в MacPaw и Grammarly, в прошлом году Дмитрий Филипенкорешил взять таймаут и поступить на 1 курс КПИ — получить второе высшее по прикладной математике. В интервью для DOU Дима рассказал о том, насколько полезно хождение на пары и ведение конспектов для уже состоявшегося разработчика и чем в итоге закончилась эта затея.

— Дима, почему вы решили оставить работу и поступить в вуз? Какая была цель?

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

Больше всего меня интересовало направление Machine Learning. Для развития в этой области мне, прежде всего, не хватало математического бэкграунда. Я закончил Приборостроительный факультет в КПИ, там математика была только на 1-2курсах и не считалась профильным предметом. В основном занимались черчением: собственно, я и начал карьеру в IT с дизайна и уже потом перешел во Front-end.

Чтобы подтянуть знания по математике, я стал заниматься с репетитором. Мы начинали прямо с основ — повторяли математику за 7-8 класс,потом двигались дальше. Повторив весь школьный курс, столкнулся с проблемой того, чтобы найти репетитора для университетского курса: почему-то все, с кем я общался, предлагали занятия максимум с какими-то элементами «вышки», но не были готовы последовательно преподать мне весь курс.

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

— А почему именно очное обучение? К примеру, сейчас доступно множество онлайн-курсов на Coursera и других площадках.

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

— Какие «за» и «против» рассматривали, когда решались поступать? И как отреагировали ваши коллеги?

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

В Grammarly некоторые расстроились, некоторые поддержали, у кого-то это вызвало непонимание. В общем, обычная реакция :) Но на самом деле было много поддержки от ребят, за что я им благодарен.

— А как вы планировали жить несколько лет, не работая?

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

— Почему выбрали именно КПИ? Какой факультет?

Помимо КПИ, я рассматривал КНУ им. Шевченка и Могилянскую академию. Но среди моих коллег в Grammarly было очень много людей, которые закончили именно IT-факультеты в КПИ. Впрочем, я не знаю, получили ли они свои знания благодаря или же вопреки вузу :)

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

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

Если бы поступал не ради математики, а ради компьютерных наук, то, скорее всего, выбрал бы УКУ.

— Поступали на общих основаниях? Как готовились?

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

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

— И как вам обучение? Какие впечатления?

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

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

Я честно учился, писал конспекты, делал домашние задания. И хватило меня на полгода :)

— А почему прекратили учебу?

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

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

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

Так что в конце первого семестра покинул вуз и с февраля работаю в компании Ring Labs на позиции Full Stack Developer.

— А было в планах доучиться до конца?

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

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

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

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

— Насколько в целом оправдались ваши ожидания от учебы?

Оправдались процентов на 60, может, 50 :) Я попробовал, получил опыт, приобрёл знания — вот это для меня самое ценное.

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

— Какие проблемы системы образования заметили за время учебы? И какие сильные стороны?

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

Если смотреть с точки зрения студентов, которые только закончили школу, то основная проблема — отсутствие ответа на вопрос «Зачем?». Их сразу начинают грузить какими-то абстракциями и не объясняют, зачем это, собственно, надо, как и где можно будет применить эти знания. Это убивает мотивацию.

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

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

Дима среди участников курса«Introduction to Data Science, Business Analytics, Big Data and Artificial Intelligence» в КПИ

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

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

— А если человек уже несколько лет проработал в разных сферах, но хочет освоить IT?

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

— Можете посоветовать какие-то лайфхаки по учебе? Как эффективно усваивать новую информацию?

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

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

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

С коллегами по Ring Labs

— На новой работе, в Ring Labs, уже используете новые знания?

Да. Основную часть времени занимаюсь разработкой, но есть и Machine Learning задачи. Меня менторит коллега Кирилл Трусковский.

Заметил, что до вуза, еще в Grammarly, когда я расспрашивал коллег о Machine Learning, то довольно слабо понимал суть того, что они мне рассказывали. А теперь уже понимаю разговоры и даже сам могу вставить что-то умное :)

— А не рассматривали вариант снова вернуться в Grammarly после того, как оставили вуз?

Я думал про это, но хотелось себя попробовать где-то еще, чтобы была возможность поработать с Machine Learning. В Ring Labs такая концентрация крутых ML-специалистов,что я подумал, это хороший шанс поучиться у них. К тому же некоторых я знал лично или это были знакомые знакомых.

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

— Какие у вас дальнейшие планы?

Развиваться в области Machine Learning. Мне кажется, сейчас есть 3 перспективные сферы, за которыми будущее, — это Machine Learning, космос и робототехника. Космосом я вряд ли займусь :) Робототехнику немного изучал, но меня несколько демотивировало, что создание одного устройства от идеи до прототипа — это очень длинный процесс. Machine Learning мне ближе всего, и это именно та область, ради которой мне хочется учиться.

Как известно, самое ценное в рабочем процессе — это люди. Профессионалы, которые образуют команду и могут помочь проекту стать успешным и добиться высоких результатов. Но могут, конечно, и перессориться, подвергнув риску даже самый гениальный стартап. На втором Kyiv CTO Meetup, организованном Preplyи Projectorв июле 2017, украинские СТО делились опытом создания удаленной команды мечты и обсуждали особенности этого непростого и важного дела. Я резюмирую идеи коллег и поделюсь своей стратегией в организации работы дистанционных сотрудников.

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

Эффективная команда: «стационар» vs «удаленка»

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

Алексей Осипенко, СТО в Cimon:

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

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

Коммуникация и контроль в удаленной команде

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

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

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

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

Судя по выступлениям спикеров на митапе, идеальный инструмент для организации работы удаленной команды найти непросто — это всегда метод проб и ошибок в поиске чего-то удобного и максимального эффективного. Начиная от простых созвонов в Skype или Hangouts и заканчивая многофункциональными Jira или Redmine — главное обеспечить собранность команды и работу связки «задача-действие-результат». Настройки некоторых инструментов настолько громоздкие и трудозатратые, что иногда компании приходят к необходимости разработке своего продукта. Так, например, поступили в Cimon — и в скором будущем обещают поделиться своими разработками с коллегами. Из опыта Алексея Осипенко, «хипстерские Слэки и Бейзкампы хорошо подходят для команд в 3-5человек и совершенно не подходят для хоть сколько-нибудь больших команд. Что же до инструментов вроде Trello, то эти инструменты во главу управления ставят проект. Они используют канбан-идеологию, которая в первую очередь рассчитана на небольшой поток задач и при масштабировании превращается в кашу из столбиков разных назначений и огромной кучи задач в секции «пока еще не запланировано».

Человеческий фактор и особенности хайринга

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

Отсюда — акцент на личные качества сотрудников удаленных команд. Алексей Осипенко из Cimon рекомендует обратить внимание на следующее: «Самостоятельность и адекватность принятия решений должна быть в первую очередь. Кроме того, существует теория, которая говорит, что взрослые состоявшиеся разработчики вполне справятся с любой поставленной задачей и в удаленную команду нужно набирать только таких. А среди таких вот лобовитых „сеньоров“ необходимо выбирать тех, у которых хорошо развиты гибкие навыки („soft skills“). На них и стоит обращать внимание в первую очередь при собеседовании в удаленную команду». Соглашаются с ним и другие участники встречи.

Станислав Скляровский, СТО ЛУН.ua:

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

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

Адекватный KPI универсален для всех

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

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

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

Вместо заключения

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

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

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

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

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

О каких же привычках идет речь?

Критическое мышление

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

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

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

Передача информации

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

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

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

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

Трекинг и распространение

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

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

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

Эмпатия

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

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

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

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

Бизнес-ориентация

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

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

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

Например, на сегодняшний день в HR-менеджменте существует такая компетенция, как культурная эффективность (Global and Cultural Effectiveness). Ее суть состоит в способности оценивать перспективы и учитывать интересы всех вовлеченных в проект сторон. А привычка постоянно держать такую информацию в голове и проводить анализ в фоновом режиме стала еще одной характеристикой настоящего профессионала.

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

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

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

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

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

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

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

Итак, основные отличительные особенности Enterprise-приложений это:

• Сложность;
• Большие объемы данных;
• Сложные и многообразные интеграции;
• Распределенность;
• Критичность для поддерживаемого бизнеса;
• Высокая стоимость ошибки.

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

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

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

Проблемы Enterprise-приложений

Самая главная проблема Enterprise-приложений — это сложность. Сложность предметной области и, как следствие, — сложность самих приложений. И это не абстрактное понятие. Например, размер одного из модулей (проекта) в рамках единого Enterprise-приложения обычно около 300-500 Мбисходных кодов. И такой объем информации невозможно взять и запихать ни в одну голову: как бы вы ни старались, часть уже запиханного будет вываливаться из головы. Это СЛИШКОМ много.

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

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

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

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

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

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

Более того, я часто люблю рассказывать такой пример. В США (вроде бы не самой отсталой стране мире, особенно в техническом плане) до сих пор все компании, связанные с телевизионным вещанием, синхронизируют свои программы передач с помощью выкачивания файлов (!) по FTP (!!!). Да-да, 4 Гб XML в архиве. Как вам такая интеграция? Самые дикие случаи я из уважения к бывшим клиентам (и из-за NDA) вам рассказать не могу. Но поверьте, там вообще на самом деле СТРАШНО. Просто В2В — это раз настроено и работает до конца века, это даже не пять лет.

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

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

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

Объемы же кода Enterprise-приложений примерно такие. Один модуль — 300-500 Мбисходников. Это модуль, который развивала на протяжении 10 лет команда из 3-5 разработчиков.Модулей таких — от полусотни до тысячи. То есть все приложение — это навскидку что-то порядка терабайт-десятков терабайт исходников.

Вы понимаете, это не то, что можно просто взять и переписать. Это не то, что можно в какие-то представимые временные рамки отрефакторить. И с этим всем надо что-то делать.

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

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

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

Как все это решается сейчас

Сначала большими мазками.

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

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

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

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

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

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