Quantcast
Channel: Найцікавіше на DOU
Viewing all 7751 articles
Browse latest View live

DOU Проектор: EMtracker - устройство для распознавания стрессовых состояний у близких людей

0
0

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

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

Сейчас наш основной продукт, «лебединая песня», — устройство для распознавания стрессовых состояний у близких людей (не люблю слово «seniors») под названием EMtracker.

Идея

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

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

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

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

В итоге появилась технология, которая снимает реографию с запястья для определения уровня стресса — Emotion Technology. EMtracker определяет нестабильные состояния пользователя за счёт считывания медицинских данных. Он состоит из браслета с датчиками и программного обеспечения. Датчики внутри браслета фиксируют сигналы и отправляют на телефон. ПО включает в себя сервер, приложения для Android и iOS, веб-интерфейс для корпоративного использования.

Реализация

На момент старта проекта у компании FORCE было две технологии: Motion Technology (распознавание жестов) и Emotion Technology (распознавание стресса), акцент сделали на второй. Выбор был не из легких, но так появился флагманский продукт EMtracker.

EMtracker — первый трекер, который решает задачи в комплексе: определение местоположения, оповещение об опасности для здоровья, напоминание о звонке/приеме лекарств, измерение % кислорода в крови, частоты дыхания, медицинских данных и стресса, как совокупность параметров. Суть Emotion Technology в распознании таких видов стресса:

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

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

  • Акселометр (уникальный алгоритм распознавания падения);
  • Датчик реограммы (точное измерение HRV c запястья);
  • Датчик биоимпедансной спектроскопии (измерение уровня стресса);
  • PPG (оптическая технология для определения колебаний потока крови в сосудах).

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

На этом трудности не закончились. Нужно было не только сделать новый продукт, но и справиться с этим лучше существующих на рынке косвенных аналогов. После многочисленных проб и ошибок у нас это получилось. Исследования в лаборатории FORCE показали, что измерение вариабельности сердечного ритма и обнаружение пульса у EMtracker лучше, чем у Samsung SimBand и Samsung Gear S3 на тёмной и татуированной коже. Также собственный встроенный алгоритм падения трекера EMtracker достигает на 25% лучших результатов, чем браслет Philips Lifeline.

Получился качественный продукт, идет работа с социальными сетями. Но и это не конец задач по продвижению. В директ Инстаграма компании FORCE написал Артур Фролов, председатель совета в компании Universaim, который порекомендовал специалиста в сфере пиара — Алесю Крылач. Совместно с новым PR-специалистом компании разработан сайт, подробно рассказывающий о текущем прогрессе компании и стадиях проекта. В итоге получился ресурс, положительно о котором отзывались и Билл Демас, CEO компании Shopkick Inc, и наши «одноклассники» в акселерационной программе Alchemist.

Результаты

Вышеописанная работа над продуктом дала возможность получить предложение сразу от двух всемирно признанных акселераторов: лучший в мире акселератор для В2В компаний Alchemist и первый в сфере digital health — Vertical. Стартап FORCE был выбран среди 1200 компаний-претендентов на место. Это первый украинский проект, прошедший в стенфордский акселератор. Отбор в Vertical проходит 4% команд, подавших заявки, которые интересны ведущим здравоохранительным компаниям Финляндии.

У компании FORCE соглашение с австралийской аналитической компанией PsyQuation и медицинской компанией Into-Sana на покупку 200 и 300 устройств соответственно. Также ведутся переговоры с рядом финских компаний, таких как Fazer и Suunto. Кроме того, есть предпродажи на сайте и через Kickstarter.

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

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


Зачем возвращаться: плюсы жизни в Украине

0
0

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

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

Разумеется, приведённые в этой статье причины могут быть совершенно нерелевантными для вас лично — и это нормально, потому что стимулы у всех разные. Объясню на примере книжки «Приключения Буратино». Сначала наша жизнь похожа на приключения Буратино — сбежать из дома, заработать свои первые 4 сольдо и попробовать устроить революцию кукол. Потом наступает гедонизм — нас начинают больше интересовать Мальвины (девочки с синими волосами) и прочие радости жизни. И уже к зрелости возникает резонный вопрос — а как доктор кукольных наук синьор Карабас-Барабас поднял свой бизнес, и как он управлялся со своим балаганом (ох, не зря у него плётка была!).

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

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

Возвращение

Первым делом при переезде в Украину нужно было найти работу.

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

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

Больше всего меня накрыло при собеседовании в SoftServe: я подавался на высокую позицию на стыке менеджмента и РНР-девелопмента, а ощущал себя как на экзамене в университете по основам языков программирования. «Чем отличается Software Design от Software Architecture? Как расшифровывается аббревиатура SOLID? Перечислите все виды полиморфизма?». Меня накрыло потому, что я был СТО в датском стартапе, где у нас было 3 уровня тестов и реализованный Domain Driven Design, я летал сетапить команды девелоперов в обеих странах, ну и наша компания из 10 человек пару лет была самым большим клиентом Google Denmark. Каждую букву из слова «SOLID» мы использовали на практике, но расшифровывать аббревиатуры и именовать виды полиморфизма — seriously? (Тем более, что в РНР реализован только один вид полиморфизма). Я не понял прикола. #меняНеВзяли

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

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

Но потом эйфория прошла, и «нас властно обступил хаос мелочей, целое море элементарнейших требований здравого смысла, из которых каждое способно было вдребезги разбить всю нашу [...] науку» © Макаренко. Не мне вам рассказывать, что такое украинский быт. Тут ты понимаешь, почему 30% украинцев живут в Дании, Италии, Канаде — а остальные 70% живут в стрессе.

Ведь Дания даже в бытовом смысле находится в 5 технологическом укладе (то есть в «эпохе компьютеров»), а Украина — в третьем (в «эпохе угля»). В Дании метро без водителя, а у нас в поезде все твои достижения в туалете выплёскиваются прямо на рельсы. Пока Запад борется с раком и летит на Марс, мы ещё лужи не одолели.

А не страшно?

«А не страшно возвращаться в страну, где идёт война?» — самый частый вопрос, который нам задавали. Страшно. Когда сидишь исключительно на новостной диете с 2014 года, у картины мира сильно заваливается горизонт: с Востока летят угрозы взять Киев за три дня, Боинги падают, Мариуполь трясёт, в Мукачево «стреляют сигареты».

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

Есть и ещё более крупномасштабные плюсы нынешней Украины.

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

Украину «не уронили» западные компании и финансовые организации — в том числе Джордж Сорос, купивший долю Ciklum. Медленно, но начинает расти экономика. Когда мы планировали переезд в 2015, уже стоял большой безвизг (в который, впрочем, никто тогда не верил, и крутил нам у виска). С нашим безвизом прелесть датского гражданства сильно меркнет — Западная Европа становится просто большим Дальним Закарпатьем.

Далее, Фейсбуки и Ютубы стали реальным социальным оружием. Уже успел убедиться, как быстро при ярком освещении (в прессе) разбегаются тараканы.

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

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

Главная проблема Украины — не война, которая когда-нибудь закончится, а нечто посерьёзнее (интрига!).

Фото — Сергей Матюшенко

Украинское IT

Что сразу бросается в глаза в профессиональном плане после приезда?

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

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

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

Весьма показательна история создания программы Skype:

  1. 2 скандинава рождают идею;
  2. датский инвестор вкладывает в неё деньги;
  3. программную реализацию заказывают у эстонской компании;
  4. эстонская компания аутсорсит разработку в Украину (как раз во Львов).

Мы — в самом конце производственной цепочки компьютерной эры. Мы не генерируем бизнес-идеи, не принимаем ключевых решений — мы пишем код. Украинский разработчик это понимает. Поэтому не важно, насколько ты хорош в техническом плане, если ты «гребец на галере», и повышение по службе — просто новая «галерная лычка». Эта галерная метафора очень распространена сейчас в украинском IT. Разработчиков, мыслящих этими категориями так много, что хватило на аудиторию целого сайта ebanoe.it. Подумайте сами — проблема не в сайте с неприличным названием, а в том, почемуон появился и стал популярным; не из-за скабрёзного лексикона же.

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

Big Refactoring

Разбудит вас какой-то тип
И впустит в мир, где в прошлом — войны, вонь и рак,
Где побеждён гонконгский грипп.
На всём готовеньком ты счастлив ли, дурак?

Владимир Высоцкий. «Вот твой билет, вот твой вагон»

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

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

«Да что ты можешь один?» Илья Кенигштейн продавил появление 3G в Украине: собрали толпу под Кабмин, притащили телефонную будку как символ старой системы, символ попал в медиа — всё получилось.

Ты. Можешь. Быть. Прогрессором.

Недавно на DOU было интервью с Алексеем Колупаевым. Там в подкасте была ценная мысль, почему-то не вошедшая в статью:

«Не надо идти в компанию, где круто — там и без тебя круто. Надо сделать компанию крутой», Ев. от Алексея, 23:17

И есть проблема ещё более важная, чем война на Донбассе. Ведь война закончится, а мы так и останемся в нищете.

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

Вы не задумывались, почему кофе — итальянский, а чай — английский, если они там не растут? Зёрна кофе и каменный уголь — удел развивающихся стран, а Lavazza и Intel — развитых.

Есть мнение, что «развивающиеся страны — это страны, которые не развиваются». Мы нищие, потому что не развиваемся.

Главная проблема Украины — у нас нет образования.

Мы учим английский в школе и универе более десятка лет — но мы его не знаем.

Учитель тригонометрии жалуется, что дети задолбали вопросом «зачем нужна тригонометрия», а она не знает, что ответить. А потом IT-компании жалуются на низкий уровень математики у джуниоров.

Обучение бизнесу — в Европе проходят Customer Development и Business Model Canvas — кому именно ты продаёшь, какую их боль решаешь, какими каналами движутся товары, деньги и обратная связь, в общем, чистый здравый смысл на вопрос «как вести бизнес». А у нас — «разницу между ООО и ОАО» и «формы налогообложения».

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

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

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

Свои проекты

— Мой дорогой друг, кто вам позволит?
— Это не главное. Главное — кто меня остановит?

Айн Рэнд. «Атлант расправил плечи»

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

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

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

