Давно присматривался к GitHub Pages, но руки никак не доходили.

Внезапно решил навести порядок на площадках, где публикую статьи и заметки, и решился-таки на статику (как доп. площадку).

Всякие разные Pages

GitHub Pages нативно поддерживает Jekyll — пушнул в репозиторий, и сайт сам собрался. Никаких докеров, никаких CI/CD (ну почти), никаких серверов.

А чтобы было совсем хорошо, решил поддерживать и GitLab Pages — для симметрии. Чтоб не привязываться к одной платформе и чтоб было куда переключиться, если что. Но тут без CI/CD никак.

Структура репозитория и настройки

Репозиторий называется как положено — kinnalru.github.io - тогда он будет доступен по этому доменному имени. Gemfile:

gem "github-pages", group: :jekyll_plugins

group :jekyll_plugins do
  gem "jekyll-feed"
  gem "jekyll-sitemap"
end

Обратите внимание на github-pages — это мета-гем, который тянет Jekyll и все нужные плагины в совместимых версиях. Никаких "а у меня работает", потому что GitHub Pages собирает ровно тем же набором.

Заполняем конфигурацию _config.yml где выбираем тему, плагины, и всякие настройки. Тема minima — адаптивная под светлую/темную тему. И сразу же в конфиге ссылочки на все свои ресурсы: GitLab, GitHub, Teletype, Telegram, Dev.to. Чтоб гость зашел и сразу понял, где меня искать, а то вдруг нигде раньше не нашел ссылок :)

GitLab Pages — симметрия ради симметрии

Для GitLab Pages пришлось чуть заморочиться. GitHub Pages собирает Jekyll сам, а GitLab — нет, нужен .gitlab-ci.yml:

image: ruby:3.2-slim

build:
  script:
    - apt-get update -y; apt-get install -y build-essential
    - bundle
    - JEKYLL_ENV=production bundle exec jekyll build --config _config.yml,_config.gitlab.yml -d ./public/
  pages:
    publish: public
  rules:
    - if: ($CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH) && ($CI_PIPELINE_SOURCE != "schedule")

И отдельный _config.gitlab.yml — переопределяем только url:

url: https://kinnalru.gitlab.io

Jekyll умеет мержить конфиги при сборке: --config _config.yml,_config.gitlab.yml. Всё, что идет справа, переопределяет то, что слева.

Чтоб было "хорошо" — намазал сверху RSS и Sitemap

Просто собирать HTML — это скучно. Мне нужно, чтоб поисковики индексировали, а читатели подписывались. Поэтому сверху еще и:

• ставим плагин jekyll-sitemap, и он автоматически генерирует /sitemap.xml. Но я не доверяю автоматике до конца, поэтому в _includes/custom-head.html добавил явную ссылку:

  <link rel="sitemap" type="application/xml" title="Sitemap" href="/sitemap.xml" />

• ставим плагин jekyll-feed — он генерирует базовый /feed.xml
• но я решил, что хочу RSS с полным контентом статей и расширенными настройками, поэтому написал свой шаблон feed.xml

Кастомные шаблоны

Стандартная minima хороша, но мне хотелось, чтоб на каждом посте была ссылка на оригинальную публикацию. Переопределил _layouts/post.html и _layouts/home.html — добавил canonical_url и пометку "Моя публикация на ...". Теперь зеркало не выглядит как украденный контент, а как полноценный агрегатор.

Что в итоге?

В результате мы имеем:
- Статический сайт на Jekyll, который собирается автоматически
- Зеркало на GitHub Pages — kinnalru.github.io
- Зеркало на GitLab Pages — kinnalru.gitlab.io
- RSS с полным контентом для подписчиков и дальнейшей обработки
- Sitemap для поисковиков
- Все ссылки на мои ресурсы в одном месте

Keep it simple, stupid — но при этом всё должно работать.

Teletype | Архи DEV | Dev.to | GitHub | Blogger

Кто к нам с чем и зачем?

За годы у меня накопилась целая коллекция площадок, куда я (и не только я) что-то публикую:

• Личный блог на Teletype — сюда пишу руками
• Корпоративный блог blog.rnds.pro — пишем вместе с коллегами
• Dev.to — личный аккаунт kinnalru и корпоративная организация RNDSOFT
• GitHub Pages — kinnalru.github.io
• Blogger (Blogspot) — kinnalru.blogspot.com

Раньше тут обитал ещё и Hashnode, но теперь у этих негодяев платное API для публикации — пусть сами к себе пишут.

Как теперь работает схема

1. Пишу статью вручную в Teletype (личное) или в корпоративный блог.
2. Статьи автоматически улетают в черновики Dev.to через RSS
3. Перед публикацией на Dev.to я добавляю FrontMatteroriginal_author=kinnalru.
4. Публикуем: личные — от себя, корпоративные — от организации RNDSOFT
5. По крону (через GitLab Pipelines) запускается скрипт-синхронизатор, который забирает только мои статьи (по фильтру original_author) и публикует их дальше:

