Несколько месяцев назад уроженец Днепра Андрей Аксельрод, кофаундер Smarling, принял неожиданное решение. После 20 лет жизни в Нью-Йорке и 8 лет построения своего бизнеса он согласился переехать в Сан-Франциско, чтобы стать техническим директором набирающей обороты компании с украинскими корнями People.ai.

— Ты уехал из Украины еще в 90-е,насколько тогда это было сложным решением?

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

— Хорошей ли была подготовка в сфере компьютерных технологий, которую давал ДГУ? Тяжело было учиться после переезда, учитывая языковой барьер?

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

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

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

— В софтверную компанию RunTime Technologies ты пришел еще студентом и проработал там около 8 лет — завидное постоянство.

В этой компании я вырос до должности Chief Software Architect. Там мне встретились очень интересные люди, настоящие профи своего дела. Джек Вельди, операционный директор RunTime, впоследствии стал моим партнером в Smartling. Боб Мацуока, кофаундер, умнейший парень, многому научил меня в области технологий. Джим Килоу, глава правления, дал мне глубокие знания в сфере бизнеса. Тесная работа с ним на протяжении трех лет, когда я занимался, в том числе планированием продаж и обслуживанием клиентов, стала для меня своего рода MBA.

С Джеком Велди

— Как произошла твоя трансформация из инженера в менеджеры?

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

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

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

— Первая твоя менеджерская работа была в компании SpaFinder, где ты стал VP of Engineering и проработал год. Расскажи об этом периоде своей жизни.

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

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

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

Спустя какое-то время я встретился с бывшим коллегой, который тоже созрел для собственного дела. Джек Вельди тогда ушел из RunTime и работал в компании eMusic. Он поделился со мной несколькими идеями, которые можно было развивать. Одна из них была связана с соцсетями, вторая — близка к тому, что сейчас делает Stripe (обработка электронных платежей — ред.). Но мы решили выбрать тему, связанную с переводами и локализацией. Так, с разговора в кафе в 2009 году началась наша компания Smartling.

В офисе Smartling c Максом Согиным, Director of Software Development

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

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

Конечно, мы ездили в Долину, питчили инвесторов, но необходимости в переезде не было. Делать стартапы в Нью-Йорке — это абсолютно нормально и сейчас. Безусловно, в Сан-Франциско концентрация технологических компаний гораздо выше. В достаточно небольшом пространстве спрессована вся индустрия. Это играет очень важную роль особенно в том случае, если речь идет о B2B бизнесе в области tech. Ты выходишь из своего офиса, переходишь дорогу и попадаешь в офис к своему клиенту, по соседству — офис другого твоего потенциального клиента и так далее. Это уникальная ситуация и другая динамика.

— Если мы сравним не Нью-Йорк и Сан-Франциско, а например, Киев и Сан-Франциско. Можно ли сделать успешный стартап, находясь в Украине?

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

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

День независимости Украины в офисе Smartling

— Возвращаясь к созданному тобой и Джеком Велди стартапу. С 2010 года компания Smartling, работающая в сфере управления переводами, привлекла $ 63 млн инвестиций и, по оценке Forbes, стоит порядка 250 млн. Среди ваших клиентов — GoPro, Spotify, Vimeo, Foursquare, Pinterest, Uber, Tesla и другие. Как вам удалось поймать такую крупную рыбу?

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

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

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

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

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

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

— В Smartling у вас есть аутсорс-офисы в Украине. Какие твои впечатления от сотрудничества с украинскими разработчиками и рекрутерами?

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

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

Новогодний корпоратив в Smartling

— Недавно ты объявил о том, что прекращаешь участвовать в операционной деятельности Smartling, оставаясь советником, и переходишь на должность CTO в компанию People.ai, получив в ней долю. Это платформа на основе искусственного интеллекта для управления отделом продаж. Стартап базируется в Сан-Франциско, а его основатель — твой земляк, выходец из Днепропетровска, Олег Рогинский. Расскажи, как это все случилось?

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

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

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

В мае я приехал в Сан-Франциско на конференцию, и мы встретились с Олегом за обедом, который затянулся на пять часов. Олег рассказывал свое видение развития People.ai, а у меня в голове была четкая мысль: «Holly sheet! This is a billion-dollar company in the making!». Это ощущение одновременно и интуитивно, и имеет рациональную основу. У проекта Рогинского есть все признаки супер-успешной компании: это и то, что для Олега это не первый стартап, и сам он как личность, и участие в Y Combinator, и то, что этот стартап с инженерной точки зрения очень челленджевый, и качество видения продукта, его амбициозность.

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

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

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

— Ты прожил в Нью-Йорке 20 лет и знаешь его очень хорошо, в Сан-Франциско часто бывал наездами. Можешь сравнить эти два города?

Сан-Франциско очень single-minded, тут сплошной tech. Вся Bay Area — это такой утопический пузырь, то, чего на самом деле не должно существовать. А в Нью-Йорке есть все, представлены все аспекты нормального человеческого общества, разные индустрии. Это делает его намного более сбалансированным.

Ритм жизни в Нью-Йорке, конечно, сумасшедший, это то место, куда все приезжают делать бизнес и зарабатывать деньги. Сан-Франциско гораздо спокойнее, в 10 вечера все закрывается, поесть негде. Если у тебя есть амбиции в какой-то другой сфере, не технологической, то Нью-Йорк — тот город, который однозначно тебя поддержит. Он более респектабельный, там больше old money — людей, заработавших состояние давно. В Сан-Франциско мощная субкультура со множеством вариаций, все привыкли свободно самовыражаться. Это, пожалуй, the hippiest city in the world. Я пока не нашел с ним общий язык, но, думаю, все получится.

— На протяжении всех этих лет жизни в США ты продолжаешь приезжать в Украину и можешь отследить изменения, которые происходят. Какие твои впечатления?

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

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

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

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

Некоторые подозревают, что где-то есть злой умысел. «Зачем это они рассказывают, сколько проект привлек инвестиций? Какая мне разница, сколько фаундеры положили в карман? Лучше скажите, какая зарплата», — так рассуждают некоторые девелоперы, и вот с ними нам не по пути. Олег написал свой пост, чтобы отсеять людей с таким мышлением, чтобы они не приходили к нам на работу. Всем остальным — добро пожаловать. Мы предлагаем невероятную возможность, находясь в Украине, стать частью well-executed Silicon Valley startup with a potential to be a rocket ship.

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

Андрей Щурков, Senior Software Engineer в Irdeto

Сразу оговорюсь, что я уже больше 5 лет работаю не в Украине, поэтому буду отвечать по возможности в стиле «на Западе так, а в Украине этак».

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

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

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

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

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

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

• Краткое описание проекта, например: «Система обмена сообщениями для банка».
• Список технологий.
• Методологии (Scrum, TDD, BDD etc).
• Список достижений, например: «По моей инициативе перенесли сервис в облако, чем радикально улучшили масштабирование системы и сделали обновление без даунтаймов».
• Краткое описание, чем именно вы занимались на проекте, например: «Начинал мидлом, вырос до синьора, писал код, занимался оптимизацией базы данных».

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

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

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

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

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

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

Совет новичкам.Покажите, что вам не пофиг. Укажите GitHub с пет-проектами, сделайте это самое сопроводительное письмо.

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

Виктор Михайлов, Senior Java Developer в ABB

Я наблюдаю две типичные ошибки: слишком мало или много информации. В первом случае невозможно понять, чем человек занимался, какими инструментами пользовался, какова его роль. Например, указано: «Java developer in Sabre, PNR Services», и больше ничего. Во втором случае, если резюме занимает 6-8страниц с подробным описанием всей истории работы, начиная со школьной скамьи или студенческой подработки — это излишество.

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

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

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

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

Key areas of expertise:
— Database design
— Enterprise applications
— Microservices
— Mobile applications

Затем — список технических скиллов, которыми вы владеете. Например:

Technical skills:
— Programming languages: Java, C#, Kotlin, Scala, SQL, PL/SQL
— Development tools: Eclipse, IDEA
— Operating systems: Windows, Linux, Solaris, Mac OS 10.x
— Database systems: Oracle, PostgreSQL, MySQL
— Object modeling, Design Patterns, UML, SOLID
— Version control systems: SVN, Git, Perforce

Самые важные скиллы должны быть в этой шапке.

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

October 2015 — January 2017
Sabre Holdings. World-wide provider of electronic travel services, airline reservations, hotel and rented car bookings.

Achievements:
— Participated in development of PNR Services — services for retrieving/updating airline reservation data in Sabre TPF host via XML/SOAP open standard protocols.
— Participated in development of TPE (Travel Policy Engine) — service for validation travel records against set of business rules.
— Developed core components of eHotels — high volume transaction processing system, used for hotel booking and shopping worldwide.

Technology:
Java, J2SE 1.6, Hibernate 3.2, Camel, Spring, JAXB, JIBX, JBOSS, Oracle 10g, Linux, Solaris.

Личные качества можно перечислить, но это необязательно.

Если вы размещаете резюме на зарубежном сайте, например, Monster.com, который представляет собой большую базу данных, можно задействовать хитрость под названием «keyword spamming». Поисковая машина сортирует резюме по определенным ключевым словам, и те CV, в которых этих слов больше, поднимаются наверх в результатах поиска. Так что смело добавляйте побольше ключевых слов. Например, если вы специалист Oracle, то слово «Oracle» должно встречаться в каждом описании проекта как минимум раз или два.

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

Совет новичкам.Впишите как опыт работы какие-то некоммерческие студенческие и личные проекты, участие в Open Source.

Петро Сасник, Solutions Architect/Technical BA в SoftServe

Наразі я провів понад 100 співбесід і стільки ж внутрішніх оцінок знань та продуктивності роботи. Зазвичай співбесідую інженерів, але є досвід інтерв’ю з QA-менеджерами, техрайтерами, менеджерами з продукту, VP of Engineering.

Під час рекрутингу намагаюся відповісти на такі питання:

• Що людина знає (теоретично і практично)?
• Наскільки її профіль відповідає тому, що ми шукаємо?
• Чи дозволять особисті характеристики кандидата успішно вбудуватися в команду і давати результат?

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

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

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

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

Наприклад, коли в резюме на вакансію Cloud DevOps я бачу згадки про віртуалки, мережі, але не бачу нічого про CloudFormation/ARM/etc, Chet/Puppet/Ansible/etc, я розумію, що маю справу з системним адміністратором, а не DevOps. Він не відповідає профілю, який я шукаю, і співбесіди швидше за все не буде.

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

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

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

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

Щодо опису особистих якостей, я не бачив, щоб цей розділ оформляли так, щоб це було варто уваги. Проте для рівня Senior+ я вже очікую самоорганізованості і здатності вести за собою. Згадайте про це в описі проекту. Наприклад: «Вчасно завершував спринти, мав у підпорядкуванні двох Trainee, яких виховав до рівня Middle».

Не використовуйте Comic Sans ;) Шрифт має нормально читатися, тобто бути більший 8-горозміру і нормально виглядати після друку.

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

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

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

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

Останній новачок, якого я наймав, був дуже зелений, не знав багатьох базових речей. Але він написав і опублікував в Google Play Market простеньку гру.

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

Петр Коренев, iOS Team Lead в Sigma Software

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

Размер.Оптимально — 2-3странички А4.

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

Также я бы просил использовать PDF вместо DOC в целях повышения читаемости.

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

Фото.Если есть хороший снимок, то лучше вставить. Если нет, то лучше без фото.

Сопроводительное письмо.Если речь идет об Украине, я не вижу в нем необходимости. По крайней мере до интервьюера оно не доходит.

Совет новичкам.Главное — соответствовать требованиям на позицию. Если речь идет о частичном совпадении, то я в первую очередь отдаю предпочтение студентам и выпускникам технических вузов, а не выпускникам GoIT, BrainBasket и прочих вайти-курсов.

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

Дмитрий Думанский, Co-Founder Blynk

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

Еще одна довольно частая ошибка — нерелевантный к вакансии опыт. Например: «работал официантом» или «был оператором на телестудии».

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

Оформление.Главное в резюме — это пункт про опыт. Этот раздел должен находиться быстро и содержать такую информацию:

• технологии/стек;
• количество лет/месяцев на каждом из проектов;
• компания;
• домен проектов;
• ваша роль на проекте.

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

Фото.Не надо, это лишняя информация. Я вас все равно увижу на собеседовании (или нет).

Сопроводительное письмо.На своей практике ни разу не встречал. Как по мне, это лишнее. Лучше покажите свой код.

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

Может ли ссылка на LinkedIn быть заменой резюме?Да, вполне. Это даже лучше, чем PDF-ка.

Іван Вергун, TeamLead в Lohika

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

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

Розмір.Оптимальний розмір резюме для інженера з певним досвідом — до трьох сторінок.

Оформлення.На першій сторінці розмістіть «шапку» та загальну інформацію: objective, список технологій/інструментів/методологій, освіту, професійні зацікавлення.

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

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

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

Розділ з особистими якостями я ніколи не читаю.

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

Чи може лінк на LinkedIn бути заміною резюме?Як на мене, резюме на LinkedIn не дуже зручне і читабельне. Воно свідчить лише про те, що кандидат занадто ледачий, щоб оформити якісне резюме власноруч.

Андрей Губский, CTO в Торф ТВ

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

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

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

Оформление.Желательно избегать экзотических шрифтов. Размер шрифта должен быть в пределах 12-14 пунктов,чтобы текст не был слишком мелким или крупным.

Опыт работы лучше всего оформлять следующим образом:

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

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

Фото.Лично я необходимости в этом не вижу. А учитывая, что HR часто распечатывают резюме на черно-белом принтере, фото может превратиться в невнятное черно-серое пятно.

