宣伝

GithubのプロフィールはREADMEによって管理できることはご存知かと思います。
プロフィールの README を管理する - GitHub Docs

そのREADMEにて、Qiita・Zennで書いた記事や、connpassの参加イベントを取得することで、最新のアクティビティを表示したいという要望を叶えるのが本アクションです。
以下のようなプロフィールを作ることが出来ます。

使い方は、プロフィールのリポジトリにymlファイルを一個追加し、READMEに書き換え用記述を置くだけです。
アクション使用者はIDなどを設定するだけで良いという、なるべく簡単なインターフェースにすることを心がけました。
Github Actionsには定期実行の仕組みがあり、1日1回自動で更新させるといったことも可能です。
筆者のプロフィールでは以下のymlファイルとREADMEを置いてます。

.github/workflows/main.yml

name: profile updater

on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:

jobs:
  profile-updater:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: kumackey/profile-updater@v1
        with:
          zenn_user_id: kumackey
          connpass_nickname: kumackey
          qiita_user_id: kumackey
      - name: Commit and push
        run: |
          git config --local user.name "GitHub Actions"
          git config --local user.email "action@github.com"
          git add .
          git commit -m "profile updated" || true
          git push origin main

README.md

(略)

# Zenn Articles

<!-- profile updater begin: zenn -->
(略)
<!-- profile updater end: zenn -->

# Qiita Articles

<!-- profile updater begin: qiita -->
(略)
<!-- profile updater end: qiita -->

# connpass Events

<!-- profile updater begin: connpass -->
(略)
<!-- profile updater end: connpass -->

参考(筆者のプロフィールリポジトリ): https://github.com/kumackey/kumackey

詳細は以下リポジトリを見てください。
kumackey/profile-updater

開発

着想

先駆者が割と多くいて、自分も作ってみたいと思い開発しました。
リポジトリを見に行ったりして、大いに参考にさせてもらいました。

mikkame on Twitter: "GitHub ActionsでQiita/Zennの投稿をGitHubプロフィールに自動反映できるようにした
 シェルスクリプトでZennの投稿をGitHubプロフィールに自動反映してみる
 【GitHub Actions】GitHubのプロフィールを自動更新する仕組みを作った - yyh-gl's Tech Blog
githubActionsを定期実行させて、オリジナルなREADME.mdをつくる
 Actions Readme Feed · Actions · GitHub Marketplace

使用技術

GoとGithub Actionsだけです。
業務ではGoを書いたことはありますが、個人開発では初めてまともに使いました。
感想になっちゃいますが、Dockerに乗せるのがクソ楽だったり、ライブラリを気軽に使えたり、構造体リッチにできたのは満足度が高いポイントでした。
何より書いてて安心感があり、本記事作成までにv1.0〜v1.4まで出しましたが、最初期の開発はともかくとして、改修は非常に楽でした。

設計

.
├── Dockerfile
├── action.yml
├── cmd
│   └── main.go
└── pkg
    ├── adapter
    │   └── ...
    ├── domain
    │   └──  ...
    └── usecase
        └── ...

設計は一応はClean Architectureの思想でやりました。
依存はadapter -> usecase -> domainという方向にし、外部API通信やIOは詳細であるとしてadapterに詰め込みました。
ControllerやPresenterに該当する層は~~面倒だったので~~作ってないため、近いのはヘキサゴナルアーキテクチャだと思います。

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab