先に結論だけ書きます。ここだけ押さえておけばOK。
独自ドメインでメールアドレスを運用する場合、無償版G Suiteが定番でした。
無償版 G Suiteの新規契約は、2012年12月5日をもって終了しており、現在新規契約は停止しています1。
しかし、2022年一月に無償版G Suiteの終了がアナウンスされました。これにより、長らく無償版G Suiteを使用していたユーザーはアカウント移行を余儀なくされるかたちとなりました。
しかし、結論としては無償版G Suiteは継続されることになりました。それに至る経緯をまとめたいと思います。
個人的な対応タイムラインを時系列で追います。
先行して話題になってたからわかってはいたけど、ついにGoogle workspaceの有料化の案内が今朝きてしまった。どうするか検討せねば… pic.twitter.com/7Tg2VcpSTH
— toshimaru (@toshimaru_e) April 8, 2022
6月までにプラン変えろとのことなのでとりあえず上げといた pic.twitter.com/DpYMmd6tso
— toshimaru (@toshimaru_e) May 3, 2022
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が継続されることになったから良かったものの、ついでに本当に無償版が終了していた場合に対応はどうしていたかも書いておこうと思います。
いろいろ検討した中では、最終的にはCloudflare Email Routingが一番良さそうでした。
https://t.co/wkrifm4rz2 聴きつつ Cloudflare Email Routing が良さそうやんって思って試したら全然イケたので「これでいいや」という気持ちになったhttps://t.co/q0gxfT5ZTs
— toshimaru (@toshimaru_e) April 22, 2022
Cloudflare Worker にルーティングしてEメール処理をゴニョったりもできて、カスタマイズ性・拡張性に富み良さそうでした。
今回のアナウンスに伴い、アカウントを削除・移行したり、その作業に多くの時間を費やした方も多くいらっしゃるのではないかと思います。残念ながら削除したアカウントは戻ってきませんし、費やした時間・労力も当然戻ってきません。
先般も楽天モバイルの0円プラン廃止が話題となりました。こういった”おいしい”無料プランは未来永劫続くわけではないことを肝に命じて、いつか来る有償化の流れに備えておく必要がありそうです。
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"
実際に上述の 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秒程度でビルドが終了しています。
ビルド時間 | |
---|---|
並列実行しない場合 | 50秒 |
並列実行する場合 | 15秒 |
今回サンプルとなった Dockerfile
の場合、3倍の高速化 に成功しました。
本ブログは Disqus を使ってコメントフォームを設置しています。いや、正確には設置していました。
SNSのプラットフォームが十分に成熟している昨今ですから、そもそもコメント欄を設置すること自体がなんとなく時代遅れになってきているのでは?と感じるのですが、Jekyllを使われている皆さんはDisqusを使ってコメント欄を設置されているようなので、それに倣ってDisqusでコメントフォームを設置。
Jekyllならここまでできる!ブログをJekyllに移行しました
しかしながら、試したいDisqus有料機能があり有料プランに一度トライアル申込みするとトライアル終了後に 広告が表示され続けて消せない という事態に見舞われました。
サポートチームに問い合わせたのですが 広告を消す唯一の手段は再度有料プランに切り替えることだ ということらしいです。(今までは無料で広告無しで使えていたのですが、一度有料プランにしてしまうとそれが継続できなくなるっぽい😢
そんなこんなでしばらく Disqus コメントフォームを閉鎖していたのですが、やはりコメントフォームはあったほうがいいかなぁということで、 Disqus の別のアカウントを作成し Disqus のコメントを再設置いたしました。
過去のコメントも移行できれば良かったのですが、どうやら Disqus から Disqus のコメント移行はサポートされていないようだったので、過去コメントは失ってしまいました。(過去にコメントいただいた方すみません🙇 データは旧アカウントには一応残っています…
Disqus側のほうで方針変わって広告が無料プランでも表示されるようになったら再び消す可能性もありますが、しばらくはこちらをご利用いただければと思います。🙏
Disqus有料プランに(トライアルでも)一度切り替えると、二度と広告無しの無料プランには戻れない。
個人のRuby on Railsプロジェクトで、従来のcircleci/rubyから次世代イメージであるところのcimg/rubyに移行してみたので紹介します。
circleci/ruby
から cimg/ruby
へ変更します。
executors:
default:
working_directory: ~/app
docker:
+ - image: circleci/ruby:2.7-node-browsers
- - image: cimg/ruby:2.7-browsers
今回の変更とあわせて、下記2つのCircleCI公式Orbも導入しました。
orbs:
ruby: circleci/ruby@1.1.2
browser-tools: circleci/browser-tools@1.1.3
上述のOrbを有効活用することで
のstepを下記のようにシンプルに記述することが可能になります。
rspec:
executor: default
steps:
- checkout
- ruby/install-deps
- browser-tools/install-chrome
- browser-tools/install-chromedriver
- run: bin/rails db:schema:load --trace
- ruby/rspec-test
rubocop の実行も同様に circleci/ruby
Orbに組み込まれており、簡単に実行できます。
rubocop:
executor: default
steps:
- checkout
- ruby/install-deps
- ruby/rubocop-check
実際に circleci/ruby
から cimg/ruby
へと移行した Pull Request の全体像としては下記のようになります。
Migrate CircleCI image from circleci/ruby to cimg/ruby by toshimaru · Pull Request
Gemfile.lock
に記述された特定バージョンのgemを簡単にインストールできる bgem コマンドを作った。
(gem名としては rubygems/rubygems にインスパイアされて bundled_gems
とした)
toshimaru/bundled_gems: Install gem specified in Gemfile.lock without bundle install.
もともとは、GitHub Actionに cache機能が来る前に作ったもの。
GitHub Action でCIしていた場合、cache機能がないと毎回 bundle install
走らせる必要があり、巨大プロジェクトだとそこがCIにおけるコストになっていた。
また CI で rubocop だけを走らせている、みたいな場合、全てのライブラリのインストールは必要なく、rubocopと一部のライブラリさえあれば十分で、それ以外のライブラリのインストールはいわば無駄なインストールとなっている。
「だったら必要なライブラリだけインストールしてCI走らせりゃいいじゃん」というのが今回のgemの着想。
$ gem install bundled_gems
これで bgem
コマンドが利用可能になる。
$ bgem install gem_name
こうすることで Gemfile.lock
内に記載されている gem_name
のバージョンを読み取ってそれをインストールしてくれる(内部的には gem install gem_name:version
を走らせている)。
例としては、bgem install rubocop
とした場合、Gemfile.lock
に記載されているバージョンの rubocop
をインストールする。
Gemfile.lock
のパースに関しては、@ledsun さんにサンプルをいただきました1。ありがとうございました。
blogged. | DependabotをGitHub公式Dependabotに移行させた - Hack Your Design! https://t.co/6Mb0XDSaSC
— toshimaru (@toshimaru_e) June 18, 2020
ただ go modules のアップデートに関しては、アップデート時に go mod tidy
を実行してくれないという問題がありました。
renovate ならオプションでやってくれるみたいなのでGoプロジェクトはこっちに乗り換えるかーhttps://t.co/qVbkb5UXlA
— toshimaru (@toshimaru_e) January 22, 2020
代替として、Renovateという go mod tidy
してくれるアップデーターを使っていました。
しかし、この度 Dependabot が go mod tidy
も実行してくれるようになっていました。
Dependabot: `go mod tidy` and `vendor` support https://t.co/x9Wwj0yuMG
— GitHub Changelog (@GHchangelog) October 19, 2020
.github/dependabot.yml
ファイルを作って、下記のように記述すればOK。
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "gomod"
directory: "/" # Location of package manifests
schedule:
interval: "weekly"
下記のPRの通り、きちんと go mod tidy
をやってくれています。
github.com/toshimaru/nyan/pull/104
Withコロナの時代においてリモートワーク、もっというとWork from Homeーーすなわち在宅ワークは当たり前のものとなりました。
そんな中、少なくない人が<最強の在宅ワーク環境>を求めて、インターネットの海を泳いだことでしょう。
その結果、見つかる情報は、
みたいなものであったりします。
ーーで、思うわけです。
「そんな金もそんなスペースも家にはねぇ❗💢」
そもそもそんな金をかけて作る在宅ワーク環境は書斎や仕事部屋であったりしますが、そんな贅沢なスペースは誰しもがあるわけではありません。既存の限られたスペースの中でいかに仕事をするためのスペースを確保していくかが重要になります。
また良いモノに高いお金を払う、それ自体は素晴らしいことですし否定はしませんが、誰しもが手元にそんなお金があるわけではありません。在りモノ・もしくは安価に環境が揃えられるのであればそれに越したことはありません。
ということで、今日は「頑張らない在宅ワーク環境」ということでまとめてみようと思います。
在りモノを活用しつつ、安価にそこそこの在宅ワーク環境を整えること1。
良い椅子・チェアがなく腰痛に悩まされている方も多くいるのでは、と思います。
つい高級チェアなんかを求めがちですが、発想を転換させて「そもそも座らない」とするのはいかがでしょうか?
僕は子ども用に購入した棚が高さとしてちょうど良かったので、そいつをちょいと拝借して雑なスタンディングデスク(?)を構築しました。
これが在宅ワーク環境のリアルだ!(子ども用に新調した棚の上にむりやり作ったスタンディング環境) pic.twitter.com/gFMsDeIp75
— toshimaru (@toshimaru_e) May 14, 2020
ただずっと立っているのも疲れるので(無理に立ち続ける必要はないと思います)、たまに座れる椅子を横に用意しておくと良いかと思います。僕は5年以上前にニトリで買った折り畳み椅子をいまだに使い続けています。
スタンディングデスクを使うことで全てが解決するわけではないようなので、体勢を変えることやストレッチを挟むなどの工夫は依然必要だと思います。
ただこれだけだと心許ないので気分にあわせて下記を使っています2。
これらそのものが腰に効くというよりは、姿勢を矯正することで腰の負担を軽減してくれる、というモノと理解しています。
良い椅子はないけど、仕事時の腰の負担を軽減したいという人にはおすすめのグッズです。
ラップトップスタンドとしては、BoYataのノートパソコンスタンドを使っています。
他の製品より多少値が張るのですが、安いスタンド買って失敗したことのある僕にとって、これは買ってよかったと思える製品でした。
抜群の安定感があることに加え高さ、角度がよい感じに調整できるのが素晴らしいです。
しっかりとしたモニタ & デスクがある方であればモニターアームを取り付けると机上のスペースがスッキリして良さそうです。
金とスペースがあればウン万円するようなウルトラワイド曲面ディスプレイがほしいところですがそんなスペースも金もありません。
MacユーザーかつiPadをお持ちであればSidecar で iPad をサブディスプレイとして使うのがオススメです。
スタンディングスペースにSidecar iPad用のスタンド買い足して幾分かワーク体験がよくなった pic.twitter.com/cv1T8akL4j
— toshimaru (@toshimaru_e) October 20, 2020
ノートパソコンと高さをあわせるため、先程紹介したラップトップスタンドに加え、Amazonで見つけた安いスマホ兼タブレットスタンドを使ってます。
現状のラップトップ付属のキーボードに満足しているなら無理に用意する必要はないと思いますが、在宅ワークが状態化して家にいることが多いのであれば、使いやすい・疲れにくいキーボードを一台常備しても良いかと思います。
僕はエンジニアなので元々手元にあったHHKBを使っています。ただ高いしエンジニア向けなので万人におすすめはしません。
何をもって使いやすいというのは人それぞれなので、ここでは特にコレ!といったおすすめキーボードは上げません。一番良いのは、実際に店頭にいって試してみて自分に最もあったものを購入することかと思います。
最近だと老舗のREALFORCEやHHKBでなくとも、1万円以下でも良いキーボードが買えるようなので、いろいろ調べてみると良いかと思います(こだわりすぎると、いわゆるキーボード沼にはまるので注意⚠️)。
リモートワークとともにリモート会議も当たり前のものとなりました。Zoom, Google Meet, Slack Callーー使っているリモート会議ツールはそれぞれでしょう。
リモート会議で音声が悪いというのは喋る側、聴く側双方にとってかなりストレスとなります。ですので仕事を円滑に進めるためにも音声にはこだわりましょう。
といっても、音声に関してはそこまでお金をかけなくていいと思っています。みなさんiPhoneは持ってますよね? じゃあ付属のApple EarPodsを使いましょう。これだけで格段に喋る側、聴く側双方が幸せになれます。
参考. テレワーク用にヘッドセットは買わなくてもいい “iPhoneのオマケ”が役に立つ - ITmedia NEWS
一方、ソフトウェアでノイズを削減するというのも手です。
おすすめはKrispです。Krispをかますだけで出力側、入力側の両方でめちゃめちゃノイズを削減してくれます。
最高のリモートミーティング体験を求めて Krisp を試用してみたけど、ホントにものっそい周囲のノイズがカットされていてすごかった
— toshimaru (@toshimaru_e) March 18, 2020
Krisp | Noise Cancelling App https://t.co/bF8bQ8q2xg
リモート戦国時代を生き抜くために Krisp を年間購読した
— toshimaru (@toshimaru_e) April 22, 2020
Beforeコロナ時代に、カフェとかからリモート会議繋ぐとめちゃめちゃ周囲のノイズが入っていたのですが、これを使うことでだいぶ改善されました。
効果的なリモート会議にするためのプラクティスから音声環境として意識すべき点をいくつか抜粋します。
在宅ワークにおいて強いネットワーク環境を用意することが大事なのは言うまでもありません。
僕の場合、しばらくGoogle Wifiを使っていたのですが、WiFiルーターを変更することでWifiの速度が劇的に向上しました。
同じデバイス、回線、時間帯と条件を合わせて2つのWi-Fiルーターで速度テスト。これだけ速度が違うのだからやっぱWi-Fiルーターにはこだわりたい。 pic.twitter.com/VLn89H1xRS
— toshimaru (@toshimaru_e) December 12, 2020
(ちなみに早い結果のほうのルーターはAtermのWG1200HP3 です)
インターネット回線に関しては家庭によっていろいろな制限がある(マンション共有回線が厳しい、高速なXXX社の回線は引けない、速度制限がある等)ので、すぐには改善できない方も多いかもしれませんが下記などで改善できそうなら検討してみてもいいかもしれません。
みなさんはどんな工夫をして在宅ワーク環境を乗り越えているでしょうか? もし「頑張らないリモート環境」のコンセプトに合致する良いアイディアがあればぜひ教えてください。😄
余談で実は今年引越ししたのですが、本記事で紹介したようなセットアップさえ整っていれば、下記のとおり引越し後の部屋の片隅に引っ越しダンボールを積み上げて、即席のスタンディング環境を用意することができました。
最強のWFH環境(2020年) pic.twitter.com/bwEdUgNUmX
— toshimaru (@toshimaru_e) November 9, 2020
最後に在宅ワークのお供として飲んでいるコーヒーグッズのおすすめを置いておきます。
]]>git 2.23 にて git switch
, git restore
というコマンドが導入されたことはみなさん既にご存知のことかと思います。
One of our favorite open source projects has a big update... Git 2.23 is here!
— GitHub (@github) August 16, 2019
Read all about the latest release and new features ✨https://t.co/fpQICF8Onc
雑に要約すると「git checkout
に機能もたせすぎてわかりにくくなっちゃったから、git switch
, git restore
でわかりやすくしたよ!」ってことだと思います。
一方、まだgit switch
に移行しきれていないという人も多くいるのではないかと思います。実際、私の周囲でも今もgit checkout
を使い続けている人をちらほら見るので、本記事ではgit switch
に移行していくためのコツを書いてみます。
switch
のaliasを設定しろ、そしてcheckout
のaliasを捨てろ
checkout
というコマンドは長ったらしいのでaliasを設定して運用していたのではないでしょうか。
僕の場合、下記のようにaliasを設定しました。
# ~/.gitconfig
[alias]
co = checkout
ただこれだと git checkout
をそのまま便利に使い続けてしまうので、思い切ってこいつを削除してしまうと良いかと思います。
もしくは下記のようにメッセージ出すとかでもOK。
# ~/.gitconfig
[alias]
co = !echo "Use git switch/restore instead!"
git switch
を使いやすくするために下記のようなaliasを設定します。
# ~/.gitconfig
[alias]
sw = switch
swc = switch -c
こうすることで checkout コマンドが下記のように生まれ変わります。
before:
$ git checkout main
after:
$ git switch main
# sw = switch を設定している場合
$ git sw main
before:
git checkout -b hoge main
after:
$ git switch -c hoge main
# sw = switch -c
g swc hoge main
git restore
に対する良いaliasは今のところ見つかっていません。
git reset
とalias的に名前空間かぶつかるので、自分の中でしっくりくる命名できていないんですよね。何かいいアイディアのお持ちの方は教えてください。
今日は作ったGitHub Actions、auto-author-assignの紹介をしたいと思います。
Pull Request(以下、PRと表記)を作成をしたとき、多くの場合そのPRの担当者(Assignee
)はそのPR作者自身になるかと思います。
その「PR担当者をPR作者にアサインする」アクションを自動化した、というのが今回作成したGitHub Actionsになります。
たくさんの人がPRを出しまくる、そんな大規模プロジェクトだとPR一覧を開いたときに
Author
に加えて)Assignee
によるフィルターができるようになるあたりが嬉しさになります。
リポジトリに .github/workflows/auto-author-assign.yml
みたいなファイルを用意して下記のように設定すればOK。
name: 'Auto Author Assign'
on:
pull_request_target:
types: [opened, reopened]
jobs:
assign-author:
runs-on: ubuntu-latest
steps:
- uses: toshimaru/auto-author-assign@v1.2.0
with:
repo-token: "$"
最初、 on: pull_request
でイベント発火させていたのですが、これだとfolkしたレポジトリからのPRで下記エラーが出てアサインが失敗します。
Error: Resource not accessible by integration
なぜなら folk したレポジトリからは secrets.GITHUB_TOKEN
にアクセスできないためです。
This event is similar to pull_request, except that it runs in the context of the base repository of the pull request (snip) This means that you can more safely make your secrets available to the workflows triggered by the pull request
via. Events that trigger workflows - GitHub Docs
ということで、 on: pull_request_target
使ってActionを起動させる必要があります。
本ActionはGitHub Actions Hackathonにも提出しました1。
]]>rubocop-rails_config v1.0.0 has been released! rubocop-rails_config now requires rubocop v1.0. https://t.co/PL2v9POeVC
— toshimaru (@toshimaru_e) October 27, 2020
もともと作ったきっかけとかの記事。
つくったやつ | Railsと同じRuboCopの設定が利用できるrubocop-rails gemを作った - Hack Your Design! https://t.co/szG0eLPetS
— toshimaru (@toshimaru_e) January 29, 2018
作ったプロジェクト名を公式に譲ってリネームした話。
Blogged. RuboCopチームにgemの名前を譲った話 - Hack Your Design! https://t.co/vumSGBK3UN
— toshimaru (@toshimaru_e) July 17, 2018
rubocopメンテナの@koicさんとは、rubocop v1.0 にあわせて rubocop-rails_config v1.0 もリリースしようぜと話していた。
今回rubocop v1.0 がリリースされたことに加えて、Rails本体でもrubocop v1.0が使用されるようになったことをきっかけとして rubocop-rails_config も v1.0 にあげることを決めた。
RuboCop 1.0 がリリースされた - koicの日記https://t.co/ii353h4ZBQ
— Koichi ITO (@koic) October 21, 2020
この記事を書いている時点で既に rubocop は v1.3 までリリースされていたので、 v1.3 までのバージョンはサポートしておいた。
]]>