Мамкін Архітектор

Ось візуалізація матриці 2 на 2 (або, як правильно підмітили у коментарях, матриці Ейзенхауера, про це можна і на сріні теж прочитати).

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

Важливість визначає, чи треба це робити саме вам, бо задача вимагає ваший особливих навичок чи вмінь.

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

Відповідно, алгоритм для обробки списка задач приблизно ось такий

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

Неважливі термінові делегуємо (якщо треба організувати зустріч зі стейкхолдерами, то доручаємо це асистенту)

Важливі нетермінові плануємо на потім (написати драфт пропозала для нового проекту, який запускаємо наступного місяця)

Неважливі і нетермінові просто викидаємо (черговий пост про Redis в телеграм канал писати не будемо, бо і так всі все знають)

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

Тоді одним із підходів до побудови інформаційних систем (це те, шо зараз називають мікросервісами і клаудами) було використання такої собі enterprise message bus. Діди здригнуться, прочитавши назви Tibco, IBM WebSphere MQ чи Microsoft BizTalk. То були люті часи, ті системи коштували, як хмарочос, потребували команди сертифікованих адмінів і давали надію власникам бізнесу, шо "ось зараз заживемо". Програмісти не потрібні (або їх треба сильно менше), замість написання якихось своїх велосипедів треба просто робити XML, закидати його в шину, і читати, що там закинули інші. І тепер бухгалтерія дізнається, що там оприходували на складі, бо їхні системи інтегруються через шину.

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

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

Але це все не означає, що зараз ті всі рецепти втратили актуальність. Навпаки, рішення асинхронної взаємодії стали набагато доступнішими і більш функціональними. В кожному клауді є декілька рішень для черг. On premise теж можна використовувати безліч чудових продуктів. І для побудови сучасних стартапів це дуже привабливий архитектурний підхід. Адже асинхронна взаємодія набагато надійніша і гнучкіша, аніж стандартні RPC (remote procedure call) підходи.

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

Ось посилання на сайт: https://www.enterpriseintegrationpatterns.com/patterns/messaging/

Натрапив на цікавий пост про чийсь досвід із проєктування фінансових систем. Ось вижимка для нетерплячих:

- 🌀 Уся обробка має бути ідемпотентною – ми не хочемо, щоб під час повторного запиту з рахунків знялися зайві кошти.

- 🗂️ Система має зберігати історію, а не лише кінцевий стан – привіт, друже event sourcing.

- 💰 Зберігати гроші потрібно в найменших одиницях:
- Якщо лише одна валюта (гривня), то в копійках.
- Якщо можливі конвертації – використовуйте DECIMAL(19,4).

- 🔄 Округлювати можна як завгодно, головне, щоб всюди однаково.

- 🔢 Конвертації краще робити в кінці розрахунків.

- ⏱️ Час зберігати в INT (unix time – це дуже потужна штука, я в Redis його використовую і дуже тішуся).

📌 Оригінальний пост з картинками і більше тексту:
Engineering principles and best practices

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

За свою карʼєру я був експертом по Delphi, MS SQL, .NET, Kafka. Тому що постійно працював з ними, слідкував за оновленнями, стикався з проблемами, вирішення яких підвищувало мій рівень експертності. Але зараз звісно не на всі питання зможу відповісти (а деякі може і не зрозумію взагалі).

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

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

Що думаєте?

Ще трошки #реклама від партнерів для тих, хто хоче прокачатись

🦾 Не відкладайте карʼєрний розвиток у розробці та архітектурі ще на рік — придбайте сертифікат на навчання зі знижкою до 40% на всі ІТ-курси від robot_dreams.
⠀
Серед курсів, які вже є в розкладі на 2025 рік:

🏃🏻Golang для розробників — навчитеся створювати високопродуктивні програми на Go

🔧Docker & Kubernetes — опануєте інструменти контейнеризації та оркестрації, щоб прискорити розробку та забезпечити стабільність інфраструктури

🔗Архітектура високих навантажень — опануєте сучасні практики з хайлоаду та системного дизайну, що застосовують у великих компаніях

♾️DevOps — опануєте всі потрібні інструменти й технології для автоматизації розробки, налаштування софту і підтримки його робочого стану

⚙️Чистий код і патерни проєктування — навчитеся рефакторити код та швидко опануєте 30+ патернів проєктування

Плануйте своє навчання у 2025-му році:
👉 Купуєте сертифікат до 31 грудня
👉 Обираєте напрям та курс
👉 Підключаєтесь до навчання та зростаєте в розробці й архітектурі

Більше курсів та деталі акції ⬅️

Гарна інфографіка від bytebytego про kafka. Ніколи не користувався flink до речі, а ви?

(ще трохи інфоциганщини, бо пʼятниця)

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

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

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

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

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

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

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

Шо ще?

Я все ніяк не почну проходити цього річний Advent of Code, натомість (трохи з заздрістю) дивлюсь, як це роблять інші. І знову хочу нагадати вам про канал Сіпласпластик, який мало того, що регулярно постить по мотивам AoC, а ще й розвʼязує задачі на різних мовах програмування, і по його постам можна скласти враження про них.

Прямо як книжка 7 Languages in 7 Weeks в форматі телеграм каналу.

https://t.me/cpplastic/361

Замовники часто приходять із готовим рішенням, замість того щоб описати проблему, яку вони намагаються вирішити. Ось типовий приклад з адмінським UI:

Ситуація
Замовник каже: “Нам потрібен дашборд з таблицею, де буде 15 стовпців, 5 фільтрів і можливість експортувати все у PDF та Excel. Зробіть, будь ласка (тобто бігом).”

У чому проблема?
Замовник вже запропонував рішення: “таблиця з 15 стовпцями та фільтрами”. Однак він не пояснив:

• Чому саме 15 стовпців?
• Які дані найважливіші для користувача?
• Що насправді потрібно досягти з цим дашбордом?

Що потрібно зробити?
Замість беззаперечного виконання, потрібно повернутися до проблеми та зрозуміти вимоги:

Питання до замовника:

Для чого потрібен цей дашборд? — Щоб побачити ключові метрики чи знаходити певні аномалії?

Хто буде користуватися цим дашбордом? — Адміністратори, аналітики чи менеджери?

Які дії ви очікуєте від користувачів після перегляду цих даних? — Прийняти рішення, надіслати звіт чи щось інше?

З’ясувавши проблему, можна запропонувати більш оптимальне рішення:

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

Результат:
Адмінське UI стане зручнішим, ефективнішим і буде вирішувати реальну проблему, а не “втілювати” готове рішення замовника.

попросили поділитись цікавою ініціативою, а я і не проти

Найкращий час для творення змін — сьогодні.
Бо освіта не чекає, а життя — тим паче.

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

Програма «СтудМентор» — це програма волонтерства та розвитку, в якій українська молодь вивчає менторинг та застосовує його для викладання шкільних предметів у онлайні для дітей з прифронтових регіонів.

Умови участі:
📌 тобі 18-35 років;
📌 ти маєш глибокі знання з одного зі шкільних предметів;
📌 готовий/а приділяти програмі 4+ години залученості на тиждень;

Формат:
📌 уроки з учнями відбуваються онлайн, двічі на тиждень, по 45 хвилин;
📌 один/а ментор/ка викладає для 1 або 2 груп учнів (одна група — до 3 дітей 5-11 класу);
📌 команда «Навчай для України» забезпечує менторів/ок усіма матеріалами для викладання та постійним супроводом вчителів із досвідом.

Долучитися до програми можна за посиланням: https://forms.gle/fzMFrve5Nxr7wWNcA

Гарна інфографіка про API security. Єдине що хочеться додати — в багатьох випадках для веб застосунків API взагалі не потрібен.
Але це тема для майбутніх постів.

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

http://t.me/stendap_sogodni/176

Я колись писав, шо не люблю slack і jira / confluence. Бо вважав це унилим enterprisом, і коли в мене зʼявилась можливість, запустив процеси на discord і notion. Це було прикольно, обидва інструменти цікаві, були певні моменти, проте все вирішувалось.

Але життя занесло в ще один сетап, в якому (surprise, маза фака) той самий starter pack поміркованого стартапера. І я такий "oh shit, here we go again" почав то все використовувати, і... зрозумів, шо воно доволі прикольне.

