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

Українська EdTech компанія Headway потрапила до переліку найкращих стартапів Європи та може досягти капіталізації в $1 млрд (стати «єдинорогом») у найближчі два роки. Відповідне дослідження ринку провела компанія GP Bullhound. Звіт Titans of Tech відображає стан європейської технологічної екосистеми. Упорядники проаналізували понад 100 європейських стартапів на предмет масштабованості та швидкості зростання, а також опитали 120 інвесторів. На основі одержаних результатів команда сформувала рейтинг 50 стартапів із найбільшим потенціалом досягти капіталізації в $1 млрд у найближчі два роки. Headway знаходиться серед 30 перших стартапів у цьому рейтингу. «В основі Headway — зростання. Наші продукти допомагають людям в усьому світі розвивати себе та навчатися день за днем протягом життя. Ріст, який за останній рік показала команда попри всі виклики, спричинені війною, — це свідчення неймовірних зусиль та натхнення будувати справжній український стартап-«єдиноріг», — коментує СЕО Headway Антон Павловський. Список сформували за кількома критеріями — розглядали тільки технологічні бізнеси, що працюють в інтернеті чи створюють програмне забезпечення, зі штаб-квартирою в Європі чи Ізраїлі, засновані не раніше 2000 року, які вже залучали мінімум $20 млн інвестицій або ж оцінюються в понад $400 млн. Зазначають, що більшість бізнесів, які GP Bullhound включала до переліку потенційних «єдинорогів» у 2021 році, уже досягли капіталізації в $1 млрд або перебувають на шляху до цієї позначки. Окремо упорядники звіту зазначають, що попри повномасштабне вторгнення росії, українська технологічна екосистема залишається стійкою. Так, у 2022 році IT-експорт України зріс на 5%, 77% технологічних бізнесів продовжують працювати з глобальними клієнтами, а 65% компаній не скорочували працівників попри війну. Довідка: Headway — EdTech стартап, що створює продукти з мікронавчання. Входить до списку найінноваційніших компаній у сфері цифрової освіти та корпоративного навчання — GSV 150. Заснований у 2019 році. За 3,5 роки компанія зросла з 3 до 170+ людей у команді та відкрила офіси у Києві, Варшаві, Нікосії та Лондоні. Продукти Headway допомагають розвиватися мільйонам людей через лаконічні формати освітнього контенту: самарі, курси, ігри, інфографіки. Флагман компанії — Headway app, який у 2023 став App of the Day в США чотири рази поспіль та отримав відзнаку Editor Choice від Apple Store. GP Bullhound — це провідна консалтингова та інвестиційна технологічна компанія, яка надає консультації щодо угод та капіталу підприємцям з усього світу. Компанія була заснована у 1999 році в Лондоні й на сьогодні має 13 офісів у Європі, Азії та США.

Використання AWS та GitHub Actions застосунку дозволяє автоматизувати та спрощувати процес розгортання, забезпечує швидкість та ефективність розробки, а також надає можливості масштабування та інтеграції з сервісами AWS. Докладно про це розповів Front-end Team Lead у Boosters Олександр Барило на мітапі у генезійському фронтенд-ком'юніті. Він уже шість років займається розробкою й пів року очолює команду фронтенд-розробників. Публікуємо найважливіше з виступу. Про які AWS ресурси піде мова Розглянемо їх детальніше Amazon CloudFront — це вебсервіс, який пришвидшує розповсюдження статичного та динамічного вебконтенту, як-от .html, .css, .js, а також файли зображень, серед користувачів. CloudFront доставляє контент через мережу дата-центрів, які називаються edge locations. CloudFront дублює вихідні ресурси на локацію, яка ближча до юзера — так він швидше отримуватиме потрібний контент. Amazon S3 Bucket — це контейнер для об’єктів, що зберігаються в Amazon S3. Bucket дає змогу зберігати будь-яку кількість об’єктів. Всього в акаунті можна мати до сотні подібних Bucket. Amazon Route 53 — це високодоступний масштабований хмарний вебсервіс системи доменних імен (DNS). Дає змогу перенаправляти кінцевих користувачів до інтернет-застосунків завдяки перетворенню доменних імен (наприклад, www.example.com) у формат цифрових IP-адрес (наприклад, 192.0.2.1), які використовуються комп’ютерами. З його допомогою потрібно буде перенаправити юзерів до вашого домену. Як це виглядає у вебінтерфейсі Йдемо у Console Home, створюємо акаунт, підв'язуємо свою картку. Тепер можна щось створювати натискаємо на S3. Там знаходяться Buckets, нам потрібно створити новий. Для управління записами є Route 53. Натискаємо на нього, потім переходимо до Hosted Zone. Якщо у вас чистий акаунт, то Hosted Zone не буде, але в моєму прикладі вона є. Тут міститься ряд записів. Якщо потрібно створити новий — така опція також є. Недолік цього способу полягає у тому, що є ризик забути порядок дій, а також у тому, що інші користувачі мають можливість внести зміни, які буде важко відстежити. З цим допомагає впоратися AWS CDK — платформа розробки програмного забезпечення з відкритим вихідним кодом, яка дає змогу визначати ресурси для хмарних застосунків, використовуючи звичні мови програмування. Це означає, що код, який ви написали, під час запуску буде сетапити ті чи інші ресурси. AWS CDK підтримує декілька мов, як-от TypeScript, JavaScript, Python, Java, C, .Net, Go, однак тут і далі ми будемо використовувати TypeScript. Підготовка до роботи: що потрібно Для того, щоби почати роботу, знадобляться: Тож, зробимо тестовий CDK-проєкт — звичайний creator app застосунок, який у нас буде лежати у своїй папці. Потрібно виконати команду: cdk init app — language typescript Для того, щоб можна було деплоїти через CDK, вам потрібно створити credentials для юзера. Це робиться через окремий сервіс AWS, який називається IAM. У ньому відображається список юзерів. Знаходите вкладку security credentials, а там — колонку Access Key ID. Спочатку у вас їх не буде: credentials потрібно генерувати, а потім зберігати для подальшого використання. Використовуючи їх у файлі AWS Credentials, можна засетапити юзера по дефолту або з певним іменем. Тоді для нього прописується Acceess Key та Secret Access Key. Далі покажу, де це буде застосовуватися. CDK project Перевага CDK — все, що ви створите, можна буде потім почистити за допомогою команди destroy. На початку проєкт має ось такий вигляд: Спершу акаунт потрібно хардкодити в конфіг. env: { account: ‘aws-account’, region: ‘us-east-1’ } Після того, як ви це зробили, вам потрібно буде запустити команду для Bootstrap. export CDK_NEW_BOOTSTRAP=1 cdk --profile=test_acount_cdk_user bootstrap Тоді CDK під’єднається до вашого акаунту, піде в S3 й створить свій Bucket для зберігання артефактів, які йому необхідні для порівняння змін, щоб зрозуміти, що потрібно оновити, а що видалити. Далі приступаємо до конфіга. cdk deploy --profile test_acount_cdk_user Це команда для того, щоб деплоїти, але зараз мова про те, як сконфігурувати ваш stack. Перше, що ми створимо — це Bucket. Більшість ресурсів зашиті до core-бібліотеки, aws-cdk-lib. Якщо ні — потрібно буде шукати та встановлювати додаткові бібліотеки. У попередніх версіях усі ресурси були розкидані окремими бібліотеками, але поступово їх додають уже в core. Спочатку створюємо S3 Bucket, передаємо йому наш stack. Звертаємо увагу на // s3 bucket const frontendAppBucket = new Bucket(this, 'Test-S3Bucket', { bucketName: 'test-v1-s3-bucket' }) — це ідентифікатор, який має бути унікальним на рівні всього stack. Всередині є конфіг для Bucket, і потім потрібно буде передати тільки bucket name. Коли ми це запустимо, цей шматок коду створить нам ось такий Bucket. Створюємо нову Hosted Zone, яка створить необхідні записи в Route 53. // hosted-zone const hostedZone = new HostedZone(this, 'MyHostedZone', { zoneName: domainName }) Коли ми запускаємо команду для деплоя, вона створює HostedZone, яка містить ось такі записи. Тоді нам потрібно «піти» у реєстратор, де ми створювали домен, й прописати все це у відповідному вікні. Команда // sertificate const appCert = generateCertificate(this, domainName, hostedZone) генерує сертифікат. Тут використовується метод from.dns, вона сама пройде валідацію за допомогою запису в RoutedZone. S3 bucket, CloudFront, Deploy User Отже, Bucket ми створили. Тепер потрібно створити CloudFront Distribution new CloudFrontWebDistribution() Це те, що називається cdn. Для CloudFront Distribution створюється користувач, якому надається доступ до S3 bucket. // Cloudfront user const cfoai = new OriginAccessIdentity( this, 'CloudFrontOriginAccessIdentity', { comment: 'Cloudfront user which will be allowed to access the site s3 bucket' } ) // add access cloud-front-user to S3 bucket frontendAppBucket.addToResourcePolicy( new PolicyStatement({ principals: [ new CanonicalUserPrincipal( cfoai.cloudFrontOriginAccessIdentityS3CanonicalUserId ) ], actions: ['s3:List*', 's3:Get*'], resources: [`${frontendAppBucket.bucketArn}/*`] }) ) Це для того, щоб з S3 Bucket направити на цей CloudFront. Юзера ми також створюємо для того, щоб деплоїти. Відповідно, коли ми будемо заливати це в S3, нам знадобляться credentials. Далі цьому юзеру передаємо permissions на ReadWrite для bucket. // grand permissions for S3 bucket frontendAppBucket.grantReadWrite(deployUser) Потім створили CloudFront, додали до deployUser політику за допомогою якої він може інвалідувати цей CloudFront. Нижче додали рекорд, який буде перенаправляти дані з нашої доменної зони на інстанс CloudFront. deployUser.addToPolicy( new PolicyStatement({ effect: Effect.ALLOW, actions: [ 'cloudfront:GetInvalidation', 'cloudfront:CreateInvalidation', ], resources: [ `arn:aws:cloudfront::${process?.env?.account}:distribution/${cf.distributionId}`, ], }) ); new ARecord(this, 'AppDNS', { recordName: domainName, zone: hostedZone, target: RecordTarget.fromAlias(new CloudFrontTarget(cf)), }); Далі йдуть висновки — те, що буде виводитися у консоль, щоби ми могли побачити, що саме створилося. new CfnOutput(this, 'FrontendAppBucket', { description: 'Js App Bucket name', value: frontendAppBucket.bucketName, exportName: `${appName}AppBucket`, }); new CfnOutput(this, `${appName}AppCloudFrontDistributionID`, { description: 'CloudFront Distribution ID', value: cf.distributionId, exportName: `${appName}AppCloudFrontDistributionID`, }); new CfnOutput(this, 'DomainApp', { description: 'App domain', value: domainName, exportName: `${appName}App`, }); new CfnOutput(this, `${appName}AppCertARN`, { description: 'App Certificate ARN', value: appCert.certificateArn, exportName: `${appName}AppCertARN`, }); new CfnOutput(this, `${appName}AppDeployUserARN`, { description: 'Deploy frontend user ARN', value: deployUser.userArn, exportName: `${appName}AppDeployUserARN`, }); new CfnOutput(this, 'DeployFrontendAccessKeyId', { value: accessKey.ref }); new CfnOutput(this, 'DeployFrontendSecretAccessKey', { value: accessKey.attrSecretAccessKey, }); } } Пробуємо задеплоїти, робимо це за допомогою команди cdk deploy -- profile test_account_cdk_user У цей момент на основі нашого конфігу генерується Json-файл, який «дивиться», що змінилося і публікує. В output виводиться інформація щодо створених ресурсів, де ми можемо отримати credentials, які нам знадобляться в GitHub Actions. Як налаштувати GitHub Actions Ось приклад команд які запускаються в екшені. Фактично, це послідовність скриптів які виконуються для того, щоб збілдити й задеплоїти проєкт. - name: Install packages run: npm install - name: Run unit tests run: npm run test:ci - name: Run linters run: npm run lint - name: Build project run: npm run build - name: Deploy to S3 uses: jakejarvis/s3-sync-action@master Для конфігурації екшенів в кореневій папці проєкту потрібно створити папку `.github/workflows` — в ній зберігаються конфіги екшенів. Я створю два конфіги: один для pull requests, а інший — для deploy. В pull requests спочатку вказується, для яких подій потрібно запускати Actions. Далі йде опис jobs, де потрібно вказати, з якої директорії запускати скрипти (якщо ви прямо з кореня все запускаєте, то це можна пропустити). name: Build pull request to the master # Controls when the action will run. Triggers the workflow on push or pull request # events but only for the selected branch on: pull_request: branches: [ master ] # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" build: # set default directory defaults: run: working-directory: ./genesis-frontend # The type of runner that the job will run on runs-on: ubuntu-latest strategy: matrix: node-version: [12.x] Уже на тому етапі, коли ви зробите якийсь pull request master — запуститься останній скрипт. - name: Install packages run: npm install - name: Run unit tests run: npm run test:ci - name: Run linters run: npm run lint - name: Build project run: npm run build Спробуємо внести зміни — додамо новий текст. Припустімо, що ми хочемо закомітити ці зміни, аби вони потрапили в потрібний домен. Йдемо на GitHub. Створюємо pull request та переходимо на вкладку Actions. Тут ми можемо подивитися логи, як усе збирається. Це свого роду перевірка, щоб впевнитися, що після змін в коді проходять всі тести, білд і цей код можна сміливо релізити. Вище ми створювали два конфіги. Раніше ми працювали з pull request, тепер розглянемо конфіг для deploy. - name: Deploy to S3 uses: jakejarvis/s3-sync-action@master with: args: --acl public-read --delete env: AWS_S3_BUCKET: ${{ secrets.AWS_PROD_BUCKET_NAME }} AWS_ACCESS_KEY_ID: ${{ secrets.AWS_PROD_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_PROD_SECRET_ACCESS_KEY }} AWS_REGION: ${{ secrets.AWS_REGION }} SOURCE_DIR: "genesis-frontend/build" - name: Invalidate Cloudfront cache uses: chetan/invalidate-cloudfront-action@master env: DISTRIBUTION: ${{ secrets.PROD_CF_DISTIRIBUTION_ID }} PATHS: "/*" AWS_REGION: ${{ secrets.AWS_REGION }} AWS_ACCESS_KEY_ID: ${{ secrets.AWS_PROD_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_PROD_SECRET_ACCESS_KEY }} Для того, щоб це все працювало, потрібно все що ви отримали з cdk піти і засетапити secrets з відповідними значеннями. Secrets, які використовуються, можна побачити в Actions, а отримати з cdk. Спробуємо викатити апдейт. Попередня версія коду уже залита. Дивимося у GitHub стан Actions. Все успішно — проєкт зібрався. Тепер виливаємо наш апдейт на продакшн: мерджимо pull request, confirmation, переходимо до Actions і запускаємо їх заново. Раніше вони називалися pull request master, а тепер — prod build and deploy. Після того, як код збілдився, проєкт задеплоївся в S3 та інвалідувало кеш на Cloud Front. Було: Стало: З таким процесом deploy підводні камені можуть з'являтися на кожному етапі: не вистачає доступів, неправильне налаштування. Однак рішення усіх цих труднощів нескладно нагуглити. Зручність рішення — його велика перевага, адже весь set up зберігається у вигляді коду на GitHub. Відповідно, якщо хтось внесе зміни, ви завжди можете подивитися GitHub і зрозуміти, що саме перемінилося. Такого не вийде зробити, якщо сетапити інфраструктуру через вебінтерфейс. У себе в проєкті ми ухвалили рішення: все, що сетапиться на AWS, має сетапитися через cdk — для того, щоб була якась стабільність і ми не втрачали потрібні налаштування.

PlantIn — один з наймолодших проєктів на мапі портфельних компаній Genesis. Однойменний застосунок для догляду за рослинами за три роки завоював прихильників по обидва боки Атлантики. Як із невеличкого проєкту, який два розробники створювали у свій вільний час, PlantIn перетворився на одного з лідерів у ніші — розповіли співзасновники компанії Михайло та Дмитро Гринці. Одного разу служба підтримки українського мобільного застосунку PlantIn отримала запит від користувачки зі Сполучених Штатів із проханням допомогти врятувати спатифілум, який вже майже загинув, але був дорогий їй, бо залишився від матері. PlantIn — застосунок-помічник для догляду за різними видами рослин, який пропонує скористатися вбудованою ШІ-технологією або отримати консультацію експертів із ботаніки для вибору плану догляду. Команда сапорту одразу надіслала запит і фото спатіфілума фахівцям. Ті розписали детальний план догляду, поливу, прогнози, допоміжні інструменти: важливу рослину треба було рятувати оперативно. За два місяці користувачка повернулася із фотографіями живої і квітучої рослини. «Ми побудували підтримку від експертів таким чином, аби хтось із них був доступний постійно: так ми можемо охопити користувачів у різних частинах світу» — коментує Михайло Гринець, співзасновник і со-СЕО PlantIn. У 2020 році, в розпал пандемії ковіду, він разом зі своїм братом Дмитром запустив першу версію застосунку для розпізнавання рослин і догляду за ними. Спортсмени і розробники У сім’ї Гринців любителькою і знавчинею рослин була бабуся Дмитра і Михайла, але про те, що їх робота буде тісно пов’язана з ботанікою, майбутні підприємці і не здогадувались. Школярами обидвоє професійно займалися бігом, потім вступили до Київського національного університету імені Тараса Шевченка. Дмитро – на факультет кібернетики, Михайло — на юрфак. «Я з дитинства цікавився програмуванням, тому обрав вивчення системного аналізу в університеті. З третього курсу почав працювати як Java-розробник, паралельно самостійно вивчав інші мови, цікавився створенням мобільних ігор» — згадує Дмитро. Тим часом Михайло спробував себе в юриспруденції, але IT-індустрія виявилась більш цікавою. Не маючи профільної освіти, він вивчив PHP і JavaScript самостійно, деякий час працював бекенд-розробником в ізраїльському стартапі, а у 2018 році отримав офер від проєкту Impulse з екосистеми Genesis, де спочатку був єдиним бекендером в команді. Проєкт тоді запускав нову мобільну гру на кшталт квізу. «За перші півроку в Impusle я опанував стільки нових навичок — про те, як створювати мобільний продукт з нуля — скільки не отримував за всю кар’єру раніше» — розповідає Михайло. Саме цей досвід і менторська підтримка колег з інших проєктів екосистеми надихнула його на ідею попрактикуватися у запуску власного диджитал-продукту. Своїми думками Михайло поділився із братом. Plant-проєкт замість pet-проєкту «У нас в офісі завжди багато рослин, і за ними регулярно приходить доглядати спеціаліст, який знається на цьому. Для мене це було трохи дивно, тому що ми з братом завдяки бабусі з дитинства знали все про домашні рослини і догляд за ними. В певний момент з цього виникла задумка — чому б не спробувати зробити щось на кшталт диджиталізованого помічника для тих, кому бракує знань із ботаніки, аби підтримувати домашні рослині в порядку» — говорить Михайло. Ідея була цікава, проте для її реалізації потрібно було знайти iOS-розробника, бо на Swift брати не програмували. Дмитро вирішив опанувати мову самотужки. Для розробника, який раніше працював із Python, JavaScript, C# це не було чимось надскладним. Зі специфічного — треба було навчитися працювати з інтерфейсом мобільних девайсів на нативних методах. За півроку Дмитро вивчив Swift та написав першу версію застосунку. Михайло займався бекендом. Вдвох вони збирали контент для PlantIn — додавали рослини та плани догляду. В середині 2020 року застосунок вивантажили в AppStore — повністю безкоштовний. Для розробників це був сайд-проєкт, поле для опанування нових навичок та експериментів. «Спочатку ніхто з нас не планував на цьому заробляти, не аналізував ринок, ми не запускали рекламу. Просто зробили цікаву штуку для загального користування, на яку витратили лише свій вільний час» — згадує Михайло. Головною метою розробників було створити onе-button-solution, аби користувач міг знайти все про рослину, яка його цікавить, — повний опис, особливості, інформацію про догляд, наявні хвороби рослини, та отримувати нагадування про полив, пересаджування тощо. Водночас у цієї концепції були і проблеми. У першому ж відгуку в AppStore застосунок отримав одну зірку від користувача і коментар: «Надто мало рослин у базі». Вирішення цієї проблеми знайшли нетривіальне: додали опцію розпізнавання рослин на основі технології машинного навчання. Користувачу достатньо завантажити фото в застосунок, і система визначає тип рослини і надає план догляду. «Під капотом» це виглядало трохи складніше. ML-модель для розпізнавання рослин також довелось писати з нуля — цього разу Дмитру Гринцю потрібно було три місяці на опанування технології та розробку моделі. Після релізу функції розпізнавання справи у додатку пішли вгору. Прискорення додала пандемія — усі диджитал-застосунки зростали, і PlantIn також. «Це було потрапляння в правильну аудиторію із правильним набором фіч — і ми побачили великий стрибок у кількості завантажень» — говорить Михайло. У безкоштовного застосунку без реклами з’явилися перші декілька тисяч активних користувачів. В цей час розробники вирішили додати опцію «підтримати проєкт» — за бажанням користувача. Функціонал залишався у відкритому доступі, проте усі охочі могли заплатити за користування застосунком у форматі, аналогічному до Patreon. Після того, як кількість користувачів досягла 10 000, а частина з них оформила платну підписку на застосунок, стало зрозуміло, що PlantIn вже важко назвати pet-проєктом, він потребує розвитку та інвестицій. PlantIn - нова «дочка» Genesis Задача кофаундингової компанії — вирощувати успішні технологічні бізнеси. В Genesis вже виросли та стали незалежними декілька великих компаній, такі як Jiji, Headway та інші. Кожен бізнес в екосистемі працює автономно, з окремими командами і керівництвом, проте материнська компанія бере на себе забезпечення адміністративних функцій: юридична, фінансова, комунікаційна та інші. Це особливо допомагає стартапам на ранніх стадіях зосередитись на створенні продукту та швидко масштабуватися. «Ми прийшли до СЕО Impulse Євгена Костенецького та співзасновника Genesis Віталія Лаптенка із пітчем нашого продукту. У нас були користувачі, непоганий трекшн та застосунок, який працює. І отримали зелене світло» — згадує Михайло. Він став на чолі новоствореної компанії, а Дмитро зайняв позицію CTO. Задля можливості розвивати власний продукт, йому довелось відмовитись від оферу до лондонського офісу фінтех-компанії Revolut. «Я вірив, що у нашого проєкту є потенціал, і долучитися до його розвитку було важливіше, аніж працювати на когось, хай навіть у Revolut» — говорить Дмитро. В липні 2020 року Genesis взявся розвивати PlantIn як окрему компанію всередині своєї екосистеми. Аби масштабуватися, проєкт потребував команди та інвестицій — силами двох розробників на парт-таймі стало неможливо підтримувати продукт із десятками тисяч користувачів. Кофаундингова компанія допомогла з розбудовою команди, процесів, а також — із підприємницьким менторством. «Досвід колег-управлінців, особливо Ярослава Морозова з Universe, а також Олександра Федорова з OBRIO, Михайла Галяна з Boosters та інших допоміг нам оминути типових помилок фаундерів-початківців. До того ж, саме величезна експертиза зі створення мобільних застосунків, яка зосереджена в Genesis, дала нам неабиякий буст. Ми змогли швидко масштабуватися та вдосконалювати продукт» — говорить Михайло Гринець. У 2020 році на ринку, в який цілився PlantIn, вже було немало гравців. Найбільші серед них: французський проєкт Pl@ntNet, американські PlantSnap та Garden Answers. Їх об’єднував функціонал із розпізнавання рослин, проте жоден із них не пропонував план або поради по догляду. Водночас існували застосунки, які допомагали із вирощуванням і доглядом, але не містили технологій розпізнавання. Поєднання цих двох опцій дозволило українському проєкту увійти і закріпитися в ніші на ринках США, Латинської Америки, Австралії та Європи. «Плани і нагадування по догляду — це те, що дало можливість підтримувати високий показник утримання користувачів. Якщо людина додала свою рослину в застосунок, і використовує його регулярно для догляду, ймовірність, що вона піде від нас за місяць-або два, дуже низька» — пояснює Дмитро. Нині у PlantIn більше 20 млн завантажень. Водночас засновник підкреслює, що головна особливість цього ринку — сезонність. «З березня по вересень — наш високий сезон, люди значно активніше починають купувати рослини, доглядати за ними. Спочатку ми намагались якось активувати користувачів зимою, але згодом прийшли до висновку, що не треба винаходити велосипед, наш бізнес сильно залежить від сезону, цим ми і керуємось» — говорить Михайло. У «високі» місяці у PlantIn — від 3 млн активних користувачів. Застосунок працює за моделлю fremium, але левова частка функціоналу все ще залишається доступною безкоштовно. У платну підписку входить можливість додавати необмежену кількість рослин та отримувати консультації експертів із ботаніки. Нині це команда з восьми дипломованих фахівців зі всього світу. Підписка коштує $29,9 для всіх користувачів, крім українців. Для них PlantIn став безкоштовним з початком повномасштабної війни. Базуючи велику частину функцій на машинному навчанні, компанія пішла далі, і створила ШІ-асистента, який нині допомагає користувачам не лише розпізнавати захворювання рослин, а й підбирає лікування. Це своєрідний аналог ChatGPT, але для рослин, і повністю розроблений ML-командою PlantIn. «Нині штучний інтелект і реальні експерти працюють із запитами користувачів паралельно, але ми прагнемо до того, аби віртуальний помічник перебирав на себе якомога більше функцій, щоби зробити досвід користувачів більш легким і цікавим» — розповідає Дмитро Гринець. Соціальна мережа для фанатів рослин Комплексний продукт, який дозволяє розпізнавати рослини і водночас допомагає з їх утриманням і доглядом створив навколо себе справжню спільноту ботаніків-аматорів. Наступним етапом розвитку PlantIn засновники бачать створення зручного платформи не лише для догляду за рослинами, а й для спілкування користувачів, обміну досвідом, цікавими кейсами. Михайло Гринець розповідає, що в перспективі декількох років PlantIn перетвориться на своєрідний ботанічний Instagram. У користувачів вже нині є профілі в застосунку, і вони мають змогу ділитися фотографіями рослин у новинній стрічці, взаємодіяти, коментувати. Ставку робитимуть на plant bloggers — інфлюенсерів, які зможуть об’єднувати навколо себе спільноту та монетизувати свою експертизу чи досвід у рослинництві. «Ми зібрали більше 20 млн людей, об’єднаних одним хоббі, це унікальна можливість для експертів та продавців рослин пропонувати свої консультації і рослини релевантній аудиторії, замість того, аби використовувати той же Instagram з величезною різнорідною аудиторією» — пояснює Михайло Гринець. Із розвитком продукту та розбудовою ком’юніті в компанії відбуваються і структурні зміни. Нині обидва брати ділять між собою посаду СЕО. «Це було зроблено, аби звільнити технічну вертикаль, щоб технічні спеціалісти в команді мали змогу дорости до посади CTO», — пояснює Дмитро, — «загалом мій пул обов’язків не змінився, я відповідаю за розвиток продуктової та технічної команд, Михайло — за стратегічні питання маркетингу, креативні команди та контент. Ми від початку управляли компанією в тандемі, і у нас це добре виходить, тому структура управління, яка є нині — найбільш органічна». За три роки команда виросла до 50 співробітників, і постійно підсилюється новими фахівцями. «Наша корпоративна культура постійно приваблює до нас людей небайдужих, які дійсно горять тим, що вони роблять. Я йду відпочивати на вихідні, і бачу, шо наш ML-розробник все ще онлайн у корпоративному чаті і робить якісь експерименти, а iOS Lead може фіксити версії в суботу зранку. Вони бачать, як розвивається продукт, і бачать свій внесок у загальний результат — це не може не надихати» — говорить Михайло Гринець.

