Archives

Що почитати: дайджест кращих блогів за 2020 рік

Якщо кінець року – кращий час, аби підбивати підсумки, то початок нового – кращий час аби згадати найкраще!

Тож зустрічайте добірку блогів з рубрики BlogSpot за 2020 рік: актуальні теми, цікаві думки, поради та гайди від експертів. Приємного читання!

Як перестати хвилюватись та не перетворити навчання на прокрастинацію

Автор: Тетяна Хряпіна, Director, CEE Learning & Development Head, GlobalLogic Ukraine

Про що: Як вчитися ефективно, без прокрастинації та з задоволенням? Чим відрізняється мікро-навчання від макро? Що робити, аби вивчене не забувалось на наступний день? На ці та інші відповіді знайдете відповіді у цій колонці.

Тонкощі CV або Як скласти та кому надіслати, щоб отримати пропозицію мрії про співпрацю

Автор: Анна Туліна, Talent Acquisition Specialist, GlobalLogic 

Тема створення резюме актуальна завжди. Опис підводних каменів на цьому шляху та навички грамотної презентації власних досягнень часто прирівнюється до скрижалей мудрості або мапи скарбів. Проте, не все так складно, як здається на перший погляд. Як скласти CV? Що треба пам’ятати та як вірно розставити акценти, аби отримати пропозицію мрії про співпрацю? Відповіді – у детальній статті від експерта!

Soft and Hard Skills: Що важливіше? Розповідь одного рекрутера

Автор: Олена Лісовська, Recruitment specialist, Consultant, GlobalLogic Ukraine

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

Як успішно пройти інтерв’ю з клієнтом? Поради менеджера

Автор: Олександра Cкібіна, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic Ukraine

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

Always put your best foot forward, або Як Trainee пройти перше в житті інтерв’ю — 10 порад

Автор: Катерина Сич, Associate Recruiter, Consultant, GlobalLogic Kharkiv

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

Декомпозуй це: розкладаємо великі та складні задачі на компоненти

Автори:  Андрій Сидор, Senior Consultant, Quality Assurance, GlobalLogic Ukraine, Андріан Яблонський, Senior Consultant, Engineering, GlobalLogic Ukraine

Будь-яка велика задача складається з маленьких. Її можна розкласти на компоненти – це називається декомпозиція. Як декомпозувати складні задачі? Які техніки є ефективні? Про це та більше – розказали у цій колонці.

Python: чому вивчати та з чого почати?

Автор: Віктор Мойсеєнко, Team Lead, Python speaker and trainer, conducted over 25 group training courses, Consultant, GlogbalLogic Ukraine

Звісно, не міг цей дайджест обійтись без технічних статей! Чому Python такий популярний сьогодні? У яких сферах він використовується? А найголовніше – з чого почати вивчення цієї мови? На ці та інші важливі питання відповіли у великій оглядовій статті про Python!

Автоматизоване мобільне тестування: перші кроки

Автор: Антон Пелянський, Test Engineer, Quality Assurance, Consultant, GlobalLogic Ukraine

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

Інтерв’ю як історія: шлях героя для Agile проєкту

Автор: Андрій Кульшан, Business Analyst, Product Owner, Consultant, GlobalLogic Kharkiv

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

Кар’єра для студента: на проєкт без комерційного досвіду

Автор: Юлія Марсо, Recruitment specialist, Consultant, GlobalLogic Ukraine

З чого почати свої кар’єрний шлях? На що звернути увагу вчорашньому студенту? Які курси прийдуть на допомогу та як подолати фільтр “відсутність комерційного досвіду”? Що криється за назвами GL BaseCamp та GL ProCamp? Читайте за посиланням!

Бажаєте бути в курсі появи нових Блогів та оновлень? Слідкуйте за нами у соціальних мережах: Facebook, LinkedIn, Instagram та Телеграм-каналі.

А також – запрошуємо долучитись до технічних спільнот GlobalLogic, де крім спілкування на вас чекають вебінари та інший професійний контент:

Smart Collar: гаджет для собаки, помічник для хазяїна

Продовжуємо розповідати про наші Concepts на сторінках BlogPost!

Назва: Smart Collar

Локація: Харків

Автори: Євген Напрягло та його команда.

Статус: In Progress, є прототип

Сьогодні поговоримо про братів наших менших – песиків! Адже кожен хазяїн хоче, аби його пес був здоровий та захищений. Як цього досягти? На допомогу приходять технології! Одна з розробок інженерів GlobalLogic – розумний нашийник! Чому саме він?

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

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

Що таке Smart Collar?

“Розумний нашийник” або “Smart Collar” – це рішення, яке допомагає вивести спілкування між власником і улюбленцем на новий рівень. На жаль, коти та собаки не вміють розмовляти, але за них це можуть зробити технології: “Smart Collar” інформує про нагальні потреби вихованця та його добробут.

Мета:

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

Як це працює?

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

Ключові особливості:

  • Сигналізує про найперші симптоми хвороб. Розпізнайте перші симптоми та збережіть дорогоцінний час.
  • Вбудований GPS-трекер. Ви завжди будете знати, де знаходиться ваш маленький друг.
  • Відстеження фізичної активності вихованця, його харчування. Нашийник також допомагає відстежувати вагу та активність тваринки.
  • Нашийник світиться в темряві, що полегшує утримання собаки в поле зору, а також зменшує ризики зіткнення з автомобілями, велосипедами, тощо.
  • Моніторинг температури, який убереже собаку від перегріву – додаток сповістить вас про небезпеку, якщо песик перегрівся.
  • Додаток працює спільно з ветеринарною клінікою. Ви завжди матимете доступ до медичної документації вашого улюбленця, де ви зможете побачити всі процедури, які проходила ваша собака, вакцини та взяті аналізи.
  • Розумний нашийник може бути частиною розумного будинку. Він може регулювати температуру навколишнього середовища, якщо собака відчуває жар чи холод, вмикати світло, відчиняти та зачиняти двері, аби улюбленець міг пересуватися вільно. Він також може увімкнути камеру, щоб ви могли в режимі реального часу бачити, чим займається ваш вихованець.

