Стендап Сьогодні

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

02.01.2023

Прогрес з RSS-стрічкою для Reddit

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

Погрався трохи з генерацією повнотекстової RSS-стрічки Reddit, такої як я зробив для Hacker News. Виявив ряд особливостей.

Ну, по-перше, Hacker News один, а сабреддітів безліч, тож одну стрічку на всіх не зробиш. Якщо відкривати власне рішення (щоб не марно його писати), бачу три варіанти. Або робити сервіс — напевно, платний, бо збирати стрічки та обходити обмеження без витрат не вийде. Або опен-сорсити, щоб кожний сам розгортав. Або ж ще можна зробити стрічки для декількох цікавих мультіреддітів — ну, наприклад, зібрати мультіреддіт для вебтехнологій. От з останнього спробую почати.

Далі, як взагалі забирати дані з Реддіту? Спочатку я хотів витягувати RSS-стрічку та скрейпати додаткові дані зі сторінок окремих постів. Але потім помітив, що адреса RSS - це та сама адреса сабреддіту, але з суфіксом .rss та спробував замість нього написати суфікс .json. Працює! Будь-яку сторінку — сабреддіт або окремий пост — можна легко отримати у форматі JSON. Та для цього не потрібно використання API та ніякої авторизації. На мою думку, чудове рішення.

Нарешті, Reddit зараз суворо ставиться до ботів, кілька запитів — і ви вже бачите блок-сторінку. Але я знайшов, як обійти, через два заходи. Включив cookie - для цього в Ruby є чудовий гем Mechanize. А також почав назначати user agent, згенерований бібліотекою Faker. Так, принаймні, 50 послідовних запитів в мене не блокуються. Також необхідно впровадити кеш, щоб не повторювати ті самі запити — в мене вже такий є.

01.01.2023

Бачення проєкту

Перше січня. Час поговорити про бачення, або ж як ще кажуть, vision. Бачення — це душа проєкту; без бачення залишається проєкт-зомбі, що рухається незрозуміло куди, незрозуміло навіщо.

Про бачення складно говорити, бо це відчуття. У айтівців зазвичай складно з такими “мʼякими” поняттями, тому питання про бачення заміняються на підрахування “за” та “проти”, призначення числових оцінок, та інші аналітичні засоби.

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

Тож я б радив ще до заповнення таблички “за” та “проти” прислухатись до інтуїції та зрозуміти, чи є робочий варіант, що відчувається вірним. Якщо є — добре! Заповняємо табличку від душі. Якщо ні — треба шукати далі; випробувати різні прототипи; поки інтуїція не скаже — ось воно!

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

На ці міркування мене наштовхнуло відео про те, як Стів Джобс відповідав на їдке запитання. Та ще трохи перегляд “Матриці”.

31.12.2022

Підсумки 2022 року

Настав час підбити підсумок 2022 року.

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

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

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

Окрім того, додав українську локалізацію до Сінтри, а потім, натхненний успіхом, переклав на українську мову RSS-читач Miniflux, а нещодавно ще й пошукову систему Kagi. Сподіваюсь продовжити цей тренд у наступному році.

Вже безмаль пʼять місяців веду цей канал. Неабияке випробування для письменницького таланту, але, краще писати щодня, ніж зовсім не писати. :) До того ж відродив свій блог, на який до того ніяк не вистачало часу.

Вдала спортивна програма року: Seven - дуже на часі — бо сім хвилин на день можна знайти. Десь пів року роблю без перерви.

Речі року: гамак WiseOwl - провів в ньому багато літніх годин; ручна еспресо-машина Wacaco Picopresso - завдяки їй випив багато гарної кави далеко від дому; перфоратор Bosch 2-26 - перетворює свердління отворів в “наведи та клацни”.

🎄 З Новим 2023 Роком! Попереду ще 365 здобутків, незважаючи ні на що. 🥂

30.12.2022

AWS Redshift, його видатне кешування, та як їм користуватись

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

Я нещодавно писав, що у кожної NoSQL бази даних є “золотий сценарій використання”, який треба розуміти, щоб ефективно побудувати свій додаток на її основі. Поступово починаю розуміти, який “золотий сценарій” у Redshift.

Раніше я думав, що головна перевага Redshift - це можливість швидко обробляти великі обсяги даних. Але ні, це лише визначальна властивість OLAP баз.

Зараз мені здається, що у Redshift найкрутіше — це кешування. Навіть складні запити (основну роботу OLAP бази) можна зробити швидкими, якщо розробити таку структуру запитів, яка буде здатна до часткового кешування. Ось знайшов сьогодні гарну статтю від AWS.

Один з видів кешу — це materialized views, про які я вже писав. Redshift здатний робити їх автоматично, якщо можна у запиті виділити фрагмент, що підходить. Так, якщо деякий складний запит можна частково підготувати для всіх клієнтів разом, а потім фільтрувати під клієнта, то він буде відпрацьовувати швидко, попри видиму складність.

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

