TL;DR

不要なGitHub Actionsのキャッシュを簡単に削除できるtoshimaru/delete-action-cacheというActionを作った。

GitHub Actions Cacheの容量制限

GitHub Actionsのキャッシュの保持容量は10GBまでという制限がある。

GitHubは、7日間以上アクセスされていないキャッシュエントリを削除します。 保存できるキャッシュの数に制限はありませんが、リポジトリ内のすべてのキャッシュの合計サイズは制限されています (最大 10 GB)。

ref. 依存関係をキャッシュしてワークフローのスピードを上げる - GitHub Docs

キャッシュが超過している・超過しそうだと下記のような警告が表示される。

Least recently used caches will be automatically evicted to limit the total cache storage to 10 GB. Learn more about cache usage.

キャッシュ容量制限で困るケース

比較的小さいプロジェクトであれば、この制限に引っかかることは少ないだろう。

しかし下記のようなケースで、この10GBという制限が足かせになることがある。

• 巨大な Monorepo を運用している
• docker/build-push-actionなどを使って大きいdockerイメージをレイヤーキャッシュしている

10GBを超えると古いキャッシュから削除されていくため、キャッシュスラッシングが発生してビルドが遅くなったり、場合によってはビルドが壊れることもある。

最近だとこちらの記事が話題になっていた：やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ

不要なキャッシュを削除するActionを作った

そういった問題を解決するため、不要なGitHub Actionsのキャッシュを簡単に削除できるActionを作った。

toshimaru/delete-action-cache: Delete GitHub Actions Cache with ease.

具体的には下記のようなことが簡単にできるようになる。

• Pull Request のマージ後、トピックブランチに紐づくキャッシュを削除
• workflow_dispatch イベントをトリガーに、特定ブランチのキャッシュを削除
• scheduleイベントをトリガーに、特定ブランチのキャッシュを削除

工夫したところ

今回のActionを作るにあたり、下記のような工夫をした。

自動リリース

r7kamura/bump-requestを使い、workflow_dispatchからPRマージでリリースできるように自動化を行った。

リリース自動化に関してはbump-requestの作者が解説記事を上げているので、そちらを参照するとよい。

• リリースの自動化
• パッケージリリースの自動化

メジャーバージョンリリースの自動化

GitHub Actions には v1.1, v1.2, v1.3… のようなリリースを v1 とメジャーバージョンに丸めて扱う慣習がある。

このへんのリリースは actions/checkout でやっている半自動アプローチを採用した。手動でworkflow_dispatchからリリース対象バージョンとタグを指定してリリースする方法である。

詳しくは下記の.github/workflows/update-main-version.ymlワークフローの内容を参照するとよい。

checkout/.github/workflows/update-main-version.yml at main · actions/checkout

おわり

もしGitHub Actionsのキャッシュ容量制限にお困りの方はお試しください。

余談

このActionを作るにあたり、gh cache listコマンドにオプションが欲しくなったので、付けておいた。

• feat: Add cache key option to gh cache list by toshimaru · Pull Request #8667 · cli/cli
• feat: Add ref option to gh cache list by toshimaru · Pull Request #8711 · cli/cli

`gh cache list` コマンドに ref オプションも足したぞい！ » Release GitHub CLI 2.45.0 · cli/cli https://t.co/4mtappf4UP https://t.co/lcJJw0AvjF

— toshimaru (@toshimaru_e) March 5, 2024

参考文献

• Caching dependencies to speed up workflows - GitHub Docs
• GitHub Actions の Cache 管理(2023 年 1 月の場合)

GitHub Actions のワークフローの実行ログを削除するGitHub CLI 拡張機能、gh-workflow-log-cleaner を作成したのでご紹介。

toshimaru/gh-workflow-log-cleaner: Clean outdated workflow logs.

モチベーション

古いGitHub Actionsのワークフロー実行ログは残り続ける。現役バリバリで利用しているワークフローならいいが、既に使用していないワークフローの場合、このログがノイズになることがある。

GUIでポチポチ実行ログを削除することは可能だが、まとめて削除する方法は提供されていない。代わりに公式ドキュメントでは、Bashプログラムで削除する方法が紹介されているが、やや面倒でカジュアルには実行しにくい。

ということで、GitHub CLI 拡張機能化しカジュアルに実行できるようにしてみた。

拡張機能の作成方法

GitHub CLI の拡張機能は、大きく下記の２つの方法がある。

• Bash 方式
• Go Precompile方式

