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

[Сергій Хлівненко — менеджер проектів у Lucky Labs. Упродовж останніх 7 років співпрацював з компаніями «Дотик технологій», Panasonic та Yaware, яким допомагав створювати та виводити на ринок власні ІТ-продукти. Основна експертиза та сфера інтересів: інформаційні технології, блокчейн, маркетинг, сучасна енергетика. Організовує тренінги із систематизації життя «Life Project Management»]

Я щодня вирішую задачі, пов’язані як з людьми, так і з процесами та проектами. Більшість із них вимагають комплексного підходу у виборі інструментів — для побудови ефективних комунікацій, проектування, досягнення результату «win-win» у домовленностях із замовником... Вирішив підготувати підбірку книжок про сучасні моделі менеджменту, аби допомогти початківцям зорієнтуватися у актуальних підходах в управлінні проектами. Порядок книг не випадковий: перші три найбільш концептуальні, демонструють чітку методологію сучасного менеджменту; дві останні більш практичні і для щоденного використання. Сподіваюся, ви знайдете їх корисними для себе.

Don Edward Beck, Christopher C. Cowan «Spiral Dynamics: Mastering Values, Leadership and Change»

В російському перекладі — Дон Бек, Крис Кован «Спиральная динамика. Управляя ценностями, лидерством и изменениями в XXI веке»

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

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

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

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

Клер Грейвз

Donella H. Meadows «Thinking in Systems: A Primer»

В російському перекладі — Донелла Медоуз «Азбука системного мышления»

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

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

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

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

Frederic Laloux «Reinventing Organizations»

В українському перекладі — Фредерік Лалу «Компанії майбутнього»

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

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

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

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

Daniel H. Pink «Drive: The Surprising Truth About What Motivates Us»

В українському перекладі — Даніель Пінк «Драйв. Дивовижна правда про те, що нас мотивує»

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

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

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

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

«Один бізнес-лідер висловився з приводу мотивації цілком буквально. Коли він проводить співбесіду при прийомі на роботу, то потенційним працівникам заявляє: «Якщо вам потрібно, щоб я вас мотивував, то я, ймовірно, не найматиму вас».

David Allen «Getting Things Done: The Art of Stress-Free Productivity»

В російському перекладі — Дэвид Аллен «Как привести дела в порядок: Искусство продуктивности без стресса»

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

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

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

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

Шел 22-йгод моей жизни или же 2016, если считать по общепринятым меркам. Я уже больше 2-хлет занимался разработкой под Android, и это неплохо у меня получалось. Работал в компании Eastern Peak Software, только получил диплом бакалавра ХНЭУ по специальности, близкой к Computer Science, и готовился к поступлению на магистерскую программу двойного диплома.

Однажды летом мне передали, что учительница информатики Яна Валентиновна Ефимова (дальше просто ЯВ) просит провести несколько уроков информатики в моей родной школе — ОСШИ II-IIIступеней «Одаренность» в Харькове. Целью занятий была подготовка школьников к олимпиадам по программированию (это когда нужно решать простые задачи на алгоритмы за определенное время). Предлагали вести 2 занятия в неделю на протяжении 2 семестров. Учительница обратилась ко мне, потому что у меня уже был опыт в этом деле: 2 года участия в школьных олимпиадах и 5 лет участия в университетских олимпиадах по спортивному программированию.

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

2016 учебный год

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

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

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

• Неглухой телефон.
• A+B.
• Зарплата.
• Пятью пять — двадцать пять!
• Единицы.
• Скачки.

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

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

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

Code Marathon 1.0

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

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

Призовых мест было 6: 1 первое, 2 вторых, 3 третьих. Призы — фитнес-браслеты Xiaomi и флешки. Спонсорами стали я и ЯВ, призовой фонд — около $100.

CodeMarathon 1.0 начался 20 октября 2016 года и закончился 20 января 2017. На протяжении всего этого времени мы раз в неделю вывешивали листик A4 в кабинете информатики с первыми 6 участниками на текущий момент. Конкуренция была, но не сильная. Решили довольно много задач (в среднем по 25 на одного участника).

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

В этом же году один из школьников (Коваленко Юра) занял 3-еместона Всеукраинской олимпиаде по информатике в г. Ровно.

2017 учебный год

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

Ученики были с разной подготовкой. С одной половиной 11-Вя уже занимался в прошлом году (это были в основном олимпиадники), поэтому с ними мы разбирали довольно сложные алгоритмы и структуры данных. Со второй группой 11-В (которые были вроде как не очень расположены к программированию, именно так изначально поделились группы) мы довольно быстро прошли весь базовый синтаксис C++ и тоже под конец перешли к олимпиадным задачам. С 9-Ау нас было в 2 раза меньше времени, поэтому с ними мы успели пройти только синтаксис С++. Но и там были отдельные люди, которые быстро перешли на онлайн-курсы и сами смогли освоить Python (необходим для длинной арифметики) и STL в С++ (нужен за счет всех плюшек vector, set, map, sort).

На уроках мы в основном решали контесты, созданные на базе тестирующей системы DOTS, разработанной и поддерживаемой Арзубовым Николаем Алексеевичем. Это тренер по олимпиадному программированию для школьников в Харькове, учитель информатики в гимназии № 45, руководитель МНО «Q-BIT». Система действительно очень удобная, на ней же проходят областные олимпиады в Харьковской области.

Code Marathon 2.0

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

Первые шаги

Результаты на листе А4 раз в неделю? Конечно, нет. Нам определенно нужен был сайт с обновлением результатов онлайн. Поскольку я мобильный разработчик, то создание сайта вызывало у меня много вопросов. А время поджимало, поэтому я решил, что пора начинать регистрацию на соревнование, а уже потом по ходу делать сайт. Форму для регистрации я сделал на Google Forms с сохранением этого всего добра в Google Sheets. Для того, чтобы иметь доступ к этим данным с любого устройства, я решил использовать БД на Firebase. Для синхронизации я использовал сервис Zapier, который дергает Cloud Function из того же Firebase. В итоге все данные после регистрации оказываются на Firebase в удобной для работы форме.

Для решения проблемы с разрывом в уровне подготовки было решено разбить участников на 2 дивизиона. Div1 — для опытных олимпиадников, Div2 — для остальных. Но 9 классу было морально тяжело соревноваться с 10 и 11, поэтому для них был добавлен еще Div3. При этом, если было желание, они могли регистрироваться и в Div2, и в Div1.

Для подсчета текущего рейтинга было необходимо для каждого участника стягивать его страничку ACMP, доставать из нее данные и отправлять их на Firebase. Для этой цели я написал небольшое консольное приложение на Kotlin, которое каждые 10 минут выполняло описанную выше процедуру. Поначалу все это работало у меня на ноуте, поэтому работало не постоянно. Это было явной проблемой, поэтому я искал варианты, где бы это запустить. Бесплатные сервера типа Amazon EC2, Google Cloud Engine у меня по какой-то причине поднять не получилось (возможно, из-за отсутствия опыта). В итоге в голову мне пришла идея запустить мой скрипт на Raspberry PI — оставалось только ее раздобыть...

Поскольку в соревновании теперь было целых 3 дивизиона, то и призовых мест соответственно должно было быть больше в 3 раза. Я решил поискать дополнительных спонсоров среди своих друзей. К нам присоединились моя девушка Алла Дубовская и сокомандники по спортивному программированию Дмитрий Смерчинский и Виталий Обидейко. Благодаря им призовой фонд вырос до 6000 грн, и мы смогли позволить себе приобрести Raspberry PI Model 3B в качестве приза за первое место в Div1. Полный список призов можно посмотреть здесь.

Полный призовой фонд

Соревнование стартовало 2 ноября 2017 года. Пора было приниматься за сайт. Немного погуглив, я наткнулся на очень простое решение — сделать сайт на основе примера на Node.js от Heroku. Табличка с результатами была готова в течение 3 часов и залита на тот же Heroku.

Для того, чтобы усилить конкуренцию и поощрить общение между участниками, я создал чаты в Telegram, по одному на каждый дивизион. Кроме этого я сделал простенького Telegram-бота, который каждые 10 минут писал о том, кто и какие задачи решил и сколько рейтинга набрал. Если посмотреть на графики набранного рейтинга по дням (c 10 по 20), то 2 эти действия определенно сильно повлияли на активность участников чемпионата.

Суммарный набранный рейтинг по дням (X — день соревнования, Y — рейтинг)

Разработка

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

Я разослал приглашение по чатам и стал ждать — откликнулось 8 человек. Думаю, что желающих было больше, просто побоялись, что не справятся :) Контингент был абсолютно разный — кто-то умел только немного С++, кто-то умел Git и JS.

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

Часть задач выполненных во время марафона

Под конец марафона все школьники освоили базовые команды консольного Git, умели запускать сайт на Node.js локально, верстали на HTML/CSS, немного писали на JS и Kotlin. Полный список разработчиков можно посмотреть здесь.

Итоги

Второй чемпионат проходил на протяжении 81 дня. За это время зарегистрировалось 56 участников — 54 из них решили хотя бы одну задачу. В сумме школьники решили более 4000 задач, набрав при этом более 85 000 рейтинга. Максимальный набранный рейтинг — 8259, для сравнения мой текущий рейтинг на ACMP — 12836, а всего можно набрать — 28753.

По завершении Code Marathon 2.0 был проведен опрос, в котором приняло участие 26 респондентов. Вот несколько интересных графиков:

И напоследок несколько ответов на вопрос «Что вам больше всего понравилось в Code Marathon 2.0?»:

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

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

Выводы

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

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

Ссылки

• Официальный сайт чемпионата
• Исходный код приложения на Kotlin
• Исходный код сайта
• Вспомогательные скрипты
• Тестирующая система DOTS
• Презентация с награждения
• Исходный код Code Marathon 1.0
• ACMP
• Сайт школы

Мои контакты: LinkedIn, GitHub, Instagram.

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

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

Я розділив ці поради на дві категорії: для начальників усіх рівнів та для членів команд незалежно від досвіду та спеціалізації.

Поради начальникам

• Не визнавайте, що ви не знаєте чогось, інакше вас вважатимуть слабким. Завжди можна змінити тему розмови і повернутись до неї пізніше після відповідної підготовки або ж не повертатись ніколи, якщо не хочеться.
• Баланс між особистим та робочим життям — це всього лише модне, лівацьке словечко, виправдання, щоб працювати менше. Справжній успіх досягається важкою, невпинною працею. Не соромтеся писати повідомлення, листи вашим підлеглим чи навіть телефонувати після роботи, на вихідних та під час свят. Спостерігайте, як швидко вони відповідають. Іноді можна надіслати листа цілій команді чи навіть особисто запушити коміт посеред ночі, щоб продемонструвати, що на відміну від них, ви ніколи не відпочиваєте, і змусити їх почуватись винними.
• Не діліться ніякою інформацієюпро цілі та плани компанії з підлеглими. Менше знають — краще сплять.
• Попри всю привабливість Scrum як підходу, в ньому все ж є один фатальний недолік: стендапи трапляються лише раз в 24 години, а це ціла вічність. Ви повинні цікавитись прогресом щонайменше кожних кілька годин, в ідеалі — особисто. Так ви можете переконатись, що люди не байдикують і відчувають достатньо тиску, щоб не збавляти темп до наступної перевірки.
• Щодо процесів — це всього лише інструменти. Кому, як не вам, знати про всі поточні і нові пріоритети? Не соромтесь переривати будь-який процес та розставляти пріоритети заново.Якщо робити так достатньо часто, ваші підлеглі будуть готові до будь-чого і не зважатимуть на відсутність конкретних цілей. Це по-справжньому гнучко!
• Щоб краще планувати проекти — розбийте їх на якомога більше маленьких шматків та оцініть кожен з них наперед в годинах. Ваш начальник оцінить таку деталізацію в плануванні!
• Не засмучуйтесь щодо скасування чи перенесення запланованих зустрічей з вашою командою в останній момент. На відміну від підлеглих — ви зайнята людина і ваш календар не знає відпочинку.
• Інший спосіб досягати більше та натренувати вашу команду, як справжніх «Морських котиків», — це розумові вправи з перемикання контексту. Час від часу давайте підлеглим по кілька різних завдань, які потрібно виконувати одночасно та насолоджуйтеся подвійним чи потрійним приростом продуктивності!
• У певний момент ви відчуєте, що знаєте своїх підлеглих краще, ніж вони знають самих себе. Пора приймати рішення за них, щоб уникнути низької продуктивності! Один із перевірених часом способів — це призначати конкретні завдання конкретним підлеглим замість того, щоб дати автономії (інше словечко, що насправді маскує анархію) шанс закрастись у вашу команду. Підлеглі повинні відчувати абсолютну, особисту, майже батьківську відповідальність за виконання кожного призначеного та оціненого вами для них завдання!
• Ваші підлеглі повинні завжди пам’ятати, що помилки недопустимі. На кожну помилку повинен бути знайдений винуватець і жорстко покараний. З іншого боку, такі помилки часто перетворюються в прекрасні, невмирущі жарти для вечірок: «А пам’ятаєте, як Петя завалив базу даних в продакшені? Пацан ще кілька днів ходив білий, як папір, і пив валер’янку! Ха-ха-ха-ха!».
• Чесно кажучи, ви насправді не можете довіряти підлеглим, колегам чи людям загалом, але ви вже це, мабуть, знаєте.
• Коли настане час давати підвищення підлеглим, обирайте лише своїх друзів чи людей, що ніколи не піддають сумніву ваш статус та не задають дурних запитань.
• Ніхто не ідеальний: знайдіть кілька недоліків чи слабких місцьу кожному з ваших підлеглихта пам’ятайте про них, щоб мати причину відмовити у підвищенні, коли вони попросять. Це перевірений спосіб тримати їх самооцінку низькою і змушувати працювати більше.
• Коли ваш начальник злий і невдоволений роботою вашої команди — обов’язково передайте цю злість та невдоволення на своїх підлеглих. Вони повинні відчувати весь гнів та повну особисту відповідальність працювати ще краще, щоб встигнути до встановлених термінів!
• Але все-таки краще не зізнавайтесь своєму начальнику, коли є проблеми в роботі. Скажіть, що все добре, а самі використайте всі важелі впливу на своїх підлеглих, щоб вони усунули проблеми якнайшвидше і будь-якою ціною.
• Проекти зазнають невдач через недосвідченість вашої команди. Проекти стають успішними завдяки вашим унікальним лідерським якостям.
• Бути начальником означає контролювати все. Не дозволяйте будь-яким зовнішнім комунікаціям зійти з вашого радару: ваша команда не повинна консультуватись, розмовляти чи навіть дивитися в бік інших команд, не кажучи вже про інших начальників.
• Навіть якщо ви вже давно не писали ніякого програмного коду чи зовсім не маєте технічного досвіду — ви все одно повинні знати краще за підлеглих, які інструменти, технології, архітектури чи програмний дизайн вони повинні використовувати для вирішення задач.