• на GitHub Pages
• на Blogger

Итог

Написал небольшой синхронизатор, который делает всё ровно так, как мне нужно. Теперь дело за малым — писать сами статьи :)

Teletype | Архи DEV | Dev.to | GitHub | Blogger

Иногда, чтобы решить свою проблему, приходится написать инструмент. А иногда — чтобы написать инструмент, приходится решить свою проблему. Короче, как обычно, всё началось не с идеи сделать утилиту, а с того, что добавилась пара важных документов (по иппотке) к существующему зоопарку данных, которые надо хранить.

Как я к этому пришел

У меня давно назрела проблема: синхронизировать разные файлы с разных рабочих мест — по крайней мере дома и на работе. Документы (важные), сохранения из игр, книги для читалки. Ну и надёжный архив всего этого добра, потому что терять даже что-то незначительное это боль 🤕.

Просто положить всё в одно облако — хорошо, но нужен ещё постоянный процесс актуализации. Яндекс Диск работает, Google Drive может изменить условия, Dropbox может внезапно ограничить доступ. Поэтому идея была простая: хранить копии везде. Яндекс Диск, Google Drive, Mail.ru Cloud, Dropbox — чем больше, тем надёжнее. Только файлы, только хардкор!

Раньше я обходился консольным демоном yandex-disk — он работал, но только с Яндексом. Потом перешёл на самописные bash-скрипты, которые вызывали rclone напрямую. Это работало… до поры до времени. Конфигурация разрасталась, порядок синхронизации был важен (нельзя синкать из пустого облака в другое до того, как туда прилетели файлы) и всякое подобное. Проблема!

Когда появились нормальные ИИ-ассистенты для кодинга, я решил, что пора пробовать, а мне нужен нормальный инструмент. Declarative configuration, predictable order, automatic error handling и пр. Так родился Syncerman.

Из говна и палок архитектура и технологии

Syncerman написан на Go — выбрал его только за простоту распространения (один бинарник).

В основе лежит rclone bisync — двусторонняя синхронизация с сохранением метаданных. Syncerman не пытается переизобрести колесо синхронизации, а выступает оркестратором над rclone, предоставляя удобный CLI и YAML-конфигурацию. Никаких серверов и БД.

YAML-конфигурация

Вместо папок с ссылками на bash-скрипты — чёткая структура:

jobs:
  important:
    name: "Важное"
    priority: 10
    tasks:
      - from: "local:/home/jerry/cloud/mirror/Documents"
        to:
          - path: "gdrive:folders/Documents"
          - path: "ydisk:folders/Documents"
      - from: local:Наследие
        to:
          - path: gdrive:Наследие/
            args: [ "--force" ]
          - path: ydisk:Наследие/
            args: [ "--force" ]
          - path: mailru:Наследие/
            args: [ "--force" ]

  games:
    name: "игрули"
    priority: 20
    tasks:
      - from: "local:games_sync"
        to:
          - path: "ydisk:folders/games_sync"

Порядок tasks и to внутри массивов сохраняется строго. Это критично для цепочек: local → Google Drive → Yandex Disk. Без этого — катастрофа.

Проблемасики

rclone bisync требует state-файлы для работы (они лежат где-то в папке пользователя). При первом запуске на новой паре путей он падает с ошибкой "cannot find prior Path1 or Path2 listings". Syncerman детектирует это по двум паттернам в выводе и автоматически перезапускает синхронизацию с флагом --resync. Пользователь даже не замечает проблемы. Раньше делал руками.

На ранних этапах обнаружился критический баг: из-за использования map в Go порядок выполнения целей был недетерминированным. Для линейных цепочек это катастрофа: если сначала синкать из пустого Yandex в Google, а потом из локальной папки в Google — быть беде. Проблема! Так появились массивы.

Результат

Syncerman версии **0.3.6** сейчас работает в production — то есть на моих машинах :) Само собой нужны пруфы, и их есть у меня!

• бинарники для Linux и Windows (сборка сразу подо всё)
• GitLab CI как в лучших домах
• Покрытие тестами - самому было бы лень писать а тут юнит-тесты для всех ключевых пакетов (config, rclone, sync), интеграционные тесты (не просто интеграционные а целые bash-сценарии с десятком шагов).

Публичные репозитории (это мой фетиш):

• Gitlab https://gitlab.com/kinnalru/syncerman
• Github https://github.com/kinnalru/syncerman
• Gitflic https://gitflic.ru/project/kinnalru/syncerman
• Gitverse https://gitverse.ru/kinnalru/syncerman

Использование

Мой crontab выглядит так:

# Синхронизация документов и сохранений 2 рааз в час и лог для ручной проверки
10,30 * * * *   /bin/sh -lc "cd /home/jerry/cloud/mirror && syncerman sync 2>&1 | tee ./lastrun.log"