ref. Creating GitHub CLI extensions - GitHub Docs

今回はBash方式で作成した。下記のコマンドで拡張機能をイニシャルセットアップできる。

$ gh extension create EXTENSION-NAME

工夫した点

• Bashのテストを書くために bats-core/bats-core を使用した
  • see also. 2024-08-30 BATS(Bash Automated Testing System)でBashのテスト | TTIL
• optionをパースするのを少し頑張った(--limitオプション)
• GitHub cliと同じような出力になるように一部を bold に echo するなどした

注意点

• 拡張機能のリポジトリ名は gh- で始まる必要がある
• 拡張機能をgh extension searchで検索機能にするためには、gh-extensionというトピックを設定する必要がある

GitHub公式が出している issue-metrics Actionをご紹介。

開発生産性を計測するにはGitHub Insightは貧弱すぎる

GitHubのデータで開発生産性を計測したい。いわゆるFour Keys メトリクスを計測したい。

しかし、開発生産性を計測するにはGithub Insightの機能はあまりにも貧弱だ。

そんな折にGithubから開発メトリクスを計測する公式Actionが出ていたので試してみた。

github/issue-metrics: Gather metrics on issues/prs/discussions such as time to first response, count of issues opened, closed, etc.

説明

リポジトリ名にIssueと付いているので、Issueに関するメトリクスを計測するものかと勘違いしてしまいそうになるが、Pull Requestに関するメトリクスも計測することができる。

具体的には下記の項目を出すことができる。

• Time to first response: PRが最初にレビューされるまでの時間
• Time to close: PRがマージ/クローズされるまでの時間
• Number of items closed: どれだけPRをマージ/クローズできたか
• PR一覧

使い方

公式のREADMEに掲載されたUsageの設定だと前月データ決め打ちになっているので、Year-Month を指定してworkflow_dispatchイベントで実行できるように改修したものが下記：

repo:your-org/repo-name の部分は計測したいリポジトリ名に置き換えること。

# .github/workflows/monthly-metrics.yml
name: Monthly Pull Request metrics

on:
  workflow_dispatch:
    inputs:
      year:
        description: "Enter the year (e.g. 2023) for which you want to collect metrics"
        required: true
        type: number
      month:
        description: "Enter the month (1-12) for which you want to collect metrics"
        required: true
        type: number

permissions:
  issues: write
  pull-requests: read

jobs:
  build:
    name: pull request metrics
    runs-on: ubuntu-latest

    steps:
      - name: Get dates for specified year and month
        shell: bash
        run: |
          # Get the specified year and month from the inputs
          year=$
          month=$

          # Calculate the first day of the specified month and year
          first_day=$(date -d "$year-$month-01" +%Y-%m-%d)

          # Calculate the last day of the specified month and year
          last_day=$(date -d "$first_day +1 month -1 day" +%Y-%m-%d)

          # Set an environment variable with the date range
          echo "$first_day..$last_day"
          echo "selected_month=$first_day..$last_day" >> "$GITHUB_ENV"
      - name: Run issue-metrics tool
        uses: github/issue-metrics@v3
        env:
          GH_TOKEN: $
          SEARCH_QUERY: "repo:your-org/repo-name is:pr created:$"
      - name: Create issue
        uses: peter-evans/create-issue-from-file@v5
        with:
          title: "Monthly pull request metrics report ($)"
          token: $
          content-filepath: ./issue_metrics.md

実行イメージ

下記のようにActionsページからポチポチで対象年＆月を指定して実行でする。

サンプル

作られたメトリクス結果のサンプルは下記：

Monthly pull request metrics report (2024-08-01..2024-08-31) · Issue #2333 · toshimaru/RailsTwitterClone

最後に

Github Pull Request の簡易的なメトリクスを振り返るのに issue-metrics は便利。

一方で、GitHub公式の機能として Four Keys っぽいものをリアルタイムで確認できるような機能が欲しいぞ。GitHub殿、よろしく頼む。

RubyKaigi 2024に参加して、そのアフターイベントであるRubyKaigi 2024 Wrap Party にて『RubyKaigiのプロポーザルを通したい。 』という発表をしました。

資料

発表のきっかけ

久しぶりにRubyKaigiに参加してみて、RubyKaigiは素晴らしいイベントだと感じたので、RubyKaigiのカンファレンスとしての特殊性に触れつつ、プロポーザルを出してみたいと思っている人に参考になる情報が発信できたら、と思い今回の発表をしました。

自分もプロポーザルを出したいと思った

