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

Я живу в Кремниевой долине 5-йгод и работаю Software Engineer в компании Styra. В статье я постараюсь описать свое субъективное видение жизни в этом месте.

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

Что это за место

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

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

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

Big sur California. Чуть меньше 3 часов езды от Долины

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

Работа

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

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

Интервью и зарплата

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

Справедливости ради, стоит признать, что без этого можно обойтись. Живой пример — моя подруга, получившая недавно 3 оффера в Apple, Airbnb и небольшой стартап на позицию Ruby on Rails разработчика и зарплатой порядка $150K в год до налогов. Ее интервью были на порядок проще, чем те, которые проходила я, но и работать ей придется с достаточно старым кодом, что уже звучит не так волнующе. У меня есть еще несколько примеров ребят, получивших должность разработчика без алгоритмических задач на интервью. Минусы позиций, на которые они устроились, на мой взгляд, — достаточно унылые проекты со старыми технологиями и низкая заработная плата.

Как показала практика, с совершенного нуля (это когда не знаешь, как найти максимальный элемент в массиве или что такое бинарный поиск) можно подготовиться к интервью в Google или Facebook за 6-18 месяцев,пройдя курс на Сoursera и решая задачи medium-уровня на LeetCode. С 2-3годами опыта работы разработчиком и хорошей подготовкой можно рассчитывать на суммарную компенсацию $180-200K в год в Facebook, из которых базой (непосредственно зарплата) будет $100-120K, остальное — стоки и бонусы.

Еще одна моя подруга, которая имеет в целом 12 лет опыта, последние 3 из которых проработала в Amazon, недавно получила оффер в Google с суммарной компенсацией чуть больше $300K в год. Подготовка к интервью у нее заняла 2 года. Занималась она 2 раза в неделю по 2-3часа — день LeetCode, день — системный дизайн.

Для позиции выше, чем джуниор (это примерно 2-3года опыта работы, может, чуть больше), кроме алгоритмов, для интервью понадобится системный дизайн. Пример вопроса: «Расскажите, как бы вы делали Twitter» или «Дизайн корзины покупателя в Amazon». Кроме описания дизайна самого проекта, нужно еще рассказать, как бы вы масштабировали эту систему на 10, 1000, 10K запросов в секунду. Как выглядят типичные вопросы и ответы для дизайн-интервью можно посмотреть здесь.

Нормальная практика в Долине — получить предложение на позицию, которая подразумевает работу с технологиями, с которыми у инженера нет никакого опыта. Считается, что хороший разработчик, может разобраться в любой технологии за приемлемые сроки. Обычно это 3-6 месяцев,в то время как поиск идеального кандидата может занять намного больше. Также очень часто в компаниях уже существует самописная инфраструктура, которую, конечно, нигде не изучишь. Я вышла на работу, зная только слово docker из всего того, с чем мне предстояло работать. Как мне рассказывали коллеги, именно поэтому на интервью и задают общие задачи, которые проверяют базовые знания Computer Science (алгоритмов) и показывают, как человек мыслит.

Рабочая культура (company culture)

Наверное, «корпоративная культура» — не совсем правильное название, но я не смогла подобрать адекватный перевод. Если вы спросите о том, как работается в американских компаниях, вам ответят: «Depends of company culture and team». Грубо говоря, существуют негласные законы, действующие во всей компании, которые дополняются правилами конкретной команды. К примеру в «Амазоне» company culture (по крайней мере в офисе Bay Area) предписывает выкатить продукт как можно раньше, а уж потом разбираться, что там нужно добавить и где какие костыли пофиксить. То есть если разработчики оценили сроки работы над проектом в 3 месяца, то их могут очень настойчиво попросить сделать то же самое за месяц. Окей, без юнит-тестов и с костылями здесь, тут и вон там. Но за месяц.

Что здесь достаточно распространено и практически не зависит от компании, так это отсутствие привычных кофе-брейков и посиделок в интернетах вместо работы. Для меня было огромным шоком, что рабочее утро не начинается на кухне. В 9:30 почти все уже на работе и сразу открывают IDE и начинают писать код. Работают действительно целый день (у нас опенспейс, и я вижу мониторы почти всех коллег). Хорошая новость — привыкаешь к этому достаточно быстро, и уже не очень понятно, как же можно иначе.

Уровень разработчиков

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

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

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

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

Удаленка

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

Аутсорс гораздо дешевле: разработчик в Штатах, получающий «на руки после налогов» $7K в месяц, обходится работодателю в 13K в месяц + офисные расходы и прочие макбуки. Но, несмотря на это, аутсорса стараются избегать до последнего — низкая продуктивность, особенно если это стартап.

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

Цены, быт и окружение

Цены

San Francisco Bay Area — достаточно дорогое место. Я бы сказала очень дорогое. Основная статья расходов — это жилье. Его стоимость увеличивается по направлению с юга на север — то есть от San Jose до San Francisco. Квартира с одной спальней (двухкомнатная по украинским меркам) в южном Сан-Хосе на данный момент (зима 2018) стоит около $2000, в Сан-Франциско такая же квартира будет стоить уже на $1K больше.

В среднем расходы на квартиру (в районе San Jose — Mountain View), еду, оплату кредита за машину (стоимостью до $25K), бензин и другие мелочи на одного человека будут составлять $3,5-5K. Конечно, можно как увеличить, так и уменьшить эту цифру, но я привела, что называется, среднюю температуру по больнице.

Улицы в Santa Clara перед Рождеством

Быт

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

Лично для меня многие бытовые вещи здесь оказались гораздо проще. Для всего на свете есть инструкции. Хочешь получить права — принеси такие-то документы (список), сделай такие-то шаги (список) и все.

Права — это как пример. Сейчас я не имею в виду спорные кейсы, которые требуют работы адвокатов. Вот здесь все гораздо более печально. Я не буду останавливаться на этом подробно в статье, но если вас угораздило работать с адвокатом, по любому кейсу — будь то green card process или суд за разбитую машину — всегда пинайте адвокатов и пять раз перепроверяйте то, что они вам говорят. Это правило. Если этого не делать, ваше дело будет тянуться в 5 раз дольше, чем могло бы, и они все время будут исправлять ошибки, которые сами же делают.

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

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

Окружение

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

Как переехать

Переехать можно такими способами:

• рабочие визы: H-1B, L-1;
• другие визы: O-1, J-1;
• выйти замуж;
• жениться;
• стать беженцем.

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

Про H-1B и L-1 многие знают. В крайнем случае легко нагуглить. Очень интересна О-1 виза — грубо говоря, это виза для одаренных. В какой-то степени так и есть, но при достаточной подготовке это самый простой вариант. Хотя и не самый дешевый. Я лично знаю ребят, которые получили эту визу. Один из них программист, второй — рекламщик. За выдающиеся достижения у программиста пошли участия и победы на нескольких хакатонах. В целом за 6-8месяцев можно вполне подготовить все документы. Если у вас есть книжка — отлично! Нет — можно успеть написать книгу «Мой любимый фреймворк для чайников» — подойдет. Работа адвоката обойдется в $6-10K.

J-1 — студенческая виза. С дипломом, полученным в США, можно податься на H-1B вне общей очереди (для этой цели ежегодно выдается определенное количество виз). Так же можно пойти в науку и получить PhD совершенно бесплатно, даже получая за это зарплату. К сожалению, в этой теме я плаваю, но детали гуглятся достаточно легко.

Выводы

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

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

Продакт- и requirements-менеджеры каждый день сталкиваются с разными вариантами поведения системы в своих продуктах. И каждый раз возникает вопрос: что сообщать пользователю? И сообщать ли вообще?

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

Сразу проясним, кто должен заниматься написанием текстов. C моей точки зрения, это только продакт- (requirements) менеджер / бизнес-аналитик. Никто другой лучше с этой задачей не справится: дизайнер должен заниматься визуализацией интерфейса, у разработчика нет всей полноты картины, technical writer довольно редко встречается в команде, а у клиента/топ-менеджера и так забот полно.

Разберем 3 составляющих сообщения для пользователя: содержание (контент), формат и стиль.

Лучшее сообщение — никакого сообщения

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

К примеру:

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

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

Содержание

Максимальная простота

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

Объясните, что именно произошло

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

By Amazon

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

Вот еще плохой пример ошибки:

• «Printing failed».

А вот как это можно исправить:

• «I couldn’t print your document. Check your printer or connection».
• «Couldn’t print your file. Check your printer or refer to troubleshooting documentation».
• «The file didn’t print. Is your printer turned on?».

А как сообщать очень плохие новости? Точно не так:

Moving Fulcrum

А лучше так:

Tumblr

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

Сокращайте текст

Good
«Oops! Something went wrong between your printer and me. Please check if your printer is turned on, connected to the network or printing settings».

Better
«Oops! Something went wrong between your printer and me. Better check to see if everything is OK».

Best
«Oops! Looks like your printer isn’t connected properly».

Но не сокращайте слишком сильно

Medium

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

Расскажите, как исправить ситуацию

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

Вот не самый лучший пример:

Spirit

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

А вот пример гораздо лучше:

By Microsoft

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

Убедитесь, что понятен контекст

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

Medium

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

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

By Jira

Напишите, что именно требуется от пользователя

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

UX Planet

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

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

Вот гораздо более гуманный вариант:

UX Planet

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

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

Используйте как можно более избитые слова и формулировки: Save, Follow, Share и т. д. Это помогает пользователям быстрее сориентироваться и принять решение. Сами слова должны быть как можно короче и проще.

«Кради как художник»

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

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

Избегайте двузначности

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

В примере ниже пользователю нужно 2 раза прочитать текст и выбрать нужный вариант:

Google Material design guide

Намного лучше, если вы повторите слово из заголовка, и action-кнопка будет глаголом:

Google Material design guide

Разные сообщения для разных событий

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

Freshsparks

Размещение

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

By Airbnb

Сделайте сообщение заметным

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

Вот плохой пример из сайта одной из киевских клиник:

А вот хороший:

UXmas

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

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

Потом все же руки дошли до оптимизации и получился следующий вариант:

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

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

Стиль написания

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

Используйте неформальный стиль (если это уместно)

К примеру, можно пошутить:

By Yahoo

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

Не вините пользователя

By Tumblr

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

Вот пример хорошей тональности сообщения:

By Dropbox

Подчеркивайте роль пользователя

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

This post was liked by you. -> You liked this post.

Password needs to be changed after first login. -> Please change password after your first login.

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

Проверяйте текст у носителя языка

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

Выводы

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

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

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

• Apple Human Interface Guidelines (PDF)
• Modern Apple design guidelines for iOS
• Material design guidelines

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

Ruby и Rails

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

Фреймворк Rails внёс огромный вклад в развитие языка Ruby, и именно в последнее время, вместе с появлением Rails, интерес к Ruby стал стремительно возрастать. Так что, если у вас есть желание научиться создавать различные web-приложения и не только на Rails, то можно одновременно изучать и Ruby, и Rails.

На просторах интернета существуют тысячи статей, в которых описано создание RoR блога за 15 минут (признаюсь честно: когда я начинал, уложиться в 15 минут ни разу не получалось). Вы можете использовать любой гайд, который вам понравится. В своей статье я приведу некоторые наблюдения, рекомендации и список основных гемов (или gems — так в руби называются библиотеки), которые желательно иметь в своём пет-проекте и которыми нужно уметь пользоваться, если вы планируете работать на RoR.

Для начала, хочу поделиться двумя источниками, которые я применяю в работе:

• ресурс с документацией для Ruby;
• ресурс с документацией для Rails.

Настройка окружения

Первым делом нужно настроить окружение. Лучшими операционными системами будут Linux (например, Ubuntu) и Mac OS. Ситуация с Windows на данный момент обстоит не лучшим образом, и я бы не рекомендовал тратить своё время и нервы, хотя в будущем все может измениться. Недавно компания Microsoft выпустила обновление для Windows 10, которое позволяет установить «Bash on Ubuntu on Windows Linux Subsystem». Но даже сама формулировка звучит жутко, и пока что всё работает нестабильно, так что остается надеяться и ждать.

Хороший ресурс для настройки окружения — Go Rails. Тут описаны настройки для Ubuntu, Mac OS и для Windows. Ресурс в целом полезен и достоин места в копилке полезных ссылок RoR-разработчика.

Интересное наблюдение.Первые несколько раз настройки окружения редко заканчиваются успехом, может потребоваться не одна попытка. В то же время все те ошибки, которые вы совершите в начале необходимы, чтобы никогда больше к ним не возвращаться. Зачастую эти ошибки происходят из-за пропуска одного из пунктов. Также, если вы используете RVM, советую использовать файлы .ruby-version и .ruby-gemset. По завершении настройки, вы сможете создавать новые Rails-приложения и запускать сервер.

Полезная информация.По умолчанию rails сервер использует 3000-йпорт. Может возникнуть ситуация, когда нет возможности нажать Ctrl+C для остановки сервера. На помощь придет ответ с ресурса Stack Overflow.

Установка Ruby Gems в проект

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

Для установки Ruby Gems (или гемов) в Rails-проект вам понадобится утилита Bundler. Она управляет версиями гемов и их зависимостями. Список гемов, которые применяются в проекте, находится в файле gemfile.

Полезные Ruby Gems

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

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

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

Gem twitter-bootstrap-rails — подключает инструментарий, разработанный компанией Twitter. Включает в себя различные стили и верстку, применение которых сделает ваше приложение более приятным глазу.

Gem jquery-rails — JavaScript — это хорошо, но работодатели требуют знание фреймворков, например, jQuery. Использование его упростит работу с JavaScript и позволит сделать приложение более динамичным.

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

Gems byebug’/ ‘pry-rails — гемы для отладки и дебаггинга. Позволяют создавать брейкпоинты в приложении, добавляя в вызов метода, где это необходимо.

Gem rspec — мощный инструмент для написания автоматических тестов.

Gem capistrano — инструмент для деплоя.

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

Gem rubocop — один из важнейших гемов. У каждого языка — свой style guide (предпочтения к форматированию текста кода). В Ruby это rubocop. Он поможет вам писать код так, чтобы в вас не кидались камнями люди, которые будут работать с вашим кодом. Несмотря на то, что rubocop — всего лишь набор пожеланий к оформлению, на начальных стадиях он может научить многому. Анализируя код, он выделяет те места, которые оформлены неверно, а также предлагает рекомендации по его улучшению. Именно эти рекомендации помогут вам лучше изучить Ruby. Также некоторые правила можно отредактировать.

Рекомендации к написанию кода

В rubocop указана максимальная длина строки 80 символов, однако для современной веб-разработки этого недостаточно. Для большинства случаев 120 символов должно хватить.

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

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

Хороший пример указан в книге Сэнди Метц «Ruby. Объектно-ориентированное проектирование»:

		def diameters
		wheels.collect do |wheel|
			wheel.rim + (wheel.tire * 2)
		end
	end

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

	# обход всех элементов массива
	def diameters
		wheels.collect { |wheel| diameter(wheel) }
	end

	# вычисление диаметра одного колеса
	def diameter(wheel)
		wheel.rim + (wheel.tire * 2)
	end

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

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

В реальной жизни существуют немного иные ситуации. Например:

class Gear
	# . . . 

	# Передаточное отношение в дюймах
	def gear_inches
		ratio * diameter

	# Диаметр колеса
	def diameter
		wheel.rim + (wheel.tire * 2)
	end

	# . . .
end

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

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

Итого

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

В выпуске: тенденции в развитии JavaScript, что происходит с F#, обзор возможности запуска Linux-контейнеров на Windows.

.NET

Dissecting the async methods in C#, The performance characteristics of async methods in C#
Отличные статьи об устройстве и производительности асинхронных методов.

Herding Nulls and Other C# Stories from the Future
Видео о планах на будущее в развитии C#.

All About Span: Exploring a New .NET Mainstay

Deep-dive into .NET Core primitives: deps.json, runtimeconfig.json, and dll’s

Using MVC result executors in ASP.NET Core middleware

HttpClientFactory Consumption Patterns

Stacktrace improvements in .NET Core 2.1

Parallelizing Tasks with dependencies — Design your code to optimize performance

ASP.NET Core 2.1 roadmap

