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

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

Попередній досвід

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

Як на мене, питання досить нерелевантне, тому що, як правило, інтерв’юер буде очікувати саме технічних проблем, тоді як у нашій роботі більшість складнощів пов’язані якраз із людьми. Навряд його задовільнить відповідь: «Ми вперлися в обмеження системи. Щоб порефакторити, треба було 3 місяці проводити купу мітингів з іншими відділами, щоб переконати їх, що ця робота повинна бути виконана саме зараз» (це, напевне, більше про менеджерський досвід). Або «у нас хаотичний замовник, і ми 4 рази переписували якусь частину системи. Вже на третій раз мені було дуже складно себе мотивувати».

Натомість усі чомусь будуть очікувати прохолодних історій про те, як ви перемелювали петабайти даних на кластерах, які коштують тисячу баксів за годину роботи. Як ви ковбасили 300kk req/sec на чистому Netty. Як ви застосовували consistent hash ring для шардування терабайтів даних і подібні байки.

Я вже писаву себе на каналі, що найскладніші задачі, для виконання яких мені треба було думати і напружувати сіру речовину, залишилися в університеті. Реальна робота з технічної точки зору виявилася прогулянкою Центральним парком у сонячний день. Тому, якщо вам не пощастило працювати в highload/adtech/fintech/gambling проектах, де є реально великі навантаження, то вашою найскладнішою проблемою, напевне, було розслідування якогось хитрого бага, який не давав нормально рендерити формочки або конвертувати один XML в інший.

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

Щоразу я по-різному відповідав на це питання. Бувало, прямо казав, що в інституті мені треба було малювати граф зі стрілочками і там була складна тригонометрія. Іноді казав, що фіксив меморі ліки, а іноді — що мав терки з іншими відділами. Якось викручувався.

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

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

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

Ще мав співбесіду в лідера ринку на техліда.У них на проекті є AWS. І в мене у CV теж написано, що я щось тямлю в тому. Ну і вони давай мене питати: а перелічіть усі сервіси, які ви використовували, а чому оце не взяли, а чому оце взяли, а які проблеми були, а що таке ось ця штука і так далі. Наостанок програм-менеджер(!) у мене запитав: «Чим відрізняються лямбди, написані на Java та інших мовах?» :)

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

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

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

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

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

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

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

Співбесіда на Java-помідора у дрібну аутстаф-контору.Їхній інженер розповідає, що в них мікросервіси на Spring Boot та Go, щось там якось крутиться, задає мені кілька дефолтних питань. Далі ми переходимо до фронтенд-частини, потім повертаємося знову до бекенд. І тут інженер у мене питає: «А от як би ти вирішив задачу, яка у нас стоїть? Мікросервіси і все це». Я не довго думав і відповів: «Взяв би Spring Boot і не парився», тобто віддзеркалив їхнє рішення :) Смішно було.

У ту контору мене не взяли, бо знань з фронтенду було мало.

Співбесіда на Java-техліда у лідера ринку.РМ-ом проекту виявився мій колега з попередньої роботи, який мене добре знав та був готовий брати мене фактично без співбесіди, але треба ж було дотриматися усіх формальностей. Отож, розмовляло зі мною аж троє людей (чомусь лідери ринку дуже люблять побільше людей напхати у переговорку). Одразу перейшли до запитань щодо розподілених систем, Spring Cloud Netflix, тестування АРІ.

Основним запитанням, як і на багатьох інших співбесідах, була організація RPC, як забезпечити уникнення проблем з версіонуванням API, як це тестувати, документувати та перевіряти дотримання контрактів. Тут я трішки дав маху, тому що був не в курсі трендового зараз gRPC, який, наскільки мені зрозуміло, всі ці задачі з успіхом вирішує. Довелося відбріхуватися рестом та JSON-Schema. Далі були запитання про побудову стійких систем і ще чогось такого. Трішки зачепили AWS, але я не знав потрібного їм сервісу.

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

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

Ще я мав реально хардкорну співбесіду на позицію SRE в аутстаф-контору.По скайпу зі мною розмовляли двоє людей — технар та менеджер. Продукт у них досить складний, хайлоадний та супер-секурний — його не можна в клауди, все бер-метал і т. д. Судячи з усього, найбільші вимоги у них були до мережевих файлових систем та сховищ даних, от по ним мене і почали питати. Шкода, що я практично ні в зуб ногою ні про такі системи (типу Ceph), ні про внутрішні деталі їхньої реалізації, ні про складнощі, які виникають при експлуатації таких систем. Завжди мав S3 і не парився, а тут виявилося, що ще є люди, які самі те все менеджать.

Отже, мене почали питати про те, як шардувати дані. Які є варіанти, які є протоколи для того, щоб це все правильно робити (щоб не було brain split наприклад), які є варіанти генерації ключів для шардів. Тут я мав би розповісти про consistent ring hash, про який я щось колись читав, але майже не пам’ятав, що воно таке. Хлопці все намагалися мене наштовхнути на це рішення, але я занадто далеко від цих штук (веб-макака ж!), щоб на ходу придумати рішення. Майже 40 хвилин ми вирішували задачу, яким чином побудувати надійне сховище даних, і крутилися навколо схем хешування. Ще трішки торкнулися баз даних і базових команд юнікса, на тому й розійшлися. Вердикт мені дали очевидний: «Далі не пускати».

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

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

Зв’язуємося по Zoom. Інтерв’юер довго вивчає моє CV (очевидно, що мітинги-мітинги, і не було часу підготуватися), і в нас відбувається такий діалог:

— Скільки у вас років досвіду з Java?
— 11 + ще з інституту пару років.
...
— Скільки у вас років досвіду роботи тімлідом?
— Подивіться в CV, там є абсолютно точні терміни.
— Скільки у вас років досвіду роботи тімлідом?
— ??? Я ж кажу — в CV все є.
— Скільки у вас років досвіду роботи тімлідом?
— Вам що, формочку якусь треба заповнювати, що ви такі питання задаєте?
— Ні, я просто хочу для себе розібратися, який у вас був досвід.
— Окей, якщо не хочете в CV дивитися, то 2 роки.

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

Продовжуємо:
— Розкажіть мені щось про Spring.
— Що конкретно розказати?
— Ну, щось.
— ???
— Розкажіть, навіщо потрібен Spring Boot.
...
— Розкажіть мені щось про JVM.
— Що?
— Щось.
— Ви знаєте, я не Шипильов, щоб вам тут про JVM розповідати. Давайте, може, якесь конкретне питання?
...
— А тепер, м-м-м, у нас буде питання про дизайн. Треба задизайнити систему. Ось є фейсбук, гугл, ютуб, твіттер, ще щось високонавантажене. Виберіть собі щось та задизайніть.
— Що саме?
— Ну, щось зі списку, що вам подобається.

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

Відповідаю:
— Окей, я вибираю Hacker News. Це високонавантажений проект, він крутиться на одному сервері та зроблений на LAMP. От його і будемо робити )))

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

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

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

Мене були готові пускати далі, але несподівано виявилося, що в материнській компанії відбулися якісь ротації серед керівництва і весь найм заморозили.

Ще була співбесіда у аутсорс-контору на Java-помідора.Там хлопців теж сильно цікавило, яким чином побудувати RPC, тестувати контракти і оце все. Відповідь я вже мав — gRPC :) Зараз усюди мікросервіс через мікросервіс, тому ці речі точно необхідно знати.

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

Інтерв’ю в highload стартап на Java-техліда.Там, де мені треба булона співбесіді за півтори години написати робоче рішення. Отож, я мав розмову з головним архітектором, і він почав мене питати по задачі. Як зробити, щоб тут було більше даних? А от якщо в нас буде даних забагато і буде ООМ, то що робити? А як можна попередити таку ситуацію? У цілому всі питання були спрямовані на те, щоб розібратися, як кандидат буде вирішувати більш складні задачі, які виникають при значному збільшенні обсягу даних.

Цю співбесіду я успішно пройшов і отримав офер.

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

Менеджерські та фінальні співбесіди

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

• Кому я буду репортити?
• Хто відповідальний за мій розвиток (якщо він є)?
• Яка використовується методологія розробки?
• Як організована комунікація? Які є канали, як вони використовуються? Що більше, що менше (пошта, Slack, Skype)?
• Скільки часу витрачається на мітинги та іншу комунікацію?
• Яким чином організовується документація на проекті?
• Чи мають інженери доступ до продакшн-систем?
• Як часто система деплоїться?
• Як робиться DevOps?
• Як організований контроль якості?
• Скільки людей у команді? Хто є на боці замовника?
• Які плани по проекту? Коли продакшн, коли саппорт? Які взагалі перспективи?
• Які найбільші складнощі на проекті прямо зараз?
• Чи бувають овертайми?
• Яким чином ухвалюють ключові технічні рішення?
• Які є можливості зростання на проекті?
• Хто стейкхолдери, яка структура власності (якщо це стартап або продукт)?

Мене цікавили такі питання, тому що насправді я прихильник async/remoteпідходу, але, на жаль, у жодній компанії нічого схожого не було. Всюди слаки та мітинги, що поробиш.

Якихось цікавих співбесід на цьому етапі в мене не було. Лише зачеплю тему переговорів.

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

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

Ще мав офер на позицію Java-техліда. Там мені запропонували на $300 менше, мотивуючи це тим, що в них по грейду більше не можна. Але якщо ось я пройду внутрішні курси на архітекта і стану архітектом, то дадуть більше. Я теж відмовився — ще чого. Невідомо, чи буде та позиція через півроку, невідомо, чи дадуть більше грошей і т. д.

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

Бонусні співбесіди

Ще я мав співбесіди у три різні компанії на позиції відповідно Solution Architect, Group Manager та VP of Engineering. Тут вже питання та підхід трішки інші, ніж на девелоперів та тімлідів. Розповім і про це, щоб розбавити нашу одноманітність технічних співбесід.

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

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

Щодо того, хто такий архітект, є крута стаття від Єгора Бугаєнко Are You an Architect?. Я з його концепціями повністю погоджуюсь.

В принципі я це все знав, але вирішив спробувати.

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

І ось ці всі люди мене по черзі починають питати, який у мене досвід в архітектурі, які документи я готував, як працювати з функціональними-нефункціональними вимогами, як робив планування навантаження та ресурсів (capacity planning), чи я це все якось захищав. Власне технічних питань не було: наприклад, як організувати read-heavy рішення, коли можна, а коли не можна NoSQL різних сортів та видів і т. д. Лише запитали про AWS, які сервіси я знаю.

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

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

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

У вердикті, крім того, що я нічого не знаю, написали: «He has very Technology Centric thinking». Думаю, що можна з натяжкою вважати це таким собі компліментом :)

До речі, щодо вердикту — я запросив у HR фідбек і рекомендації, і, на диво, мені їх надали досить розгорнуто. Щоправда, я зрозумів, що точно не хочу працювати Solution Architect :)

Друга співбесіда в мене була вже в іншу компанію на позицію Group Managerпари-трійки команд (загалом 20-25 голів).Їм потрібен більше менеджер, ніж технар. Враховуючи, що на аналогічній позиції з такою самою кількістю людей я вже відбатрачив у минулому кілька років, то мене розглянули. Сам я вирішив піти туди зі спортивного інтересу: дадуть офер — буду думати. Але великого бажання працювати менеджером у мене не було.

Спочатку був досить довгий (більше години) скрінинг по скайпу з рекрутером, де у мене з’ясовували минулий досвід. Потім почали задавати питання на конфлікт-менеджмент, типу «Є співробітник, який працює в команді, де роботи не так багато. Потрібно його перевести в інші, але він не хоче. Що будеш робити?»

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

Я прийшов до офісу, де мене вже чекали HR директор компанії та один з тих самих груп менеджерів. І почалося: розкажіть про ваш минулий досвід, а чому змінили роботу, чому розглядаєте менеджерську позицію, як ви себе оцінюєте, як ви надавали фідбек (позитивний або негативний), чому ви думаєте, що нам підходите, а які у вас були складні кейси, як оцінювати людей, як взаємодіяти з іншими менеджерами, як ви будували CI/CD ланцюжок (???) і ще якісь такі питання.

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

Час закінчувався, тому HR директор, який увесь цей час бачив мене наскрізь (маю на увазі те, що я не хотів працювати у них), сказав, цитую: «Подумайте про свої недоліки, а ми з вами зв’яжемося наступного тижня». Я швидко відповів, що дуже багато працюю та буваю настільки лояльним до компанії, що нехтую власними інтересами. Відповідь не проканала :)

Через кілька днів ми з HR директором знову зв’язалися уже в скайпі. Я намагався щось мукати та бекати про власні недоліки, але вийшло не дуже. У результаті мені винесли вердикт: «Сам не знає, чого хоче» та «незрілість», — що не дивно, тому що я дійсно не дуже хотів у них працювати. Крім того, мої справжні цілі точно йшли в розріз з очікуваними відповідями на позицію, тому я й склав враження типа, який сам не знає чого хоче :) А HR директор не дарма свій хліб їсть та бачить одразу лівих кандидатів. Йому респект, що мене не пропустив :)

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

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

Отож, спочатку мене чекав скрінинг по скайпу с HR. Були дефолтні питання про те, про се. Потім домовилися про ще один скрінинг вже з їхнім техдиром. Знову поговорили про те, про се. Їх дуже цікавив CI/CD ланцюжок чомусь — тут я трішки щось розумію, тому мене покликали поговорити вже очно.

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

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

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

Fin

На цьому все! За результатами проходження співбесід у 16 різних компаній за два місяці (жовтень та листопад) я провів 35 сесій, не враховуючи деяких співбесід з рекрутерами, які нічим не закінчились. Я витратив приблизно 40 годин чистого часу + 10 годин на вирішення тестових завдань. Отримав 3,5 офери (менше ніж 25% конверсії, що, як на мене, малувато). Від усіх відмовився з тих чи інших причин та залишився там, звідки й почав. Але вже краще розумію, що є на ринку, як скоротити час на проходження усіх кіл співбесід, як себе ефективніше поводити та як готуватися. Також мені залишилася купа своїх думок щодо цього всього, якими я з вами і поділився.

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

Як основний висновок цієї подорожі співбесідами я би хотів зазначити таке: хорошому інженеру з солідним досвідом немає ніякого сенсу працювати в українських аутсорс/аутстаф/offshore devcentre посередниках. Ви будете далі від кастомера, отримуватимете менше грошей, витрачатимете більше часу на комунікацію та політику, матимете менше перспектив. Шукайте віддалену роботу у стартапах та продуктових компаніях — там і гроші будуть серйозніші, і можливостей може бути більше. В ідеалі знайти віддалену роботу напряму від замовника із зарплатою інженера з Silicon Valley :)

Якщо вам сподобалась моя писанина, то не забувайте долучитися до мого Telegram-каналу.

Всім хорошої роботи та продуктивних співбесід у новому році!

Попередні частини:

Senior у пошуках роботи. Як я пройшов 20 співбесід з HR і що про це думаю

Senior у пошуках роботи. Як я пройшов 15 технічних співбесід і що про це думаю

Senior у пошуках роботи. Про задачі на технічних співбесідах і теоретичні питання

В этот раз DOU Ревизорпобывал в офисе WePlay! Esport Newmedia Group — медиаплатформы в сфере гейминга и киберспорта. Помимо разработки и онлайн-трансляций, компания занимается организацией турниров, подготовкой игроков, менеджментом команд и поддерживает сервис ставок на киберспорт.

Компания была основана в 2012 году и сейчас сфокусирована на профессиональных играх. На данный момент в WePlay! работает 155 человек, 29 из них — технические специалисты и разработчики.

В округе и поблизости

В офис по адресу Днепровская набережная, 21 компания переехала в августе 2018 года. Дорога из центра города на автомобиле занимает 20 минут. Также до офиса можно добраться за 15 минут пешком от станции метро «Осокорки» или доехать за 5 минут на маршрутке.

Рядом с офисом довольно много мест, в которых можно пообедать. В этом же здании расположена вареничная «Катюша», поблизости — рестораны il Molino, «Сушия», «Черноморка», «Сыто-пьяно», Carpaccio Café, а на противоположной стороне улицы скоро откроется River Mall. Перекусить также можно едой из холодильников в самом офисе.

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

Рабочее пространство

Нынешний офис WePlay! общей площадью 1100 м²полностью обустроили за год. Все рабочие пространства здесь выполнены в стиле open space. Кое-что все еще требует доработки, ремонт пока не на финальной стадии. Компания уже занимает 5-7этажи здания, соединенные бетонной винтовой лестницей, но планирует расширяться и дальше.

На данный момент в офисе всего 2 митинг-рума, названные в тематике гейминга: Hearthstone и Secret room — как отсылка к secret shop в Dota. Еще три комнаты — Counter Strike, Artifact и Dota 2 — пока на ремонте. «Пасхалки» и референсы к разным играм помогают увлечь новых сотрудников в индустрию киберспорта.

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

Количество квадратных метров на человека в рабочем помещении — 8 м² (по данным компании).

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

7-йэтаж здания WePlay! оборудован как лаунж-зона с PlayStation 4 и настольным футболом, которая своей круговой планировкой и желтыми стенами напоминает улей. Здесь же проходят уроки английского языка и иногда — собеседования. На этом этаже взгляд притягивают желтые стены и пиксельные декорации с макапами героев игры Super Mario и других игр 1980-х.По словам команды, когда в офисе проходят трансляции игровых турниров, пространство становится один в один похожим на пчелиный улей с огромным количеством людей внутри.

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