И мы уже это делаем в проекте Zero to Hero. Мы снимаем видеокурсы, которые может использовать любое учебное заведение. И средним школам, и IT-академиям приходится объяснять двоичную систему, язык Python, основы баз данных и так далее. Зачем это делать каждый раз заново? Что предлагаем мы — дайте студентам посмотреть видеокурс как дидактический материал (где ему объяснят зачеми покажут в связи с другими темами), а на занятиях займитесь реальной практикой. Так каждый предмет нужно будет заснять всего один раз — а пользоваться будем все. Плюс вместо «здесь знаю, здесь не знаю, здесь рыбу заворачивали» мы пытаемся формировать единую картину понимания мира — математика завязывается на историю и бизнес, IT — на теорию вероятностей, и т.д. Курсы упаковываются в специализации — так что любую профессию можно разложить на несколько дискретных навыков.

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

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

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

Журналисты канала"1+1″ приехали к нам во Львов и сняли репортаж и про возвращение нашей семьи из Дании, и про мой образовательный проект.

Очень было приятно, когда коллега на работе сказал: «Звонил отец, спрашивал, а сколько же будет 1/2 + 1/3, там какой-то Скакунов рассказывал».

Телеканал ZIK снял свой репортаж:

Вообще в Украине сейчас идеальный момент начинать свои проекты. Девиз бизнеса: «покупай дёшево — продавай дорого». Украина проходит экономическое дно — куда ж дешевле? Самая большая страна в Европе с несколькими климатическими зонами с постсоветским сервисом в любой отрасли, по числу жителей больше Скандинавии, и жители эти — очень талантливые люди, готовые работать за 1/10 твоей IT-зарплаты. И ты: логически мыслишь, знаешь языки, видел мир, умеешь общаться с иностранцами, у тебя нет необходимости спрашивать разрешение, и ты знаешь, как дать сервис. Возможно, без большого опыта, но с серьёзным потенциалом. Одноглазый в стране слепых.

Хоть ресторан открывай, хоть кальвадос гони, хоть кино снимай.

Ведь это и есть лекарство от сарказма: «лучше создавать работу, а не искать ее» © Марк Цукерберг.

Твой внутренний синьор Карабас-Барабас ещё не поглаживает бороду с хитрым прищуром?

В общем, ребята, скажу так: East or west — home is best.


См. также весь цикл статей

DOU Hobby: Альпинизм — от спортивного туризма до восхождения на семитысячники

0
0

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

О том, что лучше гор могут быть только горы, DOU рассказали харьковчанин Сергей Шиян, Senior Software Developer в компании Sigma Software, и киевлянка Мирослава Партала, Test Engineer в GlobalLogic.

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

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

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

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

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

Сергей (слева) на вершине Казбека, 5033 м

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

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

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

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

Мирослава на склоне Хан-Тенгри, базовый лагерь, около 4000 м

Подготовка к восхождениям

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

Первая задача перед восхождением — найти толкового гида/инструктора и обязательно продумать все детали перед поездкой:

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

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

По словам Сергея, для него альпинизм — это постоянное желание насладиться красотой природы, возможность забрести на самый настоящий «край мира»

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

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

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

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

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

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

В планах Мирославы — получить титул «Снежный Барс» за 5 семитысячников бывшего союза — пик Ленина, пик Хан Тенгри, пик Корженевской, пик Коммунизма и пик Победы

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

Сергей видит в альпинизме возможность самореализации:

«Знаете, у Джорджа Мэллори (по неподтвержденным данным именно он первым в мире покорил вершину Джомолунгмы) однажды спросили: „Зачем вы идете на Эверест?“. „Потому что он есть!“ — ответил Джордж».

Опрос: какую ИТ-литературу стоит читать

0
0

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

Результаты предыдущего рейтинга доступны по ссылке.

Также форму можно заполнить по ссылке.

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

0
0

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

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

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

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

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

Как видно из описания — в бизнес и технологическом сегментах ценным было создание чего-то полезного для бизнеса (что-то типа consumable solution), в то время как в сегменте «люди» ценностью было выполнение указаний менеджеров (в лучшем случае working software). При этом контрактные модели бизнес и технологического сегментов позволяли не платить/платить меньше в случае, если вендор не создавал ценный для бизнеса продукт (партнерские отношения). В то время как контрактные модели сегмента «люди» были ориентированы на предоставление рабочей силы без привязки к полученному результату (удовлетворил бизнес потребность или нет — а за людей заплати).

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

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

Рейт состоит из зарплаты специалиста, «маржи» компании и прямых/косвенных затрат на содержание рабочего места специалиста + ведение бизнеса (менеджмент и т.д.) также знакомых всем нам как оверхед (overhead). Таким образом, при конкуренции в плоскости «цена» маленьким компаниям расти гораздо проще, ввиду возможности предложить более низкий рейт при той же зарплате за счет меньшего оверхеда (в компании в 20 человек CEO заплатил себе 10 000 долл в месяц зарплаты и на этом оверхед закончился. В компании в 500 человек на зарплату non-billable людям уйдет гораздо больше. Соответственно оверхед будет гораздо выше).

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

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

В EPAM это PDS 2.0, в Luxoft — Managed Delivery, в Intetics — PSE (Predictive Software Engineering). Чем больше компания, тем острее ее руководство ощущает потребность в диверсификации бизнеса и переходе в сегменты разработки решений.

Для всех нас, преимущественно работающих в IT outsourcing, это означает одно — с изменением фокуса на решения от всех нас будут требовать совершенно иного набора навыков. Гораздо более разнообразного и широкого, чем просто уметь писать код либо выполнять тесты, либо составлять требования. Сложность работ, выполняемых в сегментах «бизнес» и «технологических» решений на порядок выше, чем в сегменте «люди». Поэтому, чтобы делать consumable solutions, для начала нужно будет поменять майндсет в стиле «works on my PC».

К сожалению, быть просто «хорошим кодером» уже недостаточно. Причина этому очень проста. Сейчас от специалиста ожидается автономность. Ожидается, что ему можно сказать, что «с 01.06.2017 пользователь хочет видеть бонусы по всем своим скидочным картам». Предположим, что вы разрабатываете некий агрегатор скидочных карт. Раньше специалист мог бы прийти к архитектору и спросить, а как же и где же взять информацию о бонусах и где и как же взять и создать список карт, ну и имел luxury задать еще с десяток вопросов, частично перекладывая решение задачи на своих коллег. Это было возможно благодаря контрактной модели Staff Augmentation или Time and Materials, когда вендору было выгодно продавать отдельно QA, отдельно BA, отдельно Database Developer и еще .NET Developer, ну и, может, даже .NET Architect (причем довольно часто Solution уровня. У нас их почему-то очень много). Все эти люди ходили пили кофе и чай, устраивали митинги и задавали друг другу вопросы, аргументируя их своей узкой специализацией и зоной ответственности.

По модели Fixed Price, чем меньше людей у нас работает, тем выгоднее, так как меньше затрат на зарплату, аренду столов и туалетную бумагу. И в таком проекте от специалиста будут ожидать даже общение с конечными пользователями для выяснения, а каким же цветом показывать отрицательные числа, если это возможно? Красным или оранжевым? Не говоря уже о том, где взять информацию, с кем, как и когда провести интеграцию, как обеспечить безопасность и отказоустойчивость. И все это за те же $3500-4000, за которые мы раньше привыкли зарабатывать ВСД, выпивая по 5-7чашек кофе в день, в попытках выспросить у коллег, как же лучше выполнить нашу работу.

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

Чему же учиться?

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

Java дайджест #33: Pattern Matching for Java

0
0

Ссылки, на которые лучше таки нажать (по мнению автора), отмечены знаком (!)

Что-то вроде новостей

(!) Собственно новость месяца: Pattern Matching for Java. На мой взгляд, выглядит странно. У кого какое мнение по этому поводу?

Java EE is moving to GitHub!

Вышел Apache Maven 3.5.0. Появилась самая важная фича — цветной вывод в консоль.

Вышел Gradle 3.5

Вышел Spring Cloud Pipelines 1.0.0.M4. Похоже, что под брендом Springхотят собрать все тулы для разработки на Java.

Почитать и посмотреть

(!) Bytestacks — флеймграфики для Java.

Java Finalization to be Deprecated?

JVM Anatomy Park #3: GC Design and Pauses

All about java.util.Date. Статья никаких откровений не содержит, но для «закрепления материала» сойдет.

Custom collectors in Java 8. Довольно просто про то, как работают Collectors.

Обзор Spring Boot Actuator.

Java 9

(!) Using JDK 9 Memory Order Modesот Doug Lea.

(!) 3 статьи о модулях Java 9 от Stephen Colebourne:

Support for Java 9 Modules in IntelliJ IDEA 2017.1

На сколько Eclipse готовк Java 9

Беспокойства сообществапо поводу Jigsaw.

Is Jigsaw good or is it wack?

Микросервисы

Real World Microservices with Spring Cloud, Netflix OSS and Kubernetes. Сколько баззвордов в одном заголовке.

Ссылка на pdf-книгуиз предыдущего доклада.

Java micro-frameworks: Why Jooby?

В joobyпоявилась поддержка Kotlin. Похоже, что Kotlinбудет основной темой хипстерского движения в Java.

Meecrowave — еще один фреймворк для микросервисов.

Аналитика, так сказать

Меряем производительность Java-логгеров.

Java in 2017 Survey Results

Top Java Web Frameworks Popularity Index: March 2017

DZone/Java EE Guardians Survey Results


Предложения и пожелания все еще принимаются или через завсклад и товаровэдадминистрацию ДОУ, или через твиттер @_silverwolf. Также можно оставлять комментарии в специально выделенной темена форуме.


← Предыдущий выпуск: Java дайджест #32

Ruby/Rails дайджест #4: Hanami v.1.0.0, чек-лист по безопасности в Rails и Idiosyncratic Ruby

0
0

Всем привет! Ruby/Rails дайджест за апрель посвящен фреймворку Hanami не просто так. В апреле Hanami обновился до версии 1.0.0, поэтому обратите внимание на подборку материалов о фреймворке. Также в новом дайджесте ищите чек-лист по мерам безопасности в Rails, подборку полезных советов и скрытых возможностей в Ruby и много других интересных статей.