ChatGPT від OpenAI з'явився восени минулого року, і з того часу вже багато написано про те, як використовувати його для розробки й тестування, зокрема для автоматизації тестів. Проте є ще один великий сегмент, в якому штучний інтелект може допомогти — тестування застосунків на вразливості. Невирішені питання безпеки в майбутньому можуть коштувати компанії-розробнику коштів, часу і витрачених зусиль. Про те, як використовувати найпопулярніше надбання індустрії ШІ для тестування безпеки, розповів Head of QA у компанії EVO Свят Логін на мітапі DOU QA Community. Свят вже понад десять років працює в тестуванні й понад п'ять років займається тестуванням вразливостей на Web та Mob. Окрім цього, веде блог із тестування безпеки. Публікуємо конспект найважливішого з його виступу на мітапі. Використання штучного інтелекту для тестування вразливостей — найкращий варіант для компаній, які бачать необхідність в тому, аби убезпечити свої продукти, проте не мають достатньо бюджету для найму пентестерів. Компаніям, для яких безпека є одним з найважливіших пріоритетів, краще обрати послуги тестувальника, або навіть команди пентестерів, аніж залучати ChatGPT. У будь-якому випадку штучний інтелект стане в пригоді всім. Чому? Тому що нові вразливості з'являються щодня, і навіть найдосвідченіший тестувальник може не знати, як з ними обходитись. Проблеми тестувальників, які може вирішити ChatGPT Нестача досвіду у сфері тестування на проникнення. Звичайні QA перевіряють все на предмет функціональності. Нині, під час війни, ворог використовує інтернет для завдання ударів також. Саме тому тестувальникам варто розібратися в тому, як шукати вразливості та реалізовувати тестування безпеки. Відсутність чіткого флоу. Штучний інтелект може швидко надати покроковий план того, як варто тестувату ту чи іншу вразливість. Брак часу. Навіть досвідчені пентестери використовують ChatGPT, тому що він допомагає суттєво оптимізувати роботу, беручи на себе рутинні завдання. Він може реалізувати навіть написання тест-кейсів та чеклістів (але тут варто перевірити, чи все вірно він зробив). Критичні вразливості за OWASP OWASP (Open Web Application Security Project) — це міжнародна некомерційна компанія, яка займається промотуванням безпеки вебзастосунків. OWASP створює велику кількість ґайдлайнів із безпеки, як для вебу, так і для мобайлу. OWASP Top-10 — це світова методологія оцінки вразливостей вебдодатків, яка містить десять найбільш розповсюджених вразливостей та методи їх визначення. На малюнку вище ми бачимо порівняння OWASP Top-10 за 2017 та 2021 рік. Насправді вразливості залишилися ті ж самі, при цьому деінде змінилася їх пріоритезація та повна назва. Якщо ви лише починаєте знайомитись із тестуванням вразливостей, вам допоможе базове флоу для пошуку вразливостей з OWASP Top-10 за допомогою ChatGPT. Штучний інтелект і вразливості Для пошуку вразливостей можна використовувати як платну, так і безоплатну версії ChatGPT. Різниця між ними невелика: платна дещо швидше генерує відповіді та необмежена в обсязі написаного. Безоплатна генерує не більше ніж 2048 символів за одну відповідь. Окрім цього, платну можна інтегрувати з різними додатками, зокрема з Postman. Як правильно користуватися чатом? Визначаємо для нього певну роль. Так він буде шукати й аналізувати інформацію вузьконаправлено, з точки зору тої ролі, яку ми йому запропонували. Якщо цього не зробити, він буде шукати інформацію у всій мережі, а це означає дуже абстрактну відповідь. Пишемо завдання. Вказуємо уточнення до завдання. Тут варто згадати всі додаткові уточнення, які можуть бути — це зробить відповідь максимально релевантною саме для вашого кейса. Для питань з різних тематик створюємо різні кімнати. З кожним питанням ChatGPT навчається, і формує свою думку на основі попередніх питань, що ви ставили. Якщо ваші питання стосуються різних сфер, наприклад, тестування безпеки й менеджменту, то варто ставити їх в окремих кімнатах, аби не отримати заплутану відповідь. Типи вразливостей Вразливості мережі й бібліотек Вони виникають у випадку неправильно налаштованих серверів та використання бібліотек від розробників, які можуть містити вразливі компоненти. Якщо така бібліотека використовується в додатку, і лише один компонент вразливий — вразливим стає весь додаток. Через таку вразливість був розповсюджений вірус notPetya у 2017 році. Як це працює? У нас є вебзастосунок, який містить бекенд, фронтенд, базу даних та мікросервіси. У мікросервісів можуть бути також свої фреймворки, за якими вони працюють. В якийсь момент ми вирішуємо, що ця версія нашого застосунку застаріла, ми хочемо переїхати на нову, а може на навіть і на нову базу даних. Тож ми переїжджаємо, але на те, щоб забрати з інтернету стару базу даних, не маємо часу або грошей. Якщо зловмисник просканує наш додаток, і знайде база даних, то він матиме змогу без перешкод залізти в неї exploit. Така сама схема працює і з бекендом, і з мікросервісами. Тому обов'язково потрібно видаляти ваші застарілі сервіси, бібліотеки й бази даних. Як має виглядати запит для ChatGPT для пошуку вразливостей цього типу. У інструменту nmap є різноманітні плагіни, і ви навіть можете попросити у ChatGPT, аби він сказав, як користуватися певним плагіном за допомогою nmap. Він пам'ятає тему про яку ви говорили минулого разу, тому одразу напише, що вам робити з плагіном. Веб-вразливості Найрозповсюдженіші вразливості типу А3: Cross-Site Scripting. 90% сайтів мають таку проблему. Це вразливість, яка дозволяє стороннім користувачам додавати сторонній js код у ваш додаток. Якщо у вашому вебдодатку немає екранування символів, які вводяться звичайними користувачами, то саме це може бути джерелом вразливості. Зловмисник може написати шматок кода на js, закинути вам в input, зберегти в базі даних, і потім зламувати ваших користувачів. За допомогою XSS він може вкрасти cookies, змінювати ваш сайт, встановлювати keylogger (програма, яка допомагає бачити, що інші користувачі набирають на клавіатурі, до того, як це відправлено на сайт). Також він матиме змогу додавати фішингові поп-апи, і за їх допомогою діставати дані користувачів. Як сформувати запит для цієї вразливості? Вразливості логіки Ці вразливості з’являються через прагнення UI/UX-дизайнерів та продактів зробити найзручніший та найпростіший для користувача продукт. Часто для цього нехтують безпекою. Це призводить до того, що з'являються вразливості системи, через які потім можна виводити кошти, обманювати користувачів тощо. Як протестувати цю вразливість? Запит для чату має бути наступний:

Мова програмування Swift — це сучасне потужне рішення для будь-якого продукту чи обмежений інструмент в закритій екосистемі? Асинхронні оновлення iOS та Swift досі ламають проєкт? Чи вдалося IBM адаптувати цю мову під бекенд, а розробникам Apple — нарешті «допилити» SwiftUI? Та чи дозволить Kotlin Multiplatform Mobile оптимізувати розробку для двох команд? Найпоширеніші міфи про Swift спростовує Роман Кириленко, iOS Developer в Quarks, партнерській компанії Genesis. > Swift створили, щоби замінити Objective-C, але цієї мети так і не досягли > Swift — мова, на якій неможливо писати поганий код > Після кожного оновлення Swift, iOS чи Xcode все ламається > Swift повністю адаптований для проєктів за межами iOS > На Swift можна створювати ігри > SwiftUI — нове покоління UI-фреймворків > Єдиний код для Android та iOS неможливий МІФ №1 Swift створили, щоби замінити Objective-C, але цієї мети так і не досягли Поява Swift у 2014 році була органічною потребою, адже Objective-C вже тоді була доволі застарілою мовою програмування. Попри її мачурність та здатність вирішувати багато завдань, вона не відповідала поточним трендам розробки, була недостатньо гнучкою та сучасною. Мотивація Кріса Латнера, який розробляв Swift, не була націлена на витіснення Objective-C та подальше домінування в iOS-розробці. Але, побачивши результат, Apple почали інвестувати в комʼюніті, чия активність і зробила мову Swift такою, яка вона зараз. Було зрозуміло: якщо Swift «зайде» і проживе декілька версій, надалі ми рухатимемося в бік повної відмови від Objective-C. Це ми спостерігаємо зараз. Останнім часом нативні фреймворки поступово переписуються на Swift, все менше проєктів запускають на Objective-C, — а ринку вже чимало розробників, які ніколи не стикалися з цією мовою. Іде відмова навіть на рівні Apple, і це гарна тенденція на користь покращення перформансу. МІФ №2 Swift — мова, якою неможливо писати поганий код Взагалі iOS-розробка складається з трьох компонентів: власне Swift, iOS SDK та Xcode. На кожному рівні є певні правила, які не допускають помилок. Більшість проблем розробників повʼязані саме з Xcode. Порівняно з іншими програмними середовищами, Xcode має проблеми з перформансом, оновленнями та містить баги. Щодо Swift — це така ж мова як і всі інші, в яких якість коду цілком залежить від навичок розробників. В останніх версіях мови було розширено інструменти, які дозволяють відслідкувати баги, але водночас додано функціонал, який створює велике плато для нових помилок. Наприклад, раніше під час програмування вагомим джерелом помилок був менеджмент памʼяті, зараз — на рівному місці можна створити проблеми з перформансом в плані зайвих обчислень чи відмалювань UI, що призводить до інших складнощів. Щоби цього уникати, треба ретельно вивчати інструменти, з якими працюєш. МІФ №3 Після кожного оновлення Swift, iOS чи Xcode все ламається Xcode, iOS SDK та Swift справді часто оновлюються асинхронно. Раніше це було проблемою, оновлення часто ламали всю роботу. Зараз це не так. Проблеми з оновленнями Swift так само були найбільш відчутними на початку. Між першою, другою і третьою версіями різниця була настільки суттєвою, що при кожному оновленні треба було переписувати вагому частину проєкту. Починаючи з четвертої версії, зʼявляються скоріше мінорні зміни, та зберігається зворотна підтримка попередніх версій. Це свідчить про те, що Swift стає більш мачурною і стабільною мовою. Тепер, якщо девелопери хочуть згорнути певну функціональність, вони дають рік або навіть два для перехідного періоду — цього часу достатньо, щоби перейти на нову версію. Зазвичай розробники не поспішають імплементувати нові фічі в проєкти, адже більшість оновлень можна використовувати тільки на останніх версіях iOS. Наприклад, нативний фреймворк StoreKit. Комʼюніті дуже чекало його оновлення, щоби зробити міграцію з першої версії, яка на той момент була сильно застарілою та містила чимало «бородатих» багів. Анонс другої версії відбувся разом з анонсом iOS 15. На той час актуальною для користувачів була версія iOS 14. Оскільки поширеним правилом є підтримувати хоча б -1 актуальну версію, на той час більшість продуктів підтримували iOS 13 та iOS 14. Проте для повної міграції на нову версію StoreKit потрібно було відмовитись від всіх версій крім 15 або підтримувати обидві реалізації одночасно. Тому для більшості розробників вибір був очевидним — чекати анонсу та переходу користувачів на наступну версію операційної системи, iOS 16. МІФ №4 Swift повністю адаптований для проєктів за межами iOS Objective-C — мова, замкнена на операційній системі macOS. Раніше ніхто навіть не пробував використовувати її для іншої розробки. На відміну від неї Swift — open-source проєкт, який можна використовувати для завдань за межами iOS/macOS. Наприклад, на Swift пишуть короткі легкі скрипти для локальних завдань. Також IBM намагалась інвестувати в бекенд на Swift. Зрештою, з цього так нічого суттєвого не вийшло. Крім локальних невеликих проєктів, Swift залишився технологією, що не виходить за межі екосистеми Apple. Основна перешкода — потреба інвестувати в комʼюніті, яке саме собою зростати не буде. Крім того, з точку зору перформансу є значно цікавіші альтернативи для того ж бекенду. Наприклад, відносно новий Go, який показує гарні результати, в якого вже доволі хороше комʼюніті. МІФ №5 На Swift можна створювати ігри Swift — це компільована мова, написана на С++. Вона досить швидка, чудово перформить. При цьому Swift не може існувати в iOS-розробці без набору фреймворків SDK. Туди входять певні інструменти для рендеру графіки, але вони не підходять для розробки ігор, які зазвичай мають високий FPS і потребують рішень, ближчих до хардверу. Ніхто не створює ігри на тих самих фреймворках, що звичайні застосунки. Для цього є спеціальні рішення у вигляді SDK, такі як SceneKit, SpriteKit, Metal. Останній з них був вже написаний під час домінування Swift, і досі розвивається. Проте написані на цих технологіях ігри будуть обмежені платформами iOS та macOS, тому доцільність використання саме Swift для розробки ігор дуже залежить від контексту. В Unity є опція експортувати проєкт у Swift, щоби надалі мати можливість зарелізитись в App Store. Для рендеру графіки вони використовують кастомний двигун, написаний на С++, який забезпечує пряму комунікацію з хардвером. МІФ №6 SwiftUI — нове покоління UI-фреймворків SwiftUI випустили 2019 року дуже «сирим». Якщо перші версії Swift були проблемними, то на SwiftUI в принципі неможливо було створити застосунок, адже цей фреймворк не закривав базових завдань. Певною мірою SwiftUI досі залишається «недопиленим». Ряд питань, які вже відпрацьовані в iOS-розробці протягом років, не можна закрити на SwiftUI, а треба повертатися на рівень UIkit. Загалом SwiftUI може існувати в певній архітектурі. Але нормально цей функціонал працює лише у версіях, починаючи з iOS 15 (поточна — iOS 16). Тому про нове покоління, вочевидь, говорити ще зарано. МІФ №7 Єдиний код для Android та iOS неможливий Десять років тому поширеним упередженням серед розробників було те, що майбутнє — за кросплатформною розробкою. Мається на увазі поява єдиної мови програмування, на якій можна буде створювати продукт та експортувати для різних платформ. Це виглядало дуже логічним: навіщо створювати окремі продукти на двох платформах, якщо все можна зробити на одній? Проте ця ідея не «вистрілює» вже довгий час з багатьох причин. У кросплатформених рішеннях доволі багато недоліків. Сама розробка може бути складнішою — подекуди розробнику треба орієнтуватись одразу в трьох рішеннях — iOS, Android та тій тулзі, на який він пише. Також кросплатформені рішення з часом застарівають і замінюються новими, через що треба переписувати проєкт. Наприклад, застосунок Airbnb зрештою переписали з кросплатформеної розробки на нативну, вклавши в це чимало часу та грошей. Натомість зʼявилося інше рішення — кодова мультиплатформа Kotlin Multiplatform Mobile (KMM), яка дозволяє iOS-розробникам ділитися кодовою базою із Kotlin-розробниками. Теоретично у такий спосіб можна буде реалізовувати певні фічі на одній платформі і передавати іншій. Наприклад, одна команда створює якусь бізнес-логіку, ділиться з іншою, яка вже навішує свій нативний UI. Це дозволило б оптимізувати час на розробку і підтримку. В мобільному комʼюніті це одна з найгарячіших тем для обговорення.