Slack додав собі з останнього часу, як я його бачив, купу цікавих штук, чим стає дуже схожий на Notion. (Хоча мабуть насправді на teams, але не будемо згадувати його всує). Списки задач з делегуванням, канвас, де можна написати шо хочеш, зручний механізм відслідковувати свої заборгованості через нагадування – і це все навіть без сторонніх інтеграцій. Завести різні канали, типу сповіщень інфраструктури чи ще чогось, завжди було легше в слак. Єдине, що не можна процитувати частину повідомлення у відповіді, але фіг з ним – треба ж кудись рости.

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

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

Кароч, я тепер поціновувач і слаку і jira. Кидайте помідори в коментах.

Супер книжка (її ще називають "книжка з мостами", що ставить її в ряд до "кабанчика", "планера" і інших культових книжок), яка відносно стара, але не втрачає своєї актуальності. Для мене вона фундаментальна, бо свого часу відкрила абсолютно інший підхід до архітектури — message driven. Бо до цього в голові була лише модель синхронної взаємодії, коли один сервіс викликав інший, так само, як один клас викликав інший. До речі, OOP, який більшість з нас знає, насправді "неправильний", бо оригінальна ідея, реалізована в SmallTalk передбачала саме асинхронний обмін повідомленнями між обʼєктами, а не прямі виклики. Принаймні, це моє розуміння, я не дуже вдавався в деталі, напишіть в коментах, як правильно.

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

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

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

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

Так, хотів написати про книжку, а натомість мене винесло на філософію про messaging. Будемо вважати це вступом до наступного посту, який вже буде про книжку 🙂

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

Перше, це потрібно її десь зафіксувати. Коли я читав про GTD, мабуть сама головна думка, яку я виніс звідти, це те, що інформацію потрібно якнайшвидше виносити з голови. Чим більше речей ми тримаємо в голові, тим більше стресу це створює, і в цілому наше самопочуття і продуктивність погіршується. Тому швиденько потрібно кудись це записати.

Я особисто заношу або просто у daily note обсідіану, якщо я за компом. Або створюю нотатку в notes, якщо я з телефоном. Або просто надиктовую в годинник, якщо на ходу і інші методи незручні.

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

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

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

Таким чином я можу забути про цю задачу, і покластись на інструменти.

А ви шо? Розкажіть про ваш підхід

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

Коли я заходжу в новий проект (тут мав би бути прикол про рушник під ноги), дуже стрімко починає рости власний беклог. І те треба було б зробити, і те, а без цього ми і дня не протримаємось. Задачі накидується, і постає питання – а як то все приоритизувати?

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

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

Зустрічайте матрицю 2 на 2. Малюємо табличку 2 на 2. По горизонталі в нас буде оцінка важливості, а по вертикалі – терміновості. Для кожної задачі визначаємо, чи є вона важливою, та чи є терміновою, і по результатам закидаємо в табличку. І таким чином отримуємо кластери

- важливі / термінові
- неважливі / термінові
- важливі / нетермінові
- неважливі / нетермінові

Потім робимо задачі з цих груп у порядку, описаному вище. Коли все термінове і важливе розгребемо, то усі нові задачі так само додаємо сюди. І завжди намагаємось зробити так, щоб в нас було якомога менше термінових задач. Резервуємо цей квадратик для випадків, коли начальник вривається з криком "шо ви тут розсілись, бігом робіть ось це". Бо насправді більшість задач стають терміновими просто тому що про них забули (або забили)

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

Що думаєте?

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

Зрозуміло, що налаштування та підтримка інфраструктури це окремий скіл, і вимагати, аби одні і ті самі люди і писали код і підтримували оточення – це занадто, проте є і інша сторона. CICD це складова саме розробки. Усі перевірки, які там запускаються, ініціюються і використовуються розробниками. Тому розуміння механізмів, що надає та чи інша платформа (умовних github actions) дозволяє зробити це найбільш ефективно.

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

Так само і потрібна інфраструктура. Можна чекати, поки по твому тікету піднімуть умовний posgtres на EC2, налаштують доступи і ти зможеш робити локальну розробку. А можна підняти усе шо треба в compose і радісно навалювати годняковий код.

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

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

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

Шо думаєте? Де та межа?

https://t.me/cpplastic/354
Прикольний допис про мову програмування, якої я ніколи не чув. Може і вам буде цікаво почитати :)

До речі, робите Advent of Code? Я цього року трохи буксую, але розглядаю можливість пострімити трохи. Типа пізній врив, коли суєта вспокоїться, почати з перших завдань – такий собі слоупок режим.

Перша книжка, яка дала мені розуміння про проблеми (і рішення) розподілених систем була Release It! (можете погуглити, там планер летить на обкладинці). Ось декілька цікавих інсайтів звідти:

- Усі взаємодії з віддаленими сервісами повинні мати таймаут. При чому чим він менший, тим краще. Нескінченний таймаут підвищує ризик того, що у випадку проблем усі потоки вашого сервісу стануть недоступними;

- Насправді краще лімітувати будь-які ресурси, що використовує сервіс;

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

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

- Реалізовувати стратегію disaster recovery набагато краще на етапі проектування і розробки, аніж під час масштабного збою в продакшені. Закладайте захист від збоїв на самих ранніх етапах, проводьте хаос тестування, збирайте метрики.

А ви читали її? Чи може щось інше? Напишіть в коментах.

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

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

Проте я натрапив на пост про те, як цьому сервісу згодували документ, що складався з декількох сторінок, заповненими лише двома словами: Poopoo Peepee (какулі пісюлі). Внизу буде посилання на результат, і я вам скажу, що воно варто того, аби послухати.

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

Критики AI кажуть, що це не інтелект, він не вміє думати. Але ми бачимо, що він чудово вміє як мінімум це імітувати. І робить це так, що доволі важко відрізнити від контенту, що згенерують люди. Тобто, аби робити це, не треба вміти думати.

А може ми насправді так і думаємо? Просто ситуативно на основі контектсу (памʼяті) визначаємо нашу наступну думку токен за токеном?

Звісно, може це все постанова, результат або повністю зроблено, або ж відредаговано людьми, можете самі послухати і скласти свою думку: https://www.youtube.com/watch?v=gfr4BP4V1R8&list=LL

Трохи флекса з минулого. Колись давно, ще в часи windows, MS SQL і Delphi, до мене, як "тижайтішніка" звернулись знайомі з турфірми допомогти з прогою, яку вони собі придбали. Там така собі повнофункціональна CRM з турами, туристами і тд, все прикольно і працює, але була проблема з тим, що паперові документи воно генерувало не такі, як потрібно. Ну знаєте, ваучери, квитки, звіти тощо. А виробник чи то не хотів це міняти, чи було дорого, але як би там не було, вирішили покликати компʼютерного майстра, що живе поряд, тобто мене.

Виявилось, що там стек такий самий, що і в усіх: умовний Delphi / C++ клієнт та MS SQL сервер з базою. Сервак стояв на тому ж компі, шо і клієнт і все чудово працювало. Клієнт звісно не мав ніяких можливостей для розширення (плагінів тощо), але цього і не потрібно було. Оскільки всі дані були в базі, можна було зробити зовніше рішення для друку необхідних документів. Стандартне рішення було б використовувати якусь бібліотеку для репортів, типу CrystalReports (вибачте, якщо у вас тут звело олдскули), але в нього були недоліки. Кожен репорт у разі змін потрібно було б фіксити мені, компілювати, давати нову версію, надсилати її імейлом, а потім ще й траблшутити, чи точно нову версію запустили, чи стару 🙂

Я хотів мінімізувати підтримку і зробити максимально гнучке (і в той же час зручне) рішення. Тому обрав автоматизацію з MS Word. Ідея в тому, щоб зробити шаблон (це документ .dot), в якому буде весь необхідний текст і поля, які замінюються значеннями з бази. І кожен документ представляв із себе звʼязку шаблону з SQL запитом, який мав параметри, міг був дуже складним, дістати будь-що і зконвертити у потрібну форму. Шаблон містив поля, в які підставлялись значення з відповідних полей результату, що повертав запит.

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

