Стендап Сьогодні
Що я зробив, що я хочу зробити, і що це все значить.
Повсякденні здобутки в форматі стендапу.
Детальніше в статті
Підписатись на RSS
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
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. Та написав для нього особливий рендерер. Він не тільки параграфів не робить, а й конвертує списки назад у дефіси, і зберігає вірні перенесення строк.
Намальовується непоганий опен-сорс — але до того ще потрібно навчитися працювати з картинками, а також все ж доробити кросс-постинг в блог.
14.09.2022
Мій досвід з Clojure
🧙☕🏕️ Сьогодні якось згадалась між словом мова Clojure, яку я обожнюю, хоч не використовую.
У мене цікава ситуація з Clojure - з одного боку, вона мені подобається як естетично, так і функціонально. Але з іншого боку, для будь-якої задачі знаходиться мова краща. Так що я на Clojure нічого не пишу — хоча залишилась пара живих проєктів, такі як дисплей погоди.
А проте, досвід, набутий з Clojure, залишився зі мною на довгі роки. Тому, на мою думку, цю мову корисно випробувати кожному інженеру.
- Clojure - функціональна мова програмування. З мого досвіду, як не найпростіша для освоєння новачком. Тут я тільки скажу, що з функціонального програмування виріс React. ФП навчить вас краще розуміти потоки даних у вашому коді.
- Clojure- це лісп. І, мабуть, знов найдоступніший. Лісп навчить вас писати чудові DSL, бо в цій мові можливості розширення на порядок кращі, ніж в будь-якій “нормальній” мові.
- Clojure можна використовувати як з Java, так і з JavaScript, для написання фронтенду. Фреймворк re-frame надихнув бібліотеку reselect, між іншим.
- Творець Clojure - Річ Хікі — винахідник терміну “програмування в гамаці” та інших філософських роздумів. Як цінитель гамаків, не можу його не підтримувати.
Якщо хочеться глянути на 50 рядків красивого коду на Clojure, пропоную мою імплементацію OAuth.
13.09.2022
Чому мені не подобається модель REST
🎂👮🍱 Сьогодні день програміста. Вітаю з 0х100!
Поскаржуся трохи на REST, як систему організації HTTP API.
Спочатку про хороше: більшість того, що ми робимо через API - це саме створення, перегляд, редагування та видалення ресурсів. Ці дії чудово вписуються в ментальну модель REST, і дуже добре, що є конвенція, яку всі знають і не треба кожного разу щось складати своє.
Тепер про погане: як і будь-яка система, модель REST не описує всі операції. Наприклад:
- операції над групами (
bulk_import
якихось товарів) - усілякі додаткові операції над ресурсами, особливо незворотні (
publish
якогось поста) - процедури, які не створюють ресурсів (який-небудь
track
для аналітики)
Оскільки у Ruby on Rails дуже зручно створювати API для ресурсів, то є тенденція натягувати на REST абсолютно все, до фанатизму. Так виходять ресурси на кшталт bulk_imports
або, ще гірше, publishs
- тобто з дієслова штучно робиться іменник. А ще HTTP-методи окрім GET та POST не повністю підтримуються браузерами — спробуйте зробити DELETE через форму.
Я розумію, що інженери люблять розкладати речі за акуратними коробочками, і якщо щось не влазить, то це рушить всю систему. Але на мою думку, щоб ефективно користуватись будь-якою моделлю, треба розуміти її обмеження, і не боятись виходити за них, якщо цього вимагає здоровий глузд.
REST - для явних ресурсів. Для всього іншого - POST по шляху з назвою дії.
12.09.2022
AppleScript для зберігання вкладок у Reeder
🤖✨🔖 Позавчора я розповідав, який зручний список читання у Reeder. А вчора навідкривав десь 40 вкладок (передивлявся архів Hacker News), після чого зрозумів — чого Reeder не вміє, це додати у список відразу всі вкладки. Що ж робити?
Сьогодні скористався вбудованими засобами автоматизації, щоб це виправити. Спочатку хотів написати AppleScript. Це давня та езотерична мова, яка надає доступ до даних запущених застосунків. З допомогою AppleScript можна отримати перелік всіх вкладок з Safari - після того, як трохи пограєшся з “наближеним до людської мови” синтаксисом.
Але є проблема. AppleScript працює тільки з тими застосунками, що його підтримують — оголошують власний API. На жаль, Reeder так не робить. Проте виявилось, що він підтримує Shortcuts - більш сучасну систему автоматизації. Shortcuts прийшов з iOS і дозволяє збирати скрипти з графічних блоків.
Shortcuts не працює з вкладками Safari. Зате, в шорткат можна вбудувати шматочок AppleScript (або JavaScript, або шелл-скрипта.) Оскільки скрипт я вже написав, залишилось додати до його результатів цикл та операцію додавання до Reeder. Тут теж не без хитрощів — треба, щоб між кроками збігались типи даних — але в цілому Shortcuts простіше у використанні, ніж AppleScript.
Готовий шорткат можна зашарити, а ви можете подивитись за посиланням. Дивна система поширення шорткатів — каталогу немає, просто ти отримуєш посилання і все.