У процесі масштабування продукт «обростає» великою кількістю даних. Бізнес має їх приборкати, аби працювати ще ефективніше. Тоді на роботу запрошують дата-аналітиків, вакансії для яких ми й хочемо запропонувати у першому літньому дайджесті. Гортайте до кінця та шукайте можливості для себе! Data Analyst (вакансія закрита) Аби обійняти цю посаду, потрібно мати мінімум рік досвіду в ролі Product Analyst, Web Analyst чи Data Analyst, працювати з SQL, а також вміти самоорганізовуватися. У кандидаті цінуватимуть вміння презентувати аналітичні результати за допомогою Tableau, Power BI та знання Python. Серед робочих завдань — A/B-тестування нових продуктових фіч, автоматизація процесів, визначення проблемних місць та точок росту, детальне дослідження поведінки користувачів. Data Engineer (вакансія закрита) Приєднуйтеся до команди OBRIO, чиїм флагманським продуктом є астрологічний застосунок Nebula — світовий лідер за кількістю завантажень у своїй ніші. Новий Data Engineer посилить мобільну команду, долучиться до побудови та підтримки нової структури. На цій позиції фахівець зможе самостійно формувати повну архітектуру та впливатиме на процес побудови ETL. Навички, які знадобляться — знання Python в контексті створення ETL data pipelines (Pandas, pyodbc), автономна робота зі сторонніми API, розуміння побудови архітектури баз даних, досвід роботи з хмарними сервісами, а також із середовищем зберігання та обробки «великих» даних. Технологічний стек: Vertica, PostgreSQL, MySQL, BigQuery, Python, Git, а ще — Firebase, Amplitude, AppsFlyer, Google Analytics. Data Analyst Від кандидата на цю позицію команда очікує володіння інструментами SQL, Python і Tableau. Серед особистих якостей оцінять вміння пояснювати складні речі простими словами, працювати в умовах невизначеності, проактивність та здатність брати на себе відповідальність. Хороша новина для світчерів: якщо маєте бекґраунд у маркетингу, фінансах чи інвестиціях, ця посада також для вас. У детальнішому описі вакансії за посиланням ви знайдете приклади завдань, склад команди маркетингової аналітики та інші умови роботи. Marketing Data Analyst (вакансія закрита) Команда Genesis Growth Accelerator будує унікальну модель роботи з перспективними продуктами — інвестує в проєкти на ранніх етапах, масштабує та допомагає створювати успішні компанії. Головне завдання на цій посаді — допомогти команді маркетингу ефективно працювати з рекламним трафіком завдяки інсайтам на основі даних. Також потрібно буде розвивати автоматизовану систему для аналітики та оптимізації трафіку, шукати точки зростання — у наявних продуктах й MVP на нових ринках. Знадобиться від року досвіду, знання Python (NumPy, Pandas) на середньому рівні, базове розуміння ключових маркетингових показників, а перевагою буде досвід роботи з SQL та API, інструментами для контролю ефективності трафіку, а також сервісами веб- і мобільної аналітики Similar Web, Sensor Tower, AppMagic. Вакансії партнерів Data Science Content Developer Продукт стартапу Codefinity — освітня платформа для навчання програмування. Окрім створення навчального контенту, аналітики найкращих на ринку навчальних програм та роботи з фідбеком користувачів, посада передбачає розробку інструментів та побудову процесів для оптимізації роботи та пошук способів гейміфікації курсів, вікторин і завдань. Серед вимог — знання Python чи R, навички управління проєктами, розуміння принципів та підходів Data Science. Analyst/Data scientist Ще один аналітик у команді Codefinity буде знаходити закономірності в поведінці користувачів на всіх етапах життєвого циклу, створить статистичні моделі для прогнозування конверсії, утримання та інших ключових показників, а також попрацює над системою рекомендацій, яка допоможе користувачам знайти найкращий контент. Для цього йому знадобляться знання Python, SQL та Excel, академічна освіта в галузі математики/статистики/комп'ютерних наук та англійська мова рівня Upper Intermediate та вище. Перевагою будуть знання економіки. Data Analyst (вакансія закрита) Solidgate — це B2B-платформа у сфері онлайн-платежів, команда якого будує фінтех-екосистему для швидких, безпечних та вигідних прийомів оплат в усьому світі. Шукають дата-аналітика, який покращить декілька внутрішніх сервісів, а саме: систему маршрутизації транзакцій між банками, скорингову модель оцінки підозрілих транзакцій та сервіс оптимізації регулярних списань для клієнтів, що працюють за моделлю підписок. Найкраще з завданням впорається фахівець з 2+ роками досвіду, технічною освітою, вмінням працювати з BI системами та знанням SQL. Технічний стек: Python (Keras, Pandas, Numpy, Matplotlib, Prophet), SQL, Tableau, AirFlow, Git, Elasticsearch, Grafana. Що почитати про роботу з даними: 7 міфів про SQL. Спростовує Data Engineer в Boosters Майже у всіх вакансіях з цієї підбірки є вимога — знання SQL. Це повноцінна мова розробки чи примітивний інструмент для вибірки даних? У чому різниця між SQL та NoSQL? Чому знати конструкції та селекти не дорівнює знати SQL? У матеріалі за посиланням відповідаємо на ці питання та спростовуємо найпоширеніші міфи індустрії. Об’єднуємо, фільтруємо, групуємо: SQL-скрипти для отримання вибірок Технічний матеріал, де послідовно та без води розповідають, як використовувати SQL для отримання вибірок з декількох джерел з потрібними обмеженнями, в потрібному вигляді й розрізах. Корисно для ознайомлення тим, хто вчиться працювати з SQL або володіє ним на початковому рівні.

3 червня 2023 року Genesis провела першу конференцію Innovating Education для представників закладів освіти. Темою заходу стала «Взаємодія держави та ІТ-бізнесу». Подія відбулася за підтримки Міністерства цифрової трансформації та Міністерства освіти і науки у співпраці з Product IT Foundation for Education. Конференція об'єднала понад 1500 освітян, які активно впроваджують цифрові технології в освіту. Під час панельної дискусії спікери обговорили напрями співпраці держави, закладів освіти та продуктового ІТ-бізнесу задля побудови сталого партнерства в освіті та економічного зростання України. «Genesis — це українська компанія, 90% наших співробітників та керівників від початку повномасштабного вторгнення залишаються в Україні. Наше майбутнє, як і майбутнє більшості українських компаній, залежить від якості освіти та рівня випускників наших університетів. Аби конкурувати з найбільшими світовими лідерами, потрібно мати освіту, рівень якої не поступається світовому. Я вдячний державі, яка інвестує багато часу та зусиль у її розвиток, але переконаний, що компанії також мають вкладатися у цей напрям», — наголосив під час конференції Володимир Многолєтній, співзасновник і СЕО Genesis. Під час дискусії учасники конференції також обговорили використання інноваційних технологій в освіті для розвитку студентів та модернізації освітнього процесу. «Поки в Україні триває війна, світ не стоїть на місці й активно розвивається. Цінність людського капіталу росте в рази. Саме тому розробити новий шлях для освіти — наш важливий виклик і завдання. Зараз, разом із командою Міносвіти, ми формуємо цю стратегію. Основний акцент — на впровадженні технологій та інновацій в освіті, цифровізації та дебюрократизації. Це дозволить впровадити сміливіші та швидші зміни, щоб наші діти здобули знання, які відповідають викликам сучасності. А кожен талановитий українець зміг реалізуватись вдома, в Україні», — прокоментував Михайло Федоров, Віцепрем'єр-міністр з інновацій, розвитку освіти, науки та технологій – Міністр цифрової трансформації України. «Будуючи нову стратегію освіти, ми детально вивчаємо кожну деталь. Якщо ми змінюємо мінімально елемент, маємо ефект впливу на мільйони. Вкладаємося в освіту — маємо економічний ефект на всю країну. Наша мета — конкурентоспроможна освіта, яка дасть максимум для кожного українця. У бізнесу та освіти є багато простору для співпраці заради цієї мети», — сказав Євген Кудрявець, Заступник міністра освіти й науки України. У події також взяли участь представники студії онлайн-освіти EdEra та провідних українських ЗВО, зокрема, КПІ ім. Ігоря Сікорського, Національного університету «Києво-Могилянська академія», Київського національного університету імені Тараса Шевченка та Київської школи економіки (KSE). Конференція Innovating Education відбуватиметься щороку та стане майданчиком для обміну досвідом між бізнесом, закладами освіти та державою з метою розвитку інноваційної країни, де технології та ІТ-освіта відіграють ключову роль.