A new experiment: Browser-based web apps with .NET and Blazor
Анонс экспериментального фреймворка, который позволяет выполнять Razer страницы в браузере используя WebAssembly.

Архитектура

AWS Lambda Reserved Concurrency
Возможность ограничивать количество одновременно выполняющихся лямбд, чтобы контролировать нагрузку на БД или другие системы.

Using the MongoDB Oplog to trigger asynchronous work

Sure, you can just use RabbitMQ
Что нужно иметь в виду при проектировании систем обмена сообщениями.

Should You Put Several Event Types in the Same Kafka Topic?
Отличная статья о том, как решить, какие сообщения отправлять в какой топик.

Learnings from Using a Reactive Platform — Akka/Squbs

Legacy Evolution: Moving Quickly & Safely From Monolith To Microservices

Инструменты

C# Interactive in Rider

Debugging third-party code with Rider
Очень удобная штука с генерацией исходников на лету.

Curated list of Rider content

General web development updates in Rider 2017.3

Tar and Curl Come to Windows!

Build better apps faster by generating types from data
Удобный инструмент, позволяющий генерить типы по данным, например класс по JSON.

A sneak peek at LCOW
Обзор возможности запуска Linux-контейнеров на Windows.

Docker for Mac with Kubernetes

UI

I just asked 23,000 developers what they think of JavaScript. Here’s what I learned.
О тенденциях в JS.

Chrome is turning into the new Internet Explorer 6

Книги

Why Great Teams Embrace Remote Work

Distilling Domain-Driven Design

Разное

Framework Benchmarks Round 15

Stack Overflow Developer Survey 2017

Remote Work in the 2017 Developer Survey

Best-websites-a-programmer-should-visit

31 Million Client Registration Files Leaked by Personalized Keyboard Developer

Functional Geekery Episode 118 — Scott Nimrod
О том, что происходит с F#, использовании в продакшене, инструментах.

Remote-First vs. Remote-Friendly

Thanks a Million, Jon Skeet!
Jon Skeet заработал 1М рейтинга на SO.

12 tips to write unit tests that don’t cripple your codebase

Crossover Hiring Tournament — Kiev
Видео турнира, в котором я принимал участие. Было весело, рекомендую поучаствовать. Для кого-то это может быть возможность проверить свои скилы, для кого-то — найти более интересную работу.

GitHub PRs

Remove my password from lists so hackers won’t be able to hack me

Add configure option to enable blockchain usage

Интересные твиты