Таким чином, використання готових інструментів – Word для роботи з текстом, T-SQL для своєрідних лямбд для кастомної логіки без компіляції і Delphi, щоб дати цьому всьому гарненький сучасний для тих часів UI – допомогло реалізувати елегантне прагматичне рішення, яке тішить мене до сих пір. Ось такі технології нульових.

Розказуйте, чи було у вас щось схоже 🙂

#реклама від партнерів. Розробити гру на курсах про патерни проектування звучить як мінімум цікаво :)

⚙️ Патерни проєктування — це не код і не мова, і навіть не алгоритми, але ідея розв’язання певних завдань.

Навчитися рефакторити код та швидко опанувати 30+ патернів проєктування ви зможете на курсі «Чистий код та патерни проєктування» від robot_dreams.

За 21 заняття ви:
🦾 навчитеся бачити недоліки коду та виправляти їх
🦾 познайомитеся з архітектурою складних enterprise-level систем
🦾 розберете всі патерни та познайомитесь з антипатернами
🦾 дізнаєтеся як організовувати асинхронний код

У фіналі курсу розробите гру з використанням вивчених патернів проєктування і додасте цей кейс у портфоліо.

Лектор:

Олег Фокін — Lead Software Engineer у GlobalLogic, що має понад 20 років досвіду в розробці програмного забезпечення.

Деталі, програма та реєстрація ⬅️

🎁 До 30 листопада у robot_dreams діє акція до «Чорної пятниці» — придбайте будь-який курс і обирайте ще один у подарунок

По коментам до останнього посту трохи здалось, що люди сприймають написане у чорно білому спектрі. Тобто або фреймворщик, що нічого не тямить у алгоритмах і струкутрах даних, або CS graduate, що програмує лише на leetcode. Але насправді моя теза були іншою. Спробую більше розкрити її у цьому пості — побачимо шо з цього вийде 🙂

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

Якщо треба зробити сайт, не потрібно писати свій рушій для цього, проксі, кеш або сторедж. Для високодоступного сервісу вже є готові рішення для оркестрації, моніторингу живучості, масштабування тощо. Коли бізнесу потрібно запустити свій магазин, навряд чи він хоче, аби розробники витрачали його кошти на написання чергового ecomerce клону. Коли додавання товарів у кошик робиться двома командами три спринти, а в кінці все одно є баги. Just get the job done.

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

Або якщо вже все працює, гроші є, і видно, що можна десь щось оптимізувати. Тоді можна написати свій envoy, як це зробили в lyft, або kafka (вона здається з Linkedin, я не гуглив, виправте в коментах якщо ні.) І ці рішення будуть флагманами і можуть зробити вас відомими. Але навряд чи це стосується 90% людей, які це читають. Нам треба просто ефективно витрачати кошти наших клієнтів, а не флексити під "not invented here" синдромом.

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

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

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

Не треба городити свої планувальники задач, бо інфраструктура дає можливість запланувати будь-що, давай свій код і розклад у форматі CRON і йди пити пиво.

Не потрібно думати за алгоритми консенсусів, split brain, транзакційності тощо, бо є готові рішення, які можна додати, як залежності і просто використовувати.

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

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

Що думаєте?

Розширення, яке дозволяє зберігати sqlite базу в полі таблиці postgres.

Саме той випадок, коли ми не питаємо "нащо", ми питаємо "як".

https://github.com/frectonz/pglite-fusion

Netflix на вихідних упав, Envoy був незадоволений, а я згадав про service mesh. Що це таке?

Service mesh — це підхід (патерн? парадигма?), який вирішує питання безпеки, спостережуваності та надійності в Kubernetes-кластерах. І головне — розробникам не треба нічого спеціального дописувати в код. Усе працює на рівні інфраструктури. Типовий Kubernetes-стиль. 😊

Як це працює?

У кожен pod (мінімальна одиниця деплойменту, яка може складатися з одного чи більше контейнерів) додається sidecar — проксі-контейнер. Через нього проходять усі вхідні та вихідні запити. Найвідоміший приклад — Istio, який використовує Envoy як sidecar.

Ці sidecars автоматично додаються під час створення pod’ів і об’єднуються в мережу, що контролює увесь трафік. Завдяки цьому реалізуються такі можливості:

🔐 Безпека: автоматичне шифрування трафіку між pod’ами через mutual TLS (mTLS).

📊 Спостережуваність: на ingress додаються W3C Trace-Context заголовки, які прокидаються далі через усі виклики. Траси записуються, наприклад, у Jaeger, даючи вам карту всіх запитів. Правда, треба трохи допрацювати код, щоб передавати ці заголовки в інших викликах.

⚙️ Надійність: такі патерни, як повтори або “запобіжники”, налаштовуються на рівні Kubernetes-маніфестів. Просто задайте таймаути, кількість повторів тощо — і вони почнуть діяти.

🚦 Контроль трафіку: можна налаштовувати canary-розгортання, A/B-тести, розподіл трафіку за версіями або навіть за вмістом заголовків.

Недоліки?
• Покриває лише синхронну взаємодію.
• Споживає додаткові ресурси та знижує продуктивність.
• Іноді може “падати” — чи то через конфігурації, чи то з інших причин (девопси кажуть, буває).

Чи популярно?
Service mesh — це цікаво, але в продакшені я бачив це не дуже часто. Хоча для великих систем із синхронною взаємодією — штука корисна.

А у вас є досвід із service mesh? Поділіться думками! 👇

А чи задумувались ви, чому в GitHub зміни називаються “pull request”, а не “merge request”?

Якщо ви працюєте з GitHub, то напевно створювали pull request (PR), щоб запропонувати свої зміни в репозиторій. На перший погляд, логічніше було б назвати цю дію merge request — адже мета PR полягає саме в злитті змін. Однак у назві криється більше, ніж здається.

GitHub побудований на системі контролю версій Git, і тут криється ключ до розуміння. У Git команда pull означає витягнення змін з віддаленого репозиторію у локальний. Аналогічно, pull request відображає запит: “Витягни мої зміни з моєї гілки та додай їх у основну”. Тобто автор PR запрошує власника репозиторію “запулити” (pull) його код.

Історично GitHub запровадив цей термін, щоб залишитися ближчим до термінології Git. Це допомогло розробникам легше зрозуміти концепцію PR і співвіднести її з добре знайомими командами git pull та git merge.

Інші платформи, наприклад GitLab, використовують термін merge request (MR). Це звучить інтуїтивніше: адже кінцева мета — злити зміни. Але MR ставить акцент на фінальній дії, тоді як PR фокусується на процесі: обговоренні, перевірці та перевірці змін перед їх інтеграцією.

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

Отже, навіть якщо “merge request” може здатися зрозумілішим для новачків, “pull request” — це відображення спадщини Git і духу відкритого обговорення, що стоїть за кожним внеском у репозиторій.

І ще трохи про трасування. Воно непогано працює в синхронних сценаріях типу "запит - відповідь". Клієнт робить запит на сервер, той шось відповідає, ми бачимо все в трасі. Це показують на демах, усі раді і хочуть швиденько впровадити у себе.

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

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

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

Технічно це все можливо зробити, бо той же самий W3C Trace-Context це просто набір ключів та значень, і їх можна передавати у метаданих повідомлень. Проте проблема саме у питання "що саме я хочу трасувати і нащо". І зазвичай знаходяться інші, більше прості і зрозумілі рішення для таких питань.

І наостанок додам, що існують продукти під назвою APM системи (Application Performance Monitoring). Хоча цей акронім насправді не означає певний продукт, а скоріше це процес. Проте також він вживається для продуктів, які інтегрують логи, метрики і трасування "все в одному". Той же самий DataDog, або Elastic Observability (що раніше називався Elastic APM).

Про них треба знати те, що
- вони існують
- вони коштують грошей (зазвичай багато)
- вони дуже зручні в користуванні
- їм є заміна, або open source self hosted, або вбудовані рішення вашого хмарного провайдера.

Мем вихідного дня, який нагадав що я колись планував написати пост чи серію про service mesh.

В минулому пості перелічили чесноти трасування, але чому ж воно так мало застосовується? Напишу свій досвід як використання, так і спостережень.

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

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

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

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

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