Моделі використання:

Історія 1

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

Історія 2

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

Підсумок

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

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

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

Якщо вам сподобалась стаття, то запрошуємо долучитись до технічних спільнот, де крім спілкування на вас чекають вебінари та інший професійний контент:

GloDroid: актуальний Android на одноплатному комп’ютері

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

Назва: GloDroid 

Локація: Харків

Автори: Maryna Sergiyenko та її команда.

Статус: In Progress

Уявіть, що у вас є остання версія Android, одноплатний комп’ютер і цілий рік вільного часу на експерименти. Що б ви зробили? Спробували б запустити на ньому Android? А тепер уявіть, що це вже зроблено: презентуємо вашій увазі GloDroid! Це безпечне (no backdoor) та недороге рішення з відкритим кодом, яке працює прямо “з коробки” без жодних додаткових маніпуляцій.

GloDroid – це проєкт по портуванню та адаптації Android-додатків з відкритим кодом для роботи на широко доступних одноплатних комп’ютерних платформах.

Основними цілями GloDroid є:

Створити дешеву та надійну платформу з найсучаснішим Android “на борту” для створення прототипів, навчання та досліджень.

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

Поділитись усіма напрацюваннями та здобутками зі спільнотою.

На відміну від існуючих пристроїв, на кшталт Raspberry Pi, що мають на борту старі версії Android, GloDroid постачається з актуальною версією Android, що використовує open-source драйвери, залишається актуальною та має підтримку від Google.

Як це виглядає?

Проєкт складається з одноплатного комп’ютера — Orange Pi Plus 2E — та Android 10 з відкритим кодом на борту.

Чому ми обрали саме цю плату?

  • Вона дешева.
  • Має велику спільноту.
  • Гарне “залізо”, що задовольняє нашим цілям: 32-bit процесор, 4-ядра 1.6 GHz, Mali-400 графічний чіп, 2 GB RAM та 16 GB MMC. Плюс усі необхідні інтерфейси: USB для периферії, Wi-Fi та Ethernet.

GloDroid базується на Google AOSP та містить репозиторії, зазначені у таблиці нижче. Ми зробили makefiles для конфігурації Android на основі того, що ми хочемо створити (TV, Automotive, та інше) та яку підтримку HAL/сервісів ми хочемо мати (наприклад, Wi-Fi та Bluetooth).

Ключові переваги рішення:

  • Відкрите та безкоштовне рішення настільки, наскільки це можливо.
  • Має актуальну версію Android.
  • Близьке до основного Android, наскільки це можливо.
  • Поставляється з усіма необхідними бібліотеками та софтом, так що користувач може легко запустити свіжий Android без зайвих дій.
  • Працює “з коробки”.
Що ми зробили

Фінальний проєкт ми виклали на GitHub. А ось його wiki.

Також ми провели спеціальний вебінар та розповіли про наші розробки на DOU.

Сьогодні, GloDroid успішно працює на базі Android 11 та Linux 5.6.

Підтримує такі плати:

  • Orange PI family: Plus 2E / PC / PI 3 / WIN
  • Pinephone / Pinetab
  • Raspberry PI 4
  • PodCast

Та такі девайси:

  • Pinephone
  • Pinetab

Ми написали приблизно 1,800 рядків Android makefiles та близько 2000 рядків файлів коду C/C++/DTS та ін., аби все працювало добре. Близько 2% часу роботи над проєктом було присвячено розробці коду, 5% – створенню файлів побудови. Для наочності: протягом 3–4 місяців фази активного розвитку, лише 10 днів було витрачено на написання коду, а 25% часу ми витратили на компіляцію та виправлення помилок.

Android OS – це система, що живе та розвивається у реальному часі. Що було актуальним для версії 8, часто-густо вже немає жодного сенсу для версії 10.
Нам довелось багато аналізувати вихідний код, тому ми впевнено кажемо, що крім розв’язання практичної задачі портування, робота над проєктом значно покращила наші навички самоосвіти:

Заглибившись в офіційну документацію Google, ми зрозуміли логіку нового Android 11.

Ми набули практичного досвіду з наявними репозиторіями AOSP, з’ясували практичні аспекти їх роботи – щоб висвітлити деякі “сліпі місця” офіційної документації Google.

На цей момент ми зайняті виправленням помилок, про які нам сигналізувала спільнота через репозиторій GloDroid, та всебічно розбираємось з прев’ю Android 11 аби згодом портувати й цю версію.

Якщо вам сподобалась стаття, то запрошуємо долучитись до технічних спільнот, де крім спілкування на вас чекають вебінари та інший професійний контент:

Python: чому вивчати та з чого почати?

Автор: Віктор Мойсеєнко, Team Lead, Python speaker and trainer, conducted over 25 group training courses, Consultant, GlogbalLogic Ukraine.

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

Чому Python користується популярністю?

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

Швидкість розробки. На перший погляд, це не так вже і важливо, але час розробника – це гроші замовника. Як приклад, написати й розгорнути бекенд на Python можна набагато швидше ніж на будь-якій іншій мові (навіть швидше за Node.js). Тому ринок зацікавлений у Python. Корпорації на кшталт Google та Apple взагалі вже майже десятиліття більшість своєї внутрішньої розробки пишуть саме на цій мові.