Поради членам команд

• Не стримуйтеся, коли розмовляєте — говоріть так голосно, щоб колеги вас чули навіть в навушниках.
• Робота — це нудно. Час від часу розважайте колег посиланням на кумедну картинку чи зачитуванням останніх новин.
• Час — це гроші. Коли ви застрягли з якоюсь проблемою, не витрачайте навіть п’яти хвилин дарма на пошуки відповіді в Googleчи на спроби розібратися самостійно — одразу запитайте колегу. Бажано особисто.
• Коли не можете вирішити якусь проблему та соромитесь зізнатися в цьому — невинна брехня на стендапі допоможе виграти кілька годин, а то і днів часу.
• Один з найкращих способів зберігати позицію і мати повагу колег — володіти таємними знаннями. Тримайте при собі все, що дізнаєтесьі вивчите про вашу роботу та професію, щоб уникнути конкуренції.
• Додайте трохи складності в проект, коли відчуваєте, що він надто простий і легкий для розуміння. Інакше в чому ж ваша цінність як працівника, якщо ваш проект може збагнути і взяти на себе будь-хто?
• Інший спосіб залишатися затребуваним на ринку професіоналом — знати якнайбільше сучасних технологій та фреймворків. Використовуйте нові мови програмування та технології на кожному новому проекті. Якщо немає нових проектів — час від часу переписуйте існуючі з використанням новинок.
• Вас не повинні звинувачувати у помилках колег. Переконайтеся, що всім відомо, чия помилка це була.
• На противагу попередньому пункту, не соромтесь розповідати усім про ваші навіть найменші досягнення, щоб отримувати визнання та повагу.
• Працюйте лише над своїми завданнями. Не витрачайте час на допомогу колегам, це не входить у ваші обов’язки.
• Якщо є можливість — обирайте лише цікаві завдання. Рутиною нехай займаються інші.
• Намагайтеся уникати присутності більш досвідчених та талановитих колег, бо є ризик виглядати погано на їх фоні.
• Час від часу в присутності інших задайте колезі ніби мимохідь якесь складне запитання, на яке він точно не знає відповіді. Здобудете захоплення усіх інших вашими знаннями та досвідом.
• Хочете бути кращими за інших у своїй команді та отримувати підвищення? Просто працюйте більше!Якщо ви працюватимете всього лише на дві години довше за колег щодня, це дасть вам щонайменше 40 годин фори щомісяця!
• Не витрачайте час на комунікацію. Говоріть якомога менше під час зустрічі з колегами. Нехай додумують решту самі, а хто не зрозумів — його проблеми.
• Під час робочої суперечки не соромтесь поділитись посиланнями на блоги та статті відомих у вашій сфері людей, щоб довести щось колегам. Перекрийте точку зору колег стороннім авторитетом замість того, щоб вислухати її.
• Результати вашої роботи — це продовження вашого «Я», це ваше дитя, частина душі. Не дозволяйте критикувати вашу роботу нікому!
• Не соромтесь скаржитися на недосконалі рішення чи процеси. Рано чи пізно знайдеться хтось, хто нарешті все полагодить!
• Якщо колега не справляється з роботою — це тому, що він лінивий або дурний. Якщо ви не справляєтесь з роботою — це тому, що так складаються обставини.
• Будьте оптимістичними, оцінюючи складність завдань.

Висновок

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

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

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

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

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

Идея

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

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

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

Александр Пойманов, создатель CLAP

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

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

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

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

Реализация

Создание CLAP, включая проектирование, разработку и тестирование, заняло 3 года. В общей сложности мы вложили в R&D около 7 млн долларов.

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

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

Команда CLAP

Если говорить о стеке технологий, мы использовали Java, Spring (MVC, Boot, Integration, Security), JMS, реляционные и нереляционные базы данных, Docker, Selenium, Cucumber. На сервере — микросервисная архитектура.

Для производства «железа» и всех необходимых микросхем мы построили в Виннице автоматизированную линию сборки. Оборудование закупали в Южной Корее и США.

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

Каким получился продукт

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

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

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

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

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

За время разработки мы несколько раз меняли дизайн датчиков, уменьшая их размеры. Конечные размеры устройств стали на 30-50%меньше, чем были первые прототипы. Речь идет не только об эстетике форм: от геометрии датчиков зависит и качество — к примеру, простота и легкость крепления.

Функциональность

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

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

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

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

Результаты и планы

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

С лета 2018 года CLAP будет устанавливаться в новых домах «Укрбуд»: мы заключили эксклюзивный контракт на более чем 160 тыс. устройств для 20 тыс. квартир. В то же время, пока длится контракт, мы не можем сотрудничать с другими застройщиками в Киеве.

В четвертом квартале 2018 года планируем начать продавать продукт первым розничным покупателям. Система будет стоить от 500 до 4 тыс. долларов в зависимости от размера квартиры, комплектации, количества датчиков и требований к задачам, которые должна решать. Сейчас мы участвуем в международных выставках, активно изучаем рынки разных стран и думаем, на какие из них лучше выходить вначале. Уже сейчас ведем переговоры с потенциальными клиентами из США, Германии, Венгрии, Израиля, Казахстана, Узбекистана и Беларуси.

Привет, меня зовут Влад, и я ... (нет, не то, что ты подумал) я — тимлид. «Войти в АйТи» случилось со мной в 2010 году на позиции системного администратора (или как сейчас стильно-модно-молодежно — SRE) маленькой сервисной компании, название которой нельзя произносить вслух :)

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

Если ты, как и я когда-то, мучал или продолжаешь мучить себя вопросом: «Есть ли жизнь после Senior?», то спешу с ответом — есть. Это либо все тот же Senior, когда ты любишь писать код с закрытыми глазами, при этом помешивая ложкой свой кофе, и это на самом деле ок! Либо архитектор, либо тимлид. Давай на последнем мы и остановимся.

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

Так, мы уже определились, что с технической стороны ты определенно крут, но какими софт скиллами ты должен обладать на позиции Senior+ / Team Lead? Однозначный ответ дать достаточно сложно. Слишком много переменных и обстоятельств. Проект, команда, стиль управления, бизнес-боли, которые ты лечишь, — все это катализаторы различных навыков человека.

SOLID. Что в себе несет аббревиатура, понимает даже Middle Developer. Но не каждый осознает, какую цель преследуют эти принципы. На первый взгляд, все они направлены на стандартизацию и улучшение качества кода. Но если это так, то зачем размножать и без того описанные best practices? Будь то PSR, если говорить о PHP, или Coding Guidelines в случае с Java.

SOLID направлен на самодисциплину и культуру разработки. В наших же практиках мы пошли дальше и применяем SOLID для персонального развития всех и каждого в команде. Итак, что такое SOLID с точки зрения разработчика, который стремится в Senior+ level?

S — Smart

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

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

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

O — Obvious

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

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

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

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

L — Loyalty

Лояльность — композитное понятие. Оно проявляется во многом, начиная от пропаганды культуры и до общения 1-2-1.

В нашем же случае, лояльность — двухстороннее понятие. Лояльность, проявляемая лидером, порождает лояльность команды.

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

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

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

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

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

Забудь про микроменеджмент. Удерживай баланс свободы и инициативности в команде.

А как насчет геймификации? Это работает! Преобразуй рутину в соревнование, где соперником для каждого является его «Я», а целью — командные достижения. Пример из нашего опыта: каждый успешный pull request засчитывается в общий счетчик достижений команды. Достигая определенных значений, приложение выдает achievement и усложняет достижение новой цели. Если кто-то допускает критическую ошибку (например, в разрез прописанным стандартам разработки) — команда голосует, счетчик обнуляется и виновник торжества ставит всем пиво. Назвали мы это Beer Mistake. Чем дальше прогресс, тем пристальнее и ответственнее ребята подходят к решению своих задач.

С применением подобной геймификации мы получили метрики производительности. Да-да, всякие Jira считают Burn Down, но это не про клиентские или менеджерские графики. Это про внутреннюю производительность, которую оценивает команда.

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

I — Initiative

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

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

D — Driver

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

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

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

Ты не начальник. Ты — лидер. Никто не любит боссов, кроме человека-кодера, которому нужны четкие задачи и оплата. Мы в своей практике упразднили вертикальный стиль управления. Строгая горизонтальность! Junior ты или Architect, не имеет никакого значения. Твое мнение — это Грааль. Мы работаем ради общей цели, а различает нас только круг обязанностей. Лидер всегда находится в лодке, а не у штурвала. Управлять лодкой можно и без руля, общими усилиями ;)

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

В заключение

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

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

Находите общий язык и вершите великие дела. Спасибо за внимание, у меня все :)

Полезное чтиво

Том ДеМарко «Deadline. Роман об управлении проектами»

Том ДеМарко «Человеческий фактор: успешные проекты и команды»

Ричард Брэнсон «Теряя невинность»

Робота техрайтера в Україні стає все затребуванішою. До прикладу, на момент написання цієї статті у розділі Technical writer на DOU міститься 56 вакансій. Парадоксальною особливістю цієї професії є те, що їй ніде не навчають. Спеціалізованих програм з technical writing немає ні в українських, ні в європейських університетах. Нібито такі програми все ж є в кількох університетах США, але навіть якщо і так, їх випускники навряд чи коли-небудь задовільнять попит на українському ринку праці.

Сьогодні в Україні налічується декілька сотень техрайтерів. Нещодавно з’явилася спільнота у Facebook Technical writers of Ukraineдля обміну досвідом і організації зустрічей. Тож як вони потрапляють у професію? Де навчаються і як знаходять своє перше місце роботи? Про це ми запитали українських техрайтерів з різних IT-компаній.

Заряна Ніколаєва, Information Manager в NetEnt

3 роки в техрайтингу

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

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

Згідно з описом вакансії вимагали, перш за все, гарну англійську. Зрозуміло, що професії Technical Writer у нас не вчать і що більшість додаткових навичок опановуватиметься в процесі. Тестове завдання мало визначити все: мій рівень володіння мовою, вміння дотримуватись заданого стилю, увагу до деталей і творчий підхід. Воно складалось із завдання на опис функцій гри та завдання на аналіз існуючого опису. Досвід копірайтингу став у пригоді! Чимала складність для мене полягала в тому, що такі ігри (відеослоти) я ще не бачила, і тому спочатку аналізувала їх сама, а потім описувала, як для таких самих новачків — щоб точно все було зрозуміло :)

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

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

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

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

Евгений Чеканов, Technical writer в Betlab

2 года в техрайтинге

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

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

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

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

Профессиональный рост.Я вот уже год в продуктовой компании, осваиваю новые шаблоны документации (BRD и Concept), изучаю MadCap Flare (интересная и мощная вещь, но не без изъянов). В перспективе считаю, что при должном изучении процессов анализа и менеджмента райтер может без особых усилий расти в сторону бизнес-анализа и управления проектами. Работа на данной позиции обязывает вникать в весь продукт и во все его направления и нюансы, и зачастую бывает так, что райтер владеет большей информацией, хоть и верхнего уровня, по продукту в целом.

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

Олег Романенко, Technical writer у GlobalLogic

понад 5 років у техрайтингу

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

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

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

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

Поради людям, які хочуть стати техрайтером, але не знають з чого почати. Учіть технічну англійську. Я почав з того, що роздрукував «Microsoft Manual of Style» і читав його з ручкою, зазубрюючи незнайомі слова. Забудьте про рідномовну локалізацію своїх додатків, завжди обирайте американську англійську. Читайте англійською, гугліть англійською. Учіть основи програмування та баз даних. Це дасть вам можливість спілкуватися з розробниками їхньою мовою.

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

Марина Кібченко, Technical Writer в AltaReturn

4 роки в техрайтингу

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

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

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

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

З кількох техрайтерів-початківців, яких узяли водночас, якнайшвидше були потрібні повноцінні робочі одиниці, тому задачі посипалися майже одразу. Чесно кажучи, голова йшла обертом. Роботи було вдосталь: окрім написання та перекладу текстових документів, ми займалися локалізацією web-рішень, створенням web-довідок, FAQ, навчальних відео для користувачів і т. д. Як я тепер розумію, далеко не в усіх компаніях техрайтер може робити і робить все це. Але для першого місця роботи, для «хрещення вогнем» — кращого годі й бажати. Та все ж найбільше я вдячна цій компанії за колектив техрайтерів. Саме він, без перебільшення, став визначальним у моїй історії. Колеги настільки щедро ділилися знаннями, що ще й досі, зізнаюся, мені важко прийняти той факт, що є люди з іншим підходом до співпраці, до навчання новачків. Користуючись нагодою, передаю віртуальний привіт і подяку моєму колишньому колезі, який теж ділиться своїм досвідом у цій статті.

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

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

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

1. «Як писати?» — опанування навичок техрайтингу (специфічні програми та додатки; стиль письма, формати тощо).
2. «Про що писати?» — здобуття загальнотехнічних навичок, які зокрема допоможуть зрозуміти програму чи web-рішення, яке необхідно описати.
3. «Що писати?» — робота з вузькоспеціальною англійською, моніторинг галузевої термінології.

Це все не так складно, як може здаватися. Раджу бути допитливим, кмітливим і уважним до деталей.

Карина «Карен» Сорей, Technical Writer/Editor в Cossack Labs

3,5 года в техрайтинге

Опыт работы до техрайтинга. Я получила высшее образование в Харьковском национальном университете им. В. Н. Каразина — переводчик английского и немецкого языков, менеджер медиа-коммуникаций. До того как стать техрайтером, я работала переводчиком, копирайтером — писала на технические темы, была PR-менеджером в компании, разрабатывающей хардверные и софтверные решения для шоу-бизнеса. Кроме того, всегда параллельно занималась музыкой. Сейчас, когда я пишу документацию к серьёзному криптографическому софту, занятия музыкой помогают держать в жизни ментальный баланс между «техникой» и «лирикой».

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

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

В Cossack Labs я попала благодаря DOU. Когда я на какое-то время решила отдохнуть от бешеного темпа работы в шоу-бизнесе и пофрилансить, меня спонтанно начали «хантить» рекрутеры в соцсетях. Активно я работу тогда не искала, но решила посмотреть, что вообще происходит на рынке вакансий для техрайтеров. И нашла на DOU вакансию от Cossack Labs, которая мне так понравилась, что cover-letter к формальному резюме у меня выглядел примерно как «Ааа! Чуваки, вы крутые, я хочу у вас работать!» (не рекомендую повторять в реальной жизни ;))

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

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

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

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

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

Главная проверка на профпригодность — сможете ли вы объяснить что-то действительно сложное так, чтобы вас понял 5-летнийребёнок. И это — не просто упражнение, это работает и на реальных читателей. «Объясни мне Zero-knowledge Proof так, будто мне 5 лет» — до сих пор одна из самых популярных статей в Medium-блоге Cossack Labs.

Читайте также:Каково это — быть техрайтером.

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

Антон Славута, Senior Software Engineer в ЕРАМ

