#Ruby

Є така хороша бібліотека для Ruby - css_parser. З 88 мільйонами завантажень, це вірний вибір для розбору CSS з середовища Ruby. Зазвичай вона працює добре, але ми виявили, що не для будь-яких документів. На деяких вхідних документах швидкодія падала безнадійно. Ну як — безнадійно? Насправді надія є, можна взяти та зʼясувати, що не так — адже код відкритий.

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

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

Але регулярка не робила нічого магічного; вона розділяла вираз CSS на властивості — крапкою з комою, а потім на імʼя та значення — двокрапкою. Це досить легко зробити за допомогою простіших методів String#split та String#index.

Далі за допомогою профайлера RubyProf та його режиму відстеження виділення памʼяті я переробив код циклу так, щоб уникнути виділення памʼяті повністю. (Щоб побачити, що проблема в регулярці, теж був потрібен RubyProf, але в більш звичному режимі відстеження часу виконання.)

Ці зміни не тільки покращили швидкість розбору в 3.5 рази та використання памʼяті в 3 рази, але й уникнули тих випадкових проблем з регулярками, з яких все починалось. Як бачите, проблема була не в тому, що Ruby - повільна мова, а в тому, що підхід обраний неоптимальний. Регулярні вирази - потужний інструмент, але ж потужність приходить з ціною; для простих потреб треба брати прості, явні операції на рядках.

Вже писав, як я прискорив бібліотеку для Ruby css_parser прибиранням регулярних виразів. Проте це було не єдине покращення того сезону. Нещодавня стаття Аарона Патерсона про клас StringScanner нагадала, що я теж залучав StringScanner, щоб прискорити парсер на 80%.

Зміни можна подивитись у цьому коміті. Як бачиш, вони мінімальні: просто замість методу String#scan використовую клас StringScanner. Цей клас існує ще з Ruby 1.8 - саме час його вивчити. :)

Бо мій канал не для того, щоб просто сказати, який клас хороший. Розберімося, чому. Перший ключ в тому, що він цілком написаний на C. Проте так само і String#scan. Взагалі в Ruby багато низькорівневих методів реалізовані на C, що трохи розвіює міф про те, що Ruby обовʼязково має бути повільніше за мови, що компілюються.

На жаль, профілювання коду Ruby не пояснить нам різницю між цими реалізаціями. Зате ось gist з бенчмарком, який показує, що на тривіальному прикладі StringScanner навіть на 170% швидше. Тобто різниця полягає не в виконанні регулярного виразу (тут тривіалізованому), а в тому, що відбувається окрім нього. Єдине, що обидва методи роблять окрім регулярки — це повертають знайдений рядок.

Я здогадуюсь, що різниця у виділенні памʼяті. Якщо пропустити мій бенчмарк через benchmark-memory, то виявиться, що String#scan виділяє в 5 разів більше памʼяті. Здається (без подальшого профілювання), що String#scan (тобто rb_str_scan) містить більш узагальнений код, а StringScanner#scan (тобто strscan_scan) - зоптимізований рівно під повертання результату з початкової позиції. (Так, до речі, є різниця в тому, що StringScanner шукає тільки на початку рядка — але зазвичай це саме те, що нам потрібно.)

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

Нарешті знайшов час зробити два PR до бібліотеки css_parser для Ruby, про які я писав рік тому, а зробив ще у 2021-му. Кілька спостережень.

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

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

• До речі, чому взагалі зробив PR зараз? Бо власну гілку треба було ще підтримувати, та в один момент вона припинила підтримувати сучасний Ruby. Взагалі у гілок завжди ця проблема: якщо не підтримувати, то вони ані оновлень безпеки не отримують, ані тим паче нових функцій. Тому я раджу завжди робити PR відразу. Проте це легко зробити з виправленням помилок (бо їм всі раді) та складніше з новим функціоналом або оптимізаціями.

Вчорашній пост змусив мене знову подумати, чому ж в Ruby on Rails з моделлю працювати зручніше, ніж будь-де. ActiveRecord залишається неперевершеним в простоті використання, навіть для побудови складних та потужних бізнес-процесів.

Отже. В Ruby немає різниці між методами та атрибутами, а точніше, весь публічний інтерфейс обʼєктів є виключно методами. Це приховує силу-силенну складності — аспекти реалізації не обтяжують споживача. Наприклад, User.all.map(&:name) елегантно та непомітно залізе в базу. (Але краще User.pluck(:name), що відразу витягне масив імен.) Фактично в Rails база виглядає, як “внутрішня”, а не “зовнішня” структура даних. Інколи це підштовхує писати неоптимальний код — але, як каже Роб Пайк, не варто оптимізувати код наперед.

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

Можна подумати, що це робить код Rails неможливим для перевірки. Але, в Ruby весь код живе у спільному просторі імен та доступний для змін під час виконання. Тому практично кожний метод, змінну чи клас можна замінити на тестову копію. Це насправді дуже потужно, та ми постійно цим користуємося. Для прикладу, можна навіть змінювати константи.

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