Ком’юніті – любов до цієї мови зі сторони розробників створила величезне ком’юніті, яке активно підтримує перспективні проєкти, фреймворки, відповідає на складні питання на StackOverFlow, та розвиває мову.

Універсальність – ця мова на сьогодні є найбільш універсальною: на ній можна вчити програмувати дітей в школах, писати веб-додатки, сервіси, тестувати сайти чи програми, використовувати машинне навчання та програмувати пристрої для Internet Of Things.

Якщо я вивчу Python, у яких сферах я маю перспективи, чим цікавим зможу займатися?

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

Веб-розробка

Python один з лідерів в розрізі розробки веб-додатків та REST API сервісів – тут Python конкурує лише з Node.js. Це стало можливим завдяки масі перевірених часом фреймворків, серед яких:

  • Django – популярний фреймворк-комбайн по принципу “все за ціною одного”. Для багатьох веб розробка почалась і “закінчилась” з вивченням лише цього одного фреймворку, бо в ньому є все необхідне для написання додатку будь-якої складності – від туторіального блогу до порталу (саме на Django був написаний Instagram). Тут є своя екосистема, структурованість, свій ORM та мова шаблонів. Для легкого “прикручування” REST API до Django проєкту існує чудовий пакет Django REST Framework.
  • Flask – міні-веб-фреймворк. Тут вже інша ідеологія, ніж в Django – якщо в тому вся структура вже задана, у Flask розробник має сам її побудувати. І якщо в Django треба створити за допомогою утиліт ціле дерево директорій та файлів для проєкту та додатку, щоб створити початковий проєкт у Flask треба п’ять строк коду. І ще кілька, щоб прикрутити REST API за допомогою Flask-Restless.
  • Aiohttp – майже повністю український проєкт. Для тих, кому цього мало, можна додати, що це повністю асинхронний HTTP як сервер, так і клієнт – тобто на ньому можна писати як супер швидкі веб-застосунки, так і скачувати/шукати щось в вебі. Багато проєктів, яким важлива швидкодія, переходять з традиційних на асинхронні фреймворки/технології (до речі, Django 3.x вже також може працювати в асинхронному режимі також).

Машинне навчання

Якщо в інших сферах можна знайти якісь альтернативи, то в цій Python на першому місці без варіантів. Так, для статистики та деяких задач є ще чудова мова R. Але для продакшен вона не дуже згодиться. Тому Python, який однаково зручно використовувати як для початкового концепту, так і для фінального. Ще важливим чинником для лідерства в цій області є (знову!) простота та гнучкість Python. Старі розробки для складних розрахунків, що були написані десятиліття назад на мовах С та Fortran були легко перенесені у Python. Google та Microsoft використовують цю мову як основну для машинного навчання.

За допомогою Python можна:

  • Читати текст або визначати типи об’єктів на фото чи відео
  • Спрогнозувати показники на біржах, вірогідність заторів на дорогах чи хвороби пацієнтів по даних їх аналізів
  • Генерувати картинки чи змінювати відео в потоці

Зараз є такі основні/цікаві бібліотеки для машинного навчання:

  • Numpy – “основа всього”, реалізація класів матриць/векторів та пов’язаних операцій
  • Pandas – бібліотека для аналізу даних, майже повністю злизана з чудової мови R.
  • Matplotlib – бібліотека для візуалізації даних, дуже стара та надпотужна з безліччю форматів та можливостей – навіть інтерактивних (як приклад, ось гра Сапер, написана на matplotlib). Єдиний мінус – ця бібліотека трохи складна, тому високо-рівневі бібліотеки на кшталт Seaborn набирають популярності.
  • Scikit-learn, Kerras, PyTorch, TensorFlow – популярні пакети/фреймворки для реалізації різних алгоритмів машинного навчання – від лінійної регресії до нейромереж.

Автоматизоване тестування

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

Є багато бібліотек/фреймворків для тестування. Серед тих, що постачаються відразу з Python – є проста, що дозволяє писати тести прямо в коді майже серед коментарів – doctest, так і потужна unittest, що є базою для тестів у багатьох проєктах. Є навіть такі, що перейшли з тестування на Java (JUnit) на Python. Перехід досить простий тому що обидві ці бібліотеки належать до одного сімейства xUnit, і в них дуже схожий API.

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

З чого варто почати, які ресурси для новачків?

В інтернеті є безліч ресурсів. Youtube переповнений короткими та довжелезними курсами та гайдами. Але якщо потрібний вивірений часом перелік ресурсів від зовсім простеньких до гарних курсів, то ось він:

  • LearnPython – супер-мінімалістичний інтерактивний туторіал. Прекрасний варіант, якщо хочеться глянути на мову, спробувати базові методи. Має перелік тем, на кожну з яких треба десь 5 хвилин.
  • Python for Absolute Beginners! – Безкоштовний курс на Udemi для абсолютних початківців.
  • Python for Everybody Specialization – безкоштовні курси по Python від Coursera. Я чув гарні відгуки щодо них.
  • My GitBook – матеріали для курсу по Python, який я веду в GlobalLogic.
  • Python3 on SoloLearn – безкоштовний курс. На вигляд дуже простий, але покриває основні теми досить глибоко + є тести. Є мобільний додаток з таким же ім’ям – дуже гарно зроблений з оновлюваним контентом від користувачів.
  • Python Lectures – набір лекцій по Python від Rajath Kumar у вигляді Jupyter notebooks. Мені ці лекції подобаються тому, що вони схожі на мої власні, які я використовую на курсі. Це інтерактивні Jupyter зошити (notebooks), які можна скачати і запускати локально, переглядаючи в браузері.

Ще дуже рекомендую підписатися та слідкувати за цими блогами:

  • Codeguida – дуже файний український девелоперський блог. Гарні статті по Python.
  • Python on Reddit – Python-меми та новини.
  • Python Insider – Майже офіційний блог Python ком’юніті. Основні новини від головних розробників.