Сопроводительное письмо.Для меня такое письмо вряд ли стало бы серьезным преимуществом. Больше внимания я обращаю на само резюме.

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

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

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

Іван Даниленко, Full Stack Developer в Mindmarker

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

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

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

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

Розділ про особисті якості не є важливим. Не варто писати кліше, на кшталт hard working, positive. Вони викликають певне відчуття «no, not again».

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

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

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

Чи може лінк на LinkedIn бути заміною резюме?Я вважаю, що ні, але в резюме варто додати посилання на ваш профіль. На LinkedIn можна розмістити більше інформації, відгуки. Це дозволяє скласти краще враження про кандидата.

Максим Михеенко, VP of Technology в Intel 471

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

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

Размер.2-3страницы обычно достаточно. Есть достойные исключения, когда и на одной странице размещают все необходимое, но чаще лучше несколько страниц.

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

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

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

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

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

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

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

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

Сергей Факас, Information Security Officer

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

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

Размер.2-3 страницы,максимум 4. Все, что больше, — много.

Оформление.Резюме должно быть структурировано. Используйте какой-либо шаблон, например:

• Краткие личные данные;
• Знания и навыки в отрасли;
• Опыт работы (в обратном порядке);
• Английский;
• Регалии, публикации, хобби и прочее.

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

Раздел с личными качествами можно не писать. Более того, для меня наличие такого раздела попахивает неискренностью. Вряд ли кто-то в нем напишет: «Не люблю работать в команде» или «Считаю, что я всегда прав».

Фото.Если речь идет об IT — оно не нужно.

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

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

Андрей Литвинов, Senior Software Developer

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

Размер.1-2 страницы.

Оформление.Уделите внимание структуре. Распишите детальнее опыт предыдущих 2-3 лет,а остальное сократите до самого значимого/интересного.

Раздел с личными качествами не думаю, что важен. Но, если есть что сказать, стоит сказать.

Фото.Из США сейчас идет тенденция убирать информацию, по которой можно дискриминировать кандидата. Хорошее фото может улучшить общее впечатление, но оно совсем необязательно для меня.

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

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

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

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

[Артем Чернодуб, Chief Scientist в Clikque Technology. Более 10 лет опыта работы с алгоритмами машинного обучения, распознавания изображений и нейронных сетей. Кандидат технических наук, преподаватель в Украинском католическом университете, член программного комитета нескольких научных конференций IEEE]

— Слушай, а ты, вообще, понимаешь, что делаешь?
— У меня очень точные данные по анатомии человека.
— Ну конечно. Это же помогает тебе эффективнее нас убивать, да?
— Именно так!

© к/ф «Терминатор 2», сцена с зашиванием Т-800 раны Сары Коннор

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

Ian Goodfellow, Yoshua Bengio, Aaron Courville «Deep Learning»

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

Эта книга хорошо подойдет для любого уровня подготовки. Пробовали ли вы запускать нейронные сети, читали научные статьи или блоги на эту тему и хотите углубить и систематизировать свои знания, или же у вас уже есть своя публикация на NIPS, у вас должна быть эта книга! Она хорошо структурирована, содержит приличное количество математики (хотя, конечно, чем более свежие подходы приводятся, тем меньше формул и больше текста) и ссылки на оригинальные статьи. Также книга хороша в роли справочника и источника для цитирования вместо книги С. Хайкина «Нейронные сети: полный курс» (2006), сейчас уже устаревшей. Это must-have книга для каждого, кто работает с нейронными сетями. Как минимум, чтобы класть ее на ночь под подушку, чтобы знания сами впитывались во время сна, поскольку последовательно прочитать более 1000 страниц, конечно, никаких сил и времени нет.

Christopher Bishop «Pattern Recognition and Machine Learning»

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

Более свежий конкурирующий аналог — Kevin P. Murphy «Machine Learning: A Probabilistic Perspective», 2012.

Луис Педро Коэльо, Вилли Ричард «Построение систем машинного обучения на языке Python»

Очень практическая книга, написанная специально для новичков. В отличие от двух предыдущих трактатов, математики она почти не содержит. Зато есть быстрое введение в популярные python-библиотеки для машинного обучения и визуализации (numpy/scikit-learn/matplotlib), дается базовая культура работы с данными и интересные задачки-примеры, сделанные на коленке from scratch. А ведь все знают, что нет лучше способа понять, как работает сложная система, чем собрать ее самому на коленке from scratch! Среди примеров для воспроизведения есть: рекомендательная система для онлайн магазина, анализ эмоциональной окраски твитов, классификация музыкальных жанров по аудио, классификация музыкальных изображений и даже есть пример с обсчетом больших данных на AWS. Хотя эта книга немного сыровата и содержит небольшие ошибки, достоинств у нее явно больше, чем недостатков. Рекомендована девелоперам, которые хотят заняться машинным обучением. Достойная альтернатива на ту же тему — Stephen Marsland«Machine Learning: An Algorithmic Perspective, Second Edition», 2014.

arXiv.org

Позволю себе читинг, приведя вместо книги сайт-библиотеку научных статей arXiv.org (произносится как «архив»). Здесь публикуются препринты научных статей с самыми свежими результатами, часто даже перед их публикацией на конференциях или в научных журналах. Я встречал девелоперов, интересующихся AI/ML, которые без проблем читают длинные мануалы на английском и разбирают сложный чужой код, но почему-то стесняются читать научные статьи в оригинале. Напрасно! Во-первых, читать научные статьи (или «пейперы», прилипло к ним такое словечко!) это просто: хорошие научные статьи написаны по принципу «мыльной оперы», когда сценарий изложения материала очень стандартный: обзор существующих решений, мотивация своего решения и его описание, эксперимент и анализ его результатов. Если потренироваться, то читать их на самом деле легче, чем статьи на Хабре или популярные блоги в силу лучшей структурированности. Во-вторых, сейчас к научным статьям в области машинного обучения принято прилагать код на GitHub, который можно попробовать у себя, на своих примерах и для своих задач. Пробуйте! Если вы хотите быть в курсе самых последних новостей в мире машинного обучения, лучше arXiv.orgничего не бывает.

Владимир Лобас «Желтые короли. Записки нью-йоркского таксиста»

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

Анастасия Режепп, глава дизайн-студии DataArt, рассказала на конференции IT Arena Lviv, как им с коллегами удалось повысить доверие к работе дизайнеров внутри компании и научиться продавать клиентам дизайн как часть финального продукта. В этой статье — о том, как они учились, назначали дизайн-лидов, убеждали коллег и клиентов в важности дизайна.

Анастасия Режепп в центре

Дизайн-студия в DataArt работает с 1999 года, можно сказать, она существовала здесь всегда. Вначале задача дизайнеров заключалась в том, чтобы сделать разработанные нашими инженерами приложения более нарядными. Потом наступил переломный момент № 1: в мире резко вырос интерес к проектированию взаимодействия, и аббревиатура UX оказалась у всех на слуху. За ним последовал и второй: DataArt сменила курс, повернув от классического аутсорсинга в сторону консалтинговых услуг. С сервисом в области дизайна нужно было что-то делать.

Ситуация

Я стала главой дизайн-студии в 2014 году, ситуация тогда выглядела достаточно шаткой. С одной стороны, студия уже была довольно большой, в ней работало более 40 человек (исторически — дизайнеров и веб-мастеров). С другой — уровень доверия к ее услугам внутри DataArt был невысок.

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

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

План действий

1. Образование: выровнять уровень теоретических знаний у всех дизайнеров.
2. Уровень качества: поднять планку по результатам работы.
3. Повышение внутреннего доверия: заставить внутренних стейкхолдеров поверить в наш дизайн.
4. Убеждение клиентов: сделать так, чтобы клиенты захотели дизайн покупать.
5. Финальный шаг: включить дизайн в процессы и проекты в большинстве случаев.

Образование

Мы начали с чтения книг. Первой была «Handbook of Usability Testing», by Jeffrey Rubin — затрудняюсь сказать, почему получилось именно так. Тем не менее мы собрали группу энтузиастов и читали эту книгу по одной главе в неделю с последующим обсуждением в митинг-руме. Позже мы прочитали еще два десятка книг. По крайней мере мы начали понимать, как строятся правильные процессы, и смогли о них говорить.

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

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

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

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

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

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

Уровень качества

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

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

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

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

Повышение внутреннего доверия

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

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

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

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

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

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

Убеждение клиентов

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

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

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

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

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

Включайте все важные аспекты, оценивая стоимость проекта. Если вы уверены, что приложение для беременных не взлетит без тестирования на пользователях, четко и ясно скажите об этом клиенту. Старайтесь не поддаваться на уговоры менеджеров: «Что это у вас тут 200 часов на прототип? Я же знаю, вы и за 50 сможете!». Допустим, и правда сможете. Но когда пользователи начнут указывать на неудобства — виноваты будете вы, UX-дизайнеры.

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

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

Бесконечный процесс

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

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

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

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

Андрей Ткаченко увлекся программированием еще в военном училище, но 25 лет посвятил службе в армии. По ее окончании, в 42 года, он решил вернуться к программированию и стал Software Engineer в Intetics. О своем карьерном пути он написал для DOU.

Служба

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

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

Я закончил училище с красным дипломом и мне посчастливилось попасть в Военный научный центр космических исследований (при Харьковском военном университете), который взаимодействовал в том числе и с Национальным космическим агентством Украины. Я был вовлечен в очень интересные проекты, связанные с разработкой системы контроля космического пространства, специальной обработкой информации глобальных навигационных спутниковых систем. Эти проекты требовали как научного подхода, так и умения программировать. Именно там и пригодились не только мои научные знания, но и приобретенные на кафедре навыки программирования.

За 25 лет в армии я дослужился до звания подполковника. Службу проходил в нескольких местах: Военный научный центр космических исследований, Объединенный научно-исследовательский институт Вооруженных Сил, Харьковский университет Воздушных Сил им. Ивана Кожедуба. Также защитил кандидатскую диссертацию на тему «Первоначальное определение орбит космических объектов по радиолокационным и оптическим наблюдениям».

Программирование

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

Чтобы определиться с технологией, я проанализировал рынок и пришел к выводу, что со знанием Java у меня открывается больше возможностей, чем если бы я углублялся в С++. Я понимал, что надо развиваться, и начал углубленно изучать английский, прошел курсы Java в Oracle Academy, начал программировать на Андроиде.

Английский я изучал постоянно (частные уроки, аудиокниги, фильмы, онлайн-курсы), начиная с уровня Pre-Intermediate в 2009 году и заканчивая получением сертификата САЕв 2016 году.

Хотя во время службы на Java не приходилось писать, поставил себе цель изучить Java до такого уровня, чтобы быть готовым к сертификации SCJP for Java 6, для чего прошел четырехмесячные курсы в Oracle Academy.

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

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

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

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

Работа

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

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

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

Начал я сразу с реальных задач, хотя и самых простых, вроде добавления элемента «Кнопка» в графическом редакторе. В начальный период главной задачей было освоиться с функциональным языком программирования (у заказчика он свой). Язык внутри проекта — Flow. Он закрытый, не open source и используется только у нас. Таких много, их называют DSL-языки, или Domain-specific language. Такие языки предназначены для специфических областей. Также предстояло смириться с тем, что ООП в общепринятом понимании не поддерживается, и разобраться с архитектурой уже написанного кода.

Очень понравилось то, что заказчик учитывает индивидуальные особенности каждого и дает возможность входить в проект в своем собственном комфортном темпе. Лично у меня ушел где-то месяц на «вхождение» в проект (по опыту коллег — в среднем так и происходит). Мне помогло изучение ресурсов по реактивному функциональному программированию (их достаточно много в сети), а также курс «Functional Programming in Scala»на Coursera. Я прошел этот курс немного позже, но считаю его очень хорошим с точки зрения знакомства с функциональным программированием. Сейчас новички проходят тренинговый курс из 10 задач, охватывающих разные аспекты использования языка.

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

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

Вывод

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

iOS 11

Цього року Apple здійснила дуже багато змін в iOS. Найсуттєвішими серед них є такі:

• Drag & Drop, зокрема і між різними аплікаціями;
• Системна аплікація Files, з якою можуть бути інтегровані ваші власні аплікації;
• Машинне навчання з Core ML, що зокрема включає в себе можливості розпізнання зображень та NLP: аналіз текстів мовами світу;
• Доповнена реальність з ARKit, про який зараз говорять на кожному кроці.

Є ще багато інших змін. Для ознайомлення з програмуванням під нову операційну систему я раджу книгу «iOS 11 by Tutorials», яку сам зараз читаю. Ця книга не містить нічого зайвого. В ній не пояснюється те, що вже було в попередній версіях iOS. Тільки нове, починаючи від Swift 4 і змін у Foundation до PDFKit і MusicKit.

Один з нюансів iOS 11 полягає в тому, що Apple викинулаінтеграцію з Facebook, Twitter та іншими соціальними мережами. Про перехід з фреймворку Social на TwitterKit з метою збереження інтеграції вашої аплікації з Twitter можна прочитати у документації Twitter туті тут.

Стів Возняк у Києві

Візит Стіва Возняка до Києва активно висвітлювали у Facebook українські IT-шники, що побували на різних заходах за його участі 30 вересня і 1 жовтня. AIN.uaта «Українська правда»підвели підсумки його візиту до України. Я хотів би навести дві ключові цитати з виступів Возняка у Києві, які опублікувала «Українська правда».

Про Україну:

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

Про Apple без Джобса:

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

Всем привет! Меня зовут Виктор, и я работаю менеджером проектов в компании Cogniance. Делюсь дюжиной интересных материалов по управлению проектом и продуктом в октябрьском выпуске PM Digest’a!

Project Management

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

Интервьюс автором книги «Working with Coders» (a practical guide to managing teams of software developers aimed at a non-technical audience). Хороший takeaway:

«Understanding the perspective and priorities of software developers is key to building effective relationships».

Интересная запись в блоге Макса Цепкова: Что делать, когда число специализаций превышает размер команды. Для кого-то актуально?

Новичок в Project Management? Задумаетесь о дополнительном образовании по предмету? Автор блога про аутсорсинг подготовил для вас пошаговое руководствопо выбору курса по управлению проектами.

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

Google раздает бесплатные плюшки — менеджер, налетай!

Agile, Scrum и все такое

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

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

Также несколько материалов по теме:

• Презентацияс AgileDays Максима Цепкова
• Статья Sharon Ede — Spiral Dynamics — A Way of Understanding Human Nature
• И на закуску, легкое чтиво в PDF — Introduction to Spiral Dynamics

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

Интервьюс автором книги SAFe Distilled. Избранная цитата:

«SAFe was launched on the back of the basic paradigm of self-organizing and cross-functional agile teams».

6 Ways Agile can turn Static:

• Unsastainable System Architecture
• Limitations of existing tools
• Culture Gap
• Difficulty Scaling Up
• Not the right type of project
• Bogged down by collaboration.

Детали и пруфы в статье. Приехал еще коммент с 7 пунктом:

• Agile: Great on paper, poor in execution

Любителям послушать подкаст по пути на работу посвящается: Top 10 Agile Podcasts.

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

Ретроспективы не работают, и все упражнения из Кикстартераидут по n-ному кругу? Может, стоит поэкспериментировать и попробовать холакратическую методику IDM?

Product Management

Анализ 100 вакансий продакт-менеджеров в Долине.

Как найти a-ha! moment в своем продукте и увеличить вовлечение пользователей.

О каких вещах люди пишут в отзывах на приложение. Если у вас есть приложение, настройте себе интеграцию отзывов в Slack, почту или Telegram (например, через AppFollow). Это крайне полезно и удобно.

User Journey Mapping для новичков.

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

Зачемдействительно делать MVP?

Для простоты тоже есть предел.

Fun

Постоянная рубрика: новости северных соседей

Автор проходитсяпо фейковой сущности Agile методологий в стиле вышкаленного Agile-прагматика, заканчивая статью вполне здравыми советами в секциях 60-30-10и Roles Checklist. Сарказм и Ирония — это юмор, поэтому попадает пост в блок Fun.

Еще немного мифов про Agile:

Синьор-Лид Проджект Менеджер #вредныесоветы

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

In 1983, female computer scientists at MIT wrote a report on how sexism was pushing women out of their—historically female—field. #Tbt August 31, 2017

Продакт овнеры/гейм-продюсеры (или как правильно в гейм-деве :)), пожалуйста, описывайте все требования, ничего не оставляйте на гейм-девелоперов:

Как гнобить разработчиков на собеседовании. Просто смешной текст на русском.

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

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

Переезд

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

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

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

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

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

Процедура примерно такова:

1. Сдать медицинские тесты и сделать отпечатки пальцев.
2. Заполнить большое количество бланков.
3. Бесконечное ожидание.
4. Забрать Emirates ID и паспорт с вклеенной визой.

Работа

Я сотрудничаю по контракту с международной австралийской компанией Tigerspike, которую недавно поглотила компания Concentrix. Занимаюсь дизайном интерфейсов. Cпонсором и клиентом является государственная компания Emirates Airlines, в офисах которой я постоянно и нахожусь. Главный офис находится в аэропорту — мне нравится наблюдать из окна за взлетами и посадкой самолетов.

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

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

Общий дизайн-отдел в компании называется Xd (Experience Design). Он делится на два подразделения — UX и UI.

UX-отдел занимается аналитикой, проектировкой wireframes, проводит user testing, собирает статистику, готовит презентации для клиента. UI — занимается визуализацией данных, созданием low-/hi- fidelity prototypes, анимацией, user interaction. Оба отдела постоянно взаимодействуют между собой.

Интересно, что в Украине часто миксуют эти два направления: все выполняет один дизайнер. Но как такового UX и его лучших практик в украинских компаниях особо не наблюдал. Максимум, очередной воркшоп по design thinking, который можно просто заменить здравым смыслом и логикой. Зато украинские дизайнеры имеют гораздо более сильные навыки в UI.

Моя дизайн-среда состоит из следующих инструментов: 15″ MacBook Pro последнего поколения, Sketch, Invision, UXPin, Principle, Adobe CC, JIRA, Trello, Chrome Inspect Mode. У меня с командой в среднем 2-3встречи в неделю с product owners со стороны Emirates. Часто это несколько человек из топ-менеджмента. На встречах презентуем, защищаем и продаем свои дизайн-решения клиенту, собираем отзывы и вносим правки.

IT-рынок

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

Технологический рынок страны довольно мал по сравнению с украинским, но имеет огромный потенциал. Есть отдельные интересные технологические локации. Например, Internet City, где находятся офисы Microsoft, Oracle, IBM, Google, или другая локация — Dubai Design District.

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

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

Жилье

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

Сам процесс аренды жилья довольно сложный для тех, кто недавно приехал в город. Вся недвижимость арендуется через брокеров и брокерские агентства, которым вы заплатите 5 % комиссии от годовой стоимости аренды жилья, в среднем это будет $1500-2000.

Также многие арендодатели хотят получить оплату за квартиру 1, 2, 4 чеками. То есть если аренда квартиры — $30 000 в год, то хотят сразу эту сумму получить одним чеком, это и есть 1 чек, 2 чека — оплата каждые полгода по $15 000 и т. д.

Еще один важный нюанс: для получения чековой книжки в банке и открытия счета вам необходима виза резидента и Emirates ID. Все это вы сможете получить не ранее чем через месяц после переезда. Таким образом, на краткосрочный период вам нужно будет пожить в отеле или арендовать комнату неофициально, например, через AirBnb или группы в Facebook. Готовьтесь к тому, что вначале будет некомфортно. Также здесь очень не любят расчеты наличными при проведении официальных операций.

Уровень жизни

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

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

• Аренда комфортного жилья в хорошем районе в месяц (студия, one bedroom, комната в 2 bedroom): $1500-2000;
• Средние расходы на питание, транспорт, средства гигиены, бытовые предметы в месяц: $1000-1500;
• Средний чек в хорошем кафе: $20-30;
• Средний чек в хорошем ресторане: $100-200;
• Обычный поход в супермаркет: $50;
• Проезд на такси, средняя дистанция: $20;
• Проездной метро на 3 месяца (2 зоны): $200;
• Ночная жизнь и развлечения: от $100;
• Посещение кино, концерта или другого развлекательного мероприятия: от $50;
• Автошкола и получение водительских прав: от $1500.

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

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

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

Муниципальный транспорт самый чистый и новый из того, что я видел в жизни. Беспилотное метро покрывает все локации города. Также есть трамвай, автобус и городское такси. Uber тут популярен гораздо меньше, чем в Киеве. Хотя по стандарту к вам приедет новый Lexus, впечатления от поездки не всегда могут быть хорошими из-за некомпетентности таксиста. Например, часто, когда мы вызывали Uber, таксист просто не приезжал. Был случай, когда он просто забил и уехал куда-то в пустыню. Также часто пропускают локацию назначения и высаживают в другом месте, так как разворот и обратная дорога очень длинные (особенности трасс в Дубае).

Свободное время люди здесь проводят в основном в тренажерных залах. Также много пьют в пабах, ходят по ночным клубам, на пляж и в огромные моллы (торговые центры). В целом тут нет такого движа, как в Европе и США. Учтите, что все развлечения и вечеринки в Дубае обойдутся вам в приличную сумму.

Климат

Климат довольно сложный и непривычный для людей из холодных стран. Полгода тут сущий ад в пустыни (+48 °C), когда живешь от кондиционера к кондиционеру. А вторые полгода — с октября — тут райские условия. Температура около +24 °C, море, пляжи, пикники в пустыне под открытым звездным небом, различные фестивали и мероприятия. Другими словами — жизнь оживает.

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

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

Люди

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

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

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

Общее впечатление

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

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

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

Сергій Шалаєв — допоміг організувати радіозв’язок, Євген Семенов, будучи в зоні бойових дій, продовжував вчитись і шукати своє місце в ІТ, В’ячеслав Гуменний — знайшов «вихід» з Донецького аеропорту і повернувся в ІТ. Про війну очами програмістів — читайте нижче.

«Чорт! Я ж на справжній війні!»

Серпень 2014 року. Окупованою проросійськими сепаратистами Красногорівкою навприсядки рухається трійка українських бійців 20-гоокремого мотопіхотного батальйону, наче у сцені з фільму «Full Metal Jacket» про В’єтнамську війну. Позаду них ще трійка солдатів, п’ятдесятьма метрами далі цокотить Т64. Ліворуч дороги видніється пустирище, а з ним — кулеметна черга. Свист куль, хвиля липкого страху. Бійці падають на землю, а Т64 гупає у відповідь. «Чорт! Я ж на справжній війні!», — мимоволі подумав тридцяти восьмирічний айтішник Сергій Шалаєв, лежачи на землі.

Сергій народився в Дніпрі. В 1994 році, коли уявлення про комп’ютер в Україні було близько рівня ігрових приставок Atari чи ZX Spectrum, він вступив до ліцею інформаційних технологій. Кілька років потому — школа, де Шалаєв викладав інформаційні технології. Там він організував свою першу веб-студію. «В школі навчився трохи управляти проектами в теоретичних і практичних основах. Один учень навіть справді став програмістом», — пригадує Сергій. Далі просто: резюме, Archer Software, де став згодом Delivery Manager й відповідав за виробничу частину розробок програмного забезпечення, і — війна.

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

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

«Людей з „воєнки“ в армії ніхто серйозно не сприймає. Особистий склад — це чоловіки 35-40 років,багато з них далеко не ангели, і їх треба вміти організувати», — говорить Шалаєв.

Частоти сепаратистів

Радіозв’язок в тодішній армії кульгав, наче підстрелений, а то й смертельно. З технікою Сергій давно на «ти», як сам жартома говорить. Тож з іншими хлопцями йому вдалось налагодити радіосправу, яка в регламенті ще не передбачалась: три лінії зв’язку, в кожного бійця по портативній радіостанції. «Одна лінія — „борщ — готовий“ — побутова, інша зі скремблюванням для тактичної інформації, а третя — батальйонна з шифруванням, 2кБ ключем і ретранслятором. Коли ми поїхали на ротацію, хлопці, що прийшли на заміну нам, мали п’ять радіостанцій. В нас було під сорок».

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

«Вони кілька разів серйозно підставлялись. Одного разу збирались в розвідку. Наші їх засікли й в п’ятистах метрах від опорного пункту накрили з гранатомету».

Після цього по рації можна було почути, як бойовики виговорювались. В перекладі на літературну звучало приблизно так: «Я до Львова дійду! Знайду негідників! Здійсню статевий акт над тобою і всіма твоїми сусідами!...».

Отупіння і збірник задач

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

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

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

«В кожного своє стойло»

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

Так Євген Семенов потрапив у спеціальні війська, де солдати займаються зв’язком та забезпеченням особового складу. До кінця строкової служби у бійця була мрія — повернутись з фронту й потрапити в ІТ. В зоні АТО він провів без місяця рік. А сьогодні працює в SPD-Ukraine. Дорогу в ІТ військовик прокладав саме в зоні бойових дій.

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

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

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

Фото з Яворівського полігону

Дві сесії та терпіння

У вільний час солдати займаються різним. «Хтось пив, невелика кількість хлопців займалась на турніках, деякі ходили в місто, інші спали. У вільний час я більше робив лабораторні на старому ноутбуці, потроху вчив програмування. — згадує Семенов. — Обстановка була не найкраща, я не пов’язував свою подальшу долю з армією. Хоча багато моїх колег по фронту казали, що не бачать себе на „гражданці“. Тому я намагався частіше займатись тим, що буде в мене після війни». У Євгена висіли дві не закриті сесії, які, узгодивши в університеті, він мав здати та бажання працювати в ІТ.

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

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

За три місяці курсів на фултаймі він попрацював з Java, Spring, Spring MVC, Hibernate, Angular 2, Unit Testing, Clean Code principles, TDD, зробив власний невеликий проект. А за п’ять місяців влаштувався в SPD-Ukraine на проект PitchBook.

Гради на горизонті

«Це був чийсь кабінет. Дивлюсь — на столі лежить томик Цвєтаєвої. Почав читати й аж легше стало, оживило», — пригадує свій час в АТО Оperational & Project Manager В’ячеслав Гуменний. Більше двох місяців він захищав Донецький аеропорт в складі 72-оїокремої механізованої бригади.

Гуменному трохи більше тридцяти. З ним ми говоримо по Skype. Фронтовий досвід згадує весело, але легке тремтіння його рук говорить про те, що війна залишила свій слід. В ІТ опинився просто: навчаючись в КПІ, вирішив з другом робити сайт рідного містечка — так і закрутилось. До війни він майже влаштувався у Frontman, а перед цим сім років працював у NewAgeLab проектним менеджером. Після анексії Криму і подальших подій Гуменний на патріотичному піднесенні був переконаний: армію треба будувати. Тому коли прийшла повістка, зрадів. Потрапив в аеропорт.

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

Або взяти себе в руки, або накласти їх на себе

