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

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

02.03.2025

Затримка оновлення в OpenSearch

В OpenSearch/ElasticSearch є така цікава особливість, що між внесенням змін та їхнім ефектом минає кілька секунд. Тобто буквально доведеться почекати, щоб побачити, що щось змінилось.

Причиною є те, що OpenSearch видає результати тільки через словники (“індекси” мовою інших баз), а оновлення словника відбувається періодично — як мінімум, щосекундно. Бо оновлення є дорогою операцією та краще, коли воно працює з цілою пачкою змін.

Зауважу, що затримка ніяк не є наслідком того, що OpenSearch є розподіленою базою. Навіть один індекс на одній машині буде оновлюватися так саме повільно. Взагалі OpenSearch оптимізований для великого масштабу, а на малому працює не набагато швидше. Також затримка не впливає на надійність — зміни нікуди не дінуться.

З досвідом традиційних СУБД це є повною нісенітницею. Проте типові використання OpenSearch - наприклад, аналіз журналів — не потребують моментального застосування змін. Будь-яка архітектура з OpenSearch всередині повинна розділяти запис та читання та передбачати ці затримки. Тому на роль головної бази - OLTP - вона фізично не підходить.

01.03.2025

Зволожувачі

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

🔉 Ультразвукові зволожувачі розпилюють воду вібраціями. Перевагою тут є велика різноманітність форм. Недоліком цього методу є те, що вібрації розпилюють не тільки воду, а й все, що в ній знаходиться. А у воді, якщо вона не дистильована, містяться розчинені солі — тобто фактично пил. Тому ультразвуковий зволожувач підвищує PM2.5, як я сам бачив, та може навіть залишати наліт на меблях. Теоретично можна заправляти його тільки дистильованою водою, але це суттєво ускладнює використання (та тому я навіть не перевіряв такого варіанту.) До речі, ультразвуковий зволожувач взагалі не зволожує повітря, а створює водяні краплі, які швидко випаровуються. Частина цих крапель може осідати поруч — особливо, коли вологість вже висока.

🫖 Зволожувач гарячою парою це, буквально, кипʼятильник у зручному корпусі. Єдина форма зволожувача, яка не потребує змінних елементів — тільки очищення від накипу. (Накип — це ті самі солі.) Але є пара суттєвих недоліків. По-перше, він споживатиме багато енергії: 200-300 Вт. І це пристрій, увімкнений постійно. По-друге, кипʼятильник буде випаровувати навіть при підвищеній вологості, що ризиковано — надмірна вологість ще гірша для оселі, ніж сухість.

💨 Зволожувач холодною парою складається з вентилятора та величезного паперового фільтра, а точніша — гніта. Гніт одним боком стоїть в посудині з водою та капілярним ефектом тягне її вгору. Вентилятор сприяє випаровуванню, тобто “сушить” гніт та зволожує повітря. Тут і енергії витрачається менше (10 Вт), і випаровування фізично уповільнюється, коли повітря вже вологе. Солі залишаються на папері. Недолік — мокрий папір згодом плодить бактерії та грибки, тож фільтр доведеться міняти. Ба більше, такий зволожувач не можна залишати мокрим та вмикати час від часу — стояча вода зацвіте ще швидше.

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

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

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

28.02.2025

Кліматична гра

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

Доведеться збалансувати температуру, вологість, рівень пилу PM2.5, та рівень вуглекислого газу CO2. Для початку, треба надбати пристрій, який все це може поміряти. А краще — по одному на кімнату. В мене вже роки 4 стоять Awair Element, але варіантів багато. Непогана відкрита система AirGradient.

Та далі починається… Для CO2 є єдине рішення — провітрювати. Також CO2 накопичується з часом; якщо сидіти в закритій кімнаті, то дуже суттєво! Підвищений рівень CO2 погіршує розумові здібності, до речі.

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