29.12.2022

Плани по Bullet Journal

З Нового року планую все ж таки впровадити трохи порядку у своє життя. Буду повертатись до ведення Bullet Journal, системи самоорганізації у паперовому блокноті. Колись це була одна з найуспішніших моїх спроб організуватись. А тепер, як виявилось, система BuJo набула неабиякої популярності — я знайшов декілька українських магазинів знаряддя саме для неї. (Посилання не чекайте — ліпше взяти звичайний блокнот та ручку.) Взагалі, BuJo зіпсований — як на мене — ряснотою креативних користувачів, які роблять зі своїх блокнотів справжні витвори мистецтва, з малюнками та каліграфією. На їхньому тлі мій виглядає зошитом першокласника. Але, сама по собі система не потребує ніякого художнього хисту.

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

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

(Чому ж штампове “з нового року”? Та творець BuJo сам так радить — новий рік почніть з нового блокноту. Втім я вже почав експериментувати у старому.)

28.12.2022

Покращення для gRPC сервера на Ruby - Gruf

🎄🎅🎁 Сьогодні день покращення нашого gRPC сервера. Саме те, чим варто займатися в новорічний сезон — дрібна задача, на яку зазвичай не вистачає пріоритету.

gRPC сервер, як я вже писав, на gruf. Перше, що бісило — це кепська робота перезавантаження коду у режимі розробки. Причина — відсутність засобів безпеки при паралелізації. Якщо клієнт робив паралельно декілька запитів, то кожний запит окремо викликав перезавантаження, та це призводило до помилок на кшталт “Невизначений клас”. При чому якийсь мьютекс у коді був присутній. Тільки він не покривав весь код, що перезавантажується. Я взяв інструкцію по конкуренції Zeitwerk (Zeitwerk - то гем, що забезпечує перезавантаження коду як для Gruf, так і для Rails.) та зробив по неї. Вийшов отакий святковий PR.

Далі, оснастив сервер інтеграцією з Sentry. Ми її втратили при переході з самописного сервера на Gruf. Та якось далі жили без неї, бо помилки все одно реєструвались з клієнта. Але це було незручно — помилки втрачали свій стектрейс та контекст. Нарешті, приєднав офіційну інтеграцію gruf-sentry.

І третє — увімкнув також моніторинг швидкодії також від Sentry. Чому не New Relic? Тому, що у нас він на власному сервері, тож це виходить “безплатно”. New Relic на наших обсягах виходить дорого. Та й моніторинг потрібен суто базовий.

27.12.2022

Налаштування пулу підключень у Ruby on Rails

Повертаючись в більш рутинні питання — відкрив як важливо не забути про налаштування пулу підключень у Ruby on Rails.

За замовчуванням розмір пула встановлюється відповідно до значення змінної оточення RAILS_MAX_THREADS. Це гарно працює для звичайного вебсерверу, який так само прочитає кількість паралельних потоків з цієї змінної. Корисно знати, що Sidekiq також візьме рівень паралелізації з тієї самої змінної. Тож єдине налаштування RAILS_MAX_THREADS вирішить як питання паралелізації, так і розміру пулу підключень до бази даних (Звісно, встановлювати змінну для вебсервера та для сервера задач треба окремо.)

Але ця змінне — це тільки домовленість, та не всі бібліотеки її виконують. Так сталося з бібліотекою gruf, яка у нас використовується для gRPC. Там паралелізація налаштовується окремо, а за замовчуванням значення береться з гему gRPC.

Тут нас очікувала халепа — бо у гемі gRPC за замовчуванням стоїть 30 паралельних потоків, а у RAILS_MAX_THREADS значення за замовчуванням тільки 5. Тобто 30 потоків RPC ділили 5 підключень до бази даних.

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

Вирішилось все використанням RAILS_MAX_THREADS як кількості потоків RPC - тож і вам раджу у своїх проєктах слідувати цій корисній конвенції.

26.12.2022

Основи TLS - VPN

Хочу закінчити серію постів про шифрування розповіддю про VPN, бо це типу теж шифрування, тож, наприклад, чи можна вважати, що якщо ти увімкнеш VPN, то вже не потрібно турбуватись про HTTPS? (Забігаючи наперед — НІ!)

VPN перпендикулярна технологія до TLS/HTTPS. Це категорія протоколів, що створюють безпечний канал між двома вузлами в Інтернеті. Але! Безпека VPN простягається тільки від твого компʼютера до сервісу VPN.

Бо насправді VPN - засіб для віддаленого підключення до приватної мережі. Наприклад, корпоративної. При цьому віддалений компʼютер потрапляє нібито всередину мережі. Ми на роботі користуємося внутрішнім VPN для обмеження доступу до ресурсів — дуже зручно, коли команда розповсюджена бозна-де.