Почитать

Безопасность

Ruby on Rails Web Application Vulnerabilities: How to Make Your App Secure‒ лонгрид о наиболее распространенных проблемах безопасности Rails-приложений. Обязательно к прочтению для тех, кто заботится о безопасности в Rails.

One Line of Code that Compromises Your Server‒ Session secret ‒ ключ для шифрования cookies. В статье объясняется, как взламывают этот ключ и с какими потенциальными угрозами для application-сервера вы можете столкнуться.

Resilience in Ruby: Handling Failure‒ если вы решили больше не хранить все данные приложения в одной базе данных и разделить их, статья поможет вам справиться с этой задачей и предотвратить возможные неудачи.

Zen Rails Security Checklist‒ чек-лист по мерам безопасности, которые стоит учесть при разработке Rails-приложений.

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

5 Tips for More Effective Capybara Tests‒ Capybara ‒ популярный фреймворк для тестирования веб-приложений, любимый многими. Тем не менее, 5 советов для более эффективного тестирования с Capybara не будут лишними и для опытных разработчиков.

Yardcheck: Validate YARD docs by running your test suite ‒ гем Yardcheck проверяет корректность YARD типов, прогоняя комплексные тесты.

Full-Stack Testing with Rails System Tests‒ статья о подходе Rails 5.1 к системным тестам и их преимуществах как для для олдскульных интеграционных тестов, так и текущих решений для тестирования на базе Capybara.

Производительность

The Rubyist’s Guide to Memoization‒ мемоизация ‒ один из способов улучшить производительность программного обеспечения. Детальные примеры в статье раскрывают суть мемоизации.

Monitoring Sidekiq Using AWS Lambda and CloudWatch‒ интересный кейс об использовании AWS Lambda для визуализации данных о enqueued jobs и повторных передачах Sidekiq.

GraphQL::QueryResolver: Minimize N+1 queries generated by GraphQL and ActiveRecord‒ GraphQL:: Query Resolver позволяет минимизировать запросы N+1, которые генерируются GraphQL и ActiveRecord.

ActiveJob::TrafficControl: Rate limiting/job enabling for ActiveJob using distributed locks in Redis or Memcached‒ гем ActiveJob::TrafficControl предоставляет возможность устанавливать паузы и лимиты на запуск задач для ActiveJob c помощью распределенных блокировок.

GitHub::DS: A collection of Ruby libraries for working with SQL on top of ActiveRecord’s connection‒ GitHub::DS ‒ это коллекция Ruby-библиотек для работы с SQL наряду с подключениями ActiveRecord.

Jumping Off The Ruby Memory Cliff‒ Richard Schneeman объясняет, почему иногда использование RAM превышает лимит и как бороться с этой проблемой.

Improve your Ruby application’s memory usage and performance with jemalloc‒ библиотека jemalloc позволяет улучшить производительность Ruby-приложений до 10%, а также уменьшить использование RAM.

Разное

Ruby 2.4 series from BIGBinary‒ подборка статей по теме Ruby 2.4, которые держат разработчиков в курсе о новом функционале и обновлениях.

Rails Benchmarking: Puma and MultiProcess‒ бенчмаркинг Rails-приложений: Puma и MultiProcess.

Versioning a Rails API ‒ что вы получаете от контроля версий API, почему не стоит отказываться от этого и как обновить ваше приложение, чтобы оно заработало.

How I Wrote the HTTP-client for mruby‒ кейс о написании небольшого HTTP-клиента для mruby.

Ruby 101: Data Structures‒ статья для начинающих разработчиков о структуре данных в Ruby: array, hash, iteration.

Dry-Validation as a Schema Validation Layer for Ruby on Rails API‒ Legacy-код никогда не бывает таким, как нам бы хотелось. Но благодаря готовым решениям вроде библиотеки Dry-Validation ‒ одной из «мастхэв» библиотек для работы с разными видами входящих данных ‒ эта проблема решается.

A Ruby Shadowing Bug in the Wild‒ не все замечают затаившийся баг в Ruby, когда локальные переменные «заслоняют» методы класса. Tom Copeland рассказывает об этом подводном камне в Ruby.

All Rails Service Objects as One Ruby Class‒ Service objects становятся мейнстримом в Rails-сообществе; статья раскрывает суть service objects, заключенных в один класс.

Speed Up Your Sinatra Development with OpeningAct‒ OpeningAct ‒ гем, который предлагает простой шаблон для Sinatra, таким образом, вы можете полностью сосредоточиться на разработке вашего приложения.

Idiosyncratic Ruby: Documenting All Ruby Specialities‒ подборка различных приемов и хитростей в Ruby, а также сравнений, советов и много других полезных вещей.

Support of Ruby 2.1 Has Ended‒ Ruby 2.1 больше не поддерживается. Рекомендуется как можно быстрее перейти на Ruby 2.3 или Ruby 2.4.

Послушать

TinyTDS, Databases, and SQL Server with Ken Collins‒ авторы подкаста Ruby Rouges обсуждают TinyTDS, базы данных и SQL сервер вместе с Ken Collins ‒ автором SQL Server Adapter for Active Records и TinyTDS.

The Rails 5 Way with Obie Fernandez‒ звездный гость очередного подкаста Ruby Rouges ‒ Obie Fernandez, автор The Rails 5 Way.

Migrating from redis-namespace, Rooby, Headless Chromium, CodeSandbox, Prettier и прочее ‒ новый выпуск подкаста от RWpod включает в себя темы по Ruby (дополнительные параметры для Logger в Ruby 2.4, обсуждение полезных гемов) и JavaScript.

Посмотреть

Using Webpack in Rails with the Webpacker Gem‒ скринкаст с гемом Webpacker для создания современных frontend решений JavaScript в вашем Rails-приложении.

Ruby Snack #60: Create New Rails App with Docker‒ в очередном скринкасте RubyThursday объясняется, как с помощью Dockerfile и docker-compose.yml файла создать новое Rails-приложение.

Ruby Snack #61: Rails Development Flow with Docker‒ продолжение предыдущего скринкаста о разработке Rails-приложения с Docker.

Туториалы

Ruby on Rails 5.1.0 Deprecations‒ перечень устаревших методов в Rails 5.1.0.

Configuring New Rails Projects With .railsrc and Templates‒ конфигурация новых Rails-проектов с помощью .railsrc файла и templates.

Action Cable ‘Hello World’ with Rails 5.1‒ пошаговый туториал объясняет, как отправить HTML-код из консоли в уже загруженную веб-страницу.

Slim down hefty Rails controllers AND models, using domain model events‒ статья (а также скринкаст в ней) объясняет рефакторинг-технику для следования гайдлайну «fat model, skinny controller».

Importing Invalid Legacy Data with Rails‒ туториал о том, как импортировать legacy-код, несовместимый с вашим новым Rails-приложением.

How to Recover from Rails Database Schema Conflicts When Rebasing‒ туториал по пошаговом решении конфликтов при изменении версии схемы после мержа изменений.

Stop Using Case Statements in Ruby‒ при проверке классовых типов данных, лучше избегать использования case statements и прибегать к полиморфизму. Туториал объясняет, как решить проблему case statements.

Релизы

www.faecms.com‒ новая open-source CMS на Rails с удобным интерфейсом и функционалом: отслеживанием изменений, глобальным поиском, инструментом для загрузки и обработки изображений и др.

Hanami

Hanami v1.0.0‒ в апреле вышел релиз Hanami v1.0.0. Это ‒ маленькая победа для сравнительно свежего фреймворка (работа над Hanami началась в 2012 году). Релиз включает в себя новые версии гемов:

  • hanami-1.0.0
  • hanami-model-1.0.0
  • hanami-utils-1.0.0
  • hanami-validations-1.0.0
  • hanami-router-1.0.0
  • hanami-controller-1.0.0
  • hanami-view-1.0.0
  • hanami-helpers-1.0.0
  • hanami-mailer-1.0.0
  • hanami-assets-1.0.0

Также мы подготовили интересные статьи по теме, которые дадут вам возможность узнать побольше о фреймворке Hanami, сравнить его с Ruby on Rails и познакомиться с его возможностями.

What I learned Building an App in Hanami‒ вопрос «Hanami лучше, чем Rails?» интересует многих. В статье рассказывается об опыте создания приложения на Hanami.

Rails vs Hamani‒ сравнение Rails и Hanami по многим фронтам: структуре каталогов, действиям контроллеров, application routing, view helpers и другим.

From Rails to Hanami (Lotus) Part 1: Container Architecture, Models, Views and Assets‒ лонгрид о переходе с Rails на Hanami, а также MVC-архитектуре Hanami.

Hanami Trick: Default Template for Mailers‒ статья о создании стандартных шаблонов для email’ов.

Uploading Files with Shrine in Hanami‒ Shrine ‒ гем, который реализует загрузку файлов в Hanami. Пошаговый туториал объясняет, как реализовать функционал загрузки файлов с Shrine.

How to Run Hanami in RubyMine‒ туториал по запуску Hanami в RubyMine.

Using Sidekiq with Hanami‒ Sidekiq ‒ популярный гем для отложенных задач в Rails. В статье объясняется, как интегрировать Sidekiq в Hanami.

Библиотеки

GoogleCloud: The Google Cloud client library for Ruby‒ библиотека предоставляет API для интеграции с сервисами Google Cloud Platform.

Postal ‒ полноценный mail server для веб-сайтов и веб-серверов, который быстро попал в топ рейтинга Trending на GitHub, получив более 2600 звезд.

Книги

Rails, Angular, Postgres, and Bootstrap: Powerful, Effective, Efficient, Full-Stack Web Development‒ 25 июня в издательстве The Pragmatic Programer выходит второе издание книги Rails, Angular, Postgres, and Bootstrap: Powerful, Effective, Efficient, Full-Stack Web Development.Уже можно оформить предзаказ.

Effective Testing with RSpec 3‒ также в июне выйдет книга Effective Testing with RSpec 3 в O’Reilly Media. Предзаказ уже открыт.