DOU Ревизор спрашивает

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

Виталий, Technical Product, 2 года в компании:

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

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

Иван, Chief Design Officer, 2 года в компании:

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

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

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

Анна, QA Automation Engineer, 6 месяцев в компании:

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

Ну что, мы поехали дальше... А если вы хотите, чтобы DOU Ревизор приехал к вам, пишите нам — revisor@dou.ua

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

Следите за нами на Facebook — www.facebook.com/dourevisor

Подписывайтесь на видеоканал DOU Ревизор на YouTube.

Фото: Леся Коверега.

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

Антон Бойко — Senior Solution Architect в Ciklum, а также основатель сообщества Microsoft Azure Ukraine User Group. Работает в IT более 10 лет, с 2011 года разрабатывает программы на базе Microsoft Azure.

Антон — обладатель почетного звания Microsoft Azure Most Valuable Professional (MVP) с 2014 года. Вместе с коллегами по сообществу он организовывает две популярные конференции по Microsoft Azure — AzureDayи Global Azure Bootcamp.

О себе

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

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

Интересно, что о вакансии преподавателя на курсах я узнал из газеты с объявлениями. А позже издатель этой газеты сам стал первым работодателем, куда я устроился как программист. Компания называлась Rabota+. Там я разрабатывал систему документооборота, отдаленно напоминающую современные CRM. Работал с Object Pascal на Borland Delphi 7, часть ресурсов была написана на PHP 5.

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

Переключившись на системное администрирование, я пришел работать в компанию «Информационные программные системы». Только сейчас понимаю, насколько крутыми вещами мы там занимались. На базе продуктов Microsoft мы построили решение, которое очень напоминало теперешний Microsoft Office 365. Мы начали продавать его по модели SaaS украинским клиентам — на 5-6лет раньше, чем это начал делать сам Microsoft.

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

О «гаражной» веб-студии и майндсете клиентов

Тогда я решил попробовать себя во фрилансе. Мы с женой основали собственную «гаражную» веб-студию и стали делать сайты на заказ. Сначала думали взять за основу PHP. Но я уже имел опыт работы с решениями Microsoft и решил попробовать C#/.NET. К тому же нам удалось получить от Microsoft бесплатные лицензии на Visual Studio и Windows Server по программе поддержки подобных «гаражных» проектов.

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

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

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

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

Об аутсорсинге и работе в Microsoft Украина

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

Потом было еще несколько компаний, среди которых Matrix42 и Livatek. В каждой из них я проработал год-полтора. Стек технологий варьировался вокруг Microsoft Azure. Но в какой-то момент заканчивались сложные задачи, и я двигался дальше.

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

В 2016 году меня пригласили поработать внештатным консультантом (вендором) в украинском офисе Microsoft. Разработкой украинский офис не занимается — в основном тут работают евангелисты, продавцы и маркетологи. Но я работал в экспериментальном проекте по поддержке инструментов Microsoft для европейских компаний, которые аутсорсят разработку в Украину. Я напрямую подключался к украинским командам и помогал им освоить и внедрить новые технологии, а также спроектировать архитектуру на их базе. Иногда такие пилотные проекты занимали до 3 месяцев, при этом я мог проводить все это время в офисе партнера. Кстати, одним из таких партнеров и оказался Ciklum, мой следующий работодатель.

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

В Ciklum я пришел как Solution Architect. На тот момент в команде архитекторов работало всего лишь 3 человека, включая нашего руководителя департамента. За следующие полгода-год я помог выиграть несколько крупных тендеров и получил повышение до уровня Senior Solution Architect.

О сообществе Microsoft Azure

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

В рамках сообщества мы проводим конференцию AzureDay. В 2018 году мероприятие собрало около 250 участников. Я стараюсь приглашать на Azure Day лучших украинских и заграничных экспертов, чтобы повестка дня состояла из максимально сложных и глубоких докладов. Мечтаю, что мероприятие будет привлекать не только местное сообщество, а и разработчиков из других стран Европы. Кстати, сама конференция уже выросла за пределы Украины: ее проводили в Беларуси, Польше, Болгарии и России.

Также мы поддерживаем в Украине Global Azure Bootcamp — это всемирная конференция, которая проходит в один и тот же день в разных городах мира. В прошлом году в ней участвовали суммарно 15 тыс. человек. Я координирую Global Azure Bootcamp в Киеве, мои коллеги — в Харькове, Львове и Одессе. В рамках конференции проходит благотворительная лабораторная работа: мы поддерживаем исследования для неприбыльной организации, которую выбирают организаторы.

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

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

Типичный рабочий день в Ciklum

Рабочие дни проходят очень по-разному в зависимости от того, какие активности я запланировал. Утром из дома я проверяю рабочие чаты и почту. На основе этой информации планирую день. К примеру, могу приехать в офис и к 7-миутра, если надо, или к 10-ти,как большинство коллег. Такой изменчивый график работы связан с тем, что моя основная роль в Ciklum — специалист по решению проблем. Почти как Мистер Вульф из «Криминального чтива» :)

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

На работу над проектами трачу около 4 часов в день. Примерно 2 часа — на самообразование и еще 2 часа — на менторство.

Что касается менторства, моя позиция — никогда не бегать за учениками. Это ученики должны бегать за ментором :) Люди должны быть заинтересованы в собственном развитии. Заставлять их что-то делать через силу нет смысла. Если у человека есть мотивация и он тянется к новым знаниям, я помогаю ему развиваться дальше. По такому принципу я обучал уже примерно 10 человек, и все они смогли добиться успеха в своих начинаниях. Если же у человека нет глубокого интереса, то я отказываю: вряд ли из этого что-то получится. Кстати, поэтому мне не очень интересно развиваться по линии people-менеджмента — мне кажется, что эта роль подразумевает бегать за людьми.

В офисе я провожу около 8 часов в день. На личном опыте убедился, что переработки до добра не доводят. Если «тушу пожар» и приходится засидеться, на следующий день прихожу позже или же ухожу раньше. Постоянных овертаймов стараюсь не допускать. К примеру, sales-менеджеры одного из проектов из США любили назначать митинги на поздний вечер, при этом команда начинала работать рано утром. Но я объяснил, что от меня будет намного больше пользы, если я не буду перерабатывать и хорошо отдохну.

На развитие Ukrainian Microsoft Azure Community трачу около 4 часов в неделю. Примерно столько же — на общение с коллегами по сообществу Microsoft Azure MVP. Мы даем компании обратную связь по продуктам и за это получаем бесплатные лицензии на продукты и сервисы, возможность протестировать обновления одним из первых (порой до того, как начнется private preview), а также доступ к сообществу экспертов и единомышленников по всему миру.

Инструменты и продуктивность

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

В плане офисных инструментов активно пользуюсь пакетом Microsoft Office 365. Стоит он относительно недорого и дает мне почту на личном домене, календари, хранилище файлов и лицензию на пакет Microsoft Office.

Основной инструмент коммуникаций — почта. Уведомления просматриваю всегда, но отвечаю на письма по мере свободного времени. Дополнительно использую мессенджеры. Для общения по работе — Microsoft Teams и Slack, для общения с друзьями — Skype и Facebook Messenger, порой Telegram. Но иногда часть рабочей коммуникации проходит и через Skype. Это мне не очень нравится, так как я стараюсь разделять личную и рабочую жизнь, но иногда бывают исключения.

Помимо инструментов для общения, я использую массу других приложений, которые нужны для работы. Чаще всего это Sourcetree и GitHub Desktop — для работы с исходным кодом. Rider, WebStorm, VisualStudio, VisualStudio Code — для написания кода, Postman — для тестирования API. Архитектурные диаграммы делаю в Visio и Draw.IO Desktop, документацию — в Camtasia Snagit. Для презентаций удобен PowerPoint, для заметок — OneNote.

Книжки и самообразование

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

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

На такой фриланс я трачу до 20 часов в месяц.

Что касается чтения, в основном это не книги, а статьи. Например, блоги крупных компаний и людей, которые в этих компаниях работают: Microsoft Azure Blog, AWS News Blog, Google Cloud Blog, Martin Fowler (ThoughtWorks), Donovan Brown (Microsoft), Troy Hunt (Microsoft). Слушаю HanselMinutes Podcast. Мне интересно, в какую сторону движется тот или иной вендор в плане развития своих технологий. Если какая-та тема цепляет, изучаю ее глубже. Пробую технологию руками и оцениваю, насколько ее маркетинговые описания совпадают с реальностью.

Помимо технологий, изучаю бизнес: как он работает, почему именно так, а не иначе. С каждым годом чувствую все больший интерес к этой теме. Читаю статьи людей, которым удалось реализоваться в бизнесе. Если говорить о книгах, очень нравятся работы Ицхака Адизеса"The Phoenix Project«Джин Ким, Джорджа Спаффорда и Кевина Бера, «Surrounded by Idiots»Томаса Эриксона, «Games People Play»Эрика Берна, «The World According to Clarkson»Джереми Кларксона и «Сказка о Тройке»Стругацких. Каждая из этих книг помогла мне стать тем человеком, кем я есть сейчас.

Ретроспектива и планы на будущее

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

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

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

Напередодні Нового року згадаймо, яким був 2018-й.Ми попросили топ-менеджерів IT-компаній, представників освіти та ІТ-спеціалістів поділитися одним реченням про свої найяскравіші досягнення за 2018 рік.

У результаті зібрали 41 коментар в максимально стислому форматі.

Хтось долучив до команди 2000 фахівців, хтось зібрав $500K на Kickstarter, а хтось нарешті отримав офер на позицію Senior Developer.

Юрій Антонюк, голова EPAM Україна

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

Ярослав Любінець, голова Ради директорів SoftServe

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

Ігор Бєда, керуючий директор GlobalLogic в Центральній та Східній Європі

У 2018 році я вважаю саме зростання основним позитивним показником: GlobalLogic в Україні перетнула межу в 4000 інженерів і досягла показника росту із року в рік — 30%.

Олександра Альхимович, Managing Director Luxoft Ukraine

Фахівці Luxoft Ukraine разом зі співробітниками Daimler AG розробили платформу для MBUX — інформаційно-розважальної AI-системи, яка була представлена на виставці CES 2018, а зараз вже встановлена у всіх нових Mercedes-Benz A-класу.

Олексій Сігов, President Infopulse

У 2018 Infopulse отримав статус CSP (Cloud Service Provider), відкрив канал продажу у цьому напрямку та успішно надає замовникам послуги та рішення — SAP on Azure, Cognitive on Azure та DevOps on Azure.

Андрій Крупа, CEO ELEKS

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

Віталій Седлер, CEO & Co-founder Intellias

Intellias виріс майже на 50%, ми відкрили офіс у Харкові та залучили інвестиції від Horizon Capital.

Валерій Красовський, CEO Sigma Software

Перемога команди Sigma Software на всесвітньому хакатоні Volvo, де наша команда запропонувала найбільш інноваційне рішення бізнес-проблеми і посіла 1-емісце серед 250-тикоманд з різних країн світу.

Андрій Павлів, CEO & Founder N-iX

Продовжили активно зростати, досягнувши відмітки в 100+ активних клієнтів та понад 900 професіоналів.

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

Отримали статус Platinum Partner компанії Salesforce Commerce Cloud, яких загалом нараховується менше сотні в світі.

Галина Шакірова, Chief People Officer Dev-Pro

Зміцнили позиції в топ-50 найбільших IT-компаній України — тільки за 2018 компанія виросла на 63%, зберігаючи гнучкість і адаптуючись до роботи з новими офісами: у Києві, Львові, Дніпрі та Шарлотті (Північна Кароліна, США).

Едуард Рубін, Founder, Chairman of the board Telesens

Telesens отримала патент на спосіб шифрування даних, а наш проект багатоцільової платформи для безпечного обміну повідомленнями в Інтернеті речей отримав відзнаку Horizon 2020.

Олександр Холодов, CEO Yalantis

Створили в компаніі нові експертні ролі, команду Golang та Node.js розробників, завели декілька enterprise клієнтів і виросли в два рази.

Андрій Скоропад, CEO Perfectial

У 2018 році ми виросли: відкрили офіси в Івано-Франківську та Києві, провели ребрендинг та оновили сайт, а також взяли участь у міжнародних подіях — Ukrainian Week in London і Malta Blockchain Summit.

Сергій Корнієнко, COO Agiliway

Випустили першу версію нашого власного продукту — мобільної CRM аплікації для некомерційних та громадських організацій CiviMobile.

Ігор Ткач, CTO Daxx

Запустили новий корпоративний сайт, увійшли у топ-10 рейтингу Clutch, отримали першого замовника з Австралії, пригостили голандських замовників вином у Amsterdam Tower, і нас стало більше на 20%.

Олег Богуславський, General Manager Ring Core

Покупка Amazon і зростання української команди до 800 осіб.

Василь Ульянов, Co-founder Genesis

Стали першою технологічною українською компанією-монополістом на ринку Африки і лідером додатків Health and Fitness на ринку США, отримали грант YouTube, визнання Facebook і Snapchat, а також запустили інвестиційний фонд Genesis Fund.

Олександр Косован, CEO MacPaw

За 2018 рік команда MacPaw виросла — свій 10-йДень народження ми відзначили релізом Gemini Photos і CleanMyMac X, а також запустили низку благодійних проектів: #CleanMyCity, #hellocode() та інші ініціативи #MacPawCares.

Олексій Орап, CEO YouScan

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

Денис Циганок, CEO & Co-founder ЛУН

Допомогли з пошуком житла 20 млн користувачам у 30 країнах.

Ігор Гнатовський, CEO LetyShops

Вихід LetyShops на міжнародну арену — мешканці Іспанії та Німеччини тепер повертають кешбек за онлайн-покупки.

Денис Жаданов, VP of Marketing Readdle

Застосунки Readdle досягли позначки в 100 млн завантажень.

Дмитро Думанський, Co-founder Blynk

Доросли до 100 млрд реквестів на місяць і 150K MAU.

Роман Кравченко, Founder IoT Hub

Стартап акселератора IoT Hub — Feel VR — зібрав $500K на Kickstarter, рекордні для України, а мети — перших $60K — досягнув усього за 75 хвилин.

Тарас Поліщук, CTO & Co-founder TripMyDream

Виросли на 120% у продажі авіаквитків, відкрили новий медіанапрям на YouTube і розвинули його до 115К підписників, побудували кілька B2B-рішень у travel для Британського ринку, а також переформатували команду і сфокусувалися на розробці нового авіапродукту.

Вікторія Репа, CEO & Co-founder BetterMe

Зміцнили лідерські позиції в категорії Health & Fitness в США, досягли 15 млн завантажень по всьому світу і були визнані однією з кращих компанії, які швидко розвиваються, за версією App Growth Awards.

Ігнат Тхоровський, СТО & Co-founder PopTop

Стали першою івент-платформою з транзакційною моделлю в Британії, а також згенерували £9 млн для виконавців і збільшили кількість замовлень на 100%.

Ахмед Сулейман, CEO Flawless App

Пройшли в акселераційну програму Techstars London, що дозволило нам швидше підтвердити стратегічно важливі продуктові гіпотези і отримати мережу контактів UK інвесторів, клієнтів, менторів.

Тимур Шемсединов, архітектор технологічного стеку Metarhia, замдиректора ДП інфотех МВС України, викладач КПІ

Нам вдалося побудувати конвергенцію технологічного стеку Metarhia, Єдиної ІС МВС України з інженерним і навчальним потенціалом КПІ, де я читаю курс, 50 зі 100 відео вже доступні на Youtube.

Олексій Молчановський, Academic program director of MSci in Data Science Ukrainian Catholic Univeristy

Три роки поспіль студенти-магістри УКУ потрапляють у фінал міжнародних змагань Queens International Innovation Challenge, а цього року наших команд було вже дві.

Зеновій Верес, директор освітнього напряму Львівського ІТ Кластеру, к.т.н., асистент кафедри комп’ютеризованих систем автоматики НУ «Львівська політехніка»

В 2016-мубула 1 програма Кластеру і 55 студентів, цього року вже 9 програм і 724 студенти, які вступили на програми Кластеру.

Павло Педенко, консультант з Product Management

Зробив найбільший хакатон у Європі і першу англомовну конференцію з growth marketing в Україні.

Єгор Папишев, Offensive security researcher

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

Олександра Ковальова, QA Evangelist, Certified Unicorns

Після отримання IT Awards, в 2018 пішла з компанії і заснувала першу в Україні спільноту для обговорення та впровадження міжнародних стандартів з тестування — Ukrainian ISTQB Community.

Євген Канівець, Mobile Engineer, 360Learning

Рік роботи в паризькому стартапі 360Learning — вивчення французької мови, продуктової культури, участь у хакатонах.

Артур Чистяк, Tech Lead, KeepSolid

Провів 3 навчальні курси з C++ в Одеському національному політехнічному університеті і навчив основам С++ 250 студентів — при цьому я сам студент 4-гокурсу цього ж університету і паралельно працюю в IT.

Сергій Марієха, Go Engineer, Percona (ex @MacPaw)

Пішов з топової продуктової компанії країни, щоб писати на Go.

Денис Ювженко, C++ Developer, eZlo

Нарешті отримав офер на позицію Senior Developer.

Юлія Іщенко, QA Engineer, GlobalLogic

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

Олексій Пастухов, Team Lead, Sigma Software

Став одним з maintainer-ів опенсорс проекту Storybook.

