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

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

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

Раніше

Пізніше

24.09.2022

Підходи до локализації блогу на Hugo

🌐📖🔄 В мене на блозі триває SEO-покаліпсіс: майже всі сторінки випали з індексів, та відвідувачі з пошуковиків практично скінчились. Зробив деякі зміни, щоб виправити, але на жаль пройдуть дні, поки я зможу побачити якийсь результат.

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

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

(До речі, Hugo буде додавати до всіх адрес локалізованих сторінок префікс з кодом мови. Цього неможливо уникнути глобально, але для конкретної сторінки завжди можна задати повний url у front matter - тоді префікс не додається.)

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

Тому натомість просто додав свій, особливий параметр сторінки lang (насправді він давно вже був), і використовую його для локалізації окремих сторінок (наприклад, у тезі <html lang="uk">). Ще бачив поради зробити мову тегом або категорією. В будь-якому разі, тоді Hugo продовжує працювати у звичайному режимі без локалізації.

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

23.09.2022

TLS сертифікати, де їх взяти, та проблеми з ними

🌎🔐💸 Продовжуючи тему проблемних вебтехнологій: TLS. Або ж SSL (чи знаєте ви, що TLS - це нова версія SSL, а SSL абсолютно застарілий та ненадійний та давно його ніхто не підтримує?)

Зараз такий час що всі користуються TLS, а все завдяки поширенню чудової ініціативи Let’s Encrypt. Тепер будь-хто може безплатно отримати сертифікат для сайту. Тепер і більшість хостингів безплатно створять його за вас, включаючи й AWS. Це дуже добре, що всі мають доступ до безпечного інтернету.

Де ж проблеми? Проблеми в тому, що не всюди ці сертифікати приймають. Якщо сертифікат вам потрібен для сайту на HTTPS - то, напевно, обійдетесь Let’s Encrypt. (Чи знаєте ви, що HTTPS - це звичайний HTTP, але комунікація відбувається через канал TLS?) Браузери з ними нормально працюють — і браузерів насправді не так багато.

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

Тому, якщо у вашого проєкту є бюджет хоч на $20 на рік, раджу придбати “справжній” сертифікат і не мати проблем. Справжній — то від серйозного емітента, наприклад, Comodo. Рекомендую купувати на NameCheap, хоч вони мені не платять. До того ж оновляти такий сертифікат доведеться раз на рік, а не на місяць.

22.09.2022

Чому я раджу не тримати свій DNS сервер

🕸️📖👈 Що я вам скажу — не раджу підіймати свій DNS.

Принаймні, не рекурсивний. Річ у тім, що DNS - вкрай езотерична технологія. І хоч ми всі їй користуємося постійно, мабуть, мало хто здогадується, що таке рекурсивний DNS, і який ще буває.

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

Перша — це, грубо кажучи, дерево DNS-серверів, які зберігають адреси сайтів. А саме, є кореневі сервера, що знають адреси DNS-серверів доменів верхнього рівня (.org). Далі у домену .org є свої сервери, які знають адреси DNS-серверів всіх доменів .org - наприклад, .telegram.org. Зазвичай DNS-сервер домену другого рівня скаже вам адресу самого сайту та його піддоменів. Але не завжди — бо глибина дерева технічно не обмежена. (До речі, самі DNS-сервера вказуються у вигляді доменів, а не IP-адрес. Мені це здається зациклюванням, але ж якось воно працює. Таємниця!)

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

Через повільність і ненадійність такої системи DNS існує друга. Це кешуючі DNS сервера, які зберігають результати запитів та віддають їх моментально. Часто вони теж не роблять рекурсивний пошук, а питають в інших. Так робить DNS-сервер на вашому пристрої (бо звісно, є й такий!), на роутері, у провайдера.

А є ще публічні кешуючі DNS сервери, наприклад, 1.1.1.1 від Cloudflare. Їх користь в тому, що вони працюють “нормально”. Бо протокол DNS складний і неоднозначний, і в деяких історичних ситуаціях “нормальні” сервери роблять не так, як написано. (Принаймні, це я так розумію.)

Ми спробували підіймати рекурсивний DNS сервер Unbound. Він дуже класний, але він жорстко слідкує за стандартом, а це “ненормально”, тобто інколи результати не збігаються з очікуваннями, і пояснити, чому, нелегко. Після численних проблем повернулись до DNS від Cloudflare.

Якщо хочеться почитати про DNS більше, раджу чудовий блог Джулії Еванс.

21.09.2022

Моя боротьба з пошуковою оптимізацію та поради

🔎🧰🔥 Сьогодні боровся з пошуковою оптимізацією.

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

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

Отже, раджу зареєструватись у Google Webmaster Tools, а також в Bing Webmaster Tools, і подивитись, що вони кажуть. Лайфхак: підтверджені сайти з Google можна в один клац імпортувати до Bing. Тобто не треба два рази підтверджувати власність.

І не зволікайте на те, що Bing не такий крутий, як Google. Бо саме в індекс Bing дивиться DuckDuckGo, а ось DDG досить популярна альтернатива Google. Та й сам Bing у багатьох користувачів Windows стоїть за замовчуванням.

Що я сьогодні встиг зробити, це додати до всіх сторінок meta description. Бо Bing їх дуже хоче. А також виправити внутрішні посилання, що вели на сторінки без кінцевого слешу. Бо як виявляється, Google не може з цим змиритися, навіть якщо посилання насправді працюють через перенаправлення. А ще додати до сторінок тег link rel=canonical, що допомагає пошукачам зрозуміти, яку саме сторінку показувати — це теж корисно у ситуації з перенаправленнями.