Один з найважчих моментів був згодом. Українські військові були розбиті на два розрахунки по п’ять бійців в кожному. Гуменний, будучи командиром взводу, ганяв: тиждень з одними, тиждень з іншими. Одного дня прилетіло прямісінько в розрахунок. «Я якраз пішов від них за день. Міна потрапила прямо туди. Заділо всіх. Один загинув, інших швидка забрала в Донецьк. Хтось доклав, і їх забрали в полон», — Гуменний замовкає й не має охоти продовжувати історію далі. Відомо, що хлопці вижили. Їх обміняла СБУ.

«Кілька разів бувало дуже важко психологічно... — каже Гуменний, але приклади згадувати не хоче. — Питання в руках: або їх накласти на себе, або взяти себе ними. Що зробив? Як бачите, живий», — сміється він.

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

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

Привет, я Макс Макаренко, сооснователь и CEO компании Docsify. Наша команда создала одноименный IT-продукт, который помогает продавцам закрывать сделки быстрее и проще. В 2017 году Docsify стал лучшим B2B-продуктом на битве стартапов IT Arena. О том, как мы к этому пришли, делимся с сообществом DOU.

Идея

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

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

• А получил ли клиент письмо или оно попало в спам?
• Если письмо получил, то ознакомился ли с содержимым письма?
• Переходил ли он по ссылке на сайт?
• Досмотрел ли он документ до конца?
• Обратил ли он внимание на персональную скидку или просто проскролил весь документ?

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

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

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

Кратко о сервисе

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

Наш сервис:

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

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

(Этот список будет существенно расширяться в ближайшее время)

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

3. Позволяет настроить автоматическую отправку follow-up и интеграцию с любой CRM с помощью API и WebHooks.

Все это в конечном счете нужно для того, чтобы продавец смог:

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

Реализация

На сегодняшний день Docsify — web-приложение, которое встраивается прямо в интерфейс Gmail с помощью Google Chrome расширения.

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

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

Для front-end разработки и расширения для Google Chrome был выбран ReactJS, который позволяет писать высокопроизводительное приложение при работе со сложным интерфейсом Gmail. Компонентный подход ReactJS дает нам возможность использовать один компонент и в расширении, и в админке, что существенно экономит ресурсы.

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

Работая над версией Docsify 2.0, наша команда разработчиков из 2-хчеловек, совершила практически невозможное, разработав минимально жизнеспособный продукт с нуля всего за 4 месяца. Да-да, практически с нуля, ведь кардинальная смена концепции продукта — это совершенно нормально для стартапа, но подробнее об этом я расскажу немного позже.

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

Именно с этого и началась реализация сервиса Docsify в сентябре 2016 года. А уже в декабре мы запустили beta-версию Docsify 1.0.

При создании первой версии продукта основной акцент делался на:

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

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

В первые несколько месяцев после запуска мы собрали достаточно данных, получив всесторонний фидбэк от клиентов, чтобы понять, что необходимо брать курс на западный рынок, потому что, к сожалению, возможность масштабирования компании на локальном рынке практически невозможна. Это связано с тем, что полноценно использовать наш продукт начали в основном IT и другие компании, у которых уже хорошо отстроен sales process и налажена работа с CRM-системами. Подобная ситуация нечасто встречается среди большинства украинских компаний, где привыкли пользоваться записными книжками и таблицами Excel. Именно поэтому более продвинутый и технологический в этом отношении западный рынок оказался более привлекательным и перспективным для нас.

Также нам нужно было сузить ЦА до пользователей Gmail и G Suite. Когда мы дали пользователям возможность отслеживать документы независимо от способа отправки, мы не просто заставили их осваивать новый интерфейс, но и использовать еще один дополнительный инструмент. Ведь для того чтобы воспользоваться нашим сервисом, пользователям приходилось заходить в интерфейс Docsify 1.0 для создания каждой персональной ссылки на документ, а также для просмотра каждой статистики по просмотру документа. В итоге наш «универсальный» инструмент оказался слишком неудобен в использовании.

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

Уже через 4 месяца, к августу 2017 года, мы закончили работу над полностью обновленной версией Docsify 2.0 как Email&Document Tracking и Lead Scoring инструментом.

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

• создали с нуля удобное и простое в использовании расширение для Gmail;
• обеспечили вывод детальной статистики прямо в Gmail;
• создали Live-статистику в Gmail;
• изменили и расширили функционал Admin Panel продукта;
• разработали Dashboard с возможностью создания и вывода приоритизированного списка клиентов с гибкой системой фильтров и сортировки;
• добавили возможность настраивать показ документов на поддомене пользователя;
• добавили возможность подключения к отправленным документам дополнительных инструментов, через вставку JS-кода;
• разработали Desktop-уведомления;
• добавили функционал взаимодействия с Docsify через WebHooks;
• полностью поменяли дизайн и упаковку продукта, уделяя особое внимание UI/UX части.

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

С какими трудностями сталкивались и как их решали

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

В первой версии приложения мы конвертировали многостраничные документы (pdf, doc и т. п.) во внутренний формат хранения данных. Это занимало время на преобразование и лишнее место на диске, так как каждая страница документа, по сути, представляла собой несколько изображений, оптимизированных под различные разрешения экрана. Во второй версии мы пошли другим путем: все поддерживаемые документы мы преобразуем в формат PDF, который напрямую передается в браузер пользователя, где рендерится при помощи библиотеки PDF.js. Сам PDF-файл хранится на CDN-серверах Amazon для оптимизации скорости отдачи.

Описание проекта и принципов его работы

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

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

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

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

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

Несмотря на то, что пользователь получает детальную информацию прямо в Gmail, он также может перейти в так называемую панель администратора (Admin Panel) и с помощью нее получить доступ ко множеству других возможностей.

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

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

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

После отправки письма документы, прикрепленные к нему, открываются в браузере по URL present.docsify.net. Но у юзера есть возможность настроить открытие документов на собственном поддомене, а также использовать корпоративные цвета в оформлении окна просмотра документа. Делается это тоже на админ-панели.

Также недавно мы реализовали функционал взаимодействия с Docsify через WebHooks и API. Но это далеко не все возможности нашего продукта.

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

Результаты

Сегодня Docsify может похвастаться выходом на крупную площадку BetaListи победой в номинации The Best В2В StartUp на IT Arena 2017.

Планы на будущее у нас грандиозные, и один из ближайших — выход на ProductHunt.

Также совсем скоро можно будет увидеть в реализации следующие фичи Docsify:

• отложенная отправка сообщений прямо из Gmail;
• автоматическая отправка follow-ups;
• создание и сохранение шаблонов сообщений в Admin Panel, в том числе HTML-шаблонов;
• аналитика эффективности отправляемого контента и работы команды в целом;
• контроль содержимого письма после его отправки (замена контента, окончание срока действия контента, запрос данных о получателе перед просмотром документа);
• настройка рекламных кампаний (ремаркетинг) Facebook и Google Adwords только на тех получателей, которые смотрели отправленный документ;
• встраивание сторонних приложений (чатов, инструментов для звонков и т. п.) прямо в отправляемые документы;
• возможность интеграции в один клик с самыми популярными CRM-системами;
• интеграция с Outlook.

Вместе с этим Docsify планирует развивать направление AI, чтобы давать рекомендации, какой контент (документы, темы письма, шаблоны и даже целые последовательности писем), с какими клиентами и на каком этапе сделки использовать, чтобы получить наилучший результат.

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

Кстати, если вы хотите дополнить нашу команду профессионалов и делать крутой World Wide Product — присоединяйтесь!

Привет, меня зовут Дима. Я Full Stack программист, разрабатываю кроссплатформенные приложения и игры для web, desktop и mobile платформ. Чуть больше пяти лет я использую Haxe в своей повседневной работе. И так уж случилось, что большая часть Haxe-девелоперов используют его (в том или ином виде) только при разработке игр. Это, на мой взгляд, одна из причин недостаточной осведомленности о том, как его можно применять в других направлениях разработки ПО. В этой статье я хотел бы пролить свет на то, чем же является Haxe и почему вам стоит задуматься о том, чтобы начать использовать его в своих проектах уже сегодня.

О чем вообще речь?

Haxe — это open source инструмент (toolkit) для разработки кроссплатформенного ПО, в основе которого лежат такие вещи как:

1. Сам язык Haxe со строгой типизацией (но для любителей динамики есть возможность писать динамический код!).
2. Быстрый и современный компилятор.
3. Стандартная, кроссплатформенная библиотека и доступ к нативным функциям всех поддерживаемых платформ.

Сильная сторона языка Haxe в том, что он в большинстве случаев не компилируется, а транслируется в другие языки. Хотя в официальной документации и используется термин «compiler», правильнее было бы назвать его «transcompiler». Для простоты понимания я буду называть его транслятором. В чем же тут сильная сторона, спросите вы? В обилии целевых платформ, список которых постепенно увеличивается: JavaScript, C#, C++, Java, PHP (включая PHP7), Python, ActionScript 3, Lua, а также загадочные Neko и HashLink.

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

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

О синтаксисе и языке в целом

Приведу основной перечень преимуществ Haxe как языка:

• Мощная система типов (классы, интерфейсы, анонимные структуры, дженерик-типы, динамические типы, алгебрагические типы, абстрактные типы).
• Выразительный синтаксис (все есть выражение (everything is an expression), геттеры и сеттеры, сопоставление с образцом (pattern matching), упрощенный синтаксис создания массивов (array comprehension), интерполяция строк).
• Близость к целевой платформе (наличие extern-классов — позволяет применять нативные библиотеки конечной платформы, использование untyped кода, скрещивание Haxe с кодом целевой платформы).
• Оптимизация (inline-методы, inline для объектов, удаление мертвого кода (dead code elimination), статический анализатор, оптимизация кода).
• Метапрограммирование (макросы, кодогенерация на уровне выражений и целых типов — позволяет как генерировать, так и редактировать код во время компиляции, метаданные).
• Прочие вкусности (рефлексия, препроцессор, условная компиляция, статические расширения).

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

Так где все это использовать?

Краткий ответ — везде. Вот вам кейс из жизни и практики. Один из моих проектов — это мобильное, полуигровое приложение, в котором используется нативный UI и OpenGL для отрисовки игровых элементов. А также NodeJS сервер, который соединяется с Firebaseи обрабатывает клиентские запросы. Для решения этой задачи я написал мобильный фреймворк (что-то вроде React-native), который транслируется в С++ для iOS и в Java для Android, оставаясь полностью нативным. Но поскольку Haxe не умеет транслироваться в Objective-C, то мне все же пришлось написать небольшую прослойку для UI, которая обращалась к Obejctive-C методам из C++. Разделив логику и представление, я получил до 90% общей кодовой базы.

Используя JS как целевой язык, я продолжал писать код сервера на Haxe под NodeJS. Таким образом, сервер разделял единую логику с клиентами, написанную на одном языке, что оказалось гораздо приятнее и удобнее, чем если бы я тянул два\три\четыре разных языка на одном проекте. К слову, скоро я планирую открыть исходный код своего мобильного фреймворка.

Также Haxe постоянно выручает меня при разработке игр. Обилие фреймворков и библиотек в этой области позволяет запускать свои приложения абсолютно на всех платформах, включая консоли. А например, для тех, у кого остались проекты на ActionScript был создан такой фреймворк как OpenFL, который на 99,9% покрывает Flash API и способен запускаться как в браузере, так и на С++ платформах.

Я использую Haxe даже при написании мелких, консольных утилит, которые упрощают мне жизнь.

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

Посмотрим код

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

class Test {
    static function main() {
        trace("Haxe is great!");
    }
}

(function () { "use strict";
var Test = function() { };
Test.main = function() {
	console.log("Haxe is great!");
};
Test.main();
})();

Попробовать самостоятельно: try.haxe.org

Справа в качестве исходных данных у нас есть класс Test со статической функцией main, которая является точкой входа для программ, написанных на Haxe. Ну а trace — функция, которая выводит отладочную информацию в консоль.

Как и говорилось выше, по сгенерированному коду слева можно заметить, что Haxe старается все решать нативными средствами платформы. В случае с JavaScript он не создает ничего лишнего для функции trace и использует нативную для JS реализацию — console.log();

Взгляните теперь на следующий пример:

class Test {
    static function main() {
        var a:Int = 10;
        var b = 20;
        var c = a + b;
        trace('Result is ${c}');
    }
}

(function () { "use strict";
var Test = function() { };
Test.main = function() {
	console.log("Result is " + 30);
};
Test.main();
})();

Попробовать самостоятельно: try.haxe.org/#3496D

Здесь мы можем увидеть сразу три интересные вещи:

1. Хоть Haxe это строго типизированный язык, указывать тип необязательно. Haxe умеет выводить тип из выражения прямо во время компиляции.
2. Интерполяция строк, где переменная захватывается прямо внутри самой строки.
3. Haxe — это оптимизирующий компилятор. Он не станет генерировать вам переменные, если они нигде не используются. Haxe посчитает все во время компиляции, а в сгенерированный код подставит результат вычислений. К слову, это срабатывает статический анализатор, который можно отключить, при необходимости.

Ловко, не так ли?

Следующим примером я продемонстрирую то, что мы все еще имеем доступ к нативным функциям платформы.

Haxe

import js.Browser.document;
import js.Browser.console;

class Test {
    static function main() {
        document.addEventListener("DOMContentLoaded", function() {
            console.log(document.location);
        });
    }
}

JavaScript

(function () { "use strict";
var Test = function() { };
Test.main = function() {
	window.document.addEventListener("DOMContentLoaded",function() {
		window.console.log(window.document.location);
	});
};
Test.main();
})();

Попробовать самостоятельно: try.haxe.org/#b2A0c