Іллюстрації — Євген Величев

Дайджест создан в соавторстве с Павлом Кривко.

00h > Интро

Привет! В предновогоднем выпуске мы расскажем о том, как прошел UA-CTF в Киеве, покажем материалы ZeroNights 2018, поговорим о взломах в Украине и мире, поделимся парочкой авторских статей и инфой по уязвимостям и сплойтам. Не пропустите самый жирный выпуск уходящего года!

01h > Горячее

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

В Киеве состоялась ежегодная конференция по информационной и кибербезопасности UISGCON14. Качественное видео с докладами и презентациями разных потоков этого большого ивента уже доступнодля всех, на Youtube-канале Securit13 Podcast. Кстати, а разве вы еще не постоянный слушатель первого украинского подкаста по ИБ?

Хочется отметить офигенно атмосферный UA-CTF, который прошел в Киеве 16 ноября. Участники рубились за призы в режиме 24 non-stop, в клевой локации, над задачами, которые были максимально приближены к реальным кейсам и киберинцидентам 2018 года. Это первое мероприятие в Украине, проведенное именно в таком формате — впечатление можно составить по фоткам с ивента, который, к слову, был бесплатным. Основной контингент состоял из участников самого большого в Украине true 1337 h4×0r комьюнити — киевской Defcon группы DC8044, однако были ребята и из других городов. В итоге — абсолютно состоявшееся мероприятие высокого уровня, которое теперь будет проводиться на регулярной основе и с большим размахом!

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

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

Поликлинику № 2 Управления делами Президента РФ атаковала неизвестная хакерская группа, с использованием zero-day эксплоита под Flash. Исследование уже опубликованов разныхисточниках, а следы хакерской APT-группы ведут в Украину. Стоит отметить, что атака произошла практически сразу после инцидента в Керченском проливе.

Одному из авторов этого дайджеста удалось угнатьчужой ботнет, состоящий из многих сотен троллей ФБ, Инсты и ВК. Привет!

02h > Около секьюрити

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

Неизвестные, воспользовавшись недостатками в API-инструментарии площадки OLX.ua, спарсили базу объявлений этого украинского сервиса (за период, порядка, девяти дней). Получился массив из 55К записей, среди которых: ИД объявления, телефон продавца, город, дата, категория, имя продавца и ссылка на объявление Где-то на просторах гхостбина можно найти какую-то ссылку, актуальность которой под сомнением.

КБ «Южное» запустилосамый мощный в Украине суперкомпьютер, который ночью нашептал уборщице про XSS на сайтеКБ «Южное».

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

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

Лаборатория CISCO Talos опубликовала исследованиео TeleGrab: с помощью этой малвари можно красть пользовательские сообщения в сервисе Telegram.

Хакеры инфицируют Linux-сервера рансомварью JungleSec через IPMI Remote консоль.

Сервис Gazorp, размещенныйв TOR, позволяет самостоятельно собрать себе бинарь с популярным стилером AzorUlt версии 3.0, вам нужно только указать адрес своего С2 сервера и получитьготовый билд. Удобно, комфортно, для людей.

03h > Интересное

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

Вы занимаетесь malware-анализом, а может быть, работаете в SOC/CSIRT? Тогда эта софтинадля вас: автоматическая идентификация и классификация малвари (сканирование сорц кода via Yara), получение дампа оригинального кода, интеграция с кучей полезных open source тулзовин и удобный интерфейс. Бесплатно. А демка вот тут.

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

Основная масса новостей и информации о различных событиях в мире безопасности ICS/SCADA находятся на профильном каналев Telegram.

Небольшая, но удачная подборка тематической литературы доступнана Меге. Среди книжек есть такие хиты, как Practical Malware Analysis, Hacking — The Art of Exploitation, Serious Cryptography и ряд других.

Опенсорсная тулзадля реверса и анализа Android APK поможет ресерчерам и энтузиастам.

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

Хорошая и полезная подборка материалов по Active Directory Attack & Defense опубликована тут.

Видео докладов со встречи DEFCON MOSCOW 15 уже доступнок просмотру. DNS-туннелирование в нынешних реалиях, мифология о приватных мессенджерах, рекон веб-приложений и другие интересные темы!

Возможно, вам понравится очередная вариацияна тему NETworkManager-ов.

На днях PENTESTIT запустили свежую «Test lab» v.12 — лабораторию тестирования на проникновение, имитирующую работу реальной корпоративной сети. Попробовать свои силы можно тут. А гайд от разработчиков опубликовалина Хабре.

Степ бай степ: разбираемвредоносный .LNK файл от APT29, на пальцах.

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

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

Bellingcat’s Online Investigation Toolkit будет интересен тем, кто занимается OSINT и прочей разведкой. Документ доступенна гугл-диске.

И в продолжение темы OSINT, статьяс описанием базового «must have» инструментария для разведки в 2019 году от гуру из команды SpiderFoot, — Steve Micallef.

04h > Уязвимости && Эксплоиты

Допиленный сплойтпод MS17-010, с расширенным функционалом и модифицированный, с учетом реализации реверс-шелла.

Readfile 0-dayсплойт под Winнедолго оставался приватным. Его можно было приобрести за вполне подъемные деньги вскоре после появления, а затем он и вовсе был вылит в пабликавтором SandboxEscaper, который дисклозит свои 0day уже не первый раз. Актуальная на текущий момент ссылка для загрузки РоС-сплойта тут (но все может поменяться в любой момент).

Заинжектить вредоносный HTML/Javascript в документ Word 2016? Нет ничего проще с использованиемсоответствующей уязвимости и скрипта PowerShell.

Эксплоит под недавно патченную уязвимость CVE-2018-15982 во Flash, опубликованэнтузиастом на GitHub.

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

05h > Фан

Украинский гидрометеорологический центр подвергся нападению highly sophisticated ROFL APT, недавно открытого класса APT нового поколения. Они похекали почтовый сервер Укргидромета, так как данные SMTP учетки были общедоступнына GitHub. Больше коммитов — больше атак!

Интересная и загадочная фигня. Попробуйте свои силы.

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

Пошел в магазин и без приватного сплоента? Да вы вайтхет!

06h > Аутро

Happy Holidays 4all! XD

← Предыдущий выпуск: Information Security дайджест #11.
Следующий выпуск: Information Security дайджест #13→

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

Результати опублікуємо наприкінці січня.

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

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

В 2018-муспільнота DOU виросла — нас вже 278 тис. зареєстрованих користувачів. Ми з вами написали більше 500 статей, створили майже 2 тис. топіків та залишили 233 тис. коментарів.

Найкраща аналітика

Ми випустили 21 аналітичний матеріал, що зібрав 872 тис. переглядів. Середня кількість переглядів кожного тексту — 41 тис.

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

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

Рейтинг мов програмування 2018: Go і TypeScript увійшли до вищої ліги, Kotlin варто сприймати серйозно.З 2010 року Руслан Шевченко робить рейтинг мов для спільноти DOU. Вже наприкінці січня опублікуємо ювілейний, 10-йвипуск. А поки — заповнюйте анкету!

ТОП-50 ІТ-компаній України, липень-2018: стабільне зростання та 50 тисяч спеціалістів.За підсумками першого півріччя 2018 року ТОП-50 досяг нової відмітки — 52 тисячі спеціалістів, з яких 41 тисяча — технічні фахівці. Уже друга ІТ-компанія в Україні переступила відмітку 5 тисяч спеціалістів, а одна з компаній з ТОП-50 на ринку майже 30 років.

Найкращі ІТ-роботодавці 2018.Цього року ми перезапустили рейтинг роботодавців — обнулили попередні голоси, розширили анкету та створили категорію для великих компаній. За два місяці 14 602 ІТ-спеціалісти проголосували за 993 компанії.

Рейтинг шкіл за результатами ЗНО-2018.В 2018-муСергій Городецький, автор рейтингу, враховував результати ЗНО за три роки.

Портрет ІТ-спеціаліста — 2018. Інфографіка.Вже за гарною традицією третій рік поспіль створюємо інфографіку для Портрету з POPEL Agency. Цього разу в стилі pixel art.

Рейтинг вишів DOU 2018: Могилянка знову в лідерах, Львівська політехніка наприкінці списку.Із цікавого — у трійці лідерів одразу два харківських університети, а КПІ, як і минулого року, всередині списку. Окрім рейтингу, ми ще з’ясували, що майже половина нинішніх студентів ідуть у виш лише за «корочкою», а 25% отримують роботу вже 1-2 курсі.

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

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

Яких спеціалістів шукали в 2017 і на кого є попит у 2018. Бліц з ІТ-компаніями.Ми опросили ІТ-компанії, технічна команда яких, за даними ТОП-50, зросла більш ніж на 100 спеціалістів у 2017 році. З’ясувалося, що в 2017 році найчастіше шукали спеціалістів рівня Middle. Найпопулярнішими технологіями були QA, Java, .NET, JavaScript та C++.

Перша робота: скільки junior спеціалістів найняли IT-компанії в 2017 році.За 2017 рік 43 IT-компанії найняли більше 3 тисяч молодих фахівців. Більше 50% джуніорів увійшли в ІТ через внутрішні курси при компаніях.

LinkedIn, Джин і рекомендації — найкращі канали пошуку спеціалістів. Результати рекрутинг-опитування. DOU багато років проводить опитування програмістів, але практично ніколи не опитує «іншу сторону» — роботодавців. На Джині вирішили виправити це і провели опитування серед роботодавців і рекрутерів.

Ринок праці 2018: рекордні темпи росту і 160 тисяч спеціалістів.За нашими підрахунками, кількість зайнятих спеціалістів в українському ІТ за рік збільшилася на 33 тисячі. Галузь продовжує зростати рекордними темпами, і схоже, що стримує її лише дефіцит кадрів.

Скільки ІТ-спеціалістів в Україні: підрахунок за даними Мін’юсту.За відкритими даними реєстру фізичних осіб-підприємців, в Україні 123 тисячі ФОПів айтішників станом на квітень 2018 року.

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

Найкращі колонки

21 колумніст опублікував 36 колонок, які зібрали понад 550 тис. переглядів. Відібрали 13 найцікавіших на думку редакції:

Що не так із апельсиновим соком.Художній текст від Юрія Савки. Як завжди, в його колонках присутні гумор та іронія, а читаються вони на одному подиху. Фраза про апельсиновий сад через п’ять роківвже стала крилатою на DOU.

Проблеми входження в IT: чому кандидати не підходять, або Що робиться не так.Микола Лотоцький написав дві колонки на тему входження в ІТ, які загалом набрали майже 70 тис. переглядів. Це друга частина циклу присвячена завищеним вимогам для початківців, перша частина — про те, чи варто йти на курси.

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

Outsourcing vs software consultancy: як підняти рейти до 75 USD/година.Сергій Корольов, Managing Director в Railsware, поділився досвідом, як їм вдалося змінити бізнес-модель та підняти рейти.

Технічна співбесіда на Java-розробника: питання і поради щодо підготовки.За останні 10 років Зеновій Верес провів понад 300 технічних інтерв’ю Java-фахівців — як Intermid, Senior рівнів, так і TechLead/Architect. Він поділився своїм підходом до проведення технічних співбесід, спостереженнями та загальними рекомендаціями, які можуть допомогти кандидатам справлятися із завданнями успішніше.

Професійне вигорання: як не «перегоріти», коли дуже припече.Тема вигорання дуже популярна на DOU. Одні не сприймають його серйозно, інші — вважають цей стан є вагомою професійною проблемою. Альона Черненко-Диба, автор статті, поділилася висновками, які вона зробила, зіткнувшись із вигоранням.

Я, девелопер.Що означає бути Full Stack девелопером в наші дні і чому практичний досвід — це ключ до того, щоб стати справжнім експертом в області мультітехнологій — розказав Павло Веллер, CTO, Digital Engagement Practice в EPAM Systems.

Від дедлайна до реченця: роздуми про українську мову в ІТ.«Я описала фічу, заеплаїла коменти, потім не ранився білд...». Ярослава Качан, Technical Writer в Ciklum, поділилася роздумами щодо непростих взаємовідносин української мови і англійської технічної термінології.

Будуємо сильну команду: від 0 до 100.На думку Дмитра Зинов’єва, Software Engineering Manager в EPAM, головне завдання полягає не в тому, щоб набрати сильних і самостійних людей з ринку. Метою повинна бути безперервна інвестиція в лідерів.

Переходимо на Java 10: проблеми та рішення.Дмитро Думанський одним з перших перейшов на дев’ятку. І перехід на Java 10 не став виключенням — через місяць після виходу нової версії Дмитро все випробував та поділився зі спільнотою.

Сто років менеджерського досвіду в IT, або Свій досвід добре, але і до інших розумних людей варто прислухатися.Віктор Матусов, директор з інжинірингу в GlobalLogic, розказав про цікавий досвід після роботи з 10-марізними керівниками.

Хто, де і як буде вчити тестувальників в Києві в 2026 році.Олексій Лупан, QA Trainer в Astound Commerce, вважає, що традиційні навчальні курси коли-небудь «закінчаться». Майбутнє — за курсами, які готують до роботи в певній компанії. І головне — вони повинні не вчити, а тренувати.

Для чого технарям бізнес-освіта: мій досвід навчання у Львівській бізнес-школі.Зеник Матчишин, CTO в Altran Ukraine (Lohika), маючи 17 років досвіду в ІТ, вирішив ще отримати додаткову освіту в LvBS. У колонці він поділився досвідом, як проходить навчання та навіщо технічному фахівцю можуть знадобитися знання бізнесу.

Найкращі інтерв’ю

Ми опублікували 22 інтерв’ю, які зібрали 365 тис. переглядів. Більшість з цих матеріалів про українських спеціалістів з закордону. Але були цікаві історії про програмістів та науковців, які живуть і працюють в Україні.

17-річнийпрограміст з Кропивницького — про любов до Embedded, розчаруванні в КПІ і роботі в аутсорсі.Найпопулярніше інтерв’ю 2018 року — майже 40 тис. переглядів і три сотні коментарів. Хтось героя засуджував, хтось підтримував. Але Руслан Коптев йде своєю дорогою, він не давав порад, а лише ділився своїм досвідом.

Один з сорока тисяч: українець Євген Василенко про навчання в Каліфорнійському університеті в Берклі.Одесит Євген Василенко в 2015 році став студентом UC Berkeley за фахом «Комп’ютерні науки». Про те, чи складно туди вступити і як це, вчитися в університеті, де є окремі парковки для нобелівських лауреатів, — Євген розповів DOU.

52-річнийпрограміст — про те, як бути джуніором у 46, переїзд до Грузії та податок 0%.Дмитро Скороход, iOS розробник, поспілкувався зі своїм батьком Михайлом, який в 46 років став джуніором, а потім переїхав до Грузії. Навіть Саакашвілі опублікував це інтерв’ю на своїй сторінці в FB.

Дизайнер Павло Грозян: «У Сан-Франциско і Долині ти можеш заробляти стільки, скільки захочеш».Павло Грозян переїхав з Києва в Сан-Франциско в 2016 році за візою О-1 для людей з видатними здібностями. За два роки він двічі отримував цю візу. Вперше — коли перейшов працювати з Grammarly в фінтех-стартап Zero, а другий раз — нещодавно, коли приєднався до спеціального проекту Reddit.

«У мене був кращий старт, ніж у випускників Стенфорда, бо в мене багато досвіду». Розповідь Senior software engineer з LinkedIn Марії Панютіної.Львів’янка Марія Панютіна вже 6 років живе в Кремнієвій долині. За цей час вона народила там двох дітей, перейшла з GlobalLogic у LinkedIn і отримала підвищення до Senior software engineer.

Український розробник Віктор Радченко — про втечу в США, створення двох успішних стартапів до 30 років і майбутнє блокчейну.Ще будучи студентом, Віктор Радченко очолював відділ по інтернет-безпеці в «ПриватБанку». Сьогодні, у свої 27 років, він вже створив два стартапа, які придбали глобальні компанії.

Українська програмістка — про адаптацію в США та Франції і саббатікал у таїландському цирку.Анна Саварин, Site Reliability Engineer у французькій компанії Criteo, здійснила вже дві релокації — до США та Франції. А відчувши професійне вигорання, поїхала до Таїланду працювати в цирку та займатися спортом.

Програміст з Амстердама — про 90-тіроки в українському ІТ, роботу в Booking.com та життя в Нідерландах.Євген Сандуленко працює Manager Software Development в Booking.comв Амстердамі. Розбиратися в комп’ютерах він почав ще з кінця 80-х.Працював розробником, керівником аутсорс-проектів, директором, але згодом повернувся до технічної ролі.

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

Дослідник нейромереж — про півсотлітню історію штучного інтелекту, свідомість АІ та розвиток людства.Чому в розвитку нейромереж немає особливих результатів ще з минулого століття, а захоплення темою спаде в найближчий час, чи може штучний інтелект мати свідомість та як комп’ютери вже керують людьми — Олександр Різник, доктор технічних наук, піонер нейромереж, розповів в інтерв’ю для DOU.

Найкращі статті

213 авторів опублікували 235 статей, які зібрали 2,8 млн. переглядів (не враховуючи матеріали редакції та редакційних авторів). Нижче найкращі матеріали на думку редакції, відсортовані за тематикою та кількістю переглядів.

Для програмістів

