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

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

19.08.2022

Сон, їжа, тренування - простий фудамент самопочуття

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

- Сон - хоча б сім, а краще вісім годин в день. Недостача сна буквально робить нас дурніше, показують дослідження. І це, мабуть, головне, що треба виправляти більшості айтівців.
- Їжа - здорове і регулярне харчування. Якщо неясно, з чого почати, раджу почитати про середземноморсью дієту. Не забуваєм і про українські суперфуди - борщ та гречку. (Серйозно, греча вважається нарівні з модними кіноа та амарантом.)
- Моціон - байдуже що, але головне щоб регулярно. Хоча б прогулянки на свіжому повітрі. Але краще щось, що задіє все тіло. Якщо душа до спорту не лежить, є 7-хвилинні тренування.

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

18.08.2022

Дебаг, AWS Kinesis Firehose, sidekiq-unique-jobs

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

Окрім хелс-чеків, у складній системі перетворень важливо пам'ятати, де слаба ланка.

Технологія, яка не підводить: AWS Kinesis Firehose. Це такий безрозмірний приймач повідомлень, які він батчить та складає в базу. Зручно для ситуації, коли потрібне бути впевненим в масштабуванні. Колись на проєкті мільярди повідомлень в день збирали, і Firehose цілком спокійно їх обробляв. Ще Firehose добре порається з помилками на боці бази, а саме вміє спробувати завантаження декілька разів, та в разі остаточної невдачі складає помилкові записи на S3. Та й моніторінг у нього зручний і прозорий. Дуже класна технологія і недорога - близько $0.03 за ГБ даних.

Технологія, яка підвела вже не раз: гем sidekiq-unique-jobs. Він запобігає подвійному запуску завдання за допомогою запираючих записів у Redis. Але, в разі катастрофічного виходу ці записи можуть залишитись назавжди, і наступного разу завдання ніколи не запуститься. А якщо не налаштувати правильно вихід sidekiq при зупинці сервісу, то катастрофічним буде кожний вихід. Через це ми пройшли минулого разу коли це трапилось. Цього разу ще додав Time-To-Live. Раджу без Time-To-Live для лок-записів навіть не починати з цим гемом.

17.08.2022

Маленька гра на React Native

📱🎮⏱ Сьогодні несподівано для себе зробив маленьку, але справжню мобільну гру, і навіть встиг завантажити до Test Flight. Ну тобто не всю гру, а "вертикальний зріз". Але, як кажуть, лиха біда - початок.

Я давно це обіцяв синові, бо ідея його, та й оформлення буде теж його. З мене - програмування.

Почати було важко. Новий проєкт - купа питань. На чому писати. (До речі, гра має вийти в iOS/Play Store/Steam, тож щось кросплатформенне.) Як все облаштувати. І таке інше. Свято прокрастинації та гоління яків.

Але сьогодні все ж таки взяв найзнайоміший інструмент та почав. На React Native. І от, на створення проєкту та перші прототипи уйшло десь півгодини. У сучасного React Native гарний шаблон додатка, до того ж є версія на TypeScript. Ще півгодини на публікацію в TestFlight (акаунт в мене вже був.) Тепер є шанс, що гра все ж таки побачить світ.

Моралі дві:

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

16.08.2022

Що вміє ElasticSearch

🗄🗄🗄 Сьогодні продовжую розбиратися з ElasticSearch, тобто насправді з OpenSearch.

Завантажив датасет на 5 ГБ. Для цього є операція _bulk, в яку влазить невідомо скільки записів за раз. Сто тисяч точно влазить, а більше соромно було спробувати. Звісно, записи відправляються в форматі рядків JSON, тобто якщо ви відвантажили JSON з іншої бази, то його можна без перетворень залити в OpenSearch. Тільки й різниці, що перед кожним рядком треба додати рядок з командою _create. П'ять гігабайтів база забрала десь за 8 хвилин - це з негайною індексацією. Відзначу, що непогано працює система типів - mappings (а саме, значення типу "дата" або "IP адреса" проходять перевірку).

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

Але ж так само з Redis, Mongo, CouchDB або будь-якою новітньою базою даних. У кожної є деякі переваги над SQL базами. Як правило це набагато краще продуктивність у деяких специфічних сценаріях. І кожну з них треба знати, коли і як використати. Натомість SQL бази можуть "все", але ж в продуктивності програють.

15.08.2022

Переклав українською мовою сервіс Miniflux, та як це робити

🇺🇦📲❤️ Сьогодні, на хвилі локалізації, переклав українською мовою RSS-читач miniflux.

Miniflux - це RSS-читач, написаний на Go, з самостійним розміщенням (в мене - на fly.io.) Люблю його за простоту та за надійність. З необхідних мені фіч, він вміє організувати стрічки в категорії та підтримує Google Reader API (що й досі є де-факто стандартним API для читачів RSS.)

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

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

- або знаходиш iOS/macOS додаток, який має підтримку декількох мов (це повідомляється на сторінці додадка у App Store), та пропонуєш творцям додати переклад. Далі, скоріш за все, перекладаєш такий самий словник.

А ще з цього вийшов би добрий хакатон.

14.08.2022

Чарівна синхронизація Firebase

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

На скріншоті показано наш сайт та мобільний додаток. Вони ніяк між собою не пов'язані, окрім як через хмарну базу даних Firebase Firestore. І як ви бачите, при перемиканні мови на сайті, мова в додатку перемикається миттєво! Так працює не тільки локалізація, а й будь-які ваші дії. Це найкрутіший рівень синхронізації який я взагалі бачив. Особливо приємно, що Firestore так працює "сама", ми жодних зусиль до цього не прикладали. Все, що треба було зробити - це підключити клієнт та підписатись на оновлення документів. Ну та й звісно, використовувати React / Redux.

До речі, детальніше про нашу архітектуру я писав у статті.

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 мінімально типізовані. Зазвичай помилку не треба роздивлятись, а просто час перервати запланований алгоритм. (Звісно, є випадки, в яких можна перевірити, що це саме за помилка, і якось особливо відреагувати.)
- На практиці це призводить до того, що кожний написаний алгоритм враховує всі можливості помилки, а це вельми цінно.
- Є ще один різновид помилки - паніка. За механізмом, паніка є виключенням, як у інших мовах. Але за змістом вона значить, що це програміст накосячив, і вихід тепер один - виправити код. Наприклад, паніку викличе звертання до нульового покажчика. (Легкий спосіб її схопити - ігнорувати помилки.)
- Неперехоплена паніка в будь-якій з паралельних рутин призводить до повного краху програми. Настільки все серйозно.

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

Раніше

Пізніше