[Об авторе: Эдуард Рубин, сооснователь харьковского ИТ-кластера, депутат Харьковского облсовета, инициатор ряда независимых образовательных проектов]

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

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

Почему это важно

Программа была принята еще в апреле 2016 года и не предполагала вообще никакого соучастия айтишного сообщества. Заниматься ее реализацией должны были Управление массовых коммуникаций облгосадминистрации и областное коммунальное предприятие «Харьковские областные коммуникационные системы». Всё!

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

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

Зачем вообще нужна эта программа

Харьков хорошо известен как один из лидеров национальной ИТ-индустрии, но вот ситуация в Харьковской области кардинально другая. Ее информационное развитие сильно запаздывает, и жители сельской местности часто лишены доступа к интернету, а значит, и ко многим современным сервисам, в том числе государственным. Читателям DOU это, возможно, покажется удивительным, но в Харьковской области лишь 36 из 100 жителей имеют доступ к интернету, в то время как в самой благополучной в этом смысле Одесской области, например, показатель охваченности интернетом составляет 87 на 100 жителей. Понятно, что одна из ключевых задач программы — развитие современных телекоммуникационных сетей в сельской местности.

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

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

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

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

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

Предложения принимаются

С текстом программы «ИТ-Харьковщина» можно ознакомиться на сайте Харьковского областного совета. Любые конструктивные идеи от читателей DOU, естественно, приветствуются. Как соучредитель ИТ-кластера и депутат областного совета постараюсь продвигать все рациональные идеи.

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

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

[Оригинальные данные и скрипты обработки можно взять на GitHub]

В опросе принял участие 7361 человек, 90% участников проживают в Украине.

Коммерческое использование

Тройка лидеров не изменилась. Go и TypeScript впервые вошли в десятку самых используемых, а Clojure — в двадцатку.

А вот динамика последних лет:

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

JavaScript по-прежнему растет, но темпы его роста значительно замедлились. Впрочем, картинка меняется, если вспомнить, что TypeScript является расширением JavaScript. Тогда видно, что суммарные темпы роста JavaScript/TypeScript остаются те же.

Доля C# так же медленно понижается, как и раньше. Доля Python растет, он уже однозначно стал доминирующей платформой в Data Science.

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

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

Переход iOS разработки на Swift более или менее предсказуем: если в прошлом году Swift использовала где-то половина iOS разработчиков, то в этом году — 76%.

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

Еще примечательно возрастание доли Kotlin практически с нуля до почти одного процента. Вероятно, это связано с тем, что Google приняла его официальным языком разработки в Android.

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

Личные предпочтения

Тут мы видим похожую ситуацию. Разве что уменьшение доли Java более стремительное, как и увеличение доли Kotlin. То же самое с JavaScript и TypeScript.

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

Также можно отметить «вторую волну» интереса к Rust и наличие ядра сторонников Erlang.

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

Тут тоже интересно: Swift и Kotlin стали практически безальтернативным выбором для iOS и Android соответственно. Следующий предпочитаемый язык — Go, а затем уже фавориты предыдущих лет: Scala, C#, Clojure.

Языки, которые пользователи предпочитают не использовать в следующих проектах: Groovy, Objective-C, 1C, Apex.

Изучение новых языков

Большая часть опрошенных (52%) точно планируют изучить какой-то новый язык программирования в следующем году; еще 30% не уверены. Какие языки интересны для изучения — можем уже сказать в динамике за 2 года:

Фаворит изучения этого года — Python, также будут смотреть на Go, TypeScript, Kotlin. Есть люди, еще не знакомые с Java и JavaScript.

По-прежнему большинство респондентов (57%) собираются осваивать новый язык самостоятельно с помощью книг и документации, не прибегая к курсам. Онлайн-курсы будут смотреть 30%, а к помощи офлайн-курсов с преподавателями прибегнут 8%.

Дополнительные языки

Главный дополнительный язык — JavaScript, также активно используется Unix Shell. Как и прежде, возросла доля процедурных расширений SQL (PL-SQL и T-SQL) и добавился TypeScript.

Свои проекты

Тенденции, в принципе, повторяются. В какой-то мере сюрприз — увеличение количества своих проектов на PL-SQL. Возможно, мы таки увидим замену 1C ;) Также немножко больше начали писать на C.

Финальная таблица

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

Дополнительные данные

Возраст разработчиков в зависимости от языка:

Самая молодая тусовка — по-прежнему Kotlin. Медианный возраст — 24 года, 27 — для Java разработчиков, 28 и 29 — для Go и Scala соответственно. А самые взрослые — разработчики на Pascal/Delphi, тут медианный возраст превышает 37 лет.

Посмотрим на зависимость между языком и опытом работы:

Особых аномалий нет — люди приходят в программирование через JavaScript (и немного R, наверное работая с Data mining). Perl, Pascal/Delphi (и, вероятно, в недалеком будущем — PL/SQL) — потенциальная область риска.

Общие данные по опыту работы:

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

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

Есть ли разница в использовании языков у нас и за границей?

Разница довольно большая. Видно, что за границей больше пишут на Java, Go и Scala и меньше — на JavaScript, PHP и C#. Впрочем, там характеристики опыта и возраста аудитории тоже другие, так что механически переносить результаты нельзя.

Распределение возрастов:

Образование

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

Мы видим, что от Pascal/Delphi постепенно уходят, также больше людей пишут свои первые программы на C++ (больше, чем на Java). Поэтому есть надежда, что вместо позавчерашних технологий студенты будут осваивать вчерашние ;)

Результаты предыдущих опросов: 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017.

В заключение — давайте сделаем еще один опрос:

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

• на украинском
• на русском
• на английском
• мне все равно.

Ответы оставляйте в Google-форме.

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

Ідея

Привіт. Мене звати Олексій Малицький, я СЕО проекту Octogin. Це плагін, який контролює рекламу (Ad controller). Наш проект почався з дуже класичного для українців старту, коли урвався терпець. Рік тому я працював у діджитал-агенції, і для мене важливо було моніторити та оцінювати рекламу. І кожного разу, коли я вимикав Ad Blocker, на мене нападали «монстри», які хотіли захистити від вірусів, «Форекс» вперто намагався зробити з мене мільйонера, а Ванга вкотре торочила про близький кінець світу. Повний треш.

Якось я зайшов на сайт Forbes, де було прохання відімкнути Ad Blocker, адже на гроші рекламістів журналісти створюють свій контент, аби бути не залежними від бізнесу. Ти вмикаєш Ad Blocker, і журналіст не отримує оплату своєї праці. Ad Blocker має 600 мільонів завантажень, можна тільки уявити, скільки грошей недоотримали контент-мейкери. Так я почав думати про варіант win-win для користувачів, видавців та рекламістів.

Улітку 2017 року я зібрав команду і восени ми запустили першу бету.

Реалізація

Octogin розроблений на платформі Firebase. Наше перше MVP було у вигляді гейміфікованого маркету: юзер завантажує наш плагін для Chrome, вимикає Ad Blocker і за перегляди реклами отримує «бонуси», які він може тут же обміняти на квитки у кіно, передати їх у фонд «Таблеточки» чи притулок для тварин «Сіріус» або переказати комусь із друзів. У першій беті ми хотіли перевірити гіпотезу, чи готові користувачі вимикати Ad Blocker заради таких «бонусів». Виявилося, що так. Ми отримали 400 перших завантажень.

Вся система гейміфікованого маркету побудована на прозорій системі транзакцій, в якій кожен користувач може переглянути будь-яку транзакцію. Ланцюг транзакцій побудований за технологією validity-chain, в якій дані кожної транзакції мають у собі захешовану суму цієї і попередньої (мінус хеш) транзакції в сервісі. Ми надамо сервіс, на якому людина може переглянути всі транзакції, перевірити одну зі своїх або весь ланцюг транзакцій. Таким чином, всі будуть прозоро бачити, що дані не були втрачені і що «бонуси» у Петрика не з’явились з повітря. Але це були дуже символічні бонуси, за місяць близько 200 грн. І цінність установлення Octogin була лише в отриманні «бонусів».

Аби знайти новий півот для Octogin, ми поїхали на Web Summit. До речі, були єдині з українських стартапів, які увійшли з 2000 проектів до списку 200 (Арена), з правом пітча перед журі. Також корисними для нас стали поїздка у Долину та участь у Google Launchpad.

Ми виправили проблеми першої бети, пов’язані з функціями і їх обривання без будь-якої причини чи логування, обмеженням в можливій виборці з БД, а також обмеженням в кількості одночасно під’єднаних користувачів (100 000). Зараз ми розділяємо всі частини системи на сервіси і переходимо на новішу систему FireStore, яка не повинна мати проблем з кількістю з’єднань. Також додаємо новий функціонал, який базується на відгуках вибірки користувачів.

Результат

Octogin — це у першу чергу Ad controller, адже він дозволяє користувачу впливати на рекламу, на її якість та таргетинг. А вже потім маркет, який дає бонуси за рекламу. Головна ідея, яку ми реалізовуємо у цьому проекті, — це створити систему win-win: юзерам — контроль та участь, а не пасивне споживання, видавцям — менше збитків через Ad Blocker, а рекламістам — highly convertible мережу (якщо користувачу цікаві івенти, а не праски, то за допомогою Octogin рекламісти будуть показувати релевантний контент, а бюджети не будуть зливатися).

Ad Blocker — це позиція пасиву, адже ми маємо постійно ховатися, тікати від реклами. Також це «пасивне піратство», коли ми не платимо за крутий контент, який живе за рекламу. А судячи з темпів розвитку ad tech, тенденції такі, що реклама буде нас знаходити у найнесподіваніших місцях. Постійно ховатися — це пасивна поведінка. Ми хочемо мати голос і мати право самим визначати, яку рекламу можемо дивитися, а яку банити. Ad controller Octogin — це активна позиція — впливати та контролювати рекламу, її якість, таргетинг і отримувати бонуси за це.

Плани на майбутнє: запустити нову бету, яка матиме удосконалену систему визначення релевантності реклами — personal rank (можливо, на основі АІ) та інтерактивне голосування, допрацювати гейміфікацію маркету, відкрити АРІ, реалізувати півот — запуск на одному українському сайті Octogin, пройти до американського акселератора та отримати pre-seeds.

П’ять років тому я закінчила бакалаврат механіко-математичного факультету КНУ. Хотіла займатися застосуванням математики у реальному житті, тому почала шукати можливості для подальшої освіти. Тоді в Україні ще ніхто не говорив, що Data Science — це професія XXI століття, і програм відповідно не було. Тому я почала шукати можливості освіти за кордоном. Обрала дворічну магістерську програму «Mathematics for real-life systems» у Швеції та Англії. У статті поділюся власним досвідом, як здобути стипендію та що я робила після закінчення навчання.

Почала я з пошуку у гуглі за запитом «математика, магістратура, стипендія». З нього критично відібрала програми, на які точно не підходжу за критеріями або які потребують хоча б якогось фінансового внеску. Зрештою подала документи на три програми Erasmus Mundus,які дозволяють навчатися в 3-4університетах та отримати диплом в усіх. Позитивну відповідь отримала з двох програм.

Пріоритетною для мене була програма «Прикладне застосування математики в реальному житті» (mathematics for real-life systems). Здебільшого це те, що ми називаємо штучним інтелектом, а також деякі фізичні застосування, як квантова механіка чи динамічні системи. Місця навчання можна було обирати самостійно із запропонованого списку країн і закладів. Перший рік я навчалася в університеті Чалмерс — найкращому технічному університеті Швеції. Другий — в університеті міста Уорвік в Англії, який досить відомий у математичному середовищі, зокрема, там викладає один із останніх лауреатів премії Філдса Мартін Хаїрер.

Як податися

Вступати на такі програми може кожен незалежно від віку або досвіду. Вибір спеціальностей досить широкий: знайде себе і відеооператор, і спеціаліст з тропічних лісів. Із цьогорічних прикладів IT-спеціальностей можу навести «Big Data Management and Analytics»або «European Master in Embedded Computing Systems».

Для подачі треба підготувати резюме, рекомендації викладачів, мотиваційний лист, підтвердження знань англійської, переклади дипломів. Жодних вікових обмежень нема — були успішні випадки вступу за 60 років, середній вік з мого досвіду — близько 27 років. Мені було 20. Нормально сприймається зміна професії: ніхто не очікує, що з першого разу ви знайшли себе. Хоча якщо ця зміна різка, треба обґрунтувати своє бажання.

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

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

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

Розмір стипендії

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

Розмір стипендії Erasmus Mundus можна переглядатина сайтівибраної програми. Зазвичай це 1000 євро в місяць + разова виплата 2000 євро кожний семестр + вартість страховки. До того ж стипендія не оподатковується. Разом виходить 16 тисяч євро нетто в рік, що в багатьох країнах є еквівалентом заробітку джуніора (це з тримісячною літньою відпусткою і ще місячною різдвяною). Стипендії зазвичай достатньо, навіть для людей, які їздили зі своїм партнером.

Навчання

Перший рік магістратури я провела у місті Гетеборг (Швеція) в університеті Чалмерс. Усі предмети можна було вибирати самій, нема жодних обмежень, (можна навіть обирати курс з іншого факультету по біології або хімії). Але все-таки ми всі приїхали вивчати штучний інтелект.

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

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

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

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

Для групових проектів в університеті можна самостійно вибирати, чим команда хоче займатись, і тому ми брали участь в онлайн-змаганнях: Hackerrank, Topcoder, Kaggle. Не скажу, що вдалося щось виграти, але це дало можливість пройти через певні стандартні помилки, коли ціна була малою. Одного разу, наприклад, ми дуже недооцінили час на виконання програми, і найнижча оцінка часу для її завершення, навіть із доступним від університету суперкомп’ютером, становила близько 6 років.

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

Типовий краєвид Англії