Ну і остання причина, що воно насправді не таке вже і критичне. Здебільшого трасування потрібно для визначення критичних затримок. Але їх можна діагностувати і іншими механізмами, які простіше впровадити. Це і кастомні (або вбудовані, шо ще краще) метрики, або ж прості лог записи з часом, які потім можна пошукати в кібані.

Поки писав, згадав про ще одну проблему і таку штуку, як APM. Але в цей пост вже не влізе, давайте вже в наступному.

Останній з трьох стовпів спостережуванності (а перші два це логування і метрики) — це трасування. Насправді розподілене трасування, і розглядається воно в контексті розподілених систем.

В розподілених системах операції, запити чи команди, зазвичай проходять через декілька сервісів. Серед тих сервісів є як ваші, так і сторонні. І у випадку проблем дуже хочеться дізнатись, хто ж з них виявився слабкою ланкою і всіх підвів. Це звісно можна подивитись в логах, проте далі починається пошук винних серед попередників. Може це вони налажали і неправильно оформили запит?

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

Ідея в тому, що у вхідній точці обробки запиту формується його айді, яке потім прокидується в інші запити. Інші запити прокидують його далі, і додають в контекст свою інформацію. Це все пишеться у спеціальний сервіс, який потім агрегує дані і показує у вигляді гарненьких waterfall діаграм (ви могли їх бачити в dev tools браузерів). І там видно, хто кого і коли викликав, і як довго ці виклики тривали.

Наприклад, сервіс yoba зробив запис в postres за 10ms, а потім відправив повідомлення сервісу foobar, який успішно впав

Знову таки, зазвичай колгоспити нема потреби, є готові рішення і стандарти. Уся необхідна інформація для трасування описується в стандарті W3C Trace-Context. Є сервіси що збирають і агрегують цю інформацію (каноном серед них є Jaeger). Платні рішення теж це підтримують, як і клауди, де воно вдудовано в їх системи спостережуваності.

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

Пишіть ваш досвід і шо ви про це взагалі думаєте у коментах. Дизлайки не ставте (хіба шо по приколу, але тоді напишіть про це в коменті).

Зробив відео про те, як на дешеві китайські приставки поставити лінукс і обʼєднати їх у кубернетес кластер. Дешево і сердито, але прикольно і працює.

Відео знімав і монтував тиждень (а може і більше). Це виявилось складнувато, але мені сподобалось і далі буде ще.

https://youtu.be/R8VLUCvIIro

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

А сьогодні от попалось це, і я не зміг втриматись.

Продовження про метрики, або пара цікавих фактів.

Як метрики збираються? Зазвичай практикується pull модель. Це коли сервіс не передає кудись (в prometheus) свої метрики, а натомість виставляє їх по HTTP у текстовому вигляді. Тобто буквально є сторінка, зазвичай /metrics, де перераховані усі метрики і їх значення. А prometheus опитує (по науковому кажуть "скрейпить") ці сервіси з якоюсь періодичністю. Тому в конфігурації прописуються усі такі місця, куди йому треба дивитись. Звісно, є виключення і push модель, коли сервіси передають самі свої значення у prometheus, але вони доволі рідкісні.

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

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

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

<якась дата> cpu_usage{cpu="cpu0", exported_instance="lupa", exported_job="truenas", instance="graphite-exporter:9108", job="graphite", kind="system"} = 4.040404

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

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

В prometheus є своя мова для запитів, називається PromQL і вона доволі гнучка і місцями складна. Опанувати її – ціла наука.

Перед тим, як робити свої запити варто познайомитись з PromQL, типами метрик і зрозуміти концепт. Бо, наприклад, кількість запитів збирається у типу даних counter, який постійно збільшується, і якщо ви хочете показати кількість запитів в секунду, то треба використовувати комбінацію функцій rate() і sum(). Причому у правильному порядку, бо інакше дані будуть неправильні. А ви цього і не помітите.

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

#реклама last call на курс про високонавантажені системи

⚡️12 листопада у robot_dreams стартує курс «Архітектура високих навантажень» з Олегом Муравським, Principal Data Architect в eBay, який має 20+ років досвіду розробки ПЗ.

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

У програмі курсу — 16 занять, 11 домашніх завдань, та курсовий проєкт.

Після курсу ви:
✔️ вільно розроблятимете високонавантажені системи
✔️ обиратимете відповідне архітектурне рішення залежно від вимог до продукту
✔️ навчитеся адаптувати технології до конкретних вимог і завдань бізнесу
✔️ створите власну систему, здатну витримати щоденний трафік в ≥ 1 млн користувачів та масштабуватися

Детальна програма та реєстрація 🔗

Продовження серії про спостережуваність, і цього разу поговоримо про метрики.

Метрики – це усілякі числові показники, що змінюються з часом, які можна збирати і аналізувати. Завантаженість процесора, використання памʼяті, кількість або частота запитів – усе це метрики.

Для роботи з метриками вже все придумано до нас. Придумали навіть спеціальний тип баз даних, time series DB, які заточені саме під них.

Стандарт – це prometheus + grafana. Якщо спростити, то перший збирає, друга – показує (насправді і перший може показувати, і друга збирати, але в більшості випадків вони використовуються, як написано вище). У кожного є механізм для сповіщень, alert manager для prometheus і grafana alerting, які можна використовувати для нотифікацій, якщо певні метрики викликають тривогу.

Для більшості випадків достатньо знати ще терміни node exporter (збирає метрики з серверів), cadvisor (збирає метрики з контейнерів) і Service / Pod Monitors, які збирають метрики в кубернетесі.

Базовий набір метрико початківця такий:
- ставимо десь prometheus і графану
- на серваки ставимо node exporters
- в докери ставимо cadvisor в кубернетес сервіс монітори
- гуглимо гарні дашборди і додаємо їх в графану. Це максимально просто, потрібно лише вставити айді дашборди в UI графани і підключити відповідний промітеус.

Усі ці "ставимо" насправді є копіпастою yaml файлів з інтернету і робиться за пару хвилин.

В результаті отримаєте графану з гарними графіками, як на pic related (це скрін з моєї графани, яка запущена на кластері з ТВ приставок – про них на днях вийде відео на ютубі).

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

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

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

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

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

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

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

Розпарсити JSON простіше, ніж паритись з регулярками. Теж правда, проте паритись з ними може і не треба. Більшість форматів вже відома, їх можна нагуглити, і накрайняк ChatGPT підкаже правильний регексп. І знову таки, це одиничні операції, якщо у вас команди мають певний стек, то і в усіх сервісах буде однаковий формат. І не варто забувати про сторонні сервіси, сайдкари, бази, проксі і тд, які не в джейсон форматі. З ними все одно треба шось робити (і дуже рідко коли я бачив, щоб девопси переводили логи кубернетеса в json). З такої позициї вигідніше розглядати усі логи як plain text і будувати свою стратегію на цьому.

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

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

Є такий чудовий термін observability, або ж спостережуваність. Він означає властивість системи, що дозволяє зрозуміти її внутрішній стан на основі зовнішніх даних, які вона генерує. Складається з трьох компонентів: логи, метрики та відстежування (tracing). Цей пост буде про перший з них.

Логи є мабуть найзрозумілішим з цих компонентів. Текстові повідомлення, які пише наш (або чужий код), і по яким можна спробувати зрозуміти, шо відбувалось і що пішло не так. Є купа бібліотек для логування, як і транспортів. Їх можна писати в кафку, базу, на зовнішній сервіс і тд. Моя особиста порада (для бекенд) – триматись якомога ближче до дефолтів, і писати в stdout (в консоль). Чому так? Тому що зазвичай ваші сервіси будуть працювати в середовищі, де є механізми збору логів з stdout, а також усі необхідні перетворення, доповнення і так далі.

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

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

Є адепти структурованих логів, які вимагають, аби усі логи писались в JSON форматі. Бо їх легше оброблювати і можна додавати різні метадані. які потім зручно використовувати для запитів. Наприклад, id користувача, номер замовлення та інше. Я доволі прохолодно відношусь до таких вимог, бо вони, як правило вимагають відходу від дефолтів, налаштування форматерів і додавання зайвого інфраструктурного коду. Для мікросервісів це означатиме нові залежності, які треба підтримувати, якось мігрувати (новий архітектор запропонував змінити структуру джейсона, шо робити з існуючими сервісами) і тд. Суцільний геморой.