Як можна розвиватись, якщо ти вже Junior чи Middle розробник, але хочеш стати справжнім гуру?

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

  • Можливо, на поточному проєкті потрібна автоматизація якоїсь рутини? Завантаження файлу, пошук певних записів серед логів?
  • Чи треба адмінку для моніторингу статусу когось чи чогось?
  • Можливо треба веб база даних для книжок проєкту? Чи цікавих серіалів? Чи каталог мемів? База використовуваних віртуалок на проєкті?
  • Може потрібен Telegram чи Slack бот, який буде допомагати запускати тести, білди чи повідомляти про помилки?

Якщо цього замало – ось ще купа ідей:

Кожний такий проєкт – це цікава задача, цікава подорож у світ. Тож час в дорогу! Бажаю вам приємної подорожі та сподіваюсь, що зміг зацікавити Python!

А якщо ви хочете ще гайдів – то можете прочитати про те, як робити перші кроки у вивченні BiGData: частина перша та частина друга.

CI/CD для JS розробників. Частина друга – практика

Автор: Інна Іващук, Senior Software Engineer, Engineering, Counsultant, GlobalLogic Ukraine

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

У цій частині ми глянемо на основні популярні інструменти CI/CD, які можна використати у розробці, і спробуємо швидко сконфігуруємо Travis CI (і, звісно, запустимо), і глянемо на GitHub Actions.

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

Плюси використання CI/CD практик

Для початку, глянемо, що нам потрібно, щоб почати використовувати СІ:

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

Що ми отримаємо?

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

Для того, щоб почати використовувати практику СD, потрібно:

  • Високе покриття коду тестами.
  • Деплоймент повинен відбуватися автоматично.
  • Використання додаткових flags, які дозволять нам приховувати незакінчений функціонал (наприклад Launch Darkly).

Що ми отримаємо?

  • Деплоймент веб додатку стане набагато простішим.
  • Можливість робити реліз набагато частіше.

Для того, щоб почати використовувати практику СD (continuous deployment), потрібно:

  • Різні типи автоматизованих тестів (integration, performance, acceptance і тд), написаних не лише розробниками, а і QA.
  • Документація, яку потрібно тримати в актуальному стані.
  • Додаткові flags, які допоможуть приховати незакінчені частини, які зараз в процесі розробки.

Що нам це дасть?

  • Повністю автоматизований реліз.
  • Не потрібно робити code freeze, через те, що реліз довго готується.
  • Відсутність ризиків, адже все продумано, налаштовано та сконфігуровано.
  • Задоволені користувачі, які бачать покращення кожного тижня або, навіть, кожного дня.

Easy start with Travis CI

А тепер саме час спробувати один з інструментів, а саме Travis CI. Для того, щоб розпочати роботу, нам потрібно:

  • Перейти на сайт travic-ci.com та авторизуватись використовуючи GitHub акаунт
  • Підтвердити авторизацію на travis-ci.com, після чого буде перенаправлення на GitHub.
  • Пройти декілька простих кроків та обрати репозиторій, до якого ми хочемо додати відстежування Travis.
  • Додати у вибраний репозиторій файл travis.yml, у якому ми напишемо буквально декілька рядків і таким чином, запустимо роботу CI.

А тепер до коду!

GitHub Actions: чому варто звернути на них увагу

GitHub Actions однозначно вартує вашої уваги, тому що вони:

  • Вбудовані в GitHub, через те інтеграція проходить надзвичайно швидко
  • Дозволяють мультиконтейнерити тестування. У GitHub є багато різних темплейтів для будь-яких типів Continuous Integration
  • Дозволяють створювати свої власні actions та публікувати їх на GitHub Marketplace
  • Абсолютно безкоштовні для open source репозиторіїв

Основні концепції GitHub Actions:

  • Actions – це найменші частинки описаної поведінки.
  • Events, до яких ми можемо прив’язуватись, такі як push, pull request, та виконувати певні задачі
  • Runners
  • Job
  • Steps
  • Workflow – це безпосередньо наш файл, в якому описані поступові кроки, які містять actions, job і steps.

Ось що потрібно, щоб підключити GitHub Actions до репозиторію: невеличкий відео-туторіал. 

Висновки

Повертаючись до заголовка статті, пора все-таки відповісти на запитання: CI/CD для JS – потрібен чи ні?

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

Бажаємо вам успіхів, а якщо хочете більше корисних матеріалів – завітайте до нашого JS Community!

CI/CD для JS розробників. Частина перша – теорія

Автор: Інна Іващук, Senior Software Engineer, Engineering, Consultant, GlobalLogic Ukraine

У цій колонці я хочу поговорити про автоматизацію (куди ж без неї). Спробуємо покращити процес розробки та життя JS-розробника та розберемось в чому плюси CI/CD практик, яка різниця між CI vs CD vs CD.  А наступного тижня ми перейдемо до практичної частини та спробуємо запустити Travis CI. Тож, поїхали! 

CI: що це таке та навіщо?

Думаю, ви неодноразово зустрічали термін Continuous integration (або скорочено CI), але що саме мають на увазі під використанням CI?

Сьогодні ми з цим спробуємо розібратись. Перш ніж продовжити знайомство із CI/СD практиками, варто згадати про системи контролю версій, такі як git, svn, mercurial та інші. Швидше за все, більшість із вас є частиною команди та для того, щоб зручно було працювати, контролювати код додатку, який змінюється кожного дня, нам необхідний VCS інструмент, який допоможе без проблем синхронізувати зміни декількох розробників.