У 2014 році Міжнародна спілка електрозв’язку (ITU) запровадила Міжнародний день дівчат в IT, який з тих пір щороку відзначається у квітні. Це свято створили, аби привернути увагу до того, що в технологічній галузі все ще є потреба у більшій кількості жінок. Сьюзан Войчицькі управляє YouTube, Гвін Шотвелл керує процесами в SpaceX, Мері Бет Вестморленд — технічний директор Amazon. Водночас індустрія все ще сприймає жінок технічних спеціальностей як виняток із правил. Ми розпитали трьох генезійок, які працюють на технічних позиціях, про їх кар’єрний шлях, освіту, дозвілля і стереотипи, з якими стикаються (або ні) жінки в IT. iOS замість хімії Своє навчання я починала в університеті Граца, що в Австрії. Після закінчення ліцею в Україні вступила спочатку до грацького коледжу, потім до вишу на спеціальність «Біомедична інженерія». Навчання в університеті було складним і насиченим. Дуже швидко я збагнула, що хімія мені не до душі. Водночас університетські лекції з інформатики та електротехніки мене дуже зацікавили. В цей час з'явилася думка перевестись в інший університет на технічну спеціальність. Після першого семестру я повернулася на літо в Україну, подала документи в КПІ на факультет інформатики та обчислювальної техніки, вступила туди, і залишилась в Києві. На другому курсі почала працювати бекенд-розробницею в сервісній компанії. В певний момент в ній просто закінчились проєкти для мене, і мені запропонували навчатися писати застосунки на Android або iOS. Мені завжди подобався дизайн iOS-апок, тому вибір був очевидним. Нові навички опанувати було не складно, маючи досвід програмування. Так я переключилася на iOS-розробку, якою займаюся і дотепер. У 2021 році мене запросили на співбесіду в PlantIn, і за місяць я вже отримала офер. Нині моя позиція — Engineering Lead iOS-команди із трьох фахівців. В нашій зоні відповідальності два застосунки для ідентифікації рослин — PlantIn та Carl. У мене як у ліда є додаткові управлінські таски: проведення рев’ю-зустрічей, one-on-one, консультування інженерів тощо. «Ніколи не знаєш, що тебе спіткає» Мені було цікаво випробувати себе в якості керівника, хай навіть невеличкої команди. Спочатку я була менеджером одного розробника, в мене був випробувальний термін на цій позиції. Тоді не було жодних чітких критеріїв і тасок саме в розрізі менеджменту для мене, тож я складала собі воркфлоу самостійно. Відштовхувалась від того, що помічала, коли була розробником — що можна додати або змінити в процесах для більшої ефективності. Окрім цього, в перші ж тижні мого випробувального терміну в ролі ліда у нас з'явилася позиція для нового iOS-інженера. Опановувала ще й проведення найму, онбордингу тощо. Найцікавіше в управлінні — ніколи не знаєш, що може тебе спіткати. Я стикнулася з великою кількістю питань, які раніше навіть не виникали у мене. Як правильно комунікувати різні рішення, розв’язувати конфлікти, або — навіть цікавіше — попереджати конфлікти, які гіпотетично можуть виникнути. Велику кількість уваги намагаюсь приділяти тому, чи всім членам команди комфортно, чи відверті вони в тому, чим вони діляться зі мною, чи вільні у вираженні своїх занепокоєнь або ідей. Для стратегічних питань в мене є менторські зустрічі із одним із СЕО PlantIn Дмитром Гринцем. Оскільки в нього більше досвіду, мені важливо отримати фідбек до моєї роботи, поставити питання щодо менеджерства або технічної складової роботи, які мене хвилюють. Я б хотіла й надалі розвиватися в компанії, і в напрямі розробки, і в напрямі управління. Мене дуже цікавить розвиток продуктового мислення та бізнес-підходи до створення IT-продуктів. Водночас мене цікавлять технології, я хочу продовжувати писати код і розвиватися в створенні застосунків. Хобі і дозвілля У вільний час я дуже люблю фотографувати — це захоплення зі мною з дитинства. Малою брала камеру в батька, потім вже мала власну. Беру її в кожну подорож. Окрім цього багато часу приділяю спорту: біг, велосипед, йога, силові тренування, бадмінтон. Коли ти весь робочий день проводиш сидячи за комп’ютером, спортивне навантаження обов’язкове. Вихідні обожнюю проводити в книгарнях із книжкою, кавою і моїм улюбленцем — джек-расселом Мортіком. Навіщо потрібна технічна освіта? Ще в останніх класах школи я вирішила, що хочу бути інженером, аби створювати щось дійсно суттєве і корисне для людей. Спочатку навіть хотіла вчитись будувати літаки, але все ж таки обрала програмування: мені завжди подобалась математика, мала високі результати з цього предмету. Для навчання обрала Могилянку, вона тоді була лідером рейтингів найкращих ЗВО для технічних спеціальностей. Технічна база в університеті була дуже якісна: профі-викладачі, корисні практичні заняття. Освіта в Україні не ідеальна, але нині я бачу, що багато чого я пам’ятаю ще з часів навчання, в той час, як деякі розробники-сеньйори лише зараз це починають вивчати — алгоритми, принципи роботи комп’ютера тощо. Окрім цього, академічна освіта значно розширила досвід, дала багато практики в різних напрямках програмування. Після другого курсу я почала працювати в маленькій компанії, а за рік потрапила у Genesis. П’ять тижнів тривав процес найму, і от — я в Boosters. Від воронок до платформ Спочатку я працювала на лендингах-воронках різних продуктів компанії. Там немає важкої логіки, переважно верстка, підключення оплати, відстеження аналітики. Водночас це дуже динамічна робота, щодня прилітали нові таски, були постійні зміни. Код, який писався до цього декілька тижнів, за секунду ставав нерелевантним. Час від часу я була там однією розробницею, тож з багатьма штуками доводилось розбиратися самостійно. Це був класний челендж, і все вдалося. Були різні складнощі, повʼязані і з підключенням внутрішніх продуктів Boosters, і з продуктами компаній Genesis, але з усім вдавалось справлятись. Не дивлячись на динаміку, задачі все ж були досить одноманітними, а мені хотілось чогось більш складного. Нині вже майже рік я працюю на іншому проєкті від Boosters. Там платформа вже більш навантажена: авторизація, декілька ролей у користувачів, адмінка, чати, більш цікава логіка, велика команда. Цей рік був дуже цікавим, тому що ми розбудовували продукт з нуля, покращували його, імплементували багато нових фіч. Мені цікаво розширювати досвід, але не хочется втрачати свій грейд. Щоби світчнутись, до прикладу, в iOS-розробку, маю наважитись почати з джунівської позиції, ще й в часи, коли і так дуже висока конкуренція. Можливо, в найближчий час спробую фулстек. Перейти одразу на мідла буде не так просто, проте челенджі мене не лякають. Дівчата і фронтенд В моїй групі в університеті близько 30% складали дівчата. Вони були розумними і талановитими програмістками, не поступалися хлопцям. Мені дивно, що люди й досі дивуються дівчатам-розробницям. По-перше, розробка абсолютно однаково дається і дівчатам, і хлопцям, це не питання гендеру. Навпаки, хлопцям може бути важче, тому що їм іноді не вистачає терпіння і наполегливості, на мою думку. Мені здається, справа в кордонах у сприйнятті себе і світу, нібито програмування справа чоловіча, і багато дівчат навіть не допускають можливості стати розробницями. Але це лише стереотипи, адже, маючи зацікавленість і наполегливість, можливо все. Я справді дивуюсь, чому в Genesis так мало дівчат-розробниць. Нещодавно натрапила на лекції тимліда Wix Олени Жукової на React fwdays. Мене надихає, коли я бачу дівчину на високій технічній позиції у великій продуктовій компанії. Мені здається, таких спікерок має бути більше в публічній спільноті фронтендерів, аби кожна з нас могла собі зайвий раз сказати: «Ти можеш бути тим, ким захочеш». «Будеш шукати жучків» Те, що я потрапила в IT, було абсолютною випадковістю, або долею, як подивитись. При вступі в мене був вибір між фінансами і кібербезпекою. Фінанси мене мало цікавили, а про кібербезпеку я нічого не знала. Коли ми з мамою прийшли подавати документи на вступ, випадково зустріли якогось викладача, який сказав — «А чого б тобі не вступити на кібербезпеку? Це цікаво, будеш там шукати всіляких «жучків». Так загалом і вийшло, тепер шукаю «жучків» у коді. В університеті у нас було дуже багато годин комп'ютерних наук, інформаційних технологій, вивчали різні мови програмування. Тому пізніше, коли я пішла на курси вивчати більш поглиблено QA, це не було щось зовсім нове для мене. Закінчила курси, працювала в різних компаніях на посадах від офіс-менеджера до QA-фахівця. Півтора роки тому я прийшла в Genesis, де основною моєю задачею стало полегшити роботу менеджерів, які займались тестуванням, взяти на себе всі етапи тестування фічей від розробників. Я стала відповідати за написання документації, побудову процесів в команді — не лише QA, а і взаємодію з розробниками. Нині я і Manual QA, і Automation QA. Автотести ми пишемо на Cypress разом із нашим фронтенд-розробником. До приходу в Genesis в мене був досить невеликий досвід написання автотестів, а тут були і можливість, і час цьому навчитися. Часто я стикаюсь із уявленням, що тестування, — це така monkey job. Типу сидиш і клацаєш кнопки. Звичайно, це не так. Чим більше людина заглиблюється в цю спеціалізацію, тим чіткіше розуміє, що й тут варто багато чого знати і вміти, аби бути класним QA-фахівцем. До того ж, нині дуже змінився ринок, тож людині без досвіду роботи досить важко знайти цікаву роботу в сфері QA. Як бути менеджером? Невдовзі після мого приходу в OBRIO наша команда почала розширюватись, водночас я залишалась єдиним QA-фахівцем. Аби не стати боттлнеком для задач, я мала найняти ще одного тестувальника. В мене не було жодного досвіду найму і управління, проведення співбесід тощо. Зазвичай я працювала як один QA, або один з двох QA, у яких різні зони відповідальності. Тут мені потрібно було розібратись, як проводити співбесіди, підготувати карту найму, скласти запитання до співбесіди, провести інтерв’ю з кандидатами, надати по ним фідбек, оцінити тестове завдання. В OBRIO є хайринг-інтенсив, де HR-фахівці допомагають майбутнім менеджерам опанувати цю навичку, розповідають, як проводити хайринг, на що звертати увагу, які існують red flags. Окрім цього, аби стати менеджером, я мала пройти Leadership Intensive. Це було дуже корисно: спікери з різних генезійських проєктів підсвічували найважливіші моменти, ділилися різноманітним досвідом, і це все можна було одразу застосувати на практиці. Також мені дуже допомогли колеги QA з інших проєктів, з якими ми спілкуємося в ком’юніті: розповіли, які питання ставити для кандидатів різних грейдів, як оцінювати софт скіли, на що звернути увагу, поділилися лайфхаками зі свого досвіду. Нашого другого QA-фахівця в команду ми взяли з першої співбесіди. Інтерв’ю проводили з різними кандидатами, але зупинились на першій кандидатурі, бо відразу було зрозуміло, що ми знайшли найкращого спеціаліста. Я дуже хвилювалась і підійшла до цього відповідально — читала книжки, складала план онбордингу тощо. Для мене було важливо, аби у людини, яка доєдналася до команди, склалось позитивне враження, щоби їй було комфортно. Подальше опанування менеджмент-скілів — один з пунктів мого PDP (плану особистого розвитку) на три наступні роки. Мій план має своєрідну T-shaped структуру. Горизонтально планую розвиватись у сферах, дотичних до моєї: вивчати продакт-менеджмент, дизайн, DevOps. Це не означає, що я через рік стану девопсом або дизайнером. Горизонтальне навчання — для ознайомлення із цими спеціальностями. А от вертикальне — це більш поглиблене опанування, власне, QA і менеджменту. Намагаюсь вкладати час і сили в самоосвіту. З цікавістю слідкую за виступами і статтями української QA Guild Master Євгенії Гловацької. Ще з корисного — подобаються книжки про Agile-тестування від тренерок Карен Грейвс і Саманти Лейонг, «Хто? Вирішуйте проблему №1» Джеффа Смарта та YouTube-канал про тестування «Попелюха». Не тестуванням єдиним Моя мама займається шиттям, і я з дитинства багато спостерігала за цим процесом. Останніми роками стала бачити в Instagram багато невеличких магазинів, які не мають власного виробництва і перепродають не дуже якісний одяг. Подумала – чому ми не можемо зробити краще? Знайшла приклади виробів, які б хотіла створити, декількох кравчинь, технолога. Ми розробили лекала і відшили першу партію одягу. Так з’явився мій нетехнічний pet-проєкт, бренд домашнього одягу Mior. Нині я займаюсь його розвитком у вільний час самостійно, проте зараз відчуваю необхідність і бажання приділяти багато уваги своєму професійному розвитку як QA-фахівця. Для магазину залишається менше часу, але замовлення постійно надходять, тому можливо скоро доведеться пошукати собі помічника для розвитку бренду.

Побудова модульної архітектури — поширений підхід для розробки масштабованих і підтримуваних проєктів для Android. Який спосіб розділення на модулі обрати? Яка їхня оптимальна кількість? Чи варто робити модуляризацію, коли проєкт на стадії MVP? Владислав Козир, Android Engineer у Headway поділився кейсом впровадження модульної архітектури для учасників комʼюніті мобільної розробки. Він розповів про теоретичні та практичні аспекти, підхід, який рекомендує Google, згадав, з якими проблемами стикнулася його команда під час імплементації рішення та як їх долала. > Модуляризація: плюси, мінуси, підводні камені > Як розбивати проєкт на модулі: бачення та рекомендації Google > Принципи розподілення на модулі > Час збірки > Як ми починали роботу над модуляризацією > Корисні матеріали Модульна архітектура: плюси, мінуси, підводні камені Як виглядає типовий флоу розробки більшості продуктових команд: отримавши дизайн певної фічі, команда береться до розробки. Якщо задача досить складна, може зʼявитися проміжний етап її проєктування всередині команди. В ідеальному світі після закінчення розробки команда передає ресурси на локалізацію, «релізиться» та починає A/B тестування. Отримавши результати, приймає рішення на основі аналітики. І зрештою має почистити конфіги та прибрати зайві івенти з аналітики. Подібний флоу мала наша команда, але зі зростанням ми стикнулися з певними проблемами. Одним із найочевидніших рішень була модуляризація. Постало питання: чи підійде це нашому кейсу, та чи буде результат вартим зусиль? Так виглядає умовна схема модулів та звʼязків між ними у нашому хедлайнері — застосунку Headway. Для збору модуля :app потрібен певний функціонал: Reader, Library тощо. Уявімо ситуацію, що команда локалізації й контенту захотіли мати окремий застосунок, в якому можна давати фідбек і переглядати його в апці. Під ці потреби добре лягає концепція модуляризації всього проєкту. Наприклад, якщо нам потрібен суто Reader (:App-demo-reader), ми беремо всі потрібні фічі, які відносяться до неї, а також модулі, повʼязані з domain- чи з data-логікою, і будуємо залежності. Демо-апка також може додатково містити модулі, повʼязані з фідбеком до контенту, — певну репортингову систему, яка дозволить слідкувати за якістю контенту, сповіщати про проблеми з ним. Плюси модульної архітектури: Краща організація коду. Це дозволяє команді масштабуватися без зайвих проблем. Легке управління та підтримка. Невеликі функціональні команди зможуть розробляти певні модулі та відповідати за певну область застосунку. Це допоможе пришвидшити розробку. Зручність тестування. Кожний модуль можна тестувати незалежно, що полегшує виявлення та виправлення проблем. Це призводить до кращого тестового покриття та надійності коду. Скорочення часу збірки. З правильним підходом до модульної архітектури можна оптимізувати час холодної та гарячої збірки. Мінуси модульної архітектури: Ретельне планування та координація. Варто завчасно продумати та перепроєктувати вашу систему, щоби мати прогнозований результат її використання і не стикатися з великою кількістю проблем. Ризики конфліктів та несумісності в управлінні залежностями. Як розбивати проєкт на модулі: бачення та рекомендації Google У ґайді з модульної архітектури Google спростовує міф про єдиний варіант розбиття проєкту на модулі за шарами (data, domain, presentation), згідно з ідеєю Clean Architecture. На думку розробників, можна так само розділяти проєкт на модулі суто за сферою використання, тобто певними фічами. Що ми маємо в такому разі: фіча, яка містить логіку Reader, має також посилатися на прогрес із бібліотеки користувача. Тобто вона буде залежною від інших фіч. У такому випадку ми збільшуємо висоту дерева модулів у проєкті, що призводить до збільшення паралельної збірки. Отже, краще розбивати проєкт і за фічами, і за шарами. Наприклад, у фічі Reader ми можемо винести в окремий модуль все, що пов'язано з книжками в domain-логіці, в інший модуль — все, що повʼязано з даними. Далі між цими модулями потрібно встановити правильні залежності та отримати гранульовані модулі. В них буде збережена необхідна логіка, яку доволі зручно тестувати та підтримувати. У цьому полягає рекомендація Google, і, забігаючи наперед, це досить вдале рішення. Принципи розподілення на модулі Про принципи SOLID знають усі досвідчені розробники — про них питають чи не на кожній технічній співбесіді. Вони допомагають правильно структурувати код, щоби можна було ефективно працювати. Роберт Мартін пропонує принципи звʼязності компонентів, які описують певні аспекти роботи з ними. В цьому контексті компонентом є певна сукупність класів, інтерфейсів. Варто звернути увагу на три принципи: REP (The Release / Reuse Equivalency Principle) — основна ідея полягає в тому, що компоненти мали окреме версіонування, щоб забезпечити повторне використання коду. Потрібно організувати класи у компоненти, які можна застосувати повторно, а потім відстежувати їх за допомогою релізу. Без номерів версій неможливо забезпечити сумісність усіх повторно використовуваних компонентів один з одним. CCP (The Common Closure Principle) — цей принцип вказує, які класи слід групувати разом. Багаторазові класи з більшою ймовірністю залежать один від одного, тому вони рідко використовуються окремо. CCP стверджує, що класи компонента повинні бути нероздільними. Це означає, що якщо один компонент залежить від іншого, то він має залежати від усіх його класів, а не від окремих з них. Коротко кажучи, класи, які не мають тісного зв'язку один з одним, не повинні зберігатися в одному компоненті. CRP (The Common Reuse Principle) — цей принцип вказує, що ми не повинні змушувати користувачів залежати від речей, які вони не збираються використовувати. Тому слід пам'ятати, що модулі в компоненті будуть використовуватися разом. Це означає, що ми маємо переконатися, що класи, які ми розміщуємо в компоненті, є нероздільними, адже неможливо залежати від одних і не залежати від інших. В іншому випадку ми будемо використовувати більше компонентів, ніж це необхідно. Ці принципи суперечать один одному, отже ми можемо дотримуватись лише двох з них або намагатися балансувати. Щоби зрозуміти, чому це складно, розглянемо їх попарно: CCP-REP є досить інклюзивними, намагаються зробити модулі більшими, відповідно збільшують зв'язність коду. Але CRP — ексклюзивний принцип, який дотримується тенденції зменшення модулів; CRP-REP — принципи, орієнтовані на повторне використання, прагнуть оптимізовувати модулі для тих команд, які їх використовують. З іншого боку, принцип CCP орієнтований на підтримку, оскільки прагне оптимізовувати модулі для тих, хто їх розробляє. Отже, ви маєте бути готовими зосередитись на двох підходах, відкинувши третій. Згідно з Робертом Мартіном, існує ще низка принципів, які стосуються саме залежностей. ADP (The Acyclic Dependencies Principle) — про циклічні залежності, а точніше їхню відсутність. Граф залежностей пакетів, модулів не може мати циклів. На схемі вище видно, що фіча С замикається на фічі А. В цьому випадку є два рішення: Використовувати окремий модуль із залежністю, від якого залежить С і А. Це рішення підходить, якщо використання цього допоміжного модуля не буде поодиноким випадком. Додати в модуль С певний інтерфейс, який дозволить комунікувати з фічею А через модуль :app. Рішення підходить для поодинокого випадку. SDP (The Stable Dependencies Principle) — принцип стабільних залежностей. Наприклад, ми маємо розповсюджені модулі для роботи з базами даних. Вони є стабільними, тому на них базується більша частина системи. Якщо певні модулі мають велику кількість використань, вони вважаються більш стабільними. Вся ієрархія залежностей має будуватися від найбільш стабільного до найменш. Тобто модуль :app завжди буде найменш стабільним, адже він змінюється від задачі до задачі, інкапсулюючи в собі частину логіки, яка потрібна для зведення певного функціонала навігації. SAP (The Stable Abstractions Principle) — абстракція підвищує стабільність. Йдеться про те, що ми завжди хочемо залежати від абстракції та змінювати тільки реалізацію певних компонентів у системі. Час збірки у модульній архітектурі Розглянемо наш граф залежностей в Gradle. Використання модулем :app фічі Reader — це ребро графу. Час збірки доволі сильно залежить від висоти нашого дерева. В холодній збірці ми спочатку збираємо найбільш стабільні модулі та розпаралелюємо побудову дерева за залежними модулями. Тобто спершу у нас будуватиметься модуль з ремоут-конфігами. Далі перебудовується модуль аналітики та паралельно створюється модуль з даними. Після цього будуватиметься модуль з фічею. Щоби зменшити кількість перебудов і покращити в цілому досвід розробки при модуляризації, важливо використовувати для великих фічей кешування залежностей Gradle. Якщо нам потрібно в модулі з аналітикою додати до фічі певний перелік івентів, то у нас будуть перебудовуватися майже всі фіче-модулі, залежні від аналітики. В таких випадках великі модулі потрібно виокремлювати, робити більш стабільними і використовувати певні залежності при необхідності або виносити публічне API. Це дозволяє зменшувати час збірки для багатомодульних проєктів і підвищує продуктивність розробки функціонала. Як ми починали роботу над модуляризацією Раніше наш проєкт можна було назвати монолітом. У ньому була виокремлена та розбита за шарами частина з data- та domain-логікою, а також стилі, графіка та дизайн системи. Через те, що ми не застосовували підхід із розділенням за фічами, така архітектура призводила до певних складнощів при збільшенні команди. Перша проблема, з якою ми стикнулися, розпочавши перехід на модульну архітектуру, — навігація. Якщо дотримуватись концепту, що всі фічі мають лежати на одному рівні та не залежати одна від одної, нам потрібно було знайти спосіб зводити виклики інших функціональностей. Для цього розділяли фічі по модулях, виносили навігацію та зводили її в модулі :app. Ми не користувалися стандартними рішеннями, запропонованими Google, а використовували власне рішення на базі підходу координаторів, адже потребували доволі гнучкої логіки у відкритті певних екранів і певних флоу, залежно від різних станів застосунку. Це дозволило сегрегувати запуск тестів на окремі модулі. Ми використовуємо підхід до модуляризації варіантів екранів або фічей. Чому це важливо в нашому контексті? Наприклад, в корені in-app модуля і payment-модуля можна викласти API для роботи з платежами, і на базі нього посилатися на певні фічі всередині in-app payment. Саме цей підхід вирішив проблему із залежностями під час A/B-тестування, а також дозволив більш ефективно зводити функціонал і зберігати ресурси окремо. Достатньо видалити умовно модуль з певним функціоналом і на цьому наша робота з прибиранням зайвого коду закінчена. Таким чином, ми зводимо до мінімуму ризики неправильної підчистки певних фічей, і це призводить до більшої стабільності. Наразі проєкт має близько 50-60 модулів, і процес модуляризації продовжується — найближчим часом плануємо розділяти data- та domain-логіку. Обираючи підхід для свого проєкту, враховуйте, що універсального рішення, яке підходить усім, не існує. Будуйте архітектуру так, щоби вона в першу чергу органічно підходила вашій команді. Корисні матеріали Martin Fowler, Presentation Domain Data Layering Robert C. Martin, Principles of OOD Robert C. Martin, Clean architecture Gergely Orosz, Building mobile applications at scale