Functional Web Development with Elixir, OTP, and Phoenix‒ Elixir-комьюнити активно развивается. Новая книга по веб-разработке с Elixir выходит 10 октября на The Pragmatic Bookshelf, электронная версия книги уже доступна.

События

Ruby Meditation #15‒ 13 мая в Днепре впервые пройдет митап Ruby Meditation. Полная agenda и детали ивента по ссылке.

#pivorak 22‒ 28 апреля во Львове митап #pivorak собирает спикеров с темами Secret Life of Git, Data & Bounded Contexts, Strong and weak sides of Golang in production.И, как всегда, будет традиционная афтепати в стиле #pivorak.

Rails DDD Workshop in Lviv with Andrzej Krzywda‒ 25 мая во Львове разработчики Andrzej Krzywda и Robert Pankowecki из Arkency проведут Rails Domain Driven Design Workshop.

Организаторы конференции RubyC 2017, которая состоится 3-4июня в Киеве, объявили финальный список спикеров и их тем, так что не забудьте купить билет ‒ лето не за горами.

Ruby Meditation #16‒ 16 июля солнечная Одесса встречает митап Ruby Meditation. Билетов в продаже пока нет, ждем agenda и старт продаж.


Касательно тем/материалов/ивентов, которые стоит добавить в следующий выпуск дайджеста, пишите в комментариях или на volodymyr.vorobiov@rubygarage.org. Спасибо за помощь в подготовке дайджеста команде RubyGarage.


← Предыдущий выпуск: Ruby дайджест #3

DOU Проектор: Kyiv Maker Faire — как в Украине развивается мейкерство

0
0

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

Меня зовут Света Бовкун. Мы с мужем Юрой Власюком — продюсеры Maker Faire в Украине. 20-21Мая на ВДНХ мы с командой проводим четвертый Kyiv Mini Maker Faire. Приставка Mini, как и раньше, означает, что ее организаторы (то есть мы :) — независимые партнеры большого международного проекта Maker Faire, а не то, что он маленький :)

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

Идея

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

Слово «Мейкер» вошло в обиход с появлением журнала Make. Оно объединяет DIY с Hi-Tech: от первых шагов детей, которые с помощью скотча и палок создают первую ракету, до того момента, когда эта ракета таки улетает на марс.

Что такое Maker Faire?

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

Это формат show&tell — «покажи и расскажи», а в большинстве случаев можно еще и попробовать самостоятельно.

Зачем нам это понадобилось?

Во-первых, это было интересно и этого не было в Украине. Юра читал журнал Make, и сам пробовал все, что связано с Digital Fabrication. В мире повсеместно открывались фаблабы и мейкерспейсы. Это приносило удовольствие, этим хотелось делиться.

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

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

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

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

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

Международный саммит продюсеров Maker Faire в Майами

Реализация

Первый ивент был проведен 6 июня 2015 года. Чтобы стать партнерами сети Maker Faire, нам понадобилось долго и целенаправленно общаться с главным офисом из Сан-Франциско, рассказывать им о том, что у нас происходит, сколько у нас есть мейкеров и почему мы считаем, что готовы проводить этот ивент.

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

Наши партнеры были удивлены, получив запрос из Украины в начале 2015 года, когда главные новости были о войне. На тот момент на карте Maker Faireне было ни одного ивента восточнее Австрии. Пришлось рассказать, что сейчас Украина, как никогда, готова стать страной мейкеров.

Важным фактором было наличие в стране развитого IT-комьюнити.

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

Это был эксперимент, который стал возможен благодаря поддержке Юрия Мыколышина и Саши Оленева (тогда Intel), Дениса Довгополого, Growth Up, которые не словом, а делом и деньгами поддерживают развитие сообщества.

Роман Кравченко, когда узнал о нашей инициативе, как раз готовил логотип IoT хаба, и тоже поддержал нас с первого ивента, сейчас Хаб — это наш стратегический партнер.

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

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

Команда по пути в Одессу

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

Одним словом, первый Kyiv Maker Faire появился, потому что он просто не мог не появиться, потому что были люди, которым это было нужно.

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

Результаты

На данный момент мы готовим 7-й Maker Faire. И это уже огромный ивент на 200 участников и, как мы ожидаем, около 7000 посетителей.

Чтобы не быть столичным ивентом в 2016 году мы провели фесты в Одессе, Харькове и Львове. В этом году мы принимаем у себя митап мейкерспесов из Польши, Чехии, Словакии, Венгрии и Великобритании. Для стран из Восточной Европы именно мы являемся трендсеттерами. Наши волонтеры из Кишинева в этом году проводят собственный ивент.

Мы получаем запросы на мейкеров от TechStars и Hardware club, а на инженеров — от крупнейших компаний, и сейчас выстраиваем сотрудничество и с первыми, и со вторыми.

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

Для того, чтоб было проще объяснять, чем мы занимаемся, мы перевели на украинский книгу «Makers Movement Manifesto» и готовим к переводу еще несколько книг. Показали фильм «Makers», запустили Hardware StartUp MeetUp.

К нам присоединяются IT-компании и школы — все, кто ищет новые форматы самовыражения и обучения новому (далеко не всегда технологиям).

Мы начали сотрудничество с Институтом Модернизации Содержания Образования и помогаем школам запускать собственные School Maker Faire.

Что дальше?

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

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

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

Поэтому, помимо усиления ивентов, наш фокус сейчас на трех направлениях:

  1. Организация постоянно действующего хаба, который будет помогать мейкерам в развитии, для этого мы ищем поддержку фондов и корпораций.
  2. Работа в регионах — мы ищем партнеров и площадки.
  3. Развитие мейкерской инфраструктуры (мастерские и мейкерспейсы).

Мы всегда открыты для мейкеров, партнеров и людей, которым нравится движение мейкеров.

Поддержать нас очень просто, нужно купить билет, но можно также стать партнером или просто другом. Это важно для нас и для сообщества. Увидимся на 4-м Kyiv Mini Maker Faire!

Контакты: Светлана Бовкун, +38067 242 7856, s.bovkun@makerhub.org


Facebook, Google, Microsoft: о стажировках и карьере в гигантах

0
0

Здравствуйте. Меня зовут Дима, и за 4 года обучения в Киеве (КНУ, Кибернетика) мне посчастливилось поработать на разных IT-фронтах, включая outsource, freelance, competitive programming, а также пройти стажировки в Microsoft, Google и Facebook.

Сейчас я работаю на full-time в Facebook, Лондон. С удовольствием откликнулся на предложение DOU поделиться опытом. Приступим.

Прошу заметить, что история моя полностью построена на личном опыте, и к прочитанному стоит относиться соответствующе. Здесь и далее все сказанное о «гигантах» относится к моему мнению о Microsoft, Google и Facebook. Договорились? Тогда поговорим о следующем:

  • Чем прекрасна работа в гиганте?
  • О стажировках, после 100 лет одиночествагода стажа. Тактика и стратегия.
  • О фултайме. Есть ли жизнь после стажировок, и есть ли жизнь без них.
  • Почему я выбрал Facebook.

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

Чем прекрасна работа в гиганте

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

Данные.Представьте объем в 40 000 google search запросов в секунду или сверх миллиарда пользователей Facebook, и сколько данных окружает каждого из них. Здесь у вас будет возможность работать в среде, где каждая оптимизация — это победа.

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

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

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

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

All companies swag

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

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

Перед тем, как мы двинемся дальше, bonus point:

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

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

О стажировках. Тактика и стратегия

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

Стажировка — это не испытаниеи не «Голодные Игры». Это взаимное интервью.

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

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

Каждая из поездок в США на 3 месяца и работа с гениальными и просто классными ребятами была очень ярким эпизодом моей жизни. Из вторичного: весомый вклад в резюме и солидная зарплата. Да, там так круто, что это вторично.

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

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

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

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

Стажировка — это Манна небесная для обеих сторон. Теперь к лайфхакам.

Учите английский.Хорошее определение нужного уровня: вы должны понять интервьюера, а он должен понять вас.

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

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

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

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

Crack these interviews.Чаще всего на интервью перед стажировкой вам достанутся задачи в стиле leetcode.com, так что решить сотню-другую подобных задач не помешает. Это можно сделать за месяц, главное систематичность. А вот правильно ли задавать такие задачи на интервью — это holy war. Ну вы поняли.

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

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

Work smarter, not harder.В Facebook это один из девизов, но действителен для всех. Приоритеты, эффективность и фокус в течение восьми часов дадут намного больше, чем двенадцать часов бараньего упрямства. Впрочем, немного overtime еще никому не вредил. Но этого от вас никто требовать не будет.

Есть только один интерн, которого вам нужно победить.Себя, это настолько банально, что часто недооценивается. А ведь это так.

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

О фултайме. После стажировки и без нее

Если стажировка закончится успехом, вам предложат return internship или full-time offer, в зависимости от того, сколько вам осталось учиться и некоторых тонкостей виз в разные страны (про это нужна отдельная статья).

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

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

Несколько мыслей на эту тему:

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

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

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

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

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

Почему Facebook

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

Со своей командой в офисе Facebook

Как вы могли верно заметить, я люблю списки.

Bootcamp.Из всех известных мне компаний такое есть только в Фейсбук. Bootcamp — это первые шесть недель работы, во время которых вы посещаете интересующие вас лекции (инфре, тестирование, цели, культура, прочее) и работаете с ЛЮБЫМИ командами. В конце Bootcamp вы присоединяетесь к команде, которая больше всего понравилась ВАМ. Команда влияет на множество вещей, поэтому Bootcamp стал решающим фактором выбора компании для многих моих друзей и коллег.

Culture.Это просто. Очень тёплая атмосфера, глубокое уважение, а еще — Фейсбук, это нация impact (очень не люблю перевод этого слова). Здесь мы действительно ценим вклад, и вы всегда будете работать над важными вещами. Даже на интернатуре меня воспринимали как равного, и я мог расти над собой каждый день.

Ship love.Сугубо личное мнение, но я считаю, что Фейсбук делает очень много полезного для мира. Всегда приятно слышать от людей, как они ценят то, что ты делаешь.

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

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

И это всё?

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

П.С. Простите за английский, но не поднялась рука на термины.