В той же самий час я не бачив де б ці структурні речі дійсно зарішали. Бо якщо вам треба знайти логи по номеру замовлення, то можна просто використати повнотекстовий пошук з цим номерам. А робити якийсь репортинг по логам (group by order_id в Kibana) — то ще та дикуха (якщо треба деталі – пишіть в коменти, розкриємо тему).

Ще одна причина, чому не варто очікувати всюди JSON логів (та і взагалі уніфікованого формату), це те, що у міксі ваших сервісів не лише ваші. Різні кафки, трефіки, і інші пострегси теж пишуть свої логи, на які також хочеться подивитись. А підігнати їх під ваш формат – це задача із зірочкою (і з нульовим вихлопом). Тому краще просто вміти агрегувати логи незалежно від формату.

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

Тому просто пишемо в stdout, використовуючи дефолтний логер (або якийсь хіпстерський, який налаштовується одним рядком), а решту розгрібаємо на наступних етапах. Іншими словами – хай девопси паряться.

Шо скажете?

Чим відрізняється докер від кубернетеса? Наче і там і там контейнери, але є ньюанс.

Хтось може сказати, що Docker це і є контейнери, але це не зовсім так. Контейнери існували ще до появи docker, і навіть мають різну реалізацію. В bsd системах вони називаються jails, тобто фраза "10 год тюрми" для поціновувачів BSD систем може нести інший зміст.

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

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

Але шо ж тоді doсker? Це продукт, який зробив використання контейнерів зручним. Тулінг, який включає формат файлів для побудови контейнерів і набір утиліт для керування ними. Також включає compose, який дозволяє описувати набір контейнерів у декларативному форматі, що зручніше за CLI.

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

Це так само не єдине і унікальне рішення. У докера є swarm, який вирішує ту саму проблему. Але кубернетес це саме популярне, і своє знайомство з оркестраторами варто починати саме з ним.

У твітері натрапив на чудовий пост про виклики, що постали перед розробником розподілених систем, переклав його для вас:

Коротше, я вже реально втомився від того, що люди кажуть, ніби моєму додатку для контактів не потрібна повноцінна мікросервісна архітектура. Перейшов з $8 на $48-доларовий сервер, бо, ВИЯВЛЯЄТЬСЯ, що запуск Elasticsearch, MongoDB, Postgres, Redis, Kafka з повним зберіганням подій використовує “забагато пам’яті”. І що вони від мене хочуть? Зберігати номери телефонів в одній таблиці? Як якийсь аматор??

У моїх діаграмах 16 різних сервісів, і так, кожен з них потребує власної бази даних. Клієнт постійно питає, чому збереження контакту запускає 47 фонових задач, але вони просто не розуміють найкращих практик. Постійно отримую OOM, навіть якщо немає жодного користувача, але це очевидно через те, що health checks від сервісмешу генерують забагато подій (кожен ping health треба зберегти в 3 базах даних для узгодженості). Так, додаток зараз крашиться, але це тільки тому, що треба більше RAM. Можливо, доведеться перейти на $96-сервер, щоб впоратися з навантаженням на запис, бо кожна CRUD-операція зберігається як незмінна подія.

Якщо у когось є рішення, які не передбачають видалення мого service mesh або пропонування SQLite, я відкритий до пропозицій. І ні, “спростити” не варіант. Не для того я 6 років вивчав розподілені системи, щоб будувати примітивний легасі моноліт із минулого століття.

.... наступний пост:

Оновлення: клієнт розірвав мій контракт, бо “не зміг розібратися з кодом” і “навіщо нам Kafka для зберігання 5 номерів телефону”. Лузери. В будь-якому випадку мій технічний пост про патерни enterprise-управління контактами на підході.


P.S.: вони також відмовилися дати мені переписати все на Rust. Якщо чесно, я лише уникнув проблем.

#реклама (від себе скажу, що мені завжди було цікаво, звідки беруться замовники. Адже мало написати код, треба, аби за нього хтось заплатив)

Втомилися від низької конверсії лідів у 3-5%? Чи зростає ваш CAC на 55% щороку? А найголовніше — постійні брейншторми з командою не допомагають зрозуміти, як підвищити ефективність продажів і знизити витрати?

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

Реєстрація за посиланням:
https://forms.gle/JJeDvB43gKJiutkHA

Чим цей вебінар корисний для вас:
1) Як збільшити конверсію лідів. Як впровадження системи скорингу лідів може підвищити вашу конверсію до 20-30%? Ми навчимо вас, як персоналізувати комунікацію та оптимізувати процес кваліфікації.

2) Як знизити CAC. Дослідження показують, що середній CAC у B2B бізнесах зріс на 55% за останні 5 років. Ви дізнаєтеся, як аналізувати та оптимізувати канали залучення клієнтів для зниження витрат.

3) Customer retention  це новий Customer acquisition. Втрата навіть 5% клієнтів може знизити прибуток на 25-95%. Ми розкажемо, як збирати зворотний зв'язок і впроваджувати програми лояльності для підвищення retention.

4) Наслідки короткострокових контрактів. Короткострокові контракти призводять до зниження LTV клієнта на 30-50%. Як розробити ціннісно-орієнтований процес продажів?

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

Не пропустіть. Реєстрація за посиланням:
https://forms.gle/JJeDvB43gKJiutkHA

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

На одному з останніх стрімів почав це робити. Як то буває на стрімах нічого нормально не виходило, і лише під кінець я знайшов (насправді згадав) правильний helm чарт і справа пішла, графана залетіла, і на тому все призупинилось.

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

І от я його зробив. Додав на пупу cadvisor і node exporter. Також підняв там окремий prometheus (може і дарма, але най буде). З цього всього отримав метрики по ноді і усім докер контейнерам. На лупі стоїть TrueNAS, він чомусь не вміє в prometheus, а лише в Graphite, тому довелось підняти його на пупі (бо компоуз), після чого налаштував туди експорт. В результаті є метрики по TrueNAS.

Шо ще є? Роутер з OpenWRT. Виявляється і з нього можна зняти метрик, поставив пару пекеджів з експортерами, завів їх на prometheus пупи, звідти в графану.

В результаті купа дашбордів, циферки, графіки – є усе. На цьому треба було б зупинитись, але ніт.

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

Але це може і добре. Бо цього разу можна буде автоматизувати і може зробити з цього контент на ютуб. Вам же цікаво подивитись, як з телеприставки за 2500 грн можна зробити лінукс сервак, а потім зібрати декілька штук у кубер кластер?

Хоча насправді треба робити бекапи...

В мене в планах серія технічних постів про мій проект, але сьогодні черга ось цього.
У твітері один пан написав щось типу "побачив, шо людина, якою я захоплювався, як висококласним технічним спеціалістом, використовує ChatGPT, і це мене засмутило". Мовляв "я думав він крутий, а він у чата питає те, шо я і так знаю". І мене це трохи тригернуло.

Бо для мене чат це лише інструмент. Такий самий, як редактор, чи IDE, чи компʼютер, чи Google в кінці кінців. Пригадався кейс, коли запускався Uber в Лондоні, то це викликало обурення серед водіів таксі. Бо їм потрібно було вчитись півтора року (чи шось таке) і знати напамʼять усі вулиці. А тут якісь позери ставлять апку, вішають телефона на панель тачки і починають робити їхню роботу.

Або колись були ерудити спеціалісти. Які знали різні факти і могли підказати якщо була їхня ласка. Але придумали інтернет, там запустили Google, і все – кожен може отримати необхідну інфу одразу.

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

AI для програміста покращує багато напрямків: дозволяє швидше знайти (чи пригадати) потрібну інформацію, надасть потрібний контекст, чи нагенерить бойлерплейт. Це все прискорює роботу, і дозволяє закривати задачі швидше. А хіба саме не швидкість вирішення проблем (якісного звісно) визначає класс спеціаліста?

Шо думаєте, чи можуть користувачі AI інструментів вважати себе експертами?

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

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

– Графічний UI. Я багато часу провів у текстовому режимі (DOS і побутові компи), відеокарти з графічним прискоренням були чимось надприродним, а ті що були (CGA, EGA, VGA) вимагали надзусиль для простих графічних операцій і були дуже повільними. Тому ідея малювати текст у графічному режимі для мене здавалась доволі амбіційною. Ще й шоб курсор там миготів – ну дурдом.