Під час навчання нас не обмежували у виборі мов програмування. Переважна більшість для мене — це Python (і його пакети Pandas, SciPy, Scikit, NLTK чи Gensim — для тексту, StatsModels, OpenCV — для зображень, Bokeh i Seaborn — для візуалізації). Також не можна не згадати магію Jupiter i Django. Часом користуюсь R, MATLAB, VBA i SQL.

В обох університетах були суперкомп’ютери, на які можна було завантажувати складні для обчислення завдання, як, наприклад, моделювання клімату. Спілкування з ними велося UNIX-командами, а самі програми писали на С++. Тут важлива швидкість, тому Python не підходив. Однак це доволі низькорівневі обчислювальні програми, де математичних С++ бібліотек більш ніж достатньо.

Лекційне навантаження дуже мале: 3-4години на тиждень із предмету, а предметів 2-3.Часу вистачає для того, щоб, скажімо, трохи попрацювати: віза зазвичай дозволяє не більше 20 годин у тиждень, але більше вам і не вийде. Я мала невеликий підробіток прямо в університеті: перевіряла екзамени, проводила практичні заняття для бакалаврів. Така робота коштує біля 20 євро в годину, але з цієї діяльності вже відраховують податок + потрібно оформити документи.

Ще можна отримувати незалежні гранти від університету. В основному вони надаються під конкретну ціль, потрібну для навчання: участь у конференції (я таким чином їздила в Ріо-де-Жанейро, Единбург і Оксфорд), купівля книг чи комп’ютерних штучок. Тут головне — бути в курсі, коли така можливість з’являється, тож не зайве бути друзями з адміністрацією чи хоча б активно читати оголошення.
Студенти — дуже незалежні і мотивовані. Мало хто прийшов у магістратуру відразу після бакалаврату. Це історії, коли люди попрацювали, зрозуміли, що їм цікаво, та свідомо пішли вчитися далі.

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

Житло

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

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

На другий рік навчання в Англії вирішила шукати житло самостійно. Якби не вдалося його знайти, університет взяв би це на себе. Але знайшла досить легко: 300 фунтів (400 євро) за місячну оренду кімнати, від якої до університету 15 хвилин їзди велосипедом.

Враження

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

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

Вільний час

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

Групова поїздка в Ліверпуль

У Лондоні мені сподобалася доступність і різноманітність IT-подій. Зустрічі, тренінги, майстер-класи, конференції, лекції, хакатони проводилися щодня, а на вихідних взагалі треба було вибирати з десяти цікавих опцій. Я, мабуть, побувала в усіх офісах великих компаній та познайомилася з більшістю місцевих зірок Data Science. Найбільш пам’ятною для мене була лекція Андрiя Карпатого, тоді аспіранта MIT, працівника Deep Mind і Open AI, а тепер Director of AI в Tesla. Також він автор онлайн-курсу «Stanford’s CS231n» і взагалі багато зробив для сучасних Convolutional Neural Networks. Я довго читала його блог, тому лекції були абсолютним «вау». Він нереально харизматичний і розповідає з таким натхненням, що після зустрічі хотілося прийти додому і програмувати всю ніч.

Також я активно брала участь в аналітичних хакатонах. Найпам’ятнішим є мій перший раз в ролі капітана — це було змагання від Transport for London (TfL). Ідею для розробки взяла з власного досвіду. У мене завжди була проблема з тим, як планувати свою подорож у метро: наприклад, якщо я виходила з дому о 8:00, то добиралася до місця стажування о 8:45, але при виході в 8:15 добирання розтягувалося на півтори години. Усе тому, що люди будуть чекати наступний потяг, а не штовхатися і влазити, і в такій черзі можна простояти довго.

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

Висновки

Магістратура була для мене дуже корисною, але не так тому, що це було за кордоном, а тому що Data Science, на мою думку, важко навчитися самостійно. Особливо для тих, хто хоче займатися саме розвитком методів (тобто в планах — аспірантура чи робота в DeepMind). Головною була атмосфера. Зараз бачу схоже до мого тодішнього середовище в УКУ: нічні посиденьки в бібліотеках, власні проекти, мотивація.

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

Канікули в Ютакані, Мексика. Одне з 7-мичудес світу

Плани

У січні 2016-гомоє навчання закінчилося. Після цього півтора року я пропрацювала в консалтинговій компанії McKinsey and Company, в практиці Advance Analytics. Займалася застосуванням методів штучного інтелекту для потреб бізнесу. У мене були різноманітні проекти: від нелінійної оптимізації в логістиці до предикативних моделей у сфері маркетингу і продажів.

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

Це прозвучить банально, але світ насправді такий великий і неймовірний! Я була в 50 країнах, в тому числі проїхала Казахстан, Узбекистан, Киргизстан, Індію, Індонезію, Малайзію та Бруней, Австралію, нині перебуваю на Фіджі. Попереду — Нова Зеландія, ще Австралія, Гаваї та інші штати. Можна слідкувати за мною в Instagram.

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

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

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

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

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

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

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

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

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

— Флейта була вашим першим саморобним інструментом?

Спочатку була спроба виготовити власну сопілку. В принципі я знав, що можна зробити свисток і що довжина трубки до отвору відіграє роль резонатора, але на практиці все виявилось набагато складніше. Тоді я вирізав гілочку з бузини, тому що там м’яка серцевина, але не зміг зробити навіть свистка. До спроби видути перший звук на своїй бамбуковій флейті відтоді пройшло 3-4 роки.Мабуть, тому я і почав першими робити бансурі.

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

— Які ще інструменти пробували робити власноруч?

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

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

Калімби та флейти, виготовлені Андрієм

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

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

— Наскільки складно навчитись самотужки виготовляти вироби належної якості?

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

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

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

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

Процесс виготовлення калімби

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

— А як з’явилась ідея прикрашати вироби етнічними орнаментами?

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

— Чи складно грати на калімбах, флейтах, варганах? За який час можливо опанувати гру?

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

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

Наступна за складністю опанування — дримба (варган). Треба зрозуміти, як притискати деко до зубів, як зробити резонатор з ротової порожнини і як не пошкодити зуби, губи та язик. На це в мене пішов десь тиждень.

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

Звичайно, як то кажуть: «Немає меж красі візерунку». Щоб навчитися професійно грати, треба цьому приділяти майже весь свій час. А може, й навіть все життя.

— А на яких ще інструментах ви граєте?

Якщо говорити про світ професійних музикантів, то я до нього не входжу :) Тобто я не вважаю себе професійним музикантом. Дуже великий поштовх мені дало навчання в музичній школі. І хоч, як я казав, закінчив лише 2 класи, і це все відбувалося, коли мені було 8 років, але я і зараз пам’ятаю те, що грав на екзамені. А головне — це основи сольфеджіо. Саме ці основи допомогли мені опанувати більшість інструментів, на яких я хоч трохи вмію грати.

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

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

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

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

Звучання калімби

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

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

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

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

— Чи багато в Україні музикантів, які цікавляться калімбами, флейтами, сопілками та їх виготовленням? Чи є якась спільнота?

У світі професійної музики існують серійні професійні інструменти, які зарекомендували себе як надійні і доступні для ремонту та заміни. Калімба — не дуже популярний інструмент на сцені в Європі. Така сама ситуація з бансурі. Музиканти надають перевагу оркестровій флейті.

З сопілками в Україні набагато краще. Особисто я знаю двох сопілкарів, які масово виробляють дерев’яні інструменти з хроматичним звукорядом (10 отворів, всі пальці зайняті). Такі користуються попитом в більшості українських ансамблів. Але я виготовляв або діатонічні (6-7 отворів),або пентатонічні (4-5 отворів)сопілки з бамбука. І хоча налаштовував за допомогою тюнера, і багато мелодій можна зіграти, але вони більше підходять для імпровізацій.

— А на ваші послуги великий попит? :)

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

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

Ярмарка в Пирогово, квітень 2016

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

— Що можете порадити новачкам, які збираються опанувати гру чи вперше самостійно виготовити інструмент?

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

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

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

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

— Що плануєте надалі? Як розвиватимете своє хобі?

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

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

Authority как понятие власти связано с легитимной частью и чаще применяется назначенными, чем лидерами.

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

Какая бывает власть

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

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

1. Экспертная (expert) — основывается на обладании знанием (пример: джедай).
2. Поощрительная (reward) — за желаемый результат нам предлагают вознаграждение (пример: «женись на мой дочке, я тебя принцем сделаю»).
3. Легитимная / позиционная (legitimate) — проистекает из положения/позиции человека в организации (пример: царь).
4. Власть по принуждению (coercive) — поступки совершаются под угрозой негативных последствий (пример: государство пугает народ терроризмом).
5. Референтная (referent) — власть через ассоциацию с другими людьми, обладающими властью, или через умение нравиться (пример: «а ты знаешь, кто мой папа»).

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

Что делать

В силу специфики работы, я отвечаю за успешную сдачу проектов. Все было бы более-менее, если бы не одно «но»: в компании, где я работаю TPMом (Technical Program Manager), моя позиция относится к ряду individual contributor (IC). Это значит, что мне никто не подчиняется, и, соответственно, легитимной власти мне не видать. Выжить в такой ситуации мне помогают другие типы власти и несколько проверенных лайфхаков, которыми я хочу поделиться с вами (этот список пополняется по мере получения опыта).

Завоюйте доверие («Earn Trust»)

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

Покажите вашу ценность.Никто не ожидает, что у вас будут ответы на все вопросы, но понимание структуры компании, доменной области, текущих и потенциальных рисков, зависимостей — это необходимый минимум для позиционирования себя в качестве профессионала и завоевания доверия коллег. И не забудьте про демонстрацию результатов своей работы: закрытых задач и накопленных знаний в подходящей для того обстановке, чтобы о вас знали, к вам приходили за советом и к вам прислушивались. Если у вас есть желание и возможность проводить парные обучающие сессии (типа pair programming) или технические обсуждения (tech talks, brownbags, learning series), где вы можете поделиться своими знаниями или опытом — это окупится.

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

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

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

Сделайте так, чтобы было легко ответить «да»

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

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

Я сторонник data-driven подхода, когда в качестве аргумента используются метрики/данные, подтверждающие или опровергающие какую-то точку зрения. Часто вместо «мне кажется, ты не прав», можно более конструктивно объяснить, что именно неправильно — без лишних эмоций. Например, клиентские метрики показали, что только 5% юзеров используют такую-то фичу, так что ее можно убрать.

Бонус

Рекомендуемые ресурсы для тех, кто хочет развивать софт скиллы:

• PMI: Influence without Authority, Science of Influencing Others
• LinkedIn Post: Influencing without Authority
• Книги: «Results without Authority», «Getting Things Done When You Are Not in Charge»

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

Привет, DOU. Меня зовут Андрей Данильченко, я PHP-разработчик в Wikr Group. В этой статье расскажу о рефакторинге.

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

Когда нужен рефакторинг

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

Итак, что значит «упростить понимание работы программы»? Конкретные цели рефакторинга могут быть такими:

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

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

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

Что именно рефакторить

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

Повторы

Допустим, у нас есть такой фрагмент:

$dto
    ->setId($data['id'])
    ->setTitle($data['title'])…
    ->setCreatedAt($data['createdAt']);

Решение — реализовать гидратор:

$hydrator->hydrate($data, $dto);

Метод гидратора:

public function hydrate(array $data, $object) : void
{
   foreach($data as $property => $value) {
       $setterName = 'set' . $property;
       if (method_exists($object, $setterName)) {
           $object->{$setterName}($value);
       }
   }
}

Комментарии

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

Пример:

$data = $this->getData($cursor);

// put data to csv
foreach ($data as $row) {
	fputcsv($file, $row);
}

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

$data = $this->getData($cursor);
$this->putDataToCsv($file, $data);

Условные выражения

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

Пример:

class ErrorResponsePart implements ResponsePartInterface
{
   /**
    * Error response part data.
    *
    * @var ResponseDtoInterface $partData
    */
   private $partData;
   /**
    * {@inheritdoc}
    */
   public function addData(ResponseDtoInterface $data) : void
   {
       if ($data instanceof ErrorDtoInterface) {
           $this->partData = $this->format($data);
       }
   }
   /**
    * Prepares response data.
    *
    * @param ResponseDtoInterface $data
    */
   public function format(ResponseDtoInterface $data) : void
   {
        if ($data instanceof ListDataDtoInterface) {
            $formatted = $data->getListData();
        } elseif (/* some expressions */) {
            // some logic
        } elseif (/* some expressions */) {
            // some logic
        }
       return $formatted ?? $data;
   }
}

Решение — вынести if из метода addData в спецификацию. А метод format — в отдельный класс, применив стратегию:

class ErrorResponsePart implements ResponsePartInterface
{
   /**
    * Specification.
    *
    * @var SpecificationInterface $specification
    */
   private $specification;
   /**
    * Response part data.
    *
    * @var ResponseDtoInterface $partData
    */
   private $partData;
   /**
    * Formatter context.
    *
    * @var FormatterContext $formatterContext
    */
   private $formatterContext;
   /**
    * ErrorResponsePart constructor.
    *
    * @param SpecificationInterface $specification
    * @param FormatterContext $formatterContext
    */
   public function __construct(SpecificationInterface $specification, FormatterContext $formatterContext)
   {
       $this->specification = $specification;
       $this->formatterContext = $formatterContext;
   }
   /**
    * {@inheritdoc}
    */
   public function addData(ResponseDtoInterface $data) : void
   {
       if ($this->specification->isSatisfiedBy($data)) {
           $this->partData = $this->formatterContext->process($data);
       }
   }
}

Спецификация c бизнес-правилами:

class ErrorSpecification implements SpecificationInterface
{
   /**
    * {@inheritdoc}
    */
   public function isSatisfiedBy(ResponseDtoInterface $object): bool
   {
       return $object instanceof ErrorDtoInterface;
   }
}

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