Огляд ІТ-ринку праці: Тернопіль

0
0

[В серії «Огляд IT-ринку праці»ми розповідаємо про IT-індустрії в різних містах України]

В ІТ-індустрії Тернополя зайнято до тисячі спеціалістів, в місті працюють більше 20 ІТ-компаній.

Середні зарплати програмістів у Тернополі (медіани, грудень-2016):
— Junior — $500;
— Middle — $700;
— Senior — $2400.

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

Компанії

Більшість тернопільских ІТ-компанійзаймається аутсорсингом. Ми зібрали інформацію про найбільш відомих працедавців міста:

Forte Group

Американська компанія
105 спеціалістів у Тернополі

Основні напрямки — розробка, тестування та підтримка ПЗ для компаній американського ринку. Діяльність компанії зосереджена у сферах освіти, електронної комерції, телекомунікацій, юридичній, фінансовій та проектах пов’язаних з охороною здоров’я. Технології розробки: Java, Oracle ATG, .NET, Python, Front-End, PHP, iOS, Android, IoT.

Можливості для початківців:компанія має підрозділ Forte Knowledge, на базі якого вже декілька років поспіль проходять безкоштовні курси для початківців по тестуванню ПЗ (двічі на рік), Android/iOS розробці, Talent Management. Кращих випускників запрошують на роботу. На даний момент працевлаштували вже 36 випускників курсів.

MagneticOne

Українська компанія
85 спеціалістів у Тернополі

Розробка продуктів в областях електронної комерції, CMS та CRM-систем, рішень для муніципальних органів, мобільні додатки та інші напрямки.

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

ELEKS

Українська компанія
70 спеціалістів у Тернополі, 1024 в Україні

Головні індустрії розробки: фінанси, безпека, урядування, медицина, роздрібна торгівля, медіа та ін. Серед клієнтів: Autodesk; Havas; Eagle Investment Systems (a subsidiary of BNY Mellon); Commonwealth Financial Network; Phoenix; Xceedium; Xyleme; The States of Jersey Government, Jersey, UK.