– Відео по інтернету. Знову таки, через обмеження технологій, прогрес яких відбувався на очах, можливість дивитись відео через інтернет здавалась фантастикою. Бо до того інтернету з дому ми підключались через модем і там було 56кілобіт (!) швидкості. Завжди було трохи сумно від розуміння того, шо усі ці стійки з серверами, проводами, свічами і роутерами потрібні для того, шоб ми дивились рекламу тему в ютубі.

– JVM / CLR. Віртуальна машина, в якій компілюється на ходу код джави чи сішарпа і виконується? Шо за додік це взагалі придумав? Я прийшов зі світу, де програми компілюються, і все одно повільно працюють, тому в них робили асемблерні вставки, і ніяк не міг зрозуміти, як можна так марно тратити ресурси процесора.

– Python. Трохи шкода вбитого часу на пошуки ідеальної мови, коли вона завжди була поруч. Але нічого, так ви хоч зможете посміятись з моїх недолугих спроб програмування на стрімах. Ви ж ходите на мої стріми?

Пишіть те, що вразило вас в коментах

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

Тригернуло серед всього іншого твердження про те, що PATCH неідемпотентний. В моїй голові HTTP verbs матчаться на CRUD, і PATCH / PUT обидва презентують UPDATE, який по своїй природі ідемпотентний. Проте, я поліз читати інтернет і побачив такий от пост від Mozilla, де пояснювалось, чому PATCH все ж не обовʼязково є таким.

Річ в тому, що PATCH оновлює частину ресурсу, в той час як інші частини ресурсу можуть оновлюватись іншими механізмами. В оригинальному пості приводиться приклад, коли PATCH робить автоінкремент. Мені особисто такий сценарій здається дивним і не дуже доречним. Хоча в MDN статті теж йдеться про автоінкремент, проте в іншому контексті.

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

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

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

Але тепер принаймні я буду знати, що такий авторитетний ресурс, як MDN, вважає PATCH неідемпотентним. І ви також.

Задумав додати на сайт google analytics. Наче зробив все за інструкцією, але у консолі не бачу ніяких даних. Спочатку подумав, шо може треба дати йому 100 днів деякий час на роздуплитись.

Проте пройшло півтори доби, а даних все ще немає. Сайт треба запускати в дикий світ, тож вирішив розібратись шо там відбувається. Запускаю dev tools і бачу там uBlock Origin - a browser extension to block requests. А після цього згадую, що користуюсь бразузером Brave, в якому вбудований блокувальник реклами.

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

Але тепер я думаю, шо збрати статистику по відвідуванням сайту стало складніше. Бо мене мабуть цей сайт і не помітив. Тому що і на мобіли в мене браузер від duck duck go, який теж блокує трекери.

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

І до скандально таблоїдних новин. Є такий дядько, Річард Столмен. Він – засновник GNU проекту і взагалі видатний діяч опенсорс двіжу. У нього доволі прикольний сайт, https://www.stallman.org/ – такий собі олдскул. З часом він нагенерував багато різних думок, які місцями доволі контроверсійні.

Нещодавно зʼявився інший сайт, stallman report. В якому анонімні автори занотували усі спірні твердження Столмена, і звинуватили його у різних гріхах. Про це зняв відео Bryan Lunduke, це інший цікавий дядько, який останнім часом викриває різну (переважно лівацьку дічь, як то з GoDot, перегіби з діверсіті в опенсорс спільнотах і тд.). І в тому відео він вказав, шо звісно є за шо критикувати Столмена, і він сам неодноразово це робив, в тому числі і висловлював свою критику персонально самому адресату. Але сайт робить це анонімно, і це дикуха.

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

Деталі у відео: https://lunduke.locals.com/post/6235945/drew-devault-behind-stallman-report-org-hit-piece

От дивлюсь на ютубі відео, де козаки сетаплять серваки. Такий собі хардкор – серваки з початку нульово-десятих, в яких всередині є інший комп, на який можна зайти навіть коли сервер не увімкнений, продіагностувати його і запустити, наприклад. І от чувак його показує і каже "воно коштувало 10 кілобаксів і у якогось small to medium бізнесу уся інфра працювала на такій залізяці". Налаштування займало години, а може і дні, і взагалі було як ремонт, який ніколи не закінчується.

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

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

Таку зміну парадігми називають, pets vs cattle. Pets – це домашні траринки, котики та собачки, кожен з яких це індивідуальність, має імʼя, свою мисочку і тд. Так само і раніше сервери називались іменами із зоряних війн чи матриці, ходили по SSH дивитись логі та накатували апдейти. А cattle – це домашня худоба, стадо овечок чи курки на птахофабриці, які для ідентифікації максимум на шо можуть розраховувати, так це на літеро-числовий ідентифікатор. Так само, як сучасний fleet серваків, додані в ansible роль.

Мені трохи не вистачає тієї ламповості. Може тому, що я особливо її не застав, бо якось не доводилось адмініструвати серваки. А зараз це якось цікаво. Тому маю home lab з пупами і лупами. А у вас є homelab? Розкажіть.