class FormatterContext
{
   /**
    * Formatters.
    *
    * @var FormatterInterface[]
    */
   private $formatters;
   /**
    * FormatterContext constructor.
    *
    * @param FormatterInterface[] $formatters
    */
   public function __construct(array $formatters = [])
   {
       $this->formatters = $formatters;
   }
   /**
    * Format response data part.
    *
    * @param ResponseDtoInterface $data
    * @return mixed
    */
   public function process(ResponseDtoInterface $data)
   {
       foreach ($this->formatters as $formatter) {
           $data = $formatter->format($data);
       }
       return $data;
   }
}

Конкретная стратегия:

class ListDataFormatter implements FormatterInterface
{
   /**
    * Checks object for needed requirements.
    *
    * @var FormatterSpecificationInterface $specification
    */
   private $specification;
   /**
    * ListDataFormatter constructor.
    *
    * @param FormatterSpecificationInterface $specification
    */
   public function __construct(FormatterSpecificationInterface $specification)
   {
       $this->specification = $specification;
   }
  /**
   * {@inheritdoc}
   */
  public function format(ResponseDtoInterface $data)
   {
       if ($this->specification->isSatisfiedBy($data)) {
           $data = $data->getData();
       }
       return $data;
   }
}

Спецификация для форматера:

class ListDataSpecification implements FormatterSpecificationInterface
{
   /**
    * {@inheritdoc}
    */
   public function isSatisfiedBy(ResponseDtoInterface $object) : bool
   {
       return $object instanceof ListDataDtoInterface;
   }
}

Непонятные имена

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

Пример:

$fl = count($data) >= ExportBag::LIMIT_PER_FILE;

Заменяем на:

$isExceededLimitPerFile = count($data) >= ExportBag::LIMIT_PER_FILE;

Большие методы, классы

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

Длинный список параметров

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

Наследование

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

Цепочки сообщений: несоблюдение закона Деметры

Закон Деметрыговорит, что любой метод любого объекта может вызывать методы только из:

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

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

Пример:

$postService->getTemplateResolver()->getName();

Заменяем на:

$postService->getTemplateName();

Статика

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

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

Внешние зависимости, оператор new

Все внешние зависимости передаются в конструктор через DI. Если нам нужны объекты с состоянием, которые не можем инжектить через DI (Newable, Transient objects), то используем фабрики. Фабрики инкапсулируют все сложные операции сборки объекта. При этом фабрику инжектим в класс через DI.

Пример:

$delimiter = '|';
new CsvFile(delimiter);

Заменяем на:

class CsvFileFactory implements FileFactoryInterface
{
   /**
    * {@inheritdoc}
    */
   public function createFromArray(array $params = []) : FileInterface
   {
        $delimiter = $params['delimiter'] ?? CsvFile::DEFAULT_DELIMITER;
        return new CsvFile(delimiter);
   }
}
$fileFactory->createFromArray(['delimiter' => '|']);

Универсальные объекты

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

Вместо этого инжектим только нужные нам зависимости.

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

Пример:

public function updateAction() : Response
{
    return $this->get('app.user_handler.service')->handle();
}

Заменяем на:

public function updateAction(UserHandler $userHandler) : Response
{
    return $userHandler->handle();
}

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

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

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

В выпуске: реверс-инжиниринг home индикатора на iPhone, топ причин реджекта приложений в App Store, линтера для IB и xcodeproj, лучшие статьи по юнит-тестированию за 2017, менеджер пакетов для Swift.

Статьи

Reverse-Engineering the iPhone X Home Indicator Color
Лонгрид с исследованием того, как меняется цвет iPhone X home. Самого реверс-инжиниринга почти нет (см. следующую статью). Из интересного — цвет в симуляторе отличается от цвета на реальном девайсе.

iPhone X home button
И еще одна статья про iPhone X home indicator. На этот раз реверс-инжиниринг самой реализации. Не бойтесь и осваивайте Hopper Disassembler, чтобы посмотреть, как реализована та или иная вещь (в том числе и в нативных приложениях).

Face-controlled apps are here — and they are about to transform how we interact with our devices
Статья о том, как изменится взаимодействие со смартфонами с приходом приложений, которые отслеживают движение лица. Уже жду читалку, которая будет автоматически скроллить текст и подстраиваться под твой темп чтения.

The top reasons apps get rejected on the App Store
Самые популярные причины реджекта приложений в App Store. Не лишним будет просмотреть весь список требований, особенно если планируете релиз к определенной дате.

Functional architecture for Swift
В новый год с новыми архитектурами. Вдохновлена Reduxи RxFeedback.

RxFlow
Еще одна архитектура от создателей RxSwift. На этот раз вдохновлялись координаторами.

RIBs
Uber оформили в репозитории свою архитектуру. Доступен код сразу под Android, iOS, с примера как создать RIB, сделать композитный, а также есть Xcode file template.

The buddybuild team is now part of Apple
Никак не доходили руки попробовать этот CI, и уже не получится, потому что их купил Apple, и они закрыли регистрацию для новых пользователей (старые могут пользоваться до 1 марта 2018). Ждем улучшенного Xcode Server на ближайшем WWDC. Сразу появилась статья с альтернативами.

Build a Taylor Swift detector with the TensorFlow Object Detection API, ML Engine, and Swift
Интернет уже пестрит туториалами, как сделать приложения для распознавания чего-либо с уже готовой моделью. Тут же описано, как натренировать свою модель и использовать ее в приложении.

A complete list of articles on Unit Testing with Swift from 2017
Список самых популярных статей о юнит-тестировании за 2017 год. Статей много, поэтому можно использовать как справочник и искать по ключевым словам нужную статью ☝️

Smart Color Invert And Your iOS Apps
Не забываем и про accessibility. Статья о том, как адаптировать режим инверсии цвета в своем приложении.

Password autofill for iOS Apps for faster login
В iOS 11 появилась возможность вставлять пароль из Keychain прямо в приложении. Действий не так много, а пользователям удобно.

Cancellation Token
Cancellation Token — достаточно распространенный паттерн (используется в Bolts, RxSwift). Разбираемся, как создать, использовать токен, а также про альтернативы.

Tools

xcode.swift
Аккаунт организации, которая занимается tooling’ом. В их комплекте есть билд-система похожая на make, линтер и другие утилиты для работы с xcodeproj.

Mint
Менеджер пакетов для запуска скриптов на Swift. Такой себе Brew на свифте и для свифта.

topanga
Исходники джейлбрейка для iOS 11 (до 11.1.2).

IBLinter
Линтер для xib, storyboards. Попробовал на паре проектов — безрезультатно. Отпишитесь в комментах, если кому-то помогло.

Quicktype
Плагин для Xcode, который создает Codable структуру на основе JSON схемы.

Online Swift Playground
Теперь для изучения Swift достаточно только браузера. Пока в бете. Для участия надо зашарить пост и залогиниться через GitHub.

Beak
Писать скрипты на Swift теперь еще проще. Можно запустить любую публичную функцию прямо из терминала.

Неплохой совет — используйте `e` в lldv вместо `po`, чтобы вывести больше информации об объекте:

For the longest time I just used «po» in lldb to examine objects but «e» just adds a whole new level to debugging !November 23, 2017

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

У випуску: як використовувати Composer ефективно, curly bracket, PHP 7.2.1, функція monotonic timer.

Статті

Eliminating Visual Debt¯\_(ツ)_/¯

17 порадпро те, як використовувати компосер ефективно

Найпопулярніші помилкив коді на PHP на Stack Overflow або ТОР 10 security bugs

The end of Silex

What ORMs have taught me: just learn SQL

Що користувачі редіта /r/PHP вивчили за 2017 рік

PHP-DI 6: turning into a compiled container for maximum performances

Історія HTTP/2, PHP і Symfony [Слайди]

Deal with Memory Gently using «Yield» in PHP

Цікава стаття про curly bracket

Релізи

Composer 1.6.0

PHP-PH 1.0.0

PHP 7.2.1

PSR-15 has been Accepted

HHVM 3.24 (кінець підтримки PHP5)

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

Документація до PHP source code

Процес-менеджер на PHP для PHP

Open source API management platform

Різне

Для тих, хто цікавиться вивченням нових технологій та розширенням компетенцій. Тестуємо з топовими українськими розробниками формат онлайн-інтенсиву по Front-end. За 5 тижнів опануємо основи та напишемо зі студентами їх власний чат на React.

Doge.codes — тут всі деталі. Ціна першого набору дуже демократична, з 50% знижкою.

Онлайн-генератор Nginx конфігівдля різних випадків

В PHP 7.3 добавлять функцію hrtime() (monotonic timer), яка допоможе перемогти ліміти microtime(). Детально про monotonic timer можна прочитати тут.

Makefile для лінивих

Візьми участьу 2018 Developer Survey

Кого почитати

Marco Pivetta, популярний PHP розробник (Doctrine, Zend Framework)

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

С 20 декабря 2017 года по 25 января 2018 года мы проводили очередной анонимный зарплатный опрос, в котором приняли участие 8355 человек.

Исходные данные в CSV доступны на GitHub. Все зарплаты указаны в долларах США (по курсу межбанка), чистыми (после уплаты налогов). Для оценки зарплаты в выборках используется медиана. Статьи с результатами прошлых опросов здесь.

Портрет участников опроса

18,4% женщин, 81,6% мужчин. Доля женщин с каждым годом увеличивается:

См. также исследование о женщинах в IT.

Распределение анкет по возрасту, медиана — 27 лет:

Топ-7 городов: Киев (44,2%), Харьков (15,5%), Львов (12%), Днепр (7%), Одесса (5,1%), Винница (2%), Запорожье (1,6%). Удаленно работает 2,7% респондентов.

Уровень знания английского

Популярность должностей

Должности женщин

Должности студентов

Должности тех, кто работает удаленно

Средний возраст для разных должностей

Распределение возрастов Junior- и Senior-разработчиков:

Средний опыт работы для разных должностей

Популярность языков программирования

У Flex/Flash/AIR 6 анкет, у Erlang и Haskell по 2, у ABAP и APL по 1. См. также рейтинг языков программирования.

Среди тех, кто работает удаленно:

В стартапах программируют на:

Средний возраст разработчиков в зависимости от языка

Популярность вузов

См. также рейтинг вузов.

Распределение анкет по типам компаний

Распределение по предметным областям

Средние зарплаты по всем должностям

Зарплаты по городам показаны для должностей, у которых 10+ анкет:

Киев (развернуть)

Харьков (развернуть)

Львов (развернуть)

Днепр (развернуть)

Одесса (развернуть)

Зарплаты Java, C# и C++ разработчиков

В Киеве (развернуть)

В Харькове (развернуть)

Во Львове (развернуть)

Зарплаты Java не-Android и Java Android разработчиков

В Киеве (развернуть)

Зарплаты Objective-C и Swift разработчиков

Зарплаты PHP, Python и Ruby разработчиков

В Киеве (развернуть)

Зарплаты JavaScript разработчиков

Зарплаты QA

В зависимости от специализации (Киев)

Зарплаты сисадминов и DevOps-инженеров

Зарплаты менеджеров

Есливыбрать только тех PM-ов, у которых 3+ лет опыт работы и английский выше среднего или продвинутый:

Зарплаты выпускников вузов

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

Зарплаты студентов вузов

Показываются вузы с 10+ анкет:

Тип компании

Следующий график построен для Киева:

Предметная область и зарплата

Senior Software Engineer, Киев

Software Engineer, Киев

Junior Software Engineer, Киев

Динамика

Лучше всего смотреть страницу Динамиказарплатного раздела с интерактивными графиками. Вот несколько графиков оттуда (по всем городам):

Java

C#/.NET

C++

JavaScript

PHP

QA

Интерактивный зарплатный виджет:

Альтернативные виджеты: doustatistic.byethost7.com, devua.seektable.com

Раздел Зарплаты с подробной информацией: jobs.dou.ua/salaries.

Данные о количестве вакансий и откликов смотрите в разделе Тренды.

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

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

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

EIS Group

Напрям:курси Java, QA.
Місто:Одеса.
Дедлайн подачі заявок: 31 січня.

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

Java

• знання об’єктно-орієнтованої парадигми програмування;
• знання мови програмування Java;
• знання алгоритмів і структури даних;
• знання SQL;
• володіння англійською не нижче рівня Strong Intermediate;
• бажання вчитися, працювати в стрімко змінному середовищі та виконувати домашні завдання.

QA

• знання теорії тестування;
• добрі аналітичні навички;
• володіння англійською не нижче рівня Strong Intermediate;
• здатність присвячувати багато часу навчанню, працювати в стрімко змінному середовищі та виконувати домашні завдання.

Як потрапити:надіслати CV на hr_odessa@eisgroup.com, виконати тестове завдання та пройти співбесіду.

Умови:викладачі та куратори курсу — Middle та Senior інженери EIS Group, курс триває 3 місяці. Основний фокус спрямований на практичні завдання, розробку реальних проектів у командах під керівництвом кураторів. За умови успішного проходження курсу передбачено працевлаштування на позицію Junior.

EPAM

Тип:курси.
Місто:Львів, Харків.
Дедлайн подачі заявок:

• Java: Харків — 25 лютого
• DevOps: Харків — 25 лютого
• .NET: Харків — 25 лютого
• QA: Харків — 25 лютого
• Front-end: Харків — 25 лютого
• RPA: Львів — 14 лютого

Вимоги до кандидатів:знання алгоритримів і структури даних; ООП — рівень письмової та розмовної англійської не нижче В1 відповідно до Common European Framework of Reference for Languages. Також перевіряються аналітичні здібності та кмітливість при вирішенні нестандартних задач. Перевагою буде досвід роботи з БД, розуміння процесів тестування, розуміння роботи систем контролю версій. Для напрямків, що пов’язані з розробкою (Java, .NET, JavaScript), перевагою буде довід розробки будь-якою мовою програмування.

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

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