Пил можна прибрати очищувачем повітря. Їх багато різних, та всі потребують змінних фільтрів. Раджу брати такий, до якого фільтри будуть доступними, тобто відомий бренд. Чи потрібний очищувач — залежить від ваших обставин; в місті взимку стабільно багато PM2.5 через опалювальний сезон.

Вологість — тихий злодій зимового сезону. Зовнішнє повітря дуже сухе взимку: чим холодніше, тим менше пари може утримати повітря. Сухість впливає на шкіру, дихання, електростатику, деревʼяні меблі та підлогу… одним словом, на все. Та взимку вологості немає звідки взятися природно — покращити обставини можна тільки зволожувачем. (Ну, або кипʼятити багато води, приймати багато душів, сушити багато білизни…) Про зволожувачі можу ще багато написати, бо це виходить головний кліматичний пристрій взимку після опалення.

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

27.02.2025

Три приклади використання манкіпатчингу в Ruby

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

Для ізоляції тестового екземпляра. Бібліотека rspec-mocks та інші побудовані на тому, що в Ruby без всякого Dependency Injection можна замінити окремі властивості або поведінку обʼєктів. Інколи це прямо уможливлює написання тестів там, де в іншій мові їх було б надто дорого писати.
Для виправлення помилок в бібліотеках. От знайшли ви, що чужий код працює неправильно (або з небажаними ефектами.) В Ruby можна відкрити чужий клас та замінити в ньому потрібний метод — прямо з власного коду. Так можна почати працювати з виправленим кодом вже сьогодні, а не чекати, поки виправлення приймуть автори. Також для того не потрібно ані форкати, ані вендорити цю бібліотеку.
Для перевірки коду в продакшні. Коли потрібно щось швиденько перевірити, то зовсім не потрібно розгортувати цілу нову версію застосунку — достатньо одного скрипту, в якому можна відкрити будь-які класи та впровадити зміни. Це дуже зручно для профілювання, або швидкого пошуку помилок.

26.02.2025

Як залізти назад в човен?

🏄‍♂️ В колах самоменеджерів ходить така фраза, як “впасти з воза” (fall off the wagon): це коли ти припиняєш підтримувати систему. Далі на цей віз треба залізти та їхати далі. Проте мені більше подобається не віз, а човен чи навіть дошка для серфінгу: бо коли “впадаєш з човна”, вода — задачі — нікуди не зникає, а навпаки, тепер доведеться вигрібати поточні справи вручну, поки не залізеш назад.

Для мене головною проблемою із відновленням системи є — що робити з попереднім списком задач? Продовжувати як є — морально дуже важко. Викинути — ризиковано, бо завжди там сидітиме пара задач “з другого квадранту”, які потрібно зробити обовʼязково, навіть якщо час минув. Насправді навіть щось з нього викинути теж важко. Окрім утоплених витрат, взагалі важко (мені?) відмовлятися від задуманого.

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

Допоможе прорідити список система “мабуть/колись”. До “мабуть/колись” менше вимог, тому від неї значно менше стресу. Все зі старого списку, що не потребує невідкладного виконання, може йти в “мабуть/колись” та сидіти там… а хоч довічно. Головне, що ми й не забудемо нічого, і зобовʼязань не беремо зайвих. (А ще краще переносити задачі в “мабуть/колись” раніше, ще на тижневому огляді, як тільки ясно, що поки на них немає часу.)

25.02.2025

Express.js

Один з моїх улюблених засобів для створення простого вебсервера - Express. Для рубістів - Express дуже схожий за настроєм з Sinatra.

const app = express();
app.get("/", function (req, res) {
  res.send(`Hello, ${req.query.name}!`);
});