„A developed country is not a place where the poor have cars. It’s where the rich use public transportation.” —@EnriquePenalosa
(Photo: #Strasbourg, France)December 6, 2017

Holy moly. You can write a key logger in pure CSS. I wonder if @reddit custom themes would be vulnerable. github.com/maxchehab/CSS-Keylogging ...February 20, 2017

A senior programmer is merely a junior programmer who has given upFebruary 20, 2017

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

[В серии «Обзор IT-рынка труда»мы рассказываем об IT-индустрии в разных городах Украины]

В ІТ-индустрии Херсона занято около 1000 специалистов, в городе есть офисы более 20 ІТ-компаний и веб-студий. Ежегодно вузы готовят 100-150будущих ІТ-специалистов.

Средние зарплаты программистов в Херсоне:

• Junior — $300-500;
• Middle — $600-800;
• Senior —$1500-2300.

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

Компании

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

Wezom

Украинская аутсорсинговая компания
200+ сотрудников в Херсоне

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

В мобайле преобладает нативная разработка. Применяют архитектуру MVVM, есть кейсы работ с Unity Engine, WebRtc video streaming, GMS (Google maps services). В работе используют сервисы Firebase Cloud Messaging, Firebase Crash Reporting, Firebase Analytics.

Основные технологии: PHP 5.6+, PHP 7, JavaScript, jQuery, NodeJS, MySQL, PostgreSQL, Redis, Laravel 5, Yii 2, Symfony, ReactJS, VueJS, Wordpress, OpenCart, Bitrix, .NET, Angular.

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

DataArt

Американская аутсорсинговая компания
173 сотрудников в Херсоне, 1230 в Украине

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

Основные технологии: .NET, JavaScript, QA, Java, PHP, Python, Mobile.

Возможности для начинающих специалистов:в компании есть практиканские программы по направлениям .NET, Java, JavaScript, QA и QA Automation. Если по итогам стажировки практикант достигает должного профессионального уровня, куратор рекомендует пригласить его на работу в компанию. Более половины сотрудников херсонского офиса пришли в DataArt благодаря практикантским программам.

Помимо этого, DataArt проводит бесплатные IT-школы по QA, Java, .NET. Участвовать могут разработчики и студенты 3–5 курсов,владеющие разговорным английским и теоретическими знаниями по выбранной технологии. Лучших выпускников школ рекомендуют для зачисления на практикантские программы.

Logicify

Польская аутсорсинговая компания
50 сотрудников в Херсоне

Создает цифровые продукты и сервисы для клиентов из Европы и США: разрабатывает ПО с нуля для стартапов, а также усиливает своей экспертизой R&D-отделы крупных компаний-заказчиков. Экспертные области: телеком, видео, соцмедиа, страхование.

Размеры команд варьируются от 2 до 20 человек. Основные технологии: PHP, Java, JavaScript (Angular), AWS.

Postindustria

Украинская аутсорсинговая компания
40+ сотрудников в Херсоне, 70+ в Украине

Разрабатывает веб- и мобильные сервисы для клиентов, среди которых — инновационные компании (UberSocial, Break Media), стартапы (IdeaLab) и мировые бренды (Playboy, Kimberly-Clark). Помимо аутсорсинга, развивает собственные проекты.

Bedrock CRM Consulting

Британская аутсорсинговая компания
20+ сотрудников в Херсоне

Компания занимается консалтингом и разработкой под Salesforce-платформу, а также специализируется на администрировании облачных серверов. Среди клиентов — Football Premier League, NHS, Scottish Equity Partners, London Internet Exchange, Imago Group, Doctors.nеt.uk and National Property Trade.

Также в Херсоне есть офисы таких IT- компаний:

• Altima Web Systems — веб-студия, специализирующаяся на разработке сайтов: порталов, лендингов, интернет-магазинов, каталогов, корпоративных-сайтов, сайтов-визиток.
• Bonsite — студия, которая создает мобильные приложения для iOS и Android, программы и сайты для разных сфер бизнеса. Развивают собственный продукт Bonsite CRM.
• Boosters — студия интернет-маркетинга и дизайна, предоставляет услуги по продвижению сайтов, контекстной рекламе, SEO-аудиту, а также веб- и графическому дизайну.
• ChainBalance — предоставляет сервис по консалтингу и разработке ПО для цепочки поставок в розничной торговле в сфере моды.
• Elit Web — сертифицированное агентство «Яндекса» и Google, специализируется на продвижении сайтов в поисковиках и соцсетях. Также занимается контекстной рекламой и разработкой мобильных приложений.
• Essotec — маркетинговое интернет-агентство, создает и продвигает сайты, а также развивает собственный фреймворк для разработки, позволяющий выполнить тонкую настройку всех необходимых параметров для SEO.
• InStandart — специализируется на разработке SaaS-решений для e-Сommerce.
• JustIT — разрабатывает ПО для представителей малого бизнеса: корпоративные системы, веб- и мобильные приложения, а также предоставляет услуги по веб- и графическому дизайну, SIP-технологиям, интернет-маркетингу.
• NIKOLSTUDIO — веб-студия, которая занимается созданием сайтов, их продвижением и рекламой, а также графическим дизайном.
• Paradigma — веб-студия предлагает полный спектр услуг по созданию, продвижению и дальнейшей поддержке сайтов, а также разработку логотипов и фирменного стиля компании.
• Rifl Media — специализируется на разработке веб- и мобильных приложений. Флагманский продукт компании — Take It To, онлайн-платформа для управления контентом.
• Your Web Style — студия веб-дизайна, специализируется на разработке и продвижении сайтов, интернет-маркетинге, копирайтинге.
• YSBM Group — специализируется на создании B2B/B2C-проектов в сферах e-Learning, smart houses, VoIP, B2B SAAS aggregation platforms, CRM management systems, e-Commerce.
• «Мегасайт» — занимается разработкой и продвижением сайтов, а также комплексным интернет-маркетингом, контекстной рекламой, SMM, хостингом и регистрацией доменов, созданием логотипов и фирменного стиля.

Стартап- и продуктовый сегмент представляют:

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

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

За вакансиями в городе можно следить здесь.

Сообщества и события

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

IT talk Kherson — встречи в офисе компании DataArt, посвященные разным направлениям и технологиям: Java, .Net, JavaScript, QA и др. Участие бесплатное.

IT Day Kherson — социально направленная конференция для IT-специалистов и тех, кто интересуется IT. Организаторы: KAgency, «Сказка» и бизнес-ассоциация «Мы — херсонцы».

IT Day Kherson, октябрь 2017

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

За IT-событиями в городе можно следить здесь.

Образование

IT-специалистов в Херсоне готовят в трех вузах:

• ХНТУ (факультет кибернетики и системной инженерии);
• ХГУ (факультет физики, математики и информатики);
• Херсонская филия НУК им. Макарова (специальности «Инженерия программного обеспечения», «Информационные управляющие системы и технологии»).

Крупнейшие ІТ-школы:

• КА «Шаг» (разработка ПО, компьютерная графика и дизайн, сетевые технологии и системное администрирование);
• ISchool (Java, Front-end, Android, iOS, Data Science, QA, UI/UX, PM, HR, SMM, робототехника, игры, Kids);
• Main Academy (Java, QA automation, основы разработки);
• IT-школа DataArt (QA, Java, .NET.);
• IT-академия Wezom (PHP, Python, HTML+CSS+JavaScript, AngularJS+NodeJs, веб-дизайн, QA, SEO).

Перспективы Херсона как IT-региона

См. также обзоры IT-рынка труда других городов: Винница, Днепр, Житомир, Запорожье, Ивано-Франковск, Луцк, Львов, Николаев, Одесса, Полтава, Сумы, Тернополь, Ужгород, Хмельницкий, Черкассы, Чернигов, Черновцы.

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

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

Закон Мерфи

Зимой 2016, когда мы с женой поехали в круиз на Карибы, по возвращении я приехал в офис хорошо отдохнувший, без особого желания напрягаться после отпуска. Все было довольно предсказуемо: мы выдали релиз перед Рождеством, ошибок обнаружено не было, да и свой проект я знал досконально. Но законов Мерфи никто не отменял: если все идет хорошо, значит вы что-то упускаете. В обед мне назначили митинг у Senior Director, но ничего не предвещало беды...

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

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

Думать и делать: кто нужен в команду

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

Многие менеджеры скажут, что нужно было согласовать KT (Knowledge Transfer) plan или что-то подобное, и, конечно же, он у нас был (см. рисунок 1). Но план хорош, когда его готовы выполнять, а выполнять программисты из Коннектикута его не хотели и не собирались.

Рисунок 1

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

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

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

Рисунок 2

Не пытайтесь понять эту схему, раскритиковать или осмыслить. В ней есть и свои хорошие стороны, и недостатки. Но на тот момент я этого не осознавал. Было понятно только, что есть ядро, написанное на .NET 2.0/4.0 на базе COM/DCOM технологии, был API, написанный на ASP-Classic, и VB 6.0, интегрированный с ядром посредством COM-компонентов, а также фронтенд, написанный на HAHTSite Scenario Service (Java) cо своим скриптовым языком, с вкраплениями jQuery/Bootstrapper и т. д. Что-то ходило в базу через .NET SQL, что-то через OBDC, что-то через Microsoft Access. Все это было приправлено интеграцией с внешними библиотеками обработки пространственных данных MapInfo/MapXtreme и многим другим.

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

Команда и работа

Стало ясно, какая команда нужна, и выглядела она так: четверо программистов с нашей стороны с хорошим знаниями .NET, а также знаниями VB6.0 и опытом работы с пространственными данными. К работе подключили BA с нашей стороны, поскольку проект не содержал вообще никакой документации. То есть за 15 лет никто не удосужился вообще что-то задокументировать. В команду включили QA, потому что было не ясно, как вообще можно проверить эту систему на работоспособность, начать ее менять и мигрировать.

Со стороны клиента нам назначили BA, которая сидела в Чикаго, PM, который сидел в Лос-Анджелесе, Product, который сидел где-то в Коннектикуте, и одного Release-инженера, который сидел в одном кубике со мной.

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

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

«Самый медленный верблюд»

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

У него была идея разбить все на модули, сделать компонентный деплоймент. Отлично, это ему и поручили. После двух недель мозгового штурма у него стали закипать мозги от проекта: он пытался билдить проект и полностью, и частично, и покомпонентно — UI отдельно и back-end отдельно. Когда идеи исчерпались, он сказал, что development team должна разобраться и предоставить ему исправление ошибок билда. Я думаю, для многих знакомая ситуация — когда во всем должны разобраться программисты. Но пойдем дальше.

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

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

Первый программист уволился в конце марта

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

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

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

Рисунок 3

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

Второй программист ушел в апреле

Работу пришлось разбить на несколько частей. Я занялся полностью суппортом, так как другого способа просто не было. Никто лучше нас систему не знал, ни у кого не было понимания, как работает код и как можно поддерживать более 40 тыс. аккаунтов с более чем 6000 конфигураций на существующих 23 серверах. Двое ребят в Киеве начали разбираться в GUI и API, параллельно пересаживая его на более стабильную и современную платформу. Один человек занялся рефакторингом существующего ядра. BA начала работу над документацией: как система работает, какие есть конфигурационные настройки и как они влияют на работу приложения. QA занялся покрытием системы интеграционными тестами, разработкой тест-планов и стратегией тестирования.

Третий программист... на него я зла не держу

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

Начиная с апреля, моя работа состояла в том, чтобы прийти утром — выписать на доске проблемы, которые я планирую решить, и в течение дня менеджер просто подходил и расставлял на доске приоритеты. Никой Jira, TFS или Trello. Есть проблема — подходите, пишете на доске ее номер и все. Я знаю, что ее нужно решить раньше, чем проблему под ней. Затраты на коммуникации практически свелись на нет, так как объем приходящих проблем был просто колоссальный. Я мог в день закрыть 30 багов и на следующий день проснуться с еще 30-юновыми. Но через два месяца я уже знал ответы практически на 90% всех возможных вопросов, имел рабочую среду разработки и рабочий environment c возможность отладки, имел доступ ко всем production-системам.

Подходим к стабильной стадии

К осени у нас уже был рабочий прототип UI, написанный на Angular + ASP.NET MVC, документация и что самое главное — понимание, как работает система. И все казалось не таким страшным, но клиент решил отказаться от нового UI, сохранить сервера на Windows Server 2003 и попытаться мигрировать существующую систему в новый data-центр. И моя жизнь опять приобрела темный оттенок.

В нашей компании более 20 тыс. человек. И когда я попытался поискать кого-то с навыками работы c HAHTSite Scenario Server, я нашел только одну девочку, которая добавила это в описании своего проекта, еще когда пришла джуном, и даже не могла пояснить, что это значит и как это работает. Bот такой легаси код, пацаны...

Документацию по HAHTSite мы выкачали где-то на китайских сайтах, как и документацию по остальным компонентам. Компоненты работы с пространственными данными уже не поддерживались производителем, и клиент не хотел платить за лицензию. Я вспомнил VB 6.0, который учил еще на 2 курсе университета, и вы даже не представляете, что значит найти рабочий инсталлятор VS 6.0. Я научился реверс-инженерить программы, когда ты запускаешь код и просто с помощью Process Explorer-а видишь, как выполняется программа, что она берет из реестра, какое событие она передает, какую переменную инициализирует, смотришь через WireShark, куда отправляются пакеты и что возвращается обратно. Это магическое зрелище... и нудное одновременно.

В результате

На сегодняшний момент проект вошел в стабильную стадию, продукт стабильно генерирует более $45 млн прибыли ежегодно и масштабирован на 35 серверах. Потратили мы на проект около 2 лет, а на более-менее стабильную стадию мы вышли через 12-16 месяцев.Сейчас полностью построен билд-процесс и процесс тестирования, написано более 250 страниц документации, клиент спит спокойно и большинство ребят уже на другие проектах. И я хочу уже подвести вас к выводу, который я сделал:

КОМАНДА — ЭТО ВСЕ!

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

• Roman Gorielov (Development)
• Eduard Golubov (Development)
• Olga Oryshchyna (BA)
• Tamara Snigireva (Development)
• Volodymyr Neshta (QA)
• Gennadiy Likhota (Development)
• Sergii Losiev (Development)

Спасибо ребята! Вы лучшие!

Советы

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

Вот советы, которые я бы дал (постараюсь избегать общепризнанных очевидностей):

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

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

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

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

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

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

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

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

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

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

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

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

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

Якщо ви маєте інформацію про інші вакансії для початківців, безкоштовні курси/стажування, яких немає в дайджесті, пишіть на alyona@dou.ua, і ми додамо їх до статті.

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

AltexSoft

Напрям:курси .NET, QA, UI.
Місто:Кременчук.
Дедлайн подачі заявок: 10 березня.

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

• English — Pre-Intermediate і вище;
• для .NET — базові знання C#/.NET/SQL.
• для UI — базові знання HTML5/CSS3/SQL.
• для QA — базові знання SQL.

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

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

Деталі:на сайті.

Apiko

Напрям:курси JavaScript Full-Stack + React Native.
Місто:Тернопіль, Івано-Франківськ, онлайн.
Дедлайн подачі заявок: 5 березня.

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

• знання алгоритмів та розуміння принципів ООП;
• досвід програмування на будь-якій мові;
• базові знання JavaScript, HTML/HTML5, CSS/CSS3.

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

Умови:офлайн-курс проходитиме у Тернополі та Івано-Франківську, також планується запис відео для закріплення матеріалу вдома (буде доступне всім зареєстрованим користувачам). Початок навчання — 13.03.2018, заняття проходитимуть двічі на тиждень у вечірній час. Загальний курс охоплюватиме теми: Advanced JavaScript, React, Mongo DB. Далі буде можливість обрати напрямок: Full-Stack розробка (Meteor/GraphQL), мобільна розробка (React Native). Після успішного закінчення курсів найкращим випускникам буде запропоновано працевлаштування.

Деталі:на Facebook-сторінці.

Astound Commerce

Напрям:курси QA.
Місто:Вінниця.
Дедлайн подачі заявок: 23 березня.

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

• QA інженер початкового рівня;
• розуміння основ програмування;
• базові знання HTML/CSS;
• англійська на рівні intermediate;
• гарні комунікативні й аналітичні здібності.

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

Умови: QA Boot Camp буде проходити на стаціонарній основі в офісі компанії, у будні ввечері. Програма почнеться у квітні та триватиме до червня включно.

Деталі:на сайті.

Binary Studio Academy

Напрям:курси JS, PHP, .NET, QA.
Місто:Київ, Львів, Харків, online.
Дедлайн подачі заявок: 27 квітня.

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

• знання ООП, досвід з базами даних, початкові знання з JS, .NET, PHP або схильність до аналізу для QA курсу;
• бажання опанувати full stack з обраного напрямку;
• прагнення в подальшому працювати над розробкою веб- або десктопних додатків;
• готовність протягом липня — першої половини вересня, приділяти мінімум 6-8годин навчанню;
• не має значення: вік, місце проживання та рівень здобутої освіти (але студентам 3-5курсу технічних спеціальностей легше пройти завдання відбору).

Як потрапити:зареєструватися на сайті (реєстрація буде відкрита з 1 березня), пройти онлайн-тест 28.04 або 02.05, три завдання по лекціях і онлайн-співбесіду на 10-15 хвилин.

Умови:курс проходить онлайн, повністю безкоштовно. Викладачі — досвідчені програмісти Binary Studio. Перед початком навчання, 30.06, студенти та викладачі зустрічаються в офісі компанії на першу лекцію, а по завершенні курсу презентують там же свої командні проекти на випускному і отримують сертифікати. В липні студенти отримують відеолекції від викладачів і завдання до них (кожних 2-3 дні)та опановують повний стек навичок. В серпні та вересні розробляють під керівництвом коуча повноцінний додаток з нуля. Приклади минулорічних проектів можна побачити тут.

Деталі:на сайтіабо пишіть на пошту academy@binary-studio.com.

EPAM

Тип:курс DevOps.
Місто:Київ.
Дедлайн подачі заявок: 12 березня.

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

• мати уявлення про мережу і TCP / IP;
• базові знання теорії побудови операційних систем;
• базові знання адміністрування ОС Windows та Linux;
• вітається практичний досвід системного адміністрування;
• рівень володіння English не нижче A2;
• вміння працювати самостійно та в команді.

Як потрапити:зареєструватися на сайтіта пройти тестування. Тестування включає технічний комп’ютерний тест (30-60 хв)та співбесіду з рекрутером, перевірку рівня знань англійської мови (30 хв).

Умови:зовнішні заняття (до 3 місяців), Pre-Production лабораторія (від 3 до 6 місяців).

GeeksForLess Inc.

Напрям:курс Web Development (PHP, JavaScript).
Місто:Миколаїв.
Дедлайн подачі заявок:кінець березня.

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

• базові знання PHP (змінні, масиви, константи, умови, цикли, створення та використання функцій, об’єктів, PDO-клас для роботи з базами даних, класи по роботі з XML, функції по роботі з сесіями), рекомендовані ресурсидля підготовки;
• буде плюсом: SQL, базові знання Javascript.

Як потрапити:надіслати резюме на mykolayiv@geeksforless.comз позначкою «Курс Web Development» та отримати завдання для участі у конкурсі на зарахування.

Умови:викладають провідні спеціалісти компанії. Більш детальна інформація стосовно періодичності та тривалості курсу буде відома пізніше.

Деталі: 0512 58 54 83, mykolayiv@geeksforless.com.

Light IT

Напрям:курси Front-end, Python.
Місто:Запоріжжя.
Дедлайн подачі заявок: 9 березня.

Вимоги до кандидатів:курси розраховані на програмістів-початківців, випускників вишів та студентів останніх курсів, які вже знайомі з Front-end чи Python відповідно.

Як потрапити:подати заявку на сайті — Front-end, Python.

Умови:викладачі — Senior Developers компанії. Заняття почнуться у квітні і будуть проходити 2 рази на тиждень — у вечірній час (з 17:00) в будні дні 2 рази на тиждень протягом 3-хмісяців. Найкращі випускники курсів, за підсумками навчання, будуть запрошені на роботу в компанії.

Деталі:на сайтіабо пишіть на пошту hr@light-it.net.

Mirantis

Напрям:курс підготовки DevOps-інженерів по ОС Linux та хмарних технологіях.
Місто:Харків.
Дедлайн подачі заявок: 1 березня.

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

• англійська — Intermediate і вище;
• базові навички адміністрування Linux;
• базові знання мережевих технологій;
• знання основ Git та наявність акаунту на GitHub. Якщо акаунту немає, його необхідно створити;
• перевагою будуть базові навички програмування на Python.

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

Умови:програма навчання складається з 3 етапів: Linux OS management and administration, Cloud technologies basics, Cloud automation basics. Після кожного етапу учасники виконують практичні завдання. Якщо завдання не були виконані вчасно, кандидата відраховують з курсу. Кількість занять — 18, періодичність — 2 рази на тиждень по 2 години о 19:00. Початок — 5 березня. Найкращим кандидатам запропонують продовжити навчання в інтернатурі. По завершенні інтернатури можна приєднатися до команди на позиції Junior DevOps Engineer.

Деталі:на сайті.

NIX Solutions Ltd

Напрям:курси.
Місто:Харків.

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

• практика .NET;
• практика Android;
• практика iOS;
• навчання Java;
• Business Analysis Education;
• інтенсив JavaScript;
• практика PHP/CMS;
• навчання Linux Administration/DevOps;
• дистаційне навчання Salesforce.

Як потрапити:подати резюме на сайті, пройти тестування в офісі або ВНЗ, пройти співбесіду.

Умови:практики тривають 3 тижні в один з літніх місяців у офісі компанії в будні з 10:00 до 19:00. Навчання триває від 2 до 5 місяців залежно від напряму у форматі лекцій 2-3рази на тиждень протягом 2-4 годин. Business Analysis Education та JavaScript — інтенсиви, які проходять протягом 2 місяців повний робочий день з понеділка по п’ятницю.

RubyGarage

Напрям:курси Ruby / Ruby on Rails.
Місто:Дніпро.

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

• базові знання HTML, CSS, JavaScript та мінімальний досвід роботи з цими технологіями;
• бажано знання базових принципів роботи баз даних і мови SQL;
• знайомство з однією з серверних мов програмування (PHP, Java, С ++ / С #, Python...);
• технічна англійська на рівні читання документації.

Як потрапити:заповнити заявку на сайті, виконати тестове завдання (термін виконання тестового завдання 1-2 місяці),пройти співбесіду.

Умови:тривалість курсу становить 4-6 місяців.Навчання проходить два рази на тиждень у вечірній час. По закінченні студенти складають випускний іспит. Після успішного проходження курсу — можливе працевлаштування у компанії.

Деталі:на сайтіабо пишіть на пошту railscourses@rubygarage.org.

SoftServe

Тип:курси.
Місто:Львів, Івано-Франківськ, Київ, Рівне, Харків, Дніпро, Чернівці.

Напрям та дедлайн подачі заявок:

• Java: Львів — 9 березня, Івано-Франківськ — 11 квітня;
• DevOps: Київ — 12 березня;
• Quality Control: Київ — 19 березня, Рівне — 4 квітня;
• C++: Львів — 30 березня;
• .NET: Львів — 4 квітня;
• Golang: Харків — 18 квітня, Дніпро — 19 квітня;
• Test Automation: Рівне — 16 травня, Харків — 14 червня;
• Web-UI: Чернівці — 24 квітня;
• Web UI/Node.js Development: Львів — 9 квітня, Рівне — 14 травня, Харків — 18 травня;
• Web UI/PHP Development: Львів — 23 квітня.

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

• рівень англійської Intermediate+;
• студенти 3-5курсів і випускники;
• базова технічна освіта;
• детальніше — на сайті.

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

Умови:тривалість курсів — 2-4 місяці.

AMC Bridge

Напрям:стажування C++, C#, web services, Front-end.
Місто:Дніпро.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:студенти 3-6-го курсів технічних спеціальностей вищих навчальних закладів. Термін стажування повинен збігатися з навчальним планом ВНЗ, у якому навчається студент.

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

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

Деталі:на сайті.

CHI Software

Напрям:стажування Ruby on Rails, DevOps.
Місто:Харків.

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

• знання хоча б однієї об’єктно-орієнтованої мови програмування та вміння вирішувати найпростіші алгоритмічні завдання з її допомогою;
• основи релятивних БД, SQL;
• добре знання HTTP;
• знання UNIX-like ОС (Ubuntu та ін.);
• базове знання HTML/ CSS/ JS;
• знання англійської мови на рівні intermediate або вище;
• самомотивація.

DevOps

• вища або незакінчена вища профільна освіта;
• знання основ Linux;
• розуміння моделі OSI, стеку TCP/IP та DNS;
• знання принципів веб-серверів;
• знання англійської мови на рівні Intermediate.

Буде плюсом:

• практичний досвід системного адміністрування Linux/Unix;
• розуміння релятивних баз даних;
• досвід системного адміністрування Windows;
• досвід написання прикладних скриптів для автоматизації (Bash, Python etc.);
• досвід роботи з хмарними середовищами (AWS, GC, MS Azure);
• досвід з CI/CD tools;
• досвід з Docker.

Як потрапити:відправити CV на пошту careers@chisw.com, виконати тестове завдання, пройти співбесіду в офісі з технічним фахівцем.

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

Деталі:пишіть на пошту careers@chisw.com.

Clockwise Software

Напрям:стажування JavaScript.
Місто:Дніпро.

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

• вища технічна освіта;
• знання алгоритмів та структур данних;
• знання англійської на рівні Intermediate+.

Як потрапити:відправити резюме на пошту hr@clockwisesoftware.com, виконати тестове завдання та пройти співбесіду.

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

HYS Enterprise

Напрям:стажування QA manual, C#.
Місто:Одеса.
Дедлайн подачі заявок:немає.

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

• поглиблене знання OOP;
• поглиблене знання HTML / CSS (Twitter Bootstrap), JavaScript (jQuery);
• знання і досвід з C#, Microsoft.NET (ASP.NET, MVC, ADO.NET, WCF);
• знання веб-сервісів, XML, UML, VSS;
• розуміння Back-end and Front-end розробки;
• рівень англійської Upper-Intermediate є обов’язковим.

QA manual:

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

Як потрапити:надіслати резюме с поміткою «Стажировка с DOU» на hr@hys-enterprise.com, пройти співбесіду (HR, технічну та фінальну англіською мовою).

Умови:стажування триває 2-3 місяці.За умови його успішного завершення кандидат отримує статус джуніора в компанії.

Деталі:пишіть на пошту hr@hys-enterprise.com.

Luxoft

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

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

• базові знання ООП, C, C++, C++11, паттернів проектування (GoF), паттернів GRASP;
• англійська мова — Pre-Intermediate.

Як потрапити:заповнити анкету для стажування в Одесі, для стажування в Києвіта виконати завдання.

Умови:програма триває 3 місяці, протягом яких учасники проходять інтенсивне навчання проектуванню і програмуванню на C ++. Паралельно з цим є можливість пройти співбесіди в проекти Automotive, які розробляють ПЗ для провідних світових автовиробників. Під час навчання учасникам виплачується стипендія.

Деталі:стажування в Одесі, стажування в Києві

Materialise

Напрям:інтернатура C++, research, algo.
Місто:Київ.
Дедлайн подачі заявок:немає.

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

• зацікавленність в research та алгоритмах;
• навички програмування С ++;
• можливість працювати 4-6 годин.

Як потрапити:пройти тестування в онлайн-режимі та написати коротку інформацію про себе.

Умови:Стажування триває 3 місяці, щоквартально. Графік — гнучкий (4-6робочих годин на день, можна працювати віддалено). Ви маєте можливість взяти участь у дослідницьких проектах у трьох різних сферах діяльності компанії: інженерія, програмне забезпечення та 3D друк (Additive виробництво). Стажер працюватиме під керівництвом спеціалістів Materialise.
Деталі:на сайті.

Sigma Software University

Тип:стажування.

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

• JavaScript: Харків — 28 березня;
• .NET: Харків — 12 березня;
• Embedded: Львів — 25 березня;
• DevOps: Харків — 25 березня.

Як потрапити:заповнити реєстраційну форму на сайті (у відповідному розділі) та додати резюме.

Умови:тривалість стажування від 3 до 6 місяців залежно від напряму; повний робочий день.

VRG Soft

Напрям:стажування Android.
Місто:Дніпро.
Дедлайн подачі заявок:початок березня.

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

• базові знання Java;
• розуміння принципів ООП;
• базове розуміння REST і роботи з БД.

Як потрапити:надіслати резюме на hellovrgsoft@gmail.com.

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

Деталі:пишіть на пошту hellovrgsoft@gmail.com.

White Label Agency

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

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

• студенти останнього курсу та випускники;
• базове розуміння CMS WordPress, PHP;
• знання HTML & CSS;
• досвід програмування.

Як потрапити:заповнити форму на сайтіабо відправити резюме на hr@thewhitelabelagency.com, пройти співбесіду та виконати тестове завдання.

Умови:викладачі інтернатури — Tech leads та Senior Developers компанії. Тривалість програми — від 1 до 2 місяців залежно від рівня кандидата. 5 днів на тиждень, 8 годин на день. Стажування оплачується щомісячно. Програма включає практичні завдання, розробку тесових проектів під керівництвом кураторів та лекції. За умови успішного проходження курсу є можливість працевлаштуватися на позицію Junior.

Деталі:на сайті.

3Shape Ukraine

Напрям:робота С#.
Місто:Київ.

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

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

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

Умови:повний/неповний робочий день.

Деталі:надсилайте запитання на recruit-ua@3shape.com.

Clockwise Software

Напрям:робота Sales.
Місто:Дніпро.

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

• освіта вища, незакінчена вища;
• рівень англійської upper-intermediate +;
• вміння самостійно знаходити необхідну інформацію, в тому числі контактні дані;
• аналіз данних;
• базові знання пошукових ресурсів;
• досвід роботи з CRM-системами.

Як потрапити:відправити резюме на пошту hr@clockwisesoftware.com, виконати тестове завдання та пройти співбесіду.

Умови:можливий варіант як повної, так і часткової зайнятості.

CodeIT

Напрям:робота iOS.
Місто:Харків.
Дедлайн подачі заявок:березень.

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

• розуміння принципів ООП, шаблонів проектування;
• навички програмування C/C ++ або Objective-C/Swift;
• вища профільна освіта;
• рівень англійської — Intermediate.

Як потрапити:відправити резюме на пошту jobs@codeit.us, виконати тестове завдання, пройти співбесіду.

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

Деталі:пишіть на tatyana.penkina@codeit.com.ua.

Expercast

Напрям:робота Javascript, Ruby, QA.
Формат: remote.

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

• рівень англійської — не нижче, ніж Upper-intermediate;
• можливість працювати віддалено;
• кмітливість, здатність швидко вчитись, бажання брати на себе виклики ;)
• для JavaScript та Ruby розробників — попередній досвід (можна не комерційний) із технологіями буде плюсом;
• для QA Engineers — буде плюсом знання JavaScript, SQL, HTML/CSS.

Як потрапити:надіслати резюме на jobs@expercast.comта кілька слів англійською мовою про те, саме зацікавило в посаді. Обов’язково вказуйте в темі листа посаду, на яку подаєтесь: [Junior JavaScript], [Junior Ruby], [Junior QA].

Умови:працевлаштування після проходження всіх етапів процесу відбору.

Деталі:на сайтіабо пишіть на пошту jobs@expercast.com.

Intetics

Напрям:робота, функціональне програмування.
Місто:Київ, Харків, Львів.

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

• вміти виконувати алгоритмічні задачі;
• знати хоча б одну мову програмування;
• любити алгоритми (або нестандартні задачі);
• англійська рівня Intermediate та вище.

Як потрапити:

• надішліть резюме на fp@intetics.com, в листі обов’язково вкажіть, яку мову програмування ви знаєте;
• отримайте тестове завдання і виконайте його;
• поспілкуйтеся з рекрутером;
• виконайте друге тестове завдання в офісі.

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

Smart Business

Напрям:робота .NET.
Напрям:Київ.
Дедлайн подачі заявок: 19 березня.

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

• вища технічна освіта (студент 3-6курсу або випускник);
• навички використання C#, .NET;
• досвід роботи з базами даних.

Як потрапити:надіслати резюме на masha@smart-it.com, пройти співбесіду до 16.03.2018.

Умови:кандидати проходять курс лекцій та практичних занять, які тривають 2-3тижні 4-5разів на тиждень о 18:30 (по 2 години). Кандидатам, які успішно завершать навчання, компанія запропонує працевлаштування.

Деталі:на сайтіабо пишіть на пошту masha@smart-it.com.

Vakoms

Напрям:робота iOS.
Місто:Львів.

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

• знання Objective-C та/або Swift;
• знання OOP/OOD;
• розуміння дизайн-патернів;
• здатність швидко вчитися;
• англійська — від Intermediate.

Як потрапити:подати резюме на сайті.

Щомісяця редакція публікує у Стрічціпонад 40 статей, які збирають близько 1 мільйона переглядів. Нам цікаво дізнатися, що вам подобається читачи найбільше, що хотілося б додати або виправити. Тому просимо приділити 5-10хвилин на заповнення анкети.

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

Пряме посилання на анкету: goo.gl/forms/MFH2f0hHIf5abdwz2

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

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

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

Идея

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

Когда год делаешь клиенту ежедневный отчет в Word, который составляет более 500 страниц и объем только растет, начинаешь понимать, что прочитать этот документ нереально. Сейчас это кажется смешным, но раньше весь рынок мониторинга СМИ в Украине именно так и работал: собрал данные — вывел их в Word — сделал оглавление — отправил клиенту. Агентство по мониторингу часто и выбирали по принципу: у кого больше новостей в отчете, тот и лучше. Некоторые компании, кстати, до сих пор так делают.

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

Все свелось к таким проблемам:

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

Реализация

Сервис Looqme работает в несколько этапов:

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

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

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

В качестве поискового движка сначала мы выбрали Elasticsearch, но для наших целей там не хватало ряда возможностей по поисковым запросам, поэтому в итоге остановились на Solr’e. Он хоть и посложнее в установке, но с бОльшими возможностями для мудреных запросов, например, искать по тексту, где 3 куска слова находятся друг от друга на расстоянии в n символов.

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

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

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

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

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

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

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

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

Американская компания Amazon покупает стартап Ring, разработчика умных дверных звонков, с R&D-центром в Украине.

Сумма сделки официально не разглашается, но по данным Reuters она превышает $1 млрд.

Amazon buys startup Ring in $1 billion deal to run your home security t.co/Ta98V4FauC

— Reuters Tech News (@ReutersTech) February 28, 2018

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

В украинском офисе Ring работает 445 специалистов, из них 390 — технические. R&D-центр в Киеве Ring открылав конце 2016 года. Технические специалисты киевского офиса занимаются разработкой программного обеспечения в области Machine Learning, Computer Vision, Data Mining и других сфер искусственного интеллекта для использования в продуктах Ring.

За вакансиями в компании можно следить здесь.

Мы ожидаем также официальный комментарий украинского представительства Ring.

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

Год назад в DOU Hobby уже поднималась тема автоспорта: львовянин Дмитрий Захаров рассказывало ралли и участии в соревнованиях. В этот раз мы пообщались с Юлией Гриценко — она работает Senior Group Manager в сумском офисе компании Netcracker и увлекается автомобильными соревнованиями и спортивными машинами.

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

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

Моя история в автоспорте и вообще автомобильная жизнь началась очень необычно. Все началось со звонка моего директора со словами: «Ну что, ты приготовила лыжи? Ты завтра летишь в Денвер!». Это была моя первая командировка в США, и я без водительских прав на то время испытала дискомфорт. Чтобы куда-то поехать, будь то офис, магазин или куда-то на викенд, приходилось искать кого-то из коллег с машиной и агитировать свозить...

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

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

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

— Как выбирала свой первый автомобиль?

Сначала я ездила на прокатных машинах, но вернувшись с очередной командировки, загорелась-таки желанием приобрести личное авто. Это был 2014 год. Еще во время обучения я насмотрелась разных контраварийных трюков и наслушалась восхищенных рассказов своего инструктора, что самый правильный привод — полный, а самая лучшая машина — Subaru impreza WRX STI. В итоге и сама начала восхищенными глазами смотреть на эти спортивные симпотяжки.

В своем выборе остановилась на синей красавице Subaru impreza WRX 2006 года. Это, конечно, не STI, но красивая бодрая машинка. Для начинающего водителя это определенный вызов — в плане того, чтобы ее понять и приручить.

И я почти 2 года ждала зимы и снега, чтобы подрифтить по снегу, но нужной погоды не было... Из-за этого чувствовала какое-то неудовлетворение: чего-то не хватало. В то время мне случайно попался интересный экземпляр Mitsubishi lancer Evolution 9-гопоколения, заряженный и готовый к спортивным нагрузкам. Машина меня очень сильно впечатлила, и так из субароводов я перешла в ряды EVO-клуба.

Пару недель не могла поверить в то, что сделала :)