Можливості для початківців:є навчальні програми (QA, SQL, Java, Swift, C++, C#, Front-end, devOps, PM).

Crowdin

Українська компанія
34 спеціалістів у Тернополі

Продуктова компанія: розробляють платформу для управління локалізацією в технологічних компаніях. Серед клієнтів — Microsoft, Prestashop, Kickstarter, Xiaomi, Huawei, Citrix, Reddit, OWASP. Сервіс має близько мільйона реєстрацій. Технології: LEMP, AWS.

Можливості для початківців:періодично проводять безкоштовну програму Crowdin Space — навчання/стажування для студентів технічних вишів. Напрямки — розробка PHP + JavaScript, тестування.

Yaware

Українська компанія
22 спеціалісти у Тернополі

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

Можливості для початківців:компанія пропонує стажування протягом одного місяця в разі наявності відповідних відкритих вакансій. Для стажерів розроблено детальну програму. Також надається можливість використання системи онлайн-навчання для працівників — Yaware Courses (один з продуктів компанії Yaware).

JSSolutions

Українська компанія
20 спеціалістів у Тернополі, 30 в Україні

Розробка JavaScript додатків для венчурних стартапів і малих підприємств. Використовують сучасні технології JavaScript — Node.js, React, ReactNative, Meteor. Крім того, працюють над розробкою власного продукту та долучаються до розробки інноваційних та цікавих Open Source рішень.

Можливості для початківців:проводять курси, діє JSSolutions Academy.

Orange35

Українська компанія
15 спеціалістів у Тернополі

Розробка ПЗ, в тому числі для Magento та PrestaShop. Основні напрямки — Magento eCommerce Web Development, Magento Extensions, Wordpress Development і Custom Website development.

Virtido

Швейцарська компанія
12 спеціалістів у Тернополі, 33 в Україні

Дочірня компанія від однойменної у Швейцарії, займається наданням ІТ та адміністративних послуг. Розробляють ПЗ з використанням .NET, Python, C#, PHP, JS. MS SQL, MySQL. Також пропонують розробку сайтів — як на основі існуючих CMS, так і нестандартних. Є команда німецько та англомовних спеціалістів, які займаються наповненням сайтів, різноманітними операціями на бекенді.

Можливості для початківців:в плані ІТ немає, проте двічі на рік проводять оплачуване стажування, де пропонуються задачі, пов’язані з роботою з клієнтами.

Unicorn Systems

Чеська компанія
10 спеціалістів у Тернополі, 90 в Україні

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

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

MagneticOne Mobile

Українська компанія
10 спеціалістів у Тернополі

Одна з компаній групи MagneticOne Group. Займається розробкою мобільних додатків на базі Android та iOS. Реалізовує проекти у сфері цифрової трансформації бізнесу, зокрема у галузях Business, Retail, Social Projects, Sales та ін. Найуспішніші з них — Business Card Reader та Call Tracker.

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


У лютому про відкриття у Тернополі офісу на 100 спеціалістів заявила польська аутсорсингова компанія Future Processing. Компанія надає послуги офшорного програмування для клієнтів із Західної Європи і Скандинавії. У польських офісах Future Processing працює більше 600 співробітників.

За результатами голосування читачів DOU, кращими працедавцямиТернополя визнано компанії Forte Groupта ELEKS.

За вакансіями у місті можна слідкувати тут

Спільноти та події

Центр інформаційних технологій — підрозділ при ТДТУ ім. І. Пулюя. До складу Центру входять Академія Сisco Systems, Сектор розробки та впровадження інформаційних систем, Група ліцензування програмних продуктів та ін.

GDG Ternopil — спільнота розробників, які цікавляться технологіями Google. Регулярно проводять зустрічі, присвячені Android та іншим технологіям та напрямкам (.Net, iOS, Machine Learning, QA).

TernopilJS — спільнота шанувальників Javascript, заснована компанією JSSolutions. Періодично проводять зустрічі, організовують безкоштовні курси для початківців. Спілкування спільноти проходить в Telegram чаті.

Elixir Club — зустрічі розробників тернопільскої Elixir спільноти.

Зустріч GDG Ternopil

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

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

Code battle — змагання для студентів-програмістів, що символічно проводиться під час глобальної ініціативи Hour Of Code. Організатор — компанія Crowdin.

Слідкувати за подіями у Тернополі запрошуємо в Календарі

Освіта

ІТ-спеціалістів у Тернополі готують 2 виші:

Найбільші ІТ-школи:

Навчальний заход Crowdin Space

Перспективи Тернополя як ІТ-регіону

Володимир Погойда, генеральний директор Unicorn Systems:

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

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

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

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

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

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

Сергій Кутузов, Managing Director компанії Forte Group:

Тернопіль, як на мене, ідеальне місто для життя ITшників та цікава можливість для розвитку IT-компаній. Гарна екологія, мальовнича природа, низька вартість життя, зручне розташування — це лише деякі з переваг Тернополя як місця для життя IT-спеціалістів.

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

Донедавна Тернопіль був лиш джерелом кадрів для великих міст, і, досягнувши рівня middle, працівники, як правило, залишали місто. Зараз ситуація суттєво змінюється, відкрилось багато нових IT-компаній, є цікаві можливості для спеціалістів будь-якого рівня. До певної міри з’явилась тенденція до переїзду спеціалістів з інших міст до Тернополя, а головне — можливість для місцевих реалізувати себе вдома.

Для IT-компаній Тернопіль також цікавий в плані інвестування та відкриття офісів, що і відбувається останні роки.

Андрій Бурмістров, co-founder та CEO MagneticOne Mobile:

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

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

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

Сергій Дмитришин, founder та CEO Crowdin:

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

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

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

Аеропорт, велике ІТ-комюніті є поряд у Львові (2 години на авто).



Див. також огляд IT-ринку праці інших міст:
— Вінниця
— Дніпро
— Запоріжжя
— Івано-Франківськ
— Луцьк
— Львів
— Миколаїв
— Одеса
— Харків
— Черкаси

Бути чи не бути: чи підійде мені кар’єра продакт-менеджера

0
0

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

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

Позиція продакт-менеджера вам не підійде, якщо:

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

А зараз давайте розглянемо кожен пункт детальніше.

1. Ви не любите спілкуватися з людьми

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

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

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

2. Ви погано переносите конфлікти, а критику сприймаєте як особисту образу

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

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

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

3. Ви ненавидите робити одну й ту саму роботу двічі

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

Якщо тільки менеджер по продукту не суміщає ролі СЕО, маркетолога і розробника, до його/її задач входить отримання зворотнього зв’язку (див. попередній пункт) від інших учасників проекту, корегування бачення, планів тощо. В процесі може змінитися все, що завгодно: від рядку тексту до бачення продукту цілком, і до цього треба бути готовим. Відповідно, це може призвести до того, що деякі речі перероблятимуться по кілька разів. З іншого боку, погодьтеся, що переробити специфікації й плани в кілька разів швидше, дешевше та краще, аніж надати користувачам те, що їм не потрібне, й не надати те, що потрібне.

4. Вам необхідно чітко розуміти свої обов’язки і повноваження

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

Позитивний аспект полягає в тому, що, якщо ви готові брати на себе відповідальність за що-небудь, вам не заважатимуть. До речі, щодо відповідальності, то вона завжди перевищуватиме ваші формальні повноваження. Це означає, що від вас очікуватимуть вирішення проблем, а не скарг на відсутність можливостей чи питань, як щось зробити. If you are not part of the solution, you are part of the problem.

5. Вам важко самоорганізуватися і розставити пріоритети

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

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

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


Певно дехто може зауважити, що багато із переліченого можна перебороти в собі і розвинути зворотні якості. Наприклад, уміння спілкуватися чи організувати власний час можна суттєво поліпшити сходивши на пару тренінгів та прочитавши щось на зразок Getting Thins Done by David Allen, The 7 Habits of Highly Effective People by Stephen Covey, How to Win Friends & Influence People by Dale Carnegie або Emotional Intelligence by Daniel Goleman. Як бачите, я з цим не сперечаюся, оскільки займатися власним розвитком не буде зайвим у будь-якому випадку.

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

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

DOU Labs: как Evergreen экономит время менеджеров с помощью плагина к Redmine

0
0

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

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

Идея

Идея плагина возникла, когда на задачах технической поддержки мы в Evergreen постоянно сталкивались с тем, что оценку должны давать несколько специалистов — например, дизайнер, front-end разработчик и back-end разработчик, и в процессе выполнения задачи и поступления дополнительных пожеланий от заказчика возникает необходимость в дооценке. А дальше при согласовании месячного отчета начинают возникать вопросы, почему задача, оцененная в 2 часа, по факту заняла 10 часов, и эти проблемы мы можем увидеть только в конце месяца.

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

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

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

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

Реализация

Как ставили задачу по разработке Redmine плагина для согласования оценки:

  • Оценка теперь, как и затраченное время, дробится на разные виды деятельности. Общее поле «оценка» считается как сумма оценок по всем видам деятельности.
  • На странице редактирования оценки список несогласованных позиций оценки:
  • Когда мы обновляем задачу или нажимаем «добавить оценку», открывается форма редактирования задачи, в ней добавляется графа согласования оценки.
  • Оценки хранятся в базе в отдельной таблице аналогично time_entries (встроенная сущность «Затраченное время» в Redmine).
  • При любом обновлении оценок поле «оценка» задачи обновляется как сумма всех оценок, привязанных к этой задаче. Как обновлять — при сохранении, при открытии или как-то еще — вопрос к размышлению.
  • Кнопка «Согласовать» в таблице оценок доступна только определенным ролям (менеджер, клиент). Идеальная реализация — сделать в rm отдельное право доступа, чтобы можно было его выставлять в управлении ролями.
  • Когда происходит согласование оценки, должно быть видно, кто и когда её согласовал.
  • Подтвержденные записи удалять и редактировать не может никто (кроме администратора)!
  • После подтверждения даем 1 минуту, в течение которой можно опять нажать кнопку и подтверждение пропадёт, после 1 минуты или если перезагрузил страницу — всё, отменить подтверждение нельзя.
  • Если есть несогласованная оценка возле поля оценка появляется иконка warning и надпись «есть несогласованная оценка». Это поле должно быть доступно для фильтра в списке задач.
  • Редактировать и удалять записи согласования оценки (неподтвержденные) могут:
    • тот, кто её сделал;
    • администраторы;
    • сделать в Redmine отдельное право доступа, чтобы можно было его выставлять в управлении ролями.

Задача почти год лежала на полке, ожидая своего часа, но, наконец, в июле 2016 года, мы поручили разработку нашему R&D Developer’у. Опыта в разработке под Redmine у нас было мало, у разработчика опыта в Ruby не было вообще.

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

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

Например, буквально со старта мы столкнулись с тем, что банально не могли поднять окружение. Делали все по www.redmine.org/…​dmine/wiki/RedmineInstall. Сначала установили ruby 2.1, долго не хотел устанавливаться DevKit для этого же руби. При установке зависимостей из gem файла не компилился gem json и redcarpet. Перелопатили кучу stackoverflow, ничего не помогало. Потом установили ruby 2.3, DevKit поставился, все зависимости подтянулись и все гемы скомпилились, но после запуска команды bundle exec rake generate_secret_token, которая указана в документации, вылезла ошибка и опять же пришлось искать ответ на stackoverflow. В общем и целом для того, чтобы поднять окружение, пробовали и Bitnami Redmine Stack 2.6.10, и просто самостоятельно на отдельном сервере. С помощью молотка, зубила и путем дикого перебора таки подняли и начали разработку.

На этом приколы не закончились. Настроили роут `localhost/issues/:id/s/:id/time_entries_estimates`. C добавлением отдельного контроллера возникла проблема с авторизацией. Здесь нужно добавить permissions, но, когда добавляешь, пишет 404. Создали шаблон плагина через bundle exec ruby script/rails generate redmine_plugin, но не получается настроить вывод стектрейса в браузер, то, что пишут на stackoverflow, не помогло. Сломали развернутый редмайн. Откатили все коммиты, но он не ожил, и отдебажить никак не получается. Просто 500 отдадет и пишет стандартное редмайновское собщение об ошибке. Развернули новый redmine с продакшн средой.

Расковыряли код неслабо, выяснилось, что так просто под копирку сделать модель и контроллер никак не получится. В редмайне плохо реализована MVC модель, контроллер зависит не только от кучи других классов, имеет много примесей (mix-insте, что подключаются через include). В хелперах тоже куча зависимостей от других моделей.

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

Что Redmine Estimates умеет сейчас

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

Подтвержденные оценки по умолчанию скрываются, но можно посмотреть все оценки, если нажать «Показать подтвержденные оценки»:

Право на подтверждение оценки, редактирование записей оценки выставляется отдельным полем в разделе «Администрирование»:

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

В общем списке задач можно вывести поля «Всего часов оценок» и «Всего подтверждено оценок» и использовать их как фильтры:

Планы на ближайшее будущее

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

  • уведомления о подтверждении оценки и соответствующая запись в Journal;
  • запрет на редактирование подтвержденных оценок;
  • признак «Есть неподтвержденные оценки» и соответствующая иконка warning;
  • вычистить код от упоминаний time_entries, на базе которых мы делали плагин.

Где скачать плагин и как установить?

Ссылка на репозиторий GitHub: github.com/…​nmikhno/redmine_estimates

Инструкция по установке там же. Полностью Open Source, таким и останется. Разработан и используется у нас в Evergreen для Redmine 2.1, портирован на 3.0, желающие портировать на другие версии Redmine и поучаствовать в разработке и доработке на свободных началах приветствуются.

PHP дайджест #4: PHP 7 Virtual Machine, PHP вмирає, майбутне Doctrine

0
0

Після тривалої перерви зустрічайте новий випуск PHP дайджесту.

Статті

Nikita Popov детально розповідаєпро Virtual Machine в PHP 7.

Чому PHP гівно — саркастична статья для всіх хейтерів PHP.

Why Rubber Duck Debugging is the best way to debug your code.

Думки Tomas Votruba про те, чому Doctrine вмирає.

Fabien Potencier (автор Symfony) розповідаєпро Symfony 4. В його останній статті він розглядає найкращі підходи в майбутньому мажорному релізі фреймворка.

Туторіали

Introducing you to Xdebug, the powerful debugging tool for PHP applications.

Туторіал про те, як використовувати Laravel Authorization Gates.

Symfony 4: A quick Demoвід Fabien Potencier

Danny van Kooten має цікавий постпро те, як перетворювати проекти на Laravel в Go. Коротко описано про зміни, трансформацію коду, різницю в продуктивності і рядків коду.

На блозі Amazon Web Services з’явився новий пост, який показує, як використовувати logging бібліотеку Monolog і відправляти logs на Amazon CloudWatch швидко і легко.

Релізи

PHP 7.1.4

Laravel 5.4.20

Symfony 2.8.20

Symfony 3.2.8

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

PHP Magic Number Detector.

Створи PHP development environment на Dockerза декілька кліків.

Цікава і дуже проста тулзовинадля автоматичного деплоя проектів на PHP.

Різне

35 programming habits that make your code smell.

Github тред про майбутне Doctrine Project.

The $61,392 Book Launch That Let Me Quit My Job.

Can’t crack that programming problem? Go to sleep (or take a walk).

Про паролі:

Debugging a legacy app:

When we merge the intern’s code on the main branch:

Зранку після ночі кодінгу:

Коли колега поломав мій код:

Кого почитати в Твіттері

Alexander Makarov, засновник Yii

Michael Bodnarchuk, засновник Codeception

Mohamed Said, активний Core Contributor of Laravel Project

Taylor Otwell, автор Laravel

Graham Campbell, Core Contributor of Laravel Project, автор StyleCI, Cachet


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


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

iOS дайджест #18: що повинен знати Senior Developer

0
0

Станом на сьогодні на ДОУ було розміщено 33 вакансії Senior iOS Developer. Я проаналізував їх усі для того, щоб зрозуміти, які скілли найчастіше очікують роботодавці від сеньйора.

1. Мова програмування Swift — 76% вакансій

Зараз вже неможливо уявити Senior iOS девелопера, який не прочитав книгузі Swift від Apple. А для тих, хто прочитав, наступний крок — книга «Advanced Swift». Цю книгу радить Олександр Щербаков, iOS Software Engineer у компанії Prolific Interactive у Нью-Йорку.

2. Networking, REST — 45% вакансій

На цю тему нещодавно виходивокремий iOS дайджест.

3. Core Data — 36% вакансій

Темі Core Data також був присвяченийодин з останніх дайджестів. І хоча у коментарях до нього написали «Нормальные пацаны уже юзают Realm», знання Realm вимагають тільки 9% актуальних вакансій.

4. Unit Tests, TDD — 30% вакансій

Хороша книга «Разработка через тестирование для iOS» доступна російською мовою. Але якщо ви шукаєте щось новіше, зверніть увагу на книгу «Test-Driven iOS Development with Swift».

5. Multithreading, GCD — 27% вакансій

Володимир Павлюк, iOS Developer у компанії SoftServe з досвідом 7 років, радить книгу «Pro GCD and Blocks». Цитую його слова: «Одна из самых полезных книг по iOS».

6. Core Animation — 21% вакансій

Раджу книгу «iOS Animations by Tutorials» від Ray Wenderlich.

7. Local and Remote Notifications — 18% вакансій

Новий фреймворк UserNotifications було розглянутоу минулому дайджесті.


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

Если вы не умеете говорить «нет», то ваше «да» ничего не значит

0
0

Готовим список фич на следующий крупный релиз.
Директор: Что-то у тебя тут слишком долго получается. Давай смотреть, где ты ошибся в эстимейтах и сокращать их.
Я (мысленно): Ну да, что-то полгода на команду из трех человек многовато...
Я (вслух): Ну, у нас же еще саппорт, да и много третьесторонней интеграции.
Директор: На саппорт вы тратите непозволительно много времени, нужно быстрее работать. А интеграция — там всё хорошо документировано, копипастить примеры несложно. Давай поставим четыре месяца расслабленного темпа.
© Давний мой диалог в одной продуктовой компании. P.S. Сделали за год.

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

Что общего в этих диалогах? Менеджер согласился в обоих случаях, хотя можно было отказаться. Почему согласился?

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

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

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

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

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

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

Ситуации

В каких ситуациях программисты часто зря соглашаются или убегают от ответа?

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

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

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

И если человек, который всё время отказывается, — заведомо в проигрыше, то человек, который всё время соглашается, — не успевает ничего. Есть, впрочем, забавный фильм «Всегда говори „да“». Баланс нужен. Рациональный баланс.

Две компоненты

В давлении есть две составляющих:

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

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

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

«Бокс за 21 день: с нуля до чемпиона мира» © Самоучитель

Перезагрузка общения

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

Люди, которым легко

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

Большинству людей сказать «нет» сложно.

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

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

Что делать?

Быстрая оценка

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

  • У меня есть силы и способности для выполнения этой задачи? Если «точно да», то +1. Если «нет» или «ну я не знаю, тут сначала попробовать надо», то +0.
  • Есть ли у меня на это время? Если «да, конечно», то +1. Если «нет» или «а фиг его знает, сколько это займет на самом деле», то +0.
  • Хочу ли я этим заниматься. Тут важно не путать с «надо» и «могу», можно не хотеть есть манную кашу или делать какую-то противную рабочую задачу. Если «да, я хочу это сделать», то +1, если есть сомнения — то 0.

Полученную сумму запомнили. Назовем её «энтузиазм». Впрочем, если у нас энтузиазм равен 3, то дальше можно и не думать.

0123
«Надо подумать»«Да»

Теперь примерно оцениваем последствия по шкале от 0 до 10. Серьезность отказа на «одолжи 100 грн» сильно зависит от того, кто и когда просит — коллега или группа мрачных морд в тёмной подворотне. Я для себя использую примерно такую шкалу:

  • 0 — все забудут через минуту. «Кофе хочешь?»;
  • 2 — мелочь, но на отношения уже влияет. «Помоги бутыль на кулер поставить»;
  • 5 — что-то среднее. «Отсобеседуй кандидата. Да, ты не менеджер и это не твой профиль, но кроме тебя некому, а человек уже пришел»;
  • 8 — увольнение. «Ты либо доделаешь эту задачу до утра пн, либо ты нам такой не нужен»;
  • 10 — смерть.

Это число тоже запоминаем и называем его «серьезность». Числа на картинке примерные.

Выбор поведения

Если «серьезность» 0-3 —быстрый отказ. Если хочется сохранить отношения, то не просто «пошел лесом», а более мягко:

  • «Помоги бутыль на кулер поставить» — «Спасибо, что так высоко оцениваешь мои атлетические данные :) Сейчас глубоко в коде, сильно занят. Так что — нет».
  • Человек может настаивать — «ты уже отвлекся» / «а к кому мне пойти» / «ты что, бутылку поднять не можешь?» / «ты бросишь слабую девушку в беде?» Если после отказа согласиться — это приглашение сесть на шею. Так что — вежливый и твердый отказ. Лучше троллей не кормитьразговор в сторону не уводить. Вообще, если человек давит после отказа в мелкой просьбе, то это уже вопрос не про эту просьбу, а про дальнейшие просьбы. Или про «мне скучно, развлеки меня». Или «я чувствую себя одиноко, поговори со мной».