Netpeak Group

Напрям:курси Sales Management.
Місто:Черкаси.
Дедлайн: 18 березня.

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

• бажання стати Sales Manager в Ringostat;
• досвід продаж від 1 року;
• вміння правильно і чітко висловлювати свої думки без перевірки в MS Word;
• самодисципліна, щоб не прогулювати заняття та виконувати домашні завдання;
• готовність виділяти на навчання 6 годин на тиждень;
• готовність засвоювати багато інформації.

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

Умови:на курсі студенти отримають знання, необхідні для роботи в Ringostat на позиції Sales Manager. Тривалість курсу — 3 тижні. Він включає 9 занять, 8 домашніх завдань. У групі — до 7 студентів. Початок занять — 19 березня, розклад: понеділок, середа, п’ятниця — 18:00 — 21:00. Захист дипломів — 6 квітня. Після закінчення студенти отримують диплом, кращих працевлаштовують.

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

Product Crafters

Напрям:курси React/Redux.
Місто:Хмельницький.
Дедлайн: 1 лютого.

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

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

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

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

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

RubyGarage

Напрям:курси Ruby / Ruby on Rails.
Місто:Дніпро.
Дедлайн виконання тестового завдання: 1 березня.

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

• необхідні базові знання HTML, CSS, JavaScript та мінімальний досвід роботи з цими технологіями;
• бажано знання базових принципів роботи баз даних і мови SQL.

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

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

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

QATestLab

Напрям:онлайн-курси QA.
Дедлайн подачі заявок:реєстрація відбувається постійно. «Основи тестування ПЗ» — старт 5 лютого.

Вимоги до кандидатів:навчатися можуть усі охочі.

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

Умови:викладачi курсів — QAEngineers компанії QA TestLab. Формат навчання: онлайн. Тривалість курсу — 4 тижні. Курс включає в себе лекції, що проводяться через систему GoToWebinar двічі на тиждень, практичні домашні завдання та підсумковий іспит.

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

SimCorp

Напрям:курс «Introduction to APL».
Місто:Київ.
Дедлайн подачі заявок: 10 лютого.

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

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

Як потрапити:на пошту jobukr@simcorp.comнадішліть таку інформацію: в декількох словах поясніть, чому ви хочете долучитися до курсу; напишіть про вашу освіту — назва внз, факультет, рік навчання; практичний досвід у розробці, якщо він є. Бажано додати резюме.

Умови:курс триває з 15 лютого по 15 березня. Заняття (2 год кожне) — по понеділках і четвергах о 17:00 в офісі компанії.

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

Sintez Technologies

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

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

• знання загальної комп’ютерної термінології;
• розуміння базових принципів ООП;
• базове знання Java і середовища розробки (компіляція, запуск, налаштування).

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

Умови: 6 місяців; очне навчання три рази на тиждень по кілька годин у вечірній час; початок навчання — лютий. Можливе працевлаштування по закінченні.

Деталі:marina.zheleva@sintez.co.za.

SoftServe

Тип:курси.
Місто:Львів, Рівне, Чернівці, Харків, Івано-Франківськ, Київ, Дніпро.
Напрям та дедлайн подачі заявок:

• .NET: Львів — 2 лютого, Рівне — 5 лютого, Чернівці — 5 березня
• DevOps: Рівне — 2 лютого, Львів — 20 лютого
• Web-UI: Харків — 12 лютого, Івано-Франківськ — 12 березня
• WebUI/Ruby: Львів — 23 лютого
• WebUI/Python: Дніпро — 1 березня
• HTML5/ CSS3/ JavaScript: Чернівці — 5 лютого, Львів — 16 лютого, Рівне — 6 березня, Харків, Львів — 19 березня
• Software Engineering in Test: Львів — 2 лютого
• Test Automation: Харків — 12 березня
• ISTQB Practical Testing: Львів — 16 лютого
• Quality Control: Чернівці — 26 лютого, Івано-Франківськ — 5 березня, Львів — 23 березня
• Java: Київ — 5 березня, Львів — 9 березня, Івано-Франківськ — 11 квітня
• C++: Львів — 30 березня
• Golang: Харків — 17 квітня

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

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

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

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

Acceptic

Напрям:стажування PHP/JS.
Місто:Харків.

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

• базові знання PHP 5.4+, MySQL, SQL, HTML, CSS, JS, jQuery, AJAX;
• розуміння принципів ООП;
• бажання навчатися;
• відповідальність та дисципліна.

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

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

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

AMC Bridge

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

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

Як потрапити:надіслати резюме на сайті, пройти співбесіду із HR-менеджером, технічним інтерв’юером та директором дослідницького підрозділу.

Умови:стажування являє собою роботу на одному з проектів у внутрішньому дослідницькому підрозділі AMC Bridge строком на 1-2місяці з тижневою зайнятістю від 20 до 40 годин. Резюме має бути надіслано не пізніше, ніж за два тижні до офіційного початку практики у ВНЗ студента. В залежності від результатів проходження стажування, студента може бути рекомендовано до прийняття на роботу в компанію.

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

DataArt

Напрям:практикантські програми QA, .NET, Design, JavaScript.
Місто:Харків.
Дедлайн подачі заявок:програми відкриті постійно.

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

• студенти, починаючи з 3-гокурсу університету;
• теоретична база;

Як потрапити:надіслати резюме на пошту hr-kh@dataart.com, пройти співбесіду англійською, технічну співбесіду.

Умови:індивідуальний підхід, викладають працівники DataArt, беруть одну людину під одного ментора, є оплата та працевлаштування по завершенні.

Деталі:зверніться за контактами на сайтіабо пишіть на пошту hr-kh@dataart.com.

Fondy

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

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

• наявність математичної освіти;
• знання основ алгоритмічного програмування;
• досвід самостійної розробки будь-якого не складного проекту/завдання.

Як потрапити:надіслати резюме на hr@fondy.euта пройти співбесіду.

Умови:
Перший етап: 1-2місяці навчання без оплати; виконання завдань від керівника по реальним проектам компанії; навчання як самостійне, так і за підтримки спеціалістів компанії.

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

Lead Line IT

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

Вимоги до кандидатів:бажання навчатися; можна без профільної освіти — навчальні матеріали надаються.

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

Умови:за стажером закріплюється наставник. Стажування оплачується. Після закінчення можливе працевлаштування в компанії.

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

Leobit

Напрям:стажування .NET, iOS, Android, Java.
Місто:Львів.
Дедлайн подачі заявок:немає.

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

• технічна освіта (студент 4-5курсу або випускник) чи закінчені профільні курси;
• англійська — Intermediate+;
• аналітичне мислення;
• досвід роботи з такими технологіями:
  
  • для .NET — MVC, WPF, Xamarin;
  • для iOS — Swift;
  • для Java — Spring, Hibernate, Maven.

Як потрапити:надіслати резюме на sales@leobit.coз темю листа «Internship program» або подати заявку на сайті.

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

Quality Assurance Group

Напрям:стажування / виробнича практика QA.
Місто:Львів.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:курс можуть проходити усі охочі.

Як потрапити:подати заявку, заповнивши анкету, або телефонуйте (099) 376 65 05; (098) 903 64 45.

Умови:стажування повністю присвячене практиці. Студенти працюють з реальними проектами самостійно у групах під керівництвом координатора і таким чином отримують досвід роботи та напрацювання у якості прикладу своїх робіт. Робота проходить з баг-трекінговою системою Jira; Zephyr test management tool, Test Rail, Jmeter ect.

Sigma Software University

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

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

• JavaScript: Харків — 28 лютого
• JavaScript: Львів — 30 березня
• PHP: Київ — 16 лютого
• .NET: Харків — 31 січня
• QA: Харків — 31 січня
• Embedded: Львів — 28 лютого

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

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

Clockwise Software

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

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

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

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

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

Dinarys

Напрям:робота Front-end developer.
Місто:Дніпро.

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

• рівень розмовної англійської — Upper-Intermediate;
• базове знання HTML, CSS;
• увага до деталей.

Буде перевагою:

• досвід роботи з будь-якою CMS;
• позитивне мислення;
• досвід роботи з Jira.

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

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

GlobalLogic

Тип:робота.
Місто:Київ, Харків.

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

• .NET (Харків)
• Java (Харків)
• QA (Київ)

Як потрапити:подати заявку на сторінці вакансії, що цікавить.

Expercast

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

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

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

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

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

Деталі:на сайтіабо пишіть на пошту jobs@expercast.com. Посилання на вакансії: JavaScript, Ruby.

CMK

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

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

• рівень освіти — бакалавр;
• досвідчений користувач PC, Mac;
• будь-який досвід (можна некомерційний) у web/mobile/desktop тестуванні;
• високий рівень технічної англійської (читання, письмо).

Перевагою буде:

• розуміння теорії тестування програмного забезпечення;
• знання багтрекінгових інструментів (Jira, Redmine, HP QC, Mantis);
• базове знання будь-якої мови програмування.

Як потрапити:надіслати резюме на jobs@cmksoftware.com (обов’язково вкажіть ваші контакти та рівень володіння англійською), виконати тестове завдання (тестування додатка та перевірка англійської), пройти співбесіду.

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

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

N-iX

Напрям:робота Unreal Engine, .NET, Java.
Місто:Львів.

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

• Unreal Engine
• .NET
• Java

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

Smart Business

Напрям:робота Junior NAV Developer.
Напрям:Київ.
Дедлайн подачі заявок: 12 лютого.

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

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

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

Умови:кандидати проходять курс лекцій про MS Dynamics NAV development, вивчають загальну інформацію про Microsoft Dynamics ERP systems, беруть участь у кількох проектах. Кандидатам, які успішно завершать навчання, компанія запропонує працевлаштування.

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

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

Привет! Меня зовут Антон Авринский, и я расскажу про наш проект Liki24. Сервис помогает получить лекарства из аптек, не выходя из дома, да еще и на 20-30%дешевле.

Идея

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

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

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

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

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

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

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

Если подытожить, то я столкнулся со следующими проблемами:

1. Цены в аптеках космические, в разных аптеках цены могут отличаться в 2-3раза (может быть дороже на 100 и более грн).
2. В аптеках в большинстве случаев не все есть, приходится бегать между разными аптеками и искать, где же необходимые лекарства и где их можно купить дешевле.
3. В аптеках большие очереди, которые забирают кучу времени, и часто, отстояв 15-20 минут,узнаешь, что не все, что тебе нужно, есть в наличии.
4. В аптеки ходят в основном больные люди, поэтому находиться там — это опасно для здоровья, а тем более стоять в очередях.
5. Нам не удалось найти сервисов быстрой и удобной доставки лекарств с онлайн-оплатой. Те люди, которые по разным причинам не могут пойти в аптеку, вынуждены просить кого-то и создавать неудобства.

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

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

Команда, проверенная временем

Самым главным достижением в нашем проекте с первых дней стала наша команда. У нас есть опыт совместной работы. Со многими ребятами мы более 10 лет трудились в компании IT-Enterprise, где разрабатывали и внедряли систему управления производством, логистикой, продажами, финансами (ERP) для известных украинских и мировых компаний, таких как Interpipe, «Фармак», Roshen, «Лекхим» и многих других.

Команду мы усилили специалистами из разных отраслей, в первую очередь это опытные фармацевты, которые изнутри понимают фарм. рынок. Также к нам присоединились специалисты, которые прошли супершколу доставок в разных компаниях, таких как Domino’s, «Сушия», «Нова Пошта». На сегодня наша команда состоит уже из 19 человек.

Команда Liki24

Реализация

Очень символично, что мы придумали название Liki24 и официально в команде решили начинать работать над проектом 24 июля 2017 года.

Мы выбрали современный подход для реализации нашей идеи — сначала описали функциональность MVP (minimum viable product). Затем его максимально быстро реализовали. Самым сложным было отсечь весь тот поток «гениальных идей» и хотелок. Для нас всех самый главный критерий правильности нашего движения — это скорость. Нужно как можно быстрее реализовывать намеченное, как можно быстрее получать обратную связь от реальных пользователей и делать выводы.

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

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

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

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

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

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

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

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

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

Что под капотом

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

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

Мы понимаем, как важен хороший поиск для нашего сервиса, поэтому подключили Elasticsearch, который хостится в Kubernetesна Google Cloud Platformи переиндексируется каждую ночь.

Для бэкофиса мы используем собственную разработку — систему «Агонь» — это единственная система управления, которая используется в Liki24 и охватывает функционал для специалистов поддержки, менеджеров, сборщиков, комплектовщиков и курьеров. «Агонь» — это web-приложение с бекэндом на ASP.NET Core и Angular на фронте. Хостятся они на Azure, а для хранения данных используется MS SQL.

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

Задание курьеру для доставки (слева) и задание сборщику для покупки в аптеках (справа).

Как сервис работает для клиента

На www.liki24.comвводится необходимый препарат в строке поиска (кстати, тут мы применили эластику, можно даже искать с ошибками) и сразу отображается проверенная низкая цена на препарат в Киеве. Далее просто включаются в заказ все необходимые позиции либо сразу из поиска, либо со страницы продукта, на которой можно увидеть диапазон цен на препарат в аптеках Киева и размер экономии при заказе через Liki24.

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

Результаты

За первые месяцы открытого тестирования мы получили более 2 500 заказов, при этом около 20% клиентов заказывают повторно (а для нас это самый важный показатель), и доставили уже более 8 000 препаратов.

Карта доставок Liki24 за январь 2018

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

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

Что же получают наши клиенты? Это в первую очередь экономию времени, наш рекорд доставки заказа — 22 минуты! Также это, конечно, цена — одна из самых низких на розничном рынке (в среднем на 30% дешевле, чем в аптеке у дома). А еще удобство и сервис, мы работаем над проектом 24 часа в сутки. Те, кто использует Liki24, не переплачивают за лекарства и не стоят в очередях в аптеках.

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

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

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

