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

Google BigQueryЯ взагалі не люблю Google Cloud. В них все не як у людей. Але якщо є причина користуватися Google Cloud, то це буде BigQuery.BigQuery - це база даних OLAP. Не потребує розгортування, тобто доступна як сервіс. Легка на підйом та безрозмірна. Заливаєш туди дані, робиш запити. Працює все швидко навіть на терабайтах даних.Тут, мабуть, ще відступлю та скажу, що таке база даних OLAP. Така база спроєктована для виконання рідких складних запитів на великих обсягах даних. В протилежність базам OLTP - з якими звикли мати справу розробники — як PostgreSQL чи MySQL тощо. Важливо розуміти, що в базах OLAP завжди закладена "стартова ціна" та навіть на маленьких обсягах вони будуть дорожче та повільніше. Якщо база OLTP здатна грати роль OLAP, поки даних мало, то навпаки не вийде.В BigQuery легко збирати дані — власне, для OLAP-бази це необхідність. Я навіть писав конектор через gRPC. Але того робити не обовʼязково — є купа вбудованих рішень — наприклад, через Cloud Storage. Або з журналів, звісно.Зверху BQ є Looker Studio - платформа для звітів та графіків. Наші аналітики від всього цього в захваті. А інженерам важливо знати, чого хочуть аналітики.Головний недолік BigQuery, для мене — це навіть не сама ціна, а те, що вона привʼязана до обʼєму оброблених даних. Та можна легко пробити дно навіть простим запитом, якщо він достатньо широко бере. Треба бути обережним.︙ Підтримати канал: 👑 Patreon ︙

Вайб-видалення коду#ПомічникШІЩо, думаєте, LLM здатні тільки генерувати код? Поганий, брудний, зайвий код?А якщо я скажу, що сьогодні видалив понад 1000 рядків коду — повністю через Cursor? Власноруч не видалив жодного рядка! Просто написав запит, зачинив очі, та — код зник!Йдеться про певну застарілу функціональність, яка знята з використання ще три роки тому. Але видалити не було нагоди, бо ця тисяча рядків коду розкидана по багатьох частинах та шарах застосунку. Досі вона сиділа та чекала, поки в когось зʼявиться зайвий день, щоб її вичистити. (А не зʼявиться він ніколи.)Аж от сьогодні робив подальший рефакторинг, та помітив, що зачіпляю цей застарілий код. Тож відклав поточну задачу та запустив агента на видалення.Агент все знайшов за лічені хвилини. Причому це ж Rails, тому рядки треба шукати як BlueMoon, так і blue_moon, а на фронтенді ще й redMoon - бо функціональність колись перейменували. І тести вичистив. І маршрути. І всі згадки в інших моделях. Ще й Rubocop заспокоїв.(До речі: що стосується Rubocop та інших інструментів, то я роблю так: запускаю, та якщо щось йде не так — виділяю весь вихід комбінацією Cmd+Shift+Up та надсилаю агенту: Cmd+L. Нехай розбирається.)До чого я веду. У вас, певно, багато такого брухту, від якого просто немає часу позбавитись. Делегуйте це агентам.︙ Підтримати канал: 👑 Patreon ︙