Senior у пошуках роботи. Як я пройшов 20 співбесід з HR і що про це думаю.Володимир Рожков, Senior розробник, протягом декількох місяців проходив співбесіди приблизно в 16-тирізних компаніях на різні вакансії. Він провів 35 сесій, витратив приблизно 40 годин чистого часу + 10 годин на вирішення тестових завдань, отримав 3,5 офери. А ще написав цикл статейпро кожен з етапів співбесід, який зібрав майже 100 000 переглядів.

Новий 15-річнийпроект без команди і документації: як ми вижили.Проекту вже більше 15-тироків, він високомаржинальний, з великою кількістю клієнтів, написаний і підтримуваний трьома програмістами з Коннектикуту. На чому написаний проект, як все працює, як інтегрований в існуючу інфраструктуру, чи є build- і deployment-процес, чи є якась документація? На всі ці питання відповідей не було. Але одне було ясно як божий день — всі програмісти скоро звільняться, а робота системи не повинна зупинитися.

Українське ІТ в 90-тіта на початку 2000-х:перші офіси компаній.На початку 2000-хроків в Україні вже було засновано зо два десятки ІТ-компаній з ТОП-50 найбільших. Сьогодні в цих компаніях працюють тисячі спеціалістів, давайте подивимося, з чого вони починали свій шлях в ІТ.

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

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

Причини для зміни роботи в ІТ, або Почнемо з себе.Керівник «редиска», зарплата не влаштовує, і взагалі мені саморозвиватися не дають ... Артур Селецький, co-founder в IT Network, радить, перш ніж змінювати роботу, розібратися. Може, причина в вас самих, а не в компанії.

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

Мій шлях у західні продуктові компанії: від відмови Twitter до офера Facebook.Розробник Артур Кушка останні півроку провів на співбесідах в такі компанії, як Elastic, Twitter, Google, Facebook. Від останньої йому вдалося отримати офер. Артур доводить, що потрапити в компанію мрії цілком реально.

Як тімліду розвивати себе і команду: принципи SOLID.Протягом останніх двох років Владислав Анікін працює на позиції Team Lead в Provectus. У своїй практиці він застосовує принципи SOLID для персонального розвитку всіх і кожного в команді. Ось як це робиться.

Кар’єрні рішення на прикладі комп’ютерних ігор початку 2000-х.Завжди цікаво шукати аналогії там, де їх не чекаєш знайти. Станіслав Калацький, Head HR в DataArt, зібрав приклади зі знакових комп’ютерних ігор, які допоможуть прийняти непросте рішення в кар’єрі.

Для менеджерів

Що повинен уміти PM і як розвиватися на рівнях junior, middle, senior.Які аспекти спеціальності необхідно вивчати, з чого починати і що робити для подальшого зростання в управлінні проектами — розповів Дмитро Растатурін з Daxx.

Як поєднувати full-time роботу в офісі і подорожі.Віталій Марусяк, Project Manager в Provectus, за 11 років побував у більш ніж 60 країнах. При цьому він весь час працював в офісі full-time. Головний його секрет — потрібно чітко знати, де і як шукати квитки, житло, як купувати і продумувати заздалегідь детальний план поїздки, щоб встигнути якомога більше.

11 звичок проектного менеджера для ефективної роботи.Олена Сунчелеєва, Senior PM в Dev-Pro, розповідає про звички, які допомагають їй звільнити кілька годин на тиждень, уникнути частини пожеж, конфліктів і непорозумінь.

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

Як впливати без влади — радить TPM з Amazon.Ганна Хабібуліна, TPM в Amazon, пропонує почати розмову про те, як побудувати і підтримувати продуктивні відносини на роботі, які потрібні для успішної здачі завдань і проектів.

Як я готувався і здав PMP Exam з результатом «Above Target» по PMBoK 6th Edition.У червні цього року Костянтин Болотін, PM в AltexSoft, здав PMP сертифікацію з результатом Above Target. У статті він поділився своїм планом підготовки, порадами, корисними посиланнями та деякими нюансами, які виявив безпосередньо до і під час іспиту.

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

Як ми масштабувати команду і вижили.За півроку одна з команд в Dev-Pro зросла з 10 до 60 розробників. Андрій Щетина, Senior Project Manager, поділився досвідом, як перенести такі зміни, хоч і не безболісно, але успішно.

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

Для новачків

Junior, Middle, Senior, Lead — в чому різниця і куди далі.Олександр Демура керує центром розробки DataArt в Одесі. В його безпосередні обов’язки входять найм та розвиток фахівців, тому міркування на тему «сіньорності» для нього актуальні і звичні.

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

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

Як підходити до тестових завдань: поради від тих, хто їх перевіряє.Навіщо потрібні тестові завдання, як їх оцінюють і як з їх допомогою добре себе зарекомендувати, особливо якщо ви Junior? Про це ми розпитали IT-фахівців, які в своїх компаніях відповідальні за перевірку таких завдань.

Ruby для початківців: чим цікава ця мова і як її ефективно вивчати.Іван Бондаренко, Ruby Technical Lead в CHI Software, розповів про особливості Ruby і Ruby on Rails і поділився порадами про те, з чого почати вивчення Ruby.

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

«У 2016-мумоя зарплата з двох шкіл становила 2400 гривень». Як я пройшов шлях від сільського вчителя до програміста.Богдан Овенко вже рік як Java-розробник. У професію прийшов після того, як три роки відпрацював учителем інформатики, фізики та астрономії в середній школі. Стрес та інші негативи на роботі підштовхнули його стати програмістом.

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

Як безкоштовно вчитися на магістратурі з Data Science в Європі. Досвід українки.У 20 років львів’янка Марія Королюк поїхала вивчати Data Science у Швецію, а потім — в Англію. Встигла попрацювати в компанії McKinsey and Company, а зараз влаштувала собі gap year і подорожує світом. У статті Марія розповіла, як знайти безкоштовну програму зі стипендією, що дає навчання в Європі та чому варто спробувати.

Увійти в ай-ті. Частина друга: посібник для вступників до вишів.Перша частинациклу про старт в ІТ від Володимира Кожаєва зібрала понад 80 тис. переглядів. В другій частині Володимир розповів про процес вступу в життя студента айтішной спеціальності.

Технічні статті

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

Вступ до Machine Learning: знайомство з моделями.Володя Штеньович, SSE в Google, написав цикл статей для тих, хто опановує Machine Learning. В першій частині автор знайомив з основними принципами роботи, а в другій — перейшов до практики роботи з TensorFlow.

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

.NET Core: як працюють мікросервіси в контейнерах.У всьому світі мікросервіси — вже практично мейнстрім. В .NET ми тільки починаємо рухатися в цьому напрямку. Сергій Алмазов, Chief Architect в BETLAB, розповідає про принципи роботи мікросервісов.

Огляд CSS Grid — технології для спрощення розмітки HTML-сторінок.З’явившись в 2011 році, технологія CSS Grid продовжує викликати все більше інтересу. Ця стаття — невелике керівництво по технології з коротким описом найцікавіших можливостей і функцій. Вона буде корисна фронт-енд розробникам, а також іншим спеціалістам веб-розробки та дизайну.

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

Готові рішення для QA: як писати автотести на Groovy.Ярослав Святкин, тренер QA Automation & Groovy, поділився досвідом, як швидко писати тести на мові програмування Groovy, не думати про фреймворки, PageObject і ініціалізації WebDriver.

Підходи і технології в React Redux: робимо все оптимально.За останні 3 роки роботи з React Андрій Лазарев, Lead Software Engineer в Innovecs, створив з нуля близько десятка проектів. У статті він ділиться досвідом вибору підходів та інструментів для старту нового проекту і рефакторінга існуючого на React / Redux.

DIY. Підводний дрон. Історія одного божевілля. Android-розробник Євген Ткаченко розповідає, як він зібрав підводний дрон на базі Raspberry PI з управлінням зі смартфона. Рішення вийшло не ідельним, но такої мети і не було. Головне — отриманий досвід. Як каже Євген, після такого і за розробку розумного будинку не страшно братися.

Система для збору логів Elasticsearch + Fluentd + Kibana. Як це працює у нас.Побудувати систему збору, зберігання і аналізу логів досить просто, навіть використовуючи безкоштовні проекти. Андрій Товстоног, DevOps engineer в Genesis, розповів, як це працює у них.

Про релокацію

Як потрапити в Google: інструкція з підготовки.Цю статтю однозначно можна було б винести окремим блоком в найкраще за всю історію DOU — майже 100 тис. переглядів. 1,5 роки Сергій Сема готувався до оферу в Google. Готовувся планомірно майже кожного дня. В результаті він отримав офер, а ще написав корисну статтю для спільноти.

Про менталітет датських IT-шників — розповідь українського розробника.Напевно всі пам’ятають поверненняОлександра Скакунова з Данії. Він прожив в Копенгагені 5 років. За цей час встиг попрацювати СТО в датському стартапі, а також розробником в IT-відділі телекомпанії TV2. У новій статті він порівняв українські та датські айтішні реалії — в результаті 50 тис. переглядів і 800 коментарів.

Життя в Новій Зеландії: про пошук роботи, дороге житло і уявну свободу.Олександр Басан переїхав в Нову Зеландію з Києва в лютому 2015 року. «Коли я їхав до Нової Зеландії, я читав про її прекрасну природу і дорогу нерухомість. За 3 роки до природи я звик, а до цін на нерухомість — ні».

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

Мої спостереження про Кремнієву долину: міфи vs реальність.Чи правда, що інтерв’ю в компанії Кремнієвої долини такі складні? Чому там не прийнято працювати віддалено? Оксана Чуйко, Software Engineer в Styra, живе в Долині вже 5-йрік і знає відповіді.

Країна відчинених дверей. Українська програмістка про життя в Канаді.Даша Бондарева вже 7 років живе в Канаді, з них 4 — працює Software Developer в Amazon. Вона розповідає, що Канада — дуже різноманітна країна, привітна до мігрантів. А на природу неможливо надивитися вдосталь.

Країна статків і довіри: Норвегія з погляду українського програміста.У Data-інженера Олександа Іванова цікава історія. Ще будучи джуніором, він влаштувався на роботу Front-end розробником в іспанську компанію. А нещодавно отримав пропозицію від норвезької компанії і, недовго думаючи, перебрався туди.

Чому вони не їдуть з України: історії IT-спеціалістів.Ми розпитали досвідчених IТ-спеціалістів, чи розглядали вони можливість релокації, що їх утримує в Україні та чи допускають вони думку, що коли-небудь поїдуть.

Релокація в американську глибинку: мої 4 роки в Вісконсині.Валентин Пономаренко, Golang / .NET Software Engineer, переїжджаючи в США, вирішив вибрати не найпопулярніший напрям і оселився у Вісконсині. Там в основному enterprise-сегмент і стартап-культури, по суті, немає, але дружне IT-ком’юніті можна знайти.

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

Форум та читачі

В 2018-муви опублікували 1833 топіка, які зібрали 167 тис. коментарів. Майже 13 тис. користувачів DOU залишили хоча б один коментар.

Найактивнішим став Viktor Chyzhdzenka — у нього більше 8 тис. коментарів в 2018-му,найчастіше ви підримували думки Elena Morgun (серед користувачів з 300+ коментарями за рік) — кожен її коментар в середньому збирав 6 лайків, а найпопулярнішим став коментар Oleg Zarevych — 252 лайки.

Ось 15 тем, які ви обговорювали найактивніше минулого року, кожна зібрала понад 30 тис. переглядів і сотні (а іноді тисячі) коментарів:

1. База даних усіх програмістів
2. І знову бляхи, розмитнення?
3. Травля PULS Software и о нескольких интересных личностях
4. Воєнний стан
5. Законопроект про відміну 3-їгрупи оподаткування — початок кінця українського айті?
6. 23-річний .NET девелопер зі Львова потребує допомоги спільноти
7. Хто куди інвестує тяжко зароблені?
8. Почему вы иммигрировали?
9. ВикиЛиксУа або Черный список гнобителей неньки
10. Правило +500$?
11. Приєднуйтесь! Amazon Hiring Event — Kyiv/Lviv з 19 по 23 лютого
12. Як співбесідувати сіньйорів-помідорів?
13. Зарплаты не в ИТ
14. Ноутбук для девелопера в 2018 году
15. Накипело! Или почему стоит стать трактористом

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

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

[Андрей Дрожжин — Product manager Roadmap Planner в KeepSolid. Более 20 лет стажа в производственно-коммерческих компаниях на С-level позициях. Учился в EMBA Sheffield и Институте глубинной психологии, получил диплом Chartered Management Institute. Объединяя свои знания и бизнес-опыт, работает над темами развития и обучения в организациях, в т.ч. занимается разработкой инструментов в сфере управления знаниями]

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

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

Daniel Ammann «The King of Oil: The Secret Lives of Marc Rich»

В русском переводе — Дэниел Амманн «Нефтяной король. Секретная жизнь Марка Рича»

Одна из самых необычных биографий, которая представляет собой удивительный коктейль бизнес-ситуаций, политический решений, отношений личности и государства и массы примеров нестандартных решений. Марк Рич совершил революцию — превратил нефть в рыночный товар. До него торговлей нефтью занималась монополия — «закрытый клуб» из 7 компаний, т. н. «семь сестер». Рич умел решать нерешаемые задачи. Например, он обеспечивал Израиль нефтью из Ирана. Осужденный Рудольфом Джулиани (будущим мером Нью-Йорка) и помилованный Биллом Клинтоном в последний день своего президентства, Марк Рич — отличный пример того, каких результатов можно достичь, если понимать свои сильные стороны и уметь видеть скрытые возможности.

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

Антонио Менегетти «Психология лидера»

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

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

Robert M. Pirsig «Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values»

В русском переводе — Роберт Пирсиг «Дзэн и искусство ухода за мотоциклом»

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

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

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

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

Amanda Gefter «Trespassing on Einstein’s Lawn: A Father, a Daughter, the Meaning of Nothing, and the Beginning of Everything»

В русском переводе — Аманда Гефтер «На лужайке Эйнштейна. Что такое ничто, и где начинается все»

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

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

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

Douglas R. Hofstadter «Gödel, Escher, Bach: An Eternal Golden Braid»

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

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

Представляємо традиційнийфотоогляд святкування Нового року в українських ІТ-компаніях.

Якщо ви хочете додати свої фото в статтю, пишіть на alyona@dou.ua.

Academy SMART

Тема новорічного корпоративу компанії Academy SMART — гра «The Cube». Кожний учасник перевірив свої сили та виконав різноманітні завдання всередині куба.

Acceptic

Напередодні Нового року співробітники київського та харківського офісів Acceptic як слід відпочили на справжній Hype Party.

ADS group

Компанія ADS group відсвяткувала новорічну вечірку 2019 в стилі «Insta Yellow Party». Основною родзинкою вечора став жовтий корпоративний колір компанії, в дрес-коді кожного було щось жовте, а офіс перевтілився в новорічний танцпол з яскравою жовтою фотозоною.

AgileEngine

В AgileEngine святкували новорічний корпоратив за різними тематиками. У Києві влаштували справжні пригоди по мотивам Друзів Оушена з квестом та підпільним казино, у Харкові головною темою була Agile Engine Home — були ігри, танці та атмосфера святкування у великій дружній сім’ї, в Одесі вечір присвятили геймінгу та гік тусовці.

Agiliway

Новорічна вечірка ІТ компанії Agiliway — це про те, як цілу ніч танцювати у кольоровому одязі під рок-н-рол, перетворитись на справжнього «стилягу» та побувати у 50-хроках.

AltexSoft

2019 рік Altexsoft зустрічали в повному складі з колегами з харківського, кременчуцького та львівського офісів під музичний супровід гурту «Друга Ріка».

AMC Bridge

Ascendix Technologies

Компанія Ascendix Technologies провела новорічний корпоратив у стилі феєричного мюзикл-шоу, де кожен зміг продемонструвати свій талант і відчути себе справжньою зіркою

Astound Commerce

Astound Commerce двіжували під запальний хіп-хоп ТНМК на новорічній вечірці Urban NY’19 Dvizh.

B2B Soft

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

Beetroot

На Новий рік у Києві, Полтаві, Одесі, Харкові та Івано-Франківську відбулися незабутні вечірки зі секретними квестами, олів’є, Дідом Морозом та Снігуронькою, а ще було багато подарунків.

Binary Studio

В Binary Studio святковий сезон традиційно розпочався з корпоративної тижневої подорожі до Європи. Цього року команда з львівського та київського офісів куштувала Різдво в імперському Відні, технічнологічному Штутгарті, смачному Страсбурзі та контрастному Франкфурті.

Bizico

Компанія Bizico провела корпоратив у стилі «Starry night». Почали святкування з гірки шаманського та вечері в супроводі cover band. В перервах між танцями робили фото в Instabox та відпочивали в окремій лаунж-зоні з фуршетом та кальянами.

Blackthorn Vision

Компанія Blackthorn Vision цього року влаштувала затишне новорічне святкування у Ресторані «Шпацер». Ведучий розважав колег конкурсами, а родзинкою святкування стали виступ кавер-гурту «Sab Rosa» та паперове шоу.

Brander

Компанія Brander зустріла Новий рік в затишній домашній обстановці офісу в стилі Pyjama Party.

Brightgrove

Шалені брайтівці влаштували вечірку за мотивами традиційного різдвяного фільму «Home Alone». Багато танцювали, бешкетували та насолоджувались атмосферою фільму, знайомого з дитинства.

Clickky

CodeIT

Codemotion