В Ruby можна на ходу замінити будь-який метод та отримати доступ до майже кожного атрибута. Причому зробити це хоч на рівні класу, хоч для конкретного обʼєкта з instance_eval. Звучить як щось дике, але насправді це гарний інструмент, яким ми цим користуємося постійно. Ось кілька прикладів:

• Для ізоляції тестового екземпляра. Бібліотека rspec-mocks та інші побудовані на тому, що в Ruby без всякого Dependency Injection можна замінити окремі властивості або поведінку обʼєктів. Інколи це прямо уможливлює написання тестів там, де в іншій мові їх було б надто дорого писати.

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

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

Сьогодні випустив оновлення для Headless. За всіма вимірами, це треба було зробити вже давно, але краще пізніше, ніж ніколи — принаймні, якщо люди все ще просять. (Я вже писав), що мені він давно не потрібний. Десь з рік тому до мене зверталася людина та пропонувала зайнятися підтримкою, та я навіть доступи надав, але… в неї теж поки не знайшлося часу, напевно? Історія класична. Десь з тиждень тому мені знову нагадали, що гем не працює з сучасним Ruby, тож вирішив взятись.

Як я себе змусив це зробити. Думаю, ну мені не хочеться - Cursor зможе. Успіхи з Cursor були різного рівня.

Замінити Travis CI на Github Actions - впорався на 95%. (Чомусь запхав у виконання тестів xvfb-run, хоча вся суть мого гему, що він заміняє xvfb-run для програм на Ruby.) Це чудово! Я вручну б довго сидів та розбирав синтаксис.

Оновити матрицю версій Ruby для CI - впорався на 100%. Теж гарно, бо це наче просто, але довелося б бігати по сторінках завантажень Ruby та JRuby.

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

Додати Rubocop - тут я б сказав 30% успіху — наче щось виходило, але конфігурації забагато та rubocop-rails намагався теж впхати.

Виправити Rubocop - цього взагалі не раджу робити, хоча в мене були великі сподівання. Бо код псує більше, ніж виправляє. Причому псує в сенсі змінює зміст. А я зрештою замінив Rubocop на Standard - це надбудова над Rubocop із переконаним набором налаштувань. Окрім іншого, Standard добре виправляє помилки та підійде навіть в ролі автоформатувальника. Навіщо ШІ, коли є спеціалізований інструмент?

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

Передісторія. Десь у 2019 зʼявився Chrome DevTools Protocol - протокол поглибленого керування браузером. Наприклад, він дозволяє прямо встановити кукі, або зробити знімок екрана. Гарна річ, дозволяє позбавитись посередника для автоматизації браузера. Зокрема (але не тільки) для інтеграційних тестів.

Невдовзі вийшов гем Cuprite для тестів на Ruby, який дозволяв позбавитися Selenium. Selenium - не найстабільніший пакет на світі, тому тоді це сприйняли з радістю та мігрували. Радикального виграшу не отримали, хоча поглиблене керування стало в пригоді. Минуло 6 років, та Cuprite так і не переміг Selenium, а до того ж його не дуже гарно підтримують. Інтеграційні тести, на жаль, це така галузь, де вчасна підтримка все вирішує, бо Chrome оновлюється постійно та десь щось ламає. От і зараз це стало великою проблемою… можна було б переїхати назад на Selenium, тільки це проблема ще більша. Питання: чи допоможе із цим впоратись ШІ?

Виправлення, широко кажучи, можна поділити на 3 категорії.

Різниця в пробілах. Для зручності в Capybara можна перевіряти не тільки сухий DOM, але і його текстовий зміст. Кожний із рушіїв по-своєму його будує (зверну увагу, що ніякого стандартного способу тут немає.) Це веде до купи абсолютно тривіальних помилок вигляду Foo\nBar замість Foo Bar. Я думав, що ШІ тут легко все поробить, але ні. Часто він або не розумів задачі, або заміняв надто багато, вигадував своє. Зробив висновок, що ні — дрібні, розсипані по коду виправлення ШІ робить погано. Я сам швидко зʼясував природу змін… от тільки робити їх вручну все одно довго та нудно.

Зміна API В Selenium за ці роки зʼявилася підтримка CDP. Втім, звісно, виклики не збігаються. Умовно, замість driver.set_cookie треба писати driver.devtools.network.set_cookie, та ще й термін передати числом, а не датою. Я сподівався, що “перероби на API Selenium” пройде, але ні. Навіть коли додав “читай цю сторінку із прикладами”. Зрештою виявилося, що я вручну з масовою заміною можу адаптувати виклики швидше, ніж вигадувати запит до ШІ.

Складніші зміни. Взагалі, мій перший план був такий: забирати з CI журнал невдалих тестів та передавати до Claude із додатковими інструкціями. Окрім вище описаних змін, були й менш зрозумілі. Наприклад, деколи Selenium відпрацьовує швидше (чи не чекає чогось?) та перевірка випереджує стан. Тут ШІ робив якісь незрозумілі кроки. Зокрема - спрощував тести, щоб ті проходили. Тобто з масовим виправленням без людського втручання точно успіху немає.

Якщо підсумувати, то ця міграція, про яку мені навіть казали “так може ШІ це швидко зробить?”, так і залишилась великою та складною задачею.