Конфигурация зеркалирует локальные папки во все облака (настроенные в rclone) одновременно, а затем синхронизирует облака между собой. Если одно облако отвалится — данные остаются в остальных. Если rclone выдаст first-run ошибку — Syncerman сам всё починит.

Вместо вывода

Появление ИИ-ассистентов снизило порог входа для написания таких инструментов. Раньше мне было лень писать то, что и так работает с помощью пары строк на bash. А сейчас это делаю не я :) — разбор выхлопов rclone, обработка edge cases и тестирование делаются очень легко. Я могу заняться решением проблем (архитектурой и требованиями), а рутина "делается сама".

Второй фетиш это ссылочки:

• rclone bisync - это база
• unison - еще одна классная штука по теме синхронизации, она прочно заняла место в моём сердце, но об это в другой раз

Шаг первый - установка

Игра очень крутая - используется в универах для обучения экономике, однако выпущена в 2001 под Windows и это большая проблема.

Находим пыльный диск или качаем с торрентов, ставим себе wine и устанавливаем игру. Ей потребуются зависимости, которые проще всего поставить с помощью winetricks - они очень помогают. Зависимости:

• mfc42.dll
• шрифты (я ставлю все)
• DirectPlay (без этого сетевая игра по локалочке с друганом не заработает)

Игра достаточно сложная и я предпочитаю играть в неё с хорошей локализацией, для этого мало поставить русскую версию, надо еще накатить 2 (два) патча с исправлением локализации - ищите их на торрентах.

Для запуска надо будет задать локаль:

LC_ALL=ru_RU.UTF-8 LANG=ru_RU.UTF-8 wine cap2.exe

Эмуляция CDROM

Всё запустится, но не будет работать одиночная игра. Дело в том что если у вас не похаченная версия, то ей нeжен будет CDROM. Его эмуляция делается через winecfg - выбираем Диски, указывам путь к файлам инсталятора, тип ставим CDROM:

Запускаем еще раз и оно работает! На первый взгляд. Но если запустить саму игру то окажется что у неё не перерисовывается экран :(

Это ввергло меня в уныние... Я много и долго тыкал в настройки wine, режимы совместимости, поставил всякие древние версии DirectX и пр. и ничего. Но не зря же я разработчик с 20ти летним стажем?!? Дай, думаю, запущу в оконном режиме. Таких настроек в игре нет, но это не может меня остановить - я перлопатил все файлы игры в поисках конфигов, но не нашел.

После этого я пошел гуглить как заставить игру под виндой работать в оконном режиме и нашел!

Шаг второй - DxWnd

Это такая дич которая перехватывает системные вызовы и вызовы к библиотеке DirectX и позволяет надругиваться над ними.

Ставим эту волшебную прогу также под wine, запускам и настраиваем запуск Capitalism 2. Мне подошло 1440x900 Desktop center, но вы можете указать там что хотите.

Шаг третий - пора играть!

И вот, наконец, после прочтения тонны логов и выхлопов из wine, плясок с версиями библиотек, шрифтами, локалями и DirectX, можно наконец.... Лечь спать. Играть буду в другой день :)

Всем рекомендую - очень увлекательно :)

Прежде всего скажу о том что "правильного решения" нет и вообще "решения" нет. Есть работа и, возможно, её результат. И оценивать я буду стараться весь процесс работы всей команды: аналитику предметной области, презентацию/доклад, конечный результат и многое другое.

И вот тут хочу отдельно обратить внимание на некоторые моменты и для примера рассмотреть разные кейсы.

Допустим у вас сильный разработчик, гений алгоритмизации и прирождённый архитектор. Если в вашем общении с жюри и докладе не будет поставлен акцент на крутость ваших технических решений или их красоту/простоту, то никто не узнает о проделанной работе, о сложностях и о ваших сильных качествах.

С другой стороны, у вас может быть сильная аналитическая составляющая, вы всей командой нашли тот самый кейс, который перевернёт привычный взгляд на вещи, но результат вашего труда выглядит посредственно... Как быть? Делать ставку именно на аналитику! Довести до жюри ваше видение, перспективы и потенциалы развития вашего решения.

И третий случай. У вас обычные прогеры, обычная аналитика и простенький сова, натянутая на глобус бутстрап, натянутый на джангу. Но у вас хорошо распределены роли, каждый знает и делает свою задачу, и у вас есть простой, но законченный продукт, который соответствует вашей аналитике. Вы чётко рассчитали свои силы, оценили риски и уложились в сроки. Красавчики.

Каждый из этих кейсов может рассчитывать на победу и победить. Но для этого жюри должно узнать о ваших сильных сторонах. О планировании, постановке задач, взаимодействии участников команды о проблемах и их решениях. Всё это целиком уместить в 5 минут отчёта не просто, да и не надо - сосредоточьтесь на ваших достижениях.

Определите вашу собственную стратегию, сделайте ставку именно на ваши сильные стороны и дерзайте!

Парк нас встретил зимующим баобабом...

А дальше нас ждёт страшное...