Відчути літню спеку в зимовий період, так ще й у Києві? Команда Codemotion вміє, знає та практикує :)

CS Ltd

DataArt

Українські офіси DataArt святкували Новий рік під єдиним слоганом «Light up 2019!»: концепція свят була присвячена світлу та сяйву, але в кожному місті була своя особливість. У Києві пройшла вечірка з флешбеком у 90-тіз танцювальними батлами і флешмобом під найвідоміші кліпи 90-х,виступом кавер-бенду, караоке та дискотекою із замовленням пісень. У Харкові свято відбулося в історичному місці, у Львові до дрес-коду додали маски, в Одесі обрали тематику рок-паті і відкрили вечір, вибиваючи ритм «We Will Rock You» (Queen). У Дніпрі вечір присвятили легендарному фільму «Один вдома», а в Херсоні пройшло справжнє Shine party!

Daxx BV

В Києві провели Cruise party, в Дніпрі вечірку в Голлівудському стилі, в Харкові тема була «Як тобі таке, Ілон Маск». Нагороджували найкращих співробітників, дарували подарунки, танцювали та розважалися

Digitally Inspired

Edvantis

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

EIS Group

В EIS Group зробили новорічний корпоратив без тематики: сказали «ні» дрес-коду, правилам і тематичним розвагам. Сказали «так» вільному спілкуванню, подарункам від Таємного Санти та запальним танцям!

ELEKS

ELEKS Rockstar Party — це світ рок-музики, світ шаленства, AC/DC та Queen, у який поринули елексівці з усіх регіонів.

ElifTech

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

Ergonized

Компанія «Ergonized’ відсвяткувала новорічний корпоратив в стилі «Great Gatsby». Розвагою вечора були конкурси з нагородами, вручення відзнак кращим працівникам компанії та запальні танці!

Evolvice

Exadel

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

FiduciaSoft

Команда FiduciaSoft відсвяткувала новорічний корпоратив у сонячному Шарм Ель Шейху. Святкування супроводжувалося катанням на квадроциклах, дайвінгом, а також сонцем, морем та пляжем у необмеженій кількості.

Forma-Pro

G5 Entertainment

Команди харківського та львівського офісів компанії G5 Games провели корпоратив в форматі Winter Magic Forest Party. На вечірці гостей розважали справжнi фавни та кентавр, в програмі був конкурс святкових костюмів, виступ кавер-гурту та безлiч тематичних активностей. Співробітникам, які працюють в компанії понад 10 років, вручили пам’ятні нагороди.

Govitall

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

HYS Enterprise

Компанія HYS Enterprise влаштувала тематичну вечірку в стилі «Christmas Movie Premiere Closed Show» на честь десятиліття компанії. Підвели підсумки року, провели церемонію нагородження. Крім пригощань і програми, вечір наповнили шоу танцюючих офіціантів, яскрава фотозона і відео звіти про життя компанії.

Infopulse

Цього року Infopulse почав робити заходи такими, що мають соціальну складову. Тому хайлайтом вечора «Light up you heart» стало оголошення результатів благодійних ініціатив, які провели напередодні свята. Охочі могли позмагатися за унікальні брендовані лоти в аукціоні або ж зробити грошовий внесок. Більшість спеціалістів компанії допомогли благодійному фонду «Ufond», одна з головних місій якого — «Дозволити дитячим серцям битися».

Intego Group

Intellias

InterLink

В InterLink підсумки 2018 року підбили на церемонії нагородження за номінаціями та спробували себе у створенні власного кінофільму.

Itera

Itera Ukraine поринула у святкову атмосферу різдвяної ярмарки в стилі Хюге. Грали в сніжки, пили глінвейн, отримували подарунки від Санта Клауса.

Lanars

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

Leobit

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

Livatek

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

LoopMe

LoopMe зустрічали Новий Рік у стилі InstaParty. Кожен отримав після вечірки велику кількість друкованих фото. Всі мали можливість сфотографуватись з символом 2019 року, а також повірити у дива завдяки виступу фокусника.

MobiDev

Всi офiси MobiDev традицiйно зустрiлись у Харковi, щоб вiдсвяткувати прийдешнiй Новий рiк та день народження компанiї.

Netcracker

Новорічний корпоратив сумського офісу Netcracker «Secret Agent: 007»

Netrocket

Nexteum

На новорічному корпоративі Nexteum співробітники компанії перевтілилися у своїх кумирів — кіноакторів, селебрітіз, історичних персонажів. Тож на Idol Party власною персоною завітали Че Гевара, Жінка-кішка, Кончіта Вурст, Монатік, Джонатан Девіс, Мілагрос та інші відомі герої. Окрім гламуру, була й офіційна частина. Номерними знаками Nexteum компанія нагородила найрезультативніших співробітників року, після чого працівники розважали один одного читанням репу та музичними виступами.

Panther Gaming

Perfectial

Новорічну вечірку Perfectial відсвяткували у стилі Past & Future, адже Новий Рік — це містичний момент, коли майбутнє зустрічається з минулим. На вечірці було багато яскравих образів. Працівники мали можливість обрати серед стилів 70, 80, 90-хроків або ж футуристично-постапокаліптичну тематику.

Playtika

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

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

Дніпровська Playtika відсвяткувала у стилі Las Vegas Casino Party. Мафіозний настрій та справжнє казино: Блек-Джек, покер, рулетка та інші інтерактиви, де учасники могли заробляти ігрову валюту Playdollars.

Новорічна cosplay-вечірка київського офісу пройшла під гаслом Play your own comics. Неповторні костюми та образи, створені здебільшого власноруч, а також безліч розваг, конкурсів і запальна музика надали святу особливу атмосферу.

PLVision

Напередодні Нового року команда PLVision зібралася на Rock-IT Science Party: підбили підсумки року, нагородили найкращих експертів, які у 2018-муздійснили rocket science досягнення, занурилися в магічну атмосферу вишуканої локації — Львівського будинку вчених — і запалили танцпол драйвовими роковими акордами.

Provectus

Новорiчний корпоратив Provectus був за блокбастером Тарантино — From Dusk till Dawn Party! Мексика, мафiя й вампiри? Так. А ще страшенно крутий рок-концерт, танцi до ранку й фотозона для справжнiх байкерiв.

Qubit Labs

Коли фраза «Oh, You are so ugly today» звучить як найкращий комплімент :)

Qubstudio

Qubstudio Top UX/UI design studio на новорічному корпоративі під коктейлі та танці відзначила працівників у найбожевільніших номінаціях.

Rails Reactor

У Rails Reactor провели Feel fRRee рaRRty. Невимушена атмосфера та варіативність для самопрояву — таку атмосферу мала вечірка, а DJ, slow-motion зона та PJ допомагали створювати атмосферу та особливий настрій вечора.

Riseapps

RubyGarage

RubyGarage зустріли Новий Рік в стилі Casino.

Sigma Software

Sigma Software святкувала Новий рік у Disco Universe Cruise разом з героями П’ятого елементу, представниками інопланетних рас, вченими та танцівниками диско.

Sirin Software

Команда Sirin Software відсвяткувала новорічний корпоратив у лофт-локації, головним подарунком був виступ музичного гурту, заснованого співробітниками компанії.

Вечір супроводжувався церемонією нагородження Sirin Software Awards та чемпіонатом з радіокар рейсингу, і, звісно, кожен отримав подарунки від компанії та свого таємного Санти.

Skelia

Цього року Skelia відсвяткувала новорічну вечірку у стилі рок-н-рол. Запальні танці у стилі 50-х,гітари та конкурси.

SMART business

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

SoftBistro

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

Softengi

Всі поринули в яскраву атмосферу Hollywood і взяли участь у нагородженні знаменитої премії «Оскар».

SoftServe

Sombra

Вечірка з нагоди п’ятиріччя компанії у стилі 50-хроків. Також відбулась церемонія нагородження кращих працівників року у різних номінаціях.

SSA Group

2018 рік компанія SSA Group проводжала вечіркою в англійському стилі. Леді та джентльмени мали можливість поспілкуватися з Її Величністю Королевою Великобританії у справжнiй English Telephone Booth, відчути себе Шерлоком Голмсом, розкривши таємничі злочини у тематичнiй вікторині, та в цiлому весело провести час під запальні хіти The Beatles, Deep Purple, Queen, Pink Floуd та інших відомих британських бендів.

Synebo

Компанія Сінебо влаштувала вечірку в стилі Гетсбі. Провели численні конкурси та були роздані подарункові сертифікати.

Terrasoft

Напередодні корпоративу в Terrasoft запустили марафон соціальних проектів «Accelerate Good Deeds». Окрім традиційної шоу-програми, на новорічній вечірці відбулося нагородження переможців: за результатами голосування лідерами стали одразу дві команди, кожна з яких отримала по $5000 на реалізацію своєї ідеї у 2019 році.

V.I.Tech

Львівський та Івано-Франківський офіси V.I.Tech відсвяткували 11 років компанії та зарядились святковим настроєм на новорічні і різдвяні свята.

Vakoms

Новорічна вечірка Vakoms пройшла у стилі Disco Party: музика, під яку неможливо не танцювати, світлові шоу, яскраві декорації та чудовий настрій.

Waverley Software

Waverley Software святкувала в засніжених Карпатах у стилі «Ugly Sweater Party». Команди з Харкова, Львова, Києва та Одеси вже традиційно катались на лижах та санках, ліпили сніговиків та отримували призи за найкреативніші светрики.

Weblium

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

WorkNest Technologies

Цього року компанія WorkNest Technologies зустріла Новий рік з конкурсами, танцями, піснями та дитячими фотографіями. Таємничу атмосферу вечірки доповнили подарунки від таємного Санти.

YouScan

YouScan провела АНТИ-корпоратив без ялинки і гламуру, натомість ми вступили до Бійцівського Клубу: билися, повзали, підривали...

YouTeam

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

С Новым годом и Рождеством, друзья!

Этот праздничный дайджест хочу начать с краткого обзора наиболее важных событий и релизов в мире Ruby/Rails.

Конечно, в дайджесте вы найдете и свежие материалы за декабрь. Несмотря на рождественские и новогодние праздники, сообщество Ruby выкатило множество релизов, в том числе стабильную версию Ruby 2.6 с JIT-компилятором и Ruby on Rails 5.2.2. В 2019 году выйдет Ruby on Rails 6 — обязательно посмотрите график его релиза. Также не пропустите подборку материалов о поддержке Ruby на сервисе AWS Lambda.

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

А теперь давайте смотреть, чем же запомнился ушедший год?

Топ 2018

В начале годы вышла первая preview-версия Ruby 2.6, а в конце декабря состоялся релиз стабильной версии Ruby 2.6 с JIT-компилятором.

Ruby 2.2больше не поддерживается разработчиками.

В апреле команда разработчиков Ruby on Rails представила версию 5.2самого популярного фреймворка на Ruby.

Вышла версия v1.2.0 Ruby-фреймворка Hanami.

Состоялся релиз версий 2.0.2 и 2.0.3фреймворка Sinatra.

Проект Paperclip больше не поддерживаетсяразработчиками компании thoughtbot.

DHH представилфреймворк Action Text для Ruby on Rails 6.

Популярный тест-фреймворк RSpec был обновлендо версии 3.8.

Команда разработчиков GitHub обновилаприложение до Rails 5.2.1.

JRuby — популярный интерпретатор языка Ruby — теперь совместимс Ruby 2.5.

Почитать

Timeline for the release of Rails 6.0 — график релиза фреймворка Ruby on Rails 6.

Introducing Action Mailbox for Rails 6 — что такое фреймворк Action Mailbox, который войдет в Ruby on Rails 6.

Ruby 2.6 JIT — Progress and Future — о настоящем и будущем JIT-компилятора в Ruby 2.6.

Ruby Memoization and Alternatives — когда использовать мемоизацию в Ruby и какие альтернативы существуют.

Announcing Ruby build support for AWS SAM CLI — в инструмент AWS SAM CLI официально добавлена поддержка Ruby.

Using Scenic and SQL views to aggregate data — как использовать гем Scenic для работы с SQL views.

Check and Update a URL with Ruby — простой способ актуализировать старые URL с помощью Ruby.

Big on Heroku: Scaling Fountain without losing a drop — советы от Evil Martians по масштабированию приложения на Heroku.

Meet Stealth 1.1 — что нового в версии Stealth 1.1 — фреймворка для создания чатботов .

Recursion, Tail Call Optimization and Recursion — как оптимизировать хвостовую рекурсию в Ruby.

How to Reduce Memory Usage by Tuning Gemfile — как настроить Gemfile, чтобы снизить использование памяти в приложении на Rails.

Juggling Chainsaws at Machu Picchu: Metaprogramming in Ruby — автор показывает, как использовать метапрограммирование в Ruby.

Polymorphic Routes — освежаем в памяти, что такое polymorphic routing в Ruby on Rails.

Displaying, downloading and streaming files with Active Storage — полезная шпаргалка по использованию Active Storage в Rails.

Boosting the Development Environment with Vagrant and Ansible — как оптимизировать среду разработки с помощью Vagrant и Ansible.

A Weird and Wonderful Trip through Ruby’s Standard Library — обзор малоизвестных возможностей стандартной библиотеки Ruby.

Keeping your schema close to you with the ’annotate’ gem — как легко получить информацию о схеме базы данных при помощи гема Annotate.

Inheritance and Define_method — How to Make Them Work Together — как использовать наследование и метод define_method при помощи метапрограммирования.

Disassembling Rails — Template Rendering (2) — автор показывает, как фреймворк Ruby on Rails обрабатывает шаблоны.

Destroying an Association Marked as Read-Only in Rails — автор описывает интересный случай использования метода destroyed_by_association в Rails.

Benchmark: Deep directory structure vs. flat directory structure to store millions of files on ext4 — какую структуру файлов стоит выбрать — смотрим итоги бенчмарков.

How to cache Ruby gems or NPM dependencies on CircleCI 2.0 — учимся кэшировать гемы и NPM-зависимости при использовании CircleCI.

Подборка материалов об использовании Ruby на платформе бессерверных вычислений AWS Lambda:

• Announcing Ruby Support for AWS Lambda
• Using Ruby on AWS Lambda
• Ruby Sinatra on AWS Lambda
• How to build a serverless Twitter bot with Ruby and AWS Lambda

Подборка от Andy Croll

Write long strings with wiggly HEREDOCs — почему стоит использовать HEREDOC при создании длинных строк.

Always Force Booleans to be True or False — автор объясняет, почему булевые значения должны быть или true, или false.

Подборка от Appfolio Engineering

How Fast is Ruby 2.6.0preview3 for Discourse — разработчики Appfolio Engineering сравнили скорость работы Ruby 2.6.0preview3 в сравнении с Ruby 2.5.

Multiple Gemfiles, Multiple Ruby Versions, One Rails — автор делится опытом, как в Rails-приложении использовать разные версии Ruby и конфигурации гемов.

A Short Update: How Fast is Ruby 2.6.0rc1 — оцениваем скорость работы первой предрелизной версии Ruby 2.6.0.

Подборка от AppSignal

Don’t be mean: Statistical means and percentiles 101 — какие индикаторы производительности приложения выбрать.

Ruby gem 2.8: Container memory & JRuby on Alpine Linux support — что нового в версии 2.8 гема AppSignal.

Подборка от Arkency

Serverless Slack bot on Lambda with Ruby — создаем Slack-бота на Ruby при помощи сервиса бессерверных вычислений AWS Lambda.

Modeling passing time with events — автор делится опытом организации событийно-ориентированной бизнес-логики приложения.

Подборка от BigBinary

Passing current_user by default in Sidekiq — как настроить передачу current_user по умолчанию в Sidekiq.

Optimize loading multiple routes on Google map using B-spline — учимся оптимизировать маршруты доставки продукции при помощи B-сплайнов в приложении, которое использует Google Maps.

Rails 5 Active Record attributes API — разбираемся с Active Record attributes API в Rails 5.

Подборка от BoltOps

Official AWS Ruby Support for Jets Serverless Framework — serverless-фреймворк Jets теперь можно использовать с официальной поддержкой Ruby на сервисе AWS Lambda.

Jets Image Upload Carrierwave Tutorial: Binary Support — в этом туториале автор показывает, как импортировать изображения с помощью serverless-фреймворка Jets и библиотеки CarrierWave.

Jets Afterburner: Serverless Rails on AWS Lambda in 5 Minutes — как развернуть Rails-приложение на AWS Lambda при помощи Jets Afterburner.

Подборка от Jason Swett

How to Run Feature Specs Headlessly or Not Headlessly at Will — как тестировать функции приложения в браузере и вне его.

Testing Private Methods — как тестировать закрытые методы в Ruby.

Подборка от Mehdi Farsi

SOLID & Ruby in 5 short examples — принципы SOLID в Ruby на простых примерах.

Modules in Ruby: Part II — освежаем в памяти, что такое анонимные модули в Ruby.

Подборка от Ross Kaffenberger

Everything is Enumerated — как использовать to_enum с block methods в Ruby.

Why RSpec users should care about Rails system tests — почему стоит проводить системные тесты при работе с RSpec.

Подборка от RubyGuides

How to Use State Machines in Ruby — как использовать state machines в Ruby.

How to Run System Commands From Ruby — несколько способов команду из Ruby в терминале.

How to Use The VCR Gem to Improve Your Testing Suite — оптимизируем тестирование Rails-приложений при помощи гемов WebMock и VCR.

What is A REPL in Ruby?— освежаем в памяти, что такое REPL в Ruby.

