Всім привіт, JavaRush спільнота! Небагато про себе: з весни 2016 року працюю як Java Software Engineer. Люблю сюди заходити та вирішую завдання, що не вирішив ще під час навчання. Сьогодні розповім вам про бібліотеку - Image Comparison . Це open source бібліотека, яка зберігається у відкритому доступі до GitHub . Мета цієї статті донести, що створення open source продукту - це не просто марнування часу, ні! Це багатий досвід, який черпається з різних боків, коли у твоїй владі весь процес розробки, коли потрібно вникати у кожну деталь. Open Source – це світ навколо вас. Я не жартую за час існування цієї бібліотеки спілкувався з людьми з різних країн, таких як: США, Індії, Китаю, Єгипту, Росії, Німеччини, України, Швеції, Нової Зеландії, Норвегії. Тобто це реальний досвід спільної розробки, знаходження компромісів, перевірки коду тощо. Це був вступ, тепер почнемо по порядку:
Тестове завдання. Початок серпня 2017 року
Почалося все з того, що я співрозмовився до однієї з компаній, де першим етапом потрібно було написати тестове завдання. Завдання полягала в тому, щоб написати код, який порівнював дві картинки, з однаковими розмірами, знаходив відмінності між ними, групував їх і малював прямокутник навколо них. Є перша картинка:
Є друга картинка:
Потрібно було знайти відмінності та обвести їх як показано нижче:
Як можна помітити, у полі Username є відмінність, яка була обведена червоним трикутником. Більш детальний опис завдання . Я вирішив, що хочу зробити не лише правильно з погляду функціоналу, а ще й красиво, щоб було не соромно. Для цього вирішив, що опублікую це як проект на GitHub . Давно хотів вивчити GitHub, здобути досвід роботи з ним. Після швидкого перегляду, знайшов що добре додати сторонні сервіси з аналізу якості коду, по генерації покриття коду тестами і т.д. Додав такі інструменти:
Codacy – якість коду. Справді, варто звернути на нього увагу.
Travis CI — це CI(continuous integration) інструмент, який збирає проект, проганяє тести та каже, чи успішно зібрано проект. Наприклад, якщо якийсь із тестів не пройшов у слідстві з новими змінами, то він скаже, що збірка проекту невдала і забарвить її червоним кольором.
Coveralls - це інструмент, який показує, який відсоток коду покритий тестами.
BetterCode Hub ще один інструмент для аналізу якості коду. Дуже корисна річ, яка не тільки скаже, що погано, а й опише, чому й дасть посилання на книгу, в якій можна почерпнути знання про це.
Кожен із цих сервісів має свій бейджик з результатами даних, наприклад проект покриття коду. І цей бейджик можна додати в головному описі проекту - файл README. Завдання було готове — віддав його на реву. Після рев'ю відразу ж по свіжій пам'яті створив на кожне зауваження Github Issue , які потім допомогли мені покращити цей проект. Завдання від роботодавця щодо покращення не було, тому на деякий час я забув про проект...
Шлях Бібліотеки. Липень 2018 року
Логотип
Одного разу я виявив, що на мій проект часто заходять люди, причому це відбувається щодня. Мене це вразило, ще більше вразило те, що через рік створабо ISSUE, в якому було написано, що якийсь графічний дизайнер пропонує мені створити логотип мого проекту. Мовляв, він любить робити це для Opensource продуктів і зробить це абсолютно безкоштовно. Ми почали співпрацювати. Було запропоновано кілька варіантів, зрештою зупинабося на цьому:
Я тоді ще був молодий і незнайомий з Opensource спільнотою і сам факт такої пропозиції мені був диким і я запитав, а навіщо він це робить? На що він мені відповів: "Lolz oh, just cause i love contributing to open source projects. Kind of a life goals thing..." ( саме issue тут ). Ось тоді я і відчув уперше як це здорово, коли через opensource проекти тебе знаходять різні люди і пропонують такі цікаві речі!
Перший Дефект з боку
Я помітив, що якийсь розробник з Китаю створив мені issue , в якому він описав, що знайшов дефект у роботі бібліотеки, що якщо використовувати великі картинки, то виходить StackOverflowError . Людина вирішила скористатися і знайшла помилку. І не просто знайшов. а ще й написав про неї. Це новий крок у розвитку бібліотеки. Причому реального рішення у мене не було. У певний момент, один із тестувальників із Росії запропонував рішення. Але воно було сире та зроблене не як годиться і я не прийняв його. А коли вже треба було публікувати бібліотеку в Maven Central, треба було щось вирішувати з цим дефектом, не хотілося викладати разом із ним. До того ж був ще один дефект, який я так і не полагодив і він теж приносив багато незручностей.
Command Line Usage. Осінь 2018 року
Наступним етапом у розвитку було спілкування зі шведом (Renato Athaydes), який захотів використати бібліотеку через командний рядок і для цього потрібно було внести деякі зміни та доповнення. Я знову був вражений і здивований цим. Після того, як мені писав графічний дизайнер, здивування моє було трохи менше, але все ще дуже високо. Від думки, що мій код комусь реально потрібний, мене переповнювали неймовірні почуття. Він здійснив необхідні зміни, підготував код. Я провів code review, тобто переглянув зміни, були коментарі, які були змінені та зміни були вже у бібліотеці. Ці зміни я позначив як версію v2.0 Наступним етапом було додавання бібліотеки до Maven Central — центрального сховища, звідки можна буде завантажити його для будь-якого проекту та використовувати як залежність (dependency). На той момент я гадки не мав як це зробити, навіть віддалено, тому я послався на зайнятість і попросив виконати його всі дії, які необхідні для налаштування на проекті. Але цього виявилося дуже мало і найцікавіше було саме в тому, щоб налаштувати зв'язок з Maven Central. Це дикий біль, який з першого разу я так і не зміг, і реально лише 15 квітня мені вдалося опублікувати проект на Maven Central. Це було нелегко, але як люблять говорити інші: "через це проходять усі, хто хоче опублікувати свій код Java". До того, як я опублікував бібліотеку, я таки знайшов що і як робити з дефектами,v2.0.2 , в якій я подякував усім тим, хто допоміг мені, описав, що і як я зробив.
Публікація в Maven Central. Весна 2019
Щоб правильно опублікувати бібліотеку, необхідно добре розібратися з версіонуванням, як правильно виставляти версії. Я дотримуюсь такої схеми:
XX.YY.BBBB , де XX — це мажорне оновлення версії, яке тягне за собою зміни несумісні з попереднім.(наприклад зміна повертаючого результату в методах);
YY - це мінорне оновлення - зміна внутрішнє або розширення, яке не змінює те, що BBBB - це дефекти, які були відновлені.
Наприклад, версія 2.0.2 - означає, що мажорна версія 2, мінорних оновлень не було, і є два оновлення за дефектами.
Далі було важливо розібратися як правильно поставити groupId , artifactId . Їх потрібно було вибрати один раз і використати далі. З них складається пакет, у якому зберігається код. І це явно краще, тому що всім відомо, що це проект з GitHub і можна його знайти у людини з ніком romankh3 . Коли все це зробив, випустив нову версію v2.1.0 .
Спілкування зі шведами. Тдорівнюєь 2019 року
Після того як я опублікував бібліотеку, мені написав на пошту інший швед (Mika Kytöläinen) і попросив, щоб його знайомий зробив зміни у моїй бібліотеці. Каже, що це йому дуже потрібне і він буде дуже радий, якщо ми це зробимо і зробимо швидко. Я, звичайно, був не проти змін, які потрібні. Він запропонував додати конфігурацію товщини лінії, що малює прямокутник. Мовляв, для тих, хто погано бачить — це буде корисна зміна. Підготував код . Додавши ще кілька змін, випустив версію v2.2.0
Спілкування з німцем. Тдорівнюєь 2019 року
Після цього один німець створив issue, В якому каже, що хоче використовувати для тестування, але йому не вистачає функціоналу. Він зробив багато пропозицій, які були дуже цікаві, він запропонував замість того, щоб в результаті порівняння повертати тільки картинку, що створюється з результатом, повертати набір даних: те, що порівнювалося, результат (якщо потрібно) і стан в якому буде MATCH, MISMATCH, SIZE_MISMATCH . Навіть виконав зміни. Але вони зовсім не враховували попередній код і були зроблені поспіхом. Я відхабов їх і запропонував виконати так, як я вважаю за потрібне. Незважаючи на це він більше відповідав і я вирішив, що сам зроблю це і випустю нову версію. Разом з тим, Mika Kytöläinen запропонував ще цікавий функціонал — додати області, які б не брали участь у порівнянні. Це справжній кейс. І все це було випущено у v3.0.0
Використання у реальному проекті
Наприкінці травня мені написав тестувальник-автоматизатор із Києва, який зацікавився бібліотекою та хоче її використати у реальному проекті, який приносить гроші. То був прорив! Використання десь у pet-project це одне, а використовувати у реальному проекті – це зовсім інша справа. Ми обговорабо, що і як працює. Застосування дуже цікаве: у них у додатку є чеки, які друкують і потрібно було перевіряти, що чеки створюються за певним шаблоном і він не змінюється. Але була проблема, що такі секції, як дата і час, завжди змінювалися і їх потрібно було ігнорувати. У нас уже був доданий функціонал на ігнорування деяких областей, але він виявився ще дуже сирим для реального використання і ми ще плідно попрацювали кілька тижнів над цим. Результатом став випуск версії v3.1.1
Пошук ніші
Після цього я зрозумів, що реальна ніша для моєї бібліотеки використання її в тестах. Для цього я вирішив знайти якийсь форум для тестувальників та написати їм про це, щоб отримати якийсь відгук та збільшити популярність. Знайшов російськомовний форум і там опублікував статтю " Організація тестування картинок - порівняння двох схожих" . У ній я отримав реальний відгук про код і функціонал, який я застосував і випустив нову версію v3.2.0 , а потім і v.3.3.0 .
Зараз
Зараз бібліотека має 60 зірок на Github, має 33 форки. Я вважаю, що це дуже здорово з огляду на те, що я його ніяк не піарив крім статті на форумі для автоматизаторів. Дякую всім, хто дочитав до кінця. Реально виявилося набагато більше стаття, ніж я очікував. Стаття про те, як опублікувати бібліотеку в Maven Central. Якщо є що додати, пишіть! Якщо є що запропонувати щодо покращення бібліотеки — пишіть! Я все прочитаю і належно приділю на цей час. Всім кому стаття сподобалася і була корисною — оцінюйте та пишіть у коментарях. Також, підписуйтесь на мій гітхаб обліковий запис romankh3 Дивіться також мої інші статті:
Мета цієї статті донести, що створення open source продукту - це не просто марнування часу, ні! Це багатий досвід, який черпається з різних боків, коли у твоїй владі весь процес розробки, коли потрібно вникати у кожну деталь. Open Source – це світ навколо вас. Я не жартую за час існування цієї бібліотеки спілкувався з людьми з різних країн, таких як: США, Індії, Китаю, Єгипту, Росії, Німеччини, України, Швеції, Нової Зеландії, Норвегії. Тобто це реальний досвід спільної розробки, знаходження компромісів, перевірки коду тощо. Це був вступ, тепер почнемо по порядку:
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