— Первое знакомство с автоспортом произошло на Mitsubishi?

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

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

— Чем тебя привлекли соревнования?

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

Начали появляться первые достижения и победы. Помимо непередаваемого опыта и эмоций, за эти 2-3года я стала смелее, быстрее и более неугомонной.

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

Юлия выиграла Национальную серию ралли на серийных автомобилях

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

FAU, дисциплины, соревнования для аматоров

— Расскажи, о чем нужно знать новичку, который хочет «войти» в автоспорт?

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

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

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

Существует порядка 18 дисциплин автоспорта: ралли, ралли на серийных автомобилях, мини-ралли, кросс-кантри ралли, тайм аттак, дрэг-рейсинг, дрифтинг, слалом, картинг, джип-спринт, триал, трофи-рейды, трековые гонки, кросс, горные гонки и др.

В прошлом году прошло 144 соревнования, в которых приняло участие более 3500 спортсменов. Бывают соревнования разных статусов: Чемпионат Украины, Кубок Украины, национальное, клубное соревнование.

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

— Тогда поговорим об уровне национальных и клубных соревнований. Что для этого нужно?

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

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

В большинстве дисциплин наличие шлема — must. Это должны быть автомобильные или мотоциклетные шлемы с сертификацией ЕС (знак «Е» в круге), также разрешен стандарт British Standart Intuition BS 6685 тип А. На некоторых соревнованиях шлем можно арендовать, но принято иметь свой. Лучше с подшлемником. Цены на шлем стартуют от $100. Приобрести можно в магазинах, занимающихся экипировкой или тюнингом: например, ATOMIC Shop (Киев, крупнейшний тюнинговый интернет-магазин), A-Tune (Киев, есть шоурум на «Чайке»), Topline24 (Черкассы).

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

— Как обычно проходят соревнования?

Соревнование всегда состоит из таких этапов:

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

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

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

Стартовые взносы на участие в национальных соревнованиях — 700-2500 грн.Все зависит от дисциплины и соревнования.

Ралли на серийных автомобилях

— Ты получила диплом победителя ралли на серийных автомобилях. В чем особенности этой дисциплины?

В рамках ралли на серийных автопроводятся как скоростные соревнования (трофей ФАУ) по снегу, асфальту, грунту, так и очень доступный для всех формат ралли 3-йкатегории, для которого подходит абсолютно любая машина, и на исход гонки мощность машины не влияет.

Экипаж в любом ралли всегда состоит из первого и второго пилота (штурмана).

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

Как правило, они длятся 2 дня. Участникам предлагается 6-10скоростных спецучастков суммарной протяженностью 15-80боевых км.

В этой серии есть несколько классов — в зависимости от привода, объема двигателя и доработок:

• 2WD 1600 (монопривод, двигатель до 1,6 л);
• 2 WD (монопривод, двигатель до 2 л);
• 2WD OPEN (монопривод, двигатель до 8 л);
• 4 WD (полный привод, двигатель до 4,5 л);
• SP 2WD (монопривод, каркас);
• SC OPEN (анлим).

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

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

В этой дисциплине ездят разные авто: ВАЗы, ЗАЗы, BMW, Honda Civiс, Mitsubishi EVO, Subaru Impreza GT, STI, Audi TT, Porsche и другие — как специально подготовленные авто с каркасами безопасности, так и гражданские everyday car.

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

Скоростное ралли на серийных автомобилях представлено одной из самых популярных серий — Трофей ФАУ. В этом году организаторами заявлено аж 10 соревнований, которые состоятся в Днепре (снег, грунт), Киеве (грунт), Черкассах (асфальт), Полтаве (асфальт), Харькове (грунт). Посмотреть расписание можно по календарю FAU, фильтруя по названию дисциплины.

Параллельно с Трофеем ФАУ, в рамках 4-хчеркасских этапов объявлен кубок «AERORING CUP». Кроме классов Трофея в этом зачете добавлен класс ЗАЗ-968 с бесплатным участием для этих участников. Для соревнований в Черкассах организаторы задействуют черкасский аэропорт и прокладывают очень интересные конфигурации. Однако важно знать, что асфальт там довольно агрессивный и может быть повышенный износ резины.

— А как проходят ралли 3-йкатегории?

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

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

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

Этот вид — как некое приключение-квест — подходит людям с аналитическим складом ума, тем, кто любит RPG и интересно проводить время.

Дорожная книга и фигуры слалома в ралли 3-йкатегории

Каждый год 8 марта с 1999 года команда КМАМК (Киевскией городской автомотоклуб) проводит для девушек «Большое женское ралли». Очень рекомендую автолюбительницам попробовать такой необычный формат празднования. Онлайн-регистрацияв самом разгаре. В прошлом году мы участвовали и записали онборднашего женского IT-шного экипажа.

Также в этом году харьковчанами из УАР заявлена серия Autograd Rallye. Соревнования запланированына 19 мая, 4 августа и 22 сентября. Но пока неизвестно, состоится ли серия — ребята ищут спонсоров. Слабая вовлеченность спонсоров — это боль всего нашего автоспорта. На проведение одного соревнования нужна пара тысяч долларов, а стартовые участников зачастую не покрывают и трети затрат организаторов.

Ралли 3-йкатегории: прохождение спецучастка типа Спринт

Тайм аттак и слалом

— Какие еще дисциплины, помимо ралли на серийных авто, могут быть интересны новичкам?

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

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

В этой дисциплине пилоту важно понимать и выстраивать правильные траектории входа в повороты, рассчитывать момент и силу нажатия газа и тормоза. Машина также влияет в борьбе за высокий спортивный результат: нужна цепкая резина (Federal RSR-RR, Hankook rs3), хорошие тормоза, настроенная регулируемая подвеска, рекомендуется доработанная система охлаждения. Еще касательно резины: топовая Extreme VR2 — читерская резина-наварка, но в ралли с ней не пустят и на каждый день не годится.

Попробовать для себя тайм аттак можно на открытых трек-днях на «Чайке» в Киеве или «Лтаве» в Полтаве. Примеры онбордов — из «Чайки», из «Лтавы».

Если говорить о соревнованиях, есть две национальные серии по тайм-аттак: RTR Time Attack (Киев и Одесса) и Ltava Attack Series (Полтава). Организаторы в рамках этапов могут менять вектор направления движения по треку, добавлять срезки и ретардеры (ограничители скорости, как правило, связка шин).

RTR-серия — более скоростная и затяжная. Ltava Time Attack — более техничная, там меньше скорости, больше рулежки. «Лтава» хорошо подходит новичкам в ввиду своей безопасности и средней-небольшой скорости. Видеообзоры — RTR Time Attack (Киев и Одесса) и Ltava Attack Series.

— А что такое слалом?

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

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

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

Пример фигуры слалома национальной серии «Лихолет»

Насколько мне известно, скоро планируется национальная серия по слалому «Лихолет» в Харькове — 8 марта, а также в июне и сентябре. Пока в календаре FAUпусто, но вот-вот должна появиться информация.

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

Выбор автомобиля и обучение

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

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

Но если говорить про более-менее универсальное и спортивное авто, изначально спроектированное под высокие спортивные нагрузки, с интересным нравом, которое приносит эмоцию, то это Mitsubishi EVO или Subaru STI.

Меня часто спрашивают: EVO или STI? Мой ответ — EVO :) На любых соревнованиях можно увидеть, что они преобладают и доминируют над Subaru, доставляют меньше неприятностей, более надежны. У EVO хорошо развитое комьюнити (Evoclub) и есть качественные клубные СТО с профи-мастерами, которые знают их от и до, могут построить тюнинг-проект любой сложности.

Это фрагмент видео с EVO-парада в Одессе.

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

— А где лучше проходить обучение?

Азы спортивного вождения можно получить, пройдя курсы в школах водительского мастерства. В Харькове есть M-Sport (они еще организовывают интересный спорт-тур на автодром Грузии), в Киеве — школа автодрома «Чайка».

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

Присоединяйтесь к интересующему вас комьюнити, и вам посоветуют контакты. Вот несколько групп и страниц в Facebook: Форум ФАУ, Автомобильный клуб «Харьков», 2010.DOSS, Автомобильный Клуб «Черкассы», Ltava Attack Series, Большое Женское Ралли.

— Что еще можешь посоветовать начинающим?

Не стоит принимать участие в нелегальных гонках. FAU и министерство молодежи и спорта Украины их не поддерживают. Участвующие в таких покатушках пилоты могут лишиться лицензий FAU и попасть в неприятные истории. Я однажды видела такое зимнее соревнование. Вроде и цель была благородная — собирали благотворительные средства, но в потенциальных местах вылета с трассы стояли зрители с детьми, а ведь в любой момент могло произойти происшествие. К тому же, один допущенный участник на «Жигулях» был на летней лысой резине (техкома не было) и влетел на бруствер. Его вытаскивал другой участник, которому потом этот «Жигуль» протаранил бок и скрылся с места событий. Позже оказалось, что даже ОСАГО у него нет. Не стоит с таким связываться.

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

— И наконец: чем именно тебе так нравится автоспорт?

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

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

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