И последний пример, который мы рассмотрим, — это untyped код. Untyped — это нетипизированные вставки кода на языке целевой платформы. В данном случае мы присваиваем к переменной Haxe функцию из JavaScript.

Haxe

class Test {
    static function main() {
        var a = untyped __js__('function(){console.log("Hello from untyped code!")}');
        a();
    }
}

JavaScript

(function () { "use strict";
var Test = function() { };
Test.main = function() {
	var a = function(){console.log("Hello from untyped code!")}
	a();
};
Test.main();
})();

Попробовать самостоятельно: try.haxe.org/#AD46b

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

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

Выводы

Является ли Haxe волшебной палочкой? Вовсе нет. Написать один раз и использовать везде не всегда возможно, ведь Haxe старается не создавать оберток над нативными кодом. Таким образом, говоря о кроссплатформенной разработке, стоит понимать, что если вы используете JavaScript-пакеты (как на последних двух примерах), то вы не сможете транслировать такой код, например, в Java. Для решения подобных задач Haxe поддерживает условную компиляцию: когда вы можете обернуть какой-либо код в директивы (define), и все, что не попадает под их условие, не будет добавлено в компиляцию. Пример: try.haxe.org/#5B0FE

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

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

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

Как начать использовать Haxe?

• Скачайте установщик Haxeдля своей ОС.
• Скачайте и установите VSCodeи плагин vshaxe, который доступен в меню расширений VSCode (Ctrl + Shift + X).
• Переходите к мануалу, взгляните на cookbook.
• Начинайте писать код!

P. S. Если вы работаете под Windows, то можете установить HaxeDevelopвместо VSCode. Это IDE на основе FlashDevelop, которая со временем будет развиваться по своему пути. HaxeDevelop даст вам такие бонусы, как автозаполнение кода, рефакторинг, шаблоны Haxe проектов и многое другое.

Ссылки

Официальный сайт: haxe.org
Попробовать Haxe онлайн: try.haxe.org
Мануал: haxe.org/manual/introduction.html
Cookbook: code.haxe.org

Официальный форум: groups.google.com/forum/#!forum/haxelang
Русскоязычный skype-чат: join.skype.com/ck4xJ5Arrp3R

Связь со мной:
Email: dmitry.hryppa@gmail.com
Skype: dmitryhryppa

Спасибо skype-сообществу Haxe за помощь в редактировании материала.
И спасибо всем, кто дочитал ;)

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

Методом проб и ошибок

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

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

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

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

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

Ответ на вопрос «Что пошло не так?» появился значительно позже. Решение пришло с моим переходом в новую компанию и началом работы над абсолютно другим продуктом. Именно тогда в руки случайно попала замечательная книга «Jobs to be done», by D. Traynor, P. Adams, E. Meehan, G. Keating. Она дала понимание того, почему подход с Buyer Personas работает не так, как хотелось бы.

Главный вывод: products don’t match people, they match problems.

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

Job based marketing: что это такое

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

Это проблемы клиента, которые способен решить тот или иной продукт. С годами продукты, сервисы и решения могут меняться, но некоторые проблемы остаются прежними. Как и сейчас, 100-200-1000лет назад человечеству необходимо было переправлять грузы. Тогда для этого использовали лошадей, верблюдов, деревянные судна, а сейчас есть региональные или международные логистические компании, как DHL, FedEx и проч. То есть мы видим, как разительно изменились подходы к решению задачи. Но сама проблема доставки грузов никуда не исчезла.

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

Не будем далеко ходить и возьмем для примера известный всем бренд McDonalds. Кто его конкуренты? Конечно, на ум сразу же приходят компании KFC, Burger King, Subway.

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

Также не стоит думать, что конкуренция газеты New York Post заканчивается рядом авторитетных изданий, таких как New York Times или Wall Street Journal. Очень серьезные вызовы это СМИ получает со стороны Facebook, Twitter, различных онлайн-игр.

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

Выход на рынок: два пути

После того как основные конкуренты определены, можно переходить к поиску маркетинговых каналов для вывода продукта на рынок. Сейчас все основные маркетинговые каналы делятся на две большие группы: Outbound marketing и Inbound Marketing.

Outbound marketing

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

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

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

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

Холодные email и холодные звонки — еще один из каналов оutbound-маркетнга. Для B2C-рынка, к сожалению, этот канал не эффективен, но для B2B-компаний он может быть вполне успешным.

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

Холодные email для B2B-рынка могут также стать эффективным каналом для привлечения клиентов. Сейчас существует много сервисов, которые заточены под отправку cold emails. Reply rate в этом канале достаточно высокий — около 50%. Но как быстро клиент отвечает, что ему интересно предложение, так же быстро он пропадает и перестает читать письма после предложения провести демо.

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

Помимо этого, необходимо найти таких аффилиатов и потратить время на их привлечение. Для B2B-компаний, пожалуй, одни из наиболее подходящих аффилиатов — digital-агентства. Как правило, у таких агентств нет своего продукта и их «хлеб» — это настройка сервисов для интернет-магазинов. Соответственно, практически в 100% случаев они готовы заключать такое партнерство и получать процент (в среднем от 15 до 30%) от каждого приведенного клиента. Также хороший пример аффилиатов — блоггеры и лидеры мнений с большим количеством подписчиков.

Inbound Marketing

Inbound-маркетинг отличается от оutbound-каналов тем, что в нем не используется «холодный метод» привлечения клиентов. Его суть заключается в противоположном: необходимо «прогреть» лиды, «прогреть» клиента до такого состояния, когда он сам захочет купить ваш продукт. Таким образом, іnbound-маркетинг подразумевает создание полезного контента.

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

Также в качестве образовательного контента подойдут различного рода презентации, eBooks, check lists, инструкции, которые можно выкладывать на сайте для скачивания. Чтобы скачать их, потенциальный клиент должен заполнить небольшую форму, в которой он оставит свои контакты (как минимум email). Такой подход при правильном оформлении улучшит SEO-оптимизацию и поднимет позиции вашей компании в органическом поиске.

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

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

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

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

Smarketing = sales + marketing

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

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

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

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

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

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

Меня зовут Евгений Ласман. Я — DevOps-инженер в компании Provectus. За 12+ лет попробовал себя в роли системного администратора, инженера технической поддержки, тестировщика и программиста. Мой главный проект сейчас — это работа с Atlassian Platinum Solutions Partner. Кроме этого, я консультирую клиентов компании по направлению DevOps.

Fun facts: последние несколько лет работаю удалённо, до этого много «сидел в офисе», а ещё раньше несколько лет работал «очень удалённо», то есть в море на судне. Женат, две кошки, один ребёнок.

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

Начнем с важного.

Что такое DevOps institute

DevOps Institute (DOI) — это организация, которая помогает компаниям трансформировать IT-услуги в сферах Dev и Ops, а также процессы контроля качества, безопасности и даже продаж.

В разработке программ участвуют гуру DevOps из IBM, ITSM Academy, F5 и прочих. Это и заинтересовало, ведь они делятся опытом и реальными примерами внедрения DevOps-культуры.

Зачем DevOps-у сертификация

Исходя из моего опыта и отзывов участников, сертификация помогает:

• Упорядочить и закрепить знания. Например, о том, из чего состоят CI и CD в деталях, о компонентах практик Lean и о том, что же такое Muda.

• Расширить кругозор по теме DevOps. Например, что такое TKI (Thomas Kilmann Conflict Mode Instrument) и при чём тут DevOps; какие метрики успешности можно применять для оценки культурных изменений; какими аргументами можно «продать» DevOps бизнесу и пр. Как вариант, понять, что от тебя хотят Dev, когда ты Ops, и наоборот.

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

Для компаний, в которых вы работаете, особенно в роли консультанта, сертификация позволяет:

• Однозначно квалифицировать вас, как DevOps-инженера.
• Иметь в своем штате сертифицированного специалиста.

• Развиваться в направлении тренингов, как внутри компании, так и для бизнеса.

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

Как устроен тест

Экзамен построен по принципу таксономии Блумас такой структурой:

• Первый уровень (знания): в основном о концепциях и терминах DevOps;
• Второй уровень (понимание): о применении концепций и терминов в контексте.

С некоторыми подходами и ответами даже на этапе подготовки я был не вполне согласен. Например, тенденция «Customer delight is more important than customer satisfaction» мне кажется довольно противоречивой. Это больше связано с моим личным опытом, а «сферический DevOps в вакууме», возможно, работает именно так.

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

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

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

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

Как готовиться

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

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

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

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

• DevOps.com;
• DevOps Institute;
• «2014 State of DevOps Report», Puppet Labs, IT Revolution Press, ThoughtWorks;
• «Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale», J. Humble, et al., O’Reilly Media, 2014;
• «The Phoenix Project», G. Kim, et al., IT Revolution Press, 2013;
• «Continuous Delivery», J. Humble, et al., Addison-Wesley Professional, 2010;
• «Lean IT: Enabling and Sustaining Your Lean Transformation», S. Bell and M. Orzen. Productivity Press, 2010.

Я считаю, для того чтобы нормально ориентироваться в темах на экзамене, стоит прочесть «The Phoenix Project» или может даже «The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations», как более новую. Не стоит пугаться таких терминов, как SDLC, Agile, Scrum, Lean, Flow, Golden Circle, Three Ways, pipeline, CI, Continuous Delivery и Continuous Deployment и прочих подобных. Также желательно иметь какой-то опыт «продажи» DevOps бизнесу, лучше западному.

Как проходит экзамен

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

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

Экзамен может проводиться в офисе компании-экзаменатора или же удаленно. Я выбрал второй вариант. Компания, которая проводит экзамен, — PeopleCert. После регистрации на экзамен на их сайте я выбрал дату и время (слот в 1,5 часа).

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

Звучит недостаточно паршиво? Ок, идём дальше!

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

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

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

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

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

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

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

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

Вот так это происходит. Спасибо всем, кто дочитал до конца :)

Буду рад помочь и ответить на вопросы.

Дерзайте!

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

Андрей Чередарчук — ИТ-инструктор и администратор. Сертифицированный инструктор учебных программ HP, IBM, VMware, ранее также и Cisco. Разрабатывает авторские учебные курсы. Занимается поддержкой HPC-инфраструктуры в НАН Украины.

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

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

Современные тренды в HPC

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

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

На чем разрабатывать

Какие сегодня есть фреймворки для разработки под GPU и под процессоры в общей памяти? Во-первых, OpenCL. Эта технология рассчитана на использование как GPU, так и процессоров хоста. Из всех технологий, которые сегодня есть, OpenCL поддерживает наибольшее количество видов аппаратных ресурсов. Но есть мнение (иногда спорное), что программы, написанные под OpenCL, не всегда работают на NVidia GPU так же быстро, как программы, написанные с использованием CUDA.

Название технологии CUDA расшифровывается как Compute Unified Device Architecture. Ее большой недостаток — то, что она поддерживает только устройства Nvidia. С другими устройствами, скажем AMD, она не работает. Но зато большинство вычислительных приложений под NVidia GPU разрабатывается именно с использованием CUDA.

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

OpenACC — это еще один фреймворк, который похож на OpenMP и поддерживается некоторыми коммерческими компиляторами. В OpenACC есть набор готовых библиотек для работы с GPU. OpenACC не распространяется свободно.

Если сравнивать CUDA и OpenCl, то у них очень похожая идеология разработки. Однако API у них отличается. Если разобраться с одним, то понять другой потом будет несложно. До появления OpenCL 2.0 главным принципиальным отличием CUDA и OpenCl была поддержка Managed Memory в технологии CUDA. Технологии быстро развиваются и сегодня OpenCl имеет аналог, который называется Shared Virtual Memory. В дальнейшем остановимся более подробно на технологии CUDA. Далее все изображения и термины взяты с сайта Nvidia, где документация для разработчиков под CUDA есть в свободном доступе.

Модель вычислений

Основная терминология CUDA такая: хост — это вычислительный узел, на котором запускается ваша программа. В этот вычислительный узел, у которого есть один или несколько процессоров, вставлен один или несколько графических акселераторов, которые называются девайсами или устройствами. Программа, которая работает на хосте и устройстве, состоит из двух частей: это код хоста, который выполняется на процессорах хоста, и так называемый кернел (Device Kernel), или ядро устройства. Ядро выполняется на графическом акселераторе. Любая программа для GPU имеет и ядро, и код хоста.

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

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

В чем особенность выполнения кернелов на устройстве? В кернелах используется так называемая SIMD-модель (Single Instruction Multiple Data). Это модель массового параллелизма, в которой все потоки (thread) выполняют один и тот же код, но для разных данных. Если у вас есть какой-то массив, то каждый поток обрабатывает один элемент этого массива. При этом набор из нескольких потоков, которые называются варпом (Warp), физически выполняют одну машинную инструкцию.

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

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

Блоки объединяются в грид (Grid). Грид — это фактически набор различных блоков, которые могут выполняться на устройстве. Каждый поток имеет свой номер в блоке, каждый блок имеет свой номер в гриде. Эти номера могут быть представлены в виде одно-, двух- или трехмерной решетки. Именно по номеру потоков и блоков обычно осуществляется адресация элементов массивов, с которыми работает поток. Всего в гриде может быть очень большое количество потоков, больше миллиарда. Понятно, что выполняться будут только те потоки, для которых хватит ресурсов физических устройств (мультипроцессоров). Остальные потоки будут планироваться на выполнение, но выполняться позже.

То есть в варпе все выполняется одновременно. Блок — почти одновременно. Грид — параллельно или псевдопараллельно, как «захочет» планировщик.

Код кернела

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