How to Build Command-Line Applications with Ruby — учимся создавать приложения командной строки в Ruby.

MiniMagick Gem: How to Transform Images Using Ruby — как изменять изображения при помощи гема MiniMagick в приложениях на Ruby.

Подборка от RubyPlus

Kafka Producer and Consumer in Ruby using Docker — краткий туториал, как создать producer and consumer программу на Docker.

Ruby Kafka Messaging App using Docker — как подключить приложение на Ruby к Kafka при помощи Docker.

Getting Kafka Up and Running with Vagrant — пошаговый туториал, как создать приложение для обмена сообщениями на Ruby с помощью Kafka и Vagrant.

Подборка от Sam Phippen

Rack middlewares that have saved me literally hours of my life — авто на основе собственного опыта показывает преимущества использования промежуточного ПО Rack.

How I organise my VIM hotkeys — автор делится советами по работе с текстовым редактором VIM.

Туториалы

Building an API with Ruby and the Serverless Framework — создаем Ruby API при помощи Serverless Framework.

Deploying a Rails 5.2 PostgreSQL app on AWS Elastic Beanstalk — как развернуть приложение на Rails 5.2 и PostgreSQL на сервисе AWS Elastic Beanstalk.

Customizing Rails rake tasks — учимся настраивать Rake-задачи в приложении на Rails.

How to Use Ruby on Rails for Local SMTP Email Testing — в этом туториале автор показывает, как настроить SMTP-сервер в приложении на Rails.

How business transactions helped decouple Rails controllers at TextMaster — как сделать рефакторинг контроллеров в приложении на Rails.

How to Set Up Redirects in a Ruby Rack Application — как настроить переадресацию в Rails Rack приложении.

101: Law of Demeter — как устранить нарушение «закона Деметры» (Law of Demeter) на примере Ruby-приложения на фреймворке Sinatra.

Transparent compression of RabbitMQ messages with Sneakers — краткая инструкция, как ускорить работу RabbitMQ при помощи сжатия сообщений.

Релизы

Ruby 2.6.0 — релиз стабильной версии Ruby 2.6.0.

Rails 5.2.2 — вышла стабильная версия фреймворка Rails 5.2.2.

JRuby 9.2.5.0 — релиз версии 9.2.5.0 интерпретатора языка Ruby.

mRuby 2.0.0 — появилась версия mRuby 2.0.0 — реализации языка Ruby для встраиваемых систем.

RubyMine 2018.3.1 — популярная IDE RubyMine обновилась до версии 2018.3.1 (сборка 183.4588.71).

Passenger 6 — вышла стабильная версия 6.0 сервера приложений Passenger.

RubyGems 3.0.0 — релиз версии 3.0.0 менеджера пакетов RubyGems.

Послушать

The Bike Shed

181: Strong Types and a Functional Flair — ведущие и Joe Ferris — CTO компании thoughtbot — обсуждают интересных тем, в том числе сервис Apache Kafka и платформа RabbitMQ.

Ruby Rogues

• RR 391: Frontend Testing Like a Rubyist with Josh Justice — как гость подкаста применяет навыки тестирования в Ruby во frontend-разработке.
• RR 392: Crystal and Lucky with Paul Smith & Andrew Mason — участники дискуссии обсуждают созданный под влиянием Ruby язык программирования Crystal и его фреймворк Lucky.
• RR 393: Speculation on Frameworks with the Panelists — подкаст посвящен фреймворкам, которые используются в backend- и frontend-разработке.
• RR 394: Cables, Concurrency, and Ruby 3×3 with Vladimir Dem — в рождественском выпуске Ruby Rogues ведущие и гость подкаста обсуждают cables, concurrency, а также Ruby 3×3.

RWpod

• 48 выпуск 06 сезона. Announcing Ruby Support for AWS Lambda, TypeScript 3.2, Sneaker Generator, Progress-estimator и прочее
• 49 выпуск 06 сезона. Ruby 2.6.0-rc1, Truffleruby 1.0 RC10, Microsoft is building its own Chrome browser to replace Edge, Sharp, ForgJs и прочее
• 50 выпуск 06 сезона. Ruby 2.6.0-rc2, Mruby 2.0.0, Action Mailbox for Rails 6, GraphQL code generator, Matchit и прочее
• 51 выпуск 06 сезона. RubyGems 3.0.0, Ruby 2.6 JIT, Electron 4.0.0, React v16.7, Neural Network Knows When Cat Wants To Go Outside и прочее

Ruby on Rails Podcast

• 252: Confident Ruby on Rails Testing with Jason Swett — подкаст посвящен тестированию legacy-приложений на Rails.
• 253: Jets: Ruby Serverless Framework with Tung Nguyen — гость подкаста — Tung Nguyen — создатель serverless-фреймворка Jets для Ruby.
• 254: Ruby Support for AWS Lambda with Alex Wood — участники дискуссии обсуждают поддержку Ruby на сервисе AWS Lambda.

The Ruby Testing Podcast

020 — Josh Clayton of thoughtbot — гость подкаста — Josh Clayton из компании thoughtbot — делится опытом тестирования приложений, а также рассказывает о паттернах генерации данных для тестирования Rails приложений.

Remote Ruby

Accounting (?), Ruby 2.6rc1, Rails 5.2.2, AWS Lambda + Ruby, Stimulus Component Library — обзор последних новостей в мире Ruby от постоянных ведущих Remote Ruby Криса и Джейсона.

The Yak Shave

It’s not a Pyramid, it’s a Diamond — в этом выпуске Sam Phippen делится своей методикой тестирования приложений.

Посмотреть

RubyConf 2018 — подборка докладов и обсуждений с прошедшей в ноябре конференции RubyConf 2018.

Декабрьские выпуски GoRails, в которых ведущий продолжает серию о реализации встраиваемых JavaScript-виджетов в приложениях на Rails:

• Using Vuex with Forms in Rails
• Cross-origin Resource Sharing (CORS) with Rails
• Restricting Javascript Widgets to Registered Sites

Подборка платных скринкастов от Drifting Ruby в декабре:

• #162 Creating a Simple Slack Bot
• #163 Templating Ruby on Rails Applications
• #164 Policy Manager with GDPR Rails
• #165 Incoming Emails with Action Mailbox

Декабрьские выпуски платных скринкастов от Ruby Tapas:

• Getting started with rom-rb
• Writing changes with rom-rb
• Building queries with rom-rb

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

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

В выпуске: чего ждать в 2019, безопасность internal сервисов, Cortex в CNCF, 82% компаний уже немного с DevOps, почему Kubernetes крут, и он вам нужен.

Google Trends для DevOps: коррекции не будет

Predictions

8 DevOps Trends to Be Aware of in 2019 — будет расти! Надо брать. Аналитика о DevOps трендах на 2019 год.

5 Lessons Learned From Writing Over 300,000 Lines of Infrastructure Code — Gruntwork о правильной Infrastructure as Code. Прошлись по всем фронтам!

Dev vs. Ops: The State of Accountability (PDF) — 82% компаний уже немного с DevOps — и еще много разной аналитики.

Solutions

Безопасность internal сервисов — отличная статья о AWS Congito + Google + SAML и почему VPN недостаточно.

I gots to get organized - что делать, если много AWS аккаунтов, и как лучше ими управлять.

Envoy Proxy at Reddit — как Reddit мигрировал на Envoy, почему они это сделали и что получилось в результате.

Time Series at ShiftLeft — как ShiftLeft колесо строили: TimescaleDB + Prometheus + Grafana.

Everything you should know about certificates and PKI but are too afraid to ask — все, что нужно знать, перед тем как внедрять PKI

How Battlehouse saved $60,000 a year on AWS — что нужно делать, чтобы секономить в AWS.

Cortex: a multi-tenant, horizontally scalable Prometheus-as-a-Service — Cortex — крутая штука, если вам нужен Prometheus на стероидах.

Kubernetes-related

Deploy applications described in Compose onto Kubernetes clusters — теперь манифесты docker-compose можно применять прямо в Kubernetes.

Why Kubernetes Is Awesome: A Beginner’s Guide — никогда такого не было, и вот опять. Почему Kubernetes крут, и он вам нужен.

Cloud Native Development (CND) — CND поможет построить процессы разработки, за которые не будет стыдно.

How Tilt updates Kubernetes in Seconds, not Minutes — они делают docker build && kubectl apply за 5 секунд. Неплохо.

OYO Tech Staging: From Elastic Beanstalk to Kubernetes — уехали с Elastic Beanstalk в Kubernetes и решили много проблем.

Making running production-grade databases easy on Kubernetes — один из самых простых способов запустить БД в Kubernetes.

11 Ways (Not) to Get Hacked — как правильно защитить свой Kubernetes кластер.

Tools

Loki. Prometheus-inspired logging for cloud natives — как Prometheus, но для логов. Как Elasticsearch, но без полнотекстового поиска.

Goldpinger — Debugging tool for Kubernetes which tests and displays connectivity between nodes in the cluster — понятный анализ сети в Kubernetes c UI.

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

Привіт, мої любі сішники! Вітаю вас з Новим роком! Бажаю вам чистого коду, цікавезних задач, від яких перехоплює подих, та стабільного ТЗ! Пропоную в цьому дайджесті підвести підсумки року та, як завжди, розглянути декілька статей про modern С++ та улюблені інструменти для розробки. Починаємо? :)

Підсумки року в світі С++

C++ at the End of 2018 — скарбничка, в якій описано все життя С++ в 2018. У статті перераховано усі зустрічі комітету по стандартизації з посиланнями на репорти, найвизначніші конференції, розглянуто підтримку стандартів компіляторами, перелічено інструменти, які необхідні для розробки або значно спрощують життя, та їх поточний статус. Містить хорошу підбірку літератури. Розглянуто питання складності С++. Стаття обов’язкова для читання: таке не можна пропустити :)

Посиланняна трендові open source проекти на GitHub 2018 року.

Getting You There — Your C++ Standardization Efforts in 2019 — автор пише про свій досвід участі в стандартизаціЇ С++.

Call For Submissions — конференція C++Now чекає заявок на презентацію.

Інструменти

Однією з найвизначніших подій грудня можно сміливо назвати реліз Visual Studio 2019: Visual Studio Live Share, покращення швидкодії, Git stash, покращений Look & Feel та багато іншого.

Деталі можно почитати в статтях:
Making every developer more productive with Visual Studio 2019.
Honest Review of Visual Studio 2019 Preview 1.

Exploring Clang Tooling — Using Build Tools with clang-tidy — продовження циклу статей про Сlang-Tidy. В цій частині йдеться про рефакторинг при роботі з групою файлів, взаємодію з Ninja та CMake.

bake — новенький менеджер пакетів.

QtCreator CMake for Android plugin — плагін від KDAB, що дозволяє безболісно створювати андроїд застосунки в зв’язці Qt, CMake та QtCreator.

Modern C++

A brief introduction to Concepts — Part 1, a brief introduction to Concepts — Part 2 — автор надає гарні аргументи для розуміння про concepts та як їх використовувати на прикладах.

Stop with the CTAD FUD!— про сюрпризи при виведенні аргументів шаблону класу.

How to Use The Newest C++ String Conversion Routines — std::from_chars — навіщо потрібен std::from_chars, якими компіляторами підтримується, приклади використання.

Overview of std::map’s Insertion / Emplacement Methods in C++17 — описано різницю між методами вставки елемента до std::map. Гарна інструкція щодо того, коли та який метод зручніше використовувати.

C++ Core Guidelines: Rules for Variadic Templates — чудовий опис того, коли доречно та як саме застосовувати Variadic Templates.

Корисні посилання

OpenCV 4.0.0 new Graph API (G-API)розглядає нову модель роботи з OpenCV, при якій ми створюємо конвейер операцій та застосовуємо його вже до конкретних даних.

Qt: Tableview performance — аналізує проблему швидкодії TableView до Qt-5.12, містить приклад, на якому можна подивитися на покращену швидкодію TableView в Qt-5.12.

Google C++ Style Guide — Code Style від Google (і вони обирають spaces!).

Performance: C++ vs Rust — точка зору про порівняння C++ та Rust, що заснована на логічних аргументах. Автор не підкріплює думки цифрами, але почитати цікаво.

Секреты тернарного оператора — стаття з Хабру про те, де можна використовувати тернарний оператор на відміну від if() та небезпеки, які в ньому ховаються.

Deciphering the postcard sized raytracer — розгляд коду, створеного Andrew Kensler для рейтресингу.

TODO_BEFORE(): A Clean Codebase for 2019 — як з’являється tech debt() та як з цим жити далі.

Оновлення

Цього місяця маємо такі оновлення:

• ReSharper C++ 2018.3
• Qt: Qt 3D Studio 2.2, Qt Creator 4.8.0, Qt 5.11.3 Released, Qt Visual Studio Tools 2.3.0, Qt Installer Framework 3.0.6
• wxWidgets 3.1.2
• PhysX SDK 4.0
• GitLab 11.6, 11.5.5, 11.4.12, 11.3.14
• Boost 1.69.0
• LLVM 7.0.1

Для новачків

7 Best C++ Tutorial, Course & Certification [2018 — 2019]
C++ Quick Reference
C++ Tutorial for Beginners

Хвилиночка флуду

Сподіваюсь, що ялинка вже наряджена. Та якщо ви не встигли до дедлайну — тримайте лайфхак: Новорічна ялинка на github.

Більше варіантів новорічних ялинок на stackexchange :)

А наостанок — новорічний календар:

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

DXC Technology, поставщик ИТ и консалтинговых услуг, покупаеткомпанию Luxoft. Ожидается, что сделка будет закрыта к июню 2019 года и её сумма составит около $2 млрд.

BREAKING NEWS: @DXCTechnology has announced its intention to acquire Luxoft! Together, we will address every business-driven digital initiative, from modernizing legacy IT systems to delivering transformational digital solutions at scale. Learn more: t.co/1KcNLT8Gdbpic.twitter.com/OrDvnBV4BR

— Luxoft (@luxoft) 7 января 2019 г.

DXC Technology выкупить Luxoft за $59 за каждую акцию, что в сумме составит порядка $2 млрд.

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

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

В Luxoft в мире работает около 13 тыс. специалистов, из них почти 4 тыс. в Украине. Компания входит в тройку крупнейших украинских ИТ-компаний.

Напомним, что в феврале 2017 года Luxoft купилааутсорсинговую компанию IntoPro, в которой работало более 500 специалистов.

Здравствуйте, читатели! Меня зовут Алексей, я работаю JavaScript-программистом. Ранеея писал о том, как в свободное от работы время начал изучать Python и поделился ссылкой на созданный мной репозиторий, который может быть полезным начинающим Pythonist-ам. Эта статья является, по сути, продолжением пути в около-Python-овские «дебри» и, надеюсь, станет полезной тем из вас, кто начинает изучать машинное обучение на Python.

Идея проекта

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

Развеивание этой излишней «магичности» я начал с потрясающего курсаот Andrew Ng. В нем довольно понятно и детально объясняются базовые алгоритмы машинного обучения и делается это с использованием MatLab/Octave. Сначала я попытался систематизировать полученные знания для себя же, создав репозиторий machine-learning-octave, в котором добавил поддержку «многослойности» для нейронной сети (многослойного перцептрона) и отрефакторил код, чтобы сделать его более читаемым. Но код все так же был написан на Octavе, а использование MatLab/Octave в 2018-м —это, наверное, был немного «привет» из 2010-го...

Чтобы вернуть себя к реальности заканчивающегося 2018 года я запустил новый репозиторий Homemade Machine Learning, который содержит примеры популярных алгоритмов и подходов машинного обучения, таких как линейная регрессия, логистическая регрессия, метод K-средних и нейронная сеть (многослойный перцептрон). Каждый алгоритм содержит интерактивные демостранички, запускаемые в Jupyter NBViewer или Binder. Таким образом у каждого желающего есть возможность изменить тренировочные данные, параметры обучения и сразу же увидеть результат обучения, визуализации и прогнозирования модели у себя в браузере без установки Jupyter локально.

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

Реализация проекта

За основу я взял свой предыдущий репозиторий, который начал переписывать на Python и расширять новыми демками на основании новых датасетов. Я новичок в Python и машинном обучении, поэтому для меня многие базовые задачи были сложными. Например, где найти подходящие данные (небольшого размера, ведь мне нужна всего лишь демонстрация алгоритма, а не production-ready продукт), как хранить/деплоить Jupyter ноутбуки (NBViwer или MyBinder? Поддержит ли NBViwer мои кастомные плагины в ноутбуке?), какие библиотеки использовать для обработки данных (Pandas? NumPy? Или их комбинацию?), какие библиотеки использовать для построения графиков (ту же Pandas? Или MatPlotLib? А если надо интерактивное 3D? Может PyPlot?) и многое другое...

В итоге основными используемыми библиотеками стали NumPyи Pandas. Эти библиотеки используются для эффективных операций над матрицами, а также для загрузки и парсинга CSV-данных. В демостраничках для построения графиков и визуализации тренировочных данных также используются библиотеки Matplotlibи Plotly. В случае с логистической регрессией для минимизации функции потерь используется библиотека SciPy, но в остальных случаях градиентный спуск реализован на чистом NumPy/Python. Использования библиотек на подобии PyTorchили TensorFlowизбегаю из-за обучающей цели репозитория.

Работа над проектом заняла около одного месяца в свободное от работы время (приблизительно 1-2часа в день). Ниже опишу алгоритмы, которые на данный момент реализованы в репозитории.