Щоб детальніше розібратись із взаємозалежність між системою контролю версій і практикою Continuous integration, глянемо на діаграму вище: у нас є розробник, система контролю версій, і звичайно ж СІ. З даної діаграми випливає, що Continuous integration – це практика, яка дозволяє під час кожної внесеної зміни (new commit), створення pull/merge request, запускати автоматичні перевірки, наприклад тести. У випадку, якщо тести пройшли успішно, запускається білд проєкту і, в результаті, отримуємо артефакт. Під артефактом у нашому випадку можуть виступати, наприклад, docker image, який ми пізніше будемо використовувати, або ж це можуть бути статичні файли, які ми будемо одразу публікувати на Heroku, або на GitHub сторінках, або на surge, або на власних хостингах (VPS). Це, в принципі, неважливо, адже конфігурацію можна підлаштувати під потреби.

А зараз розберемось з етапами CI:

  • Підготовка. Ми налаштовуємо середовище, де буде відбуватись запуск наших команд або скриптів. Оскільки, ми зараз говоримо про JS розробку, то у нас буде Node JS і нам потрібно завантажити та встановити всі NPM модулі.
  • Перевірка коду. Для цього ми можемо використати ESLint, stylelint, або TSLint. Це залежить від специфіки проєкту, і від мови, яка використовується.
  • Тести. Вони допомагають відловлювати помилки у коді набагато швидше і раніше.
  • Збірка проєкту (Build), за умови, що всі попередні фази були успішні. Найбільш популярні інструменти для цього, це – webpack, parcel, grunt та Gulp.

Що нам у цьому допоможе? Звісно,

Корисні інструменти

Danger

Корисний інструмент, який можна використати з СІ, і який допоможе зробити автоматичне code review. Перед тим як огляд коду буде виконуватись іншим розробником, можна запускати автоматичну перевірку, до прикладу, з Danger JS.

ReviewDog

Як альтернативу Danger, можна використовувати ReviewDog та зробити перевірку і відразу додавати коментарі для того, щоб базові помилки можна було знайти на фазі коли тільки створений pull request і не залучати інших розробників.

CD: що це та навіщо?

CD має два значення: це Continuous Delivery і Continuous Deployment. Для першого і другого значення це виглядає наступним чином:

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

Різниця між CI, CD та CD

Фаза Continuous Integration актуальна як і для Continuous Delivery, так і для Continuous Deployment. Як ви бачите, кроки абсолютно однакові. Крім того, що у Continuous Delivery є один ручний крок. Якщо ми хочемо зробити реліз та зробити код доступним для кінцевих користувачів, то тут це потрібно робити вручну. А у випадку, якщо у нас повністю сконфігурований та налаштований Continuous Deployment, це все буде відбуватися автоматично. Тобто, код автоматично потрапить із тестового середовища у продакшн, і одразу там можна буде зробити smoke test – тобто швидку перевірку чи все працює так, як очікується.

CI/CD сервіси<

Основні CI/CD інструменти це Jenkins, Travis CI, CircleCI, GitLab CI, GitLab Actions та Bamboo.

А тепер детальніше глянемо на схематичне зображення GitLab CI.

У нас є репозиторій із кодом, де налаштоване відстежування нових merge request або commits, що в свою чергу запускають перевірки, юніт та білд тести, далі вже фаза перевірки коду, тестові середовища (хостинг, хмарні сервіси і тд) та продакшн.

Виглядає це наступним чином:

Якщо мова йде про сучасну веб-розробку, то у нас є система контролю версії, є СІ інструмент, є Docker, оркестратор (kubernetes), і наш додаток знаходиться на одному з хмарних сервісів (Azure, Google Cloud, AWS), то наш CI/CD pipeline буде виглядати ось так:

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

На цьому з теоретичною частиною все. Наступного разу ми поговоримо про плюси кожного рішення, спробуємо швидко сконфігурувати та запустити Travis CI , а наприкінці глянемо на новинку, це – GitHub Actions, які у кінці 2019 стали доступними для всіх.

Читайте практичну частину про CI/CD – за посиланням.

Не перемикайтесь!

Якщо хочете більше корисних матеріалів – завітайте до нашого JS Community!

Як успішно пройти інтерв’ю з клієнтом? Поради менеджера

Автор: Олександра Cкібіна, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic Ukraine

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

Звернімось до статистики – на ресурсі DOU можна подивитися кількість відкритих вакансій та унікальних відгуків кандидатів. В середньому на одну відкриту вакансію припадає близько 7 претендентів. Не всі вони пройдуть внутрішнє інтерв’ю, але навіть якщо припустити, що половина рекомендована на клієнтське інтерв’ю – як ми розуміємо, тільки 1 з них займе бажану позицію на проєкті.

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

З особистого досвіду, я виділяю 4 основні категорії, в яких ви повинні проявити себе позитивно, щоб досягти успіху на інтерв’ю:

  • Building the right context;
  • Hard Skills;
  • Soft Skills;
  • Communication.
Building the right context

Першорядне і найважливіше, навіщо клієнти проводять бесіду – це переконатися, що ви саме той кандидат, який їм потрібен. Вони хочуть бути впевненими, що ваш досвід релевантний, а ваші технічні навички відповідали потребам проєкту.

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

І ось з цього моменту починає складатися враження про вас, як про професіонала. Це і є той самий “Building the right context”. Важливо впоратися з цим завданням ще на внутрішньому технічному інтерв’ю. Як? Зробіть акценти на своїх сильних сторонах, зупиніться детальніше на досвіді, який максимально релевантний до поточного проєкту, проявіть зацікавленість. Це допоможе менеджеру правильно вас презентувати, а вам справити хороше враження заочно.

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