О том, что это кернел говорит слово «global». В эту функцию передаются указатели на массивы данных a, b, c в памяти устройства. Задача кернела — сложить массивы a + b и записать результат в массив c. Все потоки кернела выполняют одинаковые операции сложения и присваивания, но для разных элементов массивов. Для каждого элемента массива в каждом потоке вычисляется свой индекс на основании номера блока, номера потока и размера блока. Разные потоки одновременно складывают разные элементы двух массивов. Это типичная идеология для разработки под CUDA.

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

Код хоста для запуска кернела вызывает вот такую вот функцию: mykernel<<< N_Blocks, N_Threads_Per_Block >>>(a, b, c,);Сюда передается количество блоков (размер грида), количество потоков в блоке (размер блока) и аргументы кернела. Этот синтаксис поддерживается компиляторами CUDA.

Распределенность

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

Если программа хоста выполняется на виртуальной машине, то появляются еще промежуточные этапы передачи данных, поэтому скорость обычно не превышает 4-8 ГБв секунду. Это, конечно, быстрее, чем по локальной сети, но по сравнению со скоростью передачи внутри устройства, это очень медленно. Внутри устройства скорость передачи может быть больше 100 ГБайт/сек. Поэтому если вам удастся написать программу так, что время передачи данных на устройство будет очень маленьким по сравнению со временем обработки, то можно получить очень высокую производительность. Чтобы избежать задержек при передаче данных, необходимо максимально кэшировать данные на хосте и устройстве.

Память

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

Глобальная и локальная память — это относительно медленная память (обычно DDR4 или DDR5). В этой памяти выделяются области константной памяти, текстурной памяти и в зависимости от computing capability — L2-кэш. L1-кэш есть у всех устройств.

Вторая особенность — на GPU объем памяти значительно меньше, чем на хосте. Это один из недостатков, с которыми приходится сталкиваться. Ниже показаны примеры, как можно при написании своего кода указать, какую память вам нужно использовать. Ключевое слово «global» относится к кернелам, т. е. у кернела указывается ключевое слово «global» при написании кода. Если указано ключевое слово «device», то это значит, что эти данные должны находиться в глобальной памяти. Т. е. вы можете явно указать, где хранить ваши данные на GPU. «Constant» означает, что данные будут храниться в константной памяти. Это read-only память, которая кэшируется в L1 кэше. Изменять эти данные нельзя, они задаются на этапе компиляции или на этапе запуска ядра. «Shared» означает, что данные должны храниться в быстрой общей памяти блока. Ниже указаны типичные размеры областей памяти, с которыми приходится иметь дело.

__global__ void mykernel(int)
– Код кернела
__device__ float data;
– Данные в голобальной памяти
__constant__ float data [<=64 Kbytes];
- Константа в кешируемой глобальной памяти
__shared__ float data[<=48 Kbytes];
– Общая память для блока – очень быстрая!
Текстурная память
– Кэшируется в L1 , редко используется для GPGPU
__restrict__ float *pdata
– Только чтение! Кэширование в L2
Включение/выключение кэширования при компиляции
- Кэшировать глобальную память в L1 –Xptxas –dlcm=cg
может быть SEGFAULT!
- Размер L1, общей памяти, блока регистров –maxrregcount=N
- cudaFuncSetCacheConfig Размер кэша/общей памяти
Локальная память – стек в глобальной памяти GPU, медленно
- Маленький объем, кэшируется в L1

Текстурная память для расчетов сейчас уже не так актуальна. В старых версиях GPU текстурную память можно было использовать как быструю кэшируемую память. Сейчас она больше актуальна для обработки 3D-графики. Ключевое слово «restrict» означает, что данные хранятся в L2-кэше в read-only режиме. Если у вас какие-то структуры данных часто используются как read-only, вы можете указать компилятору, чтобы он обращал на это внимание и сгенерировал более эффективный код. Также можно включать и отключать кэширование глобальной памяти в L1-кэше, но это поддерживают не все GPU.

Дело в том, что если у вас GPU, скажем, Tesla с computing capability 3,5 и выше, то там такое кэширование поддерживается. Если же у вас GeForce с той же computing capability 3,5 — то там такого кэширования нет. С L1 кэшированием глобальной памяти нужно быть осторожным. Так как L1-кэш свой для каждого вычислительного процессора GPU, иногда возникают проблемы с общими структурами данных в глобальной памяти при кэшировании в L1. L2-кэширование глобальной памяти работает по-умолчанию, если доступно. На этапе компиляции можно изменять количество регистров, и даже на этапе выполнения можно изменять соотношения между общей памятью, глобальной памятью и L1-кэшем.

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

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

Например, у вас есть готовый массив, вы его на хосте заполнили, потом отобразили на устройство и там используете. Можно отобразить память одного устройства на память другого. Кроме всего прочего, можно также выполнять выделение памяти в самом кернеле. Там возможностей значительно меньше, но все равно есть функция malloc и оператор new. Эти все вещи в зависимости от computing capability и версии CUDA будут немного разными.

Для работы с памятью существует такая подсистема, как Unified Virtual Address Space (UVA). Это программно-аппаратная технология, которая позволяет очень сильно облегчить жизнь программисту. Фактически память хоста и память устройства видится как одна общая память. Что UVA позволяет делать? Она позволяет прозрачно для программиста отображать память с хоста на устройство и с одного устройства на другое. Таким образом, программисту нет необходимости выполнять сложное копирование данных с хоста на устройство и обратно. Можно просто заполнить массив структур, связанный список, или хэш-таблицу на хосте, отобразить ее на устройство и там сразу же использовать. Но есть ряд нюансов.

Первый вариант использования UVA это — zero-copy pinned memory. Это очень быстрый и удобный способ. Единственная проблема: адрес отображенной памяти на устройстве не совпадает с адресом памяти на хосте. Поэтому если в памяти массив данных типа float — то проблем нет. Если в памяти структура данных с указателями — проблемы есть. Как это можно использовать? Объявляем массив на хосте, отображаем этот массив на память устройства, получаем адрес на устройстве и запускаем кернел с этим адресом в качестве параметра.

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

Опять же, жизнь не стоит на месте, и начиная с Nvidia Pascal (computing capability 6) и CUDA-8, поддерживается параллельное использование managed memory кодом хоста и устройства, однако для более старых устройств все остается по старому! Т. е. вы на хосте заполнили массив, запустили кернел, хост подождал, кернел посчитал — хост забрал результаты.

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

Как Nvidia рекомендует использовать managed memory в структурах данных? Определяется класс, в котором есть оператор newи оператор delete, выделяющие и освобождающие память с использованием managed memory.

// class for transparent allocations
struct cuda_mapped {
void *operator new(size_t len) {
void* ptr;
cudaMallocManaged(&ptr, len);
cudaDeviceSynchronize();
return ptr;
}
void operator delete(void *ptr) {
cudaDeviceSynchronize();
cudaFree(p);
}
…
};

// allocated at device and host
struct complicated: public cuda_mapped {
complicated* next;
…
void func(){
next = new complicated;
}
};

Оператор newвызывает API-функцию cudaMallocManaged, оператор deleteвызывает API-функцию cudaFree. После этого все необходимые классы объявляются производными от этого класса, и дальше оператор newи оператор deleteбудут прекрасно работать и прозрачно использовать managed memory (если, конечно, структур данных не слишком много, так как объем managed memory ограничен). Можно с помощью препроцессора (#ifdef __CUDACC__) включать и выключать наследование ваших классов от cuda_mapped в зависимости от того, поддерживает ваш компилятор CUDA или нет. Больше ничего в структурах данных менять не нужно — структуры данных портируются очень просто.

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

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

template <typename T>
int copy_type_to_cuda(T* cuda_to, T* host_from ){
cudaMemcpy(cuda_to,host_from,sizeof(T),cudaMemcpyHostToDevice) ;
}
-----------------------------------------------------------------------
template <typename T>
int copy_vector_to_cuda(T* to, T* from){
typename T::value_type **p = (typename T::value_type**)to;
if(from->size()){
cudaMalloc(to,from->size()*sizeof(typename T::value_type) );
p[1] = p[0]+from->size(); p[2] = p[1];
cudaMemcpy(p[0],from->data(),from->size()*sizeof(typename
T::value_type),cudaMemcpyHostToDevice) ;
} else { p[0]=p[1]=p[2]=NULL;}
}
--------------------------------------------
template <typename T>
int copy_pointers_vector_to_cuda(T* to, T* from){…}

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

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

Стримы и планирование

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

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

Использование CUDA streams — достаточно удобная ведь для того, чтобы получить максимальную производительность вашей программы как на хосте, так и на устройстве. Если у вас была MPI-программа, то вместо MPI send или MPI receive можно использовать CUDA streams. Т. е. отправка данных на устройства, запуск кернела и так далее. Синхронизация между стримами выполняется с помощью ивентов (событий). При синхронном выполнении вы сначала копируете данные на устройство, потом запускаете кернел, а потом копируете данные обратно.

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

Ниже показан пример планировщика, который использовался при портировании программы, ранее написанной в стандарте OpenMP для одновременной работы на GPU и CPU.

#pragma omp parallel for
for(int i=-gpus_num; i<host_data_size; i++){
if(i<0) start_gpu_job(i);
else start_host_job(i)
}
if(gpus_finish_job()) increase_gpu_job();
else increase_host_job();
wait for gpus();

Этот код содержит цикл по всем данным хоста, которые мы хотим обработать. Строка #pragma omp parallel for — это директива компилятора для автораспараллеливания цикла на несколько потоков хоста. В оригинале цикл начинался с нуля и заканчивался общим количеством данных. После портирования цикл начинается с отрицательного числа, которое по модулю равно общему количеству акселераторов в системе и заканчивается количеством данных, которое обрабатывает хост. Для отрицательных значений параметра цикла запускается обработка данных на GPU, для положительных — вычислительный поток хоста. Операции выполняются параллельно. После завершения цикла проверяется, какая работа закончилась раньше — устройств или хоста, и соответственно корректируется объем данных, с которыми работают хост и каждое из устройств.

Несколько акселераторов

Нет ничего сложного в использовании нескольких GPU. Нужно определить, сколько у вас устройств, какие их характеристики и годятся ли они для вашей задачи. Это можно сделать с помощью функций cudaGetDeviceCountи cudaGetDevice. Перед запуском операций на какое-либо устройство вызывается функция cudaSetDevice, в которую передается номер устройства. Главное, это нужно не забывать делать перед созданием стримов, перед выделением памяти, перед запуском кернела и т. д. Компиляторы CUDA дают возможность сгенерировать код для устройств с различными значениями computing capability и скомпоновать этот код в одной программе, которая будет работать с разными устройствами. Главное, не забыть указать соответствующие опции компилятора.

Компиляторы и библиотеки

На чем и как писать код? В фреймворке CUDA поддерживаются языки C и C++. Некоторые коммерческие компиляторы, как от PGI или от IBM, поддерживают язык Fortran. При отсутствии компилятора, который поддерживает написание кернелов на языке Fortran, можно написать кернел и его вызов на C или C++ и скомпоновать с программой на языке Fortran. Код, который компилируется для устройства и хоста, обозначается ключевыми словами __host__ и __device__ соответственно. Можно с помощью препроцессора определять разный код, который будет компилироваться или только для хоста, или только для устройства.

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

Эффективность

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

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

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

Живой пример

В качестве примера кода, который был успешно портирован с процессоров общего назначения на GPU, можно привести программу авторов для расчета динамики сложных биологических нейросетей от сотен тысяч до сотен миллионов нейронов. С помощью GPU и этой программы впервые удалось промоделировать динамику трехмерных систем в модели Курамото-Сакагучи из примерно 100 000 000 нейронов и открыть новые типы состояний больших связанных систем [Link 1, Link 2].

Графический акселератор GeFroce GT 640, достаточно недорогое устройство, для этой задачи показал производительность примерно равную производительности 12-ядерноговычислительного узла с процессорами Intel Xeon 2620. Примерно такую же производительность показали и более новые энергоэффективные акселераторы Quadro K620. Производительность Tesla K40 (не новый, но дорогой и производительный акселератор) соответствует примерно 50 таким процессорным ядрам, то есть этот акселератор заменяет кластер из 4-хтаких узлов [Link 1].

Для портированного кода удалось достичь примерно 60% пиковой производительности Tesla (порядка 600 гигафлопсов). Для GPU это очень неплохо. На CPU программа использовала 75-80%пиковой производительности вычислительного узла.

Выводы

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

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

У випуску: розпізнавання карт з Python, FB використовує Python 3.6.3, генератор ботів для ігор.

Новини

Python is the 2nd most popular language on GitHub — після JS.

Python overtakes R, becomes the leader in Data Science, Machine Learning platforms — порівняння в картинках і графіках популярності R vs Python в ML.

Universities finally realize that Java is a bad introductory programming language — від Java до JS і до Python як мови викладання у вузах США.

SK-CSIRT identified malicious software libraries in the official Python package repository, PyPI — служба безпеки Словакії виявила malware в PyPi.

Lucas Langa — всі машини на Facebook уже використовують Python 3.6.3.

Нові релізи

Matplotlib 2.1

Pyinstaller 3.3 released — додана підтримка Python 3.6.

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

OpenCV-Playing-Card-Detector — визначення карт в реальному часі за допомогою PiCamera та Python. Відео.

Google Facets — тул від Google для візуалізації та аналізу даних.

SerpentAI — генератор ботів для ігор!!!

Acg — генератор API клієнтів на основі існуючого API. Почитати можна на Хабрі.

Requests-threads — requests на twisted стероїдах від Kenneth Reitz.

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

PEP’s

PEP 553 — Built-in breakpoint()— нова ф-я debugger() навіяна JS(sic!).

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

The decorators they won’t tell you about — міфи про декоратори в Python.

Non Trivial Python Exercises — маєте задачки для лайв кодінга на співбесідах.

Let me introduce: __slots__— багато кому має бути цікаво про слоти.

A Complete Beginner’s Guide to Django — Part 1

Spiral Barcode Generator: Rick and Morty Episode 101 — згенеровані баркоди по серії з РМ за мотивами „фреймворка” для написання сценаріїв від Dan Harmon. Тутможна читнути трохи теорії. Генеруйте новий сезон Ріка і Морті!

I’m too stupid for AsyncIO — не перший розробник, для якого asyncio не є очевидним чи зрозумілим. Резюмуючи слова автора, його ж текстом " You can’t document what a taco is by explaining it is a taco".

JSON Serialization in Python using serpy — бложик Twillio розповідає про лібу серіалізації. Чому пишуть — бо в них є бенчмарки.

Exploiting misuse of Python’s „pickle” — доки Python попереджають, та не всі на це зважають.

Відео

Raymond Hettinger, Keynote on Concurrency, PyBay 2017 — Реймонд. І цього достатньо.

The Fun of Reinvention — знову б написав: „Девід, і цього достатньо” :) David Beazley про нові фічі в Python 3.6.