Регрессия. Линейная регрессия

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

• ∑ Математическая модель — теория и ссылки для дальнейшего чтения.
• ✎ Пример имплементации на Python.
• ➤ Демонстрация линейной регрессии с одним параметром — прогнозирование «уровня счастья» в стране в зависимости от ВВП.
• ➤ Демонстрация линейной регрессии с несколькими параметрами — прогнозирование «уровня счастья» в стране в зависимости от ВВП и показателя свободы.
• ➤ Демонстрация нелинейной регрессии — пример полиномиального/синусоидального расширения входных параметров для прогнозирования нелинейных зависимостей.

Классификация. Логистическая регрессия

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

• ∑ Математическая модель — теория и ссылки для дальнейшего чтения.
• ✎ Пример имплементации на Python.
• ➤ Демонстрация логистической регрессии с линейными границами — классификация цветов по ширине и длине их лепестков.
• ➤ Демонстрация логистической регрессии с нелинейными границами — классификация микрочипов (исправный/неисправный) по двум параметрам.
• ➤ Демонстрация логистической регрессии с множеством параметров " MNIST — распознавание рукописных цифр по фото в 28×28 пикселей.
• ➤ Демонстрация логистической регрессии с множеством параметров | Fashion MNIST — распознавание типа одежды по фото в 28×28 пикселей.

Кластеризация. Метод K-средних

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

• ∑ Математическая модель — теория и ссылки для дальнейшего чтения.
• ✎ Пример имплементации на Python.
• ➤ Демонстрация метода К-средних — кластеризация цветов на группы в зависимости от длины и ширины их лепестков.

Нейронные сети. Многослойный перцептрон (MLP)

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

• ∑ Математическая модель — теория и ссылки для дальнейшего чтения.
• ✎ Пример имплементации на Python.
• ➤ Демонстрация многослойного перцептрона | MNIST — распознавание рукописных цифр.
• ➤ Демонстрация многослойного перцептрона | Fashion MNIST — распознавание типа одежды по фото в 28×28 пикселей.

Поиск аномалий с помощью распределения Гаусса

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

• ∑ Математическая модель — теория и ссылки для дальнейшего чтения.
• ✎ Пример имплементации на Python.
• ➤ Демонстрация поиска аномалий с использованием распределения Гаусса — нахождение аномалий в поведении сервера.

Дальнейшие планы

По мере изучения machine learning я планирую расширять репозиторий дополнительными примерами реализаций AI алгоритмов и примерами их использования. В планах также возможна адаптация Jupyter ноутбуков под Colaboratoryи покрытие кода тестами.

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

Успешного кодинга!

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

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

В анкете 13 утверждений, которые оцениваются по 7-балльнойшкале Ликерта:

1. Полностью согласен.
2. Согласен.
3. В принципе согласен.
4. Трудно сказать, не могу определиться.
5. Не совсем согласен.
6. Не согласен.
7. Совсем не согласен.

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

Но в любом случае интересно глянуть, что же все-таки не нравится сотрудникам. Для этого мы выделили отдельную вкладку с негативными оценками (от «Не совсем согласен» до «Совсем не согласен»).

Демография

По состоянию на 7 января мы проанализировали 15 794 активных анкет рейтинга.

Из интересного — 37% респондентов из Киева, специалисты в разы чаще добавляют в LinkedIn к должности приставку Senior или Lead, чем Junior и Middle, 42% респондентов — это разработчики, из которых треть — фронтендщики.

Компенсация

Меньше других довольны своей зарплатой QA-специалисты. Количество негативных оценок у них приблизительно в пределах 10% от общего количества голосов тестировщиков. Но они единственные, у кого количество тех, кто «Согласен» превышает тех, кто «Полностью согласен».

Также свыше 5% недовольных зарплатой есть среди проджект-менеджеров, разработчиков, дизайнеров и специалистов поддержки.

Я доволен(-а) материальной компенсацией своего труда в компании

Интересно, если в вопросе о зарплатах процент негативных оценок почти в два раза выше в компаниях «от 1500 специалистов», то количество недовольных соцпакетом приблизительно одинаковое в компаниях «от 1500 специалистов», «800-1500 специалистов»и «21-80 специалистов».

Меня устраивает корпоративный соцпакет

Условия труда

Несмотря на то, что 57% ИТ-специалистов работают в опенспейсах, их, похоже, это практически не расстраивает. Количество недовольных офисом также держится в пределах 10%.

Мне нравится офис компании

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

У меня есть все необходимое на рабочем месте

Часто в комментариях о графике работы читатели пишут, что +/- 2 часа нельзя назвать гибким графиком. Но, судя по оценкам, большинство специалистов довольны тем, что им предоставляет компания.

У меня удобный и гибкий график работы

Карьера

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

Я регулярно получаю обратную связь о своей работе

Компания предоставляет мне возможности для профессионального развития

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

Проект

Меньше других довольны своим проектом .NET, Java, C/C++ и Android разработчики — у них процент тех, кто «Полностью согласен», ниже, чем остальные оценки. Но в целом специалисты работают в интересных им проектах с адекватным менеджментом и имеют возможность применять современные инструменты и технологии.

Мне интересен проект, на котором я работаю

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

Я доволен(-а) рабочей атмосферой, которая царит на проекте

На проекте, где я работаю, профессиональный менеджмент

Лояльность

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

Я готов(-а) рекомендовать компанию, в которой сейчас работаю, своим друзьям и знакомым

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

Визуализация данных: Игорь Яновский

Станом на 16 грудня 2018 в рубриці iOS/macOSна DOU було розміщено 34 вакансії Senior Developer. Це майже виключно iOS: 32 вакансії. 2 вакансії macOS-розробників. Та жодної, де хоча б в тексті згадано tvOS або watchOS.

Усі 34 вакансії я проаналізував вручну, щоб дізнатись, які навички очікували роботодавці від сеньора в 2018 році. 2017-гоя вже готувавтаку аналітику, але цього року я зробив її більш детальною.

Розділяти iOS та macOS я не став, тому що в умовах, коли частка macOS на ринку дуже маленька, вакансії на macOS часто закривають айосниками.

Рейтинг навичок розділений на 2 частини: «Must have» та «Would be a plus». Скажу наперед, що загалом, на мою думку, вимоги виглядають адекватно. Лише 2 компанії вказали Xcode. Тому, думаю, варто звернути увагу на те, які знання очікуються.

Must have

Swift — 68%вакансій. Минулого року було 76%. Частка Swift є стабільною.

Objective-C — 59% вакансій. Великі зміни відбуваються саме з Objective-C. В 2014-2017роках знання Objective-C передбачалося за замовчуванням. Дивно писати у вакансіях Senior C++ Developer, що потрібно знати C++. У вакансіях Senior .NET Developer не обов’язково вказувати C#. Ніхто ж не пише в вакансіях, що потрібно ходити на роботу в одязі. Це і так зрозуміло. Але в 2018 році, коли люди, що починали зі Swift, перетнули поріг у 4 роки досвіду, вже може існувати Senior iOS Developer без знання Objective-C. Інформація про те, чи потрібно кандидату знати Objective-C, стала важливою.

Client-Server Networking — 56%вакансій. Минулого року було 45%. Більшість iOS-аплікацій є клієнт-серверними, але не всі. Особисто я більше року працював на великому проекті на 7 iOS-розробників, де сервера не було в принципі. Таке буває. Якщо ви виросли на такому проекті, а на іншу роботу не беруть без знань комунікації з сервером, пройдіть курс«Networking and Security in iOS Applications», і все стане на свої місця. Найпопулярнішою технологією комунікації з сервером є REST, він вказаний у 32% вакансій. SOAP — тільки в одній вакансії. GraphQL не вказав ніхто, хоча розмови про його переваги чутно досить часто. Конкретні бібліотеки значення не мають. Alamofire та AFNetworking згадувались по 2 рази. В 1 вакансії як must have вказано OHHTTPStubs.

Англійська мова — 44%вакансій. Часто у вакансіях не вказують конкретний рівень англійської, а просто пишуть, що він має бути достатнім для комунікації. Для того, щоб зрозуміти, яку роль відіграє рівень, я звернувся до сирих данихостаннього зарплатного опитування DOU на GitHub. Зробив вибірку Senior Software Engineer, що програмують на Swift та Objective-C, та розбив на 4 групи залежно від рівня англійської. Pre-Intermediate — 3 анкети, середня компенсація 3.067 долара після податків. Intermediate — 11 анкет, 3.173 долара.

Upper-Intermediate — 25 анкет, 3.502 долара. Advanced — 10 анкет, 4.035 долара. Можна зробити висновок, що прохідним рівнем є Intermediate. А небажання вчитись та підтягнути свій рівень до Advanced коштує (4.035 — 3.173) x 12 = 10.344 долара на рік.

Git — 41%вакансій. Єдина компанія, яка вказує SVN — Genesis. Але Git їм теж підійде.

Object-Oriented Programming — 35%вакансій. Чесно кажучи, мені це здається дивним. ООП було безумовною парадигмою в Objective-C. Але в Swift Apple просуває Protocol-Oriented Programming. Останній згадано лише в 1 вакансії. В традиційному розумінні ООП базується на класах. Але в Swift класи є лише одним з кількох типів моделей. Більшість компонентів стандартної бібліотеки Swift реалізовані як структури, а не класи. Можливість крос-типових операцій забезпечують саме протоколи.

Multithreading — 26%вакансій. Минулого року було 27%. Конкретний інструмент не настільки важливий. GCD згадується в 15% вакансій, Operation (NSOperationQueue) — 6%. Враховуючи, що в перспективі в Swift можез’явитись first-class concurrency support (вбудована багатопоточність), як в Go, ключову роль відіграє знання принципів паралельних та розподілених обчислень, а не конкретної технології.

Unit Tests — 26% вакансій. Минулого року було 30%. На цей пункт слід звернути особливу увагу, тому що дуже багато проектів в принципі не мають юніт-тестів. Відповідно, ситуація, коли розробник не має досвіду з юніт-тестами, не є екзотикою. Не обов’язково це має бути TDD. Тільки 9% вакансій згадують саме TDD. Хоча добре знати TDD — ідеальний варіант. В деяких компаніях юніт-тести пишуть, як правило, джуніори. Але концепція TDD передбачає, що сеньор пише тести, що задають вимоги, а мідли та джуніори пишуть код, що відповідає цим вимогам. Особисто я треную навички TDD на сайті HackerRank. Там ти спочатку вчишся писати код, який проходить тести, а потім можеш додавати на сайт власні тести.

Continuous Integration — 24%вакансій. На великих проектах, як правило, є DevOps. Але більшість проектів в iOS маленькі, і Senior iOS Dev виконує там роль майстра на всі руки. Важливо знати саме принципи CI, а от знання конкретної технології тут теж є другорядним. Jenkins згадується лише в 9% вакансій, хоча Xcode Server немає в жодній.

M-V-VM — 18% вакансій. MVC згадується лише в 15% вакансій. Це можна пояснити тим, що розмежування на дані та інтерфейс вже є усталеним: всі так працюють. А от той факт, що дані можуть по-різному виглядати в базі та на екрані, є як мінімум цікавим. Але іноді використання M-V-VM є просто даниною моді. Сам автор M-V-VM John Gossman ще 2006 року писав: «For simple UI, M-V-VM can be overkill».

Core Data — 15% вакансій. Минулого року було 36%. Не думаю, що Core Data стали використовувати менше. Я припускаю, що на тексти вакансій могли вплинути коментарі під iOS-дайджестомна DOU: «Core Data на больших проектах беспомощна», «Нормальные пацаны уже юзают Realm». Для тих, хто вирішив стати «нормальним пацаном», Ray Wenderlich випустив книгупро Realm. Але лише 2 вакансії його згадують. А SQLite взагалі немає в жодній.

Auto Layout — 15% вакансій. Після переходу на iOS 7 2013 року Auto Layout був топовою темою на співбесідах. Не всі мали з ним досвід, і інтерв’юер мав шанс блиснути знанням «вищої математики» констрейнтів. Зараз всі зрозуміли, що то не так складно в порівнянні, наприклад, з багатопоточністю.

Цікаво, що кожна компанія використовує у своїх вакансіях власний спосіб написання назви Auto Layout. Наприклад, в компанію Rozetka потрібен спеціаліст зі знанням «Autolayaut».

Memory Management — 12%вакансій. 6 років тому, коли я почав працювати iOS-розробником, робота з пам’яттю була ключовим знанням, потрібним на всіх без виключення проектах. Ручне управління пам’яттю залишало великий простір для memory leaks. З того часу відбулись великі зміни: перехід на ARC та Swift. Знання про пам’ять все ще важливі, але вони вже не відіграють такої великої ролі.

Agile — 12% вакансій. Waterfall не згадується у жодній вакансії. Leanзустрівся 1 раз. Конкретизувати у вакансії фреймворк в межах Agile не прийнято: лише 1 вакансія згадує Scrum, жодна не згадує Kanban.

Core Animation — 12% вакансій. Минулого року було 21%. У 2 вакансіях згадується Core Graphics.

VIPER — 9% вакансій. VIPER в Україні популяризує компанія Genesis. Оскільки вони створюють топовіпроекти та потрапили в список «New Apps We Loved» від Apple, VIPER, який був модним у США з 2014 року, зараз у всіх на вустах в Україні. Тутможна почитати про VIPER, а тут Sergey Petrov критикує VIPER та називає його поганим вибором.

SOLID — 9% вакансій. Класика безсмертна. Але не SOLID єдиним. Щоб потрапити в компанію Wirex, потрібно знати та використовувати DRY, YAGNI та KISS.

Sockets — 9% вакансій.

CocoaPods — 9% вакансій.

А особисто я вважаю, що Senior має знати, чим відрізняються Sequence та Collection. Хоча деякі навіть плутають NSCoding та Codable.

Would be a plus

Тут немає таких явних лідерів. Але цей список цікавий тим, що як would be a plus компанії вказують ті технології, які вони реально використовують на проектах.

Objective-C — 9% вакансій.

C++ — 9% вакансій.

UI Tests — 9% вакансій.

Уточню, що 9% — це 3 вакансії. По 2 рази у вакансіях зустрічались TDD, Continuous Integration, fastlane, JavaScript, React Nativeта Agile.

Мій улюблений ARKitзгадується лише 1 раз як would be a plus. В must have він відсутній. Загалом доповненою реальністю займаються згідно з вакансіями лише 2 компанії: Snap та Genesis. Машинним навчанням на Swift — ніхто. Create ML, Core ML, Vision та Natural Language немає в жодній вакансії. Хоча Apple цього року зробила ставку саме на ці технології. А ми в Perfectial вже використовуємо їх на комерційному проекті.

Також по 1 разу згадуються Docker, AWS, Xcode Instruments, Sketch, Metal, OpenGL, Python, C#, Node.js. Можна зробити висновок, що всім не вгодиш, але кожен знайде свою вакансію.

Цікавинки

В компанію ZEO Alliance потрібен Senior Objective-C Developer з хорошим знанням Mac OS X. Mac OS X існувала в 2001-2012 роках.

Компанія N-iX шукає Senior iOS Engineer для амбітного клієнта, що планує мати один мільярд користувачів до 2020 року.

Думки технічних експертів

Ольга Мацик, Senior macOS and iOS Dev в Augmentive, PhD in Computer Systems and Components

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

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

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

Багато програм можуть мігрувати на такі пристрої, а також можуть з’явитися нові програми, які будуть використовувати переваги та можливості нових гаджетів. Як наслідок, виникне велика потреба у програмістах зі знанням та з досвідом роботи з ARKit та голосовим управлінням. Кандидати з такими знаннями матимуть значні переваги у залученні до нових проектів.

Борис Щербина, Senior iOS-разработчик в Beetroot

В следующем году я бы посоветовал обратить внимание на такое явление в мире iOS-разработчиков, как full stack developer. После того, как Apple заопенсорсила Swift, выпустив его под лицензией Apache не только для OS X, но и для Linux, стало разумным и доступным создавать back-end сервисы, написанные на Swift. Следовательно, те, кто раньше мог реализовать только клиентскую сторону сервиса (iOS-приложение), теперь могут предоставить услуги и по реализации серверной части. Для владельцев небольших проектов с компактным бюджетом или для создания MVP — это очень хороший вариант.

Ігор Рапалюк, Senior iOS Dev у Perfectial

На мою думку, окрім основних скілів, які вже зазначені в цій статті вище, кожен Senior повинен ще зробити ставку на якусь передову технологію, яка зараз є у Apple, але яка ще, так би мовити, не дійшла до наших замовників. Особисто я спостерігаю таку картину, що саме передові технології є ризикованими для них, і вони не готові ставити свої гроші, допоки не переконаються, що ця технологія буде прибутковою. Я вирішив для себе покопати в бік машинного навчання. Як на мене, в цьому є майбутнє. На кількох проектах у мене вже є реальні кейси його використання. Цього року Apple впровадила технології, які значно спрощують роботу з ML-моделями,їх створення та інтеграцію в проект. Плюсом також для Senior, який хоче розібратись в ML, будуть базові знання Python для роботи з Turi Create. Це бібліотека від Apple, яка містить в собі трохи більше можливостей, ніж Create ML.

P. S.Я планую протягом року підготувати аналогічні огляди про інші технології. Зокрема Front-end, Java, .NET, PHP, Node.js, Python, C++, Ruby, Android, Scala та Go. Якщо ви маєте бажання допомогти, напишіть мені приватне повідомлення на DOU. Навіть 15-хвилиннаконсультація вже є вагомою допомогою.

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

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