Роль фронтенд-розробника полягає не лише у тому, щоби спроєктувати робочий інтерфейс, а й у тому, щоб бути сполучною ланкою між іншими командами. За необхідності, він розумітиметься і на дизайні, і на бекенді, і на продакт-менеджменті. Однак на цьому шляху є багато речей, які заважають робочому процесу та ускладнюють завдання. Про найбільш розповсюджені болі фронтенд-розробника розповідає Олесь Марола, Front-end Developer у Genesis Growth Team. Олесь понад чотири роки працює розробником, а у Genesis уже рік розробляє продукт для маркетологів. БІЛЬ №1 Фронтендери вищих ґрейдів стають «містками» між командами й витрачають на комунікацію багато часу та зусиль. Аби виконати об’ємне завдання, фронтенд-розробнику потрібно спілкуватися з багатьма сторонами — дизайнерами, бекенд-розробниками, тестувальниками, продакт-менеджерами тощо. Спочатку фахівець дізнається про всі особливості проєкту та взаємодії сам, якщо потрібно — ставить до відома продакт-менеджера. Однак кожна сторона має власні цілі, пріоритети та вподобання. Орієнтуватися серед різноманітних поглядів та шукати спільне може бути важко, особливо, коли ідеї або вимоги суперечливі. Непорозуміння призводять до затримок, перепрацювань і навіть конфліктів між командами — що тільки заважає розробці продукту. БІЛЬ №2 Необхідність працювати під тиском, у стислі терміни або з вимогами, які швидко змінюються. Фронтенд-розробка передбачає багато варіантів того, як можна реалізувати ту чи іншу задачу. Починається робота — і розробник працює за технічним завданням, але потім одержує фідбек від тимліда: все потрібно робити інакше. У мене був подібний кейс. Я почав працювати над завданнями певним чином, а коли пізніше зідзвонився з продакт-менеджером — виявилося, що пріоритети змінилися, й задачу потрібно робити взагалі інакше. Пара-трійка змін — і таска уже зовсім не така, як спочатку. Інша ситуація: розробник не уточнив ТЗ, самостійно додумав, як зробити краще, але у результаті код має велику складність, чого можна було б уникнути. Такі шматки коду в майбутньому буде дуже важко підтримувати. Робота в умовах нестабільності характерна для бізнесів на ранній стадії, яким треба якомога швидше запустити MVP. Колись нам потрібно було спроєктувати першу версію продукту — тобто, клієнтську частину, адмінку й бекенд — за два тижні. Через подібні історії проходить більшість молодих проєктів, яким треба налаштувати процеси, цикл розробки, комунікацію і т.д. Однак у стійкому продукті, що вже пару років на ринку подібних проблем буде менше. БІЛЬ №3 Необхідність забезпечувати сумісність з браузерами. Фронтенд-розробники мають переконатися, що їхній код працює коректно й виглядає узгоджено і в Google Chrome, і в Mozilla Firefox, і в Safari, і в Microsoft Edge, і в інших браузерах. Кожен з них має власний механізм рендерингу й може інтерпретувати HTML, CSS та JavaScript дещо по-різному. Те, що ідеально вписується в Chrome, може зламатися або відображатися інакше в Safari. Добре, що уже не потрібно підтримувати хоча б Internet Explorer. Проблема полягає не лише у відмінностях браузерів, а у їхніх різних версіях. Наприклад, якщо продукт нормально функціонує в останній версії Google Chrome — не факт, що він працюватиме в старіших версіях браузера. Буває так, що ми підтримуємо новіші версії, а потім приходить тестувальник, який робив регресії та перевіряв старіший гаджет, і виявляється, що все поламалося. Певний відсоток людей досі користується більш ранніми версіями браузерів, тому ми робимо застосунки й для них також. БІЛЬ №4 Продукт має виглядати гармонійно на різних пристроях і розмірах екранів, однак дизайн для всіх брейкпойнтів не роблять. Цей біль актуальний лише для розробників, які займаються версткою. Коли робиться дизайн, ніхто не «морочиться» з брейкпойнтами на планшети та інші нестандартні екрани. У найгіршому випадку проєктують тільки версію на десктоп, у кращому — варіант для мобайлу. Так, дизайнери малюють найбільший і найменший варіант, а проміжних немає. Інша проблема виникає, коли дизайнери працюють із не зовсім стандартними параметрами екрана. Наприклад, обирають висоту фрейму в Figma 900 пікселів. Здебільшого юзери мають гаджети з меншою висотою екрана, як-от 700 пікселів. І в такому випадку, контент з оцих 200 пікселів, просто не вміщається, а тестувальники приходять з питаннями до фронтендера. Тоді розробник має самостійно робити адаптиви для різних екранів. На перший погляд, це простіше та швидше, ніж намалювати декілька різних екранів. Однак для фронтендера це додаткове завдання та час, який він міг би витратити на розробку іншого функціоналу. БІЛЬ №5 Підтримувати чистий код у проєктах зі зростаючою складністю не завжди виходить. Особливо, коли над ним працюють понад три людини. Коли коду бракує ясності, командна робота дуже ускладнюється. Якщо база обростає дублікатами, застарілими шматками або неактуальними коментарями, то у майбутньому це може спричиняти проблеми з масштабуванням. Наприклад, щоб розробити нову фічу, код потрібно буде не просто змінити, а переписати. Через це завдання, що мало зайняти годину, розтягується на всі чотири. Крім того, така база ускладнює залучення новачків до проєкту. І він, і тимлід витрачатимуть час і зусилля на занурення у процес — а продуктивність страждатиме. В ідеальному світі на проєкті має бути архітектурний підхід, а всі шорсткості виправляються рефакторингом коду. Однак тут є інша проблема: на це не завжди є час, тож завдання ризикує перекочувати до категорії «ми колись до цього повернемося». БІЛЬ №6 Кодова база проєкту застаріла, їй бракує належної документації або документації загалом. Проблема, яка пов’язана з попередньою. Якщо чистий код працює без збоїв, написаний у єдиному стилі, добре задокументований та відформатований, то застаріла кодова база призводить до труднощів у імплементації рішень, збільшення часу подальшої розробки, складнощів оновлення ПЗ тощо. Наслідки можуть відчуватися не одразу, а за кілька місяців чи навіть років, коли вже вийшла купа мажорних апдейтів, оновилися технологічні пакети й додалися нові бібліотеки. Відрефакторити великий проєкт майже неможливо. Ще більше ускладнює проблему неактуальна документація. Розробникам доводиться витрачати багато часу на розшифровку архітектури системи, структури коду тощо. Колись нашій команді дістався подібний проєкт «у спадок». Спочатку здається, що все зроблено добре, а потім настає час оновлювати код або додавати якийсь функціонал — а це довго й боляче. БІЛЬ №7 Дизайнери роблять макети, але деякі елементи не працюють так, як їм би хотілося. Під час проєктування клієнтської частини важливо пам’ятати: інтерфейс повинен не лише мати гарний вигляд, а й працювати певним чином. Однак деякі дизайнерські рішення дуже важко перенести та реалізувати так, щоби вони гармонійно виглядали в коді, у верстці, а ще — коректно відображалися на різних гаджетах. Як і дизайнер, розробник добре розуміється на UI, але завдяки знанням у програмуванні здатен помітити недоліки ідеї, які заважатимуть реалізації. Саме по собі рішення може бути вдалим, але воно не працюватиме так, як задумувалося. Або ж під нього доведеться писати тонну коду, який буде важко масштабувати та підтримувати в майбутньому. Якщо дизайнер не впевнений у можливості реалізувати якесь рішення, краще проконсультуватися з розробником заздалегідь. Інакше останньому доведеться самому переробляти макет та шукати рішення, що займатиме багато часу.