Hard Skills
  1. У більшості проєктів, на які необхідно проходити клієнтське інтерв’ю вже є список найбільш поширених запитань. Якщо з якої-небудь причини з вами їм не поділилися – запитаєте про нього самі. Це дозволить вам краще підготуватися до технічної частини інтерв’ю.
  2. Ваше резюме повинне відповідати дійсності – ви легко можете відповісти на питання про всіх технологіях, які вказані в вашому резюме
    Ви повинні добре знати хронологію вашого резюме, легко відповідати на питання про досвід і проектах.
  3. Відповідайте на питання чітко, по темі. Важливо розуміти, що відповідь не повинен бути односкладових. На питання “Чи є у вас досвід в технології А?”, Клієнт точно не очікує відповідь “Так” або “Ні”. Якщо у вас є досвід, розкажіть про нього, поділіться плюсами і мінусами її використання. Якщо немає – поясніть чому і як швидко ви зможете її вивчити.
  4. Будьте чесні – якщо ви не знаєте відповідь на питання – зізнайтеся, але постарайтеся замість “не знаю”, “не вмію”, “мені це нецікаво” використовувати вирази “чув про цю технологію, але поки не було можливості застосувати”, “поки не стикався, але мені це цікаво спробувати “.
  5. Уникайте тривалих пауз перед тим, як давати відповідь – це може навести на думку, що паралельно ви використовуєте Google для пошуку відповідей. Зі своєї практики можу сказати, що кільком відмінним Java розробникам відмовили на клієнтському інтерв’ю саме через те, що їх запідозрили у використанні Google.
  6. Будьте готові, що вам дадуть тестове завдання і можуть попросити поділитися екраном, поки ви будете писати код.
Soft Skills

Ваші soft skills так само важливі, як і технічні навички. Ось кілька рекомендацій, які дозволять вам справити позитивне враження

  1. Тримайтесь природно. Під час бесіди постарайтеся не нервувати, будьте розслаблені – це не означає, що ви можете розслабитись у кріслі й в недбалій манері відповідати на питання. Подібна поведінка швидше наштовхне на думку, що вам даний проєкт не цікавий і ви вважаєте себе overqualified.
  2. Будьте “саме тим кандидатом” – під час інтерв’ю будуйте паралелі між вашим досвідом і тими вимогами, які висувають клієнти до претендента.
    Проявіть зацікавленість – ще на етапі внутрішнього інтерв’ю постарайтеся запам’ятати процеси клієнта і бізнес-домен. Якщо ви не стикалися з подібним процесом або стороною бізнесу – знайдіть необхідну інформацію і будьте готові підтримати розмову з клієнтами на дану тему.
  3. Чи не висловлюйтеся негативно про ваші минулі проєкти й замовників – постарайтеся нейтрально озвучувати факти. Таким чином це характеризує вас як відмінного професіонала.
  4. Підготуйте кілька питань – так-так, це дуже важливо. На будь-якому інтерв’ю завжди є 5-7 хвилин для запитань здобувачів. У вас має бути кілька питань з технологій, бізнес-домену або чинного процесу розробки.
  5. Цей пункт багатьом може здатися зайвим – але ви не повірите, в моїй практиці був саме такий випадок – на клієнтському інтерв’ю не варто ділитися своїми зарплатними очікуваннями.
Communication

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

  1. Думаю практично так само важлива якість вашої зв’язку, як і рівень володіння англійською мовою.
  2. Під’єднайтесь на інтерв’ю на 5-7 хвилин раніше, щоб мати можливість протестувати якість зв’язку, а також встановити необхідні програми / апдейти.
  3. Запізнення, проблеми зі зв’язком в самому початку можуть налаштувати клієнтів негативно і вони віддадуть перевагу кандидату, у якого не було подібних проблем.
    Врахуйте, що клієнти захочуть не тільки вас почути, а й побачити – включіть вашу камеру, виберіть нейтральний фон (більшість програм дозволяють вибрати такий).
  4. Незвичайний випадок стався у мого колеги – 2 кандидати проходили клієнтське інтерв’ю в один день, обидва не включали камеру і володіли схожими тембрами голосу – клієнти попросили провести повторну сесію, але вже з камерою, щоб упевнитися, що це не був один і той же чоловік.

Хочеться навести кілька прикладів, коли кандидати успішно проходили внутрішнє технічне інтерв’ю, але отримували відмови від клієнтів. Іноді подібні відмови пов’язані з неправильним розумінням вимог клієнта, а не помилками претендентів:

    1. Так на інтерв’ю з замовниками кандидат (Strong Senior) поділився своїми планами на майбутнє – він бачив себе в майбутньому як Lead Developer. Клієнти відмовили – бо за їхніми словами вони шукають сеньйора, а не Lead.
    2. Кандидат зі значним списком завершених проєктів (в рамках однієї компанії-роботодавця) отримав відмову, тому що клієнти були зацікавлені в співробітника, який має тривалий досвід роботи на одному проєкті.
Підсумки

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

І тоді заповітна позиція на бажаному проєкті – ваша. Бажаємо успіхів!

Декомпозуй це: розкладаємо великі та складні задачі на компоненти

Автори:  Андрій Сидор, Senior Consultant, Quality Assurance, GlobalLogic Ukraine

Андріан Яблонський, Senior Consultant, Engineering, GlobalLogic Ukraine

Будь-яка велика задача складається з маленьких. Її можна розкласти на компоненти – це називається декомпозиція.

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

Декомпозиція

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

  • Щоб продукт був красивий
  • Щоб швидко працював
  • Щоб не мав помилок

Правила декомпозиції: практичні поради