🦺 Проте зараз VPN в першу чергу знають як засіб безпеки. Від чого VPN дійсно врятує: від хакерів на відкритому Wi-Fi; від регіональних блокувань; від стеження з боку провайдера.

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

🏴‍☠️ І головне, що абсолютно всі твої дані проходитимуть через сам сервіс VPN, тож у його власників є ідеальна можливість стежити за тобою та подекуди красти дані. Тому дуже важливо обрати такий сервіс, якому можна довіряти, особливо застерігаю проти безплатних.

Щодо надійних сервісів, я можу порадити Private Internet Access.

25.12.2022

Основи TLS - типові помилки протоколу та що вони значать

Напевно, всі ми більше за все стикаємся з TLS, коли він не працює. Розʼяснимо найчастіші випадки, коли це трапляється.

Найпоширеніша проблема - у сертифіката сервера сплив термін дії. Так, у всіх сертифікатів в принципі є термін дії. Чому? Головна причина в тому, що зі зростанням обчислювальної можливості безпека потребує довших ключів, тож старі сертифікати рано чи пізно стають небезпечними. Щоб уникнути цього, та інших можливих вразливостей, сертифікати необхідно примусово оновлювати, зазвичай раз на рік. 😅 Якщо адміністратор цього не зробить - клієнти побачать помилку “сплив термін дії сертифікату”. 👹 АБО зловмисник підібрав ключа до старого сертифікату, чи просто його вкрав.

Далі - трапляється що імʼя домену в сертифікаті не співпадає з адресою сервера. 😅 Це зазвичай проблема налаштувань DNS, а не сертифікату; а саме, домен спрямований на неправильний або не налаштований сервер. Так може статись на “спильному” хостингу, такому як Heroku, якщо не повідомити сервісу, що у вас є власний домен. Або сайт переїхав на інший домен, а сертифікат не поміняли. Або на сервері декілька доменів, та для деяких забули купити сертифікат. 👹 АБО хтось видає свій сервер за інший, може, з дуже схожим імʼям.

Інколи клієнт не може перевірити сертифікат, тому що в системі не вистачає кореневих сертифікатів. З сучасним та оновленим компʼютером чи телефоном такого ніколи не трапиться. 😅 Але на сервері трапляється, особливо в докері (де часто за замовчування ніякі сертифікати не встановлені), або зі старою версією ОС. Кращим рішенням буде встановити або оновити сертифікати. Гіршим - відключити аутентифікацію HTTPS, що вдасться зробити тільки з власним кодом. 👹 Ніколи не можна встановлювати додаткові кореневі сертифікати від особ, яким не довіряєш абсолютно - бо ця особа отримає можливість фальсифікувати для вашої системи будь-який сертифікат.

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

Коли побачите Помилку протоколу TLS або Несумісну версію TLS, то (з мого досвіду) це не буде викликано справжніми багами клієнта чи сервера. Скоріш за все, така помилка викликана тим, що сервер віддав HTTP замість HTTPS, а клієнт намагається трактувати документ HTTP як рукостискання TLS. 😅 Може, адміністратор переплутав порти, чи не увімкнув HTTPS. 👹 Але ще це улюблений метод третіх особ блокувати доступ. Наприклад, провайдера, якщо ти не заплатив за інтернет. Або деяка система безпеки заблокувала сайт. Оскільки ніхто не може підмінити HTTPS (та й добре!), то замість нього такі добродії дають браузеру сторінку HTTP. Щоб перевірити, треба замість https://mysite.com написати http://mysite.com:443 - це може показати справжню сторінку блокування.

24.12.2022

Основи TLS - як працює HTTPS

Отже, ми зʼясували потребу шифрувати обмін даними в інтернеті. Розглянемо, як це працює, на прикладі HTTPS - шифрованого протоколу перегляду вебсайтів.

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

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

Для надання цих двох гарантій існує протокол TLS. Він ніби “апгрейдить” підключення TCP - функціонально це той самий сталий канал, але тепер вже зашифрований. Так от, HTTPS - це абсолютно той же самий HTTP - єдина різниця в тому, що запити проходять по зашифрованому каналу TLS. Та це гарний приклад: так само працюють й інші протоколи, якім потрібне шифрування, наприклад, SMTP, про який я вже писав.

Щоб зробити з підключення TCP підключення TLS, потрібна процедура рукостискання. Перше, що присилає сервер клієнту після підʼєднання — це свій сертифікат. Клієнт аутентифікує сертифікат за допомогою своїх кореневих сертифікатів, як я писав раніше. Головне, що у сертифікаті сервера зазначено його доменне імʼя, та воно обовʼязково має збігатися з тим, куди відбувається підключення.

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

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

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

Раніше

Пізніше