The Other Async (Threads + Async = ❤️)— David Beazley on threads and asyncio.

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

У випуску: що нового в PHP 7.2, вразливість Joomla! 3.7.5, Hacktoberfest — долучайтеся до PHP-проектів на GitHub.

Статті

What’s New in PHP 7.2

Stop the pain, upgrade to PHP 7

From PHP to JavaScript with Node.js — I have been a PHP developer for more than 10 years and I recently moved to the JS full stack world...

Joomla! 3.7.5 — Takeover in 20 Seconds with LDAP Injection

Hacktoberfest! Get a free tee for contributing to open source PHP projects.

What you need to know about environment variables with PHP

PHP 7.1 vs 7.2 Benchmarks (with Docker and Symfony Flex)

Partitioning for concurrency in synchronous business processes

The global PHP community continues to toxify itself, and we need to halt it for the sake of our peers

Event-Driven Architecture

Релізи

PHP 7.2.0 Release Candidate 3 Released

PHP 7.1 is now available for AWS Elastic Beanstalk

PHP 7.1 for Google App Engine is generally available

Two fantastic PHP testing tools (Kahlan and Phony) just got new major versions. Even better, they now have first-class integration!

BotMan 2.0 PHP Chatbot Framework

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

Discover files in need of refactoring

PHP library for working with recurrence rules (RRULE); meant to help with recurring calendar events.

A simple & straight-to-the-point PHP profiling extension

Message queue packages for PHP, Symfony, Laravel, Magento

Різне

Команда Pizdata Inc. перезапустила свій англомовний канал. Постять про tech, IT, science, humor and your mom. Sorry, not humor. Приєднуйтесь! Але тільки якщо ви не заходите в канали лише для того, щоб почистити сповіщення.

Книгапро асинхроне програмування на PHP.

I hate programming — цікавий тред на Редіті про програмування і кодинг.

What’s your take on older developers?— ще один популярний тред на Редіті про программістів 40+ років.

Gist of US States as PHP arrays. Many variations given from different developers.

90’s — We will use AI to cure cancer in the future
2K17:

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

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

Николай Савин — в октябре прошлого года пришел в стартап Competeraна позицию Head of Products. Николай отвечает за продуктовую стратегию компании: определяет, какие потребности есть у пользователей, как их реализовать и в какой очередности.

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

Возраст и опыт: 30 лет, 9 лет работает в IT.
Модель смартфона: Samsung S8.
Модель ноутбука: MacBook Pro.

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

В зависимости от времени года мое расписание меняется: я не люблю холод и темноту. Летом приезжаю на работу очень рано, иногда даже в 6-7 утра.Зимой — позже. Сейчас начинаю рабочий день в 10-11.

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

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

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

Главный девайс — ноутбук. Прежде чем перейти на Mac, я много лет пользовался Chromebook. Это меня приучило, что практически все — в вебе. Так что если вдруг нет интернета, то мне и заняться обычно нечем :) В этом случае я переключаюсь на телефон или просто читаю.

Телефон позволяет быстро между встречами посмотреть, что важное «упало». Если что-то срочное, можно быстро ответить.

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

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

Мой воркспейс — удобный стул, стол и ноутбук.

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

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

Основной рабочий инструмент — Jira: к ней мы обращаемся раз в неделю при планировании спринта. Чтобы распределять тот хаос, который прилетает от всех и вся, использую Trello.

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

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

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

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

Иногда использую Pomodoro, если надо какой-то отрезок времени ни на что не отвлекаться.

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

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

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

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

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

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

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

Я работаю большую часть времени, которую не сплю :) Просыпаюсь с мыслями: «Так, что у меня сегодня?», засыпаю примерно с теми же. В общем работаю в среднем 50-60 часов.Иногда бывают недели, когда по 40, иногда и все 80.

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

— А отпуск часто берете?

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

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

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

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

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

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

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

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

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

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

Из художественного — цикл «Old man’s war» Джона Скальци. Я уже давно фанат научной фантастики. Обычно читаю запоями, поэтому не так часто могу выделить на это время. Выбирая книгу, просматриваю список лауреатов премии Хьюго.

По работе последней была «Jobs-to-be-Done» — электронная книга по продуктовому менеджменту от Intercom. Это несколько другой взгляд на пользователей и их задачи. К примеру, как предотвратить такие казусы, как надпись на праздничном торте: «Джимми, мы тебя любим! (аллергия на орехи)». Откуда эта надпись появилась? На каком-то этапе кто-то передал текст, но не передал понимание контекста. Следуя методологии Jobs-to-be-Done, мы начинаем с контекста.

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

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

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

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

— За что любите и не любите свою работу?

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

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

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

Покупать биткоины :)

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

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

Хочу и дальше развиваться вместе с компанией. Достигать хороших продаж. Если не IPO, то как минимум чего-то такого, о чем напишет Forbes :)

Продовжуючи тему релокацій на DOU, вирішив внести частину іспанського тепла в холодну українську осінь. Але спочатку коротко про мене: навчався у Львівській політехніці на кафедрі оптотехніки, «увійшов в ІТ» у вересні 2015 після закінчення літнього стажування у компанії OSF Global. В основному працюю на фронтенді, але стараюсь себе цим не обмежувати. Мотивів переїзду я ще досі не осягнув сам на 100 відсотків: можливо, хотілося подивитись на світ, можливо, захотілося кращого життя (не з фінансової точки зору). Одним словом, після кліку «Send CV» на LinkedIn і почалася ця історія.

Я знайшов позицію Junior Frontend Developer у мадридському офісі Zooplus. Це німецька компанія з офісами в європейських містах. Основний її бізнес — продаж товарів для тварин онлайн, тобто типовий e-commerce. У вакансії вказувалося, що кандидат може мати малий досвід роботи — якраз такий, як у мене на той час був (6 місяців і кілька реалізованих проектів). На той час я знав, як писати CSS, JavaScript, але не мав уявлення, як влаштована сфера IT, які види компаній бувають, що таке продукт, а що аутсорсинг. Тому те, що мене взяли на роботу, вважаю великою удачею.

Переїзд

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

Співбесіди розпочалися у жовтні 2015-го,а до роботи я приступив у середині лютого наступного року. Першою була технічна співбесіда скайпом із Senior Frontend Developer з центрального офісу в Мюнхені. Через кілька днів після цього прийшло тестове завдання. Затим запросили на співбесіду в Мадрид. Візу на цьому етапі слід було оформлювати самостійно (у мене вже була відкрита туристична). В іспанському офісі розповіли, що компанія планує відкривати IT-відділ у Мадриді (до того у цьому місті вже кілька років функціонував відділ продажів). Заодно всі планували переїхати в новий офіс, ближче до центру.

Також відбувалася третя співбесіда з офіс-менеджером і кількома тамтешніми девелоперами. Вона складалася з двох частин: аналізу виконаного мною завдання і ближчого знайомства. На останній співбесіді у центральному офісі в Мюнхені спілкувався з HR і ще раз із Senior Frontend Developer, яка проводила інтерв’ю спочатку. Через тиждень прийшов офер. Після оферу роботодавець подав запит у Міністерство праці, паралельно із тим я мав подати у посольство копію оферу. Резиденція видається на один рік і поновлюється, поки людина працює, не порушує закон і платить податки :)

Через кілька тижнів після оферу мав усе на руках, ще через кілька днів був в Іспанії.

Житло

В офер входила невелика разова виплата грошей — 2000 євро. Поки жив 2 місяці у Німеччині (нижче детальніше), шукав квартиру в оренду в Іспанії. Знайшов досить швидко, у нецентральному районі. Утім до роботи їхати — 25 хвилин (2 зупинки громадським транспортом), що для 4-мільйонногоміста не є великою відстанню. За місячну оренду сплачую 550 євро + 70 за компослуги + 40 — інтернет. Вартість житла в центрі коливається від 750 євро до 3 тисяч.

Організація роботи

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

Через три місяці нам повідомили, що всіх розділять на три команди. Я вирішив піти в ту, яка допомагає менеджерам із онлайн-маркетингу, працює незалежно від основного магазину, не причетна до legacy code і має цілковиту свободу. Обрав цю команду, бо було страшно цікаво навчитися робити нові круті фреймворки. З того часу попрацював у кількох командах над різними продуктами, трохи було і легасі, але не страшно :) Тепер я один у своїй команді на frontend (і приблизно 30% часу працюю на backend). З нами є ще три backend-розробники і один тестер.

Графік роботи більш-менш гнучкий, працюємо по scrum. З командою домовилися, що з 10:00 до 16:00 нам треба бути разом в офісі. Якщо потрібен день-два роботи з дому, то без проблем можна домовитися. Бувають open weekends. Умови для роботи хороші ще й тим, що практично нема стресу. Чітко знаємо, що маємо зробити впродовж двох тижнів. Ризики невиконання цих робіт зведені до мінімуму. Нема такого, що останній день, а нічого не готове. Такі ситуації траплялися хіба 2-3рази за майже два роки мого перебування у компанії.

До 28 днів оплачуваної відпустки додаються два дні вихідних напередодні Нового року і Різдва (якщо дати припадають на робочі дні) +12 днів вихідних у державні свята. Їх можемо святкувати офісом. Щороку відзначають річницю компанії — торік офісом 2 дні провели в Німеччині.

IT-ринок

Пропозицій тут значно більше, ніж претендентів на вакансію. Щотижня отримую до 10 повідомлень від іспанських аутсорсингових компаній на LinkedIn. 90% галузі складає аутсорсинг, решту — продукт. Мені комфортно працювати з продуктом, бо чув, як працюють в аутсорсингу — з 9:00 до 21:00. Тобто балансу робота/життя як такого немає. Плюс, із мого невеликого досвіду, над продуктом працювати цікавіше: отримуєш зворотний зв’язок від користувачів, покращив, випустив реліз. В аутсорсі про такий підхід я ще не чув.

Зарплати

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

У junior-розробників зарплати стартують із 16 тисяч євро/рік. Після вирахування податків, які, втім, перекривають бонусні виплати, виходить непогана сума. Вистачає на житло, їжу, подорожі, одяг. Навіть вдається відкласти. Кожних півроку відбувається підсумкова розмова з локальним delivery-менеджером. Аналізуємо, чого вдалося досягти за цей час, які технології впровадити, що хотів би вдосконалити, як можна автоматизувати роботи для відділів продажів, онлайн-маркетингу. Результати зафіксовують, залежно від них підвищують зарплату. У контракті є пункт про щорічний 10-відсотковийбонус від річної зарплати. Його виплачують двома траншами: 30% у липні та 70% — у лютому. Бонус може бути і вищим, залежно від продажів (цього року, наприклад, він був не 10%, а 11%).

Усі відрахування здійснює фірма. Раз у місяць мені приходить платіжка, де все розписано. Податок складає 21% від зарплати (яка в мене зараз), шкала прогресивна. Раз у рік треба подати підсумкову декларацію про доходи від зарплатні і бізнесів, якщо такі є. Для цього слід зайти на сайт і заповнити декілька пунктів. Багато граф уже заповнені завдяки даним із єдиної системи податків, мені залишається поставити кілька галочок. Це нескладно, спершу тільки виникали труднощі з перекладом податкових термінів іспанською. Хоча для фрілансера або бізнесмена цей процес може бути складнішим.

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

Транспорт

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

Метро має 13 ліній, але зорієнтуватися в них легко: на кожній станції є вказівки щодо розташування. Зранку потяги ходять кожні три-чотири хвилини, після півночі — кожних десять хвилин. Лінії метрополітену відчинені до 1:30 ночі.

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

Для пасажирів віком до 26 років тут діє єдиний проїзний на всі види транспорту. Він коштує 20 євро/місяць, що, порівняно з іншими європейськими містами, є смішною ціною. Інші проїзні відрізняються залежно від зони. Усього є 8 зон: 6 у провінції Madridі, 2 — у Castilla-La Mancha, яка більш відома своїм містом Толедо, звідки багато людей їздять на роботу в Мадрид. Схема проста: чим більше зон включає у себе квиток/проїзний, тим більше й платиш. Готуйте від 55 до 100 євро :)

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

Щодо таксі: є Uber, Mytaxi і їхні локальні аналоги. Тарифи досить адекватні: приміром, дістатися до аеропорту можна за 25-30 євро.Одного разу їхав із іншого кінця міста о 4 ранку всього за 13 євро.

Медицина

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

Мова