Если «серьезность» 4-6 —лучше бы позадавать вопросы и послушать ответы. Да, это потребует минут десять-пятнадцать, ну так и серьезность уже тоже немаленькая:

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

Если «серьезность» 7-8 —стоит разобраться в теме тщательно. И если уже таки отказывать, то можно воспользоваться каким-то из приемов:

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

Если в «серьезность» у нас 9-10 —то соглашаемся. Особые случаи «на войне» сейчас не рассматриваем.

Даже бредовое обоснование лучше никакого

Девушка в офисе просила очередь пропустить ее первой к ксероксу. Если она давала обоснование «Я спешу», «Мой босс ждет», то ее пропускали на 70% чаще, чем когда обоснования не было. © известный эксперимент

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

Не бойтесь признаться в некомпетентности

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

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

Парадокс отношений и реакция на отказ

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

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

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

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

Можно оставить всё «как есть». Ведь как-то работает, есть ли смысл менять? Это требует сил и времени. Если же таки менять, то:

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


Анна Юрченко — зачем дизайнеру развивать эмпатию, о курсах в Стэнфорде и как работает американский офис Stanfy

0
0

Компания Stanfy была одним из первых в Украине экспертов в создании мобильных приложений. После открытия американского офиса в 2012 году UX-дизайнер Анна Юрченко переехала в Сан-Франциско. В интервью она рассказала о том, как проектирование, ориентированное на пользователя, и методология дизайн-мышления помогают компании создавать востребованные продукты и завоевывать клиентов.

— Аня, ты работаешь в Stanfy уже довольно долго, расскажи, как все начиналось?

С ребятами из Stanfy я познакомилась 8 лет назад, когда я помогала делать их сайт (до этого я занималась веб-дизайном), и они решили отблагодарить меня, подарив iPod Touch, который тогда только появился. Меня восхитил этот девайс: как в нем все продумано и красиво, и я загорелась идеей создавать приложения для таких устройств. Я присоединилась к команде Stanfy, где как раз начали развивать направление мобильной разработки. В Украине в 2009 году мало кто этим занимался, фактически мы стояли у истоков. Постепенно студия сделала все более востребованный mobile development своей специализацией. Поскольку мы начали раньше всех, и у нас была экспертиза и портфолио реализованных проектов, в Stanfy был постоянный поток клиентов. Мы делали приложения для сайта «Корреспондент», «5 канала», «Лиги», «Подробностей», «Киевстара», «Боржоми» и других крупных заказчиков. В какой-то момент произошло некоторое насыщение, мы стали смотреть в сторону западного рынка. В 2012 году компания открыла офис в Сан-Франциско. Постепенно мы полностью переориентировались на работу с американскими клиентами.

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

У нас здесь маленькая команда: фаундер Паша Башмаков, СЕО Андрей Гаркавый и UX-дизайнер, то есть я. По сути, мы занимаемся консалтингом, стараемся не просто реализовывать то, что хочет клиент, а пытаемся помочь кристаллизировать его видение продукта. При таком подходе дизайн — это та работа, которую тяжело делать удаленно. У заказчика есть понимание проблемы, которую он хочет решить, он эксперт в своей области. У нас же есть опыт в технологиях, мы знаем, как работают мобильные интерфейсы. И продукт рождается из синергии наших знаний. Здесь важно вырастить доверие, построить классные отношения с заказчиком, не ограничиваясь одним брифом и созвоном по Google Hangout. Обязательно нужно поработать вместе, устроить мозговой штурм, сходить на ланч. Все это приводит к тому, что появляются решения, объединяющие нашу экспертизу в дизайне и продукте и экспертизу клиента в domaine. Поэтому дизайн, который делается in person, всегда лучше. Это один аспект, касающийся работы с заказчиком.

Stanfy SF team

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

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

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

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

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

— Ты единственный дизайнер в компании, наверно, можно сказать, что сфера твоей ответственности — продакт-дизайн в целом, не только UX?

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

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

На воркшопе Hackmasters в Пало-Альто

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

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

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

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

Я начала ездить в США в командировки с 2012 года. Стала ходить здесь на профильные митапы и воркшопы по user-centered дизайну, где впервые на практике поработала над персонами, сценариями пользователей, стори-бордами, поучилась у опытных дизайнеров проводить дизайн-исследования. Поучаствовала в недельном интенсиве в Нью-Йорке, который вели специалисты из NN/g (Nielsen Norman Group). Все это дало хорошую базу и мощный заряд вдохновения, появилась уверенность в то, что ты делаешь правильные вещи. Когда я начала внедрять в компании design thinking, нужно было научиться, доносить это до других людей, убеждать их, когда ты сам еще до конца не понимаешь, что у тебя получиться. Здесь важно доверие команды и готовность клиента пойти на эксперименты. Интервью с пользователями, ресерч, анализ — это ведь все время, а значит — деньги, и нужно понимание, что это создаст дополнительную ценность.

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

Курс по дизайну я начала проходить в октябре. Это трехсеместровая программа для тех, кто уже имеет образование. Ты получаешь не диплом или степень, а просто оценку. Чтобы прослушать курс, не нужно сдавать экзамены — только оплатить семестр (около $400). Занятия проходят один раз в неделю вечером. Весенний семестр называется Design Implementation: Getting to Market. Общее направление — это дизайн-процесс от поиска проблемы до ее решения дизайн-методами и выпуска на рынок.

На занятии в Стэнфорде

— Как проходят занятия? Какие инсайты ты лично получила?

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

В целом все, что нам рассказывают, можно найти в интернете, и это не какие-то секретные знания. Большая часть из того, что я там услышала, не была для меня чем-то новым. Самое ценное было в деталях: примеры из практики, личный опыт преподавателей — дизайнеров из IDEO, которые работают в индустрии 15-20 лет.К примеру, было интересно узнать, как они подходят к организации дизайн-исследования. Как правило, они создают одну доску для всего, что относится к одной сессии работы с пользователем, выносят туда все, что всплыло во время интервью (одна мысль/идея/цитата на один стикер). Затем обсуждают, группируют, находят общие шаблоны и пересечения между пользователями. Дальше, используя различные фреймворки (personas, needs hierarchies, user journeys, empathy maps), они синтезируют идеи и инсайты. Для всех этих материалов они выделяют отдельную комнату, где есть возможность все время держать их на виду. Работают командами из 2-5 человек,и во время интенсивной фазы работы над проектом назначают определенное время, например с 10 до 16, когда все должны собраться вместе, двигаться поэтапно, с milestones и целями на каждый день/неделю.

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

— Я знаю, что ты планируешь сделать обучающий видео-курс по скетчингу, в чем его цель?

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

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

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

— Ты связываешь это именно с переездом?

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

Если вам пришлось собеседовать

0
0

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

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

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

Отбирать нужно долго, увольнять — быстро

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

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

Во-вторых, human mode on. Ведите себя расслабленно, помогите кандидату расслабиться. Шутки, разговоры про погоду, географию, расскажите, что вы сегодня не выспались, или наоборот, что у вас отличный день. Чем непринужденней проходит беседа, тем адекватней и объективней будет впечатление у обеих сторон.