2 помилки в наступних діях у GTDСьогодні пощастило цілий день сидіти без світла. На роботі взяв вихідний, відкрив контекст "Вдома", та поробив з нього все, що міг. Така вона, сила контекстів! (А також — обмеження часу за компʼютером.)Отже, розповім про дві помилки в наступних діях, які мені часто допікають.Нумер перший: дії ""розпланувати Х" чи "подумати над Y". Коли не зрозуміло, як розпочати певний проєкт, кортить записати щось подібне та перестрибнути далі. Тільки таким діям бракує конкретики; а як ми знаємо, де немає конкретики на момент розбору — там ми будемо буксувати під час виконання.Незрозумілості можуть бути на різному рівні. Може, сам проєкт недостатньо визначений чи ми погано про нього знаємо. Тоді допоможе щось як "Сформулювати 5 критеріїв успіху Х." Або "Записати постановку задачі Y одним параграфом." Допоможуть питання для продумування проєктів.А може, задача ясна, але ти ніколи такого не робив та не вмієш. Тоді можна "Спитати в А, як він робив Х." Чи "Знайти книжку про Y". Чи, в наші часи, звернутися до LLM та розблокувати себе за мить.Нумер другий: дії, для яких ніколи не буде часу. Типовий приклад — географічні дії: "відвідати таке-то місце". Якщо воно не розташоване на звичному маршруті, то така дія — це цілий прихований проєкт з власним плануванням.Отже, розмотуємо: напевно, відвідання треба запланувати, тобто записати в календар. Можемо визначитися та зробити це зараз? Чудово. Не можемо? Може треба домовитись з кимось? Або чого чекаємо? Тобто, за #GTD, що запишемо в список очікування? Нічого конкретного, просто не хочеться зараз робити? То що, проєкт пересувається до мабуть/колись? От і зʼясували.Взагалі треба бути готовим до того, що ефективним наступним діям вчишся поступово, тож нічого дивного, що спочатку будеш наче все робити за правилами, а тертя в системі залишиться.Нагадую, що в суботу 10.1 о 16:00 за Києвом буде воркшоп з усієї цієї історії з GTD, а доєднатися до нього можна через Patreon.︙ Підтримати канал: 👑 Patreon ︙

Проблема гуркітливого табуна(Як звучить, га? Thundering herd, може, чули.)Так називається ситуація, де багато споживачів одночасно звертаються до одного обмеженого ресурсу.Певно, найтиповіший випадок — одночасний старт багатьох копій сервісу. Та, припустимо, цей сервіс зчитує з бази складну конфігурацію. Якщо сервіс один, все проходить непомітно. Але з декількома копіями база несподівано лягає. Під копитами гуркітливого табуна.А якщо ви покладете конфігурацію в кеш, проблема не те щоб зникає. Бо все одно всі звернуться до бази, аж поки перший запит не завершиться та в кеші не зʼявиться значення. Так само буде й після вичерпання терміну придатності кешу.Інший приклад: класична помилка планувати повторювані задачі на початок дня чи години. Чітко на нуль хвилин. Таке призводить до раптового вичерпання ресурсів системи. (Зокрема, поштові сервіси отримують пікове навантаження саме в рокові нульові хвилини.)Порятунок від гуркітливого табуна, зазвичай, це розосередження викликів. Впровадження маленької випадкової розбіжності: 1 min + rand(5) s. Уникнення монотонності. Словами Франка Герберта, walk without rhythm and it won't attract the worm.Є й інший, значно складніший вихід. Але він допоможе, коли виклики відбуваються непередбачувано. Це згортання запитів (request coalescing або request collapsing.) Власне, потрібний посередник, який буде відстежувати однакові та одночасні запити, робити лише один, та роздавати результат усім. Наприклад, цим може займатися nginx з директивою proxy_cache_lock.︙ Підтримати канал: 👑 Patreon ︙

OmniWOPE - тепер в DiscordНа новорічних канікулах додав можливість виводити в Discord до OmniWOPE - мого рішення для кроспостингу.Хотів ще до Patreon постити, але там, несподівано, не знайшлося для цього API. Постити можна тільки вручну. Ну, нічого не поробиш.А в Discord все достатньо просто — є JSON API. Ним можна створювати пости із форматуванням, які чудово лягають під мій контент. Щоправда, доведеться кожному користувачу створити для себе застосунок та бота — адже запускається скрипт на їхньому компʼютері. Ну але то таке, розвага на один раз.Звісно, ще простіше було реалізувати все через LLM, бо я практично не писав коду сам. Поточний підхід — ретельно пропрацювати план в Markdown, а потім запускати на виконання. (Це 100% тема для майбутнього воркшопу.) Причому LLM здатна пропрацювати всі аспекти — і дослідження, і тестування, і написання інструкції.З цікавих моментів була ідентифікація каналу. Спочатку я збирався вказувати в конфігурації назву каналу. Бо ID каналу в UI ніде не світиться. Але назви недостатньо без ID спільноти (яка в API називається guild, до речі.) Тому знайшов прямий та в ретроспективі очевидний підхід: з каналу легко скопіювати посилання для поширення; це посилання і містить ID як каналу, так і гільдії. Люблю, коли URL дійсно є Універсальним Локатором Ресурсу, а не чимсь там іншим.Хотілося б ще додати вихід у поштову розсилку. Може, навіть через Mailtrap.︙ Підтримати канал: 👑 Patreon ︙