6 лет в IT, в прошлом — проводил семинары по методике оздоровления и психологии

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

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

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

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

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

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

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

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

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

Моя карьера началась в ЕРАМ, c этой компанией я сотрудничаю до сих пор. У меня установился хороший контакт с командой, через месяц я уже полностью «влился» в коллектив. Коллеги отлично меня приняли. Частично помогла практика в области психологии, но и в целом я всегда был открытым и коммуникабельным.

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

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

Единственное, что мне больше нравилось в бывшей работе — это возможность больше времени проводить на свежем воздухе :)

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

Если единственная мотивация для перехода в IT-сферу — это желание заработать, то я бы не советовал даже пробовать. Нелюбимая работа не будет стимулировать к развитию. Что касается обучения, для старта я бы рекомендовал «классические» языки: C# или Java. И, конечно, английский.

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

Андрей Лазарев, QA Technical Lead в Terrasoft

3 года в IT, в прошлом — экономист

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

До ІТ работал в 5-тиразных банках. Начинал с позиции младшего экономиста: обзванивал клиентов и собирал информацию о потенциальных заёмщиках. Впоследствии строил процессы принятия решений по выдачам кредитов. Участвовал в проектах по внедрению автоматизации принятия решений.

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

Ещё за 3 года до перехода в ІТ я понимал, что надо что-то менять. Я не сильно понимал, как мне развиваться дальше в банковской сфере. Однако сначала никаких телодвижений не производил, так как находился в комфортной зоне, не жаловался на доход, условия труда, рабочие задачи. Комфортная зона закончилась, когда курс доллара вырос с 8 до 16, а впоследствии до 25. Решение, что пора что-то менять, принял за один день.

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

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

О работе в ІТ.Рассылать резюме в компании я начал с первого дня обучения на курсах по тестированию. Составил систему с таблицами и графиками конверсии откликов на резюме, писал разные сопроводительные письма. Зачастую если моё резюме замечали и оно вызывало интерес, мне звонили спросить об опыте работы в тестировании. А так как его не было, то собеседование не назначали.

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

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

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

Андрій Воловик, Senior QA Engineer & Scrum Master в Digicode

3 роки в IT, в минулому — інженер-конструктор

Я навчався в НТУУ «КПІ» на радіотеху. З третього курсу влаштувався молодшим науковим співробтіником в галузі телекомунікацій в Інститут електроніки та зв’язку УАН. Через 2 роки вирішив, що хочу спробувати себе в ролі інженера-конструктора навігаційного обладнання. Подав резюме на ДП «Антонов», пройшов співбесіду, і після двох тижнів паперової тяганини мене взяли.

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

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

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

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

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

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

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

Основними джерелами з теорії тестування були книжки «Testing Computer Software»Сема Канера та «How Google Tests Software»Джеймса Уіттакера, а також статті на DOU та інших подібних ресурсах. Для вивчення SQL, HTML, CSS, JSON, XML, XPath використовував W3Schoolsта книжку «Head First SQL Your Brain on SQL»Лінна Бейлі. Також дивився відеоуроки Portnov Computer School.

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

Про роботу в ІТ.Я влаштувався на свою першу роботу досить швидко. Коли вже відчув впевненість в своїх силах, то відразу створив резюме, дав його на рев’ю друзям і почав шукати відповідні вакансії. Відправив резюме приблизно 20 компаніям. На наступний день мені зателефонувала HR, задавала питання по теорії тестування та SQL. Далі була очна співбесіда з технічним спеціалістом, дуже тяжка та стресова. Згодом мені зателефонували і запропонували роботу.

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

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

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

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

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

Юрий Федорченко, Project Manager в Provectus

8 лет в IT, в прошлом — артист музыкального театра

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

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

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

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

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

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

Об обучении.Азы менеджмента проектов и продукта я изучил еще в университете. Нужно было только освоить IT-контекст. Для этого читал PMBOK, книги по Agile-методологиям, QA-процессам, базам данных, ООП. Технические знания получал от ребят, с которыми работал: внимательно их слушал, пытался вникнуть, запоминал.

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

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

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

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

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

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

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

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

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

Тетяна Гладій, Senior Front-end BI Developer в Infopulse

2,5 роки в IT, в минулому — бренд-менеджер

У мене дві вищі освіти: закінчила мехмат в КНУ ім. Шевченка та маркетинг в КНЕУ ім. Гетьмана. Ще студенткою працювала супервайзером і організовувала команду промоутерів.

Моя перша і єдина офіційна робота до ІТ була у відділі маркетингу в міжнародній компанії Henkel. Я прийшла туди на безкоштовне стажування і за короткий проміжок часу побудувала кар’єру. Протягом 2,5 років була бренд-менеджером відомих марок Somat, Pur, Clin.

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

Про роботу в ІТ.Я не прагнула працювати в ІТ і не навчалась спеціально — просто цікавилася тим, чим хотілося займатися. Згодом мій друг перейшов у Infopulse і подав моє резюме у HR-відділ. Через 5 місяців мені передзвонили — це було досить неочікувано для мене на той час.

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

Протягом стажування я отримала неосяжний багаж знань з Tableau, QlikView, Crystal Report, AO. Займались і теорією, і практикою. Вже через 2 місяці мене взяли на проект. З того часу я працюю у сфері Business Intelligence, займаюся розробкою звітів для бізнес-аналізу. Спочатку мені часто не вистачало айтішного бекграунду, але з часом я звикла до сленгу та почала розуміти речі, які здавалися незрозумілими раніше.

Саме в Infopulse я вперше познайомилася з робочим процесом Scrum. Люди, які працюють у не ІТ-компаніях, навіть не здогадуються, наскільки правильно може бути організований процес роботи. Також мене здивувала відсутність телефона на робочому місці. А тепер я думаю: навіщо він взагалі? :) Всі зустрічі ми проводимо по скайпу, що неймовірно зручно.

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

Про можливості.З того моменту, як я відчула всі переваги роботи в ІТ, я рекомендую змінювати своє життя всім, хто незадоволений сьогоднішнім днем. Якщо вас теж цікавить Business Intelligence, я раджу починати з курсів BI QA Engineer, адже тестування — найбільш посильний фах для людей з іншої галузі. Вам буде потрібно вивчити SQL, QlikView, Tableau. В інтернеті є безліч безкоштовних сервісів із задачками та відеоуроками — потрібно лише бажання та щоденна робота, хоча б по 2 години в день.

Владимир Арутин, QA Engineer в HYS Enterprise

2 года в IT, в прошлом — финансист

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

Год за годом я обрастал всевозможными связями, клиентским портфелем, опытом и новыми знаниями. Однако не нужно было обладать аналитическими способностями, чтобы рассмотреть мировой тренд развития коммерческих банков. Глобальная уберизация финансового сектора, расцвет финтех-стартапов и блокчейнов склоняли весы не в пользу банков. Знаменитое «Banking is essential, banks are not», сказанное Биллом Гейтсом еще в 2008 году, стремительно воплощалось в жизнь. Можно было подобно Eastman Kodak наслаждаться достигнутым положением дел, но правильней было смотреть в будущее и действовать на опережение.

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

Об обучении.Любовь к учебе с детства вела меня сквозь калейдоскоп учебников, книг, олимпиад, медалей, курсов и семинаров, поэтому мне было легко освоить первые книги по тестированию и разобраться с процессами. Сегодня учиться легко: вокруг нас есть колоссальный океан информации, которая доступна 24/7.

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

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

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

Позже я получил сертификацию ISTQB Foundation Level, прошел курсы QA Automation, обучение на Udemy, Coursera, Edx и успешно сдал ISTQB Advanced Level, Test Manager.

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

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

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

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

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

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

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

Виталий Залевский, Project Manager в DataArt

7 лет в IT, в прошлом — историк

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

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

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

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

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

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

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

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

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

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

Олег Шкода, Junior QA Engineer в Luxoft

1 рік в IT, в минулому — менеджер

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

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

Після закінчення університету декілька місяців працював у молодіжному центрі при КМДА. Потім — менеджером у відділі маркетингу логістичної компанії.

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

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

Я претендував на позицію тестера ПЗ. На той час навіть не мав чіткого розуміння, що це таке та що потрібно буде робити. Тестувати ПЗ я навчався за методом learning by doing — безпосередньо на роботі. Доводилося чимало вивчати самостійно, по книгах, статтях та відеороликах з YouTube.

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

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

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

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

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

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

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

Софья Герман, Lead QA Artist в Wargaming

4 года в IT, в прошлом — врач-реабилитолог

Я училась в НУФВСУ на факультете физической реабилитации. Затем работала в Главном военном госпитале в хирургических отделениях и в отделении травматологии. Позже — в Центре реабилитации инвалидов, с детьми, страдающими ДЦП.

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

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

Об обучении.Около 10 месяцев я училась моделированию самостоятельно — по урокам с YouTube. Ходить я особо не могла, поэтому практически всё время занималась обучением, читала специализированную литературу, общалась на форумах и мечтала о должности 3D-моделлера.

А потом узнала о вакансии Art QA в Persha Studiia и отправила резюме. Меня взяли на позицию Junior. Самым сложным на собеседовании было снова начать общаться с людьми после 10 месяцев отчуждения.

О работе в ІТ.За 2 месяца я практически полностью вошла в рабочий процесс и могла самостоятельно выполнять задачи. С рабочими системами и процессами разобралась достаточно быстро.

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

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

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

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

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

Константин Чижов, Game-дизайнер в Plarium

4 года в IT, в прошлом — инженер-исследователь

Я закончил ХНУ им. В. Каразина, выучился на инженера-радиофизика. Сразу после окончания университета пошел работать в Научный центр «ХФТИ». Там проработал 3 года, прошел путь до инженера-исследователя первой категории. Дальше моя карьера (если это так можно назвать) двигаться не могла, несмотря на наличие публикаций, — научный сотрудник обязан иметь кандидатскую степень.

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

Я начал искать работу по направлениям «копирайтинг/локализация» и так попал в Plarium на позицию копирайтера/сценариста.

Об обучении.Со временем я обучился мануальному тестированию, работе с репозиториями, освоил прототипирование в Axure, работу в Unity, научился базовому анализу KPI, конструкции/деконструкции игровых фич. Чтобы освоить дополнительные специализации, записался на QA Boot Camp от Ciklum, который дал мне общее понимание процессов тестирования.

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

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

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

О работе в ІТ.Чтобы получить свою первую работу в отрасли, мне понадобилось порядка месяца активных поисков. В начале было тяжело «попасть в выборку», которую серьезно рассматривают HR, потому что у меня в резюме не было опыта работы в релевантной области. Потом товарищи рассказали мне, что личные/фан-проекты тоже учитываются как опыт работы, особенно если их можно показать в портфолио. Так дело сдвинулось с мертвой точки.

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

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

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

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

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

Сучасні технології IoT так стрімко інтегруються в наше повсякденне життя, що зараз вже нікого не здивуєш системою «розумний дім». Проте не все так просто, як може здаватися на перший погляд: незважаючи на широку популярність систем smart home, досі не існувало уніфікованого рішення, яке б дозволяло керувати пристроями (комплексними компонентами) від різних виробників. Команда розробників GlobalLogic створила своє програмне забезпечення Gateway SDK (software development kit), яке забезпечує керування комплексними компонентами розумного дому.

Реалізація

GL SmartHome Cloud Solution — це внутрішня розробка львівського офісу компанії, готове продуктове рішення, що може застосовуватись для автоматизації роботи багатьох функцій (керування опаленням, світлом, перевірка рівня забрудненості повітря і т. д.) сучасного будинку (квартири) чи навіть цілого розумного міста.

Наразі рішення представлене у вигляді функціонального демостенду: це міні-будинок, обладнаний новітнім устаткуванням з використанням провідних IoT-технологій (Java, Docker, реляційні бази даних).

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

Як функціонує рішення та які прилади підтримуються хмарною платформою?

Унікальність рішення полягає в тому, що воно об’єднало керування приладами різних виробників в одну систему через модуль IFTTT (If This Then That). GL SmartHome Cloud Solution підтримує 55 приладів, і їх кількість постійно збільшується. Серед локальних приладів є кольорові лампи Philips, термостат Honeywell, камера Nest та ін. Ми вибирали найпопулярніші прилади, які доступні в США. Також ми використовували Amazon Web Services, інноваційні апаратні платформи (ARM Cortex: Raspberry PI 2-3, Qualcomm Dragonboard 410, x86-64: Any) та стеки з’єднання IoT. Віддалений доступ користувача зі з’єднаними між собою приладами розумного будинку здійснюється через такі бездротові інтерфейси, як Z-Wave, Zigbee та протоколи Wi-Fi.

Рішення підтримує високе навантаження — більше 50 000 одночасних запитів на cloud для зміни налаштувань доданих приладів.

GL SmartHome складається з референс-gateway, cloud-рішення з використанням Amazon-сервісів, референс-Android-додатка та демостенду розумного будинку з реальними приладами.

Яка архітектура Cloud-рішення?

Як вже було зазначено, Cloud-рішення побудоване за допомогою Amazon-сервісів, серед яких:

• EC2 (Amazon Elastic Compute Cloud) — задає інфраструктуру серверам;
• ECS (Amazon EC2 Container Service) — використовує докер для централізованого об’єднання контейнерів в кластери і безпосереднього управління ними;
• RDS (Amazon Relational Database) — окремий сервіс для баз даних, де зберігаються акаунти, користувачі та сценарії;
• VPC (Amazon Virtual Private Cloud) — сервіс для управління мережами, що створює приватні мережі (із закритим доступом);
• IoT — сюди входить MQTT брокер, який ми використовуємо;
• S3 (Amazon Simple Storage Service) — сховище з різними розділами (buckets), у яких ми створюємо свої дані — сертифікати. До прикладу, ми використовуємо firmware для gateway як storage;
• SQS (Amazon Simple Queue Service) — сервіс, який формує черги для Java-додатків;
• SES (Amazon Simple Email Service) — мейл-сервіс від Amazon;
• SNS (Amazon Simple Notification Service) — сервіс для сповіщень.

Всі використані сервіси Amazon і Java-додатки ми поділили на 3 кластери:

1. Кластер з додатками для web і API, завдяки яким елементи розумного будинку є доступними через зовнішню мережу.
2. Logic-кластер, який поділяється на:
   
   • Time Server — відповідає за виконання сценаріїв з попередньо визначеним часом;
   • Notification service — відповідає за push-notifications, e-mail, SMS;
   • Gateway to cloud server — з’єднує gateway з cloud-ом. Він розділений на 2 додатки: пересилання MQTT-повідомлень, керування повідомленнями у черзі;
   • Rule engine — відповідає за створення та виконання. Він теж поділяється на 2 додатки, за тим самим принципом, що і gateway to cloud server.