Валідація? Користувацьке тестування? — Нєт, нє слишал. Яждизайнер! Ятаквіжу. Клієнт валідує, а хто ще? Головне, щоб клієнтові сподобалось! Клієнт же платить врешті-решт.

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

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

Ліричний відступ.

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

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

Я вже писала про це, але дозволю собі повторитися:

«Balsamiq, Sketch й навіть Photoshop все стерплять, але користувачі не пробачають непродуманості».

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

Навіть якщо вам не пощастило і ваш користувач — унікум, який заробляє $500 за годину, то ця відмазка вас не порятує. Золоте правило людино-центрованого дизайну (HCD) — будь-яке тестування краще, ніж ніякого. Навіть якщо відкинути той цілий HCD, скажу вам як колишній тестувальник (сертифікований, до речі): там усе так само. Якщо нема часу на Regression Testing — робимо Smoke testing. Якщо не було часу зробити людські сценарії й прописати гарно тест-кейси — робимо Ad Hoc testing. Будь-яке тестування краще за його відсутність. Це підтвердить будь-який тестувальник. Навіть коли до релізу 3 години, а менеджер кричить: «Не тестуй, бо нема часу фіксати!». А якщо там блокер...?! Що тоді? А що, якщо блокер знайде клієнт?

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

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

Коридорне тестування

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

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

Наприклад, працюючи над інтерфейсом бронювання кімнат в офісі, ви можете спитати: «Тобі треба зарезервувати кімнату № 213 для себе і ще п’ятьох колег. Сьогодні о 15:30 на 1 годину. Що будеш робити?».

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

Можна ще простіше: «Як думаєш, що буде, якщо ти натиснеш на цю іконку/кнопку/табку?». Якщо ви чуєте щось схоже на «Ем... Ну... Я не знаю... може... ну...», то я вас вітаю. Тест був успішний. Ви знайшли баг! Ура! Візьміть собі печенько. Ви його заслужили.

Скільки часу ви затратили? Скільки грошей це вартувало з бюджету вашого клієнта? Якщо ви тестували не вилизаний інтерактивний pixel perfect high fidelity протопип, то найбільше, що ви могли затратити — 5 хвилин. Хоча тут я трохи спростила. Щоб підтвердити баг, сценарій треба прокатати разів зо п’ять. Все як у звичайному тестування — баг має відтворюватися. Баг, який не відтворюється, не є багом. Те, що один користувач не дав собі раду з тест-кейсом (з вашим дизайном), — ще не причина бити в дзвони.

По суті, коридорне тестування є відповідником ad-hoc testing у світі Quality Assurance.

Переваги:

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

Недоліки:

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

5-тисекундне тестування

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

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

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

Трохи детальніше про фази готовності

Пам’ятаймо, швидше — краще. Fail fast, як каже Agile. Будь-яка фаза готовності означає: скетчі, чорно-білі статичні вайфрейми, зроблені в дерев’яному Balsamiq, чорно-білі чорнові прототипи та high fidelity fully clickable prototypes looking so good you’ll want to lick them.

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

Я найчастіше роблю швидкі вайфрейми в Balsamiq, компоную сякий-такий протопип в InVision і того досить. Не треба сітки, не треба все вирівнювати по півгодини, не треба бавитися зі шрифтами та кольорами. Бігом тестувати. Бо однак доведеться переробляти...

Чому не варто створювати для тестування «high-fidelity fully clickable prototypes looking so good you’ll want to lick them»

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

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

Про організацію, настрій і процес сесії тестування

Отож, алгоритм дій:

1. У вас вже є готовий скетч/вайфрейм/прототип.

2. Ви зупинились на «коридорному тестуванні».

3. Берете прототип (паперовий, веб чи мобайл).

4. Готуєте сценарій (завдання), яке має виконати користувач. Бажано прописане на чистому аркуші паперу. Можна й усно, але якщо зафіксувати письмово, то буде гарантія, що всі 5-7користувачів почують завдання однаковісінько. Ви ж теж людина, можете затинатися, помилятися, не так озвучити завдання, одному користувачу дати більше контексту, ніж іншому.

5. Ловите людину на коридорі/кухні/деінде:

— Дизайнер:Привіт-привіт. А маєш пару хвилиночок?

— Користувач:Так, кажи. Що там?

— Д.:Я зараз працюю над дизайном продукту, суть якого, згрубша, зводиться до [бронювання кімнат в офісі]. Ми зараз на фазі тестування. Хочу попросити тебе побути нашим користувачем і допомогти протестувати рішення.

— К.:Давай, цікаво. Тільки якщо не дуже довго.

— Д.:Ок. Це прототип. Це не готовий продукт, а лише картинки, склеєні докупи. Тому не все працює і не все клікається. Важливо, щоб ти розумів: ми тестуємо не тебе, а наш дизайн. Ти не можеш зробити щось неправильно.Якщо в тебе щось не виходить, то це означає, що ми десь припустилися помилки й ти допоміг нам її знайти. І ще! Я попрошу тебе думати «вголос». Якщо ти чогось не розумієш чи маєш питання — кажи все вголос. Це для нас дуже важливо. Ну що? Почнемо? Тобі треба зарезервувати кімнату № 213 для себе і ще п’ятьох колег. Сьогодні о 15:30 на 1 годину. Що будеш робити?

Увага! Останній абзац дуже важливий. Ви маєте переконатися, що донесли до користувача думку, що ви тестуєте не його. Інакше людина може скуто себе почувати та поводитися зі страхом помилитися. Це не найліпшим чином впливає на сесію тестування.

А далі ви — мавпочка, яка все бачить, все чує, але нічого нікому не підказує. Свербить язик підказати? — Вкусіть себе за нього. Вдихніть глибоко. Робіть будь-що, аби змовчати.

Відповідайте питаннями на питання користувача.

— К.: А що буде якщо я?.. А що це?

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

— Д.: А як ти думаєш? А чому ти так думаєш?

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

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

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

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

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

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

На скількох користувачах варто тестувати дизайн (один тест-кейс)

На п’ятьох. Якщо результати спірні (50 на 50) — додайте ще 2-3 тести.Цього достатньо. Чому? Бо за допомогою 5-7тестів ви знайдете 80% багів. Це будуть найчастіші та найкритичніші баги. Чи можна далі продовжувати і зробити 20-30 тестів?Можна, але для чого? Ми ж хочемо швидко, дешево й достатньо добре, а не довго, дорого й ідеально.

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

Помилки, яких варто уникати:

• Тестувати на дизайнерах. Ви отримаєте дизайн рев’ю, але не результати користувацького тестування.
• Тестувати прототип мобільного Android-рішення на iOS і навпаки.
• Тестувати прототип мобільного iOS-рішення на людині, яка користується щодень Android і навпаки.
• Тестувати веб-прототип для Mac на користувачі, який щодень користується Windows і навпаки.
• Тестувати не в контексті. Якщо це веб, то тестуємо сидячи за комп’ютером. Але якщо це мобайл, то стоячи. А якщо це планшет, який буде висіти на стіні, то тестуємо на планшеті, який висить на стіні. Якщо апка для водія таксі, який їздить по бруківці, то тестуємо в машині, під час руху по бруківці.

Що почитати на тему

Steve Krug «Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems». Прекрасна книжка, яка читається за час одного авіаперельоту (не Львів-Київ).

Що ще? — Нільсона.

Післямова

У цій статті я свідомо не розказую про інші види серйознішого тестування, яке передбачає рекрутинг автентичних користувачів під персони (BTW, You are not responsible for personas you created :-)), купівлю техніки і програмного забезпечення для eye-tracking, запис відео, аудіо і курсор-трекінг зі всіх можливих ракурсів і кутів і багато іншого. Чому? Тому що в такому випадку стаття не називалася б «Про користувацьке тестування, доступне кожному». І у вас була би купа відмазок, чому не тестувати, а я хочу забрати у вас ці відмазки :-)

Успіхів! У вас все вийде.

In God I trust, the rest I test :-)

І пам’ятайте: UX without users is not UX :-)

[Об авторе: Николай Лотоцкий — более 15 лет занимается разработкой программного обеспечения. Знаком со всеми этапами работы на проекте и развил карьеру от должности QA Engineer до Technology Expert. Несколько лет был JavaScript Software Architect и принимал активное участие в разработке сложных масштабируемых приложений. Кроме того, есть опыт работы с PHP, .NET, Python. Более трех лет проводит различные курсы и тренинги]

Мы его, можно сказать, на помойке нашли, отмыли, очистили — а он нам фигвамы рисует!
Э. Успенский «Зима в Простоквашино»

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

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

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

Радикальный метод

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

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

Это, конечно, из категории «вредных советов». А как же на самом деле выйти из ситуации? Как избежать текучки и расставаний с ценными кадрами?

Обучайте специалистов новым технологиям

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

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

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

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

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

Ведите переговоры

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

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

Расставайтесь с людьми красиво

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

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

Найдите замену незаменимым

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

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

Развивайте внутренний институт people partners

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

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

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

Подведем итоги

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

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

Images via Pierre Kleinhouse, Nezzon Aerts.

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

Никита Кравцов, Senior Android-разработчик в Depositphotos

9 лет опыта

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

Не пренебрегайте возможностью изучать внутренний код фреймворка.К примеру, в процессе разработки собственного класса FlowLayout разработчик первоначально хотел реализовать данную задачу на RelativeLayout. После изучения исходников FrameLayout/LinearLayout/RelativeLayout разработчик реализовал задачу на классе ViewGroup.

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

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

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

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

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

Разделяй и властвуй. Большинство начинающих разработчиков стараются держать всю логику и код в Activity или Fragment, превращая данные классы в огромные объекты, которые тяжело читать и поддерживать. Если вы хотите писать более эффективный код, вам необходимо понимать, что такое архитектурные паттерны (MVP, MVVM) и дизайн-паттерны.

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

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

• Java. Для начала вам необходимо досконально изучить язык и все его тонкости. Учитывая направленность этой статьи, я не буду углубляться в подробности, но как минимум, помимо базовых знаний, вам необходимо понимать и применять «Software Design Patterns». В процессе своей работы я пользуюсь ресурсами Javatpoint, Sourcemakingи Tutorialspoint.
• Google’s official Android Developer site. Отправная точка для любого Android-разработчика. Является наиболее полным пособием при разработке Android-приложений. Это один из лучших и самых актуальных ресурсов.
• Official Android Developers Youtube channel. Официальный видеоресурс с новостями, лучшими практиками и руководствами, который постоянно пополняется новыми материалами. Достаточно часто выход новой feature (к примеру, Architecture components) сопровождается выходом видео. Одно из преимуществ ресурса — возможность повышения знаний во время проезда в городском транспорте.
• The Busy Coder’s Guide to Android Development. Достаточно обширный ресурс-шпаргалка для разработчиков. Оформлен в виде книги и обладает большим количеством примеров по разработке Android-приложений. Примеры из книги вы сможете найти здесь.
• Stack Overflow. Один из самых популярных ресурсов для разработчиков многих направлений. Stack Overflow не содержит документации для обучения или целенаправленных инструкций, но является наиболее популярным местом, где разработчик сможет найти решение специфических проблем, возникающих при разработке программного обеспечения.
• AndroidWeekly. Еженедельная рассылка новостей. Рассылка представляет собой набор статей, инструкций, примеров кода, подкастов, презентаций и видео на Android-тематику.
• Google Material Guidelines. Официальный ресурс с рекомендациями к дизайну пользовательских интерфейсов.

Ростислав Антонов, Lead Software Engineer в EPAM Ukraine

15 лет опыта в IT, из них 8 лет на Android

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

Следите за новинками индустрии. Android — это динамично развивающаяся операционная система. Ежегодно Google проводит конференцию Google I/O, где презентуются новые вещи, которые будут включены в платформу. Кроме этого, на мероприятии есть возможность для общения, дискуссий и обмена опытом. Ближайшая конференция состоится 8-10мая 2018 года. Следить за событиями можно на Youtube-канале Google Developers.

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

Регулярно проходите онлайн-курсы. Очень рекомендую ресурс Udacity. Это бесплатная платформа дистанционного обучения. Она возникла в результате расширения программы по информатике Стэнфордского университета в 2012 году. Сможете абсолютно бесплатно пройти курсы и тренинги, которые позволяют получить теоретические знания и набить руку на практике, выполняя задачи в онлайне за определенное время. Можно сделать несколько разных приложений, которые помогут развить определенные скилы в Android-разработке и попробовать себя в этом деле.

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

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

Александр Зубченко, Android Lead в Waverley

8 лет опыта разработки под Android

Раз уж ты здесь и читаешь советы Senior Android-разработчиков, то ты таки решил погрузиться в мир боли и страдания виртуальных Java-машин. На самом деле нет, но иногда тебе будет так казаться, когда твой код замечательно работает на эталонном Nexus, а на топовом Samsung Galaxy у заказчика лезут баги. Решить эту проблему поможет сила убеждения. Да-да, нужно убедить заказчика купить нормальный Nexus-смартфон, и баги исчезнут! Звучит довольно просто, вот только для этого тебе нужно хорошо знать английский язык. Да уж, но без него никуда.

Прошли те времена, когда РМ, как любящая мама, ограждал(а) разработчиков от вредных и приставучих заказчиков. Увы, система так больше не работает. Знания английского на уровне чтения документации уже недостаточно, тут нужен крепкий Intermediate, а лучше Upper-Intermediate. В общем, пункт номерраз — английский язык. It’s a must, period. И да, тебе нужен не просто разговорный английский, но и «технический разговорный» — собеседования на английском никто не отменял.

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

Пункт номер два. Ты решил изучать программирование, а с чего начинается любое обучение? Правильно — с книг, со чтения документации. Если я в свое время учил Android исключительно по книгам, то сейчас книги точно отошли на второй, если не на третий план. Книга долго пишется, а SDK быстро меняется. А вот в официальной документации обычно все up-to-date! И вот здесь я бы рекомендовал зайти в раздел гайдов на Developer Androidи пройти/изучить все интересующие тебя разделы.

Ты — дитя современности и не любишь читать, а предпочитаешь смотреть/слушать? Тогда Udacity (или любые другие онлайн-курсы) — это твой выбор. Вот здесь — отличная подборка видеокурсов различного плана, и самое главное — они бесплатные. Но без пункта номер раз (это который про английский язык) тебе к ним дорога закрыта.

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

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

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

• Видео с конференций Google I/O, DroidCon. Выбери наиболее тебя интересующие и просто скачай их с YouTube на телефон/ноут и смотри, когда хочешь. Это и плюс к карме разработчика, и плюс к прокачке английского языка.
• Заходи на Android Developers Blog — там публикуются анонсы, гайды, релизы.
• Подпишись на рассылку самого «вкусного» за неделю — AndroidWeekly.
• Зарегистрируйся в Mediumи подпишись на интересующих тебя публицистов/сообщества, к примеру ProAndroidDev.
• Подпишись на тематические Youtube-каналы, к примеру Android Developers, Google Developers.
• Общайся с другими разработчиками, получай знания/информацию из соседних областей.

Пункт номер шесть.Та-а-акссс, ну теперь ты загружен по полной и каша в голове! Отличненько! Иногда много информации — это хуже, чем отсутствие информации, согласись. Поэтому заведи свою базу знаний — Knowledge Base (KB). Лично у меня это Evernote, где я по тегам раскидываю интересные статьи, куски кода. Изучая новую (для себя) технологию/фичу/либу, старайся получить информацию о ней больше, чем из одного источника. Лучшие материалы можно сохранить в свою KB, чтобы потом не рыскать по интернетам в поисках той самой статьи, где очень хорошо и подробно с примерами все было написано.

Пункт номер семь. Если ты в программирование всерьез и надолго, то очень важно, чтобы оно не стало рутиной, а было любимым хобби. Это ж круто целыми днями (а может и ночами) заниматься хобби и получать за это деньги! Уму не постижимо! А чтобы хобби не стало рутиной:

