Slack の絵文字をファイルに保存する方法のメモ。
まず、保存したい絵文字を入力 & 投稿し、絵文字を右クリックして「画像をコピーする」を実行する。
入力欄にて「ペースト」 & 投稿し、画像をアップロードする。
投稿された画像をダウンロードする。
以上。
AWS Lambda で Go のバイナリを実行すると「/var/task/main: /lib64/libc.so.6: version `GLIBC_2.32' not found」を出力して止まるときにやったこと。
GitHub Actions で作業ディレクトリを変更する方法。
はじめに
モノレポで開発をしていると、GitHub Actions のワークフローで作業ディレクトリを変更したり、デフォルトの作業ディレクトリを変更することが増えた。 作業ディレクトリを変更する方法、デフォルトの作業ディレクトリを変更する方法をメモしておく。
cd コマンドで作業ディレクトリを変更する
GitHub Actions では cd コマンドで作業ディレクトリを変更できる。
たとえば、こんなワークフローを実行した場合は、
name: Working Directory on: workflow_dispatch: jobs: print-working-directory: runs-on: ubuntu-latest steps: - name: step1 run: | pwd cd subdir pwd
出力結果は以下のようになる。
/path/to/repo /path/to/repo/subdir
ただし、作業ディレクトリの変更はステップ内だけにとどまり、ステップが変わると作業ディレクトリは元に戻る。
- name: step1 run: | cd subdir pwd - name: step2 run: | pwd
↑ このワークフローの実行結果は以下のようになる↓
/path/to/repo/subdir # step1 /path/to/repo # step2
working-directory を指定
working-directory を指定すると、スコープに応じてデフォルトの作業ディレクトリを変更できる。
ステップのデフォルトの作業ディレクトリを変更
ステップで working-directory を指定すると、ステップ内のデフォルトの作業ディレクトリを変更できる。
作業ディレクトリの変更はステップ内だけにとどまり、別のステップには適用されない。
- name: step1 working-directory: subdir run: | pwd - name: step2 run: | pwd
↑ このワークフローの実行結果は以下のようになる↓
/path/to/repo/subdir # step1 /path/to/repo # step2
ジョブのデフォルトの作業ディレクトリを変更
ジョブで defaults.run.working-directory を指定すると、ジョブ内のデフォルトの作業ディレクトリを変更できる。
作業ディレクトリの変更はジョブ内のすべてのステップに適用されるが、別のジョブには適用されない。
また、任意のステップで作業ディレクトリを変更しても、別のステップの開始時には working-directory で指定したデフォルトの作業ディレクトリが適用される。
name: Working Directory on: workflow_dispatch: jobs: print-working-directory: runs-on: ubuntu-latest defaults: run: working-directory: subdir steps: - name: checkout uses: actions/checkout@v3 - name: step1 run: | pwd cd .. pwd - name: step2 run: | pwd
↑ このワークフローの実行結果は以下のようになる↓
/path/to/repo/subdir # step1 /path/to/repo # step1 /path/to/repo/subdir # step2
ワークフロー全体のデフォルトの作業ディレクトリを変更
ワークフローで defaults.run.working-directory を指定すると、ワークフロー全体のデフォルトの作業ディレクトリを変更できる。
name: Working Directory on: workflow_dispatch: defaults: run: working-directory: subdir jobs: print-working-directory: runs-on: ubuntu-latest steps: - name: checkout uses: actions/checkout@v3 - name: step run: | pwd print-working-directory-2: runs-on: ubuntu-latest steps: - name: checkout uses: actions/checkout@v3 - name: step run: | pwd
↑ このワークフローの実行結果は以下のようになる↓
/path/to/repo/subdir # step1 /path/to/repo/subdir # step2
working-directory の指定は、より小さいスコープでの指定が優先される
working-directory の指定は、より小さいスコープでの指定が優先される。
- ステップとジョブのそれぞれで
working-directoryを指定した場合は、ステップでの指定が優先される - ジョブとワークフロー全体のそれぞれで
working-directoryを指定した場合は、ジョブでの指定が優先される
参考サイト
Amazon ECR のリポジトリにライフサイクルポリシーを設定する方法。
Amazon ECR リポジトリ内のイメージのライフサイクルを管理する
Amazon ECR を利用していると、リポジトリ内のイメージのライフサイクルを管理したくなることがある。 たとえば、リポジトリに登録してから xx 日以上たったイメージを削除したりだとか、リポジトリに登録しているイメージの数が xx 個以上になったら古いイメージを削除する、といった感じだ。
Amazon ECR のライフサイクルポリシーを使うと、こういったイメージのライフサイクル管理を詳細に制御できる。
このエントリーでは、「リポジトリに登録して366日 (= 約1年) が経過したイメージを削除する」ライフサイクルポリシーを設定していく。 設定方法としては、管理コンソールから設定する等いろいろな設定方法があるが、このエントリーでは AWS CLI での設定方法と CDK での設定方法を記載していく *1
AWS CLI での設定方法
AWS CLI では、aws ecr put-lifecycle-policy コマンドにて Amazon ECR のライフサイクルポリシーを設定できる。
まず、ライフサイクルポリシーを記述した JSON を用意しておく。 この JSON は、登録から 366 日以上経ったイメージをタグ付けの有無に関わりなく期限切れにする、というポリシーにしている。
$ cat policy.json
{
"rules": [
{
"rulePriority": 1,
"description": "古いイメージを削除する",
"selection": {
"tagStatus": "any",
"countType": "sinceImagePushed",
"countUnit": "days",
"countNumber": 366
},
"action": {
"type": "expire"
}
}
]
}
aws ecr put-lifecycle-policy コマンドを実行し、ライフサイクルポリシーを Amazon ECR のリポジトリに設定する。
ここでは、bob/awesome-tool というリポジトリに対してライフサイクルポリシーを設定している。
$ aws ecr put-lifecycle-policy --repository-name=bob/awesome-tool --lifecycle-policy-text="file://policy.json"
aws ecr get-lifecycle-policy コマンドにて、bob/awesome-tool というリポジトリに設定されているライフサイクルポリシーを取得すると、さきほどの JSON に記載していたとおりのライフサイクルポリシーが設定されている。
$ aws ecr get-lifecycle-policy --repository-name=bob/awesome-tool
{
"registryId": "xxxxxxxxxxxx",
"repositoryName": "bob/awesome-tool",
"lifecyclePolicyText": "{\"rules\":[{\"rulePriority\":1,\"description\":\"古いイメージを削除する\",\"selection\":{\"tagStatus\":\"any\",\"countType\":\"sinceImagePushed\",\"countUnit\":\"days\",\"countNumber\":366},\"action\":{\"type\":\"expire\"}}]}",
"lastEvaluatedAt": "1970-01-01T09:00:00+09:00"
}
CDK での設定方法
CDK では Repository を定義するときに lifecycleRules にてライフサイクルポリシーを設定できる。
new ecr.Repository(this, 'bob-awesome-tool-repository', {
repositoryName: `bob/awesome-tool`,
lifecycleRules: [
{
description: "古いイメージを削除する",
maxImageAge: cdk.Duration.days(366),
tagStatus: ecr.TagStatus.ANY,
}
]
});
参考サイト
*1:もちろん、CloudFormation 等でも設定できる
Mac の Mission Control のにわかユーザーによるベスト設定。
個人的な Mac の Mission Control のベスト設定をメモ。
Mission Control の使い方の好み等
Mission Control の仮想デスクトップの分け方は人それぞれで、いろいろなやり方があると思う。 なんとなく以下の2つの派閥が大きいような気がしているが、個人的は 1 が好みだ。*1
- プロジェクトごとに仮想デスクトップを分ける。
- 目的ごとに分ける。たとえば以下のような感じ
また、個人的な入力デバイスの好みはこんな感じで、入力デバイスとしてはキーボードのほうが好み。
- 基本的にマウスはあまり使わず、できればキーボード操作で済ませたい
- 何が何でもキーボード操作にこだわる、というほどではない
Mission Control の設定
| 項目 | 設定値 |
|---|---|
| 最新の使用状況に基づいて操作スペースを自動的に並べ替える | チェックしない |
| アプリケーションの切り替えで、アプリケーションのウインドウが開いている操作スペースに移動 | チェックしない |
| ウインドウをアプリケーションごとにグループ化 | チェックする |
| ディスプレイごとに個別の操作スペース | チェックする |
最新の使用状況に基づいて操作スペースを自動的に並べ替える
この項目については「チェックしない」がベストでありマストだ。
Mac の ユーザーガイド には以下のように記載されている。
最近使用したデスクトップにより素早くアクセスできるようにします
Mission Control の仮想デスクトップは、ショートカットキー Ctrl-<数字キー> で 仮想デスクトップ-<数字> に一発で切り替えられる。
個人的には、このショートカットキーによるデスクトップの切り替えは、便利というかあって当然くらいの機能で、もしなかったら非常に不便なくらいに感じている。
しかし、「最新の使用状況に基づいて操作スペースを自動的に並べ替える」にチェックが入っていると、macOS によって仮想デスクトップが自動的に並べ替えられるようになる。仮想デスクトップが並び替えられると、仮想デスクトップに割り当てられた番号も変わってしまうため、Ctrl-<数字キー> による仮想デスクトップ切り替えとの相性が非常に悪い。
したがって、「最新の使用状況に基づいて操作スペースを自動的に並べ替える」機能のチェックを外し、機能をオフにしておく。
アプリケーションの切り替えで、アプリケーションのウインドウが開いている操作スペースに移動
この項目についても「チェックしない」がベストでありマストだ。
Mac の ユーザーガイド には以下のように記載されている。
Spacesを使用している場合は、アプリケーションを切り替えたときに、そのアプリケーションのウインドウが開いている操作スペースまでデスクトップをスクロールします。
この機能がオンの場合、個人的には以下のようなユースケースでかなり不便さを感じる。
- デスクトップ1と2がある
- テキストエディターのウィンドウがデスクトップ1だけにある
- デスクトップ2で作業をしているとき、テキストエディターを使うためにタスクスイッチする
- テキストエディターのウィンドウはデスクトップ1にしかないため、デスクトップが2から1へ強制的に切り替わる
- デスクトップ1でテキストエディターのウィンドウを新しく開き、そのウィンドウをデスクトップ2へ移動する
したがって、「アプリケーションの切り替えで、アプリケーションのウインドウが開いている操作スペースに移動」機能のチェックを外し、機能をオフにしておく。
ウインドウをアプリケーションごとにグループ化
この項目については、チェックをしてもしなくても、どちらでもよいと思う。
個人的には、目的のウィンドウを探すために「ウィンドウのサムネイルを目で見て探す」ことはしないので、ウィンドウのサムネイルがどのように表示されているかはあまり重要ではない。 ただ、この機能をオンにおくとウィンドウがアプリケーションごとにまとまって表示されるので、各仮想デスクトップで起動しているアプリケーションをフワッと確認したいときには多少便利かな、と思う。
ディスプレイごとに個別の操作スペース
この項目については、チェックをしてもしなくても、どちらでもよいと思う。
個人的には Split View をよく使うので、この機能はオンにしている。
*1:このあたりの好みによって Mission Control の設定は180度変わると思う
Makefile のターゲットに .PHONY を付与するワンライナー。
Makefile のターゲットに .PHONY を付与するワンライナーのメモ。
個人的には Makefile はほぼタスクランナーとして使っていなくて、定義しているターゲットはすべて phony ターゲット になっている。 *1
ターゲットが phony ターゲットであることを make に伝えるには .PHONY <ターゲット> を Makefile に記述する必要があるが、ときどき .PHONY を付与し忘れることがある。
こんなときは以下のようなワンライナーを実行して、Makefile のすべてのターゲットに .PHONY を付与している。
$ cat Makefile | \
sed '/^.PHONY/d' | \
awk '/^[-_0-9a-zA-Z]+:/{s=$1; gsub(/:.*/, "", s); print ".PHONY:", s}{print $0}' > Makefile.new
3行目の awk で .PHONY をターゲットに付与している。
すでに記述されている .PHONY 2行目の sed で削除しているので、3行目の awk は .PHONY が重複するかは考慮せずに無条件に .PHONY をターゲットに付与しても問題はない。
Chatwork の有料プランでニックネームを表示する方法。
Chatwork のニックネームの表示について書く。
- プランを無料から有料に乗り換えたら、ニックネームが表示できなくなった
- 有料プランでもニックネームを表示する方法
Chatwork のニックネーム
Chatwork は To や返信機能 を使うと、相手の表示名を自動的にメッセージ中に埋め込むようになっている。 なかなか便利な機能なのだが、「表示名」は相手が「自分はこういう者ですよ」と他者に伝えるためのものなので、ビジネス用途で Chatwork を使っている人の場合、たいがいは本名が「フルネーム」もしくは「姓のみ」で設定されている。
しかしながら、自分の経験上、ビジネス用途でチャットアプリを使う場合は、メッセージ中に相手の本名をそのまま記載することは少ないと思う。 自分の場合、だいたいは以下のパターンのどれかだ。
- 名字 + 役職 (例: 「xx 部長」)
- 名字 + 「さん or 様」 (例: 「xx さん」)
- フルネーム + 「さん or 様」 (例: xx yy さん)
自分は To や返信機能で相手の表示名がメッセージ中に埋め込まれた後、「さん」や役職を相手の表示名に追加していたのだが、まあ普通に面倒くさい。
そんなときに便利なのが ニックネーム機能 だ。
ニックネーム機能で相手に別名を付けておくと、To や返信機能を使ったとき、相手の表示名ではなくニックネームをメッセージ中に埋め込むことができる。 非常に便利な機能というか、チャットアプリをビジネス用途を使うときには必須の機能だと思う。
しかし、プランを無料から有料に乗り換えたら、ニックネーム機能が意図したように動かなくなった。
プランを無料から有料に乗り換えたら、ニックネームが表示できなくなった
最初に「あれ？」と思ったのは、プランを無料から有料に乗り換えたときだった。
Chatwork が 2022/9/6 に発表した 直近40日よりも前に投稿されたメッセージが閲覧不可になる 仕様変更はネットでの評判はあまりよくないが、自分も大変不便な思いをしたため、プランを無料から有料に乗り換えた。
しかし、プランを有料に乗り換えた直後から、ニックネーム機能が意図したように動かなくなった。 具体的には、To や返信機能を使ったとき、設定しているはずのニックネームではなく表示名が埋め込まれるようになった。念のためニックネームの設定を確認すると、ちゃんと以前のまま設定が残っている。
「あれ？」と思って ニックネーム機能 の説明を読むと、以下のような記載があった。
有料プラン（ビジネスプラン、エンタープライズプラン）を利用している場合、ニックネームが表示されるのは、組織外のユーザーが入っていないグループチャットのみです。
理屈としては納得できるが、個人的には組織外の人とやり取りをするときこそ、ニックネーム機能が有効になってほしい。 チャットで取引先の人をうっかり呼び捨てしてしまうとか、絶対に避けたい……
有料プランでニックネームを表示する方法
組織外のユーザーが参加してるグループチャットでのニックネーム機能の挙動が不便すぎるので、「さすがにこの挙動は設定で変更できるはず」と思っていろいろ探してみたら、そのものずばりの活用ガイドが あった。
動作設定 > 表示設定 > 組織外ユーザーが含まれているチャットではニックネームを使用しない のチェックを外すと、To や返信機能を使ったとき、相手の表示名ではなく自分が設定しているニックネームが埋め込まれるようになった。