3. Кластер адаптерів, які з’єднують пристрої через наш cloud з cloud-ом виробників девайсів. Кластер складається з чотирьох компонентів: adapter, consumer, publisher та четвертий компонент для черги. Adapter опрацьовує повідомлення, які надсилаються в cloud. Коли повідомлення повертається з відповіддю, publisher закидає повідомлення в чергу, а consumer бере їх з черги і опрацьовує.

Сервіси Amazоn були обрані для реалізації проекту тому, що вони стабільні, є адаптивними та гнучкими. Крім цього, AWS вибудували надзвичайно якісну безпеку інфраструктури, як фізично так і у всесвітній павутині, а це велика перевага коли йдеться про контроль доступу до вашої домівки.

Як інтегрована Amazon Alexa?

Також ми додали Amazon Alexa, яку запрограмували для взаємодії з нашим cloud-ом і керування розумним будинком через той самий cloud.

Amazon Alexa Integration

Які ще референс-компоненти входять до комплексу?

Окрім cloud-рішення, було також створено два компоненти, що допомагають швидко інтегруватися з уже розробленим cloud API.

Перший компонент — це програмне забезпечення Gateway SDK на основі Raspberry PI 2/3, що здійснює зв’язок між локальними пристроями, які комунікують, використовуючи бездротові інтерфейси ZigBee, Z-Wave, Wi-Fi, та здійснюють двосторонній зв’язок з cloud-ом, застосовуючи MQTT-протокол.

Стандартів щодо цього зараз практично не існує, в цьому і полягала основна складність — розробити уніфіковане рішення, яке дозволить керувати пристроями від різних виробників. Тому і було вирішено створити своє програмне забезпечення — Gateway SDK. Воно передбачає такі можливості:

• керувати пристроями, що працюють використовуючи бездротові інтерфейси ZigBee, Z-Wave, Wi-Fi;
• отримувати команди з мобільного додатку через cloud, використовуючи MQTT-протокол;
• виконувати IFTTT-сценарії, коли немає зв’язку з cloud;
• надсилати повідомлення про зміну стану девайсів на мобільний додаток.

Другий компонент — це мобільний демододаток на основі Android, який демонструє функціональні можливості cloud API та показує, як правильно ними користуватися.

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

Результати і плани

Над рішенням протягом 5 місяців працювали 30 експертів з різних технологій. Зараз роботу GL SmartHome Cloud Solution демонструють потенційним замовникам та під час офісних турів. Ми не можемо сказати, що це кінець проекту, він знаходиться в нас на саппорті і з досвіду — ми постійно розвиваємо свої ж ідеї. Тому якщо вам цікаві технології, починаючи від Embedded і закінчуючи Data Science, — долучайтесь до нашої команди!

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

1. Что вернет условие 2 <> NULL?

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

2 <> NULL

возвращает ложь (FALSE), как впрочем и условие

2 = NULL

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

Возвращаясь к сути вопроса, мы не можем сказать «Два не равно NULL» потому, что мы не знаем значения справа от знака неравенства, а там как раз может оказаться двойка.

2. Что вернет условие 3 NOT IN (1, 2, NULL)?

Здесь та же история, что и в предыдущем случае. Условие

3 NOT IN (1, 2, NULL)

возвращает ложь (FALSE), как и условие

3 IN (1, 2, NULL)

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

Другими словами:

3 IN (1, 2, NULL)

это то же самое, что и

(3 = 1) OR (3 = 2) OR (3 = NULL)

В случае с NOT IN условие:

3 NOT IN (1, 2, NULL)

это то же самое, что и

(3 <> 1) AND (3 <> 2) AND (3 <> NULL)

Как мы знаем из предыдущего примера, 3 <> NULLвозвращает ложь, а значит и все условие
(3 <> 1) AND (3 <> 2) AND (3 <> NULL)

тоже будет ложным.

3. Выполнится ли этот запрос?

SELECT 
	order_id,
	order_code,
	SUM(order_value)
FROM 
	orders
GROUP BY
	order_id

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

Если этот запрос будет выполняться в MySQL, то колонка order_codeдобавится в выражение GROUP BYавтоматически и запрос выполнится нормально. Если же этот запрос будет выполняться MS SQL Server, то по умолчанию будет сгенерирована ошибка. Впрочем, это поведение настраивается.

4. Почему не выполнится этот запрос?

SELECT 
	user_name,
	YEAR(user_birth_date) AS year_of_birth
FROM 
	users
WHERE
	year_of_birth = 2000

Запрос не выполнится из-за обращения к псевдониму year_of_birth в выражении WHERE. Дело в том, что псевдонимы полей в SQL используются для форматирования данных уже полученных из базы. Поэтому их можно использовать только в выражениях, которые отвечают за оформление результата, таких как GROUP BY, ORDER BYи HAVING. В выражениях, отвечающих за получение данных, таких как WHERE, нужно использовать оригинальные имена полей.

WHERE
	YEAR(user_birth_date) = 2000

5. Имеет ли значение порядок колонок в составном индексе?

Да.

CREATE NONCLUSTERED INDEX MyInd on users (user_name, user_birth_date);

это не то же самое, что

CREATE NONCLUSTERED INDEX MyInd on users (user_birth_date, user_name);

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

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

6. Какая разница между TRUNCATE TABLE table_nameи DELETE FROM table_name?

Фактически обе эти команды вызовут удаление всех строк из таблицы под названием table_name, но вот произойдет это совсем по-разному:

1. При вызове команды TRUNCATEтаблица полностью сбрасывается и создается снова, в то время как команда DELETEудаляет каждую строку таблицы по отдельности. Из-за этого TRUNCATEотрабатывает значительно быстрее.
2. Как следствие первого пункта, команда TRUNCATE не вызывает срабатывание триггеров и правил внешних ключей, то есть, очищая таблицу таким способом, можно не бояться каскадного удаления или изменения данных в других таблицах.
3. В отличие от DELETEкоманда TRUNCATE не транзакционная. То есть, если в момент ее вызова, таблица table_nameбудет заблокирована какой-либо транзакцией — может возникнуть ошибка.

7. Какая разница между типами CHARи VARCHAR?

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

1. Тип CHARхранит значение фиксированной длины. Если строка, помещаемая в колонку данного типа, имеет меньшую длину, чем длина типа — строка будет дополнена пробелами. Например, если в колонку типа CHAR(10)записать строку SQL, то она сохранится как SQL       .

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

2. Для типа CHARиспользуется статическое распределение памяти, из-за чего операции с ним быстрее, чем с VARCHAR.

Таким образом, тип CHARподходит для хранения строковых данных фиксированной длины (например, инвентарных номеров, хешей), а для остальных строк больше подойдут VARCHARили NVARCHAR.

8. Какая разница между типами VARCHARи NVARCHAR?

Тип NVARCHAR, пожалуй, самый универсальный из строчных типов данных в БД. Он позволяет хранить строки переменной длины в формате Unicode. В этом формате каждый символ занимает 2 байта, а сама кодировка содержит 65 536 символов и включает в себя все языки мира, в том числе иероглифы.

Тип VARCHARхранит данные в формате SACII. В этом формате каждый символ занимает 1 байт, но отельная кодировка содержит всего 256 символов. Из-за этого для каждого мирового языка выделяется своя кодировка.

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

9. Какая разница между UNIONи UNION ALL?

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

10. Какая разница между выражениями WHEREи HAVING?

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

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

Статья подготовлена на основе доклада Ярослава Святкинана конференции QA Fest. Ярослав — тренер QA Automation & Groovy, Senior Test Automation Engineer, Consultant, GlobalLogic. Специализации: автоматизация web и mobile (Android и iOS), пишет на Java и Groovy.

В этой статье я поделюсь, как быстро писать тесты на языке программирования Groovy, не думать о фреймворке, PageObjectи инициализации WebDriver. Фреймворк это сложно? Нет! Я покажу способ, который позволяет думать о тестировании приложения, а не о структуре кода. Я расскажу о трех фреймворках — Serenity, Selenide и Geb.

«Все, теперь начинаем автоматизацию!»

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

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

Велосипед, или Что мы все обычно делаем

Первое, что мы ищем, — как описывать страницы, что могло бы в этом нам помочь. В описании модели PageObjectцелесообразно использовать элемент Html Elements.PageObject. Кто-то его использует, кто-то — нет, но он дает возможность описать определенные элементы и использовать их повторно.

@Name("Search form")
@FindBy(xpath = "//form")
public class SearchArrow extends HtmlElement {

    @Name("Search request input")
    @FindBy(id = "searchInput")
    private TextInput requestInput;

    @Name("Search button")
    @FindBy(className = "b-form-button__input")
    private Button searchButton;

    public void search(String request) {
        requestInput.sendKeys(request);
        searchButton.click();
    }
}

Еще одно полезное средство — дополнительный фреймворк JDI UI Test Automation Framework. Он помогает в основном создавать объекты: check boxes, text areas и т. д. с дополнительным мета-тегами и всем необходимым. Этот фреймворк помогает описать PageObject.

@JSite(domain = "https://jdi.com")
public class JDIExampleSite extends WebSite {
    public static HomePage homePage;

    public static LoginForm loginForm;

    @FindBy(css = ".profile-photo")
    public static Label profilePhoto;

    public static void login() {
        profilePhoto.click();
        loginForm.loginAs(new User());
    }
}

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

Вот три готовых решения вам в помощь.

Стандартное решение — Serenity

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

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

Project structure

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

PageObject мы используем в следующем виде:

Я думаю, все видели FindBy и знают, как он пишется (селекторы и т. д.). А вот как выглядят шаги, описание бизнес-логики:

Что немаловажно — красиво оформленный, готовый к распечатке отчет:

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

Оптимальное решение — Selenide

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

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

Готовое решение — Geb

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

Первое преимущество Geb — использование языка Groovy. C одной стороны, это плюс. Во-первых, чтобы писать на Groovy, надо писать очень мало. Во-вторых, он использует Java, поэтому все Java-библиотеки, которые у нас есть, мы можем «переиспользовать». Дополнительно — в нем замечательные asserts, которые не надо расписывать, как в TestNG или JUnit. Большой минус в том, что, во-первых, чтобы команда начинала писать на Groovy, вам надо сначала обучить команду. Во-вторых, не всегда заказчик готов к использованию Groovy, чаще к Java, а лучше Java 7.

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

import geb.Browser

Browser.drive {
    go "http://gebish.org"

    assert title == "Geb - Very Groovy Browser Automation" 
 $("div.menu a.manuals").click() 
    waitFor { !$("#manuals-menu").hasClass("animating") } 
  $("#manuals-menu a")[0].click() 
assert title.startsWith("The Book Of Geb") 
}

Тяжело ли писать такой код? По-моему, очень легко. Естественно, у нас есть first-метод, с помощью которого можно выбрать все элементы со знаком $. В данном случае нам нужен первый, поэтому мы указываем единицу — «первый элемент» и «клик». Это классический вариант.

При использовании Groovy у вас появляется широкий спектр возможностей. Приведу несколько примеров. Например — создание random stringдля необходимого количества значений возможно в одну строку:

Следующее — когда перед вами стоит задача протестировать API и у вас есть HTTP-запрос, вы получаете JSON-файл, который нужно «распарсить» и получить определенный результат. В Java вам нужны сторонние библиотеки для работы с JSON-файлом. В Groovy же поддержка парсинга и разбора JSON-файла происходит «из коробочки».

В итоге я стал писать совсем по-другому. Я получал JSON и привожу к ArrayList, и на выходе у меня получался ArrayList.

В Groovy любой массив может быть объектом. Вы берете определенный массив и пишете: (massive as Duckling). Если все характеристики совпадают, у вас появляется объект Duckling. Кроме того, у вас есть возможности точно так же описывать JSON:

Выбор селекторов

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

Здесь можно использовать ID и клас By. Любимый класс By позволяет нам по тому или иному селектору сделать выбор тех или иных элементов.

Обратите внимание на assert в этом изображении. Здесь есть знак $. Выбираем все символы p в диапазоне с первого по второй. С помощью метода *.textвыбираем весь текст этих элементов (значок * свидетельствует о том, что используется метод языка Groovy), и нам возвращается полный текст со всех элементов.

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

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

Кроме этого, есть методы, с которыми можно работать почти как со строками:

Также еще есть и масса других методов:

Один из вариантов, где показано, что нам доступно, в рамках Geb и Groovy в целом, использовать XPath с передачей аргумента:

Если сравнивать написание кода с помощью Geb и классический подход, то 25 строчек кода на Java заменит одна строчка на Groovy c Geb.

Что еще может вам помочь в работе над проектами? У нас есть понятие методов wait, и не всегда на странице есть те или иные элементы. Для проверки мы пишем метод isElementPresent, делаем track catches, обрабатываем, возвращаем trueили false.

И снова в Geb все это есть в готовом виде. Первое, у нас есть wait, который определяет, ждать элемент на странице или нет. Мы можем не ждать появления этого элемента, а проверить его наличие.

Существует wait, который определяет, сколько секунд ждать при поиске элементов. Вы сразу задаете его в селекторе при описании PageObject. Элемент может также принимать параметр required true (или false), т. е. определяет, должен или нет этот элемент находиться на этой странице.

Для кэширования в Geb тоже есть вариант. Вы можете прямо в селекторах указать:

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

Работа с таблицами

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

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

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

Как это делается? Давайте посмотрим:

В описании PageObject в Geb есть NotificationModule, а также элементы:

• имя элемента;
• через фигурные скобки — селектор этого элемента;
• moduleList в рамках модуля, где мы вызываем еще один модуль.

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

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

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

Если вам нужно вызвать все методы — ставите «звездочку» и точку (*.), и вам возвращается все, что вы хотите (это Groovy).

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

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

Если вам необходимо проверить, находитесь ли вы на странице, у вас есть замечательный метод isAt. Вы передаете текущую страницу, и у вас получается проверка true/false (на текущей странице или нет). Опять же в Geb это все идет «из коробочки».

Вот классический пример такой страницы (с логином и паролем):

Если вы хотите произвести метод логирования, у вас классически передаются логин/пароль, возвращаются элементы, вы их очищаете и с помощью Groovy вводите значение. Метод login.submitнаходит и вызывает кнопку, по которой вы сразу же кликаете.

Для описания этих действий на Java 7 с использованием Selenium придется создавать гораздо больший объем кода, чем приведенный выше. С точки зрения приложения, использование Geb очень упрощает описание PageObject.

Взаимодействие с мышью и поддержка кнопок

В Selenium у нас есть набор Actions — действий, которые мы можем использовать:

• наведение мыши;
• работа с веб элементами;
• drag-and-drop и так далее.

Для этого нужно создать объект Action, выполнить определенные действия для него и произвести эти действия. В Geb вы можете произвести те же действия — .clickAndHold, .moveByOffsetи любые другие. Разработчики фреймворка Geb предусмотрели все «под ключ». Остается единственный вопрос: почему мы это не используем?

Здесь есть и поддержание кнопок:

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

Ранее открытые окна и тесты

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