Далее, помните, что нанимаете кандидата для определенного рода задач. Нужен бекендщик? Не надо его час гонять вопросами по JS. Нужен UI-дизайнер? Не лезьте глубоко в UX. Если вы senior и собеседуете на junior-позицию, не надо проверять, знает ли кандидат столько же, сколько вы. Если вам нужен верстальщик, не проверяйте его познания сложных алгоритмов. Бывают неловкие паузы, когда кандидат не знает ответа на вопрос или рассказывает совершенно не то. Не стоит его отчитывать, рассказывать, насколько он не прав. «Отлично, я понял», — и к следующему вопросу, если в этом еще есть смысл.

Однако немного влево-вправо от его профиля и от ваших рамок позиции тоже полезно отойти. Но только с целью посмотреть, как будет развиваться ход мысли. Например, у QA без опыта автотестирования можно узнать, какие бы кейсы он в первую очередь включил в автоматизацию. У PM, которые работали только с fixed quote узнать, чем, как им кажется, может быть опасен time&material.

Это, пожалуй, очевидно, но всегда спрашивайте пару вещей из резюме. Вы удивитесь, сколько людей не могут ответить про скиллы или указанный там опыт :) Вопросы нужно стараться ставить открытые. На «Как вы относитесь к критике?» все ответят «Хорошо». А вот результаты по вопросу «Что для вас значит критика?» будут уже интересней. Старайтесь еще понять, насколько человек впишется в атмосферу коллектива, даже если речь идет про distributed team.

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

Если вам кажется, что что-то не так — отказывайте

А с ответственностью что? Я работала с товарищами, которые могли потратить в два раза больше времени на объяснения, почему так сделать нельзя и почему вокруг виноваты все остальные, чем собственно на решение проблемы. Если вам такой скилл нужен — для client-facing позиций может пригодиться, — то это отличный match. Если будет стопорить процесс, то кандидат не ваш. Обсудите с ним, какой фейл в проекте был и действия команды.

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

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

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

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

Применяйте zero jerk tolerance, т. е. если на собеседование к вам приходит Очень Большое ЧСВ, скептик, критик, специалист по переходу на личности и пр. — не тратьте ваше время. Конечно, здоровый скептицизм — очень важная черта, но скептицизм с порога и без основательных на то причин — плохой признак, и после приема на работу он никуда не пропадет.

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

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

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

Итого: common sense, интуиция, человеческое общение, zero jerks tolerance и помнить, зачем именно кандидат вам нужен.

Путь стажера: Sigma Software

0
0

Всем привет. Меня зовут Костя, я студент 4 курса ХНУРЭ кафедры программной инженерии (ПИ). Год назад я попал на стажировку в Sigma Software, а по ее успешном завершении стал Junior .NET разработчиком.

Расскажу немного о себе. Я поступил в ХНУРЭ в 2013 году и тогда еще практически не умел программировать. Я был знаком c Pascal, который мне преподавали в школе. Это примерно уровень bubble sort.

Мне очень нравилась учеба в университете, и практически все свободное время я уделял ей. Программирование поначалу давалось очень тяжело. Мне было сложно во всем: первые циклы и ifы, Python, С#, ООП казались чем-то страшным и непонятным. И самое ужасное, что я совсем не знал английский язык. Я забивал на него в школе и почти все, что мог сказать, это: «London is the capital of Great Britain». При этом я не понимал, что значит is в этом предложении...

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

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

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

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

Мое знакомство с Sigma Software произошло на третьем году учебы. В ХНУРЭ преподают предмет «Анализ требований программного обеспечения», цель которого — изучение методологий разработки ПО и в частности Scrum. Кафедра ПИ сотрудничает с многими IT-компаниями в Харькове, одной из них была и остается Sigma Software.

Особенностью этого предмета было то, что в течение семестра группе студентов необходимо разработать учебный проект под руководством специалистов компании. Они выступали в роли product owner и помогали студентам изучить Scrum.

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

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

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

Отбор

Процесс отбора в Sigma Software проходит в два этапа: техническое собеседование и собеседование с HR и Department Manager.

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

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

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

Я ушел со встречи довольным. Мне пообещали перезвонить в течение четырех рабочих дней и объявить результат. Через 3 дня меня пригласили на следующий этап отбора.

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

Второе собеседование прошло куда сложнее, чем первое, потому что теперь ребята пытались максимально раскрыть мои персональные качества, соответственно, было много личных вопросов. Это не были глупые вопросы вроде «Почему вы выбрали „Сигму“?». Они максимально раскрывали мой характер, темперамент, стрессоустойчивость, что мною движет по жизни, командный я игрок или нет, как я веду себя в критических ситуациях и все в этом духе.

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

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

Интернатура

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

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

Рабочий день начинался с лекции, а заканчивался практическим заданием. Учебный материал покрывал много тем: юнит-тестирование, мобильная разработка, S.O.L.I.D., обзор библиотек, которые удобно использовать с Xamarin, некоторые базовые шаблоны, такие как MVVM, который мы в будущем использовали для разработки Android-приложения, Scrum и т. д.

После каждой лекции мы выполняли различные практические задания. Почти все они прямо относились к проекту, который мы разрабатывали. Например, после лекций по ASP.NET мы начинали делать backend для нашего мобильного приложения, а после лекции по юнит-тестам — покрывать наш код тестами. Лекции продолжались примерно 1,5 недели, а оставшиеся время мы посвятили разработке проекта.

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

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

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

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

Результат

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

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

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

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

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

DOU Books: 5 книг по программированию, которые советует Денис Шевченко, Director of Technology в Plarium

0
0

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

[Денис Шевченко — Director of Technology в Plarium, работает в ИТ более 15 лет]

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

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

Э. Хант, Д. Томас. «Программист-прагматик. Путь от подмастерья к мастеру»

Направление:Программирование как профессия

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

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

Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. «Приемы объектно-ориентированного проектирования. Паттерны проектирования»

Направление:Архитектура

Удивительно полезная книга знаменитой «банды четырех» (Gang of Four). Отличный пример структурированного и продуманного изложения. По сути, книга заложила терминологию, которой пользуются практически все программисты, обсуждая то или иное архитектурное решение.

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

Б. Керниган, Д. Ритчи. «Язык программирования C»

Направление:Языки программирования

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

Дж. Рихтер. «CLR via C#»

Направление:Технологии

Практически идеальный учебник по .NET.
Джеффри Рихтер подробно рассказывает о языке C#, а также об устройстве и фундаментальных принципах функционирования .NET-платформы. Традиционный вопрос на наших собеседованиях: «Вы читали Рихтера? Сколько раз?». Вопрос звучит неизменно многие годы, лишь книги меняются. Раньше была «Windows via C/C++», теперь — эта. У Джеффри настоящий талант открывать двери для новичков, создавать правильный и достаточно глубокий фундамент для дальнейшего развития. Эта книга не единственная, но, если вы начинаете знакомство с технологией .NET, начните с нее. Вы не пожалеете!

Э. Таненбаум, М. ван Стеен. «Распределенные системы. Принципы и парадигмы»

Направление:Области разработки и другие направления

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

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

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

Приятного чтения и успехов в вашей деятельности. Спасибо!

QA дайджест #27: сложности тестирования игр и IoT, взгляд изнутри на тестирование Компас 3D и Mail.ru

0
0

Меня зовут Максим, я работаю тестировщиком ПО, с интересом слежу за событиями в мире тестирования и IT. Самое полезное собираю вместе и с радостью делюсь с вами. Приятного чтения! :)

Новости

Пользователи «ВКонтакте» на полчаса получили доступк инструментам администрации соцсети после сбоя.

Снова про багокнопкив iPhone.

Почитать

Освоение тестирования REST API.

Ловушки мышленияв тестировании.

Советы сеньоров: как прокачать знания Junior QA.

Особенности тестирования интернет-магазинов.

Как устроено тестированиеу разработчиков КОМПАС-3D.

Особенности тестирования веб-приложений.

Хороший перевод статей и книг известных иностранных тестировщиков. В этот раз «Эффективное применение комбинаторных техник тест дизайна».

Записи докладов с конференции Heisenbug.

Требования к паролям — полная чушь.

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

Чек-лист тестирования веб-приложения.

Подходы к тестированию Internet of Things.

Как исследовать намеренно: самоуправление в исследовательском тестировании.

«Задача тестировщика — не получать удовольствие»: каково работать QA в GameDev.

Контроль качества в играх-сервисах.

Суровая жизнь тестировщика игр.

Резюме IT-специалиста: разбор типичных ошибок с точки зрения HR.

Кто такие тест-дизайнеры и зачем они нужны.

Подборка лучших Android-приложенийдля взлома и тестирования безопасности.

Системный подход к тестированию Android-приложений, или О чем молчали разработчики.

Откуда взялись в Google ненадёжные тесты.

Сложности тестирования IoT-устройств.

Про хранение и учет мобильных устройств в статье «Зачем в команде мобильной разработки появился сейф под управлением Windows 10».

Автоматизация

Небольшая книга «Всё, что вам нужно знать о форматах отчётов в тестировании ПО».

Проблемы тестирования: почему 100% покрытие кода — это плохо.

Automation QA — это отдельная команда?

Selenium: done in 60 seconds.

Кодогенерация, Selenoid, HtmlElements в работе автотестировщика.

Настройка автоматического разворачивания независимых development окружений на одной машине (Docker, Ansible, TeamCity).

Как писатьавтотесты быстро.

Как писатьпроверки быстро.

Автоматизация мобильных приложенийс SeeTest Automation.

Как устроено автоматическое тестированиев Почте Mail.Ruпод iOS.

Топ 10 инструментовдля мобильного тестирования.

Запуск Gatling через Gradle.

Юмор

Кратко о разработке игр:

Научно-технический рэп — Дедлайн:


Все желающие делиться интересным — пишите на почту salnikov.maksim@gmail.com, обсудим, опубликуем, скажем спасибо. :)


← Предыдущий выпуск: QA дайджест #26

Viewing all 7751 articles
Browse latest View live




Latest Images