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

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

Подивився, що пропонують сучасні конструктори. Для мене є два значущих: це Squarespace та Wix. Але хоч я їх поважаю, але жодним не користувався. Ось і тут, Squarespace не підходить за браком української локализації, а Wix мені якось дуже складний та заплутаний. Отже, шукав альтернативи. Знайшов ще Sitepro, який я помітив у партнерці деяких доменних реєстраторів. Але ж не можу знайти в собі довіри до такої платформи.

Нарешті повернувся до того, що знаю, а саме до керованої інсталяції Wordpress. Чому Wordpress:

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

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

⚛️📲🪄 Пам'ятаєте як вчора Apple попросили зробити видалення акаунту? Так от, сьогодні ввечорі зробив може години за дві.

Головним помічником і заставою продуктивності є React Native. Бачите, видалення акаунту у веб-версії вже зроблено, доволі давно. Чи можу я скопіювати цю фічу з React до мобільного додатку? Звісно ж, ні. Компоненти, вигляд, поведінка фундаментально відрізняються.

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

Зазвичай при оцінці React Native недоглядають цю дуже важливу перевагу - наявність спільного шару бізнес логіки.

🔥🔥🔥 Сьогодні замість написання гарного посту займався гасінням пожежі (на щастя, метафоричної.)

Все почалося непогано: Cloudflare вже у продакшені, захищає від атак та кешує статичний контент. Здавалося, що все перебачено і нічого страшного не трапиться. При переході на Cloudflare спочатку переносяться всі DNS-записи, а потім, коли все готово і перевірено, перемикається DNS-провайдер для домену. Для користувача у той момент нібито нічого не змінюється. І це добре, бо насправді зміни у DNS тривають не "момент", а невизначену кількість часу, можливо аж до доби.

Що ж трапилось? Трапилось те, що між Route53 та Cloudflare є одна маленіка різниця у роботі з TXT записами для CNAME доменов. А цей нюанс ламає перевірку DNS записів. А від перевірки записів залежить дієздатність хелс-чеку. А від роботи хелс-чеку залежить, чи буде супервайзер рестартувати сервіси. А коли сервіси свавільно рестартують, ось це ми називаємо метафоричною пожежею. 🔥

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

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

🇺🇦🍾🔑 Сьогодні день приємно продуктивний.

По-перше, з нагоди 🔱 Дня Незалежності, ми випустили в світ повністю українізовану версію ✨Сінтри. Останнє, що довелось зробити - це локалізувати параметри App Store та підписок. Бо і там є рядки, що потребують перекладу - назва та опис додатка, та інше. Локалізація продукта - це набагато ширший процес, ніж просто переклад коду додатка.

Друге - налаштував для стейджингу Cloudflare Access. Це сервіс, яким можна обмежити або захистити доступ до деякого веб-ресурсу. Я вкрай задоволений його гнучкістю.

Раніше ми прикривали стейджинг нашим VPN за допомогою груп безпеки AWS. Це надійно, але незручно. Наприклад, нелегко дати доступ сервісним та тестовим скриптам, або пустити консультантів з-поза меж компанії.

Так от, Cloudflare Access вміє все, що можуть групи безпеки (обмежити доступ по IP), тобто рішення з VPN продовжує працювати. Але до того ж можна: поставити перед сайтом вхід через акаунт Google з певними імейлами чи цілим доменом; дозволити доступ з сервісним токеном; під’єднати тунель від Cloudflare; та багато іншого. Я за один день вирішив всі питання захисту стейджингів, що стояли перед нами роками (бо саморобні рішення вимагали купу часу).

🛡🚤🏎 Дві цікавинки сьогодні. По-перше, Cloudflare - все ж таки дуже корисний сервіс, з безліччю функцій для захисту. Тут і точне керування протоколами шифрування. І статистика по ним. І можливість закрити весь сайт за примусовим логіном (корисно для стейджингу.) І CDN. Очі розбігаються. Радий що спробували, бо у AWS для всього цього треба робити свої рішення.

По-друге, порівняв MacBook Air M1 vs MacHook Air M2 на самому об'єктивному бенчмарку - а саме, тестах нашого проєкта. Тут і Ruby, і PostgreSQL, і інтеграційні тести фронтенду на React у браузері Chrome. Тобто те, що доводиться робити кожного дня.

Отже, результат: M2 виявився швидше за M1 на 8%. Дрібниці насправді, але приємно. (Набагато важливіше +8 GB RAM.)

Окремий результат - жоден ноут не навантажував CPU більш ніж на 25%. Це обумовлено тим, що тести працюють фактично з одним ядром CPU з восьми. Може, двома, якщо врахувати роботу браузера. Висновок перший: насправді веб-розробнику ніякий M1 Pro з 10 ядрами не потрібен. Висновок другий: при звичайній роботі розробника MacBook Air не має підстав нагріватися та гальмувати.

І нарешті, порівнював ігровий тест, а саме, вбудований тест Shadow of the Tomb Raider. Був здивований майже однаковим результатам: на найвищих налаштуваннях та 1280x800 обидва ноута показують 31 FPS, а на 1920x1200 M2 показує 17 FPS супротив 15 у M1. Остаточний висновок: брати модель з 10 GPU великого сенсу немає.

🕸🛡☁️ Сьогодні налагоджував захист сайту через Cloudflare. Перше, що для цього потрібно зробити - це перенести DNS записи до Cloudflare. Наші DNS записи описані у Terraform. Як зазвичай, Cloudflare також підтримується терраформом, так що перенесення звелося до переписування ресурсів з aws_route53_record у cloudflare_record. Кльово, що деякі значення у Cloudflare беруться з ресурсів AWS (наприклад, записи для підтверждення сертифікатів.)

Terraform залишається улюбленим інструментом.

Ще така кумедна історія вийшла: в мене вже пару місяців докер віджирав біля 25% CPU. Я це списував на вроджені вади докера, і нічого не робив. Сьогодні прокрастинував і подивився, що ж таке жре CPU в докері. Виявилось, що це не сам докер, а контейнери з haproxy, а потів виявилось, що у haproxy 2.6.3 є баг з постійним використанням 100% одного CPU. Відкотився до 2.6.2, споживання CPU зникло.

До речі, корисна команда: docker stats

✉️🌍✅ Сьогодні займався локалізацією, доробляв переклади листів. Раніше шаблони листів були у Handlebars (ще раніше просто в Mailgun). Тепер ті самі шаблони обробляються бібліотекою i18next. Так простіше, тим паче нічого більш заміни змінних ми в шаблонах не використовували. Тепер можна і теми листів локалізувати, і форматування дат сховати в шаблон, і консистентність з іншим локалізованим кодом краще.

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

У таких випадках має сенс написати скрипт. Скрипт дуже простий - завантажує ресурси локалізації та перевіряє, що всі переклади задані і немає зайвих. Додав його до лінтерів і таким чином до CI. Тепер можна бути впевненим, що все перекладено вірно.

Скрипти для власного користування - часто зневажена категорія програмування. Чи робиш ти рутинні дії, які міг би за тебе робити скріпт?

📦💻🤩 Сьогодні розпаковував новий макбук Air M2. Про попередню модель я вже писав детально - новий відрізняється не сильно, але в декількох важливих деталях. Якщо в двух словах, то це все ще кращий ноут для веб-девелоперів, беріть - не пошкодуєте.

- "опівнічний" колір виглядає чорним з ледве помітним синім відливом. Скучив за чорним ноутом, так що дуже задоволений.
- тепер нарешті можна взяти 24 ГБ оперативки, щоб влізли всі докери, рубішні програми, редактори на електроні та інше.
- цей Air зроблений в новому дизайні Apple Silicon, тобто нарешті зовнішність співпадає наповненню
- люблю Fn-рядок з клавішами в повну висоту. ще більше люблю Escape нормального поважного розміру.
- щось дивне зробили з динаміками, тепер вони в торці та направлені в екран. ще не розібрався чи краще чи гірше.

Migration Assistant не захотів переносити по шнурку USB-C, а використав peer-to-peer Wi-Fi. До того, не переніс більшу частину папки з проєктами. Могло бути й краще.

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

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

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

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

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

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

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