У Льоні сьогодні

Одним реченням: Redis - це сервіс оперативної памʼяті. Почекай, скажеш ти, а навіщо нам цілий сервіс для памʼяті? В нас вже є памʼять вдома.

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

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

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

Якщо й всіх API мало, всередині Redis навіть можна виконувати скрипти на Lua! Та таким чином обійти ті обмеження повільного доступу — вибудувати з низькорівневих операцій власну бізнес-логіку.

Також Redis вміє зберігати власний стан на диск та навіть вести журнал для надійності. Головне памʼятати, що дані все одно повинні влазити в памʼять — це фундаментальна особливість.

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

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

Але хочу звернути увагу на інше бачення: Redis є спільною оперативною памʼяттю між багатьма вашими процесами чи машинами.

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

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

Redis достатньо швидкий: лише на 1-2 порядки повільніше за звичайну оперативку, та, наприклад, на порядок швидше ніж локальний SSD. (Єдина порада - не складати в один запис надто багато. Краще, коли це буде окремий примітив чи невеличкий обʼєкт.)

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

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

Дивись, є в тебе запит: SELECT timestamp FROM logs WHERE message LIKE *failed*. Як можна реалізувати його в базі? (Повнотекстовий пошук поки взагалі забудемо, бо він ще складніший.)

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

Та дійсно, навіть за наявністю індексу базі доведеться попросту перебирати всі значення. Звісно, що це буде… повільно. Втім, на допомогу нам прийде індекс за триграмами. (Ну, або N-грамами, узагальнено.)

Триграма — це шматочок тексту довжиною до 3 символів. Наше поле розрізаєaться на всі можливі шматочки:

request failed => r, re, req, e, eq, equ, ... led, ed, d

(Шматочки з одним та двома символами потрібні для коротких запитів. Хоча, скільки разів ти бачив “Для пошуку введіть хоча б 3 символи?” Тепер знаєш, чому.)

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

failed => fai, ail, ile, led

Ми шукаємо записи для кожної триграми окремо, а потім перетинаємо результати. Залишається тільки зробити зачистку, щоб прибрати небажані результати, наприклад, fai ail ile led - цей перебір займає вже зовсім трохи часу.

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

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

Збираюся підготувати для сімʼї певну інформаційну панель. Хочу показувати графік відключень, стан резервного живлення, стан повітряних тривог. Все це у зручному вигляді.

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

Як технічну базу та сховище планую мати HomeAssistant. Він вже має певні готові інтеграції, а також історію, можливість надіслати сповіщення. Далі можу або написати власну інтеграцію — чого ніколи не робив — або може просто використовувати API

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

Отже, моя ідея — залучити тут LLM. Наприклад, LLM легко здатна прочитати вище згадану сторінку та побудувати структурований в JSON чи iCal графік відключень для заданої групи. Повірте, я за своє життя не раз намагався зробити схожий парсер вручну — це нереально зробити повністю та важко зробити хоч якось. Це саме та задача, для яких існують нейронні мережі.

Ось так. Радий буду почути, якщо хтось вже робив щось схоже.

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

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

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

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

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

Головне — не поспішати зі змінами, щоб не наробити дурниць. Озирнутися ширше, спитати порад. А потім вирішувати, що робити та якою ціною.

Перший з кількох постів про реалізацію електрики для мого санвузла. Так, там матеріалу на маленьку книжку!

Я люблю сучасне багатомодульне освітлення. Але ненавиджу: пульти керування, застосунки, та панелі вимикачів, що нагадують кабіну літака.

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

Отже… Почнемо зі стельового освітлення. Довго перебирав варіанти та зупинився на Philips Hue Enrave S. Насамперед це якісні LED та добротна побудова. Але також я був впевнений, що з Hue буде працювати Home Assistant, та не створить проблем. Так, в цілому, й вийшло.

Є тільки один нюанс: будь-яка лампа Hue не буде працювати з класичним вимикачем, бо її електроніка мусить бути завжди заживлена. Отже, між лампою та вимикачем буде розумна начинка. Але… якщо HomeAssistant чомусь не працює, світло повинно вмикатися й без нього. Повір моєму досвіду — не роби розумний будинок без резервного керування, бо залишишся без зручностей в найбільш незручний час.

Знайомся — реле Shelly Plus 2PM. Я вже писав про нього, але в цьому проєкті реле розкривається ширше. В нього є два виходи — як раз на ванну та туалет — але також два входи, до яких підʼєднується той самий класичний вимикач.