Згідно з опитуванням освітнього департаменту Genesis, 95% студентів українських ЗВО відчувають нестачу практичної складової в навчальних програмах. Тому університети активно запрошують до викладання спеціалістів із індустрії. Проте читати курс на постійній основі та одночасно будувати карʼєру — складно. Щоби підсилити академічну експертизу бізнес-досвідом, освітній департамент Genesis допомагає зацікавленим співробітникам створювати навчальні дисципліни та запускати курси в університетах-партнерах. Прийти на пару до студентів та викласти матеріал — лише вершина айсберга. «Під водою» — багато годин додаткової роботи, частину якої бере на себе команда Genesis Education. Андрій Скрипник, СЕО Promova, Олег Лавренко, СТО в AMO, та Олесь Дібрівний, Unity Developer в Keiki, розповіли, як повернулися до аудиторій університетів, щоби викладати. Вони описали, яким ключовим скілам намагаються навчити своїх студентів, що в цьому процесі найскладніше та чому масштабували викладання на свою команду. Як полегшити життя розробникам-викладачам та зекономити їм до 15 годин щотижня, поділилася Каріна Плахотнюк, Education Project Specialist в освітньому департаменті Genesis. Чи можна викладати без бюрократії Менеджер освітньої програми допомагає тим, хто вже викладає в ЗВО, а також залучає нових спеціалістів із сильною експертизою. Якщо у когось з потенційних лекторів немає відповідного наукового ступеня, щоби самостійно вести курс, освітня програма запускається спільно із представником університету. «Наша команда намагається створити такі умови, щоб лектори могли сфокусуватися суто на викладенні матеріалу та перевірці знань. Для цього треба зняти зайве навантаження — від багаторівневих погоджень програми, допомоги з веденням документації до комунікації з кафедрою та студентами. Так нам вдається зекономити нашим лекторам багато годин щотижня», — Каріна Плахотнюк, Education Project Specialist. З 2019 року Genesis Education інтегрувала 20 дисциплін в освітній процес КНУ імені Тараса Шевченка, КПІ ім. Ігоря Сікорського та Києво-Могилянської академії у напрямах iOS, DevOps, Back-end, GameDev, Product & Business Analytics. Загалом до викладання долучилися близько 50 спеціалістів з екосистеми бізнесів Genesis та компаній-партнерів. Про відрахування, три формати навчання та соціальний борг У старших класах мені довелося змінити школу через переїзд у Київ. У новому закладі рівень викладання був значно нижчий, тому мені стало нецікаво, і я почав працювати на фрилансі. Повністю сфокусувавшись на перших проєктах, я розлінився вчитися. З цим настроєм вступив до КПІ на ФІОТ, де очікував, що мені все будуть закривати, як і до цього. Звідти мене відрахували після першого ж семестру, про що заступник декана повідомив лише після двох тижнів нового семестру. Я ходив на пари та навіть не знав про відрахування. Наступного року я знову склав вступні іспити та поновив навчання. Працюючи ще зі школи в розробці, я міг порівняти те, що викладають, з реальними завданнями в продакшені. Ми постійно жалілися на те, що не вистачає лекторів-практиків, які б давали актуальні знання. Коли я закінчив магістратуру 2017 року, мені зателефонувала та сама людина, яка шість років тому мене відрахувала, і запропонувала викладати мобільну розробку на ФІОТ. Я сказав, що подумаю, хоча в ту ж секунду розумів, що моя відповідь — «так». По-перше, це було цікаво. По-друге, повернути знання до альма-матер я вважав своїм соціальним боргом. По-третє, я стільки років шкодував про нестачу викладачів-практиків, відмовитись від цієї пропозиції було б лицемірством. Для мене КПІ — це особливе місце, де можна доторкнутися до чогось давнього та стати частиною великої історії. Більшість бюрократичних та організаційних питань з відомостями, розкладами, погодженням мені допомагали закривати на кафедрі. Моїми завданнями було прийти, прочитати лекцію, відповісти на запитання, перевірити знання та прийняти іспит в кінці семестру. З 2019 року з менеджментом курсу допомагала команда Genesis Education. Головний секрет усіх публічних спікерів: у той момент, коли ти починаєш готувати матеріал, тобі здається, що ти повний нуль у цій темі. Тоді шукаєш інформацію, читаєш, глибше розбираєшся. Це і було моєю мотивацією: покращувати знання в тому, що я любив. Для мене це був win-win: я навчаю й одночасно навчаюся сам. Курс, який я читав, був спеціалізованим з фокусом саме на iOS. До 3-4 курсу студенти зазвичай обирали спеціалізації (бекенд / фронтенд / геймдев), тому тих, кого цікавила саме мобільна розробка, було не так багато — до 30%. Я пропонував студентам обʼєднуватись у проєктні групи та створювати мобільні застосунки в команді, де кожен виконував свою частину роботи. Наприкінці курсу вони захищали свої проєкти. За весь час я відрахував десь трьох-п'ятьох людей через те, що вони нічого не робили. Коли ти весь семестр не ходиш, не здаєш жодної роботи, а потім приходиш на другу перездачу іспиту і питаєш, чи можна щось встигнути зробити, так нічого і не підготувавши, відповідь: «Ні, вибач, не можна». Один з найважливіших скілів розробника — швидко знаходити інформацію. Не можна знати всього, але треба мати загальне уявлення, передбачати майбутні кроки та вміти шукати відповіді. Цьому я і навчаю студентів. З початком карантину навчання перейшло в онлайн. Тоді ж проєкт Promova почав стрімко зростати, і робоче навантаження значно виросло. Ми спробували показувати лекції в записі та додатково проводили інтерактиви, Q&A-сесії та офлайн-зустрічі. Це було три різних досвіди, найкращим з яких вважаю офлайн. Раніше я багато програмував та брав участь у розробці особисто. Останні два роки роль СЕО потребує все більше менеджерського часу, і приділяти достатньо уваги технічній стороні вже не можу. Відповідно читати деякі лекції запрошую колег-розробників із Boosters, а сам закриваю інші питання та паралельно міркую над новим курсом, більш релевантним до того, чим я займаюся сьогодні. Якщо викладати те, з чим ти не працюєш постійно, це перейде в той самий формат, на який я жалівся, коли був студентом. Про масштабування, несподівані запитання та студентські дедлайни Перший досвід лектора я отримав всередині команди: розповідав девелоперам про інфраструктуру, а тестувальникам та DevOps-інженерам — про розробку. Це підвищило ефективність команди, і я почав масштабувати досвід — викладати в рамках внутрішніх і зовнішніх освітніх програм з командою Genesis Education. Згодом — вже в університетах. Один із викликів — «запакувати» у 16 лекцій предмет, який вивчають роками. Я намагаюся не давати занадто складних штук. Головне, щоби слухачі отримали загальне розуміння та контекст, що це за дисципліна, для чого вона потрібна, і що треба надалі вивчити, щоби реалізуватися в цьому домені. Прогрес завжди видно по студентах: спочатку їм взагалі нічого не зрозуміло, а з кожною наступною лекцією — лише точково. Перед запуском курсу я морально готувався, що не всім буде цікаво. Але після першої лекції не очікував, що так багато студентів будуть уважно слухати та ставити багато запитань. Якось на одній з лекцій про життєвий цикл софта ми розглядали різні підходи колективної розробки в рамках одного репозиторію. В одному з флоу від студентів прилетіло питання: а як керувати стейтментом бази даних, маючи лише одну гілку, щоби нічого не зламалося? Це дуже влучне питання рівня advance, яке мене приємно вразило. Довелося поміркувати, перш ніж дати відповідь. Питання з «домашками» — це те, що мене веселить і спантеличує одночасно. На кожному курсі ми чуємо класичні «відмазки» на кшталт «у мене боліла нога», «возив кота бабусі мого друга до ветеринара» тощо. Коли на роботі хтось з команди не вклався в дедлайн, знаєш що робити, а зі студентами — ні. З одного боку, не хочеться їх демотивувати, а з іншого — їм корисно знати, що таке дедлайн. Спочатку я викладав самостійно, а потім із командою вирішили, що було б корисним челенджем розширити викладацький склад. Так, минулого року ми прочитали два великих курси, який викладали 10 людей з AMO. Участь в наймі, співбесідах та перевірка тестових завдань — суттєва складова роботи на менеджерській позиції. Часто помічаю, що кандидати можуть виконувати певні задачі, але не мають глибини розуміння теми, не вміють працювати з оптимізацією, переосмислювати процеси. Умовно вони знають один інструмент та «затикають ним усі діри». В ІТ це працює не так. Замість чергового фреймворку важливіше розібратися в Computer Science та інших фундаментальних речах. Тому викладання для мене — це інвестиція в те, щоби вивести ІТ в Україні на новий рівень. А якщо пощастить, колись я побачу на співбесіді свого колишнього студента, який розумітиме інженерну культуру нашої компанії. Про здобуття PhD, відмову від теорії та досягнення студентів Моя історія викладання почалася ще до того, як я став розробником. В аспірантурі Державного університету телекомунікацій, де я навчався, викладання — одна з вимог. Протягом першого семестру я викладав C# та технічну англійську, з наступного року — Unity. У мене було близько шести пар на тиждень: я читав лекції для чотирьох груп, проводив практичні, лабораторні та приймав іспити. Фактично це була фултайм-робота. Паралельно я писав дисертацію за спеціальністю «Компʼютерна інженерія». Викладаючи, я швидко та глибоко занурювався в матеріал. Це дало змогу невдовзі знайти роботу в геймдеві та посилити експертизу практикою. Цього року разом з командою Genesis Education ми запустили курс з геймдеву в КПІ. В ньому я не відповідаю за організаційні моменти та не комунікую з університетом, тому стало значно легше. Щороку я переробляю курс. Причина не в тому, що інформація застаріває, а скоріше через перфекціонізм. Постійно практикуючи свій предмет, я вивчаю нові підходи, прокачую знання, і хочеться ділитися цим зі студентами. Згадую перший семестр, і стає дещо соромно за рівень матеріалу — зараз здається, що я давав недостатньо практики, оскільки ще не працював в цій сфері повноцінно. Коли зростаєш як розробник, у тебе змінюється думка, що потрібно студентам. Згодом я зосередився на практичних заняттях, адже специфіка предмета в тому, що одразу треба пробувати писати код. Курс побудований таким чином, що в кінці семестру студенти створюють власні ігри. Найцікавіше у викладанні — спостерігати прогрес студентів. Дуже радію, коли вони знаходять роботу за спеціальністю або беруть участь в геймджемах і показують там високі результати. Один зі студентів якось зробив хороший піксельний арт, і в нього вийшла дійсно крута гра. Але навіть найбільш мотивованим студентам треба не давати розслаблятися, бо вони швидко стають лінивими. Найскладніше — знайти в собі мотивацію викладати, якщо студенти цього не хочуть. Чим кращим професіоналом ти стаєш, тим більшим стає барʼєр зі студентами, адже складні речі здаються простими. Я регулярно питаю, чи підходить їм швидкість викладання матеріалу, намагаюся адаптуватися під них. Найпоширеніше питання студентів: «Я зробив так само, але воно не працює. Чому?». Також вони часто питають про нові технології, з якими я не знайомий. Річ у тім, що більшість оновлень в Unity випускаються доволі «сирими», і протягом перших кількох років їх не використовують в проєктах. Студенти дуже люблять слідкувати за ними. Як заощадити лектору до 15 годин на тиждень. Задачі менеджера освітньої програми Менеджмент освітнього процесу займає значно більше часу, ніж сам освітній процес. Він починається не з підготовки до першої лекції, а мінімум за дев'ять місяців до цього. Щоби запустити курс, компанія має пройти попередні етапи та заручитися підтримкою університету загалом та окремих факультетів. Для проходження цієї процедури в Genesis створена окрема команда. Вона знайомиться з факультетом, обговорює спільні цілі, шукає точки дотику між експертизою компанії та предметами, що викладаються. Надалі укладається договір про співпрацю з університетом та починається комунікація з гарантами освітніх програм, завідувачами кафедр та адміністраціями факультетів. Якщо все складається успішно, далі команда проходить етапи погоджень, планування та оформлення відповідної документації, перш ніж лектор зможе прийти до студентів та поділитися знаннями. Етапи запуску навчального курсу: Етап 0. Знайомство з університетом, попередні переговори та підписання меморандуму про співпрацю. Етап 1. Визначення точок дотику, де практична експертиза спеціалістів компанії доповнюватиме академічну складову університетських програм. Планування навчального року та затвердження курсу. Етап 2. Планування дисципліни та підготовка програми (вивчення ринку, створення плану, погодження з лекторами). Етап 3. Допомога з методичною документацією для ЗВО та студентів. Етап 4. Підготовка навчальних та методичних матеріалів (презентацій до лекцій, домашніх завдань, лабораторних), погодження з представниками університету. Етап 5. Організація зручних форматів комунікації між студентами, викладачем та менеджером (створення чатів, розсилок, роадмапів, налаштування платформ — GitHub, GitLab, Classroom тощо). Етап 6. Знайомство зі студентами, встановлення «правил гри», написання інструкцій. Етап 7. Запуск та ведення курсу. Етап 8. Моніторинг. Етап 9. Підбивання підсумків й закриття відомостей. Етап 10. Ретроспектива та аналіз результатів. Лектор-експерт від компанії залучається до створення актуальної програми та підготовки презентацій. Менеджер проводить глибоке дослідження, який матеріал викладається у міжнародних університетах та комерційних курсах. Оскільки спільні навчальні програми ми запускаємо з 2019 року, то можемо аналізувати попередній досвід та опитувальники студентів. З цим дослідженням менеджер приходить до лектора, і ми фіналізуємо програму. Концепція програми може валідуватися з викладачами та спеціалістами кафедри університету. Протягом останніх років заняття перейшли в онлайн. Тому завдання менеджера — подбати про запис відео та публікацію в правильних джерелах, організацію стримінгу, підключення техніки, за потреби — монтаж та корекцію звуку. Усі студенти мають вчасно отримати посилання та доступи. Менеджер бере на себе усю комунікацію зі студентами, відповідаючи на численні запитання: «коли лекція», «яке домашнє завдання», «я забув здати лабораторну, що мені робити», «у мене не відкривається посилання», «а де знайти матеріали», «а коли будуть результати тестів» та багато інших. Часто студенти питають одне й те саме, адже вони доволі неуважні. Цей шквал запитів важливо систематизувати. Якщо у викладача від компанії є потреба, менеджер може допомогти йому підготуватися до виступу, зробити кілька прогонів лекції або допомогти опрацювати фідбек студентів. Наприкінці кожного семестру команда проводить ретроспективу та підбиває підсумки. За кілька років шляхом проб і помилок ми знайшли справді зручний формат онлайн-освіти з використанням сучасних інструментів. Протягом навчального семестру, менеджер допомагає із документацією в частині, погодженій з кафедрою: ​оформлення тематичних планів, шкал оцінювання; написання анотації до дисципліни на платформі; заповнення усіх відомостей, виставлення балів, звіряння зі списками; написання невеликих звітів для кафедр чи координаторів після закінчення курсу. Якби розробник робив усе це самостійно, це б займало близько 15-20 годин на тиждень. Завдяки залученню менеджера вдається скоротити цей час до 3-5 годин. Це дає змогу залучати до викладання спеціалістів високого рівня з унікальною експертизою. Від освіти, яку сьогодні отримують студенти технічних спеціальностей, залежить те, як виглядатиме ІТ-індустрія України за 10 років. Розуміючи це, Genesis системно інвестує в освітні програми ресурси та час найкращих спеціалістів Senior- та C-level. Вони готові дати студентам те, чого самі не отримали в університетах — сучасні практики розробки та експертизу розвитку ІТ-продуктів на глобальних ринках.