• Учи то, что тебе интересно. Если тебе нравятся алгоритмы, то прокачивай этот скилл. Интересует создание игр — изучи OpenGL и все, что связано с созданием игр. Это огромный пласт информации и не только из IT-сферы.
• Важно регулярно (а вот как регулярно — у всех индивидуально) делать level-up умений: выучить и применить (помнишь проект своей мечты?) что-то кардинально новое, технологию или новый язык программирования, который ну прямо-таки меняет фсьо! К примеру: RxJava, Dagger, новые Architecture Components by Google. Это и зарядка для ума, и пунктики в твое резюме.
• Найди IT-спеца/публициста/блогера, который бы тебе импонировал, и подпишись на него. Для меня в свое время такими людьми стали: Reto Meier (архитектура, компоненты приложения), Chet Haase (GUI, анимации), Colt McAnlis (алгоритмы, сжатие данных).

Итак, теперь ты хорошо кодишь на Java... молодец! Можешь ее забыть (шучу! старушка Java всегда пригодится на каком-нибудь проекте на саппорте) и начать учить Kotlin. Если год-полтора назад он скромно стучался в домик к зеленому человечку, то сейчас это инструмент, поддерживаемый Google и уверенно вытесняющий Java. Нужно знать Kotlin. Что тебе теперь надо сделать? Правильно — подписаться на Kotlin Weekly (ты уже смышленый, знаешь, как это делается ;)). И дальше по уже знакомому тебе списку: официальная документация (она там отличная), видео на Youtube, чуток саморекламы, Medium-подписки и прочее.

Вернемся туда, откуда мы начали... Ух ты, а приложение-то твое работает как нужно и на православном Nexus`е и на корейском Samsung`е! Ой, да ты уже и не в захудалой конторке работаешь, которая снимала подвальное помещение, где не было отопления зимой, а в солидной компании. И рутинный код ты пишешь все реже, а по большей части — самые важные/вкусные куски приложения. Achievement Unlocked: «Ты — Senior!».

И напоследок парочка life-tips:

• Не хватайся за Android Wear/TV/Auto, как бы ни хотелось. Вот только если ну совсем уже нечего делать, а хочется погрызть гранит науки.
• «Ты ж программист» — не диагноз, будь разносторонней личностью! Социализируйся, ходи в кино/театры/тусовки/музеи — где еще ты встретишь свою половинку? :) Хороших умных людей должно быть много!
• После английского начни учить еще какой-нибудь иностранный язык, но только такой, чтобы не был похож на английский и ломал мозг. Рекомендую японский/китайский.
• Дерзай! Нет, не дерзи своему тимлиду, а дерзай...

Василь Пірус, Competence Lead у Perfectial

7 років досвіду у Software Development, з них понад 5 — у мобільній розробці

У світі Android-розробки сьогодні дуже легко розгубитися: постійно виходять нові статті, відкриті бібліотеки, круті анонси та рекомендації для розробки під Android від Google. До цього всього додайте ще Kotlin — нову мову програмування, яка стрімко перетворюється на стандарт для написання Android-застосунків. У такому потоці інформації важливо вміти відфільтровувати цікаві і потрібні для вас речі: для того, щоб стати справді кращим спеціалістом, не обов’язково перечитувати усі можливі статті по MVP, MVVM, MVI, Clean/Reactive/etc architecture. Швидше навпаки, важливо розуміти основи, без яких буде дуже важко рухатися вперед.

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

Отже, нижче я наведу список ключових для фокусування сфер.

1. Розуміння та знання компонентів Android SDK
Важливими є життєві цикли Activityта Fragment, а також як працювати з Service, Intent’s. Це такі поняття, які не змінюються, проте недостатнє їх розуміння може спричинити чимало проблем у майбутньому.

Ще дуже класно розібратися в механізмі роботи та можливостях RecycleView — компоненту системи, що використовується майже в кожному застосунку. Дуже хороше відео на цю тему: Yigit Boyar: Pro RecyclerView.

2. Робота з Android UI
Сюди входить робота з XML Layout, ConstraintLayout, Animation. В деяких випадках доведеться писати CustomView, тому добре наперед підготуватися і зрозуміти, як працюють методи OnMeashure(), OnLayout(), onDraw().

Якщо вам ще не випадало нагоди багато працювати з UI, добрим тренуванням буде взяти свою улюблену програму та спробувати відтворити її в Android Studio. Є серія туторіалівпро те, як побудувати інтерфейс Instagram’у на базі компонентів Material design.

3. Unit-тестування, архітектурні компоненти
Ніколи не писали Unit-тести на проекті? Не проблема, 120 хвилин з CodeLab — і у вас вже є базові навички. Ще 110 хвилин — і ви вмієте користуватися архітектурними компонентами (принаймні це зрозуміліше, ніж просто документація).

4. Kotlin
Ну і звичайно, Kotlin. Як я вже згадував раніше, це must have. Раджу не зволікати і починати писати частини коду на Kotlin. Насправді це дуже зручно і вам не доведеться чекати на проект, що є/буде повністю написаний на Kotlin.

Google зараз активно працює над документацією, та для початку буде достатньо таких ресурсів: Android Developer, Android Kotlin Guides.

5. Цикл розробки проекту
Більш загальною, проте не менш важливою, метою є розуміння повного циклу розробки програми: від написання фічі або програми і до релізу в Google Play Store; навики аналізу крешів і причин їх виникнення.

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

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

Тематичні портали:

• ProAndroidDev;
• AndroidStudyGroup/conferences;
• Realm Academy.

Твіттер-блоги:

• Fernando Cejas;
• Jose Alcérreca;
• Juhani Lehtimäki;
• Hannes Dorfmann;
• César Ferreira;
• Mirek Stanek;
• Saúl Molinero.

Книжки:

• «Effective Java» (2nd Edition) by Joshua Bloch;
• «Efficient Android Threading: Asynchronous Processing Techniques for Android Applications» by Anders Goransson;
• «Kotlin in Action» by Dmitry Jemerov,‎ Svetlana Isakova;
• «Reactive Programming with RxJava: Creating Asynchronous, Event-Based Applications» by Tomasz Nurkiewicz,‎ Ben Christensen.

Роман Кучерявец, Android Team Lead в Nullgravity

5 лет опыта разработки под Android

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

Что нужно знать
Нужно начать с основ. Любой язык программирования имеет в себе ряд конструкций и особенностей, которые необходимо знать. В случае с Java это работа с памятью, коллекции и пакет потока безопасных аналогов из java.util.concurrent.*. Раз уж речь зашла о многопоточности, нельзя забывать о том, как в целом она устроена в Java и Android в частности (один из самых избитых вопросов на собеседованиях). Кроме языка, каждая экосистема, в которой работает та или иная программа, тоже обладает своей спецификацией и требованиями. Так как нам предстоит работать с зоопарком устройств экосистемы Android, нужно знать особенности некоторых брендов, потому как не всегда поведение программы в одной ОС будет одинаковым на разных девайсах, к примеру, от Xiaomi или Meizu.

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

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

Используй практику ревью кода. Например, у нас в Nullgravity на каждом проекте используется кросс-ревью, к тому же тимлиды команд смотрят еще pull request’ы соседних проектов. Если практика code review еще не используется у тебя на проекте, будь первым, кто о ней заговорит. Времени на разработку новой фичи будет уходить больше, но код станет гораздо чище.

Что еще? Можно сказать про то, что у нас есть огромный спектр фреймворков и библиотек для всех наших потребностей! Но не стоит бездумно брать в работу первый попавшийся. Рекомендую ознакомиться с самыми популярными: Dagger2, RxJava2, Retrofit2, Google API (Maps, Firebaseи т. д.), Room (или любое другое популярное ORM решение), LiveData, Crashlytics — это одни из основных, с которыми частенько приходится работать. Все остальное ищется по принципу количества звездочек и проблем на GitHub. Всегда нужно взвешивать то, насколько конкретную задачу стоит делать с нуля, и сможешь ли ты решить ее лучше, чем это сделали другие за то же время.

И напоследок по этому вопросу. Очень рекомендую начинать практиковать Kotlin. Этот язык программирования уже прошел этап «молодого и неопытного» и сейчас быстро взрослеет. В нем есть множество вещей, которых нам могло не хватать в Java — null safety, coroutines, bind views, data class, sealed class, и многое другое.

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

Чтобы вырасти из junior’а, нужно понимать, насколько хорошо ты смог/-ла усвоить для себя какую-то тему, нужно постоянно заниматься саморазвитием. Потому даже если ты уже на проектe, то далеко не все, что было описано выше, может встретиться в работе. Всегда старайся автоматизировать то, что поддается этому волшебному слову — темплейты, CI, CD. Всегда пробуй что-то новое на pet-проектах. Выделяй время для планирования, чтобы появлялось понимание того, сколько уходит времени на задачи. Подтягивай знание английского, потому что документация по сложным фреймворкам в основном англоязычная.

Михаил Анохин, Android Developer в Dev-Pro

5 лет опыта

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

Java.Идеальным фундаментом для знаний Android-разработчика будет четкое понимание языка программирования. Для этого необходимо прочитать:

• The Really Big Index, Oracle;
• «Thinking in Java» by Bruce Eckel;
• «Effective Java» by Joshua Bloch;
• «Clean Code» by Robert Cecil Martin;
• «Java Concurrency in Practice» by Brian Goetz.

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

• Kotlin Reference;
• «Kotlin in Action» by Dmitry Jemerov and Svetlana Isakova;
• «Kotlin for Android Developers» by Antonio Leiva.

Android Framework.Необходимо понимать, какие компоненты включены в систему, как они взаимодействуют между собой и со сторонними сервисами. Эти процессы детально описаны в Developer Guides. После этого стоит прочитать книги:

• «Gradle Recipes for Android: Master the New Build System for Android» by Ken Kousen;
• «Efficient Android Threading: Asynchronous Processing Techniques for Android Applications» by Anders Goransson;
• «Android Programming: Pushing The Limits» by Erik Hellman;
• «Android Binder: Android Interprocess Communication» by Thorsten Schreiber;
• «Android Security Cookbook» by Keuth Makan and Scott Alexander-Bown.

Также стоит пройти курсы от Google на Udacity:

• Gradle for Android and Java;
• Developing Android Apps;
• Android Performance;
• Material Design for Android Developers;
• Google Location Services on Android;
• Add Google Maps to your Android App;
• Monetize Your Android App with Ads.

Что дальше?Дальше необходимо читать статьи, периодически добавляемые на Android Resources, и просматривать видео с конференций Google I/Oи DroidCon (Italy 2017, Berlin 2017, NYC 2017, SF 2017).

Олег Козак, Mobile Team Lead в Sigma Software

4 года опыта

Перше питання, яке виникає перед абсолютно всіма Android-початківцями: «Kotlin or Java?». Загалом непогано знати і те, і інше. Проте на початку кар’єри варто сконцентруватися на чомусь одному. Моя порада без вагань — Kotlin. Після того як Google навесні 2017 року анонсував Kotlin як офіційну мову для ОС Android, доля комерційних проектів на Java стрімко падає. Динаміку можна прослідкувати тут.

Для тих, хто має Java-бекграуд, рекомендую почитати цикл статей:

• Java vs. Kotlin для Android. День 1: спрыгиваем с Java;
• Java vs. Kotlin для Android. День 2: А может ну его, этот Kotlin?;
• Java vs. Kotlin для Android. День 3: Android высшего порядка;
• Та ще бонус: Kotlin Coroutines vs. Java Threads vs. Android Asynctasks.
  
  

Найкраще джерело Android-знань — Google. Нещодавно компанія запустила програму «Google Developers Training». Тут можна знайти тренінг як для початківців, так і для більш прокачаних девелоперів. Ці тренінги безкоштовні. Також можна пройти тести та отримати Android Developer Certificate, проте це вже платна опція.

Ще один важливий інструмент, на який хочу звернути вашу увагу, — Google Material Design. Дуже корисна збірка правил, де описано, як правильно будувати UI. Ці стандарти настільки круті, що ними керуються не лише в Android-розробці. Наприклад, знаю багатьох iOS-девелоперів, які використовують Material Design теж.

Але слід пам’ятати, що у всіх, навіть дуже авторитетних компаній, можуть бути недогляди. Нещодавно натрапив на проблему з BLE connection через boolean параметр в Android SDK методі. А саме — autoreconnect в методі connectGatt(context, false, сallback). Android-девайси з версією блютусу 5.0 не під’єднуються до BLE-девайсів, якщо autoreconnect true, і в той же час працюють без проблем, коли autoreconnect false. Таких огріхів, на жаль, вистачає. Однак не лише з технічними труднощами стикаються початківці.

Найпоширеніша проблема джуніор девелопера — практично будь-яка задача виглядає як «mission impossible». Але не варто впадати у відчай :) Коли не зрозуміло як вирішити задачу, не потрібно битись головою об стіну і намагатись самому знайти рішення. Найкращий вихід — просто спитати в команди. Можливо, хтось стикався вже з такою задачею. Як показує практика, в 95% випадків хтось або вже вирішував таку задачу, або знає, як її вирішити.

Ще один варіант — розбити задачу на маленькі частини і вирішувати глобальну задачу step by step. Потім, скоріш за все, доведеться трохи порефакторити після складання всього пазла, але вирішення задачі кількома способами ще нікому не зашкодило :)

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

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

Всем привет! В феврале произошло много чего интересного. Во-первых, Ruby исполнилось 25 лет, о чем написал Матц в своем Твиттере. Во-вторых, DHH выложил серию видео On Writing Software Well. В них DHH разбирает код Basecamp и рассуждает на интересные темы, например, использование callbacks для написания вспомогательной логики.

Почитать

Первые обзоры JIT в Ruby

The Method JIT Compiler for Ruby 2.6 — в феврале в Ruby 2.6 появился JIT compiler. В статье автор делится первыми впечатлениями от этой реализации.

Playing with Ruby’s new JIT: MJIT — обзор реализации JIT (just in time compiler), добавленной в Ruby 2.6.

Ruby’s New JIT — еще один обзор JIT в Ruby 2.6.

Ruby Concurrency: Building a Timeout Queue — построение многопоточной очереди с ограничением времени выполнения в Ruby.

Ruby String Literals vs Value Objects. Overengineering?— пример того, как Rails 5 API Attributes можно применять для рефакторинга антипаттерна Primitive Obsession.

Humming along — Analyzing RubyGems stats for 2017 — Infinum проанализировали экосистему Ruby в 2017: количество новых созданных гемов, загрузок фреймворков и популярных гемов.

Dig Deeper with Pry: Explore Ruby Internals — с недавних пор в Pry можно просматривать источник C-идентификаторовв Ruby.

TruffleRuby Native: Fast Even for Short Scripts — бенчмаркинг компиляции TruffleRuby, MRI и JRuby и других реализаций Ruby.

Goodbye ubygems — в версии Ruby 2.5 был удален файл ubygems.rb, и это не опечатка. Почему так произошло? Детали в статье :)

Translations with Rails and Jekyll — Mike McQuaid рассказывает, как решил проблему перевода сайтов на GitHub pages.

Coming to Terms with the ’Prima Donna Method’ Smell — разбор code smell’а Prima Donna Method в Ruby-коде.

Checking Postgres availability with pure Ruby — проверяем доступность Postgres на чистом Ruby.

Подборка от AppFolio

How Fast is Ruby 2.5.0?— AppFolio провели бенчмарк Ruby 2.5.0 и узнали, насколько новая версия быстрее, чем Ruby 2.4.3.

Benchmarking Ruby’s Heap: malloc, tcmalloc, jemalloc — сравнение производительности разных классов (malloc, tcmalloc, jemalloc), отвечающих за выделение памяти в Ruby.

CRuby Memory Slots: See Them, Tweak Them, Make Them Fast — обзор использования слотов памяти в CRuby.

Для начинающих Ruby-разработчиков

What Ruby taught me — начинающий разработчик Vinicius Brasil делится своими позитивными впечатлениями от изучения Ruby.

Как начать писать на Ruby on Rails: настройка окружения, советы по коду и полезные гемы.

Actionable advice to start learning to code — очень подробная и интересная статья с советами, как начать программировать. Внутри — истории из собственного опыта, списки полезных ресурсов и много мотивации к действию.

Туториалы

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

Testing React.js components with Jest in Rails+Webpacker+Webpack environment — подробный кейс по тестированию компонентов React.js с помощью Jest в среде Rails, Webpacker И Webpack.