В цього реле вже достатньо мозків, щоб керувати виходом зі входу. Але таке нам не треба, памʼятаєш? Тому насправді в HomeAssistant сидить автоматизація, яка слухає стан входу реле та передає Philips Hue команду увімкнення чи вимкнення. А виходи реле залишаються заживленими завжди.

Та тепер останній момент — що ж робить коли HA зліг? Власне, що мене переконало в виборі реле — це те, що на ньому можна також виконувати скрипти — на JavaScript. Та я знайшов скрипт, який перевіряє доступність HA та перемикає реле в незалежний режим, коли HA немає. Це ж фантастика!

І все це, звісно, тільки початок всієї реалізації.

(PS: не припиняю вражатися, що малесеньке реле, яке влазить за вимикачем в стінну коробку, містить в собі цілий компʼютер із Wi-Fi, Bluetooth та так, навіть віртуальною машиною JavaScript!)

Ще одна тема від пана Степана.

Програмісти — цікаві працівники. (Або це програмування — цікава задача.) Під час дай їм тиждень на задачу — зроблять за тиждень. Дай місяць — зроблять за місяць. Взагалі не давай ніяких обмежень — можуть й три місяці полірувати.

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

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

Якщо робиш проєкт як хобі — з цим простіше. Бо, або тобі взагалі байдуже, що з ним станеться, або ти все ж хочеш проєкт випустити та робиш в мінімальні терміни. Виходить парадокс: те, що на роботі зайняло б ітерацію, у своєму проєкті виходить за вечір. Так, десь воно буде поламане, тестів взагалі не буде, половину ми раніше — накопіювали б зі старих проєктів, а тепер — просто навайбкодимо. Але ж результат буде!

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

Дякую за цю тему пану Степану.

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

Справжньою цінністю, яку приносить інженер, є його рішення.

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

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

Мабуть, це вимагає певної впевненості в собі та сміливості. Бо, власне, коли ти не вирішуєш сам, а звертаєшся до керівника, то тим самим окреслюєш свій рівень та свою сферу відповідальності. Звісно, за власні рішення доведеться відповідати, в цьому і є цінність твоєї посади. Знову-таки, LLM згенерує що завгодно, але відповідальною не буде ніколи. Ти її керівник.

Отже, пропоную звернути увагу на те, які рішення ти приймаєш, а де впевненість (або довіра) закінчується.

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

The Pragmatic Programmer - моя улюблена книга з “практики програмування”. Тут немає конкретної мови чи підходу — тільки принципи та поради. Мені, звісно, зараз багато в ній здається банально очевидним, але це тому, що я її читав. Запевняю, ця книга зробить з тебе кращого програміста.

Domain-Driven Design - ця книжка в принципі описує певний підхід до архітектури застосунків — від спілкування з замовниками до розбиття на класи. Я ніколи не користувався цим підходом. Але це й не потрібно, бо ідеї закладені в цій книжці достатньо загальні, щоб користуватися ними навколо. Зокрема ідея того, що код продукту повинен використовувати ті ж назви, що й опис його бізнес-логіки.

The War of Art - так, це не книга з програмування. Це маніфест творчої людини. Вона торкається знайомих кожному програмісту труднощів. Зокрема, головне тут — ідея “опору” (resistance) - уявної сили, що заважає нам творити. Книга напівпоетична, але має, може, найпрактичніші з порад про те, як подолати опір та творити. Я наполегливо рекомендую аудіоверсію від автора, бо він читає з великим почуттям.

А у вас є такі книги? Ну, щоб не Кнут чи Кормен-Лайзерсон-Рівест, а щось що ти дійсно читав та досі згадуєш?

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

Хочу закінчити по те, як соціальні танці допомагають в житті.

Часто чоловіки уникають танців через те, що це “дівчаче заняття”. Втім, як я писав, соціальні парні танці навпаки ставлять чоловіків та жінок в суворі гендерні ролі. Ти не просто є присутнім в жіночій компанії, ти ведеш, ти ставиш тон, ти керуєш. Бути лідером в танці — це первісно маскулінне проявлення.

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

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

Пишу це та збираюся на наступне тренування. Де, знаю, доведеться трохи подумати, трохи напружитися, трохи навчитися, де буде весело, буде успіх, буде радість, буде зростання, буде весело. Чудові плани на пʼятницю, хіба ні?