• Junior — $500;
• Middle — $700;
• Senior — нет данных.

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

Компании

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

Mindy Supports

Международная аутсорсинговая компания
450 сотрудников в Полтаве, 1500 в Украине

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

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

Beetroot

Украинско-шведская аутсорсинговая компания
80+ сотрудников в Полтаве, 250+ в Украине

Компания занимается веб- и мобильной разработкой, UI/UX дизайном. Основные технологии: PHP, JavaScript, Python, iOS, .NET, QA, UI/UX, CMS (WordPress, Magento).

Возможности для начинающих специалистов:есть стажировка для желающих понять специфику работы в IT изнутри. Также в компании работают курсы Beetroot Academy по направлениям Front-end, Back-end, Python, WordPress + WooCommerce и веб-дизайну.

White Label Agency

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

Компания предоставляет аутсорсинговые услуги по разработке сайтов на платформе WordPress и дополнительные связанные с ним сервисы, такие как web-дизайн, перенос сайтов с других CMS, кастомизация плагинов под потребности клиентов. White Label Agency разрабатывает около 2000 сайтов в год. Большинство клиентов компании — из Америки и Европы.

Основные технологии: WordPress, PHP, JavaScript/jQuery, AJAX, CSS frameworks, HTML, REST API, WooCommerce.

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

Digicode

Американская аутсорсинговая компания
40 сотрудников в Полтаве, 140 в Украине

В Полтаве компания специализируется на создании веб-проектов для клиентов из США и Израиля, но планирует активно развивать и мобильные технологии.

На данный момент большинство проектов разрабатываются на PHP (Laravel), NodeJS, Angular, React. Есть проекты на .NET, Java.

Возможности для начинающих специалистов:в компании действует программа стажировок. Для приема на стажировку нужно пройти достаточно суровый отбор, но больше 70 % ребят успешно становиться полноценными специалистами уже через 12-18 месяцев.

CoreValue

Американская аутсорсинговая компания
38 сотрудников в Полтаве, 350 в Украине

Компания предоставляет услуги по разработке и тестированию продуктов для фармацевтической, медицинской и финансовой индустрий. Основные технологии: Salesforce, Java, .NET, PHP.

Возможности для начинающих специалистов:компания проводит экспресс-курсы по Salesforce, CoreValue University для студентов и начинающих специалистов, организовывает конференцию CoreCamp.

Yanpix

Словацкая аутсорсинговая компания
20+ сотрудников в Полтаве

Компания предоставляет услуги по полному циклу разработки и внедрения ПО. Экспертные области: медицина, здравоохранение, спортивная индустрия, Customer care solutions.

Основные технологии: .NET, ASP.NET MVC, AngularJS, ReactJS (MEAN, MERN stacks), iOS/Android, PHP, Wordpress, WooCommerce.

Также в Полтаве есть офисы таких компаний:

• AIT — предоставляет услуги веб-разработки и хостинга для стартапов и малого бизнеса.
• Artex Group — предоставляет услуги по разработке веб-сайтов «под ключ», контекстной рекламе, оптимизации и продвижению в поисковых системах.
• Arvo Software — специализируется на веб-разработке, предоставляют услуги аутсорсинга и аутстаффинга.
• BR Soft — разрабатывает сайты и модули на платформе 1С-Битрикс.
• D-art—занимается веб-дизайном и разработкой сайтов.
• Dorset Creative — разрабатывает программное обеспечение, в том числе VR, мобильные приложения и дизайн.
• Everyday — разрабатывает мобильное приложение для формирования правильного питания и распорядка здорового образа жизни. Программный комплекс рассчитан на диетологические кабинеты и фитнес-центры.
• Grass Business Labs — разрабатывает ПО (веб, Java, мобильные приложения) для стартапов и бизнеса.
• IST — занимается разработкой, внедрением и сопровождением ПО, системной интеграцией сетевой и аппаратной инфраструктуры, мониторингом информационной безопасности.
• Morebis — разрабатывает ПО для малого и среднего бизнеса.
• QATestLab — предоставляет полный спектр услуг по тестированию ПО, консультированию по качеству ПО.
• SmartSpace — работает над коммерческими интернет-проектами образовательной тематики.
• Testmatick — занимается ручным и автоматизированным тестированием ПО. Экспертные области: фитнес, отельно-ресторанный бизнес, учет расходов, email-маркетинг, путешествия, финансы. В компании действуют программы стажировок для студентов и начинающих специалистов.
• WebHelp Agency — специализируется на веб-дизайне и веб-разработке.
• Webington — занимается разработкой сайтов, а также их поддержкой и хостингом.
• Weblinks — специализируется на разработке ПО, создании и продвижении сайтов, а также ремонте компьютерной техники.
• Webtochka — предлагает полный комплекс услуг по созданию, продвижению и администрированию сайтов.
• Workconsult — предоставляет услуги аутстаффинга IТ-специалистов для работы непосредственно с клиентом.

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

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

Grass Coworking — коворкинг, на базе которого регулярно проходят бесплатные IT-курсы. Ближайшие старты: Unity, PHP/Laravel/Lumen/MySQL.

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

IT-Yard — ежегодный IT-форум под открытым небом, цели которого — создание IT-сообщества, обмен опытом, обучение, помощь новичкам в старте карьеры. Организаторы конференции — ПОМГО «Поколение Google».

Форум IT-Yard в Корпусном саду

InsaneByte — крупнейшая IT-конференция в регионе для программистов и представителей ІТ-бизнеса. Объединила более 500 участников из Полтавы и области.

Также разные IT-мероприятия — митапы, лекции и воркшопы — периодически проходят на базе компаний Beetrootи CoreValue.

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

Образование

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

• ПНТУ им. Ю. Кондратюка (факультет информационных и телекоммуникационных технологий и систем);
• ПИБ МНТУ им. Ю. Бугая (программная инженерия);
• ПНПУ им. В. Короленка (физико-математический факультет);
• ПУЭТ (институт экономики, управления и информационных технологий);
• ПДАА (факультет економіки та менеджменту).

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

• Beetroot Academy (Back-end, Front-end, Python, веб-дизайн, WordPress + WooCommerce);
• A-level (PHP, Front-end, Scratch, веб-дизайн);
• Atom School (Java, JavaScript, PHP, HTML/CSS, PM, веб-дизайн);
• IT-Yard (.NET/C#, WordPress);
• КА «Шаг» (разработка ПО, компьютерная графика и дизайн, сетевые технологии и системное администрирование).

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

Сергей Крыжановский, региональный менеджер CoreValue:

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

Итого, можно выделить такие преимущества IT-отрасли в регионе:

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

Что касается недостатков:

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

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

Виктория Устименко, Branch-менеджер в White Label Agency:

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

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

Из недостатков можно обозначить:

• отток специалистов в города-миллионники Украины и за рубеж;
• дефицит высококвалифицированных кадров;
• медленно развивающееся IТ-сообщество в городе.

Однако, стоит заметить, за последнее время активизировались местные компании и неравнодушные к IТ. При их содействии в городе прошла масштабная конференция InsaneByte, собравшая более 500 слушателей и спикеров из разных городов Украины и зарубежья.

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

Евгения Хименко, CEO Mindy Supports:

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

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

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

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

Андрей Януш, CEO & founder Yanpix:

Преимущества и недостатки IT-рынка труда в Полтаве такие же, как и в других небольших городах Украины.

Из преимуществ: до крупных городов — Киева и Харькова — очень легко добраться на Интерсити за 3 и 1,5 часа соответственно. А это отличная возможность посещать конференции и митапы, а также другие события.

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

Однако, если смотреть в динамике, сообщество с каждым годом развивается. В городе проходят встречи и конференции — GDG Poltava, InsaneByte, IT-Yard.

Татьяна Бойченко, HR-менеджер Beetroot:

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

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

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

Олександра Дущенко, менеджер в Arvo Software:

IT-індустрія в Полтаві активно розвивається. Офіс компанії Arvo Software було відкрито в цьому місті в 2008 році, і на той час в регіоні працювало тільки 4-5 IT-компаній.Відповідно, студенти ПНТУ ім. Ю. Кондратюка не мали великого вибору, де можна застосувати свої знання після навчання.

За останні декілька років у Полтаві збільшилась кількість і конкуренція серед роботодавців. Досвідчені фахівці їдуть у великі міста або за кордон.

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

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

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

Мене звуть Роман Апостол. Уже чотири роки я працюю в Google у Нью-Йорку, куди потрапив за запрошенням самої компанії. Після закінчення КНУ імені Шевченка у 2011-муя став одним із засновників стартапу Preply. У той же час мав багато друзів, які після стажування у Facebook та Google поїхали туди працювати. Для таких компаній є звичною практикою знаходити співробітників через людей, які вже там працюють. Персонал просять поділитися контактами тих, хто, на їхню думку, зміг би працювати у компанії. Хтось із моїх друзів (навіть не знаю хто) таким чином порекомендував мене у Google. Зі мною кілька разів зв’язувалися рекрутери компанії, але поки тривала робота над стартапом, не поспішав погоджуватися. Зрештою настав етап, на якому вирішив спробувати пройти співбесіду. Це було взимку 2013 року.

Співбесіди

Перша співбесіда проходила телефоном. Це screening interview, під час якого складають уявлення, яка це людина, перевіряють, наскільки вона може писати код тощо. Після цього відбувається ще 5 співбесід протягом одного дня в офісі того міста, в якому кандидат хоче працювати. Більшість із цих інтерв’ю — на coding skills, коли задають якісь задачі і потрібно їх на дошці вирішувати. Ще culture fit співбесіди, а також, залежно від того, на який рівень претендує кандидат, можливі співбесіди на технічний дизайн систем. Загалом весь процес може займати від 3-4тижнів до 2-3 місяців.

Як претендент на роботу, я міг самостійно вибрати місто, в якому хотів би працювати. Коли раніше бував у США, Нью-Йорк мене вразив найбільше з побачених міст. Нью-Йорк — це не тільки про IT, як, наприклад, Сан-Франциско, де, окрім цієї теми, не спілкуються більше ні про що. Нью-Йорк — це і культурне життя з його театрами і бродвейськими шоу, це місто розвинених фінансів, тут постійно щось відбувається. Це місто натхнення.

Віза

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

Віз H-1B — 85 тисяч на рік, в останні роки кількість аплікантів росте — вже більше 200 тисяч людей на рік. Серед всіх аплікантів розігрується лотерея і переможці отримують візу. У 2013 шанси отримати візу були практично 100%, зараз — уже складніше.

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

У Google є кілька рівнів, на які наймають інженерів: з 3-гопо 10-й,хоча 10-й —це, мабуть, лише Jeff Dean. 1-ийта 2-ийрівень — не інженерні позиції. Людей без досвіду, new grades, здебільшого наймають на третій рівень, на четвертий — людей із досвідом. На 5-й,рівень senior, зазвичай не наймають — таких спеціалістів Google намагається ростити всередині компанії. Мене брали на 4-йрівень.

Залежно від рівня, на працівників покладають певні очікування: якщо говорити спрощено, то 3-йрівень передбачає, що працівнику ставлять задачу й пояснюють, як її виконувати. Якщо пояснювати не треба — значить, людина може переходити на 4-йрівень. На 5-мурівні працівник уже сам знає, чим потрібно займатися, не Google впливає на людину, а людина робить Google успішнішим. Співробітник 6-горівня або має велику команду з понад 10 людей, або відповідає за велику частину продукту.

Два роки тому я запромоутився на 5-йрівень, зараз я тімлід команди з 9 людей. Разом із представниками інших команд я відповідальний за те, куди ми далі рухаємося, що робимо з продуктом.

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

Офіс

У Каліфорнії офіс Google складається з багатьох маленьких будівель, у кожній з яких сидить порівняно небагато людей, а всього там працює приблизно 20 тисяч інженерів — побачитися одне з одним буває складно. У нас же навпаки: один великий офіс, в якому працює більше 5000 людей. За площею він є одним із найбільших приміщень на Мангеттені. Це компактний будинок, у якому, щоб побачитися з колегами, не треба йти 15 хвилин з одного кабінету в інший.

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

Офіс Google

IT-середовище

У Нью-Йорку багато мітапів, де збирається велика кількість розумних людей, можна прийти послухати. Різні форми IT-освіти набувають популярності, університети вже не можуть впоратися з попитом, тому поширеним є, наприклад, формат буткемпів, при якому люди інтенсивно навчаються впродовж 6-9 місяців.Попит на інженерні позиції зростатиме ще більше, тому, на мою думку, людям варто продовжувати «входити в айті» :)

Тут є офіси Facebook, Uber, Spotify, великої кількості фінансових компаній, в яких зазвичай розвинений tech департамент (Goldman Sachs, Barclays, Two Sigma) та добре розвинена стартап-екосистема.

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

Columbia University

Житло

У перші три місяці я жив на корпоративній квартирі, яка безплатно надається новим іноземним працівникам на період адаптації. Потім у компанії запропонували послуги агента з нерухомості, який би допоміг знайти помешкання, але я самостійно знайшов краще. Перший рік жив на Мангеттені, після цього перебрався в Бруклін, у Williamsburg — хороший затишний район, звідки до роботи мені добиратися 25 хвилин на метро. У нашому районі вартість місячної оренди квартири-студії — від $2500 до $2800, 1-кімнатноїквартири — від $3200 до $4500. Актуальні ціни на оренду житла в Нью-Йорку найкраще переглядати тут.

Вартість квартир у Willimsburg приблизно така ж, як і на Мангеттені, на Zillowможна побачити ціни. В Нью-Йорку досить багато житла купляється не резидентами міста, які інвестують в нерухомість. Це загалом підігріває ціну на житло. Резиденти ж зазвичай беруть кредит на 15-30 років.На NY Timesє хороший калькулятор, який допоможе обрати, що краще — орендувати чи купувати житло.