Rustic Nil Handling in Ruby — когда в Ruby метод возвращает nil, это может означать несколько сценариев, что может привести к путанице в коде. Разработчик из HoneyBadger — Starr Horne предлагает решить эту проблему так же, как она решена в Rust.

Gzip A File In Ruby — подробный туториал по архивированию .gzip файлов в Ruby с помощью встроенного Zlib модуля.

GraphQL server with Sinatra (Ruby) — Part 1 — первая часть по созданию GraphQL сервера с помощью фреймворка Sinatra.

Speeding up Ruby with Shared Strings — Aaron Patterson рассказывает, как ускорить Ruby с общими строками.

Ruby on Rails: Running Tests with Guard and Docker — автор рассказывает, как оптимизировать запуск тестов с Guardи Docker в Rails-приложении.

Building a Command-Line Interface with Ruby — туториал по созданию command-line интерфейса на Ruby.

Goodbye Sprockets. Welcome Wepbacker 3.0 — простой гайд по переходу с Sprockets на Webpacker 3.0.

How to Separate Features for Different Organizations in a Rails App — в статье демонстрируется сразу три подхода к разделению фичей для разных организаций в SaaS-приложении на Rails.

How to use Query Objects to refactor Rails SQL-queries — в туториале объясняется, как использовать Query Objects для рефакторинга SQL-запросов в Rails-приложении.

Подборка от AppSignal

Syntactic sugar methods in Ruby — как Ruby использует синтаксический сахар для более понятного и читабельного синтаксиса.

Inspecting Data in Ruby — инструкция по дебаггингу с помощью метода puts.

Debugging Exceptions in Rails — дебаггинг исключений в Ruby.

Подборка от Reinteractive

Action Cable for Rails and Angular JS 1.x — туториал по настройке серверной части Action Cable для Rails-приложения и клиентской части Angular JS 1.x.

Wallaby: a newcomer in the admin interface market — Wallaby — альтернатива таким панелям администратора, как RailsAdmin и ActiveAdmin, с возможностью кастомизации. В статье приводится пошаговое руководство по настройке Wallaby.

Creating custom helper methods for the Rails console — туториал по созданию кастомных helper методов для Rails-консоли.

Релизы

Rails

Rails 5.1.5 has been released — в середине февраля вышла новая версия Rails 5.1.5. Детали — в changelogs.

Parallel testing — в версии Rails 6.0.0

New Feature on Rails 5.2: Redis Cache Store — в версии Rails 5.2. появился Redis Cache Store.

Ruby

В Ruby 2.5 добавили метод Hash#slice

Ruby 2.6.0-preview1 Released — долгожданный релиз Ruby 2.6.0-preview1. Из интересного — имплементация JIT и значительные улучшения производительности.

RubyGems 2.7.5 — новый релиз включает в себя исправления ошибок.

Multiple vulnerabilities in RubyGems — обзор уязвимостей в RubyGems и версии, которые подвергаются им.

Sinatra 2.0.1 is out!— а еще вышла новая версия Sinatra, детали — в changelogs.

Посмотреть

Февраль посвящен не только JIT в Ruby 2.6, но и плейлисту с серий видео On Writing Software Well. DHH обещает рассказывать, как создаватькачественный софт.

Подборка скринкастов от GoRails

Rails 5.2 — Encrypted Credentials — узнайте, как использовать Encrypted credentials в Rails 5.2 вместо secrets.yml.

Undo Sending Button like GMail — создаем кнопку «Undo», как в GMail для отмены отправки уведомлений.

Building A Hosting Platform in Ruby — строим хостинг-платформу по типу HatchBox на Ruby.

RubyTapas

Two screencasts, two ways to eradicate Ruby nil values — два скринкаста и два разных способа устранить значения nil в Ruby.

Послушать

I added a Rails app to wrap the Ruby logic

Подкасты от RWpod:

• 05 выпуск 06 сезона. Rails 5.2: Active Storage and beyond, Embedding Go into Ruby applications, Localer, Webpack demos и прочее
• 06 выпуск 06 сезона. Ruby 2.5 added Hash#slice method, Stimulus JS, Chiccocoin, Eloquent JavaScript и прочее
• 07 выпуск 06 сезона. Ruby’s New JIT, Ruby 3×3, Ember 3.0, Parcel v1.6.0, Phaser 3.0, SingleCov, Face-verify.js, Blotter.js и прочее

Подкасты от The Ruby Rogues

RR 349: The Overnight Failure with Sebastian Sogamoso — подкаст с Sebastian Sogamoso, Ruby-разработчиком из CookPad. Sebastian рассказывает о своих фейлах на проектах и способах побороть страх перед неудачами.

RR 348: Continuous Automation — Chef, InSpec, and Habitat with Nathen Harvey and Nell Shamrell-Harrington — разговор Nathen Harvey и Nell Shamrell-Harrington, которые работают в Chef. Тема подкаста, как всегда, разнообразная — платформа Chef Automate, Chef комьюнити, Continuous automation и многое другое.

MRS 031: Jeremy Evans — ведущие The Ruby Rogues общаются с Jeremy Evans, Ruby-разработчиком с 14+ годами опыта. Тема подкаста — путь Jeremy от C++ до Ruby, сравнение Rails и Sinatra и как Ruby менялся на протяжении этих лет.

Ruby Gems

Facebook-cleaner — скрипт, который удаляет весь старый контент из вашего профиля на Facebook.

Hm?— экспериментальный гем, который предоставляет эффективный, идиоматичный DSL для hash transformations в Ruby.

Random

Sandi Metz — автор книги Practical Object-Oriented Design in Ruby. Теперь все его фанаты могут купить футболку с надписью«What would Sandi Metz do?»

Касательно тем/материалов/ивентов, которые стоит добавить в следующий выпуск дайджеста, пишите в комментариях или на volodymyr.vorobiov@rubygarage.org. Спасибо за помощь в подготовке дайджеста команде RubyGarage.

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

В выпуске: новые правила в App Store, скругление в iPhone X, хаки для IB, тестируем асинхронный код.

Статьи

Display More Screenshots on Your Product Page
Теперь можно размещать до 10 скриншотов приложения в App Store.

App Review rejecting apps that use Apple emoji for user interface icons
Apple теперь не разрешает использовать эмодзи в элементах интерфейса (см. пункт 5.2.5).

Masked And Animated Corners
Пока все ждут, когда Apple сделает публичный API для «правильного» скругления, они добавляют анимации для изменения радиуса и маски для углов. Ну что ж, подождем еще пару лет.

No Cutting Corners on the iPhone X
И сразу в продолжение про правильное скругление — почему оно такое и как сделано.

Why Your App Looks Better in Sketch
Замечали, что вроде делаешь дизайн по макету, а он все равно отличается? Разбираемся, почему так происходит и как исправить некоторые моменты. А если хотите уж совсем pixel perfect design, тогда есть отличный тулдля сравнения дизайна прямо в симуляторе.

Top-down iOS error architecture
Многие архитектуры описывают идеальные случаи, но не так часто говорят о том, как прокидывать ошибки. В статье описано, как прокидывать ошибки с самого верхнего слоя вниз.

Unit testing asynchronous Swift code
У тех, кто только начинает писать юнит-тесты, часто возникает вопрос — как же протестировать асинхронный код. В статье описано несколько решений для этого.

Vapor 3 Release Schedule
Vapor планирует мажорный апдейт. Бета доступна уже сейчас, а релиз планируется на середину марта, как раз к выходу Swift 4.1. Что нового в релизе можно почитать тут.

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

Code Size Optimization Mode in Swift 4.1
В Swift 4.1 можно будет выбрать — оптимизировать код скорости выполнения или размеру бинарника.

Dependency Management for iOS projects with the Swift package manager
Swift package manager официально не поддерживает iOS проекты, но выход есть.

Spectre and Meltdown fixes influence on iOS apps build time
Как исправление уязвимостей Spectre и Meltdown повлияло на скорость компиляции Swift проектов? В среднем время увеличилось на 4%.

Circular References Between Swift and Objective-C
Интересный кейс с циклическими зависимостями код на Swift и Objective-C.

Turning Swift compile-time safety into safety for your users
Необычный подход организации деструктивных операция с предупреждениями в код. Таким образом вы не забудете показать алерт, когда это необходимо.

Hole Driven Development in Swift
Часто бывает — написал сигнатуру функции, которая что-то возвращает и Xcode ругается, что ты еще ничего не вернул. Можно просто использовать fatalError, который возвращает Never.

iOS Ref
Подборка полезной инфы, которую непросто запомнить. Например, какой в iOS используется какой шрифт, распределение iOS по устройствам, какое разрешение и тому подобное.

How to use Dynamic Member Lookup in Swift
В Swift 5 добавится динамизм в рантейме. Детали можно прочитать по ссылке или в proposal на гитхабе.

Mac Privacy: Sandboxed Mac apps can record your screen at any time without you knowing
Любое приложение на маке может захватывать экран без запроса доступа. Потом распознаем что там на экране и тихо отправляем куда надо.

Apple HIG pre-release, 1985
Выдержка из HIG за 1985 год. Актуально до сих пор.

More Interface Builder Tips And Tricks
Дельные советы для работы с IB. Я, например, не знал № 9, и меня это всегда бесило.

Tools & Libs

Fix for the missing network activity indicator on iPhone X
Apple почему-то решилине добавлять активити индикатор для iPhone Х, но можно использовать сторонний компонент для этого.

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

Fastlane CI
Fastlane занимается развитием своего self-hosted CI. Проект еще не готов к использованию, но за прогрессом можно следить тут.

Transformer
Создание NSAttributedString еще не было таким простым. Вбиваем строку, форматируем ее, как в обычном редакторе, и получаем код на Swift или Objective-C.

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

В выпуске: используем Web Worker и CSS Grid в работе, оптимизируем Webpack и учим ReasonML.

CSS и CSS in JS

CSS Paint API — возможности CSS Paint в новом Chrome 61

Everything you need to know about CSS Variables — все, что нужно знать о CSS переменных

A Houdini Quickstart: registerProperty — начинаем писать CSS in JS вместе с Houdini

Using Media Queries For Responsive Design In 2018 — зачем нужны CSS Media в эпоху Flexbox и CSS grid

Modern CSS Explained For Dinosaurs — хронология развития CSS инструментов

CSS Grid Layout Module Level 2 — W3C

How I design with CSS grid — проектируем и верстаем вместе с CSS grid

CSS Grid layout — crossed sections — делам CSS проще вместе с Grid’ами

Recreating the GitHub Contribution Graph with CSS Grid Layout — Github график коммитов на CSS гридах

JavaScript

Top 10 JavaScript errors from 1000+ projects (and how to avoid them)

Советы и приёмы ES6, которые сделают ваш код чистым и читабельным

Understanding mergeMap and switchMap in RxJS

Workers at Your Service — особенности работы service workers в Safari

An Overview of JavaScript Testing in 2018 — на чем тестировать в 2K18

Build Pacman — пошагово пишем игру на Ember

JavaScript, I love you, you’re perfect, now change — что стоит изменить в JavaScript

Web Performance Optimization with Webpack — серия статей по оптимизации производительности фронтенда с Webpack от Ивана Акулова и Эдди Османи

Progressive Web Apps (PWA)

Progressive Web Apps — The Next Step in Web App Development

Welcoming Progressive Web Apps to Microsoft Edge and Windows 10 — PWA скоро в Store на Windows 10

Progressive Web App Roadshow — серия видео о PWA от инженеров Google

React

Sneak Peek: Beyond React 16

Why I’m switching from Angular to React and Redux in 2018 — еще одно очко в пользу React

The Beginner’s Guide to React — учим React

Bringing Together React, D3, And Their Ecosystem

Top React and Redux Packages for Faster Development — что нужно для быстрой разработки на React

Higher-Order Components: The Ultimate Guide

Evolving Patterns in React

Redux и его убийцы:

• Learn Redux by Building Redux from Scratch — пишем свой Redux
• Redesigning Redux — переосмысливаем Redux
• Replacing redux with the new React context API

Статьи от Kent C. Dodds из PayPall:

• The state reducer pattern
• React’s new Context API
• Application State Management

React Native

How to Become a React Native Developer in 2018 — учим React Native

Building the F8 App — руководство по созданию кроссплатформенных приложений на React Native

Building An E-commerce Search App with React Native

Vue.js

Создатель Vue.js отвечает Хабру

What’s new in Vue Devtools 4.0

Replacing jQuery With Vue.js: No Build Step Necessary — избавляемся от jQuery (для тех, кто этого еще не сделал)

Let’s Build a Custom Vue Router — пишем роутер

Managing User Permissions in a VueJS App

10 things I love about Vue

Vue + Vuex — Getting started

Angular

NgRx 5 and Schematics

Getting to Know the @Attribute Decorator in Angular

Demystifying the Dependency Inversion Principle in Angular

Introducing NGRX Actions 3.0

Your NGRX Effects are Probably Wrong

Angular Routing Data with NGRX Effects

Ultimate Angular + Prettier Cheatsheet

GraphQL и Apollo

An Introduction to GraphQL

Какие проблемы решает GraphQL и с чем его есть — A GraphQL Primer: Why We Need A New Kind Of API:

• Part 1
• Part 2

Статьи из блога Apollo:

• Improved Apollo Client Devtools
• Securing Your GraphQL API from Malicious Queries
• Zero-config GraphQL state management
• What’s next for React Apollo
• GraphQL vs. REST

Typescript

Sexier Imports in TypeScript

TypeScript — JavaScript with superpowers

Manual Typing is No Fun: Introducing TypeWiz!

Node.js

Building a Node.js WebSocket Chat App with Socket.io and React

How to Build a RESTful API with Authentication in 5 minutes — all from your command line

AWS Lambda Go vs. Node.js performance benchmark: updated

Библиотеки

Micron — контролируем CSS анимации с JavaScript’а

Callbag-basics — минималистичная реактивная библиотека от Андре Стальца

Nact — используем акторы в Node.js приложениях

Glow — улучшаем Flow

Airtap — тестируем JavaScript в 800+ браузерах.

Karmatic — пишем тесты по новому в браузере — zero-configuration с использованием Karma, Webpack, Jasmine и Puppeteer.

Анимируем React-интерфейс:

• React-morph
• React Flip Move

Urql — делаем взаимодействие с GraphQL проще на клиенте

Unstated — минималистичный стейт-менеджмент

Используем силу Web Worker’ов:

• Greenlet — асинхронный код
• Workerize — асинхронная подгрузки модулей
• Workerize-loader — автоматически подгружаем модули c Webpack
• Stockroom — стет приложения

Послушать

Frontend Weekend:

• #38 — Владимир Гриненко про БЭМ и работу в Симферополе
• #39 — Григорий Шехет про жизнь и работу в Сан-Франциско, frontend-дайджест и FRP
• #40 — Александра Шинкевич о переезде в Минск и притеснении девушек в IT
• #41 — Виталий Харисов о создании симферопольского офиса и украинской разработке Яндекса

Веб-стандарты:

• Выпуск № 106
• Выпуск № 107
• Выпуск № 108
• Выпуск № 109

Пятиминутка React:

• #39 — TypeScript 20/80
• #40 — Яндекс Трекер на фоне YouTrack

devschacht:

• Ночной фронтенд #20 — Немного новостей и инверсия контроля
• Ночной фронтенд #21 — Rolling Scopes, день первый
• Ночной фронтенд #22 — Rolling Scopes, день второй
• Ночной фронтенд #23 — SPb Frontend Meetup: Космос, Jenkins и проблемы TCP

Фронтенд Юность (18+):

• #36 Жалкая попытка Webpack догнать Parcel
• #37 Секреты React
• #38 Rolling Scopes. Впечатления
• #39 Улучшаем Javascript вопреки божественному замыслу

Radio.js:

• Выпуск 51: MiniBeerJS с Сергеем Рубановым и Григорием Шехет

Egghead подкаст:

• Angular Web Applications with Juri Strumpflohner and Rob Wormald (Angular Core Team)
• 12-factor Javascript Applications using Docker with Mark Shust
• Data Viz using D3 with Ben Clinkinbeard
• React Router with Michael Jackson
• Reactive Programming and the P2P Web with André Staltz

Конференции и митапы

PiterJS #21

WSD в Москве 2018

KyivJS#17 February 2018

React Vienna January 2018

Что нового