Їхав із нульовим запасом іспанської. Офіційна мова компанії — англійська. Щоб влаштуватися на роботу, треба володіти нею як мінімум на рівні B2. Спочатку розмовляв з людьми англійською. Але всі співробітники з Іспанії. Те, що вони між собою говорили іспанською, дуже мотивувало вчити мову. Три місяці походив на курси, щоб вивчити граматику, + щодня міг спілкуватися по 8 годин в офісі. Так за 7 місяців опанував мову на достатньому рівні. Є слова, значення яких знаю лише англійською, але побудувати речення і порозумітися можу. Найбільше допомогло середовище.

Менталітет

Іспанці — життєрадісна, пофігістична у доброму розумінні цього слова нація. Вони до всього ставляться з гумором, усе весело, take it easy. Рутинним для них є такий графік: робота, дім, спортзал, гуляння до 1-2 ночі.До іноземців ставляться позитивно, расизму або ксенофобії я не помічав, можливо, тому що перебуваю в хорошому середовищі. Про Україну, окрім останніх подій, знають мало.

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

Іспанці люблять подорожувати. Якщо у п’ятницю після 16:00 з центру прямувати до вокзалу, то можна побачити багато людей із валізами, які виїжджають в село до родичів або на пляж, якщо це вже травень. Коли я виїжджав за межі країни, десь у Німеччину чи Нідерланди, чув багато іспанської мови.

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

Каталонія

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

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

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

Друзі і відпочинок

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

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

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

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

Погода

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

Сієста

Для офісних працівників це радше міф: економіка слабка, яка сієста? Але загалом культура сієсти в Іспанії є. З травня до жовтня, коли спека, центр Мадрида в обід може бути порожнім. Люди сидять удома, дивляться телевізори, на вулицю виходять, коли температура спаде.

Тут чимало китайських магазинчиків, у яких продається все, що спадає на думку. Держави підписали угоду, відповідно до якої бізнес китайців в Іспанії на перші 5 років звільнений від податків. Але й ці універсальні крамниці зачинені з 13:00 до 17:00. Деякі ресторани відчиняються о першій дня, працюють до 16:00, тоді знову зачиняються до 20:00, після чого працюють ще до 2-їночі.

Висновки

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

Ще один плюс — з іспанською мовою можна їздити у Південну Америку, де знання мови дає великі переваги для туристів.

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

Я не порадник для людей, які мають сім’ї. Знаю лише, що при народженні дитини жінкам надають 6 місяців оплачуваної відпустки, чоловікам — 2. До досягнення певного віку на дитину виплачують 200 євро соціальної допомоги щомісяця.

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

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

Дякую за допомогу в оформленні статті Ярославі Тимощук.

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

Меня зовут Любовь Ждан, я руководитель проекта GladPet — сервиса для пристройства и помощи бездомным животным. При запуске в 2015 году одесской краудфандинговой платформы «Мой город», одной из первых инициатив на ней был проект с замысловатым названием «Системное решение проблемы бездомных животных в Одессе».

Я пришла в команду «Мой город» чуть позже, в октябре 2015 года, — сразу на вакансию менеджера этого проекта и вела его со старта. Фразы «с детства люблю животных» и «кто из нас не мечтал открыть приют, чтобы сделать счастливыми всех бездомных животных» — банальны, но это про меня :) Это сейчас, через 2 года работы в этом направлении, я понимаю, что просто приют для животных проблему не решит. Нужен комплексный и системный подход. Так, мы создали GladPet.

Подготовка концепции ресурса заняла около полугода. К весне 2016 года техническое задание было готово.

Костяк команды проекта GladPet был сформирован из участников команды платформы «Мой город»: я, как руководитель проекта GladPet и по совместительству спикер платформы «Мой город»; Александр Шкарбалюк — web-разработчик в обоих проектах; Евгений Кузьмичев — руководитель платформы «Мой город», занимающийся маркетингом проекта. С дизайном сайта нам помогала Катрин Хиора, она принимала участие в проекте как волонтер. Поэтому были некоторые задержки из-за нагрузки на её основной работе.

В октябре 2016 года запустили сайт gladpet.org.

Слева направо: Евгений Кузьмичев (маркетолог), Любовь Ждан (менеджер проекта), Александр Шкарбалюк (разработчик).
Здесь, к сожалению, нет еще нашего web-дизайнера — Катрин Хиора, не так просто ее поймать для фото :)

Идея

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

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

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

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

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

Попутно ресурс пропагандирует цивилизованное отношение человека к животным. В рамках GladPet был успешно реализован пилотный проект «Биоэтика, или Гуманное отношение человека к животным». В 10 школах города были проведены более 200 интерактивных уроков для школьников о правилах ухода и содержания домашних питомцев.

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

Реализация

Изначально планировалась простая система: список пользователей и список приютов. Приюты размещают животных для пристройства (адопции).

Серверная часть сайта написана на PHP, PostgreSQL в качестве базы данных. Клиентскую часть реализовали на фреймворке от Google — Angular2.

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

Сейчас ресурс позволяет:

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

До сих пор концепция проекта осталась практически неизменной. Были сделаны незначительные добавления:

• размещать можно только кошек и собак, но в системе запланирована возможность добавлять и другие виды животных с целью их регистрации в базе animal-id.info;
• реализована возможность размещать питомца от частного лица, не только приюта;
• запущен блог по тематике ресурса.

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

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

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

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

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

Основные достижения проекта за год работы в Одессе (на текущий момент):

• 295 пристроенных питомца;
• 3200 активных подписчиков на странице проекта в Facebook;
• 1500 активных пользователей сайта;
• 38 000 пользователей, которые посетили ресурс с момента запуска;
• 21 организация, которые помогают животным;
• более 25 выступлений в СМИ по проекту;
• более 60 публикаций в прессе.

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

Планы:

• масштабирование на другие города Украины;
• подключение к сервису MyID, который мы разрабатываем в рамках проектов «Мой город»;
• подключить wish list приюта: возможность выбрать, купить и заказать доставку необходимых приюту зоотоваров через интернет-магазин;
• подключить ветеринарные клиники и кинологические клубы, которые будут предоставлять льготные услуги для бездомных животных, а также для питомцев, которых взяли в приютах.

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

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

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

Школа програмування Ш++

Напрям:курси Front-end (Angular, React), Node.js, PHP (Laravel), iOS/Android development, Java, Python, Golang, Linux.
Місто:Кропивницький.
Дедлайн подачі заявок:немає.

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

• Діти від 7-18років — усі охочі, без обмежень.
• Дорослим від 18 — скласти вступний іспит; потрібно мати базові навички програмування (змінні, цикли, масиви, алгоритми), знання англійської мови, навички сліпого набору.

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

• Гарвардський CS50 за підтримки brainbasket.org (мова С+ основи веб-розробки). Формат — дві лекції в тиждень.
• Стенфордський адаптований CS106A + CS106B (мова Java). Формат — p2p learning, кілька зустрічей на тиждень.

EPAM

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

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

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

Genesis

Напрям:ІТ-школа для тих, хто хоче працювати в продуктовому ІТ. Після школи випускники зможуть працювати на позиціях Product Manager, Analyst, Data Analyst, Marketing Manager, User Acquisition Analyst, Affiliate Manager.
Місто:Київ.
Дедлайн подачі заявок: 5 листопада.

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

• від 2 років досвіду роботи (ІТ, Big 4, телеком, фінанси, аудит, медіа, аналітика і т. д.);
• технічна або економічна освіта;
• знання математики — великий плюс;
• англійська на рівні не нижче Upper-Intermediate.

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

• до 5 листопада подати заявку на сайті;
• з 6 жовтня по 12 листопада пройти онлайн-тест;
• з 13 по 18 листопада розповісти про себе трохи більше;
• з 20 по 26 листопада вирішити завдання в офісі Genesis;
• і з 27 листопада по 20 грудня проявити себе на співбесіді.

Умови:двічі на тиждень з 19:00 по 21:00. Лекції та домашні завдання по кожному модулю, всього 8 модулів.
Деталі:на сайті.

GlobalLogic

Напрям:курси JavaScript (Львів), С++, .NET/JS (Львів, Харків).
Місто:Львів, Харків.
Дедлайн подачі заявок: 13 листопада (Львів).

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

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

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

JavaScript (Львів)
Пройдіть онлайн-тестування на сайті GL Test Benchу розділі Tests > JavaScript оберіть [BaseCamp] JS Test. Якщо результат тесту буде 60% та вище, заповніть форму реєстрації. Претендентів з найкращими результатами тестів та CV запросять для проходження відбіркового завдання та інтерв’ю в офісі.

С++, .NET/JS
Львів: пройдіть тест на GL Test Bench> Tests > GL Lviv BaseCamp C++, заповніть форму реєстрації. Апліканти із найкращими результатами тестування будуть запрошені на другий етап відбору — вирішення практичних задач в офісі GlobalLogic.

Харків: зареєструйтеся, а потім успішно пройдіть вступне тестування. Претендентів із найкращими результатами тестів запросять для проходження інтерв’ю, за підсумком яких буде відібрано 12 учасників курсів GL BaseCamp.

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

Харків: тривалість — 3 місяці (3 рази на тиждень у вечірній час).

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

Infopulse

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

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

• відмінні теоретичні знання C++ ;
• управління пам’яттю, алгоритмами, стандартними бібліотеками (STL, boost тощо), шаблони;
• проект, написаний за допомогою C++ на GitHub, або приклад проекту, який показує навички та знання;
• вища технічна освіта (бакалавр, магістр);
• англійська мова — вище середнього рівня;
• досвід роботи з Linux.

Як потрапити:написати та надіслати резюме, разом з мотиваційним листом на електронну адресу Alina.Hapyeyeva@infopulse.com, пройти груповий відбір та технічне тестування.

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

InventorSoft

Напрям: Java.
Місто:Чернівці.
Дедлайн подачі заявок:до 25 листопада.

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

• базові знання Java;
• буде плюсом знання HTML, CSS, JavaScript, SQL.

Як потрапити:заповнити форму, пройти співбесіду.
Умови:Тривалість курсів — 3 місяці, гнучкий розклад, робоче місце в офісі компанії. Курс складається з теоретичної та практичної частини. Теоретична частина включає в себе лекції та самостійне навчання, практична — розробку веб-додатка під наглядом менторів.
Деталі:надсилайте запитання на пошту julia.shustova@inventorsoft.co.

JetThoughts

Напрям: Ruby on Rails.
Місто:Львів.
Дедлайн подачі заявок:немає.

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

• Ruby / Ruby on Rails;
• JavaScript, HTML, CSS;
• GitHub account з будь-яким проектом на Ruby;
• великим плюсом буде знання React та TDD.

Як потрапити:прислати резюме та приклади робіт своїх проектів на електронну адресу cv@jetthoughts.com, пройти співбесіду.

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

Intersog

Напрям: Data Analysis Programmer, QA.
Місто:Київ (Data Analyst), Одеса (Data Analyst, QA).
Дедлайн подачі заявок:немає.

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

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

Luxoft

Напрям:інтернатура С++, Java, Analyst, DevOps.
Місто:Київ (C++, Analyst), Одеса (C++), Дніпро (Java).
Дедлайн подачі заявок:немає.

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

Як потрапити:відгукнутись на вакансію на сайті.

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

Samsung R&D Institute Ukraine

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

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

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

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

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

Sigma Software

Напрям:інтернатура Java, С++/.NET, PM, Software testing, Embedded development.
Місто:Київ, Львів, Харів.
Дедлайн подачі заявок:немає.

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

Як потрапити:заповнити форму реєстраціїта пройти співбесіду.

Умови:Інтерни навчаються за індивідуальним планом на реальних проектах під керівницвом менторів протягом 3-6місяців повний робочий день в офісі компанії.
Деталі:на сайті.

Ubisoft

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

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

• знання програмування на C/C++;
• розуміння ООП;
• Intermediate English;
• знання паттернів проектування (буде плюсом);
• знання бібліотеки 3D math (буде плюсом);
• досвід роботи принаймні з одною IDE (буде плюсом).

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

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

Riff Point

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

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

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

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

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

3Shape Ukraine

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

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

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

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

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

BotsCrew

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

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

• гарне знання ООП;
• Java Core;
• Relational Database;
• REST;
• Hibernate/JPA;
• англійська мова — вище середнього рівня;
• управління пам’яттю, алгоритмами, стандартними бібліотеками (STL, boost тощо), шаблони.

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

Умови:все обговорюється в індивідуальному порядку.
Деталі:на сайті.

Diligences

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

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

• базові знання Back-end (Golang, JavaScript);
• базове знання Front-end (HTML, CSS, JS);
• повна або незакінчена вища освіта в області комп’ютерних наук або суміжних;
• English level — Upper Intermediate;

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

GlobalLogic

Напрям:робота QA, JS/UI, Networking / Embedded Linux, С, С++, .Net.
Місто:Харків, Львів, Київ, Миколаїв.
Дедлайн подачі заявок:немає.

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

• для позицій Software engineers — базові знання та навички програмування;
• для позицій QA — базові знання теорії тестування;
• англійська рівня Intermediate і вище;
• деталі — в описі кожної позиції на сайті.

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

Sombra

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

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

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

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

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

QATestLab

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

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

Умови:викладачi курсу — QAEngineers компанії QA TestLab. Формат навчання: онлайн. Тривалість курсу — 4 тижні. Онлайн-курс «Основи тестування програмного забезпечення» включає в себе: 7 лекцій, що проводяться через систему GoToWebinar двічі на тиждень (з 18:00 до 20:00), практичні домашні завдання та підсумковий іспит.
Деталі:на сайті, запитання надсилати на webinar@qatestlab.net, резюме — на jobs@qa-testlab.com.