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

Виявляється, що процесори можуть просто неправильно рахувати. Ти в нього питаєш "шо ти, голова? скажи-но скільки буде 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. Як на мене це крінж.

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

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

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

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

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

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

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

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

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

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

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

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

думаю сьогодні на стрімі поробити трохи девопса. Спробувати поставити графану на кубернетес кластер, що працює на ТВ приставках. Якщо не вийде, то план Б -- на пупу, докер компоуз. Попіднімати якихось промітіусів.

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

Прийдете на таке? Десь о 19-30 плюс мінус (як завжди)

Ось ще трохи думок про передачу і обробку помилок в HTTP.

Історичний аспект

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

У сучасному світі JSON API (їх дехто називає REST, але це насправді не дуже правильно) клієнтом виступає не стільки браузер (навіть в контексті SPA), скільки кастомний код. А коду насправді пофіг, де знаходиться інфа про помилку. Чи це буде статус код, чи це буде errors. Тим більше, що зазвичай все одно в тіло навалюють додаткову інфу, кастомні коди, повідомлення і тд. І по факту пофігу, куди дивитись – на хедер, чи в тіло
if errors: do_error_shit(). І насправді колупатись з хедерами може бути банально незручно, бо треба їх тягати разом з тілом для перевірки.

Це все я до того, що помилки зі статусом 200 у певних контекстах можуть мати сенс. GraphQL так робить, то чому іншим не можна?

Статистика і метрики

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

Кастомні коди

В одній компанії на фоні генерації метрик один дуже поважний технічний гуру радив робити кастомні HTTP коди, і по ним потім збирати статистику. Типа 487 "У кастомера відпала жопа". Це звісно безглузда ідея, і так робити не треба. Але якщо ти СТО, то що може тобі заборонити? )

Що я пропустив?

Вчора нарешті пройшов сертифікацію AWS Solutions Architect Associate і зараз розкажу вам про це. Мабуть розібʼю на декілька частин, щоб не втратити тікток аудиторію. Як готувався Зі свого досвіду маю сказати, що пройти її лише на досвіді я б не зміг. Незважаючи…

В AWS більше сотні різних сервісів, про багато яких ми і навіть і не чули, і більшістю точно не будемо користуватись. В цьому пості я розкажу про один з таких. Він потрібен, аби здати екзамен на AWS сертифікацію. Коли бачите питання "у вас багато даних, бос хоче перенести їх в AWS і дає на це максимум два тижні, але з вашим інтернетом ви будете закачувати місяць. Шо робить?" І правильна відповідь буде та, де є слова AWS Snowcone або Snowball.

Мова йде про так звану AWS Snow Family, і це по суті девайси, які можна замовити в амазоні, їх доставлять американською новою поштою, ви їх підключите, все запишете, відправите назад, а тоді вже ваші дані заллють на S3 (по шнурочку, лол).

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

Якщо Snowcone це така собі велика флешка з 8Тb HDD і 14Tb SSD, то у Snowball є декілька моделей геть до 210Tb SSD, 104vCPU (ядер) і 416Gb RAM. Це все має клас захисту від зовнішнього середовища і може працювати в екстремальних умовах. Позиціонується не стільки як рішення для переносу даних, а як додатковий сторедж / обчислювальні ресурси в різних не дуже підключених і дружелюбних сценаріях.

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

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

Чи може ви чули, шоб хтось їх юзав? Напишіть.