Дивіться, який скарб. Український переклад книжки про історію small talk від активного учасника нашого чатика.
Small Talk це правильний OOP, а не те, шо ми собі всі уявляємо (C++, Java, C# і тд)

Ось пряме посилання, якщо боїтесь чатику

тоді раз книжки не читаєте, може про справжне ООП від Алана Кея прочитаєте?

https://kant2002.github.io/EarlyHistoryOfSmalltalk/

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

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

- гугл забанив і видалив акаунт чувака через те, що той надіслав фото своєї дитини своєму ж лікарю для консультації. Алгоритми побачили в цьому злочин, і все, прощавай усе
- мене колись забанив інстаграм незрозуміло за що. Це був новостворений акаунт, я пробував запустити hello world з їх апі, отримав бан.
- амазон вилучив книжку 1984 в усіх користувачів, що її "придбали", через те, що видавець порушив якісь права. Нічого нікому здається не відшкодовували.
- є випадки, коли книжки в електронній бібліотеці змінюються через різні причини, і не завжди користувачі, які "володіють" ними, можуть цьому завадити.
- історія, коли гугл необачно видалив аккаунт хедж фонду
- різні історії з банами за порушення різних правил steam / інших сервісів з втратою усієї бібліотеки без відшкодування
- бан акаунту у соціальних мережах і інших ютубах, з видаленням вашого наче "власного" контенту

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

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

Шо думаєте?

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

Тому ось що несеться останнім часом

- срач навколо wordpress між його творцем і компанією, що надає послуги з хостингу. Мовляв ті використовують wordpress для наживи, і не платять нічого. Прикол в тому, що наче і не повинні, бо там ліцензія "роби шо хочеш". Але це чомусь не завадило почати хрестовий похід. Доволі цікаво, що той Мет (засновник вордпресу) виглядає додіком, і над ним всі сміються.

- загроза зникення io домену протягом пʼяти років. Нещодавно була новина, що Велика Британія віддала якісь острови іншій державі (про яку я і не чув). А ті острови виявились Indian Ocean islands, територією, що володіє тим самим io доменом. І за процедурою він має зникнути. Там все складно і повільно, і скоріш за все нічого не зміниться. Але все одно цікаво

- демарш Godot. Це – ігровий рушій, доволі популярний і опенсорсний. Скандал виник після того, як у соціальних медіа його представники почали нагоняти політичну повісточку про діверсіті і тд. А коли їм зауважили, шо може краще давайте пофіксимо багі, то дуже агресивно накинулись на усіх незгодних. В результаті перебанили купу людей, включаючи спонсорів. А комьюніті створили форки, самий популярний з яких це Redot.
Іронія в тому, що поки що Redot лише піариться і набирає фоловерів, поки що жодного релізу не було

Розкажіть, які скандали знаєте ви?

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

Коли ми вчимо AWS (це приклад, можна взяти будь-якого іншого провайдера), то дізнаємось про різні IAM політики, ролі, security groups і так далі. Але коли починаємо це використовувати, то не дуже хочемо вдаватись в деталі налаштувань, а просто беремо вже готові, так звані "best practices". Бо нам треба просто налаштувати лямбду, яка буде слухати API Gateway, виконувати логіку і складати результати в DynamoDB.

Звісно, ми знаємо про minimal privilege policy, проте не хочемо вручну колупатись в десятках сутностей і їх параметрах. Ми хочемо просто "зробити все правильно" і піти пити пивко.

Якщо все робиться з GUI, то ці налаштування робляться за нас. Створюються неявні компоненти, відкриваються порти, додаються рули у файрволи.

А у випадку infrastructure as code замість десятків рядків детального опису інфраструктури ми обираємо один – два рядки з AWS CDK Solution Constructs. Це – високорівневі компоненти, що налаштовують взаємодію різних сервісів найбільш правильним чином. Один компонент під капотом створить десятки низькорівневих сутностей і налаштує їх оптимальним чином.

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

У будь-якому випадку, написання низькорівневих конфігурацій не виправдовує витрачений на них час. Звісно, якщо немає готових абстракцій (які зазвичай є, треба лише пошукати).

А якщо їх все ж таки немає, то варто переглянути свій план. Може можна підлаштувати його під те, що вже є готове?

"Знову проблеми на проді, був про це алерт?"
"Мабуть був, але ми його пропустили серед 100+ інших..."
"А чому ніхто не помітив, що цей графік скакнув догори?"
"Хм, він просто внизу, треба скролити графану, шоб його побачити..."

Знайома тема? Це здається абсурдом, але я особисто спостерігав схожі ситуації в декількох компаніях. Там були девопси, SRE, нічні чергування, L1-3 сапорти і тд. Купа дашбордів в графані, на кожній графіки, циферки, різнокольорові тренди. Алерт менеджери, канали в slack, нотифікації – усе це було, його було багато, проте все одно пропускались важливі сповіщення.

Чому так? Саме тому, що усього було забагато. Купа інформації, більшість з якої по суті це шум. Шум, який забивав корисний сигнал.

Що треба натомість? Простота. Дашборд, який має показувати статус системи має бути максимально простим. Ідеально – просто порожній бекграунд, або світлофор. Зелений, якщо все ок, жовтий, якщо щось не ок, червоний, якщо халепа вже настала. Бути на видному місці, щоб усі, чия реакція може допомогти, його бачили. Фізичний світлофор в кімнаті команди, монітори на стінах та інших помітних місцях.

Хтось скаже "і шо з того червоного квадратика? треба ж роздуплити в чому проблема". І це вірно. Тому такий дашборд має давати можливіть drill down в деталі, аби дістати більше подробиць. Ідея в тому, що треба рухатись саме в напрямку "бачу проблему – шукаю деталі", а не "бачу купу деталей – намагаюсь зрозуміти, чи є проблема".

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

Тому так, в данному випадку працює принцип "чим менше, тим краще", або "менше фігур – легше грати". Розкажіть, чи багато булшиту на ваших дашбордах і алертах?

запропонували поділитись анонсом безкоштовної події, а я і не проти
#реклама

24 жовтня ділитимемося практичними порадами щодо сучасних підходів до обробки даних, огляд інструментів та кейсів від провідних експертів у сфері Data Engineering.

Спікери розкажуть про рішення для архітектурних викликів даних у Redshift, уроки з впровадження Data Mesh з Kafka для 50+ команд, реалізацію фреймворку Data as a Product з AWS DataZone, відкриття даних у багатоаккаунтних середовищах AWS, помилки при плануванні архітектури даних та приховані недоліки AWS MWAA та багато іншого.

Що очікувати від нового розділу AWS Notes:

- 6 Tech Notes, де спікери поділяться своїм досвідом побудови та роботи із системами обробки та аналізу даних
- 2 короткі Snap Talks з концентрованими інсайтами про найсвіжіші технології та практики
- Формат: онлайн
- Час: 14:00 - 20:30 (GMT+3)
- Участь безкоштовна

З цієї нагоди ми збираємо разом провідних data експертів та сертифікованих AWS спеціалістів, серед яких: Юлія Шологонь з SoftServe, Тарас Сліпець з Flix, Alex DeBrie (AWS Data Hero), Joel Farvault з AWS, Ростислав Мироненко з Booking.com, Дмитро Сірант з OpsWorks та Максим Войтко з Honeycomb Software.

Для більш детальної інформації та реєстрації відвідайте сайт конференції: https://bit.ly/3YjdrzH

Колись я думав, шо причини проблем з моїм кодом – помилки компілятора. Бо інакше якого фіга мій геніальний код не працює?! Потім дізнався, шо існують космічні промені, які вибивають електрони з чипів памʼяті і це може призвести до зміни даних і, відповідно, спотворення результатів роботи програм. Але це все була фігня порівняно з тим, про що я розкажу нижче.

Виявляється, що процесори можуть просто неправильно рахувати. Ти в нього питаєш "шо ти, голова? скажи-но скільки буде 2+2?" А він такий: "пʼять!". Так, ось так тупо збреше, в стилі ChatGPT.

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

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

Сподіваюсь, я підкинув вам ще один вектор для параної (і обгрунтування, нащо треба більше серверів і чому вони мають бути новішими). Більше деталей і обговорень можна почитати на hacker news: https://news.ycombinator.com/item?id=27378624

Згадав ще один прикол. В мої олімпіадні часи арсенал програмістів був набагато скромніший.

Зі структур даних лише масиви і примітивні типи. Умовний list чи dictionary треба було писати з нуля. Сортувати масив – вручну, вкладені цикли, проміжні змінни і тд. Записати чи прочитати файл? Самопальні буфери, виклики низькорівневого апі і тд – рядків 20-30.

Тому простий сучасний oneliner "накидати в dict слова і їх кількість в тексті, відсортувати і взяти 5 найвживаніших" виглядало, як пара сотень рядків з байтомісівом, циклами з i + 1 та іншими низькорівневими розвагами. Обовʼязково зошит в клітинку, в яких малювали байти і розписували структури даних. "Тут індеси, а тут покажчики, а так будемо конвертувати одне в одне".

Зараз SDK та базові ліби сприймаються як буденність. Так само, як і виразність та потужність (а деколи і незламність – це я про rust) сучасних мов. Коли робиш Advent of Code, то прості brute force рішення пишуться за пару хвилин. Звісно, їх потім треба перероблювати, бо воно зазвичай не працює. Але раніше для того, аби написати просте рішення, потрібно було витратити купу часу. І це було доволі необачною інвестицією, бо часу, що залишався, могло просто б і не вистачити на допрацювання рішення.

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

Очевидно, що waterfall виходить з тих часів. Ітеративні підходи почали зʼявлятись лише тоді, коли технології почали це дозволяти. І зараз набагато ефективніше навалити якогось коду, може не дуже оптимального, негарного, який не сподобається ревьюверам. Але який може просто працювати. Отримати baseline, і вже його поступово покращувати. Швидкі ітерації зі зворотнім звʼязком замість довгого і нудного планування.

Мені подобається працювати саме так. Замість довго думати і планувати в голові, як той код буде працювати – просто написати його, запустити і подивитись, шо з того буде. Замість тримання в голові різних edge cases просто описати їх в тестах. Тести зелені – проблем нема. Є проблема – пишемо тест і робимо, шоб вони знову стали зеленими.

Тому я дуже тішусь прогресу інструментів для розробки, які дають можливіть прискорити ці ітерації. І вважаю, що з появою AI все буде навіть краще. Можливо зʼявляться нові мови, більш високого рівня, ніж ми можемо собі зараз уявити. Так само, як я не уявляв собі в школі, шо замість ручної реалізації сортування можна просто написати list.sort()

Але остання теза – це тема для окремого посту. А цей закінчиться тут. Напишіть, шо думаєте про це все )

Сталось те, чого я давно боявся. Запланований пост опублікувався раніше, ніж я його дописав (це я про попередній пост). В телеграмі доволі стрьомно працювати з чернетками, тому я або пишу в нотатках, а потім вставляю. Або ж планую пост на майбутнє і там редагую. Цього разу воно шось запланувалось на той самий час, коли було створене ))

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

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

Я завжди займав перші місця на області, але на всеукраїнських не вистачало підготовки. Памʼятаю, як одну тупу задачу вирішив простим перебором відповідей до якогось великого числа. Натомість у тестовому датасети були більші числа і вона падала з index out of range. Для перевірки запускали exe, код не дивились, але якщо прога падала, то в результаті отримувала нуль балів.