発表の中でも言及しましたが、RubyKaigiはRubyを作っている人たちのためのイベント です。

一方、普段僕が仕事の中で最も書いているのはRuby on Railsのコード。そんな僕にとって RubyKaigi というイベントは＜登壇する場＞という意味においては “Not For Me” なイベントだと感じていました。

ただ今回、数人の知り合いがRubyKaigi登壇しているのを見る中で、僕もこんな素晴らしいイベントで話してみたいなぁという思いが強まりました。

RubyKaigiの特殊性についてついてまとめたいと思った

Matzさんもよく「RubyKaigiは特殊なイベントだ」という風におっしゃっていて、最初僕はその特殊性についてピンときていませんでした。

ただ下記の@a_matsudaの資料を読み込むうちに、松田さんがRubyKaigiに掛けている情熱、何を大事にしてRubyKaigiを運営されているか、RubyKaigiの唯一無二性を紹介したいと思いました。

発表してみての感想

RubyKaigiにプロポーザル出してみようと考えている方の刺激になった、という声をいただけたのは良かったです。

オフライン勉強会はいいですね

最近オフラインの勉強会にちょくちょく顔を出しているのですが、やっぱりオフラインの勉強会はいいなって思います。

エンジニヤー、コロナ禍で相当勉強欲が満たせず鬱憤が溜まってたのか、大体どの勉強会も盛況だしLT発表枠も埋まっとる。首都圏だけでなく、地方の勉強会コミュニティも活発なのはいいですね。

— toshimaru (@toshimaru_e) May 31, 2024

最近オフラインの勉強会に数回出て思うのは、やっぱり求めてるのはこういうのなんだよ、こうゆうの〜、って感じになってる。

— toshimaru (@toshimaru_e) June 18, 2024

オンライン勉強会では感じ取れない「熱」がそこにあるんですよね 🔥。そして登壇する側としても衆人環視の中、適度な緊張感がありそれがまた良い。

あと個人的に勉強会の参加意義の半分くらいは、そのあとの懇親会とかカジュアルトークにあると思っていて、そこでするディープな＜現場トーク＞であったり世間話が自らの刺激になったり、知見になったりする。

「あの発表良かったです〜」「あの記事参考にさせてもらいました〜」みたいな言葉をダイレクトにいただけるのはアウトプットの源泉・モチベーションになるんですよね。

で、プロポーザルネタは？

発表後に「プロポーザルネタはなんかあるの？」って聞かれたんですが、正直言うとコレといったものはありません。笑

ただ、RubyKaigi参加後、間違いなくコントリビューション欲は出たので、Rubyのエコシステムへの貢献度は増やしていきたいなって思った次第です。

コントリビューションする中で結果として、RubyKaigiプロポーザルネタが見つかるといいなと思っています。その結果プロポーザルのネタが見つからなかったとしても、自らの行ったコントリビューション自体は消えずに残り続けるので、それはそれとしてやっていきたいと思います。

TL;DR

静的なサイトのHTMLをminifyするには、wilsonzlin/minify-htmlを使うのが良かった。

やりたいこと

このブログの静的HTMLはJekyllによって生成されている。Jekyllで生成されているHTMLをminifyしてHTMLサイズを小さくしたい。

最初に考えたこと

最初はjekyllのプラグインでminifyできないかを考えたが、下記の理由につき断念。

• 良さそうなプラグインがないこと
• Jekyll内のロジックの複雑性が増すこと
• 静的データの生成時間が増すこと

minify-html を使う

結局のところSSGは静的サイトを吐き出しているだけなので、吐き出した結果のHTMLを後処理としてminifyできればOK。

ということでそういう用途であればwilsonzlin/minify-htmlが良さそうなことがわかった。

決め手となったポイントは下記。

• Rust実装で高速
• CLIツールとして利用可能

minify-html を GitHub Actions に組み込む

GitHub Actionsを使ってこのサイトはデプロイしているので、デプロイのビルドステップにて minhtmlをかますようにすればOK.

具体的には、jekyll buildした後にminhtmlのリリースバイナリを取得し、静的データが格納されているディレクトリ（_site）に対してminify処理を施す。