Зарплати й податки

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

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

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

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

Компанії на зразок Google і Facebook зазвичай дають акції «у пакеті» на 4 роки. Тобто людина теж зацікавлена, аби компанія розвивалася й ціна акцій зростала. Усе це — зарплата, акції, умови надання річного бонуса — прописані в робочому контракті.

Транспорт

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

Метро в Нью-Йорку працює цілодобово, тому з будь-якої точки можна доїхати куди і коли завгодно. Звісно, є й Uber, але метро цілком зручне. Воно дуже живе, жваве, розгалужене, як і саме місто. Є ще автобуси, але ними не їздив. Щоб добратися до роботи, користуюся метро. Дорога від дверей дому до дверей офісу займає 20-25 хвилин.Проїзний квиток можна купувати разово, а можна на місяць і необмежено їздити. Безлімітний коштує 116.50 доларів.

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

Медицина

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

Дозвілля

Зі своєю Google-командою — приблизно 20 людей — ми раз на місяць організовуємо для себе різні івенти: стріляємо з лука, граємо shuffleboard, метаємо сокириабо просто йдемо в бар. Щочетверга в офісі відбуваються вечірки, кожну п’ятницю можна пити пиво на роботі. Крім того, відпочиваю з друзями поза роботою. Більшість із них — українці, з якими мене познайомили інші українці, але також спілкуюся і з іноземцями. Коли йдеш до когось на домашню вечірку, вважається абсолютно нормальним привести когось із собою. Всі спілкуються гуртом, все класно.

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

У Нью-Йорку дуже класні музеї, і не лише всім відомі, як Метрополітен і МоМА. У Метрополітені досить побувати один раз: експозиції не змінюються. Але є, наприклад, Whitney Museum, Cooper Hewitt — музеї сучасного мистецтва та архітектури/дизайну зі змінними виставками. Такі заклади мені цікавіші, коли не прийдеш — щось нове.

Висновки

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

З того, що унікальне для Штатів, мені дуже подобається «Амазон». Круто, що існує цілодобова доставка чого завгодно, не потрібно ходити по магазинах, все можна замовити онлайн. Це великий плюс саме Америки, здається, настільки розвиненого e-commerce ніде нема.

Перевагою є те, що США — капіталістична країна: люди, які багато працюють, отримують відповідні бенефіти від того. Вважаю, це добре.

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

Как известно, программисты — люди творческие, но вместе с тем ревностно придерживающиеся определенных идей, к примеру, выбора языка программирования. PHP считается языком «для ленивых», а JavaScript — «труднопрогнозируемой» магией. И среди огромного обилия языков функциональные языки все быстрее обрастают поклонниками и все увереннее прокладывают себе путь в большинство компаний по всему миру. Согласно аналитике RedMonkот июня 2017 и сборной оценке популярности языков на GitHub и Slack Overflow, функциональные языки (Elm, Elixir) медленно, но уверенно набирают рост. Огромный рост популярности JavaScript также ведет к повышенному интересу к ФП. Вдобавок, разработчики с опытом в функциональном программировании впоследствии начинали работать над SPA фреймворками, и, как результат, у нас есть Redux, React, MobX и другие библиотеки, которыми пользуются миллионы людей.

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

Немного азов

Прежде чем уходить в дебри, стоит начать со старта.

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

Основные отличительные признаки разработки ПО при помощи ФП:

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

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

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

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

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

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

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

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

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

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

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

Чтобы написать код, станьте кодом

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

Гребень волны IT-трендов и применение ФП

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

Если вспоминать наиболее нашумевшие тренды 2016-2017 года,это, разумеется, будут AI, IoT, Big Data и Blockchain. Они у всех на слуху, всем известен их потенциал и ключевые особенности. И именно некоторые из этих трендов послужили катализатором роста популярности функционального программирования среди разработчиков.

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

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

Суть проекта

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

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

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

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

Вывод — не бойтесь пробовать

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

• Расслабьтесь :) Поначалу и правда будет сложновато, учитывая, что вам придется отодвинуть на задний план то, что вы знаете, и учить новые подходы и принципы. И это нормально. Вспомните, как вы впервые учились кодить. Ничего страшного не случится.
• Начинайте с микрозадач, чтобы «набить руку».
• Начните изучать Haskell и затем переходите на Scala (или F#), чтобы начать вникать в принципы функционального программирования (а заодно начать мыслить более «функционально»).
• Вам могут пригодиться эти ресурсы:
  
  • Книга «Learn You a Haskell»
  • Книга «Real-World Functional Programming: With Examples in F# and C#»
  • Курс «Programming Languages, Part A» (для изучения концептов ФП с помощью SML, Racket, Ruby)
  • Курс «Introduction to Functional Programming»
  • Подборка на GitHub (JavaScript)
  • И еще однаподборка GitHub «Awesome FP JS»

Привет всем! Меня зовут Александр Демура, в IT я работаю с 2004 года, сейчас руковожу центром разработки DataArt в Одессе. В мои непосредственные обязанности входят найм и развитие наших специалистов, поэтому рассуждения на тему «синьорности» сотрудников и качеств, необходимых для той или иной роли, для меня актуальны и привычны.

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

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

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

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

Интерн

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

1. Хороший английский.
2. Понимание выбранного инструмента и умение им пользоваться.

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

Про инструмент мысль тоже, мне кажется, простая. Если вы приходите на роль программиста, инструмент для вас — язык программирования со средствами разработки, которыми нужно уметь пользоваться. Если потенциальный интерн хочет разрабатывать на .NET, но не может объяснить, что делает CLR, чем «Equals» отличается от «==» или реализовать простейший алгоритм — шансов у него нет никаких. Приходить с нулевыми знаниями и надеяться, что всему научат на месте, параллельно выплачивая зарплату, бесполезно — слишком большой конкурс. За плечами многих кандидатов профессиональные курсы, они с легкостью отвечают на все теоретические вопросы и даже имеют опыт программирования «для себя». Конечно, таких людей берут в первую очередь.

Junior

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

Для джуна важны следующие качества:

1. Желание развиваться и учиться (а на своих ошибках — особенно).
2. Энергия и целеустремленность.
3. Способность спокойно относиться к критике.

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

Middle

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

Таким образом:

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

Senior

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

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

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

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

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

Что дальше?

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

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

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

Технический эксперт

Статус технического эксперта подразумевает глубокое знание отдельной и специфической области. Например, можно быть экспертом в Azure/AWS и знать разнообразные сервисы, которые предоставляют эти платформы. Уметь делать Machine Learning или Computer Vision, знать все про уязвимости в вебе, понимать, как работают криптовалюты или правильно готовить Sharepoint. Такие задачи встречаются не каждый день, но когда появляются, наступает звездный час технических экспертов. Без них подобные проекты были бы просто невозможны, и компания зачастую готова доплачивать за эти уникальные знания.

Индустриальный эксперт

DataArt старается развиваться в определенных доменных областях (путешествия, финансы, здравоохранение и т. п.). В каждом проекте программисты не только приобретают собственно технические знания, но и получают возможность заглянуть в бизнес заказчика, понять, как устроена индустрия, узнать характерные для нее проблемы и решения. Чего стоит построить свою платежную систему вроде PayPal? Зачем нужна система Sabre? Или что такое HIPAA и какие ограничения она накладывает на разработку решений в области здравоохранения в США? Люди, которые обладают подобными знаниями, зачастую формируют костяк проекта и приносят компании и клиенту огромную дополнительную пользу. Поэтому их компенсация (т. е. деньги, которые они получают за работу) может превышать внешний рейт — компании сами готовы доплачивать таким людям сверх счета, выставленного заказчику проекта.

Фронтмен

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

Тимлид

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

Архитектор

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

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

Дополнительно: работа без посредников

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

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

По этому поводу можно отдельную статью писать, но не привести мою любимую цитату с «Баша»я просто не могу:

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

На этом мне хочется закончить на сегодня, если есть новые идеи для статей — пишите!

Всем привет, меня зовут Саша Емельянов, я Product Manager в MacPaw.

В этом выпуске: снова много Intercom, дизайн-спринты, инстинкты великих фасилитаторов, Emotional Value Proposition, полностью автоматический тайм-трекер и многое другое.

Почитать

Сразу 3 украинских продукта получили Golden Kitty Award от Product Hunt.

• Consumer Product of the Year: Setapp от MacPaw
• Bot of the Year: PatentBot
• WTF Product of the Year: Petcube Bites

Лиза Дзюба из Flawless App заняла второе место в номинации Community Member of the Year. Полный список победителей можно увидеть здесь. Кстати, даже Гройсман поздравилребят с победами.

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

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

Паша Педенко из Setapp (тот самый продукт, который Consumer Product of the Year) написал о том, как они провели дизайн-спринтыу себя в команде, что из этого получилось и какие выводы были сделаны.

Start Together, Finish Together. Статья Джона Катлера о подходе к командной работена Hackernoon.

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

Интересное деление продакт-менеджеров на 6 типовс учетом бэкграунда и экспертизы с разделением на доменные области.

Techcrunch пишет о том, почему Snapchat ожидает туманное будущее.

Сlose.io показывают, как и зачем собирать митапы с кастомерамив B2B сегменте.

Бургерный продакт-менеджмент, или Почему McDonalds проиграл войну. Спойлер: только 1 миллениал из 5 пробовал Big Mac. Cтатья не относится к разработке, но все равно интересно.

Посмотреть

Mind The Product выложили видео о том, как найти фокус в продукте. Если кратко — определите миссию продукта, метрики и KPI’s, после чего засинкайте все с командой.

Анна Булдакова (PM в Intercom) рассказала в академии Яндекса о цикле продуктовой разработки.

ТОП-10 продуктовых докладов 2017 года от Mind The Product. Если еще не видели, точно стоит посмотреть.

Еще один ТОП — 10, но уже UX — видео 2017 года от Nielsen Norman Group.

Послушать

Будут ли AR, AI и Voice UI продолжать влиять на создание продуктов? Ответы в занимательном подкасте о продуктовых трендах 2018 годаот ТОПов Intercom.

4 важные вещи, которые нужно сделать перед запуском собственного стартапа.

Emotional Value Proposition. О том, что это и как использовать креативное мышление в своих продуктахрассказывает подкаст от This is Product Management.

Лучшее с ProductHunt

Product Manual — набор ресурсов и инструментов для продакт-менеджмента. Разделен на 25 категорий, среди которых Design Thinking, User Research, Interaction Design, User Flow и Agile Methodologies (куда без них). Внутри каждой категории — статьи, видео, подкасты по теме, очень удобно для быстрого ресерча.

Planyway Calendar — календарь внутри Trello. Один календарь для одного борда бесплатно, больше — $5 в месяц.

Tixio — удобный органайзер закладок/ссылок/чего угодно.

Notejoy — сервис для хранения и синхронизации командных документов. Доступен для всех платформ, включая macOS.

Skillroad — АІ-карьерный сервис : конструктор резюме, сопроводительных писем, и помощник при подборе работы. От украинских разработчиков.

Всем известный Polymailтеперь и в вебе.

Memory AI — полностью автоматический тайм-трекер, использующий deep learning и немного магии.

Спасибо, что дочитали до конца. Увидимся через месяц!

Подписывайтесь на мой канал в Telegram Product Management Digest, чтобы быть в курсе всего интересного каждый день.

← Предыдущий выпуск: Product Management дайджест #0

Всем привет! После новогодних праздников у нас есть еще один повод для хорошего настроения. Ровно год назад мы с командой RubyGarage начали создавать Ruby/Rails дайджест, так что это наш маленький юбилейный выпуск.

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

А теперь давайте смотреть, что же произошло в мире Ruby и Rails в январе:

Почитать

Understanding the basics of Ruby on Rails: SQL Databases and how they work — если вы новичок в Ruby on Rails, статья поможет разобраться с базой данных SQL и основными командами.

Understanding the basics of Ruby on Rails: HTTP, MVC, and Routes — вторая часть The Ruby on Rails Basics объясняет, как все устроено в вебе, что такое MVC и Routs в Rails.

Comparing Timestamps in Rails — сравнение двух timestamps в Rails: Time и DateTime.

Viewing migration SQL without running the migration — статья поможет разобраться с вопросом «Как получить SQL для миграции, не запуская SQL».

Questions to Ask When Hiring a Freelance Rails Developer — несмотря на то, что статья рассчитана на рекрутеров, Rails разработчикам стоит обратить внимание на этот пост и узнать, каких вопросов ожидать на собеседовании.

Top Qualities and Skills of a Ruby on Rails Developer — а Netguru рассказывают о главных hard и soft skills, которые должны быть у каждого Rails разработчика.

Encapsulating Queries In A Rails Model — краткая подсказка, как инкапсулировать запросы в моделях Rails-приложения.

How to Speed Up Asset Precompilation Time in Ruby on Rails App — сборка ассетов в RoR приложении может быть долгой; чтобы ускорить этот процесс, воспользуйтесь списком полезных советов от Netguru.

Upgrading to RSpec 3.7.2 and system specs — автор делится опытом обновления RSpec до версии 3.7.2.

Ruby Still Isn’t Dead — Engine Yard не устают повторять: Ruby isn’t dead. Если сомневаетесь, прочтите этот краткий пост :)

Why Factories?— Thoughtbot отвечают на вопрос о роли factories в test suites и какие проблемы решаются с помощью factories.

Things I Wish ActiveRecord Had After Using Elixir’s «Ecto» — разработчик из Infinum делится своими впечатлениями от использования Ecto — обертки для базы данных — в Elixir. Кроме того, автор рассказывает, чего не хватает ActiveRecord в сравнении с Ecto.

