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

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

Підписатись на RSS
📢 Канал в Telegram @stendap_sogodni
🦣 @stendap_sogodni@shevtsov.me в Федиверсі

Пізніше

13.08.2022

Локалізація статичного сайту Сінтри

✨🔄🇺🇦 Сьогодні займався локалізацією Сінтри. А конкретно, переклав статичну частину. Сайт у нас на Hugo. У Hugo дуже кльова система локалізації.

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

Відкриття дня: Google App Engine автоматично робить геолокацію по IP і надсилає результат в заголовках. Тобто ніякого MaxMind не треба, щоб дізнатись країну користувача. Оскільки ми хостимося у Firebase, то на наші хмарні функції це як раз поширюється.

12.08.2022

Перші враження від ElasticSearch

⏱🗂🔍 Сьогодні розбираюсь з ElasticSearch. Відкриття дня: це не двигун повнотекстового пошуку, як я завжди думав.

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

Ще одна вигідна якість - ElasticSearch індексує нові документи миттєво. Ще її можна використати з AWS Kinesis Firehose - звідти я на неЇ і потрапив. (До речі, з минулого року ElasticSearch звузили ліцензію і тепер у AWS та навіть у Homebrew доступний тільки відкритий форк - OpenSearch.)

Поки ще ретельно не тестував, але обіцяє буди гарною заміною доморощеним засобам на базі Redshift.

11.08.2022

Scalr - хмарний сервіс для Terraform

🏗🤖☁️ Сьогодні переносив наш Terraform до сервісу Scalr. Тепер, замість запусків вручну на своїй машині, Scalr буде зтягувати з Git конфігурацію, (напів-)автоматично її приміняти, та зберігати стан. Спободалось.

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

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

Прикольно, що сам Scalr надає провайдера для Terraform. Тобто для налаштування Scalr не треба блукати веб-інтерфейсом, можна написати конфігурацію. Як завжди, Terraform - ідеальна альтернатива заповненню форм вручну. Колись Terraform відкрив для мене світ хмарної інфраструктури. Бо управління AWS вручну то була сізіфова праця; а Terraform замість того дає описати ресурси на декларативній мові і підтримувати їх в порядку.

10.08.2022

Особливості обробки помилок на мові Golang

🐞🔍😅 Сьогодні довелося багато попрацювати з помилками виконання на мові Go. Go - мова з яскраво вираженою авторською думкою. Отже і обробка помилок в Go зроблена цікавим і авторським чином. Ось декілька фактів про неї:

- Майже кожна нетривіальна функція повертає не тільки результат, а й помилку (мабуть, саме для цього в Go функції можуть повертати декілька значень)
- Очікується, що безпосередньо після виклику кожної такої функції буде перевірка та обробка помилки (хоча можна і проігнорувати - є лінтери, які це забороняють)
- При цьому помилки в Go мінімально типізовані. Зазвичай помилку не треба роздивлятись, а просто час перервати запланований алгоритм. (Звісно, є випадки, в яких можна перевірити, що це саме за помилка, і якось особливо відреагувати.)
- На практиці це призводить до того, що кожний написаний алгоритм враховує всі можливості помилки, а це вельми цінно.
- Є ще один різновид помилки - паніка. За механізмом, паніка є виключенням, як у інших мовах. Але за змістом вона значить, що це програміст накосячив, і вихід тепер один - виправити код. Наприклад, паніку викличе звертання до нульового покажчика. (Легкий спосіб її схопити - ігнорувати помилки.)
- Неперехоплена паніка в будь-якій з паралельних рутин призводить до повного краху програми. Настільки все серйозно.

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

09.08.2022

Програмування в парі

👱‍♂️💻👱‍♂️ Сьогодні я майже цілий день програмував у парі. Колись я вважав парне програмування безглуздим марнуванням часу (а може, ще й оплачуваного клієнтом). Але це буде правдою, тільки якщо припустити, що поодинці два інженери зроблять в два рази більше роботи, ніж удвох. Продуктивність програмістів - дуже абстрактна величина, тому таке твердження легко приймається на віру.

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

В пару сідають, щоб:

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

Кращий код та сильніша команда - гідний привід деколи "помарнувати час".

08.08.2022

Люстра та важливість правильного вибору інструменту

👷🤙🪓 Сьогодні я повісив люстру-вентилятор. Особливого хисту до ремонтних робіт в мене немає, але ж шукати найманця теж не хотілось, а люстра мала бути повішена.

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

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

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

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

Занотую три висновки:

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

Пізніше