Slack の絵文字をファイルに保存する方法のメモ。
まず、保存したい絵文字を入力 & 投稿し、絵文字を右クリックして「画像をコピーする」を実行する。
入力欄にて「ペースト」 & 投稿し、画像をアップロードする。
投稿された画像をダウンロードする。
以上。
Slack の絵文字をファイルに保存する方法のメモ。
まず、保存したい絵文字を入力 & 投稿し、絵文字を右クリックして「画像をコピーする」を実行する。
入力欄にて「ペースト」 & 投稿し、画像をアップロードする。
投稿された画像をダウンロードする。
以上。
モノレポで開発をしていると、GitHub Actions のワークフローで作業ディレクトリを変更したり、デフォルトの作業ディレクトリを変更することが増えた。 作業ディレクトリを変更する方法、デフォルトの作業ディレクトリを変更する方法をメモしておく。
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
を指定すると、ステップ内のデフォルトの作業ディレクトリを変更できる。
作業ディレクトリの変更はステップ内だけにとどまり、別のステップには適用されない。
- 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
を指定した場合は、ジョブでの指定が優先されるAmazon ECR を利用していると、リポジトリ内のイメージのライフサイクルを管理したくなることがある。 たとえば、リポジトリに登録してから xx 日以上たったイメージを削除したりだとか、リポジトリに登録しているイメージの数が xx 個以上になったら古いイメージを削除する、といった感じだ。
Amazon ECR のライフサイクルポリシーを使うと、こういったイメージのライフサイクル管理を詳細に制御できる。
このエントリーでは、「リポジトリに登録して366日 (= 約1年) が経過したイメージを削除する」ライフサイクルポリシーを設定していく。 設定方法としては、管理コンソールから設定する等いろいろな設定方法があるが、このエントリーでは AWS CLI での設定方法と CDK での設定方法を記載していく *1
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 では 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 のベスト設定をメモ。
Mission Control の仮想デスクトップの分け方は人それぞれで、いろいろなやり方があると思う。 なんとなく以下の2つの派閥が大きいような気がしているが、個人的は 1 が好みだ。*1
また、個人的な入力デバイスの好みはこんな感じで、入力デバイスとしてはキーボードのほうが好み。
項目 | 設定値 |
---|---|
最新の使用状況に基づいて操作スペースを自動的に並べ替える | チェックしない |
アプリケーションの切り替えで、アプリケーションのウインドウが開いている操作スペースに移動 | チェックしない |
ウインドウをアプリケーションごとにグループ化 | チェックする |
ディスプレイごとに個別の操作スペース | チェックする |
この項目については「チェックしない」がベストでありマストだ。
Mac の ユーザーガイド には以下のように記載されている。
最近使用したデスクトップにより素早くアクセスできるようにします
Mission Control の仮想デスクトップは、ショートカットキー Ctrl-<数字キー>
で 仮想デスクトップ-<数字>
に一発で切り替えられる。
個人的には、このショートカットキーによるデスクトップの切り替えは、便利というかあって当然くらいの機能で、もしなかったら非常に不便なくらいに感じている。
しかし、「最新の使用状況に基づいて操作スペースを自動的に並べ替える」にチェックが入っていると、macOS によって仮想デスクトップが自動的に並べ替えられるようになる。仮想デスクトップが並び替えられると、仮想デスクトップに割り当てられた番号も変わってしまうため、Ctrl-<数字キー>
による仮想デスクトップ切り替えとの相性が非常に悪い。
したがって、「最新の使用状況に基づいて操作スペースを自動的に並べ替える」機能のチェックを外し、機能をオフにしておく。
この項目についても「チェックしない」がベストでありマストだ。
Mac の ユーザーガイド には以下のように記載されている。
Spacesを使用している場合は、アプリケーションを切り替えたときに、そのアプリケーションのウインドウが開いている操作スペースまでデスクトップをスクロールします。
この機能がオンの場合、個人的には以下のようなユースケースでかなり不便さを感じる。
したがって、「アプリケーションの切り替えで、アプリケーションのウインドウが開いている操作スペースに移動」機能のチェックを外し、機能をオフにしておく。
この項目については、チェックをしてもしなくても、どちらでもよいと思う。
個人的には、目的のウィンドウを探すために「ウィンドウのサムネイルを目で見て探す」ことはしないので、ウィンドウのサムネイルがどのように表示されているかはあまり重要ではない。 ただ、この機能をオンにおくとウィンドウがアプリケーションごとにまとまって表示されるので、各仮想デスクトップで起動しているアプリケーションをフワッと確認したいときには多少便利かな、と思う。
この項目については、チェックをしてもしなくても、どちらでもよいと思う。
個人的には Split View をよく使うので、この機能はオンにしている。
*1:このあたりの好みによって Mission Control の設定は180度変わると思う
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 は To や返信機能 を使うと、相手の表示名を自動的にメッセージ中に埋め込むようになっている。 なかなか便利な機能なのだが、「表示名」は相手が「自分はこういう者ですよ」と他者に伝えるためのものなので、ビジネス用途で Chatwork を使っている人の場合、たいがいは本名が「フルネーム」もしくは「姓のみ」で設定されている。
しかしながら、自分の経験上、ビジネス用途でチャットアプリを使う場合は、メッセージ中に相手の本名をそのまま記載することは少ないと思う。 自分の場合、だいたいは以下のパターンのどれかだ。
自分は To や返信機能で相手の表示名がメッセージ中に埋め込まれた後、「さん」や役職を相手の表示名に追加していたのだが、まあ普通に面倒くさい。
そんなときに便利なのが ニックネーム機能 だ。
ニックネーム機能で相手に別名を付けておくと、To や返信機能を使ったとき、相手の表示名ではなくニックネームをメッセージ中に埋め込むことができる。 非常に便利な機能というか、チャットアプリをビジネス用途を使うときには必須の機能だと思う。
しかし、プランを無料から有料に乗り換えたら、ニックネーム機能が意図したように動かなくなった。
最初に「あれ?」と思ったのは、プランを無料から有料に乗り換えたときだった。
Chatwork が 2022/9/6 に発表した 直近40日よりも前に投稿されたメッセージが閲覧不可になる 仕様変更はネットでの評判はあまりよくないが、自分も大変不便な思いをしたため、プランを無料から有料に乗り換えた。
しかし、プランを有料に乗り換えた直後から、ニックネーム機能が意図したように動かなくなった。 具体的には、To や返信機能を使ったとき、設定しているはずのニックネームではなく表示名が埋め込まれるようになった。念のためニックネームの設定を確認すると、ちゃんと以前のまま設定が残っている。
「あれ?」と思って ニックネーム機能 の説明を読むと、以下のような記載があった。
有料プラン(ビジネスプラン、エンタープライズプラン)を利用している場合、ニックネームが表示されるのは、組織外のユーザーが入っていないグループチャットのみです。
理屈としては納得できるが、個人的には組織外の人とやり取りをするときこそ、ニックネーム機能が有効になってほしい。 チャットで取引先の人をうっかり呼び捨てしてしまうとか、絶対に避けたい……
組織外のユーザーが参加してるグループチャットでのニックネーム機能の挙動が不便すぎるので、「さすがにこの挙動は設定で変更できるはず」と思っていろいろ探してみたら、そのものずばりの活用ガイドが あった。
動作設定 > 表示設定 > 組織外ユーザーが含まれているチャットではニックネームを使用しない
のチェックを外すと、To や返信機能を使ったとき、相手の表示名ではなく自分が設定しているニックネームが埋め込まれるようになった。