JavaScript гарна мова з бібліотеками на всі випадки життя. TypeScript та Prettier роблять розробку зручною без обтяжування. Порівняно з тією ж Сінатрою, я можу впевнено досягати результатів. А порівняно з Go швидко. Для прототипів це золота середина.
Синтаксис та семантика Express прості та зрозумілі. Оголошувати маршрути, читати запити та генерувати відповіді можна з мінімумом рухів. Абстракція над HTTP прозора, завжди видно, що куди йде. Чомусь робота з тілом запита POST винесена в окремий пакет body-parser, але то дрібниці.
Nodemon та ts-node роблять локальний запуск та перезапуск простим та зрозумілим. Запускаєш yarn run nodemon entry.ts та все, можна працювати.
Express легко (відносно…) розгорнути — або навіть перетворити застосунок на serverless. Відносно, бо не люблю технології, які залежать від вихідного коду бібліотек в продакшні — хай то node_modules, геми Ruby тощо. Втім, принаймні всі залежності для Node.js розташовуються в одній директорії з проєктом.

Раджу мати Express на озброєнні для маленьких вебсервісів — прототипів, однозадачних серверів, обгорток всіляких.

24.02.2025

Мікроменеджмент

Критика мікроменеджменту (тобто стилю менеджменту з надмірною увагою до деталей, а також до контролю підлеглих) серед айтівців це як товкти воду в ступі: консенсус такий, що мікроменеджмент — погано та непрофесійно.

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

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

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

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

23.02.2025

OAuth2 - це просто... завдяки HTTPS

Майже 10 років тому я написав пост про те, як легко впровадити OAuth2 без жодних бібліотек: OAuth2 is easy. Сьогодні — трохи продовження.

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

HTTPS не просто робить вебсерфінг “трохи” безпечніше, він розвʼязує дві фундаментальні задачі безпеки: підтверджує автентичність сервера та встановлює надійно зашифрований канал до нього. Тому ми й можемо спокійно надсилати ключі (спільні секрети) “відкритим” текстом, а також довіряти відповідям.

Проблемою OAuth2 було те, що він був настільки простим, що кожний провайдер робив щось своє (про що я згадую у статті.) Тому писати загальну авторизацію було складно чи навіть неможливо. Зараз з цим стало краще, бо є протокол OpenID Connect, який стандартизує поведінку провайдерів. (Та OpenID Connect нічого спільного не має з тим OpenID, який я колись тримав на своєму сервері з phpMyID)

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

22.02.2025

Проєкти зеленого поля

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

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

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

Зокрема, ще складніше обʼєднувати декілька продуктів для розвʼязання власної задачі. Навіть коли по кожному є документація, рідко вона передбачає твою комбінацію. (От є бібліотека для JS, але чи працює вона в React Native?) До того ж проблеми можуть виникнути на різних шарах абстракції (А чому Metro не бачить типів тієї бібліотеки та що поміняти, щоб бачив?) Інтеграція не продається, її завжди доведеться збирати власноруч.

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

21.02.2025

Проєкти зеленого поля

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

Ну добре… як ото світло згенерувати в умовах комори? Походив по форумах, дізнався, що зараз всі ставлять електричні лампи. Купив лампу: LED 18W 6500K (як у сонця.) Не працює. Почитав далі — та до них ще джерело живлення потрібно! Купив джерело живлення Energizer AAA. По-перше, як його взагалі підʼєднати? По уму всі друкують плати якісь, але то ще покупати апаратуру… або дроти, це нам більше по бюджету. Все одно щось ніяк, лампу з енерджайзером зʼєднав, а вона не світить.

Роздивився, що в лампи та в батарейки різна напруга? Добре, а де взяти ті 220V? Взагалі бачу, що для того будують електростанції. Зараз як раз є холівар: або ядерну, або сонячну (це наше!), або на газі… це все не зірка, але все одно для комори якось зовсім не той масштаб. А от бензинові електростанції є дуже компактні, поміститься. Тільки треба придумати, що робити з продуктами горіння.

…Прийшов сусід, послухав про 220V, каже — так в нас такі розетки є! Я питаю — що за розетки? А воно виходить — уявляєте — в коморі прямо в стіні дірки, з яких дротом можна забрати чітко 220V, як лампі потрібно! Залишилося зовсім небагато, але про це пізніше.

Раніше

Пізніше