Ruby 3 and JIT: Where, When, and How Fast?— Appfolio делятся бенчмарками Ruby 3 в связке с JIT (just-in-time compiling).

Some Initial Ruby 2.5 Benchmarks — еще один пост с бенчмарками, в этот раз речь идет о Ruby 2.5

How We Built A Job Queue System with PostgreSQL & Ruby For Our B2B SaaS Application

The Definitive Guide to Loops in Ruby — большой гид по loops в Ruby, включая типы и методы.

Ruby on Rails / RSpec — the difference between stubs and mocks — полезная статья для тех, кто разбирается с RSpec и хочет понять разницу между stubs и mocks.

Upgrading a Rails Application Incrementally — автор делится опытом по обновлению Rails-приложения с версии 3.2 до 4.2 с минимальными проблемами в процессе.

Design Patterns: Command and Concierge in Life and Ruby — разработчики из FreeCodeCamp разыграли целую сценку в статье, показав на примере отеля, как работают команды в Ruby.

Rust for Rubyists — в последнее время появляется все больше статей по теме Rust; в этот дайджест попала еще одна статья-сравнение идиоматических свойств Rust и Ruby.

The Modular Monolith: Rails Architecture — Dan Manges, ex-CTO в Braintree, делится опытом создания модульной монолитной архитектуры для Root — Rails-приложения страховки автомобилей.

Understanding Redux store concepts by little Ruby reimplementation — автор объясняет концепцию Redux на примере его простой имплементации с помощью Ruby.

Reducing Memory Usage in Ruby — Аарон Паттернсон делится опытом оптимизации использования памяти в Ruby во время решения проблем, связанных со сборщиком мусора (garbage collector).

Серия статей от Engine Yard для новичков Ruby on Rails:
Ruby for Rails: Blocks
Ruby for Rails: Hash

Серия статей от Paweł Dąbrowski по transactions в Ruby on Rails:
Ruby on Rails. Active Record — transactions overview
Ruby on Rails. Transactions — callbacks

18 Companies Using Ruby on Rails in 2018 — что объединяет Coinbase, Strava, Intercom? То, что они построены на нашем любимом Ruby on Rails. И как говорит автор статьи: «Кто там еще говорит, что Rails не масштабируется?».

How Much Does Meltdown/Spectre Patching Slow Down a Big Rails App?— разработчики из Appfolio разбираются, как сильно патчи от таких уязвимостей, как Meltdown и Spectre, могут замедлить производительность вашего Rails-приложения.

Туториалы

Серия статей от Menseld

Kafka on Rails: Using Kafka with Ruby on Rails — Part 1 — Kafka basics and its advantages

Kafka on Rails: Using Kafka with Ruby on Rails — Part 2 — Getting started with Ruby and Kafka — туториал из двух частей по использованию Kafka, стриминговой платформы от Apache, в Rails-приложении. В первой части авторы приводят аргументы в пользу использования Kafka; вторая часть дает пошаговую инструкцию по интеграции Kafka и Rails.

Серия статей от Scout App

Deploying to AWS Part I: Dockerizing a Rails app — первый пост в серии туториалов по деплою Rails-приложения на AWS. Статья рассказывает, как «подружить» ваше Rails-приложение с Docker.

Deploying to AWS Part II: Running a Rails App on Fargate — следующая статья предлагает инструкцию по запуску Rails-приложения на Fargate — одному из сервисов AWS. Fargate позволяет запускать контейнеры, не заботясь об управлении серверами или кластерами.

Deploying to AWS Part III: Log Aggregation — логичное продолжение предыдущих постов — изучить logging, а именно более удобный формат вывода логов и перенос логов из Cloudwatch на внешний сервис.

Deploying to AWS Part IV: Performance Monitoring with Scout — узнайте, как сконфигурировать производительность приложения с помощью Scout.

Deploying to AWS Part V: The Final Punch List (load balancer, CDN, SSL) — в списке завершающих работ — конфигурация load balancer’а, CDN и SSL.

Deploying Your Rails + PostgreSQL App on Microsoft Azure — наглядный туториал показывает, как легко развернуть Rails-приложение на Azure. Кроме того, автор объясняет, как настроить базу данных PostgreSQL.

The Ruby 2.5.0 Feature Nobody Talks About — в новой версии Ruby 2.5 появилась удобная фича — branch coverage. На удивление, о ней знают не все разработчики, так что самое время познакомиться с ней.

How to make simple background job processing in Rails with Sucker Punch — статья от нашего разработчика Кирилла Шевченко о том, как сделать простую обработку фоновых задач с помощью библиотеки Sucker Punch. Создание задач, тестирование, плюсы и минусы этого подхода — в статье.

Ruby String Methods (Ultimate Guide) — полный гид по строковым методам в Ruby с примерами.

Design Pattern: Prototype and Pizza — в статье говорится о Prototype — одном из паттернов OOD. Но автор решил, что писать очередную статью про дизайн-паттерны было бы скучно и показал принцип работы Prototype на примере пекарни пиццы. Получился интересный обзор!

Setup SSL proxy for insecure browser content with Ruby and NGINX — SSL защита становится все более популярной опцией в современной разработке веб- и мобильных приложений. В статье объясняется, как настроить Ruby и NGINX сервер, чтобы они работали, как SSL прокси для небезопасного контента.

Binary Searching and Ruby’s bsearch Method — автор со своего опыта рассказывает, как преодолеть трудности с бинарным поиском в Ruby.

Rails 5.2: Active Storage and Beyond — Evil Martians представили большой гайд по Active Storage — новой фиче в Rails 5.2.

Setting up CircleCI 2.0 for Rails — в июле 2017 у CircleCI вышла версия 2.0. Thoughtbot представили обзор новых возможностей платформы.

Релизы

simple-admin v0.1.1-alpha released — simple-admin — удобный фреймворк для создания админ дашбордов. В январе вышла новая версия библиотеки.

Rails 5.2.0 RC1: Active Storage, Redis Cache Store, HTTP/2 Early Hints, CSP, Credentials

Ruby Gems

Metamagic 101 — Introduction, Installation & Usage — удобный плагин для создания и управления meta tags.

Urlify Functions & Its Implementation — гем Urlify конвертирует UTF-8 strings в ASCII-безопасные URL strings, делая их готовыми к использованию URL-фрагментами.

API Versioning with Ruby on Rails: What Gems Are the Best — отличная подборка гемов для управления версиями API от Yalantis.

Materialized Views in Ruby on Rails with Scenic — автор подготовил case study по созданию materialized views в Rails-приложении с помощью библиотеки Scenic.

Kan — простая и функциональная библиотека для авторизации от Антона Давыдова, одного из создателей фреймворка Hanami.

Any_good — часто, когда мы находим новый гем, мы идем на GitHub или rubygems.org, чтобы проверить статус гема (как давно он обновлялся, активно ли поддерживается и т. д.). any_good автоматизирует эту задачу и выдает рейтинг гема, основываясь на данных из GitHub, GitLab, BitBucket и других ресурсов.

Localer — инструмент для автоматического определения недостающих переводов i18n.

Послушать

Подборка подкастов от Ruby Rogues

RR 346: Ruby Debuggers with Daniel Azuma — беседа с Daniel Azuma, Ruby/Elixir — разработчиком из Google. Большая часть подкаста посвящена обсуждению облачных Ruby-дебаггеров.

RR 343: Ruby 2.5. With Jesus Castello — подкаст с Jesus Castello о возможностях Ruby 2.5 и улучшениях производительности в новой версии.

MRS 027: Thom Parkin — гость подкаста, Thom Parkin, делится своим опытом — как он стал разработчиком и как изучал Ruby, Sinatra, Git и не только.

RWpod

01 выпуск 06 сезона. Meltdown and Spectre, Npm operational incident, Uppy, Taskr и прочее

02 выпуск 06 сезона. Ruby 2.5 introduces FrozenError class, Awesome Ruby Meetups, What’s New in HTML 5.2, Ngx-kit и прочее

03 выпуск 06 сезона. jQuery 3.3.0, Bootstrap 4, Intro to Arel, Mapbox for Rails, Keep webpack fast, After.js, Wobble, JS Paint и прочее

04 выпуск 06 сезона. Webpack 4 beta, Reducing Memory Usage in Ruby, Ionic vs React Native, D3 Discovery, JSNES и прочее

The Bike Shed

140: A Sign of ... Stability?— ведущие The Bike Shed спорят о семантике версионности и высказывают свое мнение по поводу автоматических отчетов в changelog’ах.

138: I Don’t Know How the World Works Anymore — авторы подкаста обсуждают проблемы, которые возникают с системными тестами в Rails.

Посмотреть

Подборка платных скринкастов от Drifting Ruby

#113: Ruby on Rails 5.2.0 Changes and New Features — на днях вышла новая версия Rails 5.2.0 и подкаст Drifting Ruby посвящен обзору изменений и новых фич.

#114: Payment Gateway Basics with Stripe — скринкаст для новичков, которые разбираются с интеграцией популярной платежной системы Stripe.

#117: Upgrading Ruby on Rails Versions — из скринкаста узнаете, как обновить Rails-приложение с версии 4.2.10 до 5.2.0.

GoRails

Rais & Vue.js Trello Clone — Part 8 — 8 часть туториала по созданию приложения-клона Trello на базе Rails и Vue.

Handle 404s Better Using Rescue_from — вместо выдачи пользователю ошибки 404, можно использовать Active Support метод rescue_from, который выдает результаты поиска. Скринкаст наглядно показывает, как использовать этот метод.

Подборка платных скринкастов от RubyTapas

Episode #511: Minimum Viable Method — тема скринкаста: ответ на вопрос, стоит ли извлекать метод, чтобы удовлетворить закон Деметры.

Episode #512: Single File — тема скринкаста: оптимизация рефакторинговых сессий в Ruby.

События

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

Ивенты Rails Girls

Rails Girls Lviv — Rails Girls уже не в первый раз во Львове. В этом году ивент пройдет 10 февраля, так что спешите зарегистрироваться.

Rails Girls Leiden — в городе Лейден, Нидерланды, Rails Girls состоится 16 и 17 февраля. Регистрация закрыта, но можно записаться в waiting list.

Rails Girls Warsaw — если не успеете на ивент во Львове, можно поехать в соседнюю Варшаву. Двухдневный crash course пройдет 24 и 25 февраля. Регистрация закончилась, но можно записаться в waiting list.

Конференции

wroc_love.rb — безвиз позволяет посещать еще больше интересных событий! С 16 по 18 марта во Вроцлаве пройдет традиционная конференция wroc_love.rb с интересными спикерами и неформальным общением после ивента.

Special Ruby Meditation #20 — юбилейный 20-ймитап Ruby Meditation пройдет в Киеве 17 февраля. Спикеры и темы еще уточняются.

Курсы

Курсы RubyGarage — с 1 марта стартует очередной набор на курсы Ruby/Rails в RubyGarage. Мы всегда рады новым талантам, так что спешите заполнить заявку и выполнить тестовое задание!

CHI Software — у CHI Software в Харькове проходит стажировка на Ruby on Rails разработчика. Детали — по ссылке на DOU.

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

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

Кроме хорошо известных виз H-1B и L-1, по которым IT-специалисты чаще всего эмигрируют в США, существует менее популярный тип рабочей визы — O-1. О том, что нужно, чтобы претендовать на такую визу, каковы ее преимущества и в чем сложности ее получения, нам рассказала украинка Катя Лавренова, Senior Interaction Designer в компании Intuit.

— Катя, свою первую работу в США ты получила благодаря резюме на Djinni, расскажи эту историю.

Я работала в GlobalLogic на американского заказчика, делала UX для корпоративных приложений и дизайн-библиотеку. После командировок в Калифорнию появились первые мысли о том, что для профессионального развития было бы неплохо попробовать поработать в другой стране, но активно я ничего не искала. У меня висело анонимное резюме на Djinni, время от времени туда приходили какие-то предложения. Одно из них было от СЕО калифорнийского стартапа idevelop.city. Он собирал команду, и ему посоветовали Djinni для поиска украинских разработчиков.

Изначально они искали дизайнера в Киеве, поэтому я не сразу ответила. Но на Djinni есть условие — если ты никак не реагируешь на запрос, твой профиль перестает быть видимым. Как-то ночью я делала один срочный фриланс, вспомнила, что нужно разблокировать аккаунт, и написала, что, к сожалению, не готова менять работу, если речь не идет о релокации. Сразу же (в Сан-Франциско уже был день) получила ответ, что в принципе они готовы перевезти дизайнера в США. Мы созвонились для первого скрининга (не ожидала, что у меня будет видеособеседование ночью :) ), и, помимо всего остального, работодатель сказал, что он мог бы рассмотреть вариант моей релокации по визе O-1. На нее могут претендовать профессионалы из разных областей с выдающимися способностями.

— А до этого ты знала о такой визе?

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

— Ты ждала решения по визе в Украине?

Так как у меня была открыта американская туристическая виза, я сначала въехала по ней в США, чтобы познакомиться с компанией, войти в курс дел и ждать решения по моему кейсу там. Это было в феврале прошлого года. Правда, из-за всяких перипетий (перерегистрация компании, необходимость пробыть в США больше 60-тидней перед подачей на смену визового статуса) пришлось отложить подачу заявки на пару месяцев. Это ожидание и было, наверное, самым сложным. У меня, например, еще не было медицинской страховки, а без нее в США лучше не заниматься активными видами спорта :) Так, однажды после серфинга мне пришлось лететь в Украину к стоматологу.

Потом мы подали документы на «ускоренное рассмотрение», и через неделю мне одобрили визу. Услуги юриста стоят $4000-5000, подача — $450, ускоренное рассмотрение — $1250. Обычно большие компании берут эти расходы на себя, в стартапах — как договоритесь. В моем случае я платила за визу сама, а работодатель оплатил релокационный пакет.

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

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

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