Ми виділили кілька важливих порад, які допоможуть декомпозувати задачі правильно:

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

  • Демонструйте результат роботи над задачею кожного дня. Це допоможе вам легко та чітко зрозуміти, що ви зробили за певний інтервал часу. Ви можете підготувати звіт та продемонструвати який новий чи додатковий функціонал був успішно реалізований за цей час. Таким чином, ваш проєкт стає проєктом driven by value, де ви дійсно створюєте цінність щодня. Це потрібно робити з самого початку: від компонентів, по вертикальній декомпозиції до кожного user story.

  • Радимо робити user story на один день, а не на 81519 story points, які будуть на весь спринт.

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

  • Робіть перерви на 10-15 хвилин після двогодинного штурму задачі, аби дати можливість собі відпочити та проструктурувати інформацію в голові. Це допоможе завершити задачу швидше та ефективніше.

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

  • Пам’ятайте про “Принцип Парето”: 20% зусиль – це 80% результату. Не намагайтесь створити ідеальну систему, яка розв’яже усі проблеми світу. Зробіть те, що треба зробити сьогодні, те, що від вас вимагається перш за все.

  • Вічно оцінювати та розставляти пріоритети не можна. Створіть roadmap на 2-3 кола, не більше.

  • Будь-які проєкти закінчуються. Оце ваш час для презентації власних ідей та рекомендацій.

  • Розклали велике завдання на підзадачі? Добре. Але не залишайте їх “на потім”, бо вони мають властивість зростати, як снігова куля. Радимо відразу виконати, отримати зворотний зв’язок, та рухатися далі.

Постановка цілей та шляхи їх реалізації

Це була теорія, а тепер – до практики. Техніка, яку ми рекомендуємо використовувати, може бути застосована у будь-яких випадках життя. Тож, розглянемо шлях до реалізації цілей на прикладі простого бажання – купити авто марки Mercedes.

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

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

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

А тепер наведемо приклад, як досягти поставлену ціль.

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

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

Ось як це тестування ми розклали по пунктах на картинках нижче:

Техніки оцінювання

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

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

Тому на різних стадіях задач потрібно використовувати різні підходи.

Top-Down

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

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

Analogous

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

Three Point

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

Найпростіша формула – це додати всі три оцінки та поділити на три – (П+Р+О)/3. Точнішою формулою ж вважається оцінка, коли ми реалістичну оцінку множимо на 4, додаємо песимістичну та оптимістичну оцінки та ділимо на шість – (П+Р*4+О)/6.

Bottom up

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

На цьому ми завершимо нашу розповідь про декомпозицію та методики оцінки. Сподіваємось, наші поради стануть вам у пригоді!

Автоматизоване мобільне тестування: перші кроки

Автор: Антон Пелянський, Test Engineer, Quality Assurance, Consultant, GlobalLogic Ukraine

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

Серед інших, не менш важливих задач є:

  • Вивчення вимог до застосунку та інших проєктнихпроцедурних документів.
  • Створення документації.
  • Стратегія тестуванняТест планТест репорт.
  • Матриця TraceabilityТест протоколи.
  • Валідація тестових інструментів.
  • Розробка тестового фреймворку автоматизації.
  • Підняття проєкту для запуску автотестів.
  • Опис інструкції по підняттю проєкту та запуску тестів.

А тепер про все це поговоримо детальніше.

З чого починається інженер автоматизації мобільного тестування?

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

Аналіз документів вам надасть:

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

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

Є дві глобальні операційні системи iOS та Android, і різні версії цих систем підтримуються на різних пристроях. Зверніть особливу увагу на вимоги по сумісності: вони можуть як змусити вашу команду підтримувати застарілі пристрої, так і намагатись наздогнати тенденції ринку. Це допоможе зробити процес розробки та тестування більш ефективним. Що ж стосується дистрибуції – шляху передачі продукту до замовника, – то вона має бути заздалегідь чітко визначена і описана у відповідному документі, на кшталт Design Transfer Plan.

Підбір тестових пристроїв

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

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

Архітектура

Аби чіткіше розуміти, з чим ви матимете справу, пропоную розібратися в архітектурі заліза. Отож, поточна архітектура у iOS пристроях є arm64 (або ARMv8.0). Вона використовується у пристроях починаючи з iPhone 5S та iPad Air та підтримується версією iOS 7.0 та вище.

Більше, на зображенні нижче:

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

Нижче наведена табличка по розподілу архітектури центральних процесорів і архітектури на i- пристроях.

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

Що ж стосується Android, то тут усе простіше.

У них дві основні архітектури – на ARM процесорах це armeabi-v7a (це 32- розрядна архітектура) та arm64-v8 – це 64-розрядна архітектура. Також є дві версії для процесорів Intel – це x_86 (для 32-розрядних процесорів) та x86_64 (для 64-розрядних процесорів). Варто зазначити що відсоток пристроїв що працюють на архітектурах x86 та x86_64 станом на 2017 рік складав 1.7%.

Як поширюються ті чи інші версії Android, можна дізнатися з графіку:

Оскільки є немало версій iOs та Android, а девайсів може бути понад 50 – то виникає логічне запитання:

Як нам все це перевірити?

Для цього є кілька доступних сервісів.

#1 Firebase Test Lab

Це хмарна інфраструктура для запуску тестів на мобільних пристроях. Цей сервіс підтримує запуск тестів на Android та iOS на цілому спектрі пристроїв, а також розуміє автоматизовані тести, написані на UIAutomator та Espresso для Android, а також XCTest для iOS.
Є безкоштовна версія, яка дозволяє запустити до 5 тестів на реальних пристроях і до 10 тестів на віртуальних пристроях за добу.
Firebase Test Lab є досить корисним сервісом, якщо ви тільки починаєте знайомитись з мобільною автоматизацією, а от для проєктних цілей безкоштовна версія не дуже підходить.

#2 Amazon Device Farm