Машинное обучение vs традиционное программирование

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

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

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

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

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

Подход традиционного программирования

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

Как инженер создает решение с помощью традиционного программирования

Для предсказания курса валют алгоритм может использовать множество входных параметров:

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

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

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

Подход машинного обучения

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

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

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

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

Как дата-инженер разрабатывает решение при помощи машинного обучения

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

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

Типы машинного обучения

Традиционно машинное обучение разделяют на обучение с учителем (supervised), обучение без учителя (unsupervised) и обучение с подкреплением (reinforcement learning). Давайте посмотрим, как они работают и в каких случаях применяются.

Обучение с учителем

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

Для обучения с учителем данные должны быть маркированы (labeled). Это означает, что наряду с входными параметрами, данные должны содержать ответы или, как их принято называть, ярлыки (labels). Например, для задачи прогнозирования курса валют ярлыком будет служить значение курса обмена валют.

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

Построение модели при помощи машинного обучения с учителем

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

Классификационные задачи в машинном обучении с учителем

Классификационные задачи очень распространены. Такие алгоритмы отвечают на вопрос, входит ли что-либо в ограниченный набор ответов или нет. Например, у нас есть изображение и нам нужно классифицировать объект на нем. Есть ли на изображении кот? А собака? Либо же в медицинской диагностике классификация определяет наличие или отсутствие у пациента определенного заболевания.

Использование модели классификатора для определения объекта

Вот еще несколько примеров:

• Какой цветок изображен на картинке?
• Это положительный или отрицательный отзыв?
• Есть ли на фото знаменитость?
• Является ли данный email спамом или нет?

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

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

В этом эпизоде«Кремниевой долины» проблема показана как нельзя лучше.

Задачи регрессионного анализа в обучении с учителем

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

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

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

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

Наиболее распространенные области применения регрессионного анализа:

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

Машинное обучение без учителя

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

Работа алгоритма обучения без учителя

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

В машинном обучении без учителя выделяют три категории алгоритмов:

• ассоциативные;
• кластеризация;
• снижение размерности.

Ассоциативные алгоритмы

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

Принцип работы алгоритма:

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

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

Кластеризация

Алгоритмы кластеризации позволяют группировать данные в кластеры. Один из самых популярных алгоритмов в данной категории — это метод k-средних (K-Means). На схеме показано, каким образом он работает:

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

У кластеризации много областей применения:

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

Снижение размерности: PCA

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

С этой задачей справляется метод главных компонент (Principal Component Analysis, или PCA). Основная его идея такова:

В нашем примере PCA находит способ трансформировать двумерное представление данных в одномерное. Так, вместо двух входных параметров x и y, он создает новый параметр k, который и является проекцией из 2d в 1d.

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

На практике при тысячах входных параметров PCA может сократить их количество в 5-10 раз.

Обучение с подкреплением

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

Популярность обучения с подкреплением стала расти после известного матчапо игре го между системой искусственного интеллекта AlphaGo, разработанной британской компанией Google DeepMind, и азиатским чемпионом Ли Седолем. Система AlphaGo была создана с использованием алгоритмов RL. Даже первая версия искусственного интеллекта представляла серьезный вызов любому человеку. Следующая версия — AlphaZero — дошла до уровня сложности, недостижимого для людей. Отличительная черта AlphaZero в том, что она научилась играть сама с собой, а не использовать человеческие партии для обучения.

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

Основные рекомендации и пререквизиты

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

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

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

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

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

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

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

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

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

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

Доска (board) — используется для отображения «issues» в определенном виде. Есть два вида доски: Scrum и Kanban. Описанный концепт работает для типа Scrum. Поэтому при старте проекта выберете именно эту доску. Нам нужен Scrum из-за специфики того, как визуально разбита информация.

Версии (versions) — представляют временные отметки в проекте. В своей практике я всегда использую названия R.1 / R.Next. Все требования, которые появляются в процессе взаимодействия с клиентом в текущем релизе, должны быть зафиксированы и не теряться, поэтому те требования, которые не входят в текущий релиз, я помещаю в R.Next.

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

Теги (labels) — это ключевые слова, по которым можно легко сгруппировать/находить определенную информацию. Например, в своих проектах, я часто использую теги типа Web, APP, Integration. Чтобы быстро искать нужную информацию по разным запросам от разных участников проекта — QA, Клиента, Dev). Донесите всем, какие теги вы уже создали и зачем, а также расскажите команде, что беспорядочное создание тегов по любому поводу приведет к хаосу.

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

Фильтр (issues and filters) — просто мощный инструмент, который позволяет упростить процесс поиска данных или аналитики данных на ежедневной основе. Рекомендую вам использовать быстрые фильтры на верхней панели самой доски.

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

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

Для задач вот такой процесс:

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

Пользовательская история(story) — это отдельный тип сущностей, который я создаю на своих проектах. Он необходим для того, чтобы никого не путать терминологией. Вы также можете назвать это PBI (Product Backlog Item). Создание данного типа обусловлено внешним рынком. Людям, которые будут приходить на проект, будет намного легче привыкнуть к знакомым словам. Вы не будете путать понятия во время разговора о «тасках». Люди перестанут уточнять: это для разработчика «таска» или все же пользовательская история?

Задача / подзадача (task /sub task) — используется для более детального разделения пользовательской истории разработчиками и QA. О детализации задач идут целые войны! У каждого свой подход и методика, так же, как и по написанию пользовательских историй. Скажу пока одно: чем опытней разработчик, тем детальней описание задач и больше их количество под конкретной пользовательской историей. Задачи нужны в первую очередь самому разработчику, чтобы через неделю он мог вспомнить, что нужно сделать в определенной пользовательской истории.

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

Схематическая структура Jira для управления бэклогом

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

Плюсы работы с пользовательскими историями прямо на «борде»:

• Перетаскивание истории из одной секции в другую при помощи drag & drop.
• Быстрый поиск информации через поиск самого браузера.
• Быстрая фильтрация по нескольким параметрам: Релиз + Эпик + настраиваемый быстрый фильтр (Customer OK, Customer Review и так далее).
• Быстрая работа с определенной пользовательской историей после ее нахождения.

Минимальный набор требуемых секций в моем концепте: Backlog, BA in Progress, Ready for Grooming, Ready for Development, Next Sprint #N, Current Sprint #N. Такая структура позволит вам решить множество проблем, которые связаны с поставкой требований на разработку. Любому члену проекта, будет понятно, что происходит с бэклогом, на какой стадии каждая фича или отдельное требование, где есть проблемы в процессе разработки требований.

Секции и их предназначение

Пользовательские истории двигаются снизу вверх (Backlog => Next Sprint #N).

Отдельно нужно сказать о секции «CR Bucket». Ее наличие зависит от того, оперируете ли вы таким термином, как «Change request», у себя на проекте или нет.

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

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

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

• CR (Change request) — используется для того, чтобы помечать те пользовательские истории, которые считаются изменениями на требования. Ставится бизнес-аналитиком вендора.
• HLE (High level estimate) — используется для того, чтобы показать, что оценка пользовательской истории является высокоуровневой и там есть определенные допущения. Ставится бизнес-аналитиком вендора.
• Customer_Review — используется для указания клиенту, что пользовательская история готова к рассмотрению и обсуждению с клиентом. Ставится бизнес-аналитиком вендора.
• Customer_Hold — используется для того, чтобы показать, что конкретная пользовательская история нуждается в доработке командой вендора. Ставится человеком со стороны клиента.
• Customer_Approved — используется, чтобы отметить конкретную пользовательскую историю как утвержденную. Ставится человеком со стороны клиента.

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

Как это выглядит в реальности

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

Концепты похожего типа обговариваются на таких конференциях, как Atlassian Summit U.S. 2017 (вот видео) Если вы хотите идти в ногу со временем, вам просто необходимо начать разбираться в том, как это построить и как получить максимальную выгоду для своего проекта.

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

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

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

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

Тема внутренних маркетплейсов очень популярна в продуктовом мире. Благодаря App Store и Play Market встроенные приложения стали частью нашей повседневной жизни. В этой статье я расскажу, как мы используем iFrame, чтобы дать внешним разработчиками возможность качественно встраиваться в нашу систему. Объясню, с какими сложностями уже успели столкнуться и какие инсайты получили.

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

Немного о том, что мы делаем в Poster

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

Большинство POS-систем начинали свой путь со времен Windows 98 и выглядят вот так:

Работа с заказом в стационарной системе R_Keeper

Мы первые в СНГ сделали это по-другому:

Работа с заказом в Poster

Касса на iPad вместо Windows-моноблока. Админка в облаке вместо сервера под паркетом заведения. Сегодня с нами работают 8000 активных заведений в 75 странах мира.

Для чего нам открытый API

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

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

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

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

Как пришли к iFrame

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

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

Хостить JS/HTML на нашем сервере и загружать в админку.Таким подходом получим бесшовную интеграцию, но кто-то бесшовно поломает всю систему. Не катит.

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

Это первое, что мы услышали про iFrame, но серьезных аргументов «против» не нашли, поэтому решили попробовать 😀

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

• «iFrame небезопасен» → Да, так и было, лет 10 назад.
• «У меня на прошлом проекте все было написано на iFrame, чтобы прокинуть параметр из одной части сайта в другую, нужно потратить день» → Если неправильно использовать и городить костыли, то так и получится.
• «Он очень медленный» → Согласен, если 5 штук добавить на страницу, начнет тупить. Тогда все, что нужно сделать — не добавлять 5 штук.

В общем, все это, на мой взгляд, стереотип, главное как iFrame использовать.

Как мы используем iFrame

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

1. Manage платформукак возможность встроить веб-страницу в админ-панель;
2. POS платформудля расширения функций кассы;
3. Device платформу — единый хаб для управления устройствами в заведении.

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

• Оплатить заказ криптовалютой, emoji;
• Отправить заказ из кассы на доставку;
• Вызвать официанта, просканировав QR-код на столе;
• Оплатить заказ бонусами из приложения по лояльности.

Вот так система лояльности может расширить работу кассы:

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

Платформа под капотом

Касса Poster — это Single Page Application, которое открыто в браузере в нативном приложении. Внутри SPA под каждое приложение создается iFrame, в котором мы загружаем страницу с таким HTML:

<html manifest="/platform_157.appcache"><head><script src="/js/pos/platform/bundle.1545155099.js"></script><link rel="stylesheet" href="/css/pos/platform/main.1545155225.css"></head><body><div id="app-container"></div></body></html>

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

window.top.sendMessage({ action: "loaded", msgHash: "Ha2s7m" })

Poster слушает сообщения от iFrame и в ответ говорит, что нужно загрузить ещё один JS с кодом, который написал уже внешний разработчик:

// Слушатель на стороне Poster
window.addEventListener("message", (msg) => {
    If (msg.action === "loaded") {
       // Отвечаем приложению
       window.top.sendMessage({ 
          action: "init",
          data: "http://localhost:8080/bundle.js"
       })
    }
});

Разработчик пишет свой SPA на основе нашего шаблона на github. JS собирается Webpack-ом в один bundle файл. В процессе разработки bundle раздается через Webpack Dev Server и касса грузит его с локальной машины. При этом можно использовать фишки webpack, такие как live reload.

Как только приложение закончено, разработчик загружает bundle к нам на сервер одной командой — npm run deploy. С этого момента любой клиент Poster может подключить приложение и пользоваться им.

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

API платформы

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

let result = await window.Poster.orders.getActive(); // Получаем текущий заказ
await window.Poster.orders.setOrderBonus(result.order.id, 10) // Ставим скидку 10 грн

window.Poster — это глобальная переменная со всеми методами API. Под капотом каждый метод отправляет сообщение на Poster через postMessage. Каждому сообщению присваивается уникальный хеш. По этому хешу в локальную переменную сохраняется callback, который нужно вызвать, как только закончится выполнение метода. Когда Poster заканчивает выполнение, он отправляет на iFrame postMessage c результатом и хешом сообщения, на которое отвечает. По нему мы находим сохраненный callback и вызываем его.

Таким образом, вся коммуникация между iFrame и Poster построена на postMessage, при этом весь этот процесс двухсторонний и может инициироваться как со стороны Poster, так и со стороны фрейма.

Для удобства разработки все функции API возвращают Promise. Код процессится через babel поэтому можно использовать async. Это упрощает написание кода и помогает избежать callback hell.

Интерфейс и общение с пользователем

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

По умолчанию, iFrame скрыт от пользователя. Чтобы показать его, нужно вызвать метод Poster.interface.popup, который просто меняет CSS у iFrame и показывает его поверх основного интерфейса. В попапе разработчик рендерит страницу любым удобным для него способом. Например, мы используем React, но можно подключить другие фреймворки: Angular, Vue.js.

Некоторые ивенты могут менять обычный алгоритм работы Poster. Такие ивенты называются блокирующими и ждут ответа от приложения. Например, ивент закрытия заказа: в один из аргументов обработчика приходит callback-функция, которую нужно вызвать, чтобы продолжить закрытие заказа. Эту функцию нужно вызвать в течение 5 секунд или отобразить свой интерфейс, иначе мы перезагрузим iFrame и продолжим стандартный алгоритм работы Poster.

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

// Подписываемся на ивент перед закрытием заказа
Poster.on('beforeOrderClose', (data, next) => {
    // Если к заказу уже привязан гость, продолжаем обычный алгоритм работы Poster
    if (data.order.clientId) {
        next();
    } else {
        // Показываем окно с напоминанием
        Poster.interface.popup({title: 'Спроси про дисконтную карту'});
    }
});

В итоге, в платформе можно нарисовать любой интерфейс, но он ограничен рамками iFrame и не может поломать работу кассы. К сожалению, не у всех разработчиков есть дизайнеры, которые смогут продумать UI/UX до деталей. Большинство просто юзает Bootstrap и не заморачивается над качеством. Это привело нас к новому вызову — сделать интерфейсы внешних приложений простыми и красивыми. Глобально, мы еще не решили эту задачу, но план уже есть:

1. Выпустить свою библиотеку с компонентами интерфейса, чтобы разработчики могли использовать ее вместе с Bootstrap.
2. Сформировать UI/UX гайдлайны.
3. Сделать шаблон приложения с готовым интерфейсом.

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

Инсайты в процессе разработки

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

Кастомные доработки под клиента

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

Сейчас рекомендуем нанять разработчика, который сделает эту доработку для кассы. Так внешний разработчик сети кофеен RedCup решил проблему с мошенничеством со стороны гостей, когда гость покупает сим-карту за 50 грн, регистрирует карту лояльности и получает бонус 200 грн.

Упрощение выхода на зарубежные рынки

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

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

Улучшение архитектуры кода в ядре

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

Итог

За полтора года работы POS-платформы iFrame зарекомендовал себя как отличный инструмент, и мы планируем использовать его в дальнейших проектах. С его помощью мы качественно решаем проблемы наших клиентов и приводим новых клиентов партнерам. Уже 1200 заведений из 8000 пользуются внешними разработками.

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

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

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

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

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

Image by Nina Magradze

Формирование цели совещания

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

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

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

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

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

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

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

Далее я попросил его дать мне два дня на составление плана по данному вопросу и провел ряд рабочих совещаний? цели которых были уже заранее определены. Например: «Формирование рабочей группы, определение зон ответственности участников рабочей группы, согласование перечня безбалансовых отделений для проведения анализа AS-IS». Благодаря четко сформулированным целям каждого совещания, нам удалось в течение 4 месяцев провести реинжиниринг бизнес-процесса.

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

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

Определение даты и времени совещания

Забавный случай произошел со мной в предпраздничный день. Мне назначили совещание 23 августа на 16:00, ну и конечно, никто не задумался о том, что рабочий день у клиента был до 16:30.

Итак, в этот день я приехал на встречу, и мы пытались работать первых 15-20 минут.А дальше все участники совещания просто посматривали на часы и думали о предстоящем празднике, шашлыках, отдыхе, рыбалке. Никто, в том числе и я, не смог побороть эти предвкушения. Совещание было полностью провалено, мы не проработали в полном объеме ни одного из 5 вопросов, да и не очень то хотели, если честно.

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

Выбор места совещания

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

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

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

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

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

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

Благодаря этому я выделяю три локации для встреч исходя из целей:

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

Формирование повестки совещания

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

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

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

Определение способа коммуникации и участников совещания

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

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

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

Из офиса мы вышли в 10:30, так как нужно было ехать в другой конец города. Ровно в 12:00 мы приехали к клиенту ради совещания в 3 минуты. Архитектор задал только один вопрос: «Вы строили архитектуру с учетом отказоустойчивости?». Мы ответили: «Да». На этом совещание закончилось, и нас ждала полуторачасовая обратная дорога в офис.

Мы потеряли 3 часа на дорогу и 3 минуты на ответ. Вот такой результат. По возвращении в офис я распечатал и повесил перед собой надпись: «Без адженды и целей совещания не проводить!»

Для определения состава участников совещания мне помогают ответы на следующие вопросы:

• под каждый вопрос определен участник, ответственный?
• необходимо ли привлечение экспертов по вопросу?
• достаточно ли у ответственного полномочий для принятия решения по вопросу?

Ответ на вопрос: «Что я хочу получить в результате по каждому из вопросов?»

Для этого я создал шпаргалку, которой хочу поделиться:

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

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