Один из важных критериев — награды в международных и национальных конкурсах. В моем случае, это была победа в международном Intel Realsense Challenge с командой из GlobalLogic и в украинском DevChallenge. Среди других требований — участие в конкурсах в качестве члена жюри. Хорошо, когда есть публикации в СМИ о тебе, твои авторские публикации или выступления на конференциях. Но просто иметь персональный блог на Medium недостаточно, ты должен доказать, что это авторитетное, посещаемое медиа (юристы будут показывать статистику). Публикация на DOU — это ок.

Еще один из критериев — зарплата выше средней по твоей специальности в твоей стране (мои юристы брали статистику опять же с DOU). Также необходимы доказательства выдающегося вклада в деятельность компании, в которой ты работал. Ими служат рекомендательные письма от коллег, которые составляют юристы. Нужно состоять в профессиональных сообществах, в которые нельзя вступить за деньги и куда принимают только по профессиональным качествам. Я закончила курсы «User Experience Certification Program» от Nielsen Norman Group, и эта сертификация подошла как участие в сообществе. Раньше было достаточно членства в Dribbble, но сейчас эту лавочку закрыли, так как получить инвайт очень легко.

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

— Можно ли получить O-1 визу без рабочего оффера или для подачи нужен работодатель?

Чтобы претендовать на эту визу, необходимо сначала найти работодателя. То есть получить визу, приехать в Штаты и на месте искать работу не получится. Но привязка к работодателю не такая жесткая, как по L визе. Работу можно поменять, оставаясь в США, но тогда нужно будет заново подаваться на визу с тем же набором документов. Вероятность повторно получить O-1 практически 100%.

— Какие еще преимущества O-1 визы по сравнению, например, с H1B?

Чтобы получить эту визу не нужен диплом о высшем образовании. Это особенно актуально для украинских дизайнеров, потому что редко у кого есть профильное образование. Например, я закончила Киево-Могилянскую академию, бакалаврат филологии и магистратуру PR. Также на О-1 нет квот и лотереи, подаваться на нее можно в любое время года. Виза действительна 3 года, потом ее можно продлить еще на 3. Сразу же после получения визы можно начать оформлять грин-карту EB-1.

— А если говорить о недостатках?

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

— Расскажи о своей работе в idevelop.city. Почему уже через полгода ты решила сменить компанию?

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

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

— В какие компании ты проходила собеседования и сколько занял поиск работы?

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

Обычно собеседования состоят из стандартных этапов:

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

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

3. Когда ты прошел скрининг, твое портфолио смотрит дизайнер, и, если оно его заинтересовало, тебя приглашают на техническое собеседование. Как мне рассказывал мой тимлид в Intuit, он просмотрел около 50 портфолио, прежде чем позвал меня на следующий этап. Поэтому важно подготовить и показать лучшие кейсы. Я сходила на несколько портфолио ревью, которые регулярно проходят в Сан-Франциско. На этих ивентах можно презентовать свои работы дизайнерам из известных компаний (Google, Adobe...), чтобы получить фидбек и понять, на что они обращают внимание при приеме на работу. Имеет значение не столько визуальная часть, сколько процесс, работа с командой, то, какие проблемы ты решал с помощью дизайна, и почему выбрал именно такое решение.

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

5. Оффер и обсуждение условий. Есть хорошее правило «Never accept the first offer», особенно, если у тебя есть несколько предложений от известных компаний. Моя любимая статья на эту тему — «Farewell, App Academy. Hello, Airbnb».

Я собеседовалась во много интересных компаний, среди которых Uber, Facebook, LinkedIn, а офферы получила от четырех: Intuit, Google (на проект YouTube), Atlassian и CA Technologies. Оффер от Intuit я получила перед отпуском, я улетала на 10 дней и пришлось попросить остальные компании ускорить процесс собеседований. Так что я проходила финальные интервью прямо во время автотрипа по Исландии, что было довольно экстремально.

— Почему приняла предложение от Intuit, а не от Google?

Оффер от Intuit был интереснее по всем параметрам — проект, сильная команда, лучшие условия по визе, зарплата. Про эту компанию, наверное, мало кто слышал в Украине (я, например, ничего не знала до переезда в США), но на американском рынке это известный разработчик финансового программного обеспечения для малого и среднего бизнеса. Среди основных продуктов — QuickBooks (я работаю на этом проекте), который занимает более 90% рынка бухгалтерского софта для владельцев малого бизнеса, и TurboTax — сервис для уплаты федеральных налогов. Кроме того, я знала, что в Intuit очень сильная дизайн-команда, потому что была на ивентах, где выступали их дизайнеры. Четырехчасовое финальное интервью в офисе оставило у меня самые приятные впечатления, мне очень понравилась атмосфера и особенно тимлид. Когда я принимала решение, выбирая между офферами от Google и Intuit, мы с ним созвонились, и он окончательно склонил меня в пользу этой компании.

Офис компании Intuit

— Какие дизайнерские вызовы ставит проект QuickBooks? Не скучно ли тебе работать в области бухгалтерии?

Я работаю над Quickbooks Payroll — зарплатами и менеджментом сотрудников. Дизайнеру нужно досконально знать продукт и пользователей, так что прежде всего, нужно было разобраться в новой сфере. В Intuit для этого есть много тренингов, в том числе двухдневный «курс юного бухгалтера». На самом деле для дизайнера есть очень много интересных задач в этой области, а в компании создана отличная профессиональная среда, которая способствует твоему развитию. Например, каждое утро у нас проходит peer design review, на которых вся команда (около 40 человек) собирается вокруг проектора, чтобы послушать 5-тиминутную презентацию о том, над чем сейчас кто-то работает. После этого каждый дает по короткому комментарию. Это одна из тех практик, которая помогает тебе расти.

В компании грамотно построены процессы. Есть четкое разделение на Interaction, Visual и Content дизайнеров, причем контент-дизайнер должен принимать участие в разработке с самого начала, на этапе идей. Все решения по дизайну продукта принимаются на основе исследования пользователей, этому уделяется много внимания. У дизайнера много полномочий и ресурсов: если ты понимаешь, что для принятия решения не хватает фидбека от пользователей, в твоем распоряжении команда ресерчеров или же можно самостоятельно организовать нужное исследование. В Intuit применяют практику Follow Me Home, которую внедрили основатели компании и которая позволяет понаблюдать за поведением пользователя в его повседневной жизни, как он работает, как ведет учет бухгалтерии, управляет своим бизнесом. В Follow Me Home принимают участие не только дизайнеры, но и девелоперы и проджект-менеджеры, это дает возможность развить эмпатию и лучше понимать потребности тех, для кого команда создает продукт.

Здесь отличные условия, культура work-life balance. Нет переработок, трехнедельный отпуск, возможность работать удаленно. Intuit выделяет годовой бюджет, который можно потратить на доску для сноуборда, ски-пассы, серфинг — любые физические активности (кроме мотоцикла и прыжков с парашютом :) Очень сильная команда дизайнеров, в основном американцы. Кстати, наш кампус в Маунтин-Вью находится на одной территории с кампусом Google.

— Сейчас у тебя уже вторая O-1 виза. Какие дальнейшие планы в плане смены статуса?

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

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

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

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

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

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

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

Если ты Java, C#, .NET программист, тебе нужно знать Java, C#, .NET. Если ты тестировщик, тебе нужно знать теорию тестирования и то, что будет использоваться на твоем проекте.

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

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

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

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

GUI — >Functional — >Usability — >Security — >Performance (Load/Stress/Recovery) — >Configuration

Рассмотрим подробнее:

GUI

GUI — у любого тестируемого предмета и веб-приложения есть внешний вид, поэтому тестирование графического интерфейса или попросту, внешнего вида — это самое первое, что мы можем сделать. Сравнить его с требованиями и/или с макетом и все. Или не все? А как насчет верстки?

Верстка — размещение элементов веб-приложения (изображения, текст, кнопки, видео...) в соответствии с макетом или требованиями.

Проверяем:

• наличие всех элементов;
• их размер и цвет;
• расположение относительно друг-друга.

Все? — Нет :) У верстки есть еще множество параметров и элементов, которые мы очень часто забываем проверить.

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

Измерение размеров элемента — если это имеет значение, то померять размеры элемента и сравнить их со спецификацией можно с помощью, например Page Ruler.

Правильность шрифтов (название, размер, цвет) — WhatFont.

Цвета интерфейса — ColorZilla.

Контент — проверить на наличие орфографических и грамматических ошибок (SpellChecker).

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

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

Обозначение возможности переноса элементов.

Кодировка (UTF8...).

Стандарты HTML/CSS — достаточно неплохие решения для быстрой проверки предлагает W3C.

Заголовкипо всему приложению должны быть приведены к одному стандарту (пример).

Title страницы — о нем мы тоже часто забываем, также как и разработчики :)

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

Масштабируемость — особенно это важно при тестировании на смартфонах и планшетах. Где пользователь часто меняет масштаб экрана (Window Resizer), а также режим адаптивного дизайна (например в FireFox Developer Edition).

Кроссбраузерность — одна и та же страница может выглядеть по-разному в разных браузерах (пример).

Проверяем Scroll.

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

Проверить контент при отключенных (режим WebDeveloper) изображениях, flash, JavaScript.

Все? — Нет :)

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

• Проверяем тестовый образец на правильность перевода — тут, конечно, хорошо бы подключить переводчика или носителя языка, но за неимением таких, берем тестовый образец и переводим через любой онлайн-переводчик (ну и все мы помним, как прекрасно и весело читать описание товаров на русском языке на AliExpress).
• Длина переведенных слов — количество символов в переведенном слове может быть гораздо больше (пример), что может привести к «расползанию» интерфейса при переводе.
• Сокращения/аббревиатуры — существуют правила, по которым их либо переводят, либо транслитерируют, либо оставляют как есть.
• Валюта.
• Параметры шрифта могут также значительно отличаться в зависимости от языка ввода.
• Проверить работу поиска во всех локализациях — к примеру, на AliExpress результаты поиска одного и того же слова «смартфон» дают разный результат по количеству найденных товаров, причем разница исчисляется десятками тысяч.
• Мета-информация (keywords/title/description) — столь незначительное для пользователя, невидимое, но такое важное для поисковых машин и продвижения сайта в гугле и других поисковиках.
• RTL (right to left languages) — языки c обратным написанием (арабский, иврит) имеют свои особенности: числа пишутся слева направо, значки и иконки отзеркаливаются, названия программ не переводятся, нет переносов, кнопки редактирования Backspace и Delete работают наоборот.

Functional

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

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

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

Например:

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

Но и тут мы можем кое-что забыть. Часто забываемые проверки функциональных элементов приложения:

Кнопки:

• Enter должна срабатывать как submit;
• Tab должен переводить курсор на следующий элемент.

Поля ввода:

• trimming («убирание») пробелов в полях ввода;
• пустота/пробелы в поле ввода;
• все способы редактирования (Insert, Delete, Backspace, Ctrl+C/V/X/Z и т. д.);
• дроби ( 1.5 | 1,5 | ⅕).

Поиск:

• wildcard symbols (* | ?);
• написание поискового запроса слитно | раздельно | через дефис должно вести к одному результату;
• ввод текста в другой раскладке.

Сообщения об ошибках:

• пробуем отключить в настройках браузера.

Календарь:

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

Время:

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

E-mail:

• логин (63 символа) @ домен (253 символа (может быть ip)).

Всплывающие окна / подсказки:

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

Usability

За внешним видом и функциональностью следует удобство (Usability). Не менее важная часть, так как от нее зависит, будет ли востребован ваш продукт вообще. О каких моментах нужно помнить при тестировании usability веб-приложения?

• Соответствует ли приложение ожиданиям конечного пользователя;
• Логичность интерфейса;
• Самое нужное «сверху»;
• Продуманная навигация;
• Локализация (да, да, она относится и сюда тоже);
• Совместимость с другим софтом (соцсети) и железом;
• Скорость работы приложения;
• Информативность (сообщения / обязательные поля);
• Возможность отмены действий пользователя;
• Help — должна быть инструкция, как работать с приложением;
• Возможность печати (если нужно).

Security

Тестирование безопасности:

• Начинаем всегда с составления матрицы уровней доступа;
• Конфиденциальность — никто не может получить доступ к данным несанкционированно;
• Целостность данных:
  а) возможность восстановить данные в полном объеме при их повреждении;
  б) доступ на изменение информации только определенной категории пользователей.

Performance

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

• Имитируем нагрузку пользователями (JMeter);
• Пробуем загрузить большие объемы данных, файлы, медиа;
• Нагружаем БД;
• Понижаем скорость инета (NetLimiter);
• Понижаем скорость передачи данных (Throttling);
• Тестируем восстановление системы после падений.

Configuration

Конфигурационное тестирование. Тут все тоже просто:

• Берем у разработчиков/заказчика список софта и железа, на котором и с которым должно работать наше приложение.
• Думаем над тем, с чем еще взаимодействует приложение (например соцсети, почта, возможно, камера на телефоне и т. п.).
• Выписываем это все в список (ОС, браузеры, их версии для ПК, мобильных телефонов, планшетов, также (если это важно) выписываем на каком разрешении или с какими настройками (например, для камеры съемка в режиме HD) нужно проводить тестирование).
• Далее можем использовать метод классов эквивалентности, pairwise или просто руководствуемся тем, что есть в наличии, и настраиваем тестовое окружение с нужными конфигурациями.

Памятка

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

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

Внешнее — > Внутренее — >Стойкость — >Взаимодействие

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

Внутреннее — все функции приложения (Functional).

Стойкость — сюда мы отнесем устойчивость приложения к нагрузкам и к попыткам нарушить его безопасность (Security, Performance (load/stress/recovery)).

Взаимодействие — работа приложения с другим софтом и железом (Configuration).

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