Це сервіс для тестування мобільних додатків з хмарною інфраструктурою, який підтримує понад 170 різних мобільних пристроїв для запуску паралельних тестів. Amazon Device Farm підтримує більшість тестових фреймфорків для автоматизації, включаючи Appium, UIAutomator та XCTest. Перші 100 хвилин роботи тестів надаються сервісом безкоштовно. Якщо цього часу вам виявиться недостатньо, Amazon Device Farm пропонує платну підписку.

Емулятори vs Симулятори

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

Почнемо з різниці між ними:

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

На iOS зараз доступні лише симулятори, а на Android – емулятори.  А тепер пропоную розглянути як все працює та відбувається наживо.

Запуск iOS симулятора через Xcode: покрокова інструкція

  • Встановити Xcode через AppStore.
  • Запустити Xcode.
  • Вибрати бажаний пристрій зі списку доступних симуляторів.
  • Запустити симулятор.

Виглядає це все так: відео.

Запуск Android емулятора через Android Studio:покрокова інструкція

  • Встановити Android Studio.
  • Запустити Android Studio.
  • Відкрити Android Virtual Device Manager.
  • Створити профілі бажаних пристроїв.
  • Запустити емуляцію пристроїв.

Виглядає це наступним чином: відео.

Що ж, розібралися з Android емулятором, і тепер поговоримо про Appium.

Хто такий цей ваш Appium?

У вас є емулятори, у вас є хмарні сервіси, які запускають тести. Відповідно, ці тести треба якимось чином написати. І саме тут нам допомагає Appium. Це фреймворк автоматизації тестування з відкритим кодом, який використовує WebDriver для керування iOS та Android пристроями.

Appium дозволяє тримати тести для iOS та Android в одному фреймворку і використовувати одні й ті самі тести для обох платформ. Він підтримує тести, що написані на:

  • Java (TestNG, JUnit)
  • JavaScript (node.js)
  • Python
  • PHP
  • Ruby

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

Для Android використовується UIAutomator, для iOS – XCUITest.

Як це виглядає у коді? А ось так.

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

Змінюємо рітейл за допомогою сучасних ІТ рішень. Досвід GlobalLogic

Автор: Олексій Жерегі, Lead Software Engineer, Consultant, GlobalLogic Ukraine

Формат інтерв’ю повертається у BlogSpot! Цього разу поговоримо про етикетки. Здавалось би, до чого тут ІТ? Річ у тім, що у сучасному світі, коли мова йде про мільйонні партії товарів, які треба каталогізувати та відстежити, потрібні новітні рішення. Наш продукт і є таким. Він використовується не для статичних етикеток, як на пляшці води, а для етикеток, що містять унікальну інформацію, таку як інвентарний номер, дата виготовлення, та інше. Таку етикетку ви радше побачите на контейнері з пляшками, що пливе чи їде до магазинів.

Як сучасні ІТ рішення змінили цю галузь, як над однією етикеткою працюють команди у Франції, Бельгії та Україні та до чого тут хмарні рішення? Читайте нижче!

  • Розкажи про ваш проєкт?

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

  • Які головні завдання цього рішення?

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

Також, ми працюємо над сервісом автоматизації та розподіленого друку, який здатний обробляти великий потік команд, аналізувати їх та виконувати друк на велику кількість принтерів. Крім того, існують рішення для зберігання і контролю розроблених лейб – свого роду система контролю версій і безліч інших підпроєктів. Всі ці рішення можуть працювати у зв’язці, свого роду – це екосистема. У підсумку, все це можна налаштувати на виробничій лінії заводу, скажімо розташованому десь в Німеччині, при цьому команда дизайнерів буде знаходитися у Франції, зберігатися це все буде на сервісах Azure, а друк буде відбуватися з Бельгії. Все це можливо зробити використовуючи рішення, створене нашою командою.

  • Які технології використовуються на проєкті взагалі (екосистема) і якими технологіями займаєтеся конкретно ви?

Стек технологій досить-таки великий і він постійно змінюється згідно з трендами. Коли я потрапив на проєкт, переважно використовувалися C ++ / MFC для UI складової, C / C ++ для драйверів і сервісів, .Net / C # /WinForms для допоміжних інструментів. Але за останні кілька років акцент перейшов на сторону .NET. 

Так, остання версія дизайнера використовує WPF який спілкується з core частиною за технологією ActiveX. Сервіси реалізовані на .NET WCF. Для організації розробки ми покладаємося на TFS. Там і система контролю версій, і багтрекінг система, там же є веб-версія зі зручною дошкою, яку застосовуємо для Agile процесів. Конкретно я відповідаю за розробку UI редактора етикеток та основного ядра, яке відповідає за друк етикеток.

  • У чому внесок конкретно інженерів миколаївського офісу в розвиток продукту?

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

  • Як побудована робота з замовником?

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

  • Які на ваш погляд основні переваги проєкту?

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

  • А які недоліки? Що б хотілося змінити?

Складно сказати. Мабуть, їх і немає 🙂

  • Якими навичками та вміннями потрібно володіти, аби стати частиною вашої  команди?

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

  • Кого ви шукаєте на проєкт? Яким людям ви б рекомендували спробувати себе на цьому проєкті?

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

  • Які подальші перспективи розвитку існують на проєкті та в компанії?

Все завжди в руках спеціаліста. Особисто я починав свій шлях у GlobalLogic ще коли був студентом 3-го курсу. За 6 років я став senior розробником та dev lead в команді. Це далеко не межа! Щодо проєкту – найближчим часом є плани піти в хмарні технології та веб. Так що, цікавого попереду ще багато, тож запрошуємо всіх!

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

Бажаєте почитати ще інтерв’ю про наші проєкти? Тоді подивіться, як команда GlobalLogic створила рішення для гіганта АПЛ Manchester City. 

  • URL copied!