Для этого в Geb предусмотрены методы withWindowи withNewWindow. Чем они отличаются? Метод withWindow — новое окно открывается в существующем, производятся действия проверки и сразу же возвращается в предыдущее окно.

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

Сколько строк кода вам нужно написать или скопировать, чтобы это реализовать? В Geb весь тест будет записан в одну строчку, ничего сложного:

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

Показ скрытого элемента

Довольно часто мы используем в коде JS, так как есть вещи, которые без него сделать нельзя. Например, реализовать scroll. Для этого нужно написать определенный кусок кода, привести его к Java executor и прочее.

И снова в Geb есть все, что нам необходимо. Если вы хотите использовать JS-код, вам надо всего лишь написать js.execи указать, что именно вы хотите выполнить:

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

Поддерживаемые браузеры

В Geb поддерживаются все браузеры, которые есть в рамках WebDriver. Обычно в наших решениях мы делаем driver factory, отдельно описываем необходимые браузеры, далее его «подтягиваем» и запускаем — с учетом специфики job. В фреймворке Geb это вынесено по умолчанию. Здесь уже есть отдельный файл — GebConfig.groovy, который мы должны создать по умолчанию и в нем описать браузеры, а также тестовую среду:

Сюда можно полностью вынести все необходимые для тестов константы (имя, пароль, e-mail), настройки тестов, правила проверки, тайм-аут по умолчанию и прочее. Далее — область тестовой среды (test environment), для которой мы задаем имена окружения (Chrome, Firefox, IE) и создаем те драйвера, которые необходимы.

Понятно, что в рамках используемого build (Gradle или Maven) создаются определенные tasks. При этом для Gradle build необходимо прописать свойства системы (System Properties), а именно с каким environment будут запускаться тесты, где лежат драйвера той или иной тестовой среды:

В данном случае мы используем фреймворк TestNG и видим пример запуска тестового набора (test suite). В зависимости от того, какие tasks вы создали, у вас будет запускаться та или иная тестовая среда в рамках существующего.

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

Интеграции с mobile

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

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

Библиотека Geb Mobileпомогает создавать и использовать Geb для нативного Android- или iOS-приложения. Конечно, кое-что не будет работать в связи со спецификой нативных мобильных приложений, но построение PageObject, модулей можно применять и к этим приложениям.

Преимущества и недостатки готового решения

В заключение перечислим преимущества и недостатки использования Geb.

Преимущества:

• Использование языка Groovy (краткость).
• Готовая PageObject-модель, которую вы можете использовать для написания методов wait, переходов между страницами и пр.
• Поддержка всех тестовых фреймворков, сочетание с Cucumber, jUnit, TestNG.

Недостатки:

• Мало кто знает Groovy.
• Необходимо уговорить заказчика начать использовать новые фреймворки и технологии. Для заказчика главный вопрос — кто это будет поддерживать.

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

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

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

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

Ответственность

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

Владимир Гарбар, Team Lead в HYS Enterprise:

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

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

Арсений Оганов, Lead Solutions Architect в Netcracker:

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

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

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

Ирина Попова, Head of Development в Light IT:

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

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

Діма Павлов, Software Tech Lead в Terrasoft:

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

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

Андрей Голомоз, Head of Traffic Quality department в Admitad:

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

Павел Свинцицкий, Team Lead в Mobilunity:

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

Инициативность

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

Артем Дурнев, Unity Software Architect в Plarium:

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

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

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

Василий Иванов, СЕО KeepSolid:

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

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

Артур Мироненко, iOS Tech Lead в UPTech:

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

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

Діана Пекеліс, Senior QA Engineer в DataArt:

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

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

Іван Колодій, СЕО Ukietech та TechLead на проекті TenantCloud:

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

Пам’ятаю, коли я тільки став техлідом на проекті TenantCloud, переді мною стояло питання: залишити все як є і продовжувати розробку на старому стеку або ж переписати практично все з нуля. Це було складне рішення, оскільки потрібно було пояснити стейкхолдерам, що 2-3місяці не буде нових фіч, і, можливо, буде багато багів :) Зовсім непростий виклик. Однак ми прийняли правильне рішення і переписали все з нуля.

Гибкость

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

Діана Пекеліс, Senior QA Engineer в DataArt:

Надзвичайно важливим є вміння швидко адаптуватись до змін та інтегруватись в проекти. Я помітила, що Middle-спеціалісти дещо інакше починають роботу над новими для них проектами, ніж Senior. Це стосується в основному різниці в кількості часу, який потрібен для того, щоб перестати панікувати та почати працювати продуктивно. Мені здається, що це в основному пов’язано із широтою поглядів і досвідом, які зазвичай вже є у Senior і яких ще трохи не вистачає на рівні Middle. Поставлене завдання, скоріше за все, буде лякати їх трохи менше — і, відповідно, працювати на повну силу вони почнуть швидше. Це особливо важливо в коротких проектах або MVP, де часу на «розкачку» немає.

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

Сергей Козырев, Mobile Team Lead в Lohika:

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

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

Внимательность

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

Ирина Попова, Head of Development в Light IT:

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

Андрей Михайлов, CTO, Senior .NET & JavaScript разработчик в Zfort:

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

Честность

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

Тарас Романик, .NET Developer, Tech Lead у Conscensia:

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

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

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

Александр Тарасенко, VAS Team Lead в EVO:

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

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

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

Сергей Козырев, Mobile Team Lead в Lohika:

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

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

Зрелость

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

Андрей Завадский, Engineering Team Lead в Innovecs:

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

Я считаю, что зрелость не зависит от возраста. Она развивается, когда человек, преодолевая какую-то ситуацию, самостоятельно отвечает за свое решение.

Елена Белкина, QA engineer, Internal SoftSkill Trainer в CoreValue:

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

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

Константин Захаров, Solution Architect EPAM Ukraine:

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

Что еще почитать о развитии личных навыков:

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

На які технології та досвід був попит минулого року? Про це ми запитали ІТ-компанії, технічна команда яких, за даними ТОП-50, виросла більш ніж на 100 спеціалістів у 2017 році.

Таких компаній виявилось 15, 12 із них погодилися взяти участь у нашому міні-дослідженні. З’ясувалося, що в 2017 році найчастіше шукали спеціалістів рівня Middle (40% від загального найму), Senior і Junior — 30% і 24% відповідно. Найпопулярнішими технологіями серед компаній-учасників були QA (Manual і Automation), Java, .NET, JavaScript та C++.

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

* за даними ТОП-50. Реальна цифра може бути вищою, оскільки ТОП-50 не відображає переміщення спеціалістів у межах компанії протягом всього року.

Також ми попросили представників компаній прокоментувати, яких спеціалістів не вистачало ринку у минулому році, які фахівці у попиті цього року, а також плани компаній щодо росту у 2018.

Ирина Кононенко, Director of Recruiting, GlobalLogic:

Не новость, что сеньорные специалисты практически по всем техническим трекам были в дефиците, особенно если позиции предполагали какие-то дополнительные требования: Big Data, AI, Machine Learning, опыт в Embedded и т. п.

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

В этом году востребованными будут специалисты в таких cutting-edge-технологиях, как AI, Machine Learning, Computer Vision, Modelling, Data Scienсе, причем запрос будет на инженеров разных уровней: от лидов до джуниоров. Мы планируем продолжать инвестировать в рынок и обучать молодых специалистов, поскольку спрос на джуниоров и трейни также будет ощутимым.

В текущем финансовом году (FY18) компания GlobalLogic показала высокий уровень роста в 20%+. На следующий год наши ожидания не менее амбициозные.

Роман Гапачило, директор відділу рекрутингу, ЕРАМ Україна:

Ми відчували дефіцит у фахівцях із навичками JavaScript, BI та Big Data, Automation Testing in .NET, Performance Testing. Саме вони складали основну частку спеціалістів, з якими компанія розпочала співпрацю торік. Також ми розглядали кандидатів у тому числі і з такими нішевими навичками, як Drupal, Ruby, Demandware, Hybris.

З урахуванням минулорічних тенденцій ми прогнозуємо попит на фахівців нових технологій, наприклад: Cloud/DevOps, Big Data/AI/IoT/RPA etc. Більш детальні плани щодо зростання уточнюються. Це залежить від великої кількості зовнішніх та внутрішніх чинників. Але ми припускаємо, що зростання цього року може коливатися від 15 до 25%.

Костянтин Пилипчук, Vice President, Global Talents Acquisition, SoftServe:

Якщо говорити про виклики, з якими стикалися під час пошуку кандидатів, варто відмітити, що іноді було складно знайти WebUI-фахівців з достатніми знаннями фреймворків та Java-розробників з досвідом роботи в версії Java 8 та багатопотоковістю (concurrency). 2018 рік обіцяє бути не менш інтенсивним. SoftServe планує розширити команду на 800+ фахівців, в основному в напрямках WebUI, Java, .NET, DevOps та BigData.

Ирина Гуменюк, Head of Section (Recruitment), Infopulse:

В 2017 году большим спросом пользовались JS Developers с коммерческим опытом работы с Angular, React, Meteor. Поскольку технологии новые, уровень экспертизы кандидатов зачастую не соответствовал ожиданиям заказчика.

Интересными и сложными для поиска и найма считаются такие специализации как Full-Stack .NET/Java developers уровня Senior.

В 2018 Infopulse планирует прирост в 250 специалистов по таким специализациям как . NET, JS, Java, C++ Developers, QA Engineers уровней Мiddle и Senior.

Есть планы по увеличению количества специалистов телеком-сегмента, развитие Сloud, Data Science и IoT экспертизы.

Ольга Дюжева, HR & Recruitment Director, Intellias:

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

Зараз популярні веб-технології, ми багато шукаємо як Front-end, так і Back-end і Full Stack програмістів. Часто потрібні знання NodeJS, React, Angular. Не спадає високий попит на DevOps інженерів. Тренд останнього часу у вакансіях девопсів — вимоги до знання Kubernetes.

Останнім часом наша компанія показувала не менше як 50% зростання на рік, не має стати винятком і 2018-й.Насправді сподіваємось перевищити цей показник.

Ольга Тарасова, HR Manager, DataArt:

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

Ожидаем продолжение спроса на основные направления: QA, QA Automation, .NET, Java, JavaScript. Мы также предвидим рост востребованности бизнес-аналитиков и квалифицированных программистов на Python.

Ирина Гольцева, Recruiting Team Lead, Lucky Labs:

В прошлом году мы ощутили нехватку DevOps/SRE. Вакансия сама по себе не самая простая — большой стек технологий и высокая востребованность этих специалистов в стране заставили нас побороться за кандидатов на рынке.

Претендентам на должность не хватало в основном глубоких знаний ключевых Unix-like операционных систем и LEMP/LAMP стека, а также знаний по репликации/кластеризации и настройке реляционных и нереляционных баз данных. Кроме того, у части кандидатов мы видели слабое понимание CI/CD и незначительный опыт работы с системами «оркестрации» Ansible/Chef/Puppet/Salt.

В 2018-м,как и в прошлом году, по тем же причинам компания будет нуждаться в DevОps-специалистах. Также у нас есть несколько завышенный запрос на Python-разработчиков уровня middle, что связано с технической конфигурацией части наших проектов.

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

Татьяна Кинда, Recruitment Director, Luxoft Ukraine:

В дефиците были Senior-программисты всех специализаций, Front-end разработчики, кандидаты со специфическим стеком технологий, к примеру, С++\QT, React Native. Часто барьером для кандидатов является недостаточный опыт работы, а также уровень владения английским языком.

Исходя из портфолио наших проектов, сохранится стабильный спрос на Java- и JavaScript-программистов Middle- и Senior-уровня. В связи с ростом Automotive проектов мы будем нанимать достаточно много С++ специалистов — начиная от Junior-уровня (у нас есть интернатура для студентов) до Senior-позиций. Все чаще появляются вакансии, связанные с применением Blockchain.

Мы планируем дальнейший стабильный рост компании и наша цель — пересечь отметку 4 000 сотрудников в Украине.

Дарья Горницкая, генеральный директор, Astound Commerce Украина:

В случае с Astound Commerce дефицит специалистов зависит, скорее всего, от количества и сложности конкретной вакансии. К примеру, компания ищет Business Analyst — это достаточно сложная вакансия, не всегда запрос компании совпадает с ситуацией на рынке. Для нас востребованы аналитики с опытом работы в больших и сложных проектах с выстроенными процессами и разработкой масштабных решений, а таких не так уж и много. В том числе поэтому активность в поиске и рекрутинге бизнес-аналитиков происходит периодами и зависит от специфических факторов работы на этой должности. При этом количество нужных специалистов в сфере аналитики бизнес-процессов в разы меньше, чем тех же web- и front-end-разработчиков, QA, а сам рынок для таких вакансий — намного меньше.

В 2018 году в сфере разработки e-commerce решений мы ожидаем спрос на web- и front-end-разработчиков, Business Analyst, PHP Magento Developer, Salesforce Developer, Project Manager, QA, а также UI/UX дизайнеров.

На этот год мы планируем рост рекрутинга на уровне 30%. Такое решение связано с глобальными планами Astound Commerce и дальнейшим расширением e-commerce экспертизы на других рынках.

Катерина Сирота, HR & Recruitment Director, N-iX:

Андрей Стрехалюк, VP of Talent Acquisition, Innovecs:

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

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

Что касается спроса в 2018 году, то с точки зрения server-side это технологии, которые уже используются: Node.js, PHP. Для более крупных проектов — это Scala, Java, .NET. C точки зрения front-end, дальнейшее движение в сторону JavaScript, то есть это тот же React и Angular. По мобильной разработке — будет смесь как нативных для iOS и Android, так и гибридных вариантов, как React Native и Ionic, Angular Native. Помимо этого будут нужны технические специалисты с опытом и пониманием особенностей предметных областей, как то логистика, финансы, здравоохранение и т. д.

Мы планируем усилить позиции и увеличить долю клиентов из США до 40%, из Израиля и Европы — по 30% соответственно. В 2018 мы работаем над тем, чтобы вырасти на 70% по сравнению с прошлым годом, при этом сохраняя индустрии, в которых наша экспертиза особенно сильна: Gaming and Entertainment, Supply Chain & Logistics, Health Care, AdTech, FinTech, Telecom.

Читайте також: LinkedIn, Джинн і рекомендації — найкращі канали пошуку спеціалістів. Результати рекрутинг-опитування

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

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

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

Українська збірна. Артем — крайній праворуч у першому ряді

— Артем, що таке історичний середньовічний бій (ІСБ)? Чи є він офіційним видом спорту?

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

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

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

— Чим середньовічний бій відрізняється від історичного фехтування?

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

— Як ви почали займатись історичними боями? Що саме вас зацікавило?

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

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

— Як пройшов ваш перший бій? Коли і де?

Перші поєдинки-спаринги були у 2007 році — звісно, на тренуваннях. Перший справжній турнір відбувся роком пізніше в Києві. Там я вперше взяв участь у бугурті — масовій битві 100 на 100 людей. Спочатку я трохи нервував, але вже після першого удару сокирою адреналін зробив свою справу — хвилювання зникло, залишивши місце лише спортивному азарту :)