Задача була така "є exe файл, на вход отримує число, на вихід дає теж число. Зробіть програму, яка робить так само". Бляха, тут просто задача на якесь логічне мислення. В результаті виявилось, що та прога просто повертала кількість цифр в числі, які мають замкнуті кола. типа 18 -> 2, 11 -> 0, 4 -> 1. Як на мене це крінж.

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

А ви приймали участь в олімпіадах?

Хотів написати пост вихідного дня

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

Чергова вразливість у лінуксі. Цього разу в сервісі cups-browsed. CUPS це підсистема для друку у лінуксах (мабуть шось типу диспетчер друку у windows, але це неточно), і це її сервіс, який автоматично знаходить у мережі доступні принтери. Дуже цікаво, що в лінуксі є такий компонент який САМ ломиться в світ ще до того, як користувач це йому дозволить або взагалі помітить.

І в цьому компоненті є вразливість, яка дозволяє remote code execution. Вектор атаки – UDP запит на певний порт (631 якщо цікаво), тобто тупо зовні можна забаранити тачку.

Порада – знести нафіг CUPS / або хочаб цей сервіс чи зафайрволити його.

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

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

Деталі можете почитати в https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/, там багато цікавого.

Якщо ви використовуєте 2FA для захисту своїх акаунтів, і побоюєтесь атаки через SIM клонування чи перевипуск у оператора (назвіть останні 3 номери на які телефонували), то можете не переживати.

Насправді зараз можна отримати повний доступ до номеру, отримувати дзвінки і SMS без цих всіх зайвих рухів. Фактично достатньо лише знати номер жертви і мати доступ до закритої всесвітньої мережі під назвою SS7, якою користуються усі телефонні провайдери світу. А доступ такий можна отримати за якихось декілька тисяч доларів.

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

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

Але шо я вам тут розказую, подивіться самі https://www.youtube.com/watch?v=wVyu7NB7W6Y

стрім в ефірі.
Є на ютубі: https://www.youtube.com/watch?v=tFo31VDn1xs
твітер: https://x.com/i/broadcasts/1nAKEpbNWLYxL
твіч: https://www.twitch.tv/skalinets

Доповнення: в додаток до всього написаного нижче, виявилось, що усі шпалери просто лежать на Google cloud у вільному доступі. В коментах деталі

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

А тут він запустив свою апку для ШПАЛЕР. І отримав купу негативного фідбеку. Забагато реклами, усе дорого, навіть з підпискою бачиш рекламу, і взагалі дуже багато запитів на персональні дані, як для апки зі шпалерами.

Почали зʼявлятись меми і пропозиції для творців продуктів жертв його оглядів зробити натомість огляд на його одоробло. А йому самому замість продуктів робити огляди лише на шпалери.

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

Щодо фідбеку Маркус (так звати ютубера) вже написав, шо будуть оперативно все фіксати, ціну зменшувати, реклами обрізати і тд. Проте здається, що це трохи запізніла реакція, і запуск скоріш за все, невдалий.

Таке ось буває, коли переходиш на іншу сторону, і недопрацьовуєш продуктову частину. Ламати – не будувати, а критикувати – не робити.

Така от мудрість.

🚨 Думаю сьогодні зробити стрімчик. Фінальний (сподіваюсь) випуск 🚀 стартапу за 2 години.

Навалимо стилю, трошки підшаманимо і го ту прод. Усе в прямому ефірі.

Точно буде на твічі. Якщо за день налаштую інші платформи, то і на них теж (ютуб, твітер).

Приходьте о ⏰ 19:30 (приблизно, точний час напишу окремим повідомленням нижче).

#реклама курсу про highload від партнерів

⚙️ Як правильно масштабувати архітектуру, зберігаючи стабільну роботу та продуктивність при пікових навантаженнях?

Досвідом ділиться Олег Муравський, Principal Data Architect в eBay, на курсі Архітектура високих навантажень. Ви опануєте сучасні підходи для роботи з highload-системами та отримаєте фідбек інженера, який 20+ років у розробці ПЗ
⠀
❯ У програмі — best practices роботи з Big Data та огляд інструментів аналітики, обробки потоків даних, моніторингу та логування, які потрібні для розробки високопродуктивних систем

За 16 занять ви:

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

+ створите систему, здатну витримати щоденний трафік в ≥ 1 млн користувачів та масштабуватися

📚 PDF-гайд

Старт: 12 листопада

Детальніше про курс 🔗

Цікава (або жахлива, дивлячись на якій ви стороні) історія про відкрите API індійського стартапа. Стартап дозволяє робити замовлення в ресторанах і кафе (шось типу монобізу) через QR код. А його відкритість полягає у повній відсутності auth.

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

Хочеш усі поточні замовлення у будь-якому ресторані? Ось ендпоінт.

Чи може історію замовлень людини по її номеру телефону? Нема питань.

Статистику по ресторанам? We got you covered.

А може зробити замовлення на іншу людину / столик? Звісно, без проблем.

Ще вчора писали, що апі все ще доступне (я не перевіряв, але інфа взята з інтернету, тому це точно правда). Більше того, незрозуміло, як виправити цю проблему. Адже це breaking change, якщо додадуть auth, то зламаються усі точки доступу. А їх доволі багато.

Стартап по слухам підняв $100M інвестицій. Цікаво, шо з ним буде далі ) Зараз буквально будь-хто в твітері може навалити фейкових запитів, і фактично покласти це все.

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

Оригінальний пост про цю проблему видалено, але веб архів усе памʼятає

https://web.archive.org/web/20240923081639/https://peabee.substack.com/p/whats-inside-the-qr-code-menu-at

#реклама курсу від моїх добрих друзів

🔥Fwdays Academy анонсує практичний курс з мікросервісної архітектури!

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

🕖Коли? 10 жовтня - 21 листопада
👉Реєстрація та деталі: https://bit.ly/4eyEOuB
Кількість місць обмежена.

Після проходження курсу, ви зможете самостійно:
🔸Декомпозувати систему на мікросервіси, відштовхуючись від предметних областей. Ви розглянете DDD і Event Storming.
🔸Вбудовувати мікросервіси в оргструктуру компанії.
🔸Переходити від монолітної системи до мікросервісної.
🔸Застосовувати патерни міжсервісної взаємодії та публікації API.
🔸Впроваджувати патерни тестування та розгортання мікросервісів.

🗣Ментор: Кирило Мельничук, CTO в Uspacy та AlterEGO, 18 років у web-розробці. Керує розробкою в українському стартапі Uspacy, де все побудовано на мікросервісах.

Код для підписників на дісконт в 15%: ma_micro

Отримуйте нові знання з Fwdays Academy!

Вкрав з твітору:

C – це латина. Коріння всіх сучасних мов. Колись цілий всесвіт розмовляв цією мовою.

С++ - це французька. Це як латина але з прикольними правилами. Її використовує світова еліта у вузьких колах.

JavaScript - це англійська. Кожен говорить нею, але більшість носіїв володіє нею погано і навіть не намагається вивчити іншу мову.

Java - це німецька. Вона дуже виразна та занадто складна і змусила мене плакати кілька разів. Пояснювати не буду.

Python - це есперанто. Він був створений бути таким простим, щоб хто завгодно міг його використовувати. Його носіям також не завадить час від часу ходити в душ.

Rust - це російська. Більшість носіїв мають лівацькі погляди та хочуть розповсюдити його по всьому світу.

Ассемблер - це наскальні малюнки. Всі знають про них, але ніхто не вміє їх читати. Робити їх важко.

.NET - це голандська. Як німецька, але виглядає тупо.

PHP - це португальська. Широко використовується, але мало хто її зараз вчить.

Ruby - це ісландська. Унікальна та елегантна з природнім та виразним синтаксисом, але не популярна за межами свого кола.

LISP - це іврит. Простий набір правил який використовував ще Творець Всесвіту.

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

Haskell - це баскська. Стара, елегантна, з малою спільнотою носіїв, не схожа на жодну іншу мову.

OCaml - це українська. Має відносно малу спільноту носіїв. Носії Rust вважають себе старшим братом, проте забувають якою мовою було написано перший інтерпретатор Rust.

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