🎅 З Новим роком вас, любі підписники! Сподіваюся, що ви вже знаєте, до чого прагнути у 2026 році, та що для того робити.🤝 Я, своєю чергою, хочу більше працювати зі спільнотою. Цього року, з подачі пана Данила, я розпочинаю живі воркшопи. Наразі мета один двогодинний воркшоп раз на місяць. Тема — щось мені добре знайоме — можливо, цікава база даних, мова програмування, технології чи підходи.📅 Перший воркшоп відбудеться наступної суботи, 10 січня, о 16:00 за Києвом. Темою буде самоорганізація на роботі та в житті, зокрема Getting Things Done.📺 Воркшопи проводитимуться через Discord. Для отримання доступу до воркшопу потрібно підписатися на Patreon.🎓 А також я зайнявся менторством! Вище згаданий пан Данило якраз і став моїм першим менті (за що я дуже вдячний). Хочу взяти ще 2-3, не більше, тож якщо тобі цікаво, не зволікай! Стати менті можна через той самий Patreon. Найбільше це буде корисно вже досвідченим інженерам, які хочуть зрости та піднятися на наступний щабель відповідальності.🔗 Нарешті — щось я мало про це прошу — поділіться посиланням на цей канал! Ось, для зручності: https://t.me/stendap_sogodni. Та відгукніться в коментарях 👋

Розкласти по фактахЩе раз дякую за тему пану Степану.В IT існує певний культ фактів. Де факти — там правда. Розмова про факти набуває академічної ваги. Люди, які оперують тими фактами — видаються неемоційними, неупередженими, та вартими довіри. Проблема в тому, що часто це тільки прикриття.Інколи людина вже обрала рішення, та хоче, щоб його прийняли. Але асертивно сказати "я хочу зробити так і так" не вміє. Тоді факти стають маніпуляцією. Їх обирають так, щоб рішення було привабливим. Ключовим тут є те, що рішення вже обране. Та часто цей вибір обґрунтований зовсім іншими факторами — насамперед власними уподобаннями та досвідом.Коли є двоє з суперечливими рішеннями — починається ще й боротьба фактами-маніпуляціями. Хто краще подасть факти — той і переможе. Це може виглядати, як чесний аналіз — втім, оскільки всі рішення вже обрані, факти не змінять нічию думку, а лише здатні задавити її.Насправді коли рішення немає та впевненості немає, може трапитись ще гірше — факти служать прикриттям до цієї невпевненості. Я особисто ненавиджу приймати рішення суто по фактах. Мені треба, щоб я відчував, що роблю правильно. Та, звісно, факти можуть допомогти набути це відчуття. Але поки я дивлюся на варіанти та бачу про них тільки факти — обирати рано.🎄 А зараз я йду в новорічну відпустку. Наступний пост буде 5 січня. З прийдешнім Новим роком вас! 🎅