— Які у вас є цікаві історії, пов’язані з хобі? Які бої найбільше запам’ятались?

З 2010 року я беру участь у щорічному чемпіонаті світу «Битва націй», тому виникають історії, пов’язані з подорожами. Зазвичай митники дуже кумедно реагують на наші обладунки та зброю. Одного разу мій колега-лицар навіть подорожував літаком, не знімаючи латів, — щоб не переплачувати за вагу валізи :)

Напевно, найбільше запам’ятався фінал «Битви націй» у минулому році. Змагання проходили в Барселоні, за перемогу билися команди 32 країн-учасниць. Після трьох днів боїв національна збірна України без жодної поразки дійшла до фіналу. Ключове протистояння — 21 на 21 — відбулося між командами України та Росії. До речі, саме представники останньої утримували чемпіонство протягом семи років.

У першому раунді перевага залишилась за супротивником. Однак ми мали жагу до перемоги та змогли вибороти другий та фінальний раунди. Тож у 2017 році світ побачив нового чемпіона, найсильнішу збірну світу — збірну України :)

— Скільки часу витрачаєте на ІСБ? Як часто тренуєтесь?

Тренуюсь 5-6разів на тиждень. Тренувальний тиждень складається з 3 занять з ІСБ та 2 у тренажерному залі. Під час підготовки до серйозних змагань ще додаю одне тренування з боротьби чи кікбоксингу. Тож, з огляду на кількість витрачених часу та зусиль, ІСБ для мене не просто хобі, а справжній напівпрофесійний спорт.

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

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

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

— Скільки це все коштує? На що саме йдуть гроші?

Базовий комплект обладунків коштує приблизно $1000. Чим більше тюнінгу та покращень, тим вища ціна. Однак для новачків також доступний ринок обладунків з досвідом попередніх перемог :)

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

— Як вдається поєднувати хобі з роботою в ІТ? Чи вистачає часу на все?

Турніри в основному проводяться на вихідні чи свята, тому з роботою їх поєднувати неважко. До того ж, в ІТ зазвичай досить гнучкі робочі графіки. А вже на чемпіонат світу беру відпустку :)

До речі, серед сучасних лицарів-спортсменів дуже багато представників IT-сфери. Наприклад, лише в національній збірній України третина складу — саме айтішніки. Це хлопці майже з усіх регіонів України: Київ (Devellux, GamePoint, Noosphere, Ubisoft), Харків (Corewide, Svitla Systems), Дніпро (Caspio, MOOHII), Одеса (AB Soft, The Product Engine), Кропивницький (M.I.F.Projects) тощо.

Думаю, це пов’язано з тим, що зазвичай сучасні айтішники — досить освідченні люди з широким спектром захоплень.

— Як сформувалася збірна України? Скільки всього людей в команді?

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

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

— Чи є якісь вимоги до фізичної підготовки бійців?

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

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

— Наскільки це травматичний вид спорту? Як вберегтись від травм?

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

— Чи змінило хобі вас як особистість? Можливо, додало якісь нові риси характеру?

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

— Що порадите новачкам, яких цікавить мистецтво середньовічного бою? З чого і як починати?

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

Також долучайтеся до офіційної сторінкизбірної України у Facebook.

— Які у вас плани на майбутнє, пов’язані з хобі?

Відвідати «Битву націй 2018» у Римі та перемогти, підтвердивши титул чемпіонів світу. Змагання відбудуться 3-6 травня.Цьогорічна «Битва націй» має навіть більше значення, ніж тріумф у Барселоні, — адже конкуруючі збірні зроблять усе можливе, щоб довести, що перемога України була випадковою.

Серед більш довгострокових планів — і надалі розвивати ІСБ як спорт у всіх містах України.

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

Елена Моргун, Ruby Team Leader в Rails Reactor

10 лет опыта, из них 5 в Ruby

Проблема многих начинающих Ruby-разработчиков в том, что они обычно бросают все силы на изучение фреймворка Ruby on Rails в ущерб навыкам работы с языком Ruby, СУБД и прочим базовым вещам. На выходе мы получаем человека, который может воспроизвести туториал по решению какой-то задачи (например, может сделать какую-нить страничку с формой). Но при этом любой шаг в сторону от туториала, требующий минимального понимания теории, вгоняет этого человека в ступор. Например, необходимость написать простенький SQL-запрос.

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

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

Микола Бохонко, Competence Lead у Perfectial

6 років досвіду у Software Development

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

Звідки ж брати інформацію?

1. Документація

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

2. GitHub Issues, GitHub Pull requests та інші канали зв’язку з розробниками

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

Але ні. Наступний крок — подивитися відкриті і закриті issues на гітхабі, переглянути pull requests. Якщо проблема і справді не була наслідком неуважності, то або на неї вже є тікет в репозиторії проекту, або його потрібно створити. У багатьох великих технологій є навіть окремі форуми та чати, в яких можна задати своє питання. Заодно ще й в англійській мові попрактикуватися.

3. А як же книги?

Я не особливо підтримую занурення в читання книг на початкових етапах вивчення технології. «Agile Web Development With Ruby on Rails» і «Rails Tutorial» є, безумовно, якісними творами, але, читаючи їх, людина змушена наслідувати приклади з книги, замість написання і осмислення коду самостійно. Тому якщо ти недавно почав вивчати програмування, то пачка книг тільки сповільнить прогрес. Краще опиратися на документацію і постійно практикуватися.

Ruby language

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

• RubyFlow — Ruby community blog;
• Awesome Ruby — колекція Ruby гемів, інструментів, фреймворків;
• Ruby Koans — шпаргалка по Ruby — синтаксис, структура та деякі загальні функції та бібліотеки;
• Ruby Weekly — щотижнева розсилка новин у світі Ruby;
• Ruby — офіційний сайт Ruby.

Також дуже важливо розуміти Ruby Object Model — це маркер, який відразу показує рівень знань девелопера і загалом дозволяє використовувати Ruby правильним чином.

Rails framework

Декілька важливих пунктів, які повинен знати кожен джуніор:

• Парадигма MVC — вам потрібно знати, який рівень несе відповідальність, за що і як структурувати додаток так, щоб ви знали, де слід поставити бізнес-логіку і де представлення.
• ​​Haml/Slim — препроцесори HTML, дозволяють швидко писати структурований псевдокод, перетворений в HTML за допомогою інтерпретатора.
• ActiveRecord — потрібно знати, що таке ORM, як реалізовані міграції, асоціації, валідації.
• API + JSON — Ruby on Rails дуже часто використовується як API провайдер, тому вам потрібно знати API як концепцію та JSON як формат.
• Основи REST та HTTP.

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

Кілька корисних статей:

• 5 Simple Important Tips for Ruby on Rails
• How To Get Started With Ruby
• What advice/rules I may give to junior developers about the Ruby on Rails app design?

Деякі Rails тематичні ресурси, які також раджу додати в закладки:

• weblog.rubyonrails.org — офіційний блог Rails-команди
• Engine Yard — тематичний блог
• This week in Rails — Rails-аналог вищезгаданої щотижневої розсилки новин
• Drifting Ruby
• RailsZilla

RSpec testing

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

Корисні ресурси:

• RSpec
• Better Specs
• Tutorials Point
• How to setup a Rails app for Test-Driven- and Behavior-Driven Development with Rspec and Capybara

Постійне вдосконалення англійської мови

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

Практика, практика і ще раз практика

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

Дмитрий Семенов, Senior Ruby Developer в Dev-Pro

6 лет опыта

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

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

Если это все не проблема, можно уже и про Ruby поговорить. Многие новички пренебрегают изучением стандартной библиотеки Ruby и при первом же знакомстве пробуют использовать Ruby on Rails — я считаю это ошибкой. «Народ, не знающий своего прошлого, не имеет будущего». Так же и разработчики, которые не понимают, на что опирается их любимый фреймворк, не станут лучшими из лучших. Начинайте изучение языка с его истории и ценностей, пройдите туториал «Ruby in Twenty Minutes»и почувствуйте, поэкспериментируйте с возможностями языка, не используя лишних зависимостей.

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

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

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

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

Не будьте RoR, будьте Ruby!

Дмитро Комісарик, Senior Software Engineer в EPAM Ukraine (Lviv)

6 років досвіду

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

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

Розуміння синтаксису мови Ruby. Чим краще ти вивчиш синтаксис, тим швидше зможеш розуміти код більш досвідчених фахівців і набиратися досвіду від них. Також слід розуміти базові речі: цикли, класи, умовні вирази, модулі, блоки. Як розробник Ruby, ти будеш в основному використовувати об’єктно-орієнтоване програмуванням. Отже, потрібно знати деякі поняття OOP: інкапсуляція, поліморфізм, наслідування та абстракція. Щоб добре ознайомитись із Ruby-синтаксисом, пропоную почитати:

• Jay McGavren «Head First Ruby: A Brain-Friendly Guide» 1st Edition
• Peter Cooper «Beginning From Novice to Professional» 2nd Edition

Занурення у Ruby on Rails framework. Повинно бути розуміння MVC концепції цього фреймворку. Також важливим є знання HTTP/HTTPS протоколів і розуміння REST. У сучасному світі існують мільйони проектів на Ruby on Rails лише з backend-розробкою, тому варто добре знати, що таке API та JSON.

Рекомендована література по Rails:

• Michael Hartl «Ruby on Rails Tutorial (Rails 5)»;
• Glenn Goodrich «Rails: Novice to Ninja: Build Your Own Ruby on Rails Website»;
• Leonard Richardson «RESTful Web APIs: Services for a Changing World».

Без знання та розуміння баз даних (БД) складно стати хорошим рубістом. PostgreSQL / MySQL — дві найбільш поширені реляційні бази даних. Рекомендую розібратися у їхніх відмінностях та налаштувати їх на твоєму комп’ютері, а після цього вивчити основи SQL. Це дуже проста мова запитів, яку використовують для вибірки даних. Для початківців рекомендую книгу «SQL QuickStart Guide». Варто згадати ще й нереляційні бази даних NoSQL. У них є свої плюси, та їх потрібно розуміти, щоб знати, в яких ситуаціях використовувати.

Я уже згадував про backend розробку — «невидимий двигун» сторінки. Та є ще таке поняття, як front-end — це «красива сторона» аплікації, яка створюється за допомогою HTML, JavaScript, CSS. Відповідно, щоб вільно почувати себе у цьому напрямку, потрібно мати базові знання структури веб-сторінки HTML.Тоді ти будеш розуміти, як цю сторінку можна «зафарбувати», використовуючи CSS і як її зробити динамічною за допомогою JavaScript.

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

• Introduction to Testing — RSpec Language;
• про Rspec також згадується у туторіалі Michael Hartl;
• «Everyday Rails Testing with RSpec» — книга про основи.

Звичайно, у переліку необхідних інструментів для Ruby on Rails є GIT. Це система зберігання та керування файлами для спільної роботи в команді. Ти повинен знати і розуміти створення branch та базові команди («git pull», «git push»). Цікавий туторіал — try.github.

А далі йде — практика, практика і ще раз практика :) Ось відеокурси, де можна побачити код і практикуватись:

• RailsCasts
• Rails for Zombies
• Lynda

І ще одна дуже важлива рекомендація. Не лінуйся відвідувати курси чи тренінги, навіть якщо тобі здається, що ти вже все знаєш. Гарантовано, що на таких зустрічах ти зможеш почути щось нове та цікаве, а постійний обмін досвідом із досвідченими рубістами дасть тобі можливість розвиватися в правильному напрямку. Одне із найкрутіших Ruby-ком’юніті — це #pivorak. Вони проводять безкоштовні курси і дають хороше розуміння мови. Тому обов’язково приєднуйся до них!

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

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

Об учебе и первой операционной системе в Одессе

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

После школы я поступила в Одесский государственный университет (теперь ОНУ им. И. И. Мечникова — ред.) на специальность «Прикладная математика». Тогда компьютерным наукам там особо не учили. Факультативно мы изучали язык ALGOL.

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

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

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

В конце 1970-хмы внедряли автоматизированную систему управления (АСУ) для Минска-32 на заводе им. Октябрьской революции на Пересыпи. Это был завод всесоюзного значения, его развалины всё ещё сохранились. Наша АСУ рассчитывала план работы предприятия с учетом его ресурсов. Мы привлекли серьезный математический аппарат, использовали последние технологии. Потом мы протестировали АСУ и пришли внедрять ее на предприятие.

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

Где-то через месяц меня пригласили на завод, и я увидела там французскую делегацию. Они приехали посмотреть, как у нас развивается вычислительная техника — во Франции такого еще не было! Им показывали большую кипу бумаги с просчитанным планом работы завода. Тогда были еще не принтеры, а алфавитно-цифровые печатающие устройства (АЦПУ), которые печатали листы в формате А1. Я спросила сотрудников завода, что они показывают делегации, неужели переводят столько бумаги? Мне сказали, что они один раз просчитали план, а потом каждый день его всем показывали.

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

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

Об аспирантуре и общении с зарубежными программистами

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

Я хотела учиться у Лаврова, потому что на то время он был одним из троих ведущих ученых в IT-области в СССР. На его кафедре в ЛГУ была создана одна из самых известных школ программирования. Там работали другие, не менее известные ученые: Г. С. Цейтин, И. Л. Братчиков, А. Н. Терехов.

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

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

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

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

О ПО для «Эльбруса» и умных туалетах для японцев

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

В 1985 году мы разрабатывали ПО для «Эльбруса». Этот компьютер был первой в мире коммерческой ЭВМ, которая применяла суперскалярную архитектуру. Тогда Горбачов хвастался, что это одна из самых перспективных разработок, которая должна впечатлить мир. Потом проект купила американская компания Sun, а позже Intel. Они позаимствовали очень многие решения и переманили многих специалистов.

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

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

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

Мы показывали видеотренажер на первом в СССР международном компьютерном форуме, который проходил в Москве в начале 1990-х.Туда приехал интересный ученый Джон Варнок (John Warnock). В компьютерной графике ему принадлежит один из классических алгоритмов удаления невидимых граней. Еще он один из основателей компании Adobe Systems. Помню, мы с ребятами подошли к нему и показали наш проект, рассказали, как мы пользовались его методами. Варнок был шокирован! Как и все американцы, он думал, что приехал в дикую страну.

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

• операционка, компиляторы языков и среды программирования для «Эльбруса»;
• система бесконтактного обслуживания туалетов для клиентов из Японии;
• бухгалтерские программы и решения для банка: клиент-банк, финансовый мониторинг, работа на межбанке;
• карточная игра для игорного клуба;
• система мерчандайзинга (оптимальной расстановки товаров в зале) для супермаркетов «Таврия В»;
• система принятия решений для Одесского горисполкома;
• система управления технологическими процессами Южноукраинской АЭС;
• расчет траектории движения малых небесных тел;
• моделирование игры «Пентамино»;
• система управления производством на Одесском стекольном заводе.

