Результати пошуку

Чому мобільна розробка технологічніша за веб? Чи може програміст запустити застосунок без команди? Чи правда, що головний етап роботи над продуктом починається після релізу, та чому всі сперечаються про конструктори інтерфейсів і force unwrap? Артур Майорський, iOS Engineer в Universe з екосистеми Genesis, спростував найпоширеніші міфи в цій сфері на прикладі розробки найпростішого застосунку — мобільного калькулятора. > Мобільна розробка — це примітивне програмування > Застосунок можна створити без коду > Після релізу фаза розробки завершується > Ринок Mobile App — перенасичений, а створення застосунків — затратне > Використання force unwrap в iOS-розробці — так чи ні? > Час програмістів дорожчий, ніж час компʼютерів МІФ №1 Мобільна розробка — це примітивне програмування. Цей міф виник через велику кількість інструментів, що полегшують роботу iOS- та Android-інженерів. А також тому, що в цю сферу досить низький поріг входу. Навіть щойно почавши вивчати розробку, можна написати просту логіку базового калькулятора, додати готовий інтерфейс, — і ваш перший «продукт» готовий. Але водночас у мобільній розробці чимало цікавих завдань і складних технологій. На відміну від вебу тут є доступ до найрізноманітнішого функціонала. Наприклад, доступ до всіх функцій камери та LiDAR на телефоні дає можливість реалізувати функціональність, можливу лише в мобільній розробці. В нашому застосунку ScanGuru це використовується для підказок користувачу при скануванні документа. Це допомагає зробити якісніший знімок, регулюючи відстань, ступінь освітлення тощо. Такі рішення неможливо реалізувати, просто під’єднавши стандартну бібліотеку роботи з камерою. Треба аналізувати потік кадрів, створювати алгоритми, які шукатимуть на кожному кадрі документи та перероблятимуть їх у вигляд, максимально схожий на цифровий. Тому мобільну розробку аж ніяк не можна назвати примітивною. МІФ №2 Застосунок можна створити без коду. В iOS, як і в Android, існують готові рішення, наприклад, конструктори інтерфейсів. Деякі розробники використовують їх, адже це швидше й наочніше. Інші створюють інтерфейси з допомогою коду, тобто прорахуванням кожного елементу на екрані, адже це дає більше гнучкості. Часто це стає предметом суперечок та навіть хейту. Але насправді можна знайти плюси й мінуси в будь-яких рішеннях та архітектурах. В Universe не користуються конструкторами інтерфейсів в iOS. В Android-застосунку доля готових інтегрованих рішень складає максимум 5%. У будь-якому разі це лише візуальна частина. Розробнику все одно доведеться багато працювати з кодом, щоби її налаштувати. Навіть вже згаданий калькулятор неможливо створити готовими рішеннями без коду. МІФ №3 Після релізу фаза розробки завершується. Навпаки, усе тільки починається. Більшість розробників спочатку випускають MVP-версію продукту, щоби перевірити гіпотезу та нішу. На цьому етапі швидкість — найважливіша, тому командам немає сенсу заморочуватися над архітектурою та дизайном. Це може зайняти багато часу та інвестицій, а продукт не злетить. Повернімось до калькулятора. Наприклад, є гіпотеза, що такий застосунок може приносити мільйони. Можна створити його за день, а можна залучити команду продакт-аналітиків, два місяці думати над дизайном, проводити UX-дослідження та за пів року нарешті запустити бездоганний калькулятор. Але виявиться, що в цю нішу дуже дорого приводити людей. Дізнатися про це можна було б, витративши лише один день розробки. Тому після релізу, якщо гіпотеза не підтвердилася, і застосунок нікому не потрібен, фаза розробки справді завершується. Якщо ж продукт злетів, ця фаза починає розганятися: переписується MVP, створюється нова архітектура, набирається команда, планується додатковий функціонал, проводяться тести тощо. Надалі продукт треба буде постійно покращувати — протягом всього його існування. МІФ №4 Ринок Mobile App — перенасичений, а створення застосунків — затратне. В App Store та Google Play — мільйони застосунків. Їхнє число постійно змінюється, адже щодня на платформи завантажуються нові продукти та видаляються старі й неякісні. Водночас загальний обсяг ринку мобільних застосунків щороку зростає. 2021 року користувачі обох платформ витратили $132 млрд, а за прогнозом Sensor Tower , у 2026 році глобальні витрати сягнуть $233 млрд. Тому перенасичений не весь ринок загалом, а окремі його ніші. Натомість є ніші, що поступово зростають без зупинки, або ті, що стрімко зростають, а потім зупиняються. Для багатьох застосунків достатньо одного розробника. Якщо він обрав правильну нішу та зробив конкурентний продукт, у нього є всі шанси на успіх. Не для всіх продуктів потрібна велика команда iOS-розробників, адже 100 людей не зробить кращий калькулятор, ніж одна людина. Створити застосунок насправді можна безкоштовно, інвестувавши лише власний час та 100$ за акаунт розробника в App Store (25$ — в Google Play). Якщо розробник планує запускати продукт самостійно, він має базово розумітися в бізнесі, продакт-менеджменті та маркетингу, інакше не зможе конкурувати та залучати аудиторію. МІФ №5 Використання force unwrap в iOS-розробці — так чи ні? Force unwrap — це дія, яка за певних умов може «крашнути» застосунок. Та тема для запеклих дискусій. Одні розробники вважають, що їх не можна використовувати в коді. Але, з іншого боку, вони космічно заощаджують час розробника в застосунках, складніших за калькулятор. І якщо все робити правильно, шанс, що все впаде, — частіше мінімальний. Тому є думка, що за певних обставин force unwrap можна використовувати. Наприклад, якщо не використовувати force unwrap, а шукати шляхи безпечно приховувати від користувача помилки, як це доволі часто роблять, QA може пропустити баг. Краш пропустити неможливо, тому force unwrap може економити багато часу розробнику та зменшувати кількість багів. МІФ №6 Час програмістів дорожчий, ніж час компʼютерів. Є думка, що всі застосунки працюють занадто повільно, й розробники не докладають достатньо зусиль, щоби зробити їх швидшими. Для мобільної розробки справді немає сенсу робити дуже швидкі програми. Адже в чому сенс супершвидкої операції, якщо здатність екрана «намалювати» її все одно обмежена? Зазвичай розробники у швидкості обробки інформації орієнтуються саме на можливості екрана — 1/120 секунди. Так користувач не помітить, як вона обробляється. Навіть якщо такої швидкості досягнути не вдається, і певна операція обробляється довше, усе одно краще не «вигадувати велосипед» та не писати суперскладний код два тижні, щоби воно працювало швидше. Краще просто намалювати гарний loader, адже два зайвих тижні розробки означають, що на два тижні пізніше вийде реліз. За цей час він міг би приносити +20% виручки щодня. Це потенційно сотні тисяч втрачених доларів просто тому, що в користувача трошки швидше завантажиться екран, і це не принесе глобальної користі ані йому, ані бізнесу. Сучасні смартфони — досить потужні, здатні нормально працювати навіть у застосунках із дуже поганим кодом. Якщо програма працює занадто повільно й зависає, то це відбувається через очевидні баги, а не через те, що розробник не використав якісь складні рішення. Краще просто та швидко написати якісний код, ніж довго працювати над тим, щоби застосунок працював на 1 мілісекунду швидше. У простій зрозумілій структурі коду значно легше шукати баги та фіксити їх. Інший бік складного коду — довгий онбординг нових співробітників. Десь економиться трошки часу, але гальмується вся подальша розробка. Скоро в Genesis планується запуск нового профільного комʼюніті для мобільних розробників, дізнайтес я про інші 12 спільнот.

У новому матеріалі з серії Genesis Crew публікуємо історію генезійця, що нині боронить Україну у складі ЗСУ. SEO Team Lead проєкту Legit з екосистеми Genesis, Олександр Дука, у квітні долучився до підрозділу, що виконує бойові завдання на фронті. В інтерв'ю для блогу Genesis Олександр розповів про те, чим керування бійцями схоже на управління командою, як військові проходять навчання, і як виглядає вдалий день на війні. У сфері SEO я близько десяти років. З 2013 року налаштовував клієнтські сайти. А у 2018 мій друг, що працював у Genesis, запропонував подати резюме у компанію. Я не одразу погодився, був упевнений, що мого професійного рівня буде недостатньо, адже раніше не працював із продуктом. Ба більше, вважав тоді, що новинні сайти — це нудно, одноманітно і нецікаво для SEO-спеціаліста. Але все ж спробував, пройшов всі етапи співбесіди й потрапив у команду Legit. Спершу працював як рядовий SEO-фахівець, а з реогранізацією проєкту перейшов на позицію SEO Team Lead. Ми з колегою Ніною Ромащенко вдвох управляли командою SEO: вона відповідала за контент та менеджмент копірайтерів, а я — за технічну реалізацію, взаємодію з розробниками, а також за нашу стратегію в цілому. Робота в Legit стала якісним левел-апом в порівнянні з тим, що я робив у попередній компанії. Коли в тебе є клієнти, мусиш підлаштовуватись під їх запити, працюєш на замовника, а не для покращення продукту. В SEO для медіа все зовсім по-іншому: безперервно шукаєш ідеї та інструменти для кращого результату, відстежуєш, що там у конкурентів, як зробити ліпший контент, ніж у них. Висока конкуренція — те, що драйвить мене в роботі найбільше. І до того ж команда — у нас зібралася дрімтім, найкращі фахівці, яких я зустрічав. Пишаюся нашою співпрацею і нашими досягненнями. Минулого літа ми успішно вийшли з-під апдейту, показники сайтів значно зросли, і все це в результаті піврічної кропіткої роботи із переформатування процесів, підходів тощо. У лавах ЗСУ У перші дні вторгнення пішов у військкомат. На жаль, мені відмовили через те, що не мав бойового досвіду. Тому взявся волонтерити у складі групи, яка допомагала київській ТрО та ще декільком підрозділам: купували спорядження, шукали рації тощо. І в середині квітня, коли росіяни відійшли з Київщини, один з наших «підопічних» підрозділів оголосив набір у свої лави. Не дивлячись на те, що вони виконували досить специфічні бойові завдання, і людей без досвіду брали не охоче, мені пощастило доєднатися до них. Тоді в підрозділі з'явилися інструктори, стало більше можливостей навчати новачків. Я вже був добре знайомий і з командуванням, і з бійцями, і зрозумів, що цей мій шанс нарешті приєднатися до української армії, другого такого шансу чекатиму ще довго. В підрозділі дуже круте командування: «азовці» ще з першого набору 2014 року — бійці з історією, величезним досвідом. Це була надзвичайна можливість воювати поряд із кращими з кращих. Бойове хрещення У мене не було ілюзій про армію, бо в Genesis я прийшов після року служби на контракті у Києві. Тоді мені дуже не сподобалося, але я отримав уявлення про те, як усе працює в цій системі. Тому в мене не було наївних уявлень про шикарну підготовку та купу адекватних людей в армії. Тож з потраплянням в бойовий підрозділ «розриву шаблону» не трапилось. Спершу було півтора місяця навчання, яке ми проходили в частині біля Києва. У нас були кваліфіковані інструктори із США, вони якісно проводили підготовку, багато чого дали, що потім стало в пригоді. Паралельно ми оформлювали документи, збирали потрібні речі й техніку. Врешті поїхали за місцем призначення. Точка прибуття підрозділу — це, зазвичай, місто за лінією фронту або біля неї. Там ми розселяємося і чекаємо на бойові задачі. Скільки триватиме очікування — завжди невідомо. Це можуть бути тижні, може дні. Специфіка наших задач в тому, що ми виїжджаємо на позиції попрацювати й одразу повертаємося назад. Не всім так щастить, бо є механізовані бригади, які тримають свою ділянку, не залишаючи її. Вони передають, що відбувається, не пускають ДРГ тощо. Це стандартна робота з утримання позицій, але вона передбачає те, що ти можеш місяцями не вилізати з окопів. Перший бойовий вихід точно ніколи не забуду. Як завжди, усе було нашвидкуруч, ми практично не мали уявлення знали, куди йдемо. На місці попали у засідку. Працювали тільки росіяни, летіла арта, а від нас — нічого, була тиша. Ми знали, що якщо зараз вони на нас підуть, то швидко будуть уже у Миколаєві. Я не скажу, що було страшно йти, але це була хоробрість від незнання. Ми просто не знали, куди й на що йдемо. Потім вже стало страшно, ніколи не хотілося так жити, як тоді. Проте вдалося вибратись. Це був цікавий і цінний досвід. В результаті ми вийшли з малими втратами. Після того ми навчали людей без досвіду бойових виходів, і я побачив колосальну різницю. Люди без виходів за плечима дуже погано вчаться і мало розуміють, куди вони йдуть. Перебування в бою кардинально змінює ставлення до навчання та до опанування навичок, які можуть врятувати тобі життя. Солдат до бойового виходу і після нього — це дві різні людини. Ще важливий фактор — команда. Коли ми попали в засідку, то не мали зв’язку з командирами, це був абсолютний хаос. Бій це завжди хаос. Ми пробували відходити правильно, як вчили раніше, але виходило не дуже. Що я для себе усвідомив після перших виходів: злагоджена команда — це найголовніше. Сам по собі ти нічого не вартий в бою, запорука успіху — в командній роботі. Тому вкрай необхідно постійно проводити злагодження, тренування, щоби люди розуміли одне одного не з півслова, а взагалі без слів. Ми зробили дуже багато помилок на тому виході, і на кожному наступному навчанні ми намагаємося їх нівелювати до мінімуму. Це про сотні маленьких деталей: від зв’язку і до порядку в колонах, яка має бути між бійцями взаємодія, яка дистанція, як відстежується ситуація — не злічити всього. До речі, з часу нашого першого виходу багато всього змінилося. Коли ми вдруге нещодавно заїжджали на те саме місце, то чули вже не тишу з української сторони й російську арту, а бачили наші колони техніки за ленд-лізом. Я раніше таку техніку зустрічав лише на картинках в телеграмі. Це дуже великий дисонанс між тим, які були обставини влітку і зараз. Дивишся і думаєш: «О, які штуки катаються, навіть не чули про такі». Крім цього, дуже якісно організована нині медицина. Вони виїжджають на БТРах «на нуль», що десять хвилин, наче маршрутки: швидко туди-назад, все налагоджено максимально ефективно. Спорядження і волонтери Ми намагаємося спростувати один з найбільших міфів, який досі сидить у людей в головах, що їм усе винні, їх мають повністю забезпечити й все видати. Зараз іде повномасштабна війна, на всіх всього не вистачає, бо поки немає відповідних потужностей. Зарплата дозволяє військовим купити самим усе необхідне. Можна чекати, що щось видадуть, але цим ви будете не сильно задоволені, волонтери розбештали екіпіровкою, ми звикли до якісних речей. Ну і нічого якіснішого і комфортнішого, ніж те, що ти вибрав собі сам, не буде. Я прийшов у підрозділ повністю споряджений, купив заздалегідь усе найнеобхідніше. Доки були на навчаннях, докупив дещо. Все вирішувалось і вирішується наразі силами волонтерів і військових. Не знаю, як в інших підрозділах, але у нас забезпечення державою зимовою формою мінімальна. Видали термобілизну і теплі балаклави. Усі печі й генератори — це лише від волонтерів. Завдяки їм ми вже повністю підготовлені до зими. Тимлід і командир Я закінчив військову кафедру, тому маю офіцерське звання лейтенанта. Через це я не можу бути рядовим солдатом, відповідно не можу піти на навчання, наприклад, з управління Javelin. Якщо ти офіцер, то ти повинен управляти групою або підрозділом, жодних джавелінів. Це пережиток радянських часів, і я не дуже задоволений, що не маю змоги вчитися, як солдат, опанувати нову зброю, наприклад. Проте, наскільки мені відомо, зараз це поступово змінюється, і вже є навчальні курси для офіцерів. А поки моє завдання — керувати бійцями. Спочатку це було десять осіб, а зараз я заступник командира роти. Можна сказати, знову тимлід. Це все загалом схоже на команди в бізнесі, просто це люди зі зброєю і вони розв'язують інші питання. А процеси ті самі: інтерв’ю, сканування, кого можна поставити на командира відділення, кого треба прибрати з керівної посади, щоби був кращий клімат в колективі тощо. Найважче — це саме підготовка, коли в тебе є завдання і тобі потрібно усе організувати. Іноді для мене це навіть важче, ніж власне бій. Можливо, ми просто не зіштовхувалися з такими жорстокими боями, як інші, але саме підготовка для нас найважча. Треба усе узгодити, спланувати, розподілити людей, побудувати карти, маршрути, запасні маршрути, запасний зв’язок тощо. Справжній головний біль менеджера. Людей в нас дуже багато і вони дуже різні — і за віком, і за професіями. Наймолодшому — 19 років, найстаршому — 57. Є і будівельники, й IT-фахівці, охоронці, є навіть оперний співак. Важливо, що у нас всі прийшли в Збройні сили добровільно, тобто цілком усвідомлюють, навіщо вони тут. Людей з бойовим досвідом мало — близько п'яти відсотків. За характерами всі дуже різні, як в будь-якій команді. Ми довго уживалися всі разом, але зараз все добре, бо вже пів року пліч-о-пліч. Це, до речі, дуже допомагає тримати емоційну стабільність — коли всі діляться пережитим одне з одним, обговорюють, а не залишаються наодинці зі своїми враженнями й почуттями. Бувають погані дні, бувають кращі – як і в житті. Найкращий день на війні — коли немає втрат.

П’ять років тому команда розробників з компанії JetBrain вирішила, що світові потрібна більш лаконічна та типово-безпечніша мова ніж Java — й створила Kotlin. Мова прижилася, а Android визначив її як рекомендовану мову програмування для розробки застосунків. Тепер програмісти, але уже з Google, думають над тим, щоби переосмислити С++ та пропонують замість неї нову, експериментальну мову програмування Carbon. У липні 2022 року на конференції СPP North C++ в Торонто розробку представив   Чендлер Каррут , який керує напрямом технічних мов програмування в Google. > Навіщо потрібен Carbon > Якою буде нова мова > Де можна протестувати нову мову > А чому не обрати Rust > Як далі розвиватиметься Carbon Раніше у Google уже були подібні проєкти — і успішні, і не дуже. Наприклад, у 2007 році троє розробників компанії спроєктували мову програмування Golang (або просто Go). Нова розробка чудово підійшла для високонавантажених систем, тому вже досить добре проявила себе у бекенді, веброзробці та десктопних застосунках. «Gо — це мова невеликих, але дуже швидких сервісів. Однак, якщо «тягнути» її в enterprise з Agile-проєктами як основну, то може бути халепа зі швидкістю розробки. Зараз Go зайняла нішу атомарних сервісів, в якій раніше була мова С. Втім, попри створення деяких best practice, у ком’юніті не спостерігається якогось сталого фреймворку. Кожна аплікація на Go «особлива», відповідно, кожній команді потрібно робити свій «велосипед» , — говорить Федір Мохонь, Solution Architect. Через чотири роки Google реалізувала мову Dart — її задумували як прогресивну заміну JavaScript, яка на той момент мала проблеми з розширюваністю, продуктивністю та підтримкою роботи складних застосунків. Однак широкого використання ця мова не отримала, і зараз використовується хіба що разом з Flutter. Навіщо потрібен Carbon? На сторінці нової мови на GitHub Керрут пояснює: C++, яку застосовують для критично важливих для продуктивності застосунків, має низку проблем, які заважають сучасним розробникам. Це і десятиліття технічного боргу, і багато застарілих практик, які С++ забрала у своєї попередниці, мови С, і бюрократичний комітет, неповороткість якого значно сповільнювала оновлення та еволюцію мови. Крім того, у С++ немає безпеки пам’яті, яку матиме Carbon. Зараз помилки у доступі до пам’яті є одними з найбільших ризик-факторів у плані безпеки. Розробники Carbon будуть шукати способи кращого відстеження неініціалізованих станів, розробки API та ідіом, які підтримують динамічні перевірки меж, і створювати комплексний режим збірки. Планується, що пізніше дизайнери створять безпечний піднабір для Carbon. Розв'язувати перелічені проблеми за допомогою С++ справді складно, тож після досліджень та оцінки багатьох мов, інженери Google вирішили створити нову. Передбачається, що Carbon позбудеться багатьох недоліків С++, але водночас матиме схожий синтаксис та подібний функціонал. Ось приклади коду, написані на С++ та Carbon: Якою буде нова мова? Carbon побудують на основі сучасних принципів програмування, включно із системою, яка позбавить необхідності переперевіряти код після кожного екземпляру. У ній є компілятор, бібліотеки, інструменти, документи, pavage manager та багато іншого. Компілятор коду написаний з використанням LLVM та напрацювань Clang — компілятора для C, C++, Objective-С й Objective-C+. Відповідно до документації, мова матиме такі характеристики: можливість створювати критично важливе для продуктивності ПЗ; код, який легко читати, писати та підтримувати; здатність взаємодіяти з кодом на С++ та мігрувати з нього; можливість швидкої та масштабованої розробки; підтримка сучасних ОС, апаратних архітектур та середовищ; практична безпека та перевірка механізмів. Команда розробників також збирається створити вбудований package manager, чого дуже бракує C++. Де можна протестувати нову мову? Вихідний код можна завантажити на GitHub. Google прагне зробити Carbon незалежним проєктом, тож всі охочі можуть долучитися до обговорення в Discord . Крім того, потестувати нову мову можна в браузері завдяки інтеграції з Compiler Explorer. Вихідний код проєкту розповсюджують за ліцензією Apache 2.0 . В мережі вже є докладні відеогайди , як встановити собі карбон — з синтаксисом та прикладами. У документації сказано, що мова поки не готова до повноцінного використання. Наразі вона не має конкретної семантики та повноцінної реалізації. Для порівняння, у 2007 році розробники побачили GoLang вже повністю готовим до використання. «Go — це не випадковий успіх, а відповідь на декілька проблем. По-перше, це суттєве ускладнення бізнес-логіки застосунків в останнє десятиліття, що своєю чергою спричинило перехід до мікросервісної архітектури. Моноліт на Java, який компілювався годинами та вимагав гігабайти пам‘яті для роботи просто перестав вирішувати проблеми девелоперів. Для розробки мікросервісів, які швидко обробляють запити й ефективно використовують ресурси системи Go де-факто вже став стандартом. По-друге, на Go, крім вебзастосунків, швидко і зручно писати різноманітний тулінг, написання якого на тому ж C зайняло б набагато більше часу. Щонайменше, через manual memory management» , — говорить Дмитро Гаранжа, Team Lead at Howly . Тож зараз на Carbon можна лише переписати окрему бібліотеку та використати її в наявному проєкті на С++. Однак малоймовірно, що коли розробку мови завершать, її ключові принципи істотно зміняться. А чому не обрати Rust Одразу після презентації Чендлера Каррута в Торонто, в спільноті з'явилися думки про те, що Carbon може грати на полі Rust — ще однієї мови для низькорівневого програмування, яку розробляє Mozilla Research. За структурою мова Rust нагадує «плюси», але істотно відрізняється в деяких деталях реалізації синтаксису й семантики, а також орієнтацією на блокову організацію структури коду. Утім, проєктам, що активно працюють з C++, досить важко перенести проєкт на Rust, адже мова має properties та модулі, яких не має в C++. З одного боку, поки не можна стверджувати, що Rust і Carbon конкуренти. З іншого, якщо Google буде активно промотувати свою мову, і з’являтимуться фахівці, що пишуть нею, Rust може бути посунутий. В чому основні відмінності двох мов? Як далі розвиватиметься Carbon? Відповідно до дорожньої карти, основну версію, яку можна буде використовувати для загальних цілей, планують закінчити до кінця 2022 року. До того часу розробники уже пропрацюють оператори, класи, універсальні шаблони, основні типи інтерфейсів, вказівники, і, власне, відшліфують сумісність з мовою С++. Передбачити, чи замінить Carbon C++ повністю, важко — нова мова поки лише експериментальна. На її впровадження підуть роки, навіть якщо вона «злетить». До того ж достеменно не відомо, який саме рівень С++ Carbon зможе замінити: чи Google C++, чи С++, що містить класи, а від цього буде багато залежати. Однак навіть зараз можна помітити, що потенційний успіх мови лежить у царині використання кодових баз С++, які легко мігрують на Carbon. У спільноті фахівців побутує думка , що запорука потенційного успіху нової мови — можливість компіляції на різних платформах, а для цього Carbon має бути максимально портативним та простим для імпорту й міграції.

У жовтні шукаємо спеціалістів, здатних із хаосу побудувати систему, вирішити будь-який конфлікт та організувати освітні івенти, які будуть сприяти підвищенню рівня спеціалістів та обізнаності про роботу з ІТ-продуктом. Мова про фахівців із рекрутингу та HR. Гортайте підбірку, дізнавайтеся більше про команди і приймайте нові виклики! Recruitment Marketing Specialist (вакансія закрита) Новий фахівець посилить івент-напрям компанії задля найму найкращих кандидатів. Робота передбачає створення та проведення кар’єрних заходів, підготовку рекламних матеріалів, активну роботу з партнерами для підвищення впізнаваності бренду. Для цього ідеально мати від року досвіду у рекрутингу, менеджменті проєктів чи брендингу, навички копірайтингу та ведення переговорів, а також вміти працювати з аналітикою. Student Partnership Manager (вакансія закрита) Також шукають людину, яка буде займатися партнерствами зі студентськими та молодіжними організаціями, щоби залучати кандидатів до бізнесів Genesis. Це включає і презентації компанії на фестивалях, ярмарках вакансій та форумах, і проведення лекцій, семінарів та тренінгів, і розвиток відносин із профільними організаціями та ком’юніті. Найкраще з роботою впорається людина, яка вже рік працює у диджитал-маркетингу, брендингу чи організації івентів, вміє спілкуватися з людьми та вести переговори, й водночас не боїться роботи з аналітикою. People Partner (вакансія закрита) Holy Water — це компанія-паблішер мобільних ігор. Аби виводити процеси на новий рівень, команда шукає People Partner. Це вакансія для мідл-фахівця з трьома роками досвіду, що будував внутрішні HR-процеси, розробляв HR-інструменти в міжорганізаційних та міжфункціональних командах. У Holy Water обов’язки будуть схожими: вивчати та контролювати внутрішні HR-процеси, пропрацьовувати план змін у команді відповідно до запитів керівника та допомагати співробітникам вирішувати професійні проблеми. People Partner (вакансія закрита) У портфоліо Keiki — п’ять застосунків та освітні вебпродукти для малюків від двох до шести років. Ідеальний кандидат має мінімум три роки релевантного досвіду, у тому числі міжорганізаційної та міжфункціональної командної роботи, вміє будувати та впроваджувати HR-процеси. У перші півроку він сфокусується на аудиті процесів та запитів керівника, аби сформувати «дорожню карту» пропозицій та змін. Загалом, потрібно займатися повним циклом управління талантами, допомагати пропрацьовувати корпоративну культуру, а за потреби — скласти для працівників персональний план розвитку та допомогти їм вирішити професійні проблеми. People Partner (вакансія закрита) Фахівець приєднається до команди OBRIO , чиїм флагманським продуктом є астрологічний застосунок Nebula. Що потрібно робити? Брати участь в управлінні талантами, моніторити задоволеність та залученість співробітників, ставити цілі та організовувати освітні заходи відповідно до запиту керівників. Серед вимог — 2-3 роки у HR, з яких мінімум рік в ІТ, досвід у HR-підтримці команд із чисельністю понад сто людей, розуміння, як проводити якісні one-to-one та англійська рівня strong intermediate. Перевагою буде психологічна освіта та знання коучингових підходів. HR Business Partner (вакансія закрита) Компанія Boosters створює мобільні застосунки для покращення якості життя мільйонів людей. До команди потрібен спеціаліст, який сформує ефективну HR-стратегію, зокрема, продумає вдалу структуру команди, план розвитку працівників та топменеджменту й шляхи утримання співробітників, а також запустить роботу з HR-брендом. У майбутньому HR BP збиратиме власну команду, тож найкраще з обов’язками впорається фахівець рівня сеньйор з мінімум чотирма роками досвіду, вмінням формувати HR-стратегії та англійською рівня Advanced. Вакансія партнера: Talent Acquisition Specialist (вакансія закрита) Стартап Codefinity розробляє освітню платформу для навчання програмуванню. Новий фахівець приєднається, аби залучити сильних гравців, які виведуть продукт на перше місце в категорії «Освіта». Серед завдань — не лише робота з різними платформами для пошуку кандидатів, а й удосконалення процесу відбору: дослідження зарплат, аналіз кращих практик, автоматизація взаємодії з пошукачами. Знадобиться принаймні рік у рекрутингу в продуктових, ігрових або аутсорсингових компаніях, досвід в управлінні повним циклом найму та робочі знання англійської мови.