Webpack 4 — Перемога!

Parcel v1.6.0

Prisma

Indexed Database API 2.0 — в статусе рекомендованные

RunKit — REPL для разработки на Node.js

Web Assembly Studio — разрабатываем WASM-модули в браузере

Rekit Studio — React IDE

Node v5.7.0

Новый Storage Access API в Safai

Dart 2 — кто использует?

Kutt — новый способ сокращать URL

Демо

OpenSC2K — SimCity 2000 на JavaScript

ExpressCart — магазин на Node.js (Express, MongoDB) с потдержкой Stripe, PayPal и Authorize.net

Vue Enterprise Boilerplate

Остальное

Hiccup, Macros, API design, and magic — Никита Прокопов о генерации HTML в Clojure

5 Practical Ways To Share Code: From NPM To Lerna And Bit

Как учиться в 2К18:

• The JavaScript Learning Landscape in 2018
• The 2018 Web Developer Roadmap

Flutter — 5 reasons why you may love it — почему стоит начать писать на Flutter

We’re nearing the 7.0 Babel release. Here’s all the cool stuff we’ve been doing — ждем новый Babel 7.0

A secure web is here to stay — а ты перешел на HTTPS?!

Polacode — плагин для VS Code который делает скриншоты кода

Maybe you don’t need Rust and WASM to speed up your JS — оптимизируем наш код

Exploring ReasonML and functional programming — новая книга Акселя Раушмайера

18 марта в Киеве пройдет конференция — JavaScript fwdays’18. Будет 2 потока докладов, tech talks, workshop и Speakers’ Corner — программа. Для читателей дайджеста промокод на 15% скидку: frontend-digest-fwdays.

Grammarly ищет талантливых Front-End инженеров для усовершенствования нашего продукта, создания минималистичных элегантных пользовательских интерфейсов и решения сложных технических задач. Нашим продуктом пользуются миллионы пользователей каждый день. У нас замечательная команда, вместе с которой мы используем самые передовые технологии. И если вам интересно стать частью её, то стучитесь ко мне в Facebookили Twitter.

С вами был Григорий Шехет. За помощь в оформлении дайджеста благодарю своих коллег.

← Предыдущий выпуск: Frontend дайджест #28.
Следующий выпуск: Frontend дайджест #30→

Одеський національний політехнічний університет другий рік поспіль отримує одну з найнижчих оцінок у рейтингу вишів. У 2017-мувін зайняв 13 місце.

В ОНПУ є 4 інститути, напрямки підготовки яких пов’язані з IT:

• Інститут комп’ютерних систем (ІКС);
• Інститут промислових технологій дизайну та менеджменту (ІТПДМ);
• Інститут інформаційної безпеки, радіоелектроніки та телекомунікацій (ІІБРТ);
• Інститут бізнесу, економіки та комп’ютерних технологій (ІБЕІТ).

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

Інститут комп’ютерних систем

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

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

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

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

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

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

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

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

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

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

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

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

Языки программирования Java и C++ изучались по 1,5 месяца (1 модулю), а потом сказали, что вы основы знаете — дальше сами. Единственное, что хорошо — дальше можно выучить другой язык, на нём всё делать, и такие задания могут принимать, если нет конкретного указания, на чём делать. Еще были основы С 1 год, чуточку SQL, UML.

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

(анонімно, 4 курс)

Студентська ІТ-еврика

***

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

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

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

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

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

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

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

(Іван, 2 курс)

***

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

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

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

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

Про вивчення програмування: починали з C, потім додали Java. Далі намагались навчати PHP, але більшість студентів виконувала завдання по вебу іншими інструментами. Також додатково можна знайти лекції по Python та Machine Learning.

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

(Влад, 4 курс)

День народження старости групи

***

В целом качество образования на достаточно высоком уровне. Если студент знает, зачем он получает высшее образование, то университет дает полную базу знаний для того, чтобы пришедший студент вышел специалистом в своей области. Я обучался на кафедре «Информационные и управляющие системы» по специальности «программист». Кафедре очень благодарен, достаточно профессиональный преподавательский состав. Материальная база ввиду постоянного недофинансирования частично устаревшая, но благодаря усилиям преподавателей, декана ищутся альтернативы. На кафедре часто заключаются договора с ИТ-компаниями (Netcracker, Luxoft, Sigma Software и др.) о трудоустройстве способных ребят. Также компании помогают укомлектовывать лаборатории. Помогают с прохождением практики, есть действующие программы обмена студентами, по которым можно уехать в другую страну для повышения квалификации или обучения в университете.

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

Университет дает достаточно перспектив для дальнейшего развития, карьерного роста, если быть заинтересованным в результате. Но стоит отдать должное многим преподавателям: Антощук Светлане Григорьевне, Николенко Анатолию Александровичу, Бабилунге Оксане Юрьевне, Малыгиной Любови Ивановне, Анисимову Владимиру Александровичу и многим другим. Заставляют выучить, и если ты получаешь тройку, значит, ты все-таки выучил на тройку :) Я относился к категории двоешников и сдавал все либо в последний момент, либо уже постфактум после сессии. Но всегда преподаватели шли на встречу, и пытались чему-то научить, даже если ты этого особо и не хотел.

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

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

(Сергей, выпускник)

Інститут промислових технологій дизайну та менеджменту

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

Студенти спеціальності «Комп’ютерні науки» вивчають розробку і супровід програмних систем як загального призначення (бази даних, обчислювальні програмні комплекси, графічні пакети і т. п.), так і спеціалізованого, призначеного для забезпечення захисту інформаційних систем. Також вивчаються розробка і застосування автоматизованих систем проектування різних виробів і технологій, методи художнього конструювання і дизайну промислової продукції, інтер’єрів, ландшафту, реклами, web-дизайну, управління IT-проектами, аналіз бізнес-процесів, основи інноваційного підприємництва. У рамках спеціальності опановують розробку апаратного та програмного забезпечення для інформаційних та інтелектуальних комп’ютерних систем та мобільних пристроїв на базі Windows, GNU Linux, MacOS, Android та iOS.

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

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

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

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

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

(Ян, выпускник)

***

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

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

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

(Тая, выпускница)

Інститут інформаційної безпеки, радіоелектроніки та телекомунікацій

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

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

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

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

У нас на факультеті спеціальність «Комп’ютерні науки» була тоді досить новою, майже експериментальною. Ми всі хотіли бути програмістами, а більшість викладачів раніше мали справу тільки з радіоелектронікою. Програмування викладали менше, ніж на ІКС, і всі вважали, що ІКС крутіший. Але були класні викладачі, які намагалися розібратися в більш нових технологіях, і нам було цікаво з ними (наприклад, Андріянов). І взагалі, хоч програма і була досить старою, викладачі дуже багато вкладали в нас.

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

А на ІКС дійсно все було зовсім по-іншому, мені доводилося побути свідком багатьох занять там. Програмування там викладали стільки, що можна було тільки мріяти про таке в нас. Але головне — результат.

(Наталя, випускниця)

***

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

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

(Олексій, випускник)

***

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

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

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

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

(Елена, выпускница)

Інститут бізнесу, економіки та інформаційних технологій

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

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

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

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

***

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

В целом, учитывая, что я ботан, приобрела очень много навыков, развитие математических способностей и экономического мышления. Я работала :) Например, практические задачи, РГР регулярно сама делала. А так всему на работе училась.

(Анастасия, выпускница)

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

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

(Ольга, выпускница)

Резюме

Image source

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

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

Причини

Ще на початку свого становлення як менеджера я відчула на особі всі ознаки професійного вигорання з одним-єдиним справжнім бажанням — потрапити на безлюдний острів.

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

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

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

Висновки з особистого досвіду

Встигнути все і скрізь неможливо та й не треба. Фокус — на пріоритети і важливі справи

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

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

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

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

1. Я.
2. Моя половинка (чоловік/дружина).
3. Діти.
4. Батьки/рідні.
5. Робота.
6. Друзі / хобі / домашні тварини.

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

Обов’язково має бути час на відновлення енергії

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

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

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

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

Накопичення позитивних емоцій. Змінюємо ставлення. Фокус на можливості

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

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

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

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

Правила для попередження вигорання

Враховуючи ті зміни, особистісні та професійні, які відбувались зі мною протягом 10 років на керівних посадах, у мене сформувались чіткі правила, якими я керуюсь, аби знову не зустрітись пліч-о-пліч з професійним вигоранням:

• Бути в контакті, в гармонії з собою. Бути чесним із собою. Чути себе, розуміти, чого зараз хочеться більше чи менше, відчувати свій внутрішній і фізичний стан, слухати своє тіло і організм. При потребі змінювати пріоритети, плани, реагувати на випередження.
• Бути в моменті. Тобто бути емоційно присутнім в тому місці, з тими людьми, в тих активностях, де ти є зараз. Якщо це час з дітьми, то всі твої думки, твоя фізична і емоційна присутність має бути з ними. Не відволікаючись на різні інші питання і думки. Нехай це буде 10-15навіть 5 хвилин часу емоційної присутності в моменті, але з точки зору результативності і ефективності це краще і більше, аніж годину часу «думи думаючи на різні теми одночасно».
• Планування цілей на рік, з декомпозицією задач на місяці, тижні, дні. За пріоритетами і з фокусом на їх важливість. Враховуючи ролі, які актуальні для мене більше чи менше в кожний момент часу. Переважно послідовно, аніж одночасно.
• Відпустки — мінімум тричі в рік, краще короткострокові, але частіше. Без робочої пошти, без засобів до зв’язку з робочих питань, без інтернету і соціальних мереж. Відпочинок активний чи пасивний. З сім’єю чи з друзями.
• Фізичні навантаження. Мінімум тричі в тиждень, чергуючи силові і аеробні вправи, розтяжки. Рухливість протягом дня, максимально часто, наскільки це можливо.
• Позитивне мислення і сприйняття подій, людей, обставин. Мінімізація негативних емоцій. Фокус на можливості.
• Релаксація і відпочинок для мозку. Масаж, медіативні техніки, музика, комфортна вуху, тощо. Кожного дня я «ловлю своє даніссімо» мінімум 30 хвилин і як в рекламі — «нехай увесь світ зачекає». Це той час, коли нічого не плануєш, нікуди не біжиш, ні з ким не говориш, а просто релаксуєш за чашечкою кави чи без, спостерігаєш або слухаєш звуки природи, за всім, що тебе оточує.
• Професійний і особистісний розвиток. Відвідування тренінгів. Читання книжок, статей. Враховуючи свої бажання і фокусуючись на тих напрямках, які є важливими, бо приносять задоволення.
• Час для себе. Він має бути завжди.

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

Поради менеджеру

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

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

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

Пам’ятайте

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

Руслан Коптев познакомился с программированием в 14 лет, когда родители подарили ему на Новый год стартовый набор Arduino, и с тех пор парня не остановить. Он самостоятельно освоил Arduino и С++, затем пошел в IT-школу в Кропивницком, где создал робота для очистки рек. Параллельно Руслан начал подрабатывать на фрилансе, делая разные девайсы. В 2017 году он поступил на бюджет в КПИ, но спустя две недели забросил учебу и начал сотрудничество с GlobalLogic. Обо всем этом и немного больше Руслан рассказал нам в интервью.

— Расскажи о роботе для очистки рек — что это за разработка и в чем его особенность?

Мы назвали его Riveroni. Это автономный робот, который очищает реки. Он работает как робот-пылесос, только на воде — собирает плавающий мусор — бутылки, пакеты и прочее. Робот создан из подручных материалов. Он оснащен солнечной батареей, GPS и камерой с датчиком.

Идея робота пришла в голову моему другу Роме Шмелёву, координатору школы программирования Ш++, которую я посещал с 9-гокласса. В Кропивницком это единственная школа, где состоявшиеся программисты бесплатно учат взрослых и детей основам программирования, С++, Python, Android и другим технологиям. В школе есть кружок робототехники, вот там мы и начали собирать робота.

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

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

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

Кропивницкий, р. Ингул

— Летом у вас прошел успешный запуск, что было после этого?

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

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

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

— Давай, перед тем как перейти к сотрудничеству с GlobalLogic, поговорим об учебе. Ты в 2017 году закончил школу и поступил в университет, но тебя уже отчислили?

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

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

Например, основы программирования, которые там все начинают учить, я уже знаю. Персональные компьютеры, C++... Изучать это по второму кругу и тратить на это время я не готов. При этом пары посещать надо, на что-то свое времени практически не остается. Пришлось прощаться с университетом.

— Ты уже отчислен?

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

— Как родители отреагировали на твой уход из университета?

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

— Не планируешь вообще получать диплом? Или все-таки где-то хочешь продолжить учиться?

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

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

— Разочаровавшись в КПИ, ты начал искать работу, так?

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

Сейчас участвую в немецком медицинском стартапе. Разрабатываю устройство, которое берет на себя заботу о своевременном приеме медикаментов.

— Ты говоришь, что тебе близка атмосфера стартапов, как тогда ты попал в GlobalLogic?

Все получилось случайно. В ноябре GlobalLogic проводил Embedded Career Day в Киеве. Я вообще люблю посещать разные события, поэтому решил поехать. Ребята из «Глобала» рассказывали, над чем они работают. Проекты меня заинтересовали. Мне предложили пройти интервью, а через час уже вручили оффер.

— Как все стремительно развивалось. Расскажи, что было на интервью?

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

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

Примеры работ в резюме Руслана

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

Марсоходы на хакатоне в Кропивницком

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

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

У меня было уже около двух лет опыта работы с клиентами на фрилансе. Уверенное знание Python, C++ и JS. Я уже довел до победного конца несколько коммерческих CV-проектов,сделал много устройств. Писал фронтенд, сервера на Node.js, веб-парсеры, приложения на Android и даже пару десктопных приложений. В общем, чем я только не занимался :)

— А в другие компании ходил на собеседования?

Еще в начале учебы в университете я ходил на разные события в ИТ-компаниях. Хотел, чтобы меня взяли на работу, так как думал, что буду учиться в Киеве.

Я был в Ring и EVO Company, но с ними не сложилось.

— Ты уже почти три месяца в GlobalLogic. Чем занимаешься? Какие первые впечатления?

У нас в команде около 30 человек. Кроме меня еще есть студенты. Приходил на позицию Trainee Software Engineer, но три месяца уже закончились.

Мне нравится атмосфера в компании. Здесь нет какой-то нездоровой конкуренции, все стремятся друг другу помочь.

Наша команда занимается решениями для Autonomous Driving. Часто работаем с различного рода распознаванием с бортовых камер, датчиков. Это в основном и есть то, что я делаю.

Пока меня не забрасывают в long-term проекты. Я работаю над стадией proof of concept, где главная задача — продемонстрировать опыт специалистов компании, перед тем как начнется более тесное сотрудничество. Здесь важно ориентироваться и понимать, как можно за минимальное время добиться значительных результатов. Часто имеет смысл использовать опенсорсные решения, где-то их допилить. Поэтому проектов много, и у меня есть возможность выбрать тот, который мне интересен. В компании много людей, всегда можно найти, у кого узнать что-нибудь новое. Поэтому не приходится заниматься тем, что не нравится.

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

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

Embedded Career Day, на котором Руслан получил оффер

— Уже получал обратную связь от своего менеджера?

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

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

До 9-гокласса я был отличником. Мне давали «похвальні листи», отправляли на олимпиады. А вот после 9-го,когда я решил перестать ходить в школу, они перестали меня хвалить :)

— А почему решил не ходить в школу?

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

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

— Что для тебя важно в работе?

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

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

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

Также в Кропивницком совсем немного ребят, которые профессионально работают в Embedded или Computer Vision. Я понимал, что развиваться в Киеве будет легче и быстрее.

— Чем хочешь заниматься дальше? Видишь себя в аутсорсинговой компании или все-таки тянет в стартап-атмосферу?

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

Меня сейчас интересует Computer Vision и Machine Learning. В этих направлениях у меня пока мало опыта. Но развиваюсь понемногу — проходил курсы на Courseraплюс постоянная практика в компании.

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

— Сейчас разработчики из Украины часто уезжают в Европу и Штаты. Рассматриваешь такую возможность?

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

— Что посоветуешь тем, кто только думает начать учить программирование и хочет попасть в мир ИТ?

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