2000 год. Работа над совместным проектом в одном из банков

О работе в Provectus и бывших студентах

В компанию я пришла в 2014 году, меня позвали сюда ребята, с которыми я раньше работала. Моей постоянной работой считается преподавание в Одесском национальном университете имени И. И. Мечникова, а в Provectus я занимаю должность системного аналитика. Совмещаю обязанности BA (бизнес-аналитик), DBA (администратор баз данных), PS (профессиональное обслуживание, разработчик). Мне нравится решать проблемы и сложные ситуации. Не люблю просто так отсиживаться — для меня это тяжело.

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

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

О преподавании и проблемах вузов

В университете я читаю курсы «Базы данных и информационные системы», «Теория программирования», «Компьютерная графика». Сейчас в моих научных интересах — интеллектуальные системы. Веду спецкурс по методам Data Mining и OLAP-системам — это системы автоматического анализа данных.

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

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

Конец 90-х.Фото на память с выпускниками кафедры

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

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

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

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

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

В этот раз съемочная группа DOU Ревизоротправилась в Чернигов, чтобы посмотреть, чем живет офис SendPulse — украинской продуктовой компании, которая предоставляет мультиканальный сервис для автоматизации маркетинга. При помощи SendPulse пользователи могут отправлять e-mail, SMS, Viber и Web Push рассылки, как отдельно, так и в связке.

Компания была основана в феврале 2015 года. Главный офис SendPulse находится в Чернигове. Представительства компании есть также в Чили, Мексике, Бразилии, Турции, Беларуси и США. Но основная команда разработчиков, маркетологов и поддержки находится в главном офисе и на текущий момент составляет 80 человек. 25 из них — технические специалисты (QA + Dev); 16 — сотрудники технической поддержки клиентов.

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

Офис SendPulse расположен в двухэтажном здании по адресу ул. Святониколаевская, 12А. Компания соседствует с Черниговским Центром развития местного самоуправления, который занимает половину первого этажа того же помещения.

Само здание находится в историческом центре города. Через дорогу — аллея с множеством кафе и ресторанов, поэтому здесь не составит труда найти место на любой вкус и кошелек, а питаться можно хоть каждый день в новом заведении. Средний чек за комплексный обед — 75 грн. Ближайшее место — кафе «Буфет», где стоимость обеда составит 65 грн. В пешей доступности также есть несколько столовых, где можно съесть первое, второе и выпить компот за 40 грн. В пяти минутах ходьбы находится «ЭКО маркет».

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

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

Офис SendPulse — это 660 м²рабочего пространства. Здесь нет больших опенспейсов. Офис поделен на кабинеты, рассчитанные на команды из 8-15 человек.На стеклянной двери каждого кабинета есть хештег, который обозначает специализацию, а иногда даже настроение команды, которая работает за этой дверью. Команды сами выбирали и придумывали надписи. К примеру, #Godnota, #SalesGuru, #MarketingNinja, #DoNotFuckUp, а у команды разработки своя история — #KeepCalmAndGoAway и #WeDontLikeHashTags.

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

Рабочий день сотрудники могут начинать с 7:30 до 10:00 утра. Количество квадратных метров на человека в рабочем помещении составляет 7-8м² (по данным компании).

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

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

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

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

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

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

Вероника, QA Engineer, 8 месяцев с компанией:

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

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

Максим, Middle PHP Developer, 1 год и 2 месяца с компанией:

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

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

Дмитрий, Product Designer, более 3 лет с компанией:

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

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

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

Татьяна, Team Lead команды разработчиков, работает со дня основания компании:

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

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

Дмитрий, Product Manager, 1 год с компанией:

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

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

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

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

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

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

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

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

Дослідження проводив аналітик Павло Миронов

В Україні 123 тисячі ФОПів-айтішників, якщо спиратися на відкриті даніреєстру фізичних осіб-підприємців. Найпопулярніший КВЕД серед них — «Комп’ютерне програмування», який вказали основним 82 тисячі осіб. Також популярними є «Консультування з питань інформатизації» (21 тисяча) та «Оброблення даних» (15 тисяч).

Цікаво, що загальна кількість IT-ФОПів майже збігається з підсумковим розрахунком ринку праці, який ми робили наприкінці 2017 року, — тоді нарахували 129 тисяч ІТ-спеціалістів. Також цього року в анкеті про портрет ІТ-спеціаліста 67% респондентів написали, що вони співпрацюють з компаніями як ФОП. Тож якщо припустити, що 82 тисячі осіб з КВЕДом «Комп’ютерне програмування» — це і є ті 67% ФОПів, у результаті маємо 123 тисячі спеціалістів.

Цілком очікувано, серед регіонів найбільша частка в Києві та області — 29%. І це без урахування тих програмістів, які переїхали до столиці, але не змінили місце реєстрації. Наступні в рейтингу за кількістю IT-фахівців — Харківська (14%) та Львівська (10%) області.

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

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

Число програмістів стабільно зростає. Дані про кількість зареєстрованих ФОПів стали доступними у квітні 2016 року. Відтоді кількість програмістів значно зросла — з’явилося більше 30 тисяч нових зареєстрованих IT-спеціалістів.

Це нетипово для українських ФОПів. Якщо кількість айтішників за період публікації даних збільшилася на 33 тисячі, або ж на 37%, то загалом число зареєстрованих ФОПів впало на 186 тисяч (10%).

Як бачимо на графіку, закриття ФОПів, яке пов’язували із збільшенням мінімальної заробітної плати та, відповідно, мінімального ЄСВ, торкнулося також IT-фахівців. Але в подальші місяці цей спад кількості був швидко компенсований новим зростанням.

Як рахували?

Реєстр юридичних осіб та фізичних осіб підприємців доступний для публічного користування і завантаження. Ми шукали в реєстрі ФОПів записи із дійсною реєстрацією, в яких основним видом діяльності був вказаний один з цього списку:
62.01 Комп’ютерне програмування
62.02 Консультування з питань інформатизації
62.03 Діяльність із керування комп’ютерним устаткованням
62.09 Інша діяльність у сфері інформаційних технологій і комп’ютерних систем
63.11 Оброблення даних, розміщення інформації на веб-вузлах і пов’язана з ними діяльність

Не основні види діяльності не надаються у придатному для машинної обробки вигляді, тому ми не могли врахувати тих IT-спеціалістів, які працюють не за основним КВЕДом. Також, очевидно, не було враховано тих айтішників, як працюють не як ФОПи. Регіональна прив’язка теж встановлювалася на основі офіційної адреси державної реєстрації, а не відсутньої у реєстрі актуальної фактичної адреси ФОПа. Прив’язка до міст — на основі поштового індексу з адреси.

На момент розрахунків найновішою версією реєстру була версія від 12 квітня 2018 року. Дані про населення областей та міст взяті з сайту ukrcensus.gov.uaстаном на грудень 2017.

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

Всем привет. Меня зовут Влад. Я старший .NET разработчик в компании DataArt. В IT я около семи лет, из них больше пяти работаю c .NET. Хочу дать некоторые советы тем, кто только начинает свой путь в IT как разработчик, а также тем, кто уже имеет пару лет опыта. Надеюсь, мое видение кому-то поможет на пути.

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

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

Что хотят от джуниора

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

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

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

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

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

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

Где выгодны джуниоры

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

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

Первые шаги

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

Если с живым человеком-лектором вам проще, то советую курсы с большой длительностью, например от 3 до 6 месяцев. Мне кажется, это либо втянет вас в процесс, либо окончательно вам надоест, и вы поймете, что это не ваше.

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

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

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

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

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

Hard Skills

Я разделю все сферы знаний hard skills на такие части:

• C# - синтаксис — это база. Нанимаясь на первую работу, вы должны знать хорошо хотя-бы это.
• LINQ — расширение C#, фактически его очень важная часть. Сейчас большая часть бизнес-логики пишется именно на нем.
• .NET — платформа, на которой работает все выше описанное. Понимание базовых вещей убережет вас от часов поиска в Гугле и непонятного для вас поведения проекта, если вы что-то сделали не так.
• Фреймворки — средства поверх C#, с использованием которых и ведется разработка. Для web — это MVC/WebForms/WebAPI/SignalR, для десктоп — WPF/WinForms. Для веба главное — понимать MVC. WebForms используется реже. Можно также добавить ASP.NET Core и Store App, однако проектов по ним не так много, так что начинать учить MVC — беспроигрышный вариант. Cамый популярный фреймворк для работы с данными — Entity Framework. Де-факто стандарт. Также нужно уметь работать хотя бы с одним IoC-контейнером, например Ninject, понимать, как и зачем работает Dependency Injection и почему слабо связанное приложение лучше поддерживается.
• SQL — очень часто требуется. Знание SQL — для вас огромный плюс. С .NET приложениями чаще всего используют MS SQL Server и язык запросов T-SQL.
• Шаблоны проектирования и парадигмы — даже если вы их не понимаете — то заучите. С практикой придет понимание. Шаблон сам по себе — наилучшее, найденное в ходе эволюции миллионов человеко-часов решение какой-то общей проблемы.
• Архитектурные гайды — лезть в вопросы проектирования поначалу глубоко не стоит. Но понимание, что такое SOA, N-layer, Microservices, поможет вам гораздо быстрее въезжать в суть дела.
• Базовое понимание Front-end — очень часто от бекенд-девелоперов требуют минимальные знания фронта. Возможно, достаточно JQuery, который используется в достаточном количестве проектов, заходящих в наши аутсорс-компании. Если вы человек с чистым бекенд-профилем, то, может быть, будете более интересны продуктовым компаниям, где множество людей делают большие технологические продукты, но, по-моему мнению, попасть в такую компанию новичку сложнее, нежели в аутсорс.
• Productivity tools — очень полезно приучать себя работать быстро с самого начала. Потом productivity tools сэкономят вам сотни часов времени, воспринимайте это как инвестицию.
• Системы контроля версий — средства для организации командной работы. Фрилансерам, которые работают над проектами самостоятельно, они могут быть и не нужны, но в компаниях всегда коллективная работа — там без них никак.

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

Советы для интернов/джуниоров

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

C#

«C# 4.0 The Complete Reference» by Herbert Schildt

Хорошо подойдет для освоения базового синтаксиса самого языка. Лично мне никогда не нравились книги Троелсена, которые рекомендуют новичкам. По моим субъективным ощущениям, там много воды, а вот у Шилдте как раз все по делу и с примерами.

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

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

Методы стандартных библиотек .NET — это энциклопедические знания, и заучивать их тоже по началу не стоит. Это гуглится за пару секунд, и куда более продуктивно будет это делать уже по мере самой работы (учебной, разумеется) над какими-то своими поделками. Так у методов будет свой «вес», и потребность в них. Следовательно, запомнятся они куда лучше.

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

LINQ

«Pro LINQ: Language Integrated Query in C# 2010» by Joseph Rattz, Adam Freeman

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

Бонус #1
Даю вам свою классификацию методов LINQ, которая поможет их запомнить куда лучше. Написал ее, когда сам изучал LINQ.

.NET

«CLR via C#» by Jeffrey Richter

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

Я бы дал некоторые советы, как читать эту книгу:

Часть 1 — Основы CLR — очень глубоко вникать не нужно, достаточно понять, что такое:

• строгие и не строгие имена сборок;
• что такое CLR, по сути, и как устроена сборка, манифест, метаданные;

• как запускается CLR через исполняемый файл exe и что еще в нем может содержаться кроме кода вызова;
• JIT-компиляция и IL код;
• CTS/CLS;
• версирование сборок.

Часть 2 — Проектирование типов — эту часть нужно хорошо изучить целиком, важная базовая часть C#/.NET.

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

• главе о делегатах — достаточно полная и базовая информация об этой части языка, понимание Func, Action;
• что такое StringBuilder, как организованы строки в .NET;
• интерфейсам ICollection, IEnumerable, IList;
• Nullable-типам.

Часть 4 — Ключевые механизмы — советую очень хорошо разобрать:

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

Часть 5 — Многопоточность — слишком глубоко вникать, как это работает на уровне ядра ОС, не стоит, но надо понимать общие концепции:

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

SQL

«T-SQL Fundamentals» by Itzik Ben-Gan

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

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

А теперь челлендж: кто первый напишет тетрис на T-SQL — получит от меня бутылку ирландского виски :)

Frameworks & Tools

«ASP.NET MVC 5»Адама Фримена

Для веб-разработки рекомендую эту книгу. В ней неплохо разобраны базовые возможности ASP.NET MVC, контейнеры управления зависимостями (IoC), основы LINQ, AJAX, JQuery. Есть примеры с кодом, достаточно легко читается.

Также рекомендую очень хорошие сайты-справочники по фреймворкам на платформе .NET — Metanit.comи Professor Web. Есть очень много примеров.

Также неплохой специализированный ресурс по Entity Framework — Entity Framework Tutorial.

Productivity tools

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

Обязательно установите себе ReSharper — лично я не мыслю свою работу без этого дополнения к Visual Studio. Для тех, кто использует Rider, Resharper вообще, как родной.

Если вы используете MS SQL Server Management Studio, то must have расширение — это SQL Hunting Dog. Некое подобие ReSharper’a для более быстрой навигации по сущностям базы и переключения баз.

Если ваша разработка связана с Web — осваивайте Chrome dev tools (F12 tools).

Для 99% случаев отладки кода в браузере их должно хватить. Для более хитрых случаев перехвата и изменения трафика используйте Fiddler.

Шаблоны проектирования и парадигмы

«Паттерны проектирования на платформе .NET»Сергея Теплякова

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

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

Также советую ознакомиться с парадигмами SOLID, главная из которых, я считаю «S» — single responsibility principle. Все остальное уже производное от нее.

Front-end

Я не рекомендую читать самую известную ортодоксальную книгу с носорогом, которая называется «JavaScript: The Definitive Guide» (Подробное руководство) by David Flanagan. Очень академичный стиль изложения, очень много воды и несущественных деталей. Конечно, если вы разработчик front-end фреймворков, то эта книга для вас. Но я все же люблю более практичный подход. Самое лучше, что есть в Рунете по Javascript, это JavaScript.ruи Learn Javascript.ru.

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

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

Осваивать Angular, TypeScript или React вполне возможно на сайтах по официальной документации.

Из того, что мне показалось очень хорошим для вникания в React.js и современную инфраструктуру front-end разработки, это книга «Разработка веб-приложений в ReactJS»А. Хортона и Р. Вайса.

Вспомогательные средства

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

Clip2net — утилита, которая позволяет на ходу дорисовать что-то на скриншоте и тут же его сохранить или отправить.

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

Также есть онлайн-средства для тестирования небольших кусков кода, например, .NET Fiddle, или для регулярных выражений — RegExr.

Многие любят LINQPad — текстовый редактор, позволяющий тестировать LINQ2SQL или EF LINQ запросы к базе и разные куски кода без перекомпиляции тяжелых громоздких проектов.

Системы контроля версий

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

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

Для начала достаточно понимать, что такое Repository, Branch, Pull, Commit, Push, Merge, Stash. Если хотите создать свой приватный репозиторий — можете использовать BitBucket. Если хотите кому-то показать свой код, то удобно будет создать публичный репозиторий на GitHub.

Stack Overflow

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

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

Методологии разработки

Следует разобраться, что такое Agile-подход, хотя бы в теории, возможно, выучить «артефакты» Scrum.

Недавно IT Ukraine Association выложила документ с набором необходимых навыков для junior-специалистов. В своей учебе можно также ориентироваться на него. Методологии разработки и релиз-менеджмент уже занимают там важное место. Начать изучать Scrum можно прямо с Wiki.

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

Бонус #3
Даю свой список вопросов для подготовки к собеседованиям, который я составил несколько лет назад. Если ответите на все эти вопросы, можно сказать, что вы знаете C#/.NET и Core-библиотеки на уверенном middle-уровне.

Советы для разработчиков Middle/Senior уровня

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

C#

«C# in Depth» by Jon Skeet

Книга Джона Скита, топового комментатора со Stack Overflow. Джон — профессиональный разработчик на Java в Google, но это не помешало ему написать бестселлер про тонкости синтаксиса C#.

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

T-SQL

«Querying Microsoft SQL Server 2012» by Dejan Sarka

Книга по подготовке к экзамену 70-461от «Майкрософт». Более структурного и внятного справочника по T-SQL я не находил. Темы очень четко разделены между собой, много наглядных примеров, даются все тонкости синтаксиса T-SQL. По сути, больше, чем в этой книге .NET разработчику, если он не является профессиональным Database developer’ом, знать и не нужно.

Архитектура

«Patterns of Enterprise Application Architecture» by Martin Fowler

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

«Enterprise Application Architecture with .NET Core» by Ganesan Senthilvel

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

«Refactoring: Improving the Design of Existing Code» by Martin Fowler

Книжка Мартина Фаулера. Дается очень глубокий аналитический подход по рефакторингу и улучшению существующего кода.

Фреймворки

Если вас беспокоят вопросы производительности в старом-легаси проекте, а переписывать на чистый SQL вы не хотите — рекомендую гайд «Performance Considerations for EF 4, 5, and 6»

На Entity Frameworkможно писать достаточно производительный код, не прибегая к помощи Dapper’a или чистого ADO.NET, либо же переписывать уже существующий, оптимизируя его.

Также несколько книжек по более детальному разбору возможностей Entity Framework и производительности:

• «Mastering Entity Framework» by Rahul Rajat Singh
• «Entity Framework 6 Recipes» by Zeeshan Hirani (Author)

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

• Security — «.NET Framework Security» by Brian A. LaMacchia;
• Threading — «C# Threading Handbook» by Tobin Titus;
• Memory management — «Under the Hood of .NET Memory Management» by Chris Farrell.

Обзор Open-source проектов

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

И еще можете глянуть самый знаменитый .NET Open-source E-commerce движок.

Нужны ли сертификаты от Microsoft?

Решать вам, в этом вопросе я не специалист. Однако скажу свое мнение.

Pros:

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

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

Cons:

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

Куда расти дальше

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

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

Или же выбирайте базовые книги по проектному менеджменту: «Мифический человеко-месяц, или Как создаются программные системы»Фредерика Брукса.

Более академическая литература по проектному менеджменту — «Руководство к своду знаний по управлению проектами».

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

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

Ответы на популярные вопросы

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

Нужна ли программисту математика и алгоритмы?

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

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

Для входа в IT, думаю, с головой достаточно понимать:

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

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

И несколько холиварных вопросов :)

Что лучше — Java или C#?

В мире разработки есть более или менее уместные средства решить задачу, в том числе важный фактор — возможность найти людей, знающих технологию, и их цена. Однозначного ответа нет. На Java больше open-source, в C# более модерновый синтаксис. Java хостится на Linux, C# требует Windows, хотя .NET Core разворачивается на Linux, что делает его хорошим выбором для микросервисов под бесплатными системами управления базами данных, например PostgreSQL или MongoDB. У всех технологий есть плюсы и минусы. Все зависит от конкретной задачи.

Ставить или нет нижнее подчеркивание для приватных членов класса?

Как хотите :) Однако если весь проект написан в едином стиле, его проще читать, и члены команды привыкают читать код быстрее. «C# Coding Conventions (C# Programming Guide)» — кое-что описано тут. Можно использовать StyleCop и блокировать компиляцию проекта в случае несоответствия форматированию. В целом стандартизация повышает скорость и понятность.

Что лучше — SQL или NoSQL базы данных?

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

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

Вот и все, если захотите со мной связаться, можете писать прямо на Facebook — Vladislav Furdak.

Статья написана по мотивам моего доклада на митапе «Съесть собаку».

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

В чем проблема

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

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

Что же делать

Для того чтобы наша программа сама нам могла сообщить, что у неё «болит», мы возьмем пару готовых и бесплатных решений — ElasticSearch, LogStash и Kibana — и свяжем их воедино.

ElasticSearch — самонастраивающаяся база данных с хорошим поиском по тексту. Можете посмотреть тутор по ElasticSearch.

LogStash — синхронизатор с ElasticSearch и сбор логов из источников.

Kibana — веб-интерфейс с большим количеством дополнений.

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

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

Хорошо настроенная Kibana может отображать данные в виде таблиц, графиков, карт и т. д.

Пример #1: социальная сеть

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

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

Что нужно сделать

1. Подобрать логгер.
2. Создать класс для хранения действий пользователя, которые предшествуют ошибке.
3. Логировать взаимодействие с сервером.
4. Логировать сокет соединения.
5. Отправить данные на ElasticStack.

Начнем!

Подберем логгер для нашего приложения. Если это бекенд, я рекомендую использовать Winston. Для фронта я беру js-logger, он поддерживает основные методы логирования — log, info, warn, debug, error.

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

export default class CollectionWithLimit {
    constructor(props) {
        this.limit = props.limit || 10;
        this.data = [];
    }
    checkLimit() {
        if (this.data.length === this.limit) {
            this.data.shift();
            return true;
        }
    }
    add(data) {
        this.data.push(data);
        return this.checkLimit();
    }
}

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

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

this.stack.session.start = getCurrentDateISO();
this.stack.actions = actions;
this.stack.env.lang = lang;
this.stack.env.href = href;
this.stack.env.localization = getItem('localization');
this.stack.env.theme = getItem('theme');
this.stack.env.userID = getItem('userID');

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

Префикс redux дает понять, на каком слое нашего приложения произошла ошибка.

Мы записываем тип действия с пометкой redux и те данные, которые пришли с действием.

const logActionsMiddleware = store => next => action => {
    let payload = Object.keys(action)
            .filter(key => key !== 'type')
            .reduce((payload, key) => {
                payload[key] = action[key];
                return payload;
        }, {});
    logger.log(`redux|${action.type}|${JSON.stringify(payload)}`);
    return next(action);
};

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

rest.interceptors.request.use(
    config => config,
    error => {
        if (error.message) {
            logger.error(error.message);
        }
        return Promise.reject(error);
    }
);
rest.interceptors.response.use(
    response => response.data,
    error => {
        if (error.message) {
            logger.error(error.message);
        }
        return Promise.reject(error);
    }
);

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

this.socketManager.io.on(SOCKET_EVENTS.NOTIFICATION, notification => {
    if (notification.status === 'error') {
        logger.info(`socket|Error ${notification.message}`);
        this.props.onAuthUpdate();
    }
    else {
        this.props.onAddNotification(data); 
    }
});

Также не забываем:

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

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

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

    static displayName = 'MyComponent';
    ...
    componentDidCatch(err) {
        logger.error(`react.${this.displayName}|${err.toString()}`)
    }

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

Затем мы подписываемся на onerror и, в случае возникновения ошибки, шлем в наш Elastic информацию со всеми данными из стека.

window.onerror = (errorMsg, url, lineNumber, lineCount, trace) => {
    // create critical error
    let critical = {};
    critical[CRITICAL] = serializeError(trace, lineNumber);
    let criticalData = mixParams.call(this, critical, true);
    this.stackCollection.add(criticalData);
    // get stack data
    let stackData = this.getStackData();
    // send log to server
    this.sendLogToServer(stackData);
};

Что мы получили

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

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

Пример #2: CleverBrush

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

Мы решили вышеописанный подход прокачать.

На нашем проекте не было никакого Redux, что же нам делать в таком случае? Есть 3 подхода, как организовать качественное логирование приложения:

1. @ - декораторы — способ обернуть наш метод в функцию, в которой мы можем логировать состояние до выполнения метода и после. Такой подход подойдет, если у вас legacy код.
2. Proxy — отличный способ, интегрирует любой код в методы взаимодействия с объектом. К сожалению, поддерживается не всеми браузерами.
3. Писать код сразу с логами — хороший вариант при разработке с нуля. В таком случае вы ничего не пропустите, и код будет максимально покрыт логированием.

Так как у нас стартап, требований у нас нет, и иногда у нас не все логично.

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

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

window.onerror = (errorMsg, url, lineNumber, lineCount, trace) => {
...
    // show BSOD
    let bsod = BSOD(stackData);
    document.body.appendChild(bsod);
...
};

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

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

Наше приложение тесно взаимодействует с бекендом. Так как бекенд мы полностью писали с нуля, мы его тоже покрыли логированием. Для этого использовали winston + запись в файл через middleware Express. Logstash парсит логи из файла и отправляет в ElasticSearch. Чтобы объединить логи бекенда и фронта, мы можем генерировать ID сессии и отправлять в хедере каждого запроса.

rest.defaults.headers.common.sessionId = global.__session_id__;

Таким образом, у нас будет понимание: мы отправили запрос, и этот запрос выполняется на сервере. Приходит ответ, мы продолжаем работу на клиенте. В Kibana мы будем фильтровать по ID запросам и смотреть, что произошло.

Когда мы отправляем стек действий на Elastic, тестировщику приходит ID, и он его прикрепляет к тикету.

Что мы получили

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

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

Альтернативы

В качестве альтернативных подходов я выделяю:

• Rollbar хорошо настраиваемый. Позволяет залогировать 500 тысяч ошибок за 150$ в месяц. Рекомендую использовать, если вы разрабатываете приложение с нуля.
• Sentry более прост в интеграции, но менее кастомизируем. Позволяет залогировать 1 миллион событий за 200$ в месяц.

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

Что дальше

Логирование — это не только поиск ошибок, это еще и мониторинг действий пользователя, сбор данных. Логирование может быть хорошим дополнением к Google Analytics и проверкой User Experience.

Выводы

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

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

Детальнее о логировании вы можете узнать из видео моего докладаили в презентациина митапе «Съесть собаку».

Привет, меня зовут Виталий Малаховский, я инженер в компании Genesis.

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

• Нарисовать анимацию в Adobe After Effects, а потом легко мигрировать на любую платформу (iOS / macOS / Android), используя Lottie, — супервариант для нас как для разработчиков (потому что, по сути, и делать ничего не надо). Но для этого нужно, чтобы кто-нибудь знал After Effects, поэтому мы его не рассматривали.
• Использовать векторные ресурсы и относительные значения при работе с UIKit, — это именно то, о чём я вам расскажу.

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

Векторные ресурсы

Мы будем использовать PDF формат ресурсов — это векторный формат, поэтому мы можем масштабировать их настолько, насколько нам нужно, — а значит одним файлом можно пользоваться для всех разрешений. Для этого загляните в xcassets и найдите необходимый PDF — или добавьте его туда сразу, если его там еще нет 😬 Проверьте, чтобы было выбрано «Single Scale» в подменю «Scales» и отмечен «Preserve Vector Data». На этом с ресурсами закончили.

Относительные значения

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

Прежде всего, поместите все элементы в геометрическую фигуру. Если навести курсор на область рядом с изображением, Zeplin покажет вам прямоугольник/квадрат, в который оно вписано, или размеры до края экрана. Тогда можете ориентироваться на них. Запишите/запомните размер геометрической фигуры в пикселях. В моем случае это — прямоугольник 264×233.

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

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

Пример:
Размер моего изображения — 26×117, Х и Y — 36 и 58 соответственно.
Центр по горизонтали = Х + «ширина» / 2 = 36 + 26/2 = 49.
Центр по вертикали = Y + «высота» / 2 = 58 + 117/2 = ~117.
Центр = 49×117.

Layout constraints

Теперь мы можем начать работу с XCode. Создайте UIView, где будут располагаться все элементы. При желании, можете сделать размер UIView такой же, как и у фигуры, относительно которой мы меряли размеры. 264×233 — в моем случае.

Добавьте UIImageView и установите ей PDF в качестве изображения. Установите «layout constraints» для ширины и высоты, относительно супервью. Значения констант для всех наших «layout constraints» должны равняться 0, но вот множители (multipliers) должны выражать соотношения между размером грани изображения и размером грани фигуры, в которую мы вписываем наши изображения.

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

Пример:
Размер моего изображения — 26×117, размер супервью — 264×233.
Множитель для высоты = «высота изображения» : «высоты супервью» = 117:233.
Множитель для ширины = «ширина изображения» : «ширина супервью» = 26:264.

Теперь нам нужно установить позицию для наших изображений. Она тоже будет в относительных величинах. Для этого мы, собственно, и заморачивались с центральными точками, которые рассчитали ранее. Установите «layout constraints» для изображения, чтобы оно стояло ровно по центру супервью (center horizontally in container & center vertically in container). Значения констант должны равняться 0. Множители должны иметь следующее значение: желаемый центр оси изображения к центру оси фигуры, в которую мы вписываем изображение.

Пример:
Желаемый центр изображения = 49×117.
Размер супервью = 264×233, соответственно центр суперью = 132×117.
Множитель по горизонтали = «центр изображения по оси Х» : «центр супервью по оси Х» = 49:132.
Множитель по вертикали = «центр изображения по оси Y» : «центр супервью по оси Y» = 117:117 или просто 1.

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

Анимация

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

Требования: вилка должна сместиться на 30 пикселей влево. Относительное значение будет следующим: «смещение» / («ширина» / 100%) = 30 / (233/100) = ~13%. Чтобы использовать наш результат в коде, мы должны умножить это относительное значение на значение ширины супесью (то есть сделать обратное вычисление).

Пример кода:

private func newTableClothAnimator() -> UIViewPropertyAnimator {
    return UIViewPropertyAnimator(duration: 0, curve: .easeInOut) {
        self.tableCloth.transform = CGAffineTransform(translationX: -(self.frame.width * 0.13), y: 0)
        }
}

Итоги

• Экономия на ресурсах — мы используем один PDF-файл, вместо 3-х png-картинок.
• Сцена, которая выглядит идентично на любом iOS устройстве.
• Анимация, которая выглядит идентично на любом iOS устройстве.

Короткий пример того что получилось 👇

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