У React зазвичай використовують context’ для інкапсуляції бізнес-логіки. При цьому оновлення будь-якої властивості в одному з контекстів спричиняє оновлення всього дерева компонентів. Від цього страждає продуктивність застосунків. А якщо застосунок із великою кількістю складових, одна з важливих задач — налагодити впровадження нових функцій, витрачаючи мінімум зусиль і часу. Завдання можна вирішити за допомогою архітектури, що робить систему гнучкою при будь-яких масштабах застосунків. Такий варіант запропонував Антон Пінкевич, Front-end Team Lead в Universe, продуктовій компанії з екосистеми Genesis. У матеріалі на DOU він розповів про новий архітектурний патерн, що він розробив та запровадив на edtech-платформі Universe. Публікуємо стислий переказ найважливішого зі статті. Материал буде корисним усім, хто пише на React та хоче покращити свої продукти. > Модуль (Module) > Сервіси (Services) > Сховища (Stores) > Адаптери/Шлюзи (Adapters/Gateways) > Впровадження залежностей (Dependency Injection) > Use cases > Моделі (Models) > Утиліти (Utils) > Обробка помилок/винятків (Exceptions handling) Створений фахівцями з Universe архітектурний патерн зручно використовувати із будь-яким фреймворком для React: create-react-app, Next.js та іншими. Чим він корисний? По-перше, він дає змогу розгорнути залежності застосунку, при цьому бізнес-логіка відповідатиме за презентацію, а не навпаки. По-друге, він розділяє застосунок на незалежні модулі — таким чином більшість написаного коду може використовуватись повторно шляхом змішування модулів. Кожен модуль поділений на уніковані компоненти, тому є можливість писати тести лише для бізнес-логіки. Основна перевага модульності в тому, що вона дає можливість почати з малого і додавати нові складові поступово. З чого складається архітектура? Модуль (Module) Модуль — це основний блок, на якому будується система. Це незалежна одиниця, що містить певну інкапсульовану поведінку, але і може існувати без візуальної презентації. Це дозволяє нам розгорнути стандартні залежності застосунку та зробити так, щоби View не керував усім застосунком, а переорієнтовувався в залежності від необхідної поведінки. За замовчуванням, логіка знаходиться біля кожного модуля. Не всі модулі містять візуальну презентацію. Anonymous та Authenticated виконують логіку, але не відображаються в інтерфейсі. Тому застосунок залежить не від візуального шару, а від логічного. Базовий модуль складається з двох файлів: Index, Interactor. Якщо потрібна візуалізація — додаємо Router. У випадку, якщо візуалізація складна, додаємо один або декілька View. Стрілками позначені залежності між компонентами модулю. Interactor містить бізнес-логіку. Бажано, щоби він був ізольований від зовнішнього простору та отримував необхідні залежності через пропси. type Payload = { authenticationService : IAuthenticationService authenticationStore : IAuthenticationStore router : IRouter } interface IUserSignupByEmailInteractor { redirectToSignin : () => void passwordRecoveryUrl : string children : { signupByEmail : boolean signupByGoogle : boolean } } const useSignupPageInteractor = ({ authenticationService, router, authenticationStore }: Payload ): IUserSignupPageInteractor => { // logic implementation here return { redirectToSignin : () => router. redirect ( '/signin' ), passwordRecoveryUrl : '/password-recovery' , children : { signupByEmail : true , signupByGoogle : canUserSignupByGoogle, } } } Таким чином у нас є необхідне сховище та сервіс із пропсів. Спочатку позначаємо, які дочірні модулі може рендерити даний, а потім виконуємо перевірки та повертаємо бульові значення для кожного з дочірніх модулів. Рендер React-компонентів буде відбуватися в роутері. Router – це файл, який пов'язує бізнес-логіку та візуалізацію. Він отримує всі необхідні залежності через пропси та містить лише логіку перевірок if else, аби визначити чи потрібно рендерити той чи інший модуль. interface IProps { signupByEmail : React .ReactNode signupByGoogle : React .ReactNode interactor : IUserSignupByEmailInteractor } const SignupPageRouter : React .FC = ({ signupByEmail, signupByGoogle, interactor }) => ( <> {interactor.children.signupByEmail && signupByEmail} {interactor.children.signupByGoogle && signupByGoogle} </> ) View — файл, задача якого полягає в тому, щоби групувати різні dumb components. interface IProps { link : string } const ForgotPassword : React .FC = ({ link }) => ( А Index буде збирати необхідні залежності для Interactor і Router. У ньому ми викликаємо усі useContext, завантажуємо необхідні сервіси та сховища. const SignupByEmail = () => { con†st { authenticationService } = useServices () const { router } = useUtils () const { authenticationStore } = useStores () const interactor = useSignupByEmail ({ authenticationService, router, authenticationStore }) return ( } signupByGoogle={} interactor={interactor} /> ) } Index и Interactor — базові файли для побудови модуля. Інші – за необхідністю. Доки нам не потрібно розширювати систему, можна зберігати стан всередині модулів через useState. Для загальних даних можна створити базовий createContext. Сервіси (Services) Сервіс — це простий механізм формату «запит-відповідь». В окремі сервіси ми виносимо логіку отримання даних із зовнішніх джерел, якщо нам треба використовувати її в різних модулях. Сервіс може зберігати внутрішній стан, але лише той, який йому потрібен для виконання запитів. Які сервіси існують? Authentication — перевіряє вхідні дані користувача, дозволяє зареєструватися тощо. Analytics — збирає та надсилає аналітику. Payment — обробляє платежі. Застосунок з підключеними сервісами виглядає так: Сховища (Stores) В поданій архітектурі кожен модуль може зберігати дані всередині, але якщо треба отримати загальний стан, то ці дані краще виносити в сховища. Наприклад: Authentication — зберігає дані аутентифікації: token, refreshToken тощо. User — зберігає дані про користувача: ім’я, email та інші. Такий вигляд має застосунок зі сховищами: Адаптери/Шлюзи (Adapters/Gateways) Коли система розширюється, сервіси та сховища можуть використовувати адаптери. Наприклад, analytics service може використовувати лише Google Analytics для відправлення даних, проте пізніше можуть додатися Facebook Pixel, Amplitude, Mixpanel тощо. Не треба щоразу писати новий сервіс, достатньо лише передати необхідний адаптер у вже написаний. Так у сервісі з’являється нова залежність. Інтерфейс цього адаптера описується в сервісі, а реалізується вже зовнішніми адаптерами. Наприклад: export interface IAnalyticsAdapter { sendEvent : (eventName: string , eventData: unknown) => Promise } export class AnalyticsService { private adapter : IAnalyticsAdapter constructor (adapter: IAnalyticsAdapter) { this .adapter = adapter } // ... implementation } Далі робимо необхідні адаптери: class AnalyticsAdapter implements IAnalyticsAdapter { private adapters : IAnalyticsAdapter[] = [] constructor (adapters: IAnalyticsAdapter[]) { this .adapters = adapters } sendEvent : IAnalyticsAdapter[ 'sendEvent' ] = (eventName, eventData) => { this .adapters. forEach ((adapter) => adapter. sendEvent (eventName, eventData)) } } class GoogleAnalyticsAdapter implements IAnalyticsAdapter { sendEvent : IAnalyticsAdapter[ 'sendEvent' ] = (eventName, eventData) => { // google analytics implementation } } class FacebookPixelAdapter implements IAnalyticsAdapter { sendEvent : IAnalyticsAdapter[ 'sendEvent' ] = (eventName, eventData) => { // facebook pixel implementation } } export const analyticsAdapter = new AnalyticsAdapter ([ new GoogleAnalyticsAdapter (), new FacebookPixelAdapter (), ]) Та застосовуємо у сервісі: constanalyticsService = new AnalyticsService (analyticsAdapter) Наступним чином виглядають адаптери в застосунку: Впровадження залежностей (Dependency Injection) Аби пов'язати сервіси та сховища з модулями, використовуємо контексти React. interface IServices { authenticationService : IAuthenticationService analyticsService : IAnalyticsService } const ServicesContext = createContext ( null ) export const useServices = (): IServices => useContext(ServicesContext ) export const ServicesProvider : React .FC = ({ children }) => { // initialize services return ( {children} ) } В цій архітектурі сервіси та сховища – це класи, які не оновлюються при зміні стану. В такому випадку ми уникаємо будь-яких зайвих оновлень. Застосунок із впровадженням залежностей: Use cases Коли кількість модулів зростає, починає з'являтися загальна логіка. Її можна виносити в Use cases. Вони можуть використовувати і сервіси, і сховища через контексти. Також вони за замовчуванням не можуть використовуватися поза модулями, тому сервіси та сховища будуть завжди доступні. Вигляд застосунку із use cases: Моделі (Models) Якщо ми маємо об’єкти із зовнішніх джерел, які потрібно використовувати в декількох модулях, їх можна виділити в окрему сутність «Модель». Це дасть нам змогу валідувати дані, застосовувати до них загальну логіку та зберігати їх в одному місці. Застосунок із моделями: Утиліти (Utils) Це всі файли, які допомагають в розробці, та яким не потрібно мати доступ до зовнішніх джерел. Їх можна використовувати як в сервісах, так і в модулях. До прикладу, утиліти це: Token parsers. Date formatters. Device type detection. Обробка помилок/винятків (Exceptions handling) Всі помилки мають оброблятися винятково в модулях, тому що логіка обробки має знаходитись лише в одному місці. Для типування використовуємо тип Result, який повертається під час виклику методів у сервісах. export type Result = R | E Наприклад: class MyError1 extends Error {} class MyError2 extends Error {} // example-service.ts class ExampleService { example = (): Result < string , MyError1 | MyError2 > => { // implementation } } // example-module/interactor.ts const useExampleInteractor : React .FC = ({ exampleService }) => { useEffect (() => { exampleService. example () . then ((result) => { // typeof result = string | MyError1 | MyError 2 if (result instanceof MyError1 ) {} // typeof result = string | MyError2 if (result instanceof MyError2 ) {} // typeof result = string // do whatever you want with the pure result type }) }, []) return {} } Модулі — проміжна ланка між отриманням даних та їх зберіганням. В свою чергу use cases та утиліти використовують для спрощення цієї взаємодії. Розділення за зонами дає змогу зробити так, щоби кожна зона системи була відповідальна лише за одну задачу. Такий підхід до розробки дозволяє гнучко розширювати проєкт, залишаючи логіку інкапсульованою та зрозумілою.

Компанія SUITSME, що входить до екосистеми бізнесів Genesis, розвиває інтерактивну платформу для всіх, кого цікавить мода. У застосунку SUITSME кожен може поекспериментувати з одягом та аксесуарами від відомих брендів і стилізувати свого аватара для участі в різноманітних івентах. Усе це побудоване на основі 2D-графіки. Віталій Янчук, Unity-розробник і Tech Artist у SUITSME, в матеріалі для DOU розібрав базові методи розробки візуальних ефектів, теорію шейдерів, а також низку маніпуляцій із текстурами й кольором. Стаття буде корисною для VFX-художників-початківців, розробників усіх рівнів та інших спеціалістів, які цікавляться комп’ютерною графікою. Публікуємо стислий переказ матеріалу. З чого почати. Графічний конвеєр Маємо задачу — вдосконалити візуальний стиль продукту і створити кілька ефектів для тканин, які додали б шарму статичним речам. Так виглядає базовий ефект для тканини: А так — той самий ефект у готових образах: Спочатку всі дані й текстури проходять певний шлях перед тим, як опинитися в готовому вигляді на екрані: спочатку на процесорі комп’ютера (CPU), а потім на графічному процесорі (GPU). Ці етапи називають графічним конвеєром, або ж Graphics Pipeline. Спочатку геометрія, текстури й колір у загальному вигляді обробляються на рівні застосунку в CPU, за інструкціями, написаними C++ чи будь-якою іншою мовою. А далі — потрапляють до графічного процесора. Там спочатку обробляються вершини усіх геометричних фігур, а потім ця геометрія растеризується, тобто попіксельно зафарбовується. Растеризація та обробка геометрії відбуваються за шейдерним кодом, який зазвичай написаний на HLSL або Cg. GPU не дає змоги ефективно проводити складні логічні операції, проте здатний робити масивні паралельні розрахунки. Нижче розглянемо детальніше фрагментний шейдер. Саме на цій стадії прорахована вся геометрія, і маніпуляція з графікою відбувається лише на рівні текстур і кольорів. Текстурні координати. Створюємо форми та розташування Кожен піксель на текстурі має свої координати в UV-просторі (аналогічно до XY-координат) від 0 до 1 з кожної з координат в UnityEngine, починаючи з нижнього лівого кута. Додавання векторної константи до UV відповідає за зміщення текстури. Якщо додати до U-координати UV-простору величину, що дорівнює 0.5, текстура зміститься на половину своєї довжини вправо. Прив’язавши це до таймера, отримуємо латеральний рух текстури. Множення UV відповідає за масштабування текстури. Якщо помножити V на 2, текстура звузиться вдвічі по вертикалі й у той самий квадрат вміститься вже дві такі текстури. Додавання відповідає за зсув текстури, а множення — за деформацію. Розглянемо процес на прикладі ефекту, що імітує рефракцію від гарячого повітря. Він складається з двох шарів: зсув текстури шуму (додаємо векторну константу до UV-координат текстури шуму за таймером, у нас це вектор U=1 V=0 (1, 0), помножений на час одного кадру. Це означає, що текстура зміститься вправо на один період за одну секунду ігрового часу); додавання отриманого результату до UV-координат іншої текстури. Це має такий вигляд: Використана текстура не зовсім проста. Це процедурно згенерований градієнтний шум , тому при анімації чи зміщенні він не повторює себе й водночас не має швів. Якщо ж текстуру шуму розтягнути й дещо зменшити інтенсивність, отримаємо більш м’який ефект, що схожий на розвіювання тканини. Для розтягнення застосовуємо множення UV-координат. Ефект для тканини майже готовий, але треба подбати про деталі. Тканина — складний матеріал, і при утворенні на ній хвиль змінюється її освітленість. Кольорові координати Фрагментні шейдери також допомагають контролювати колір кожного пікселю, що видно на екрані. Майже кожен монітор комп’ютера показує колір у RGB-форматі — як комбінацію червоного, зеленого та синього різної яскравості. Тому й на графічному процесорі кожен піксель описується комбінацією трьох кольорів з яскравістю від 0 до 1. Базово додавання цих кольорів один до одного працює таким чином: В графіці використовуються різні режими змішування шарів, або ж Blend modes . Їх багато, проте всі вони містять хоча б одну з чотирьох базових операцій: додавання кольорів (режим змішування Add або Linear Dodge ) ARGB+BRGB — корисне для засвітлення без змін контрасту; віднімання кольорів (режим змішування Subtract ) ARGB-BRGB — корисне для затемнення з контрастом; множення кольорів (режим змішування Multiply ) ARGB*BRGB — корисне для затемнення без змін контрасту та маскування зображень; ділення кольорів (режим змішування Divide ) ARGB/BRGB — корисне для засвітлення з контрастом. Кілька прикладів однієї й тієї ж маски в різних режимах: Якщо комбінувати ці режими змішування, а також змінювати текстуру маски для кожного кольорового каналу, можна задати окреме значення яскравості та контрастності. Ми використали звичайний градієнт. Маскування також готують для альфа-каналу, змінюючи прозорість певних частин текстури, а не лише колір. Такі маски можна робити процедурними, анімувати й використовувати їх для чого завгодно. Ось що відбудеться, якщо застосувати анімовану маску до текстури із зірочками в режимі Multiply : Маска є текстурою, тому її також можна анімувати, деформувати й накладати на неї додаткові шари масок. Якщо маніпулювати лише кольором і застосовувати маски для кольорів, зображення набуває магічного вигляду: Повернемося до нашого ефекту розвіювання тканини: засвітимо ділянки на вершині хвилі; затемнимо ділянки внизу хвилі. Це допоможе спрощено передати світло і тінь. Для більш коректного зображення варто змінювати освітленість не від висоти хвилі, а від кута нахилу поверхні хвилі. А якщо мова про кут нахилу, то це — математична похідна. Тож якщо ми продиференціюємо текстуру за координатою U (ddx), то отримаємо більш фізично коректну картину зміни освітленості поверхні. Згори — маска для засвітлення, знизу — маска для затемнення. Потрібно намагатись робити ефект так, щоб він не виходив з контексту, відповідав стилю і був доцільним. Отже, зміна текстурних координат дає змогу досягати різноманітних процедурних форм або деформацій текстури, а зміна кольорових координат — індивідуально визначати інтенсивність кожної кольорової складової текстури. Якщо це поєднати, отримаємо повну владу над формою і кольором. Кожен шейдерний ефект у 2D можна розглянути як текстуру, що є результатом поєднання інших текстур за певною логікою. Тому можна нескінченно накладати ці текстури одна на одну, створюючи ще більше унікальних поєднань.

Свій 31-й День Незалежності ми зустрічаємо у суворі часи, проте ми віримо у краще майбутнє, працюємо для своєї країни та не здаємося. Генезійці та колеги із партнерських компаній — від операційного директора до трейні — розповіли про своє відчуття незалежності та бачення майбутнього нашої країни. Genesis вітає всіх зі святом! Артем Копанєв, СОО Genesis Як би ви описали Україну іноземцю, який ніколи про неї не чув? Україна — це країна сміливих людей та небачених можливостей, в якій свобода усіх рівнів — це вибір кожного. Це країна підприємців, які ставлять амбітні цілі, досягають їх та вражають світ своєю стійкістю. Що для вас означає незалежність? Незалежність для мене — це свобода обирати. Обирати шлях розвитку своєї країни, спільноти та себе особисто. Зі свободою приходить і відповідальність, тож це водночас і привілей, і обов’язок. З відповідальності кожного з нас, вчинків (а разом з тим і бездіяльності подекуди) і складається той історичний шлях, яким ми крокуємо. Тож кожен вчинок, кожне слово має значення, важливо про це пам’ятати. Особливо зараз, коли ми виборюємо нашу свободу. Помріємо. Україна у 2032 році. Яка вона? Я особисто вірю в незалежну та сильну Україну — і в 2022, і в 2032, і багато років наперед. Це буде одна з найуспішніших країн світу з високими економічними темпами зростання та громадянським суспільством. Таким, яке зі свого досвіду знає ціну свободи і як її виборювати. Нашими локомотивами та драйверами розвитку, найімовірніше, будуть IT, агросектор і, сподіваюсь, туризм та послуги. Ми обов’язково станемо провідним хабом Східної Європи для комфортного ведення бізнесу. Андрій Боднар, iOS Developer в OBRIO Як би ви описали Україну іноземцю, який ніколи про неї не чув? Україна — це люди. Вони не «розкидаються» усмішками, але радо дарують їх тим, кому готові довіряти. Це люди, що з будь-якої події можуть зробити мем, мерч або марку. Люди, що подарували світу гелікоптер, жорсткий диск та борщ. Що для вас означає незалежність? Як на мене це слово, яке описує само себе. Неможливо підібрати такі слова, що опишуть незалежність краще, ніж вона сама це зробить. Помріємо. Україна у 2032 році. Яка вона? Україна у 2032 році — це не про мрії. Вона буде саме такою, якою ми її зробимо власними руками. Ми можемо надихатись результатами інших країн, частково переймати їх досвід. Але справжній результат залежить від тих самих людей, які і є Україна. Віра Бігановська, Junior Graphic Brand Designer в Universe Як би ви описали Україну іноземцю, який ніколи про неї не чув? Це країна, де живуть люди, для яких немає безвихідних ситуацій. Вони неймовірно працьовиті та кмітливі, зараз серед цих якостей так ясно проявилася ще й волелюбність, яку ні з чим не сплутаєш. Вони вміють зупиняти танки голими голими руками та збивати ворожі дрони банками із томатами. Що для вас означає незалежність? Незалежність — це можливість створювати свої правила на своїй землі разом з людьми, яких об’єднує спільна культура та національна ідентичність. Але в той же час, незалежність — це велика відповідальність, Аби її зберегти, потрібно прикласти чимало зусиль. Помріємо. Україна у 2032 році. Яка вона? Якщо уявити ідеальний світ, то в 2023 році мені б хотілося насамперед бачити Україну повністю звільненою від окупантів та відбудованою. А її громадян — більш свідомими, тобто такими, які винесли всі уроки з цієї війни та зробили правильні висновки. Соломія Яськів, PR-менеджерка PlantIn Як би ви описали Україну іноземцю, який ніколи про неї не чув? Абсолютно вільна, стильна і прогресивна країна. Держава, яка історично мусила відстоювати своє право на незалежність і внаслідок цього стала революційною моделлю для інших країн. А ще — в Україні просто неймовірно мальовнича природа і класні урбаністичні рішення. Що для вас означає незалежність? Це вміння приймати рішення самостійно і нести відповідальність за наслідки цих рішень. Вміння слухати та дослухатися, якщо це відповідає особистим переконанням. Незалежність — це демонстрація того, на що ми здатні. Помріємо. Україна у 2032 році. Яка вона? Самостійна в усіх планах. ІТ-колиска Східної Європи, мистецький центр і туристичний вибір континенту. Країна, де більшість бюрократичних рішень — диджиталізовані, вітчизняні бренди — за доступними цінами, корупція відсутня як явище і лишилась тільки и в розповідях старших поколінь. Денис Попов, Manual QA Engineer в AMO Як би ви описали Україну іноземцю, який ніколи про неї не чув? Це країна, в якій живуть вільні та сміливі люди. В Україні захоплююча природа, найсмачніша їжа, найкращий сервіс і цифрові державні послуги. Але найголовніше — це сильні, відкриті, добрі, талановиті і різні, водночас єдині люди. Що для вас означає незалежність? Для мене незалежність означає мати можливість мені і державі робити свій вибір — із ким дружити, які цінності сповідувати та як жити. Але також це велика відповідальність: кожен із нас повинен поважати один одного, робити усе можливе для захисту і розвитку нашої держави і зберегти усе, що ми здобули, для майбутніх поколінь. Помріємо. Україна у 2032 році. Яка вона? Сильна і квітуча країна, котру всі поважають. Економічний і культурний центр Європи. Ми маємо свою silicon valley, де народились як мінімум із десяток українських «єдинорогів», до України кожен рік приїжджають мільйони туристів, проводяться найкращі фестивалі світу, а українці — назавжди щаслива нація. Анастасія Микитенко, SMM-фахівчиня в Head Office Genesis Як би ви описали Україну іноземцю, який ніколи про неї не чув? Це країна вільних, сміливих, запальних, талановитих та безмежно різних людей. Вони не ідеальні, у них багато роботи над собою та країною, але в них багато віри і бажання жити краще, тому вони відбудуються і створять щось неймовірне. Уже створюють. Що для вас означає незалежність? Незалежність – це можливість та обов’язок будувати, згадувати та зберігати своє. І не можна очікувати, що усе зробить влада. Кожен має самостійно докладати зусиль, бути включеним, кричати, коли щось йде неправильно. Країна без своїх свідомих людей навряд чи залишиться незалежною надовго. Помріємо. Україна у 2032 році. Яка вона? Вона вільна від російських впливів, у ній пам’ятають та поважають свою культуру. Вона приймає людей різними і створює для них рівні можливості. Ми без корупції, з якісною освітою, гідно оплачуваною медициною та бізнесами, які впевнено почуваються. Олексій Єрмоленко, Strategy and Investments Associate у венчурному фонді Flyer One Ventures Як би ви описали Україну іноземцю, який ніколи про неї не чув? Це досить колоритна країна зі своєю автентичною культурою та дуже доброзичливими та привітними людьми. Проте ці люди пройшли через низку випробувань, тому вони досить сильні та самодостатні, вони не втрачають оптимізму. А ще це дуже різна, велика та родюча країна, в якій є і степи, і гори, і море, — багато чого є. Що для вас означає незалежність? Основне слово, яке в мене асоціюється зі словом незалежність – це самодостатність. Це свобода вибору, яким шляхом іти та яке життя жити. Я думаю, що це є і привілеєм, і обов’язком. З одного боку, можна самостійно ухвалювати рішення і мати контроль над своїм життям. З іншого боку, це тягар за рішення, які ми ухвалюємо, та наслідки, які приходять після того, як ці рішення виконують. Помріємо. Україна у 2032 році. Яка вона? Це фундаментально сильна країна з національними інститутами, які розвинені на рівні провідних країн у світі, тобто і відсутність корупції, і главенство права, і дуже високий рівень освіті, і сильна економіка. З іншого боку, хотілося б утримати свою самодостатність та незалежність. Я сподіваюся, що громадяни зможуть вирішувати, куди далі рухатися, та будувати своє майбутнє так, як ми його вирішимо. Будувати без натиску будь-якої зі сторін. Я сподіваюся, що з цієї жахливої ситуації ми вийдемо сильніші — як і держава, і як нація, і як кожен громадянин. Уляна Олійник, Creative Writer в Headway, партнерській компанії Genesis Як би ви описали Україну іноземцю, який ніколи про неї не чув? Здається, тепер уже нема іноземців, які не чули про Україну. Та я б описала або «603 700 км², які обов’язково треба побачити на власні очі та дослідити», або «місце народження і становлення спраглих до життя та свободи людей». Що для вас означає незалежність? Незалежність — це про сміливість, відповідальність, свободу, прийняття і боротьбу водночас. Як на рівні країни, так і на рівні людини. Для мене це не про обмеження та підлаштування під наявні рамки, а про взяття відповідальності за своє життя, створення власних візій та принципів і їх обстоювання. Помріємо. Україна у 2032 році. Яка вона? Перше, що спадає на думку, це вільна. А ще відбудована. Зміцніла. Щаслива. Наповнена людьми, ресурсами, результатами. У балансі з природою. Розвинута. Марина Мазур, Product Manager в SUITSME Як би ви описали Україну іноземцю, який ніколи про неї не чув? Наша країна настільки різноманітна та цікава, що опис був би довгенький. Україна — величезна, крута і сучасна. Гори? Є. Море? Є. Старовинні палаци? Є. Сучасні міста? Є. Тут є усе, чого лише можна забажати. Технологічна і автентична, динамічна і спокійна… Україна може бути будь-якою — усе залежить від обраного ракурсу. Що для вас означає незалежність? Для мене незалежність — це можливість робити вибір, яким буде моє завтра, та нести відповідальність за свої рішення. Для країни справжня незалежність — це можливість будувати власне майбутнє і передавати усе найкраще як спадщину. Відповідно, головним обов’язком стає потреба боронити це право та передавати його як настанову з покоління у покоління. Помріємо. Україна у 2032 році. Яка вона? Насамперед хотіла б бачити її мирною та відновленою. Українська технологічна індустрія у самому розквіті, і ми тепер не лише потужна аграрна держава. Переосмислення власної культурної спадщини та зближення з нею дали шалений поштовх культурі сучасній, і тепер весь світ знає українських митців. Через інтеграцію зі світом наша туристична індустрія квітне, а кожен блогер мріє зробити фото на березі Лемурійського озера або на Карпатській вершині. Галина Міськів, Marketing manager в Jiji, партнерській компанії Genesis Як би ви описали Україну іноземцю, який ніколи про неї не чув? Україна — дійсно прекрасна країна, у котрій живе безліч відкритих, вільних і свідомих людей. З маленькими ресурсами ці люди здатні робити великі речі, бо роблять їх з любов’ю. Україна для мене — це про найкращі якості, котрі можуть в нас бути. Це про душевне тепло, відкритість, щирість, щедрість, про красу та ще багато чого. Україна — це про любов. Що для вас означає незалежність? Незалежність — це про бажання мати і розвивати власні опори, власні ресурси, розвивати себе. Як на мене, це стосується як держави, так і людини особисто. Таких собі макро- та мікрокосмів. Проте Незалежність нашого макрокосму, Держави, будується з розвитку нас самих, мікрокосмів. Тому нам треба прагнути до своєї власної Незалежності. А для цього брати на себе відповідальність і жити свідомо. Як мінімум, ми отримаємо Державу з внутрішньо вільною та проактивною нацією. А як максимум… Помріємо. Україна у 2032 році. Яка вона? Я вірю в те, що це буде країна майбутнього. Багато процесів буде реорганізовано і оптимізовано. Масова диджиталізація. Наплив іноземних бізнесів, котрих будуть приваблювати низькі податкові ставки. Розквітне іноземний туризм, буде реалізовано безліч ініціатив з підтримки населення та Збройних Сил України. Це буде нова глава Новітньої історії України. України, котра відстояла себе і пірнула у стрімкий розвиток.

Мова SQL — невіддільний інструмент при роботі з даними. Аналітики, тестувальники, продакт-менеджери послуговуються нею для зберігання, зміни та обробки великих масивів інформації. У статті для DOU дата-аналітик компанії Holy Water з екосистеми Genesis Андрій Ніколаєнко розповів про базові навички написання SQL-скриптів для отримання вибірок. Матеріал буде корисний фахівцям із початковим рівнем володіння SQL. Публікуємо короткий переказ для читачів блогу. Відбір, сортування та ліміти Як отримувати вибірки з декількох джерел даних, застосовуючи необхідні в конкретній ситуації обмеження? Розглянемо процес на прикладі таблиці users. Вона знаходиться у схемі (папці) product та містить дані про реєстрацію користувачів. В результаті маємо таку таблицю: reg_dt id gender age country_code app 2014-01-02 17:30:21 4446022755 f 37 US desktop 2014-01-02 21:07:08 4446556074 f 40 CH android 2014-01-14 21:07:15 4481548107 m 40 GE mobile 2013-12-30 8:33:09 4436447691 m 49 US mobile 2013-12-30 11:04:15 4436702697 m 61 CH desktop Ті ж дані, що відсортовані за віком та кодом країни: SELECT reg_dt, id, gender, age, country_code, app FROM product.users ORDER BY age DESC , country_code Команда ORDER BY відсортує поле за зростанням, а команда DESC — за зниженням. Аби вибрати всі поля, треба вказати * замість назв колонок SELECT * FROM product.users . Формування запиту, використання логічних операторів та умови WHERE Припустимо, нам треба відсортувати жінок-користувачок віком старше 45 років. SELECT reg_dt, id, gender, age, country_code, app FROM product.users WHERE gender = 'f' AND age > 45 – вказуємо умови для полів, що виводяться. ORDER BY age DESC , country_code column1 column2 1 text В умові WHERE можна використовувати велику кількість критеріїв, які пов'язані логічними операторами AND та OR . При використанні OR («або») будьте обережні й ставте дужки, щоб альтернативи були чітко окреслені. В SQL можна використовувати перенесення рядків та відступи для форматування, вони не впливають на виконання запиту. Коли ми виконали запит, отримаємо список користувачів. Деякі з них зареєстровані поза межами часового діапазону, який ми виділили — 2012–2014 рр. reg_dt gender age site 2012-08-01 0:43:09 m 34 ametconsectetur.us 2014-02-02 0:49:19 f 28 abcdefghij.com 2018-04-02 4:07:42 f 55 loremipsum.com 2021-05-08 12:00:02 m 48 ametconsectetur.com Так виходить, тому що умова OR , вказана в кінці, скасовує всі попередні умови, що пов'язані оператором AND . Цю умову інтерпретуємо як «дайте вказані поля для користувачів, які зареєстровані у вказану дату та мають домен .us або просто домен .com (без умов по даті)». Так відбувається через те, що AND виконується раніше, ніж OR . Якщо потрібно, щоби умова дати зберігалась для обох доменів, треба чітко виділити альтернативи для оператора OR за допомогою круглих дужок: WHERE reg_dt BETWEEN '2012-01-01' AND '2015-01-01' AND (site LIKE '%.us' OR site LIKE '%.com' ) reg_dt gender age site 2012-08-01 0:43:09 m 34 ametconsectetur.us 2014-02-02 0:49:19 f 28 abcdefghij.com Умову можна сформулювати і як результат перетворень: SELECT age, site, LENGTH (site) FROM product.users WHERE age% 2 != 0 OR LENGTH(site) > 17 Об’єднуємо вибірки Зазвичай для вибірок використовують більше одного джерела. У запропонованій схемі є таблиця з реєстраціями (1), таблиця із замовленнями (2), і таблиця для розшифрування типів сервісів (3). (1) reg_dt id gender age country_code ... 2014-01-02 17:30:21 4446022755 f 37 US ... 2014-01-02 21:07:08 4446556074 f 40 CH ... 2014-01-14 21:07:15 4481548107 m 40 GE ... 2013-12-30 8:33:09 4436447691 m 49 US ​ ... ... ... ... ... ... ... ​ ​ ​ ​ ​ ​ (2) user_id dt order_id service_id ... 4446022755 2014-01-02 18:30:01 2435206 14 ... 4446022755 2014-02-02 18:25:17 2437018 14 ... 4481548107 2014-01-14 21:08:45 2455378 18 ... 4481548107 2014-04-11 15:11:18 2460491 14 ... 4481548107 2014-04-13 12:10:09 2460602 5 ... ... ... ... ... ... (3) id service_name 5 test_srv 9 vip 14 month 18 90 day ... ... Аби отримати дані із додаткових таблиць, використовуємо LEFT JOIN . Наша вихідна таблиця знаходиться зліва, і ми ніби додаємо до неї відповідні рядки з таблиці замовлень. Для поля gender ми використали аліас u.gender AS sex . Для цього можна використовувати слово AS або написати аліас через пробіл. Аліаси можна застосовувати й до назв таблиць із тим самим синтаксисом (з AS або без нього). Виконавши запит, ми отримали таку таблицю: reg_dt sex age id user_id order_id order_dt service_id id service_name 2014-01-14 21:07:15 m 37 4481548107 4481548107 2460602 2014-04-13 12:10:09 9 9 vip 2014-01-14 21:07:15 m 37 4481548107 4481548107 2460491 2014-04-11 15:11:18 14 14 month 2014-01-14 21:07:15 m 37 4481548107 4481548107 2455378 2014-01-14 21:08:45 18 18 90 day 2014-01-02 21:07:08 f 37 4446556074 NULL NULL NULL NULL NULL NULL 2014-01-02 17:30:21 f 37 4446022755 4446022755 2435206 2014-01-02 18:30:01 14 14 month 2014-01-02 17:30:21 f 37 4446022755 4446022755 2437018 2014-02-02 18:25:17 14 14 month 2013-12-30 11:04:15 m 37 4436702697 NULL NULL NULL NULL NULL NULL 2013-12-30 8:33:09 m 37 4436447691 NULL NULL NULL NULL NULL NULL Користувачі, які здійснили декілька покупок, продублювалися в таблиці. А для користувачів, у яких немає оплат, застосували значення NULL. Далі ми працюємо з отриманим набором даних за тим же принципом, як раніше працювали з однією таблицею — обираємо поля, які нас цікавлять, фільтруємо і сортуємо. Чим відрізняються умови в WHERE та LEFT JOIN Умова у LEFT JOIN впливає лише на поля з таблиці, яку ми доєднуємо: SELECT u.id, op.service_id, op.user_id FROM product.users u LEFT JOIN product.orders_paid op ON u.id = op.user_id AND op.service_id = 14 id service_id user_id 4446022755 14 4446022755 4446022755 14 4446022755 4481548107 14 4481548107 4436702697 NULL NULL 4436447691 NULL NULL 4446556074 NULL NULL Спочатку ми відфільтрували таблицю orders_paid , і залишились лише всі замовлення сервісу №14. Потім — об'єднали їх, і отримали з users усіх зареєстрованих користувачів. Для тих, у кого є замовлення сервісу №14, вивели окремі рядки з таблиці замовлень, для всіх інших користувачів — NULL . Коли умова — у WHERE , вона фільтрує вибірку вже після об'єднання таблиць. До фільтрації: SELECT u.id, op.service_id, op.user_id FROM product.users u LEFT JOIN product.orders_paid op ON u.id = op.user_id id service_id user_id 4446022755 14 4446022755 4446022755 14 4446022755 4436702697 NULL NULL 4446556074 NULL NULL 4436447691 NULL NULL 4481548107 14 4481548107 4481548107 9 4481548107 4481548107 18 4481548107 Після фільтрації: SELECT u.id, op.service_id, op.user_id FROM product.users u LEFT JOIN product.orders_paid op ON u.id = op.user_id WHERE op.service_id = 14 id service_id user_id 4446022755 14 4446022755 4446022755 14 4446022755 4481548107 14 4481548107 Одну і ту ж таблицю ми можемо доєднати декілька разів, або доєднати саму до себе. У нашій таблиці із замовленнями є поле parent_order_id . Воно позначає замовлення, яке ініціювало підписку користувача. Таким чином перші платежі й подовження підписок зберігаються в одній таблиці, і ми пов’язуємо таблицю orders_paid саму із собою за ідентифікатором parent-платежу. Також можемо доєднати таблицю-довідник із типами сервісів. Використовуємо INNER JOIN для зв'язку з orders_paid , аби залишились тільки користувачі із замовленнями. SELECT u.id, opp.order_id parent_order, opp.dt AS parent_dt, op.order_id, op.dt AS order_dt, ps.service_name FROM product.users u INNER JOIN product.orders_paid op ON u.id = op.user_id LEFT JOIN product.orders_paid opp ON op.parent_order_id = opp.order_id LEFT JOIN product.pay_services ps ON ps.id = op.service_id ORDER BY op.order_id id parent_order parent_dt order_id order_dt service_name 4446022755 2435206 2014-01-02 18:30:01 2435206 2014-01-02 18:30:01 month 4446022755 2435206 2014-01-02 18:30:01 2437018 2014-02-02 18:25:17 month 4481548107 2455378 2014-01-14 21:08:45 2455378 2014-01-14 21:08:45 90 day 4481548107 2460491 2014-04-11 15:11:18 2460491 2014-04-11 15:11:18 month 4481548107 NULL NULL 2460602 2014-04-13 12:10:09 vip Тут бачимо, що для платежу, що ініціює підписку, parent_order = order_id . А сервіс vip не має parent_order , оскільки це інший тип сервісу. Таким чином parent_dt — це дата початку підписки, а order_dt — дата конкретного платежу. Детальніше про типи зв'язків та агрегатні функції в SQL ви можете дізнатися в оригінальному матеріалі на DOU .

Чи справді бекенд є найскладнішим типом розробки, що робити з рутиною, що не можуть поділити розробники бекенду та фронтенду та як експериментувати на проєкті, щоб не створити «зоопарк технологій»? Ігор Чорний, Back-end Developer в Boosters, розповів про найпоширеніші міфи, які існують серед спеціалістів цієї сфери. > Міф №1. Бекенд — найскладніший тип розробки . > Міф №2. Keep calm and blame front-end. > Міф №3. Бекенд — рутинна одноманітна робота з фреймворками . > Міф №4. Розробник пише код щодня . > Міф №5. Бекенд-розробник не має вивчати фронтенд . МІФ №1 Бекенд — найскладніший тип розробки. Є хибна думка, що якщо розробник від початку вивчав бекенд, йому буде потім легко вивчити фронтенд. І навпаки: якщо починав із фронтенду, опанувати бекенд вже буде занадто складно, адже це ніби зовсім інший рівень розробки. Так само вважається, що зарплати в бекенді вищі. Це неправда. По-перше, у фронтенді є чимало інструментів, що виконують функції бекенду, наприклад, Node.js. По-друге, складність того чи іншого типу розробки сильно залежить від проєкту. Наприклад, у фінтех-компаній, робота яких ґрунтується на безпеці, справді є потужні команди бекенду зі складними завданнями та високими зарплатами. Але існують проєкти, де фронтендери отримують більші офери за бекендські. Все залежить від навичок та досвіду. У цілому фронтендер так само може вивчити технології бекенду та стати фулстек. МІФ №2 Keep calm and blame front-end. Взагалі стосунки між спеціалістами фронтенду та бекенду овіяні міфами та мемами. Начебто вони конфліктують, перекладають відповідальність та не розуміють один одного. Насправді більшість команд фронтенд та бекенд регулярно комунікують та працюють в синергії. Щоправда, пошук, на чиїй стороні баг, дійсно є каменем спотикання. Як це відбувається: фронтенд та бекенд закінчують свої частини роботи та віддають тестувальнику, який знаходить баг. Чий він? Традиційно починається «пінг-понг»: це на стороні бекенду, ні це на стороні фронтенду… Але проблему треба вирішувати, баги виправляти, і чим краще влаштована комунікація між різними частинами розробки, тим швидше все налагодиться. Це раніше були бородаті програмісти, які весь день сиділи за компʼютером, і ніхто їх не чіпав. Зараз всюди фокус на софт-скіли. Комунікабельність, відкритість та вміння працювати в команді цікавлять топменеджмент навіть більше, ніж хард-скіли. Спілкування із продакт-менеджером, фронтендом, саппортом — це мінімум для розробника. І часто простою комунікацією можна вирішити дуже багато проблем, знайти рішення та отримати ще більший профіт. МІФ №3 Бекенд — рутинна одноманітна робота з фреймворками. Так, бекенд-розробники нерідко використовують фреймворки, які полегшують роботу. Але дуже часто бувають завдання, які неможливо виконати з допомогою готових рішень, просто тому, що ніхто ще такого не робив. Наприклад, таким завданням було створення алгоритму з визначення якості сну на основі методу когнітивно-поведінкової терапії для застосунку Avrora компанії Boosters. Написати та імплементувати унікальний алгоритм та базу даних під нього, спроєктувати, як все це буде працювати на десятках, сотнях і тисячах користувачів, а також подбати про можливість щось змінювати в ньому та масштабувати надалі — це і є той випадок, коли у вакансії пишуть «ми пропонуємо цікаві нестандартні задачі». Подібні завдання — певний виклик: спершу не уявляєш, як її виконати, а потім знаходиш рішення і отримуєш справжнє задоволення. Вони насправді допомагають не вигоряти та розвивають розробників. Тому тип завдань для бекенду залежить від проєкту, планів та амбіцій розробника. Десь працюють із фреймворками, десь пишуть з нуля. Хтось шукає цікаве, іншим підходить рутинне. Треті набивають руку та здобувають скіли, тому їм потрібен зовсім інший тип проєкту. МІФ №4 Розробник пише код щодня. Принцип «жодного дня без рядка» у сучасній команді розробки звучить як утопія. Адже є ще планування завдань по Jira, Trello, грумінги (наведення порядку в задачках), мітинги, обговорення, ретроспективи, зустрічі із менеджерами. Ще бекенд часто займається саппортом — коли треба розібратися з проблемою, залізти в логи, покопатися в аналітиках, моніторингах. Це може займати від декількох годин до декількох днів. Бекенд-девелопер може ще займатися DevOps, тоді до його повсякденних завдань додається адміністрування, проєктування, тестування. Якщо ж перед розробником стоїть складне завдання, йому потрібен час, щоб обдумати, у який спосіб це можна спроєктувати. МІФ №5 Бекенд-розробник не має вивчати фронтенд. Раніше не було жорсткого розділення на фронтенд та бекенд. Тоді були просто девелопери: «знаєш PHP — молодець, зроби нам ще адмінку». Згодом задачі почали ускладнюватися, зʼявилися окремі напрями розробки — бекенд і фронтенд. Часом бекенд-розробники, які щойно закінчили курси, не бачать повного горизонту завдань, з якими доведеться стикатися, та відмовляються виконувати дрібні завдання з фронтенду: «зверстати вам сторінку з Privacy Policy? Камон, я ж бекендщик». В їхньому розумінні, це якась інша спеціалізація, не варта уваги. Вони бояться розпилятися та прагнуть розвиватися тільки у своїй ніші. У сфері бекенду є майже бездонні джерела інформації, статей, підходів, які можна вивчати у вільний час та професійно зростати. Дійшовши до сеньойра, можна заглиблюватися в архітектуру, стати техлідом або менеджером. Але як би бекенд-розробник не заперечував цього на початку карʼєри, з роками виявиться, що він все ж таки знає фронтенд. Знання деяких рішень та фреймворків з фронтенду може справді полегшити життя розробнику. Десять років тому Javascript був ніби темним виром — в ньому було страшно, незручно, панував хаос та шостий Internet Explorer. Але зараз є безліч фреймворків, вартих уваги бекендера — Vue.js, React, Node.js, адже вони зручні та стабільні. Загалом розробник має навчатися безперервно, і для цього є безліч можливостей. МІФ №6 Проєкти обмежують простір для експериментів. Якщо бекенд-розробник багато років працює в одній компанії, це зовсім не означає, що всі ці роки він використовує обмежений набір фреймворків та технологій, а єдиний простір для експериментів — пет-проєкти. В компаніях з екосистеми Genesis менеджмент не втручається в розробку, а CTO не обмежує команду у підходах. Якщо розробник прийшов не проєкт не вчора, а добре себе зарекомендував, потестив і перевірив технологію та пояснив її переваги, з великою ймовірністю йому дадуть зелене світло. Якщо, наприклад, перехід на Golang покращить продукт — чому б ні? З іншого боку, буває, що людина запустила сервіс з MongoDB базою даних і за кілька місяців звільнилася, а в команді дивляться продакшн-конфігурацію, та ніхто не знає, як отримати до неї доступ. Усіма новими технологіями має хтось опікуватись та відповідати за них. Це як підтримувати великий автопарк. У великих проєктах зазвичай трапляється зоопарк технологій, сервісів, серверів, які тягнуть за собою великі витрати на інфраструктуру. Але якщо в команді є адекватний менеджмент, час та ресурси на реалізацію і підтримку — це нормально.

Що таке DevOps, та хто його створив, хто такий DevOps Engineer, якими навичками він має володіти. Якому бізнесу підходить цей метод та які інструменти краще обрати. А також чому DevOps певною мірою є в кожній компанії, але в чистому вигляді не імплементований майже в жодній. Олег Лавренко, Head of Engineering Department компанії AMO, розповів про найпоширеніші міфи, які існують серед спеціалістів цієї сфери. AMO — міжнародна IT-компанія, яка створює продукти й історії для мільйонів користувачів. Має три великі підрозділи: AMO Publishing, AMO Pictures та AMO Apps. > Міф №1. DevOps — це людина або команда . > Міф №2. DevOps Шредінгера . > Міф №3. DevOps зʼявився 2009 року і вже втрачає актуальність . > Міф №4. DevOps більше підходить стартапам . > Міф №5. Щоб стати DevOps Engineer, треба опанувати чимало інструментів та технологій . > Міф №6. DevOps починається з С-level . > Міф №7. DevOps — змова тестувальників проти розробників . Міф №1 DevOps — це людина або команда. Насправді це методологія розробки, яка передбачає тісну колаборацію програмістів, тестувальників та команди так званих операцій — людей, відповідальних за роботу сервісів. Практики DevOps можуть використовуватися в компанії, де немає окремої команди чи DevOps Engineer. Міф №2 DevOps Шредінгера. Досить складно знайти компанію, в якій повністю інтегрована чиста культура DevOps в тому вигляді, як вона описується. Повна імплементація цієї методології передбачає, що межа між розробкою, операціями та тестуванням сильно розмивається. Але в компаніях зазвичай такого немає. Розробник все одно пише код і не відповідає за те, як цей код працює. Тестувальники перевіряють цей код та шукають баги, але не відповідають за те, як він написаний. Так само й команда інфраструктури (або operations team) — відповідає за життєздатність сервісу, але не за його написання та тестування. Наприклад, запустили сервіс і слідкують, щоб він стабільно працював. А якщо щось йде не так, використовують різні техніки rollback — все це типовий помилковий підхід компаній, який важко назвати DevOps. Проблема полягає в тому, що більшість компаній просто перейменували системних адміністраторів на DevOps-інженерів, додали їм пару популярних інструментів, але в цілому працюють, як раніше. Тому ідея повної імплементації DevOps — дещо утопічна: цього усі прагнуть, але в чистому вигляді її ніхто ніколи не бачив. Міф №3 DevOps зʼявився 2009 року і вже втрачає актуальність. 2009 року цей термін вперше пролунав на конференції розробників «DevOps Days» у Бельгії. Але не можна сказати, що цього методу раніше не існувало. Адже завжди була автоматизація, поняття життєвого циклу програмного забезпечення, яке полягало у тих самих етапах. У доповіді лише зібрали найкращі практики з різних компаній, знайшли у них спільні риси та назвали це DevOps (від англ. development & operations). Насправді ж DevOps існував у певній формі ще задовго до компʼютерів — можна провести грубу аналогію зі створенням Генрі Фордом першого конвеєра у 1913. Адже DevOps — це своєрідний конвеєр в ІТ. Концепції змінюються не так швидко, як мода на технології, тому цілком можливо, що ця методологія буде актуальною і протягом наступних 100 років. Міф №4 DevOps більше підходить стартапам. В стартапах важливо швидко перевіряти гіпотези, динамічно змінюватися та шукати своє місце на ринку. Може статися таке явище, як півот, коли компанія кардинально змінює бізнес-модель. Наприклад, Slack, чиї творці задумали створити компʼютерну гру, але зрештою вийшов корпоративний месенджер. Стартапам не варто фокусуватися на процесах та автоматизації. Хаос — це одна з умов виживання стартапів. Коли бізнес вже стоятиме на ногах, почне уповільнювати розробку, зʼявиться потреба зробити її стабільною і рівною, компанії допоможе DevOps. Як мінімум на примітивному рівні ця методологія може бути інтегрована у всіх ІТ-компаніях. У гігантських компаніях масштабу Oracle вже не настільки звертають увагу на швидкість розробки та delivery. Їхня ставка — на маркетинг та роботу з клієнтами, тому вони можуть рідше випускати фічі, але гарантують стабільність експлуатації. Однак практиками DevOps вони також користуються. Також ця методологія може застосовуватися в дуже несподіваних галузях. В тому числі в компаніях, де бізнес-процес лежить поза віртуальними сервісами, а ІТ використовується, як допоміжний засіб. Міф №5 Щоб стати DevOps Engineer, треба опанувати чимало інструментів та технологій. Обговорення DevOps серед спеціалістів часто зводиться до того, який інструмент обрати — Jenkins, Kubernetes, GitHub Actions тощо. Однак в книзі « Проєкт Фенікс » , яку вважають біблією DevOps, немає жодного слова про технології, жодної згадки про інструменти та сервіси. Адже суть методу базується на комунікації та взаємодії між спеціалістами, а не на виборі інструментів. Більш того, з наростанням популярності цього методу усі компанії, які розробляють подібний софт, почали ставити лейбл «DevOps». Це робили навіть бази даних, випущені задовго до тієї самої конференції та повʼязані з цією методологією досить опосередковано. Більшість інструментів, які вважаються зараз трендовими та викладаються на курсах з DevOps, насправді створювалися для розв'язання окремих проблем експлуатації чи розробки. Наприклад, контейнери та Kubernetes — система управління цими контейнерами. Якщо завтра скажуть, що відтепер DevOps — це, приміром, лямбда-функції, такі актуальні зараз Kubernetes та Jenkins сприйматимуться як легасі, з яким неприємно працювати. Тому DevOps — це не про інструменти. Цю методологію можна імплементувати й на класичних кластерах віртуальних машин, які були популярними задовго до контейнерів, — будувати автоматизацію, CI\CD, динамічно масштабувати свою інфраструктуру. Загалом стандартів цієї професії не існує, а навички сильно варіюються від проєкту до проєкту. Спільна вимога до всіх DevOps, незалежно від того, з якою технологією вони працюють — це вміння будувати якісну комунікацію, автоматизувати рутинні задачі та процеси, знаходити рішення та постійно навчатися. Знайти спеціаліста, який добре розуміє базові концепції та має відповідні софт-скіли, значно складніше, ніж того, хто закриє питання по технології. В AMO є чітка стратегія, щодо технологій: тут будують cloud-native продукти, тому використовують багато інструментів, що входять до Landscape CNCF (Cloud-Native Computing Foundation). Сервіси, що пишуть в AMO, нативно інтегруються в екосистему Kubernetes, тому в команді кожен постійно вивчає щось нове. Міф №6 DevOps починається з С-level. Слова СЕО «давайте зробимо у нас DevOps» — це не те, з чого починається імплементація цього методу в компанії. Все інакше. Наймаючи людину, якій можна довірити технічну частину продукту, CEO доносить, в якому напрямі розвивається компанія, а під нього вже налаштовується процес розробки. Більш того, рано чи пізно DevOps сам проявиться в тій чи іншій формі навіть без відповідних рішень та найму окремих спеціалістів. Адже досвідченому розробнику точно захочеться як мінімум автоматизувати процес тестування, а потім зʼявиться потреба частіше «деплоїти» нові фічі, щоб перевіряти продуктові гіпотези, далі прийде CI\CD. В AMO DevOps з'явився як логічна відповідь на потребу бізнесу робити регулярні зміни в продуктах, часто додавати новий функціонал. Наразі культура DevOps є ключовою в розробці. Міф №7 DevOps — змова тестувальників проти розробників. Скоріше це змова всіх інженерів, яким стало нудно і захотілося зменшити рутину. Тих, для кого діє правило: якщо ти двічі зробив одну й ту саму дію та отримав однаковий результат, маєш це автоматизувати, щоб не витрачати час на монотонну рутину, а концентруватися на цікавіших завданнях.

Цього разу пропонуємо вам ознайомитися з вакансіями менеджерів в Genesis. У новій підбірці — дві пропозиції для СТО, а також позиції хедів за різними напрямами. Це керівні посади, тож майже всюди потрібен досвід управління. Завдання складні та амбіційні: запуск нової вебплатформи чи відеонапряму з нуля, формування власної команди, вибір оптимального технологічного стеку. То як, впораєтеся? CTO Компанія Universe створила лінійку застосунків-утиліт для iOS, як-от Scan Guru i Translate Guru. Якщо вам цікавий цей напрям — до компанії саме шукають Chief Technical Officer. Він буде керувати командою з 15 технічних фахівців і наймати нових (за потреби), оптимізує наявні бізнес-процеси та покращить процес розробки. Серед основних вимог — не менш як шість років в розробці, хороші знання і фронтенду, і бекенду, зокрема, NodeJS або Python, Amazon Web Services, а також досвід роботи зі складними високонавантаженими проєктами. Operations Manager Lift розробляє однойменний мобільний фоторедактор на основі штучного інтелекту. Завдання Operations Manager цього продукту — побудувати та оптимізувати процеси в різних напрямах, проаналізувати ринки та фінансові моделі, щоби потім знайти додаткові точки зростання для бізнесу. Найкраще для вакансії підійде людина, що працювала аудитором, консультантом чи аналітиком у компаніях «великої четвірки» чи FMCG. Також потрібно добре володіти Excel, знати англійську та мати круті організаційні навички. Operations Manager Фахівець приєднається до команди OBRIO , чиїм флагманським продуктом є астрологічний застосунок Nebula — світовий лідер за кількістю завантажень у своїй ніші. Операційний менеджер організує ефективні щоденні процеси, знайде та впровадить найкращі практики, проведе фінансовий аналіз продуктів компанії. Для цього достатньо одного року в управлінні проєктами, вміння користуватися Excel чи Sheets, Trello і Notion та впевненої англійської мови. Серед софт-скілів оцінять аналітичне мислення, енергійність, посидючість та відповідальність. Head of R&D / Head of Product У портфоліо Keiki — п’ять застосунків та вебпродукти для малюків від двох до шести років. Зараз команда планує запустити нову вебплатформу для інтерактивного навчання. У спеціаліста, що приєднається на цей напрям, буде можливість реалізувати своє бачення нового продукту — він самостійно обере інструменти та методології, а потім запустить MVP-версію платформи. Тому знання методів якісної оцінки ефективності продуктових змін, вміння працювати з аналітикою і метриками LTV, CPP, ARPU та валідувати продуктові гіпотези точно згодяться для успішної роботи. Head of Administration Це людина, яка зробить офіс не просто робочим простором, а місцем, яке надихає, об‘єднує, сприяє обміну досвідом та новим ідеям. Тож доєднуйтеся, якщо розумієте, як перетворити звичні coffee-points на атмосферні кав’ярні, а пусте приміщення — на комфортний та драйвовий спортзал. Робота також передбачає планування бюджетів, пошук підрядників та формування команди. Наша співпраця точно складеться, якщо ви вже маєте релевантний досвід, наприклад, управляли великим офісом, рестораном або ТРЦ, системно мислите та ухвалюєте рішення, покладаючись на цифри та дані. Head of Analytics / Analytics Lead Компанія Boosters створює мобільні застосунки для покращення якості життя мільйонів людей. Ідеальний кандидат на посаду керівника відділу аналітики круто знає SQL, Python чи R, розуміється на статистиці та працював з великими масивами даних. Оскільки це керівна посада, треба мати досвід у People Management: вміти формувати стратегію на команду та пріоритизувати завдання. На позиції потрібно буде відповідати за аналітичні та архітектурні рішення, вибір технологій та формування стратегії відповідно до планів бізнесу. Head of Video Department GMEM — одна з найбільших медіакомпаній України, де працює 200+ осіб. Вона створює медійні проєкти в Нігерії, Кенії, Гані, Південній Африці, на Філіппінах, а також має проєкти, орієнтовані на Tier-1 ринки. Відеонапрям одного з них й очолить новий менеджер. Разом з командою він буде створювати відеоконтент для Facebook та YouTube. Знадобляться відповідний досвід роботи на керівній посаді, розуміння принципів взаємодії з аудиторією та вільне володіння англійською мовою. На співбесіді попросять показати успішно закриті проєкти. Вакансія партнера: CTO Партнерська компанія Genesis Solidgate створює платіжний провайдер, що надає онлайн-підприємцям можливість приймати всі види популярних платежів. Новий СТО переконається в ефективності наявних технологічних рішень, вдосконалить чи сформує внутрішні процеси, а також найматиме та розвиватиме найкращих інженерів. Знадобляться такі навички: створення складних SaaS чи вебпродуктів на Java або Kotlin, робота з масштабними багаторівневими системами та сервіс-орієнтованою архітектурою, а також управління інженерними командами.

У добірці вакансій у червні — пропозиції для фахівців-аналітиків. Продукти компаній з екосистеми Genesis продовжують працювати та зростати на глобальних ринках, а значить — потребують фахівців, які допоможуть ухвалювати актуальні data-driven рішення. Серед завдань — пошук цінних продуктових інсайтів, візуалізація даних та сприяння розвитку бізнесу. Гортайте підбірку та знайомтеся з можливостями! Product Analyst Якщо ви продуктовий аналітик та прагнете генерувати цінні інсайти — ви ідеальний кандидат для команди Keiki , одного з найбільших розробників освітніх застосунків для дітей на глобальному ринку. Зараз компанії потрібна людина, що перетворить дані на метрики, знайде точки росту для бізнесу, а також оцінить спліт-тести. Знадобиться від пів року відповідного досвіду, вміння працювати з Python та SQL, розуміння принципів теорії ймовірностей. Marketing Analyst Флагманський продукт компанії OBRIO — це астрологічний застосунок Nebula, що є лідером у світі за кількістю завантажень у своїй ніші. Маркетинговий аналітик, що доєднається до команди, допоможе закріпити лідерські позиції. На посаді він буде збирати та опрацьовувати дані в Tableau, покращувати юніт-економіку, допомагати маркетологам удосконалювати рекламні кампанії. Команда очікує, що кандидат розуміє SQL, володіє Python, працює з документацією англійською мовою, а в ідеалі — розуміється на маркетингових інструментах від Facebook, Google та Snapchat. Game Analyst Ще один продукт OBRIO — казуальна гра Factory Empire. За півтора року після запуску гра почала приносити прибуток та показувати позитивну динаміку retention. Команда потребує ігрового аналітика, завдання якого — покращити систему моніторингу основних метрик, відшукати зв’язок між функціями й монетизацією гри та проводити A/B-тести. Аби приєднатися, потрібно відмінно знати SQL, мати комерційний досвід роботи з Python та аналітичними інструментами на кшталт Amplitude. Знадобляться також навички роботи з Tableau та PowerBI. Data Analyst Компанія Boosters створює мобільні застосунки для покращення якості життя мільйонів людей. Зараз команді потрібен аналітик, який буде генерувати рішення, що позитивно вплинуть на показники цих продуктів. Ця вакансія для вас, якщо добре знаєте Python та R, працювали з SQL та реляційними базами даних, а також з Tableau, PowerBI чи іншими системами візуалізації. В ідеалі, ви вже маєте досвід роботи в продуктових компаніях та аналізували продукти для смартфонів. Product Analyst Крім того, Boosters шукає продуктового аналітика. Серед його завдань — валідація продуктових гіпотез, проведення A/B-текстів та підтримка роботи аналітичної інфраструктури. Щоби приєднатися, треба мати не менш як рік на аналогічній посаді, вміння працювати з Amplitude, Tableau, Firebase, Facebook та Google Analytics, знання основ математики та статистики. Перевагу нададуть кандидатам, що працювали з BI-аналітикою, Python та SQL. Investment Analyst Маєте від трьох до п’яти років у фінансах, інвестиціях чи FMCG? Можете провести дослідження з нуля й візуалізувати його в інформативну презентацію? Цікавитеся IT-сферою та венчурними інвестиціями? Тоді ось пропозиція для вас. Ви будете працювати разом із засновниками Genesis — аналізувати ринки, ніші, компанії та проєкти на предмет потенційних можливостей, а також допоможете оптимізувати бізнес-процеси. Перевагу нададуть кандидатам, які вчилися у Київській школі економіки, проводили due diligence та складали інвестиційні документи. Business Analyst Вакансія до R&D-відділу Genesis для спеціаліста рівня сеньйор, який зацікавлений у роботі зі стартапами на ранній стадії. Він допоможе засновникам знайти нові точки зростання та створити MVP для перевірки гіпотез. Для цього потрібно мати два-три роки досвіду у корпоративних фінансах, інвестиційному банкінгу, управлінському консалтингу чи продуктовому IT, сильні аналітичні навички та відмінне знання Exel. В ідеалі фахівець має технічний бекграунд, знає SQL, Python чи REST та працював з популярними інструментами аналітики для мобільних додатків. Data Analyst Фахівця шукає міжнародна IT-компанія AMO , яка створює продукти й історії для мільйонів користувачів. На посаді він буде створювати аналітичні інструменти для трьох напрямів бізнесу — AMO Publishing, AMO Pictures й AMO Apps. Серед інших завдань — допомагати колегам приймати data-driven рішення, розробляти інформативні дашборди та автоматизувати процеси. Найкраще впорається людина, що має понад рік релевантного досвіду, працює з SQL та Python і має рівень англійської мови Intermediate або вище. Data Analyst Спеціалістам із двома роками досвіду в продуктовій компанії, відмінними навичками SQL та вільним володінням інструментами BI-візуалізації буде цікаво попрацювати в команді Sendios. Це компанія в екосистемі Genesis, що допомагає малим та великим бізнесам досягати своїх цілей за допомогою email-маркетингу. На позиції на вас чекають оцінка ефективності стратегій та ініціатив, аналіз воронок та показників клієнтів, створення ad-hoc звітів та формування нових метрик. Вакансія компанії-партнера: Product Analyst Продуктовий аналітик приєднається до Headway — IT-компанії, що розробляє мобільні EdTech-продукти, які допомагають мільйонам людей навчатись через лаконічний (bite-sized) контент. У майбутньому він може розраховувати й на вертикальний ріст, наприклад, до рівня сеньйор, і на отримання управлінського досвіду — матиме змогу зібрати свою команду. Робота передбачає стеження за продуктовими показниками та пошук причин їхніх змін, побудову зрозумілих дашбордів, які полегшать роботу команд, проведення А/B-тестів та оцінку результатів.