GitHub Actionsのビルドステップは下記のようになる。

  - name: Jekyll Build
    run: bundle exec jekyll build
    env:
      JEKYLL_ENV: production
  - name: minify HTML
    run: |
      wget -O minhtml -q https://github.com/wilsonzlin/minify-html/releases/download/v0.15.0/minhtml-0.15.0-x86_64-unknown-linux-gnu &&
        chmod +x minhtml &&
        ./minhtml --do-not-minify-doctype --keep-spaces-between-attributes --ensure-spec-compliant-unquoted-attribute-values _site/**/*.html _site/*.html
  - name: Upload artifact
    uses: actions/upload-pages-artifact@v3

そのままだと、The W3C Markup Validation Serviceで検証すると不正なHTMLが出力されるので、下記のオプションをつける必要があった。

• --do-not-minify-doctype
• --keep-spaces-between-attributes
• --ensure-spec-compliant-unquoted-attribute-values

まとめ

SSG（静的サイト生成）で生成したHTMLをminifyするには、wilsonzlin/minify-htmlが便利だった。

PHPerKaigi 2024で「10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡」というタイトルで発表しました。

※ブログのリニューアル作業を優先して進めていたら、記事の公開がだいぶ遅れてしまいました💦

話した内容を一部抜粋して、記事の形で紹介します。

登場人物

• Legacy App: 移植対象となるPHPアプリケーション。
• New App: 移植先となるRailsアプリケーション。

４つの技術負債解消アプローチ

リファクタリング

• Pros
  • ボトムアップで少しずつ安全に進められる
• Cons
  • チマチマと直すので、全てをキレイにするには膨大な時間がかかる

✅ レガシー化する前の健全なシステムであれば有効なアプローチ

（※レガシー化した後では「手遅れ」なケースが多い）

マイグレーション

• Pros
  • 機能単位・サービス単位・コンポーネント単位で安全に進められる
  • 優先度の高い一部分だけを移植対象にすることが可能
• Cons
  • 移植しやすい単位を適切に切る必要がある
  • 新旧システムの互換性を考慮する必要アリ
  • 新旧システムの並行運用期間が必要
  • 優先度の低い機能は放置され「塩漬け」になるリスク

✅ 安全性・速度・柔軟性ともにバランスのとれたアプローチ

リプレイス

• Pros
  • 一撃で負債解消できる
  • 新旧システムの並行運用期間は短くできる
• Cons
  • 必然的にビッグバンリリースとなりリスク大
  • スコープがでかいので時間がとてもかかる
  • トップダウンの意思決定（経営層の理解）が必要

✅ 成功させれば一撃必殺となるハイリスク・ハイリターンなアプローチ

削除

• Pros
  • 簡単！早い！（消すだけ）
  • 安い！（工数かからない）
• Cons
  • 「なるほど完璧な作戦っスね―ッ 不可能だという点に目をつぶればよぉ～」
  • 巻き込み事故に注意（必要ないと思って消したら実は必要だったケース）

✅ これができれば最高なアプローチ

（※現実的には全て削除は不可能で、部分的な削除になることが多い）

ソフトウェア開発の三本柱¹

• バージョン管理: GitHub でソースコード管理
• テスティング: PHPUnit + E2Eテスト
• 自動化: GitHub ActionsでCI/CDを整備

３つの移植方針

1. ロジックKeep移植: Legacy App のロジックを維持したまま移植。
2. 仕様Keep移植: Legacy App の仕様を維持したまま移植。
3. リニューアル: Legacy App をゼロからリニューアル。

リニューアルできるのであれば、さっさとリニューアルするのが吉…だけど、実際はそう簡単にリニューアルはできないので、現行の仕様を踏襲しつつ移植するのが現実的な落とし所になりがち。

結果

• 移植によってレスポンス速度が10倍に向上
• Legacy Appのコードベースを100万行削除

教訓

＜技術的負債返済プロジェクト＞が必要になるまで技術的負債を放置しない！

技術的負債自体は健全な開発チームにあって当然のこと。恒常的な負債返済サイクルが回っていないことが問題なので、普段から技術的負債の返済は心がける。

TIPS紹介

• レガシーコードをGitHub Copilotに放り投げて解説してもらうだけでも、コードリーディングの速度・解像度がグンと上がって開発体験が良かった
• 自動テスト項目をrspec --format documentationでドキュメント出力し、テスターに渡しておくと、仕様の理解促進やテスト実施項目の削減にもつながって◯
• 非エンジニアにも技術的負債について理解してもらうために、「技術的負債とは何か」について話す機会をもらって、話をできたのは良かった
• 移植時の実装方針について議論が割れたときのために、実装方針の最終意思決定者を一人に決めたのは不毛な議論が減って良かった
• Code Review が遅い問題は別発表にてまとめました: Faster Pull Request Reviews 〜ハイパフォーマンスチームへの道〜 / Faster Pull Request Reviews - Speaker Deck
• あるコードが本当に使われていないかを確認するために GitHub の Org 横断検索を使うのが良かった
  • クエリ: org:{your-org} NOT is:archived {unused_code}

感想

• 普段はRuby系のコミュニティに顔出すことが多かったので、PHPコミュニティとかかわれたのは良かったし、別のコミュニティからの刺激をもらえて良かった
• リアル勉強会はいいぞ！
  • 謎のモチベーションがムクムク湧いてくる不思議
• 発表資料のベースデザインは Azusa 3 を使わせていただいた。便利
• 参加者からのフィードバックでは「参考になった」という言葉がいただけて良かった
• プロの声優さんに出囃子やってもらうの最高体験だった
• fortee 以前使ったときよりいろいろ機能がアップデートされて強くなっててすごかった

当日の様子

お久しぶりの更新です。ブログをリニューアルしました。

お久しぶりです。

久しぶりのブログ更新です。

ブログのデザインをリニューアルしたいなーと思い立ち、リニューアルを推進するために自分自身にブログのデザインを刷新するまではブログを更新しないぞ、という制約をかけてました。

その過程で TTIL なんていう雑メモ置き場的なサブ・ブログを初めてしまい、本家のこちらの更新をサボっておりました。

が、一念発起してブログをリニューアルしました。

技術スタック

ブログの技術スタック…という程大きな技術スタックの変化はないのですが、今回のリニューアルで使った技術を紹介します。

（🆕 が付いているのが今回のリニューアルでの新たな取り組み）

• Blog Engine: Jekyll
• Hosting: GitHub Pages
  • 開発中のホスティング: Cloudflare Pages (🆕)
• CSS: Tailwind CSS (🆕)
  • Base Theme: timlrx/tailwind-nextjs-starter-blog (🆕)
  • 本文のスタイル: tailwindlabs/tailwindcss-typography (🆕)

tailwind-nextjs-starter-blogが好みのシンプルでスッキリとしたデザインに仕上がっていたので、それをベースに Jekyll に合わせて改変を加えでデザインを仕上げた。

最初はお手製のtoshimaru/jekyll-theme-classless-simpleを使ってデザイン組んでいたけど、今後のカスタマイズ性を考えて Tailwind CSS で組む方向に方針転換した。

個人ブログのレイアウトを TailwindCSS で組んでみるなどしてみた。個人ブログくらいの規模なら別に使わなくてもいい気はしたけど、 TailwindCSSのエコシステムに乗っかっていることで得られるであろう今後のメンテナンスのしやすさはかなり良さそうという実感を得た。

— toshimaru (@toshimaru_e) March 17, 2024

HostingはGitHub Pagesと基本は変わっていないが、開発中のPrivateなホスティング（ログインしたら開発中のブログv2が閲覧できる）は Cloudflare Pages を使った。

Private Repo で GitHub Pages が使えなかったのでCloudflare Pages でサイト構築した » GitHub Pages は（GitHub 無料プランにおいて）プライベートリポジトリでは運用できない https://t.co/4vjiqkGffl

— toshimaru (@toshimaru_e) May 1, 2023

他にも検討したこととして、ブログエンジンを Jekyll から卒業して Next.js、Hugo、Astro あたりに乗り換えることを検討したが、コアライブラリのアップデート追従でエターナる未来が見えたので、一番慣れている Ruby 製の Jekyll で落ち着いた（加齢とともに新たな技術的チャレンジが腰が重くなる今日この頃）。

変更点・工夫ポイント

• Google Analytics タグを GA4 タグにアップデート
  • やっと重い腰を上げて GA4 にアップデートした…けど、GA4めっちゃわかりにくくない？😱
  • [GA4] Google タグ マネージャーで Google アナリティクス 4 を設定する - タグ マネージャー ヘルプ
  • Google Tag Assistant も活用した
  • FYI: GAのChrome拡張（Page Analytics (by Google)）はもう Deprecated らしい
• ダークモードに対応
  • JavaScirpt を使ってワンボタンで切り替えられるように
  • 最初は切り替えをさせずにブラウザのテーマをベースにスイッチするようにしようかと思ったけど、気分によってライトモード・ダークモードが切り替えられたほうが嬉しいので切り替え可能にした
• ブログタイトルを変えた
  • ゼロ年代の慣習としてブログタイトルをオシャレなもにする、というものがあるがもはや今となってはそれは死んだ文化になっているので簡素なものにした
  • (before)Hack Your Design 👉 (after)toshimaru/blog
• Jekyll を Ruby 3.3 でビルドするように変更
• Tailwind CSS導入に伴い、リポジトリにpackage.jsonを導入
• ソースコードは旧デザインと同じリポジトリを使って公開
  • toshimaru/blog.toshimaru.net
  • 積年のコミットログで重くなっていたので、これを機に過去のデザインは別リポジトリにアーカイブし、新デザインでゼロからコミットログを積むことにした

今後対応したいこと

下記あたりは今後のアップデートで対応したいと思っています。

• 記事シェアボタン設置
  • X(ex-Twitter)
  • Hatebu
• コメントフォーム設置 (giscus使いたい)
• 検索ページが味気ないのでアップデートしたい
• SVGロゴの刷新
  • favicon用のSVGを作成
  • ロゴのリニューアル
• AboutページをGitHubのプロフィールを使いまわしているのでブログ用に作成したい
• ダークモードスイッチャーをオシャレに
• Google Adsense を再導入
• OG画像をいい感じに生成するやつ
• タグページを追加
• フッターのアップデート
• HTML/CSSの最適化

ブログ更新していくぞ

リニューアルもしたことだし、わりと長めの文章や技術記事とかはこちらを更新していこうと思います。💪

日々の学びを綴るサブブログもよろしくです 👉 TTIL

参考資料

• Google Analytics 4
  • Googleアナリティクス4とは？アップデート情報を完全解説！
  • [GTM] 新しいGA4のタグ設定の仕方 | アユダンテ株式会社
• Tailwind情報
  • Installation - Tailwind CSS
  • Tailwind Play
  • Tailwind CSS 導入時のメモ: 2024-03-29 TailwindCSS 入門 | TTIL

結論

先に結論だけ書きます。ここだけ押さえておけばOK。

• 「無償版G Suite終了」という方針が撤回され、継続されることになった
• まだ無償版からアップグレードしていない方: こちらから申請
• 既にアップグレード対応してしまってた方: サポートに問い合わせれば :ok:

無償版G Suiteが終わる！？

独自ドメインでメールアドレスを運用する場合、無償版G Suiteが定番でした。

無償版 G Suiteの新規契約は、2012年12月5日をもって終了しており、現在新規契約は停止しています¹。

しかし、2022年一月に無償版G Suiteの終了がアナウンスされました。これにより、長らく無償版G Suiteを使用していたユーザーはアカウント移行を余儀なくされるかたちとなりました。

しかし、結論としては無償版G Suiteは継続されることになりました。それに至る経緯をまとめたいと思います。

対応タイムライン

個人的な対応タイムラインを時系列で追います。

• 2022年1月下旬: rebuild.fm で無償版G Suite が終了することを知る
  • この時点で僕のG Suiteアカウントに日本語のアナウンスメールは無し
  • この回で話されているように、影響を受ける人も多くクラスアクションが取られることを考えると有償化方針は撤回される可能性もあると考え、この時点では特にアクションせず様子見をすることに
• 2022年4月上旬: Googleから無償版G Suite終了のアナウンスメールがアカウントに届く

  • 先行して話題になってたからわかってはいたけど、ついにGoogle workspaceの有料化の案内が今朝きてしまった。どうするか検討せねば… pic.twitter.com/7Tg2VcpSTH

    — toshimaru (@toshimaru_e) April 8, 2022

  • この頃から本格的にアカウント移行のための準備を始める
  • 手始めに、無償版G Suiteアカウントを最小限にするために、家族のために作成したアカウントのGmail移行を行う
    • 幸いにも家族アカウントはヘビーに運用していなかったのですんなりいった
• 2022年5月上旬:
  • 謎の「料金不要化のオプション」が登場したが詳細不明
  • 有償化アップグレード後も「3ヶ月無料、一年は1アカウントあたり月額300円」とのことだったので、とりあえずこのプランを契約して一年アカウントを延命することにした

  • ６月までにプラン変えろとのことなのでとりあえず上げといた pic.twitter.com/DpYMmd6tso

    — toshimaru (@toshimaru_e) May 3, 2022

• 2022年5月17日: パーソナルユースのアカウントは無償版G Suiteは継続されることが発表された

  • For users of the free legacy GSuite, @Google has added an option in the admin console to opt out of the @GoogleWorkspace transition for personal accounts. The personaly use option is rolling out slowly, so if you don't see it now, check back later. https://t.co/PURAsEM2cG pic.twitter.com/MhIiTdQElx

    — Steve Whitcher (@NeighborGeek) May 16, 2022

  • 既にアップグレードしてしまった人に関してはサポートに問い合わせを行えば対応してもらえるとのことだったので、サポートに問い合わせた
    • 状況を伝えるとすんなりわかってくれた
    • やりとりの中で同意書への同意を求められた
    • 同意後、移行を進めます、となった
    • 移行完了後にメールで連絡するとのこと
    • （もうすぐ一週間がたつがまだ無償版への移行は未完了）

ということで現在は一度アップグレードしてしまったプランを無償版G Suiteに戻してもらう移行手続きの途中ということになります（移行完了後にまたこちらに報告します）。

無償版G Suiteが終了した場合どうしていたか？

今回は無償版G Suiteが継続されることになったから良かったものの、ついでに本当に無償版が終了していた場合に対応はどうしていたかも書いておこうと思います。

いろいろ検討した中では、最終的にはCloudflare Email Routingが一番良さそうでした。

https://t.co/wkrifm4rz2 聴きつつ Cloudflare Email Routing が良さそうやんって思って試したら全然イケたので「これでいいや」という気持ちになったhttps://t.co/q0gxfT5ZTs

— toshimaru (@toshimaru_e) April 22, 2022

Cloudflare Worker にルーティングしてEメール処理をゴニョったりもできて、カスタマイズ性・拡張性に富み良さそうでした。

いつか来る有償化の流れに備えを

今回のアナウンスに伴い、アカウントを削除・移行したり、その作業に多くの時間を費やした方も多くいらっしゃるのではないかと思います。残念ながら削除したアカウントは戻ってきませんし、費やした時間・労力も当然戻ってきません。

先般も楽天モバイルの0円プラン廃止が話題となりました。こういった”おいしい”無料プランは未来永劫続くわけではないことを肝に命じて、いつか来る有償化の流れに備えておく必要がありそうです。

参考

• 従来の無償版 G Suite からのアップグレード - Google Workspace 管理者 ヘルプ

本記事では、マルチステージビルド構成のDockerfileのビルドの並列実行について紹介したいと思います。

前提

• Docker Desktop v3.2.1
  • Docker v20.10
  • Docker Compose v1.28

Dockerfile

今回テストで使うマルチステージビルドのサンプルとなるDockerfileは下記です。

FROM alpine as test1
RUN sleep 10.1 # sleep from test1

FROM alpine as test2
RUN sleep 10.2 # sleep from test2

FROM alpine as test3
RUN sleep 10.3 # sleep from test3


FROM alpine
RUN echo "build start"
RUN sleep 10.0 # sleep from main

COPY --from=test1 /tmp /tmp
COPY --from=test2 /tmp /tmp
COPY --from=test3 /tmp /tmp

RUN echo "build finished"

直列実行 vs 並列実行

実際に上述の Dockerfile のビルドを並列実行しない場合（直列実行）と並列実行する場合の結果を比較してみます。

並列実行しない場合

並列実行をOFFにして実行するには DOCKER_BUILDKIT=0 の環境変数をセットして docker buildを行います。

$ DOCKER_BUILDKIT=0 docker build --no-cache .
Sending build context to Docker daemon  331.1MB
Step 1/13 : FROM alpine as test1
 ---> b7b28af77ffe
Step 2/13 : RUN sleep 10.1 # sleep from test1
 ---> Using cache
 ---> 11b4518313de
Step 3/13 : FROM alpine as test2
 ---> b7b28af77ffe
Step 4/13 : RUN sleep 10.2 # sleep from test2
 ---> Using cache
 ---> c61101646517
Step 5/13 : FROM alpine as test3
 ---> b7b28af77ffe
Step 6/13 : RUN sleep 10.3 # sleep from test3
 ---> Using cache
 ---> 1aa97a170923
Step 7/13 : FROM alpine
 ---> b7b28af77ffe
Step 8/13 : RUN echo "build start"
 ---> Using cache
 ---> 8b2b09749321
Step 9/13 : RUN sleep 10.0 # sleep from main
 ---> Using cache
 ---> bc3f772d3fb1
Step 10/13 : COPY --from=test1 /tmp /tmp
 ---> Using cache
 ---> 0f861020f1c0
Step 11/13 : COPY --from=test2 /tmp /tmp
 ---> Using cache
 ---> eea3d212c0b7
Step 12/13 : COPY --from=test3 /tmp /tmp
 ---> Using cache
 ---> 9beba31a0ff6
Step 13/13 : RUN echo "build finished"
 ---> Using cache
 ---> 0986bef3d18f
Successfully built 0986bef3d18f

sleep 10 × 4 が直列に実行されるため、ビルドに 最低でも40秒 かかっていました。

並列実行する場合

では次に並列実行してみましょう。

並列実行するには DOCKER_BUILDKIT=1 をセットするか、私の環境の場合 DOCKER_BUILDKIT の環境変数のセットしなくてもデフォルトで並列実行されるようになっていました。

Docker Desktop v3.2 を使っている場合は DOCKER_BUILDKIT=1 の環境変数が不要でデフォルトで並列実行されるようになっており、一方、Docker Desktop v3.1の場合は並列実行するためにはDOCKER_BUILDKIT=1 の環境変数の指定が必要でした。

$ docker build --no-cache .
[+] Building 13.9s (14/14) FINISHED
 => [internal] load build definition from Dockerfile                                            0.1s
 => => transferring dockerfile: 37B                                                             0.0s
 => [internal] load .dockerignore                                                               0.1s
 => => transferring context: 2B                                                                 0.0s
 => [internal] load metadata for docker.io/library/alpine:latest                                0.0s
 => CACHED [test3 1/2] FROM docker.io/library/alpine                                            0.0s
 => [test2 2/2] RUN sleep 10.2 # sleep from test2                                              12.4s
 => [stage-3 2/7] RUN echo "build start"                                                        2.3s
 => [test3 2/2] RUN sleep 10.3 # sleep from test3                                              12.5s
 => [test1 2/2] RUN sleep 10.1 # sleep from test1                                              12.3s
 => [stage-3 3/7] RUN sleep 10.0 # sleep from main                                             10.6s
 => [stage-3 4/7] COPY --from=test1 /tmp /tmp                                                   0.1s
 => [stage-3 5/7] COPY --from=test2 /tmp /tmp                                                   0.1s
 => [stage-3 6/7] COPY --from=test3 /tmp /tmp                                                   0.1s
 => [stage-3 7/7] RUN echo "build finished"                                                     0.4s
 => exporting to image                                                                          0.2s
 => => exporting layers                                                                         0.2s
 => => writing image sha256:2dfb39f0fbed99a19fee51b23db685a0878eed7291bce08e88c3226e8fea271d    0.0s

sleep 10 × 4 が並列に実行されるため、全体として10秒程度でビルドが終了しています。

比較結果

今回サンプルとなった Dockerfile の場合、3倍の高速化 に成功しました。

参考

• DockerイメージのビルドをBuildKitで並列実行し高速化する - 🤖
• マルチステージビルドの利用 | Docker ドキュメント

タイトルの通り。

本ブログは Disqus を使ってコメントフォームを設置しています。いや、正確には設置していました。

SNSのプラットフォームが十分に成熟している昨今ですから、そもそもコメント欄を設置すること自体がなんとなく時代遅れになってきているのでは？と感じるのですが、Jekyllを使われている皆さんはDisqusを使ってコメント欄を設置されているようなので、それに倣ってDisqusでコメントフォームを設置。

Jekyllならここまでできる！ブログをJekyllに移行しました

しかしながら、試したいDisqus有料機能があり有料プランに一度トライアル申込みするとトライアル終了後に 広告が表示され続けて消せない という事態に見舞われました。

サポートチームに問い合わせたのですが 広告を消す唯一の手段は再度有料プランに切り替えることだ ということらしいです。（今までは無料で広告無しで使えていたのですが、一度有料プランにしてしまうとそれが継続できなくなるっぽい😢

そんなこんなでしばらく Disqus コメントフォームを閉鎖していたのですが、やはりコメントフォームはあったほうがいいかなぁということで、 Disqus の別のアカウントを作成し Disqus のコメントを再設置いたしました。

過去のコメントも移行できれば良かったのですが、どうやら Disqus から Disqus のコメント移行はサポートされていないようだったので、過去コメントは失ってしまいました。（過去にコメントいただいた方すみません🙇 データは旧アカウントには一応残っています…

Disqus側のほうで方針変わって広告が無料プランでも表示されるようになったら再び消す可能性もありますが、しばらくはこちらをご利用いただければと思います。🙏

まとめ

Disqus有料プランに（トライアルでも）一度切り替えると、二度と広告無しの無料プランには戻れない。

参考

• How do I import my old comments? | Disqus