До речі, для вебаналітики я вже більше як рік користуюсь Plausible. Це платний сервіс, який свідомо не будує ніякого “портрету користувача”, а спирається тільки на анонімну статистику.

20.09.2022

Прибирання диску автоматичними засобами - Hazel та інше

📁🧹🗑️ Як впоратись з програмами, які невпинно створюють на диску всякий брухт? Як приклад: XCode накопичує архіви з кожної збірки, а також файли підтримки для кожної нової версії iOS.

Для автоматичного управління файлами для macOS існує додаток Hazel. Він вміє не тільки видаляти файли, але й впорядковувати за різними схемами. Ідея така: Hazel слідкує за директоріями. Задаєш шлях до директорій та правила вибору та обробки файлів; якщо є такий файл — то зробити таку дію. Наприклад, можна слідкувати за директорією з архівами XCode та видаляти все, що старіше за місяць.

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

Що Hazel погано вміє робити, це слідкувати за глибоким деревом директорій. Технічно така можливість є — через правило recurse into directories - але воно дуже неефективне.

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

А ще щоб знайти, куди ділось місце, багато років використовую DaisyDisk. Можу і для Windows порадити - TreeSize.

19.09.2022

Пара порад про налаштування GitHub Actions

😸🔐⚙️ Пара порад про налаштування GitHub Actions.

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

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

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

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

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

18.09.2022

Чому демократія в команді - це круто

🗳️👍👎 Сьогодні пару слів про демократію в нашій команді.

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

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

Інший — спиратися на дані. Збираємо всі “за” і “проти”, зважуємо, підраховуємо, і маємо науковий результат. Нібито так все буде чесно. Але ж ні. Якби було очевидне обґрунтування, питання не стало б політичним в першу чергу. А так, збір аргументів перетворюється на конфлікт волі — більше збере той, хто більше прагне перемоги. І це, на мою думку, псує весь “логічно обґрунтований” підхід.

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

Чому це круто:

17.09.2022

Одночасна публікація постів в блог і в Telegram

🗞️🔄📢 Нарешті добив сьогодні одночасну публікацію в блог і в Телеграм.

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

Складнощі створило те, що у Telegram Bot API немає способу завантажити історію постів. Отакої. Є ще клієнтський API, який, напевно, зможе це зробити (бо клієнти історію показують.) Проте, щоб не звʼязуватись з ще одним API, знайшов спосіб експортувати історію вручну. Така можливість існує в так званому Telegram Desktop (не плутати з Telegram for Mac, яким я зазвичай користуюсь.) Експорт можна зробити у JSON формат (додатково прикладаються світлини та відео.) Потім цей JSON експорт перетворюю на пости для Hugo. Цікаво, що форматований текст, замість Markdown чи HTML, експортується у вигляді структури AST, з якої досить просто збудувати HTML (чому не Markdown? тому, що у HTML простіше екранувати спеціальні символи.)

Далі, коли всі пости вже готові, залишилось налаштувати шаблони на сайті — в Hugo таке називається content section.

Поки шаблони дуже прості, буду ще розвивати. Але розділ на сайті вже працює: https://leonid.shevtsov.me/stendap/.

16.09.2022

Публікування світлин до Telegram за допомогою боту

🏞️🌄🌆 Що ж, розібрався сьогодні з публікуванням світлин до Телеграму.

З боку бота все досить просто: замість sendMessage є метод sendPhoto. До нього можна навіть додати опис, в тому числі форматований. Але замість 4096 символів посту, опис може мати не більше 1024. До того ж пости зі світлинами мають вузький вигляд. Тому я вже раніше вирішив світлини відправляти окремо.

Але що з боку блогу? В блозі світлина до посту має бути разом з постом, звісно. Спочатку я розглядав ідею додавати фото розміткою в тексті поста, і витягувати при розборі. Але це складно. Тоді згадав по таку функцію Hugo, як ресурси сторінки: це відносно новий спосіб єднати пости та їхні ілюстрації в одній директорії. Після цього можна у метаданих (frontmatter) до посту доповнити ілюстрацію описом.

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

До речі, нещодавно запустив ще один проєкт — викладаю власні пейзажі України до фотобази Unsplash. Давно збирався публікувати якісь світлини, але не вистачало бачення. Зараз знайшов тему — це дуже допомагає. Ласкаво прошу!

15.09.2022

Форматування текста для публікації в Telegram через бота

🚧🤖📢 Просуваюсь потрохи з телеграм-ботом. Переробив відправлення в формат HTML, тому що Markdown все ж таки вельми плющений. Щоб публікувати нормальний Markdown в Telegram, треба спочатку розібрати та зібрати наново з екрануванням всіх спеціальних символів.

З HTML набагато простіше — екранування потрібне тільки таке як завжди. Тут нюанс інший — в тексті мають бути тільки теги, що Telegram підтримує — це ті, що уможливлюють засоби форматування. Навіть тег <p> ставити не можна.

Я міг би писати пости прямо в HTML, але, по-перше, яка в тому радість, а по-друге, не вийде той самий пост покласти в блог — хоча б через відсутність параграфів. Тому знайшов спосіб зі звичайного Markdown робити такий HTML, щоб Телеграму подобалось.

Для цього узяв Markdown-парсер Goldmark, який використовується в Hugo. Та написав для нього особливий рендерер. Він не тільки параграфів не робить, а й конвертує списки назад у дефіси, і зберігає вірні перенесення строк.

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

Раніше

Пізніше