Quake#ІгриВ моїй уяві є архетип шутера, з яким я порівнюю всі інші — свідомо чи несвідомо. Це - Quake 1. Де в кого Doom - це перший "справжній шутер", але я гадаю саме Quake набув справжньої сучасної форми. Не кажучи вже про те, що саме рушій Quake лежить в корні численних сучасних ігор.Quake швидкий, стрибучий, тут немає укриттів та вся безпека в рухомості та агресії. Це, в цілому, та ж гра, що й Doom Eternal - тільки зведена до мінімалістично ідеальної формули.Саме на Quake 1 я навчився WASD. Саме там був мій перший мультиплеєр — в школі, в той час, коли ми повинні були розвʼязувати олімпіадні задачі.Потім на Quake я вивчав 3D-графіку, дізнавався, що таке BSP (бінарне розбиття простору), а також .bsp - формат файлів, в яких Quake зберігає рівні. А тепер можна взагалі код його вивчати.Ще двадцять з гаком років тому на Quake була сцена модів, деякі з них повністю змінювали суть гри, наприклад, перетворювали її на фентезі чи на військовий шутер. Але смішно, що моди не могли замінити скрипти поведінки, тому в ворогах завжди впізнавалися знайомі фігури (особливо той характерний людожер з бензопилою та гранатометом.)Звісно ж, Quake живий й досі. Та досі чарує своєю простотою — це така гра, в яку легко встрибнути. Можу порадити рушій Quakespasm (навіть на мак можна!) та сайт Slipseer з модами. От відразу раджу Brutalist Jam.

Надгробки в базах данихОК, ще одна повʼязана ідея, з якою мені чомусь постійно доводиться стикатися останнім часом.Річ у тім, що видалення з бази даних практично ніколи не вивільняє місце запису. Натомість запис помічається як видалений — утворюється так званий надгробок (tombstone). І тільки пізніше, окремою операцією очищення бази це місце буде дійсно вивільнено. Інколи таке очищення відбувається лише вручну... або за певної архітектури взагалі не є можливою.Те ж саме стосується й редагування. Бо найчастіше редагування відбувається через "видалення" попередньої версії та дописування нової. Тим самим у нас теж зʼявляється надгробок. На то є кілька причин — в транзакційній базі головна причина те, що нам все одно треба зберігати й стару версію теж. Так само і в розподіленій базі.От якщо взяти PostgreSQL, то надгробки видаляються операцією VACUUM. Яка може виконуватися й автоматично. Може, а якщо це не налаштовано, то цілком реально опинитися з табличкою, де мертвих записів на порядок більше, ніж живих.В ElasticSearch все складніше; найкращій та рекомендований варіант — це просто видаляти весь застарілий індекс. Бо інакше його доведеться принаймні заморожувати на запис. Тому навіть використовується такий підхід, що оновлені документи пишуться в нові індекси, а не в один.Інколи надгробки є більш... матеріальними, от в CouchDB їх роблять заради синхронізації видалень між вузлами. Та й взагалі будь-де синхронізація вимагає надгробків.А інколи ми робимо їх самі - додаємо поле deleted_at.

Що ж воно таке за дерево той індекс?ОК, давайте відразу виправлюсь: все ж індекси використовують Б-дерева, а не двійкові дерева. Але в чому різниця?Двійкове дерево то є просто дерево, де в кожного вузла не більше двох дітей. Є двійкові дерева пошуку, де ці діти (піддерева) містять"елементи менші за поточний" та "більші". Є збалансовані дерева, де піддерева мають рівний (чи приблизно рівний) розмір. (Бо наївна побудова дерева може дати зовсім не рівний та не ефективний результат.)А Б-дерево — це як збалансоване двійкове дерево пошуку, тільки замість того щоб тримати в кожному вузлі тільки один елемент, тепер їх стає N - та так само як у двійковому дереві, ці елементи ділять простір пошуку на піддерева — але їх вже не два, а N+1. Відповідно, дерево стає "щільнішим", вузлів в ньому стає менше, як і глибини.А чому, власне, взагалі для пошуку беруть дерева, а не щось інше? Бо за деревом можна не тільки швидко шукати, а й швидко вносити зміни. (Швидко — це зі складністю O(N log N).) Б-дерева саме й винайшли для прискорення пошуку у великих файлах. Причому з такою вимогою, щоб можна було завантажувати в памʼять лише частину дерева.Б-дерева настільки прижилися, що зустрічаються майже в будь-якій базі даних. Їх можна знайти й у звичайних структурах даних різних мов - JavaScript, Go, Rust тощо. Трохи кумедно, що вони здаються складнішою структурою, втім насправді ми користуємося ними постійно — за лаштунками простих абстракцій.