Коли тільки набиваєш руку у програмуванні, важлива швидкість: чим скоріше розробник початківець опанує всі необхідні технології, тим швидше зможе братися до комерційної роботи. Розвиток розробників з досвідом дещо відрізняється. Тут ефективніше заглиблюватися в окремі аспекти розробки, відточувати уже наявні знання та заповнювати прогалини. Що почитати в першому та другому випадках? Зібрали об’ємний список із 15 книжок разом з Марією Образцовою, Frontend Developer в Universe з екосистеми Genesis. Марія вже близько 2 років працює в команді Universe. За цей час вона розвивала освітню платформу Wisey, а сьогодні працює над новим вебпродуктом. > «Head First. Програмування на JavaScript». Ерік Фрімен, Елізабет Робсон > «Розумніший спосіб вивчати JavaScript». Марк Майєрс > «JavaScript для дітей. Веселий вступ до програмування». Нік Морган > «Як влаштований JavaScript». Дуглас Крокфорд > «Javascript та jQuery. Інтерактивна веброзробка». Джон Дакетт > JavaScript.Info > «JavaScript: The Definitive Guide» by David Flanagan > Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People by Aditya Y. Bhargava > High Performance JavaScrip by Nicholas C. Zakas > «You Don’t Know JS» by Kyle Simpson > «Effective JavaScript» by David Herman > «Modern JavaScript for the Impatient» by Cay Horstmann > «JavaScript Patterns: Build Better Applications with Coding and Design Patterns» by Stoyan Stefanov > «Maintainable JavaScript» by Nicholas Zakas > «Programming JavaScript Applications: Robust Web Architecture with Node, HTML5, and Modern JS Libraries 1st Edition» by Eric Elliott > Як вчити JavaScript за книжками Для початківців ЕРІК ФРІМЕН, ЕЛІЗАБЕТ РОБСОН «Head First. Програмування на JavaScript» Англ: Head First JavaScript Programming: A Brain-Friendly Guide by Eric Freeman, Elisabeth Robson Об’ємний посібник, де зібрана ключова інформація про JavaScript: від основ до складніших тем — типів, масивів, функцій, об’єктів та DOM. Зачіпають також успадкування прототипів та тестування продуктів. Переваги: книга гарно підійде для людей, що люблять вікторини, головоломки та вправи для закріплення матеріалу; послідовна структура, що дозволяє засвоїти простіші теми, перш ніж перейти до складних. Недоліки: інформації про популярні фреймворки та бібліотеки JS майже немає; деякі матеріали можуть бути не актуальними. МАРК МАЙЄРС «Розумніший спосіб вивчати JavaScript» Англ: A Smarter Way to Learn JavaScript by Mark Myers Посібник для початківців із акцентом на розуміння та запам'ятовування правильного синтаксису. Книжка будується на постійному закріпленні теоретичних знань через велику кількість додаткових завдань. Як обіцяє Марк Майєрс, на практику йде у два-три рази більше часу, ніж на читання. Переваги: інформацію подають невеликими «порціями» — середньостатистичний учень зможе засвоїти один розділ за 10 хвилин; є сайт із вправами для кожного розділу, де можна попрактикуватися й закріпити все, про що ви дізналися; матеріал пояснюють простою нетехнічною англійською мовою. Недоліки: деякі поняття можуть бути не актуальними. НІК МОРГАН «JavaScript для дітей. Веселий вступ до програмування» Англ: JavaScript for Kids: A Playful Introduction to Programming by Nick Morgan Попри те, що книга орієнтована на дітей, вона може слугувати хорошим посібником для початківців будь-якого віку. Розповідь починається з основ, таких як робота з рядками, масивами та циклами, а далі автори переходять до складніших тем — наприклад, створення інтерактивності з jQuery та малювання графіки за допомогою Canvas. «Це зовсім базове видання, де початківці можуть ознайомитися з синтаксисом та базовими поняттями мови», — каже Марія Образцова. Переваги: мова викладання проста та зрозуміла; книжка дає достатньо знань, щоби самостійно розробити просту гру, зокрема Find the Buried Treasure, Hangman чи Snake; швидкий спосіб розібратися, чи подобається вам програмування загалом — і як процес, і як результат. Недоліки: деякі технології, наприклад, Canvas, можуть бути неактуальними для стека комерційної розробки; деякі приклади з книги не працюють так, як описано. ДУГЛАС КРОКФОРД «Як влаштований JavaScript» Англ: JavaScript: The Good Parts by Douglas Crockford Існує думка, що JavaScript має більше недоліків, ніж переваг. Однак Дуглас Крокфорд, який відіграв значну роль у розвитку JS, звертає увагу на іншу, «хорошу» частину мови — надійну, читабельну, підтримувану, придатну для створення масштабованого та ефективного коду. Так, у книжці пояснюється робота із синтаксисом обміну, функціями, методами, масивами, регулярними виразами тощо. «На початку складно зрозуміти, що саме вчити, на чому зосереджуватися. Ця книжка допомагає не витрачати ресурс на пошук базової теорії в різних місцях, а дає впорядковану й доступну інформацію», — каже Марія Образцова. Переваги: розбір вдалих прикладів та помилок — з поясненням, як їх уникати; «сухої» теорії небагато, й вона добре структурована. чимало прикладів з досвіду автора. Недоліки: деякі приклади абстрактні, їх важко пов’язати з реальним програмуванням. подекуди інформація може бути заскладною, і не вистачає авторської думки та пояснень. ДЖОН ДАКЕТТ «Javascript та jQuery. Інтерактивна веброзробка» Англ: JavaScript & JQuery: Interactive Front-End Web Development by Jon Duckett Книжка насичена візуальними матеріалами. Вони дозволяють краще відчути, як зробити вебсторінки більш інтерактивними, а інтерфейси — більш інтуїтивно зрозумілими. Автор на прикладах показує, як з нуля проєктувати сценарії JavaScript, JavaScript API, а також jQuery. Щоби ефективно опрацювати книжку, знадобляться базові знання HTML та CSS. Переваги: проста та зрозуміла мова; багато візуальних елементів роблять взаємодію з книгою цікавішою. Недоліки: трапляються приклади з помилками, яких новачки можуть не помітити. JavaScript.Info (англ. та укр.) Онлайн-підручник із сучасного JavaScript, що містить прості, але докладні пояснення з прикладами та завданнями. Є інформація про замикання, DOM, події та об'єктно-орієнтоване програмування. «Це не зовсім книжка, але сайт можна прирівняти до повноцінного посібника по JS», — каже Марія. «По структурі він як звичайне видання: розділений на три великі блоки та маленькі глави у них. Довідник влаштований так, що при послідовному читанні знання нашаровуються одне на одне — і уявлення про мову стає більш комплексним. Я багато користувалася ним, коли вчила JavaScript, але до нього можуть звертатися і мідли, і сеньйори, якщо потрібно освіжити знання», — додає розробниця. Для мідлів та сеньорів DAVID FLANAGAN «JavaScript: The Definitive Guide» Книга стане справді настільним довідником, адже охоплює всі нюанси роботи з мовою — від основних операцій зі значеннями різних типів до рушіїв. Серед інших понять, які охоплює автор — замикання, графіка та прототипування, а також суміжні з JS теми, як-от регулярні вирази й Node.js. Переваги: актуальна та сучасна інформація — автор сім разів перевидавав книгу, аби вдосконалити кожен розділ; пояснення підійдуть як для тих, хто працює з клієнтською версією JS, так і для тих, хто використовує серверну; багато релевантних прикладів. Недоліки: у книзі висвітлено ВСЮ мову: і сучасні підходи, і застарілі концепції, які уже не використовуються (однак автор говорить про це); місцями книжка заскладна та дуже деталізована. ADITYA Y. BHARGAVA Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People Книжка не висвітлює безпосередньо JavaScript, але вважається одним з найкращих видань про алгоритми та структуру даних. Вона складається з 11 розділів, де йдеться про сортування, рекурсію, хештаблиці, зв’язані списки, а також динамічне програмування. «Її корисно прочитати як джунам, так і мідлам та сеньйорам, які прагнуть зробити свої програми більш логічними», — каже Марія. Переваги: проста та зрозуміла мова, поняття введені у контекст; малюнки допомагають краще уявити структуру роботи алгоритмів та структур даних; багато прикладів. Недоліки: мало уваги приділено структурам даних, які є аналогами алгоритмів, як-от бінарне дерево, бінарне дерево пошуку, трійки тощо; тема про динамічне програмування розкрита не повністю. NICHOLAS C. ZAKAS «Нigh Performance JavaScript» Динаміка сайтів будується в основному на JavaScript — і це одна з найцікавіших частин роботи з мовою. Втім, є мінус — через це сторінки можуть завантажуватися повільніше або взагалі не працювати, що погіршує User Experience. Книжка допомагає зрозуміти фактори, що негативно впливають на продуктивність, та пропонує прийоми й лайфхаки, які допомагають усунути проблеми. Переваги: багато важливої інформації про обробку даних та об’єктів; описаний досвід об’ємний та цікавий, адже Ніколас Закас долучив до написання рок-зірок програмування — Росса Хармса, Жульєна Леконта, Стівена Левітана, Стояна Стефанова та Метта Суїні. Недоліки: деякі підходи зводяться до шаблонів програмування, які не є унікальними для JavaScript; частина порад уже застаріла. KYLE SIMPSON «You Don’t Know JS» (англ.) Серія складається з шести книг, які слід читати послідовно. Так, перша книжка, «Up & Going» охоплює основи мови, включаючи типи, значення та змінні. Друга — «Scope & Closures» — заглиблюється в роботу системи області видимості JavaScript, і в те, як працюють закриття. Останні підручники серії працюють зі складнішими поняттями. Наприклад, п’ята книга, «Async & Performance», присвячена асинхронному програмуванню та оптимізації продуктивності, а остання «ES6&Beyond» розповідає про нові можливості, представлені в ECMAScript 6 та пізніших версіях мови. «Я зверталася до одного з видань, коли розбиралася в об’єктах і класах. Теорія описана досить просто та зрозуміло. Крім того, там є нюанси, які цікаво дізнатися для загального розвитку, і які ти не вивчаєш, коли треба швидко опанувати мову, щоб виконувати робочі завдання», — каже Марія. Переваги: кожна книга написана під певний рівень знань; завдання та приклади релевантні до реальної роботи розробника; численні приклади коду з докладними поясненнями. Недоліки: подекуди інформація може бути застарілою. DAVID HERMAN «Effective JavaScript» (англ.) Девід Херман, який багато років працює над стандартизацією мови, надає 68 перевірених підходів до написання кращого коду на JavaScript. Він пояснює нюанси роботи з масивами та об’єктами, особливості ООП, функції та семантику змінних — та підкріпляє теорію конкретними прикладами. Переваги: містить інформацію, щоб заповнити прогалини у фундаментальній теорії JavaScript; насичена прикладами з особистої практики автора, а також рекомендаціями для створення застосунків різного масштабу. Недоліки: іноді пояснення написані заскладною мовою. CAY HORSTMANN «Modern JavaScript for the Impatient» (англ.) Вичерпний посібник із JavaScript ES6 та сучасніших версій мови, де зібрано практичні рекомендації та зразки коду. Книжка допомагає ефективно використати всі новинки JavaScript, уникаючи помилок і застарілого синтаксису. Книга підійде для тих, хто вже працював з іншими мовами та хоче швидко зрозуміти JavaScript. Переваги: можливість опанувати сучасний стандарт JS без занурення у старіші версії; «ігрова» система навігації з натяком на «Алісу в Дивокраї». Картинки позначають складність розділів: Білий Кролик — основи, Аліса — матеріали середнього рівня складності, Чеширський кіт — просунуті теми, Капелюшник — теми «із зірочкою» для найбільш зацікавлених. Недоліки: матеріал викладено не зовсім послідовно: спочатку деталі, потім загальна картина; інформація про відмінності JS від інших мов надається лише в третьому розділі. STOYAN STEFANOV «JavaScript Patterns: Build Better Applications with Coding and Design Patterns» (англ.) Як видно з назви, основна тема книжки — шаблони проєктування для масштабованого та якісного коду. Як класичні, так і досить специфічні. Крім того, Стефан Стоянов наводить способи обійти недоліки мови. Видання буде корисним, якщо ви — досвідчений розробник, який прагне розв’язати проблеми, пов’язані з об’єктами, функціями, успадкуванням та іншими специфічними для мови категоріями. Переваги: практичні та детальні поради щодо реалізації кожного розглянутого шаблону; автор застерігає від практик, які створюють більше проблем, ніж вирішують, та описує їх; корисна і тим, хто використовує JS для клієнтської частини, і тим, хто працює з серверною. Недоліки: застарілий синтаксис. NICHOLAS C. ZAKAS «Maintainable JavaScript» (англ.) Командна розробка вимагає уніфікованого підходу до програмування, впевнений Ніколас Закас. Колись він був солорозробником, пізніше — став Tech Leader в Yahoo! Маючи різноплановий досвід, він ділиться низкою порад — про стиль коду, програмування та автоматизацію. Рекомендації дозволяють всім охочим навчитися писати код, з яким буде комфортно працювати іншим членам команди. Переваги: видання об’єднує багато різних матеріалів у своєрідну дорожню карту та структурує їх; корисно для команд, які працюють із масштабними проєктами на JavaScript. Недоліки: деякі приклади можуть бути занадто простими для досвідчених розробників. ERIC ELLIOTT «Programming JavaScript Applications: Robust Web Architecture with Node, HTML5, and Modern JS Libraries 1st Edition» (англ.) Буває так, що внесені зміни в одній частині коди впливають на роботу застосунку в зовсім іншому місці, або взагалі його ламають. Ерік Еліот вчить писати стійкий код, з яким буде легше працювати в міру зростання кодової бази. Він показує, як додавати клієнтські та серверні функції до масштабних вебзастосунків на JavaScript без негативного впливу на решту коду. Переваги: описано багато сучасних технологій — як відомих, так і не дуже популярних; багато прикладів із фрагментами коду; ґрунтовний огляд способів створення надійної архітектури вебзастосунків. Недоліки: деякі методи та підходи описані без оцінки автора та прикладів використання, тому важко зрозуміти, до якого контексту підходить та чи інша технологія; досить вузька цільова аудиторія. Найкориснішою вона буде для архітекторів вебзастосунків. Як вчити JavaScript за книжками Чимало інформації можна нагуглити, але вона невпорядкована та непослідовна. У книжках автори цю проблему вирішують. Втім, на початковому етапі самих лише книжок недостатньо, впевнена Марія Образцова. «Я б радила поєднувати читання з пошуком актуальної інформації, переглядом статей та документації. При цьому книжку не обов'язково читати від початку до кінця. Можна просто скористатися її змістом як переліком тем до вивчення, а далі гуглити матеріали для кожної з них. Або читати окремі розділи, наприклад, про складніші концепції програмування», — каже вона. На більш просунутому етапі варто обирати літературу, що стосується верхньорівневих концепцій та речей, які змінюються не так часто, як синтаксис. «Розробники, що працюють з JS, спочатку користувалися класами. Але в якийсь момент підхід змінився — і всі перейшли на функції. Глобально мова залишилася такою ж, але програми тепер пишуться трохи інакше. Багато прикладів зі старіших книжок можуть бути нерелевантними, тож за ними ефективніше вивчати алгоритми та підходи до написання програм. Такими є, наприклад, книги Ніколаса Закаса — там мало про синтаксис, і багато про мову загалом», — говорить Марія. Вона додає, що зараз користується книгами більш вибірково та усвідомлено. «Якщо мені радять книжку і кажуть, що там добре описано певний алгоритм, то я беру і читаю конкретно про цей алгоритм. На жаль, читати книги повністю немає часу, а подібний метод дає змогу швидко та ефективно заповнити прогалини в знаннях».