OmniAICreator/Qiita-1.07M huggingface dataset:
AWS ソリューションアーキテクト試験の勉強で意外だったこと_その1

### Volume Gateway

AWS Storage Gateway(ボリュームゲートウェイ)はオンプレ環境からAWS上のストレージサービスを使用する機能

https://aws.amazon.com/jp/storagegateway/volume/

### AWS Serverless Application Model (AWS SAM)

API Gateway, Lambda, DynamoDB など典型的なサーバレスアーキテクチャでのインフラ構築を手軽にできるサービス
ちなみにこれ単体だと CI/CD の構築は行ってくれないので AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline と連携する必要がある

https://aws.amazon.com/jp/serverless/sam/

### S3 リクエスタ払い

英語では Requester Pays と表現される。　データのダウンロードなどに関する費用はS3の所有者ではなくアクセスした人が払う仕組み。ただし保存にかかる費用は所有者が払う。沢山、S3にアクセスする企業があってそこに一部負担を請求する場合に利用する。

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/RequesterPaysBuckets.html

### PrivateLink 

インターフェースタイプのVPCエンドポイント。
ただし実態は **プライベートアドレスをもつENI** 。
VPC内のリソースが他のVPCにあるNLBに接続することができる他、幅広くAWSのリソースにアクセスすることができる。

参考

https://devlog.arksystems.co.jp/2018/05/11/4896/

### RDS でも EFS が共有できる

Amazon EFS　は EC2 と合わせて良く使われているクラウドファイルストレージ
最近RDSでも共有できるようになったらしい

https://aws.amazon.com/jp/about-aws/whats-new/2022/11/amazon-rds-oracle-amazon-elastic-file-system-integration/
S3のメタ情報を扱うなら？タグ vs メタデータ

先日、ユーザー定義のオブジェクトメタデータを使ってちょっとしたデータ（ファイルのページ数とかメモとか）とファイルを一緒にS3に保存するように実装しました。するとコードレビューで『タグという選択肢もあるよ』ということを教わったので調べてみました。

どちらも制限は厳しいので、それぞれの長所・短所を把握して使い分けましょう。

## 前提

S3のオブジェクトメタデータは2種類あります。
- システムで定義されたオブジェクトメタデータ
- ユーザー定義のオブジェクトメタデータ

この記事ではメタデータという場合は『ユーザー定義のオブジェクトメタデータ』を指します。

タグは、『システムで定義されたオブジェクトメタデータ』に含まれます。そしてS3のオブジェクトメタデータはシステム定義、ユーザー定義を合わせて8KBという制限があります。この制限を超えない範囲であれば、タグとメタデータは併用可能です。

また、S3のオブジェクトメタデータは、タグにせよメタデータにせよキーのリスト取得を効率化するような用途では使えません。もちろんすべてあるいはプレフィックスによる対象範囲のキーのリストをすべて取得して、それらをフィルターするという用途には利用できます。

## タグ

公式ドキュメントに分かりやすくまとまっています。
[タグを使用してストレージを分類する](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/object-tagging.html)

- 1 つのオブジェクトに最大 10 個のタグを関連付けることができます。オブジェクトに関連付けるタグには一意のタグキーが必要です。
- ドキュメントには『タグキーには最大 128 個の Unicode 文字、タグ値には最大 256 個の Unicode 文字を使用できます。』と書かれていますが、これは制約の一部です。日本語はそのまま保存できますが、 **`!`、`#`、`%`などたくさんの記号が保存できません。** 詳しくは後述します。
- タグキーと値は大文字と小文字が区別されます。
- aws: プレフィックスは AWS 用に限定されています。ユーザーがこれを割り当てることは出来ません。タグにこのプレフィックスが付いたタグキーがある場合、タグのキーまたは値を編集、削除することはできません。aws: プレフィックスを持つタグは、リソースあたりのタグ数の制限時には計算されません。
- タグはシステム定義のオブジェクトメタデータとして`x-amz-tagging`に格納されます。

また、メタデータと比較するための追加情報としては、Tagはいつでも追加・編集・削除出来ます。メタデータは、PUTするタイミングでのみ設定可能です。

### [追記] タグの値に使用できる文字について

タグではかなりたくさんの記号を使用できない点についてコメントで教えていただきました。ありがとうございます！

[公式ドキュメント: Tag](https://docs.aws.amazon.com/directoryservice/latest/devguide/API_Tag.html) によると、以下の正規表現にマッチする文字列を格納することができます。
```
^([\p{L}\p{Z}\p{N}_.:/=+\-@]*)$
```

つまり`\p{Po}`に含まれる`!`、`#`、`%`などの記号が使えないことを実際に確認しました。この制約は結構厳しいですね。

[`\p{Po}`にマッチする文字列一覧はこちら](https://www.fileformat.info/info/unicode/category/Po/list.htm)

## メタデータ

公式ドキュメントはこちらです。
[オブジェクトメタデータの使用](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/UsingMetadata.html)

- メタデータは、キー・値形式で2KBまでという制限があります。
- メタデータキーは`x−amz−meta−`というプレフィックスが必要です。（2KB制限に含まれます）
- メタデータキーは大文字と小文字が区別されず、設定時に小文字に変換されます。
- 重複したメタデータキーを設定すると、読み取った値はカンマ区切りで連結されます。
- 任意のUnicode文字をメタデータの値で使用できますが表示の問題を避けるために以下のようにしてください。
  - RESTを使用する場合はUS−ASCII文字（日本語を含める場合はURLエンコードします）
  - SOAPまたはブラウザベースのアップロードをPOST経由で使用する場合はUTF−8
- オブジェクトをアップロードする時にメタデータを設定できます。オブジェクトのアップロード後にはメタデータは変更できません。

## 比較表
8KB制限を考慮しつつ同時にどちらも使用可能ですが、実装工数を考えればどちらかだけ実装したいですよね。
そのために参考になりそうな制限の比較表がこちらです。

|  | タグ | メタデータ |
| --- | --- | --- |
| キーの数 | 10個 | 制限なし |
| 値に使用できる文字 | `!`、`#`、`%`などの記号はNG | 制限なし |
| 値の文字数 | 256文字 | 制限なし |
| 値の文字数の合計（英数のみ） | 2560文字 | 約2000文字 |
| 値の文字数の合計（日本語） | 2560文字 | 約200文字 |
| 設定タイミング | いつでも | PUTタイミングのみ |

メタデータの制限に「約」と付けているのはキー(`x−amz−meta−...`)も2KB制限に含まれるためです。
また日本語はURLエンコードを前提です。`"あ" => "%E3%81%82"`のように1文字が変換後は9文字となります。 

## まとめ

オブジェクトメタデータに保存できるのは小さなデータなので、ちょっとでも要件が大きくなりそうであればDynamoやRDSなどにメタ情報を保存する方が賢いと思います。

もしタグかメタデータか、どちらかで迷った場合はこの比較表を参考にしてみてください。
【22日目】discord.jsで応答速度を表すPingコマンドを作ろう

# はじめに
こんにちは、なりかくんです。
今回は、discord.jsで応答速度を表すPingコマンドを作ってみようと思います。

# WebSocket Ping
まず一つ目に計測するのがWebSocket Pingです。これは、WebSocket ClientとWebSocket Serverの間の応答速度を計測しています。
具体的にはライブラリのこの辺のコードを見れば大体わかると思います（投げやり）
https://github.com/discordjs/discord.js/blob/main/packages/discord.js/src/client/websocket/WebSocketShard.js#L643

まあ適当にイメージ図を作ったのですが、多分こんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549951/b924f896-ea57-638e-7f74-dda600122889.png)

discord.jsでは以下のようなコードで取得できます。
```js
client.ws.ping
```

# API Endpoint Ping
次にAPI Endpoint Pingを計測します。これは、今の時間からメッセージが投稿された時間を引いて計算します。

discord.jsでは以下のようなコードで取得できます。
```js
Date.now() - message.createdTimestamp
```

# スラッシュコマンドで作ってみる
では今回は、スラッシュコマンドで作成します。少し上記の説明とは違う点はあります。
以下のようなコードになりました。
```js
await interaction.reply(`WebSocket Ping: ${interaction.client.ws.ping}ms\nAPI Endpoint Ping: ...`);
let msg = await interaction.fetchReply();
await interaction.editReply(`WebSocket Ping: ${interaction.client.ws.ping}ms\nAPI Endpoint Ping: ${msg.createdTimestamp - interaction.createdTimestamp}ms`);
```
まず、最初にメッセージを送信してその送信したメッセージの時間とスラッシュコマンドで発生したinteractionを引いてAPI Endpoint Pingを出しています。

実際に実行してみるとこのようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/549951/7299acee-89cc-bfd7-5b67-9ffc845006bc.png)

今回作成したコード全体は以下のようになります。
```js:ping.js
const { SlashCommandBuilder } = require('discord.js');

module.exports = {
	data: new SlashCommandBuilder()
		.setName('ping')
		.setDescription('Pongを返します'),
	async execute(interaction) {
		await interaction.reply(`WebSocket Ping: ${interaction.client.ws.ping}ms\nAPI Endpoint Ping: ...`);
		let msg = await interaction.fetchReply();
		await interaction.editReply(`WebSocket Ping: ${interaction.client.ws.ping}ms\nAPI Endpoint Ping: ${msg.createdTimestamp - interaction.createdTimestamp}ms`);
	},
};
```

以上です、最後までお読みいただきありがとうございました。
Windows10にDocker Desktopをインストールしたので手順を残す

## 目次

- はじめに
- 環境
- 公式サイト
- 手順
- おわりに

## はじめに

Windows10にDocker Desktopをインストールしたので、自分用の備忘録も兼ねて手順を書き残します。

あまり汎用性のある内容ではないかもしれません。

## 環境

Windows10 Pro

## 公式サイト

https://www.docker.com/docker-windows

## 手順

### 公式サイトからインストーラをダウンロードする。

![WS000000.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/17a578e8-0888-e0af-166b-ebbceb96740b.jpeg)

### ダウンロードしたインストーラを実行する。

![Configuration.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/e242c5a0-eb02-e06c-d121-14177feb75b1.jpeg)

### インストールが開始される。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/a8db0083-e9c1-e83d-9a43-57d2357a33da.png)

### インストールが完了する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/863e5111-d274-8182-dcf0-2ee0516beb15.png)

### Windows再起動後、規約らしき画面が自動で立ち上がる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/e0496da3-ab13-b7de-8e44-512d9ca532c4.png)


### 先にLinux カーネルをインストールしろと言われるので、実施する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/f58a946f-a7e8-939b-1cc2-d61dee0da9cb.png)

### クリックで飛んだ先の「手順 4」を実施する。

https://docs.microsoft.com/ja-jp/windows/wsl/install-manual#step-4---download-the-linux-kernel-update-package

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/ca38e1e4-0637-9b7b-5730-72c4471f3273.png)

### インストーラを実行する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/16d46ed8-c811-f46c-3dfa-ac4ec8e532b5.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/65695864-5071-42e7-928e-e3d0a352866b.png)

### 以下の「手順 5」を実施する。

https://docs.microsoft.com/ja-jp/windows/wsl/install-manual#step-4---download-the-linux-kernel-update-package

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/00f1a7bf-04af-f03a-88f7-484c2a8c1fb1.png)

PowerShellでたたく。
```Shell
wsl --set-default-version 2
```

### Docker Desktopに戻る。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/e63f3b41-c79c-d05d-d2c1-e4cbd1ee2627.png)

### 起動処理の最中。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/3602c607-3a7c-4503-0e05-76bd1159a5a2.png)

### チュートリアルはSkipできる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/6fe0e205-0cc1-a8d8-a810-a6eca1895878.png)


### 開始された。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/5f5c2bcb-b361-9da7-6ba5-1c4abc222436.png)


### プロキシ設定を環境に合わせて変更した。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/956152/bbbc2d65-0f46-1755-0a3f-e2c1f0aef129.png)

以上。

## おわりに

特に難しいことはありませんでした。

不備、ご不明点などご指摘いただければありがたいです。

この記事がどなたかの参考になれば幸いです。
VMware ESXi ホストにCD/DVDをマウント・アンマウント・確認する方法（ESXi6.5/6.7/7.0/8.0)

# はじめに
<!-- 発端や概要を記載 -->
仕事で必要となったので調べ、6.5での記事があったが6.7や7.0や8.0でも使えるか不明であった。
6.7と7.0、8.0で動作したためかなりのレアケースかもしれないが、
仮想マシンに読ませる予定のメディアがホストからちゃんと認識するか仮想マシンが全くない状況で
どうしても実機で確認しておきたいニーズが出た場合くらいしかないかと思いますが。。。
同じような人が出てくるかもしれないし、備忘としても残しておきます。

2022/12/21 20:35追記：nestのesxiにもデータストアISOではなく、物理ホスト上のCD/DVD-ROMデバイスを見せるようにESXi仮想マシンに仮想CD/DVDドライブをつけておけば
　　　　　　　　　　　　各バージョンで同様に参照も可能でした。

# 目次
<!-- タイトルとアンカー名を編集 -->
1. [マウント方法](#Chapter1)
1. [アンマウント方法](#Chapter2)
1. [参考文献](#reference)

<!-- 各チャプター -->
<a id="#Chapter1"></a>
# マウント方法
```言語名:ESXiホストにrootでssh接続した状態で以下実施
①iso9660モジュールをロード
# vmkload_mod iso9660
Module iso9660 loaded successfully

②CD/DVD ドライブのパスを確認
# esxcfg-mpath -b | grep -i cd
mpx.vmhba64:C0:T0:L0 : Local NECVMWar CD-ROM (mpx.vmhba64:C0:T0:L0)

③マウント
# vsish -e set /vmkModules/iso9660/mount ＜②で確認したデバイス名>
例: vsish -e set /vmkModules/iso9660/mount mpx.vmhba64:C0:T0:L0

④/vmfs/volumes ディレクトリ配下にマウントされていることを確認
# ls -l /vmfs/volumes/
total 6144
～ 中略 ～
lrwxr-xr-x 1 root root 20 Sep 7 13:57 RHEL-7.3 Server.x86_64 -> mpx.vmhba64:C0:T0:L0
～ 省略 ～
```

<a id="#Chapter2"></a>
# アンマウント方法
```言語名:ESXiホストにrootでssh接続した状態で以下実施
①不要になったらアンマウント
# vsish -e set /vmkModules/iso9660/umount ＜②で確認したデバイス名>
例:vsish -e set /vmkModules/iso9660/umount mpx.vmhba64:C0:T0:L0
※コマンドが似ているけどマウントするときは mount だったけど、アンマウントのときは umount

②iso9660モジュールをアンロード
# vmkload_mod -u iso9660
Module iso9660 successfully unloaded
```
<a id="#reference"></a>
# 参考文献
- [ESXi 6.5 でCD/DVDをマウントする - Qiita ](https://qiita.com/negi_c/items/8a5c801e207d7ddebff8)
保守的な職場でチーム内にひっそりとMattermostを導入した話

## 目次

- はじめに
- 背景
- 経緯
- ゴール
- 環境
- Docker導入
- Mattermost導入
- 導入後
- 移行
- おわりに

## はじめに

職場にチャットツールを導入したかったのですが、職場の文化が保守的であること等の理由で大々的にはやりにくい状況でした。

いろんな制約をかいくぐり、オンプレかつ無料版、しかもチーム内限定で使用できるようになりました。

似たような境遇の方々のご参考になればと思います。

## 背景

- レガシーにどっぷりな感じの環境（※）で、少しでも時代に追いついていく方法はないかと個人的に模索していた。
- 自分のスキルアップのため未経験のことをやりたかった。
- 時代の変化に対応しようという雰囲気をチーム内に作りたかった。

※テストコードなし、.Net Framework VB.Net/C#、SVN、Oracle

## 経緯

手始めとして、成果物に直接影響しないチャットツールを提案することにしました。

しかし、保守的な職場なので、有料版やクラウド版は調整が大変そうです。

そこで、Slackライクと言われているMattermostの無料かつオンプレ版を選択。
チーム内だけでひっそりと使用するだけ、という条件で了承を得ました。

良い機会なので~~勝手に~~DockerとGitも一緒に導入することにしました。

## ゴール

メンバーに「便利だね」って思ってもらえたら大成功です。

## 環境

サーバ：Windows10 Pro（サーバマシンではなく個人端末）

## Docker導入

手順を別の記事にしました。

[Windows10にDocker Desktopをインストールしたので手順を残す](https://qiita.com/ippaiattena/items/12b9db257322e09d335e)

## Mattermost導入

後日別の記事にします。

## 導入後

まずはお試しということで、自端末にインストールしてチームに使ってもらいました。

基本的に出社の職場なのですが、導入とほぼ同時期にある事件が起きました。
なんと、**リーダーがコロナの濃厚接触者として自宅待機**になってしまったのです。
そこで出社組とのコミュニケーションに**Mattermostが大活躍**。
リーダーから「とても便利で助かった」と評価してもらえました。

導入成功と評価して良いと思います。

## 移行

恒久的に使用されそうなので、自端末から別の場所に移行することになりました。
しかし、サーバマシンをいじるとなるとこれまた大事（おおごと）になります。
結局、あまり使われていないメンバー保有の端末を使用することに。

**移行元端末（Windows10） ⇒ 移行先端末（Windows10）**

ということは、移行したところで状況はほとんど変わりません。
が、私以上にモチベ爆上がりしたリーダーの「移行できることを確認しておきたい」という圧倒的熱意に押され、タジタジになりつつ実施しました。

その後、隣の席なのに雑談もMattermostを使ったりして、チャット依存が心配になる日々が続きました。

## おわりに

レガシーで保守的な職場にいるとスキルアップの妨げになると思っていました。
確かに限界はあるものの、自分次第の部分も相当大きいことが分かりました。
チームの意識に働きかけるつもりが、**自分の意識が一番変わった**かもしれません。

提案を前向きに検討してもらえる職場環境にも感謝しています。

ちなみに、最近リーダーは「忙しいとき煩わしいから」とMattermost通知を切り、「気づかないから直接話しかけて」と言っています。
全員出社してるからそれでもいいけど、あの熱意はどこへ？(笑)

この記事が誰かのお役に立てば幸いです。
モデリング勉強 〜ギターをモデリング〜

クラス、メソッドの設計をしている中で下記のようなことで頭をよく悩ませます。
+ 業務とユースケースは紐づいているのか
+ 意味不明な用語を使ってないか
+ ユースケースを実現するためのクラス作り方、分け方は合っているのか
+ 責務が他のクラス、メソッドに漏れ出てないか
などなど

モデリング経験の少なさで詰まることが多いため個人的に日常生活にあるものでモデリングの勉強をしています。その一部を紹介します。

## ルール
なるべく一般的な用語やその物に精通している人たちが使っている用語でまとめていくこと。
使う側の用語とシステムが紐づかなくなるから、ちゃんとした用語を使用するように心がけてます。

## 手順
決まりきった手順はないですが、自分が整理するときの手順を軽く紹介。
1. ユースケースを洗い出す
1. モデリング対象の要素を洗い出す
1. 状態遷移があるか洗い出す
1. 要素と状態遷移をモデルで表現する
1. 実装してみる -> 長くなるのでここは別途、、、m(_ _)m

## お題
アコースティックギター

https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B3%E3%83%BC%E3%82%B9%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF%E3%83%BB%E3%82%AE%E3%82%BF%E3%83%BC

## ユースケースを洗い出す
+ 弦を抑える
  + １つの弦を抑える（単音）
  + 複数の弦を同時に抑える（コード）
+ 弦を鳴らす
  + ダウンストローク
  + アップストローク

## 要素を洗い出す
+ 指板
+ フレット
+ 弦
+ 音階
  + フレットと弦のペアで音階が決まる
  + 複数のフレットと弦のペアで音階が決まる

## 状態遷移があるか洗い出す
+ 出音: true/falseでいいかも
```mermaid
stateDiagram
  [*] --> 出音中: 音を出す
  出音中 --> [*]: 音を止める
```

## モデル
```mermaid
classDiagram
  class ギター {
    list[音階]
    出音
    \指板 単音(押さえるポイント)
    \指板 コード(list 押さえるポイント)
    \音階 ダウンストローク(指板) 
    \音階 アップストローク(指板) 
    void 音を止める()
  }

  class 音階 {
    指板
  }

  class 指板 {
    list[押さえるポイント]
  }

  class 押さえるポイント{
    フレット
    弦
  }

  ギター --> 音階
  音階 --> 指板
  指板 --> 押さえるポイント
```

## 今後
この後モデリングした結果を実装していきます。
実装した結果、うまく表現できてない要素やユースケースが現れてくると思います。
その時は今のモデルに何か誤りがある可能性があるため、モデルの見直しをかけて実装に再度落とし込んでいきます。
そのサイクルを繰り返すことによりモデルが洗練されてくるはずです。

## まとめ
モデリングについて書いてみました。
モデルの見直しを行いリファクタリングをし続けることは実プロジェクトではなかなか難しいかもしれません。（すぐリリースできる環境になかったり、改善に時間が割けなかったり、、、）

でも、それをすることで自分達が作っているものをよく知れたり、バグの危険がある箇所を対処できたり、変更に強くなったりメリットはたくさんあります。

自分としてはこういう活動を繰り返すことで自分のモデリング力を上げていけたら楽しいと思うので、一つの勉強方法として取り組んでみてはいかがでしょうか。

ここまで読んでいただいてありがとうございましたm(_ _)m
[Delphi][小ネタ] Windows / macOS / iOS / Android で等幅フォントを取得する

# 等幅フォントを取得する

コードはもちろんのこと情報を表示するときとかに等幅フォントが必要になる事があります。
各プラットフォーム毎にフォント名が異なるのでめんどい！のと毎回調べてるので、メソッドにまとめてみました。

コードは以下の通り。

```delphi
(*
 * Font Utility
 *
 * PLATFORMS
 *   Windows / macOS / iOS / Android
 *
 * LICENSE
 *   Copyright (c) 2022 HOSOKAWA Jun
 *   Released under the MIT license
 *   http://opensource.org/licenses/mit-license.php
 *
 * HISTROY
 *   2022/12/19 Version 1.0.0  First Release
 *
 * Programmed by HOSOKAWA Jun (twitter: @pik)
 *)

unit PK.Utils.Font;

interface

type
  TFontUtils = record
  public
    class function GetMonospaceFont: String; static;
  end;

implementation

{ TFontUtils }

class function TFontUtils.GetMonospaceFont: String;
begin
  {$IFDEF MSWINDOWS}
    Result := 'MS Gothic'; // 英字だけで良いなら Consolas
  {$ENDIF}
  {$IFDEF OSX}
    Result := 'Osaka-mono'; // 英字だけで良いなら Menlo
  {$ENDIF}
  {$IFDEF iOS}
    Result := 'Courier'
  {$ENDIF}
  {$IFDEF Android}
    Result := 'monospace';
  {$ENDIF}
end;

end.
```

# 使い方

こんな感じでいけます。
便利～

```delphi
procedure TForm1.FormCreate(Sender: TObject);
begin
  Memo1.TextSettings.Font.Family := TFontUtils.GetMonospaceFont;
end;
```

# 補足
iOS は↓こんな感じでシステムのフォントを等幅フォントとして取得できるらしいです。
```swift:Swiftで記述
UIFont.monospacedDigitSystemFont(ofSize: 16, weight: .medium)
```
htmlとcssだけで編成表を作る

## はじめに
みなさま、編成表というものはご存知でしょうか。
鉄道車両の組成を表した図を、編成表と言います。
今回は、そんな編成表をHTMLとCSSだけで作ります。

## コード
```html
<div class="hensei">
  <div class="corner_box01">1号車<br>1001</div><div class="renketsu"><br>－</div>
  <div class="corner_box00">2号車<br>1002</div><div class="renketsu"><br>－</div>
  <div class="corner_box00">3号車<br>1003</div><div class="renketsu"><br>－</div>
  <div class="corner_box00">4号車<br>1004</div><div class="renketsu"><br>－</div>
  <div class="corner_box02">5号車<br>1005</div>
</div>
```
```css
.hensei{
  display:flex;
}
.corner_box01 {
  background: rgba(247, 17, 55, 0.8);
  width: 100px;
  height: 50px;
  position: relative;
}
.corner_box01:before {
    height: 0;
    display: block;
    position: absolute;
    left: 2px;
    content: "";
    border-top: solid 30px transparent;
    border-right: solid 30px transparent;
    top: 2px;
}
.corner_box01:after {
    height: 0;
    display: block;
    position: absolute;
    left: -3px;
    content: "";
    border-top: solid 30px #fff;
    border-right: solid 30px transparent;
    top: -3px;
    z-index: 2;
}

.corner_box02 {
  background: rgba(247, 17, 55, 0.8);
  width: 100px;
  height: 50px;
  position: relative;
}
.corner_box02:before {
    height: 0;
    display: block;
    position: absolute;
    right: -3px;
    content: "";
    border-top: solid 30px #fff;
    border-left: solid 30px transparent;
    top: -3px;
    z-index: 2;
}
.corner_box02:after {
    height: 0;
    display: block;
    position: absolute;
    right: -2px;
    content: "";
    border-top: solid 30px transparent;
    border-left: solid 30px transparent;
    top: -2px;
}

.corner_box00 {
  background: rgba(247, 17, 55, 0.8);
  width: 100px;
  height: 50px;
  position: relative;
}

.hensei div{
  text-align:center;
}

.hensei div:first-child{
  margin-left:0px;
}
```

## 終わりに
次回はこれを生成するプラグインでも作ろうかな.
enebularでnode-red その4

# 概要
enebularでnode-redやってみる。
クラウド実行環境を、やってみた。

# 手順1

フローを書く

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/1760885a-a0eb-f76c-36e4-9b6d36aa5937.png)


# 手順2

アセット画面の「クラウド実行環境」をクリック
「＋」をクリック
「OK」をクリック
１，２分待つ

設定タグ　＞　設定を編集する
HTTP トリガーを「ON」
パスを入力　（ユニークなパス）
https://lcdp003.enebular.com/new01/

「保存」をクリック

実行環境デプロイ
デプロイ対象のフローを選択して、実行

# 手順3

ブラウザで、https://lcdp003.enebular.com/new01/を、開く。
null表示となる。

# 対処

フローを一から書く。
動作した。


以上。
Azure Pipelines にコードカバレッジを表示させてみた

# はじめに
[LIGTHzアドベントカレンダー](https://qiita.com/advent-calendar/2022/lightz) 2022の21日目の記事です。

Microsoftの公式ドキュメントの記事をもとに実装してみました。
- [PublishCodeCoverageResults@1 - コード カバレッジの結果 v1 タスクを発行する](https://learn.microsoft.com/ja-jp/azure/devops/pipelines/tasks/reference/publish-code-coverage-results-v1?source=recommendations&view=azure-pipelines)
- [コード カバレッジの結果を確認する](https://learn.microsoft.com/ja-jp/azure/devops/pipelines/test/review-code-coverage-results?view=azure-devops)

# コードカバレッジを確認できると何がいいのか
>コード カバレッジは、単体テストなどのテストによって実際にテストされているプロジェクトのコードの割合を判断するのに役立ちます。 コードの変更に対する信頼度を高め、バグから効果的に保護するには、コードの大部分をテストで実行するか、カバーする必要があります。
コード カバレッジの結果を確認すると、テストでカバーされていないコード パスを特定するのに役立ちます。 この情報は、テスト負債を減らすことで、時間の経過と伴うテスト資料を改善するために重要です。

※公式ドキュメントより



# Azure Pipelines に表示する方法

以下のコードを azure-pipeline.yml の steps の後に記述します。

```azure-pipelines.yml
steps:
- task: PublishCodeCoverageResults@1
      inputs:
        # 使用するコードカバレッジツール
        # 使用できる値: Cobertura、JaCoCo 既定値: JaCoCo
        codeCoverageTool: 'JaCoCo' 

        # 行、メソッド、クラス カバレッジなどのコード カバレッジ統計を含むサマリー
        # ファイルのパスを指定する
        summaryFileLocation: '$(System.DefaultWorkingDirectory)/**/coverage.
```

### 結果の表示
コードカバレッジは、パイプライン実行の [Summary] タブの [Tests and coverage] で確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3064377/39e2fae4-904d-172d-79f8-a3ab3e9d7238.png)
また、結果は [Summary] タブの横に [Code Coverage] タブが表示されるようになるので、 [Code Coverage]　タブから表示およびダウンロードできます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3064377/0ecdd65b-623a-dbf2-518c-8b7769b0e146.png)
セーフィーのエンジニア組織と課題について

この記事は[Safie Engineers’ Blog! Advent Calendar](https://qiita.com/advent-calendar/2022/safie)24日目の記事です。

セーフィー株式会社 VPoEの谷口元信です。
2019年4月からセーフィーに入社して3年半くらいになりますが、2022年4月からVPoEとしてエンジニア組織の課題に取り組んでいます。

この記事ではセーフィーのエンジニア組織と課題について紹介したいと思います。

## エンジニア組織

私がいる3年半の間で何度か組織変更がありましたが、現在のセーフィーのエンジニア組織は職能型組織となっています。

<img width="75%" height="75%" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411590/c1f585c0-a5d6-db88-ee94-48d64709c682.png">

組織図を見てわかる通り、グループ単位で技術領域や業務範囲が明確になっています。
それぞれのグループで技術領域を深める経験が出来ますし、自分が経験していない、もしくは経験の浅い技術領域への挑戦をする事もしやすい環境となっています。

と書きましたが、現在は積極的に手上げして取り組もうとする人しか幅広い経験を積む事が出来ないという課題もあります。

では、セーフィーのエンジニア組織の課題とは何かをお話しします。

## エンジニア組織の課題

現在のエンジニア組織の課題ですが、大きく分けて４つあります。

* 技術領域の異なるグループでの開発スキルを身に着けたい
* セーフィーでのエンジニアとしてのキャリアパスを明確にしたい
* プロダクト開発を効率よく進めたい
* エンジニア採用を強化して各人の業務量を適切にしたい

多かれ少なかれ、どのエンジニア組織も上記の課題を抱えているというのが私の認識です。
その中でも今回は「技術領域の異なるグループでの開発スキルを身に着けたい」について話をしたいと思います。

## 技術領域の異なるグループでの開発スキルを身に着けたい

私自身は20代から30代にかけて、ほぼフルスタックエンジニアとして開発に取り組んできました。
プログラム言語もJavaから始まり、Perl、PHP、VB.net、python、Scala、C++、Javascript、Typescript等プロジェクトによって様々な言語も経験してきました。

一つの技術領域や一つのプログラム言語を深堀していく事もエンジニアのキャリアとしては大事ですが、現在のプロダクト開発においては技術領域間での相互理解があった上でグループ間で連携して開発を進める事も同時に重要となってきています。

過去のブログで[「セーフィーにはどんな種類のエンジニアがいるの」](https://engineers.safie.link/entry/2022/01/27/%E3%82%BB%E3%83%BC%E3%83%95%E3%82%A3%E3%83%BC%E3%81%AB%E3%81%AF%E3%81%A9%E3%82%93%E3%81%AA%E7%A8%AE%E9%A1%9E%E3%81%AE%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%8C%E3%81%84%E3%82%8B%E3%81%AE)という記事がありますが、こちらで紹介されている図を見てわかる通り、カメラ、サーバ、スマホ、PC間で様々なデータのやり取りを効率よく行う事がサービスレベルを高めるために必須となります。

<img width="75%" height="75%" src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/safie/20220118/20220118113209.jpg">

他社でハードウェア、サーバ、アプリケーションの開発をそれなりに横断して経験してきた人であれば、関連する技術領域で何をどう実装していくかをある程度イメージした上でインタフェースについて話し合いながら設計、実装していく事がやりやすいと思います。
しかし、その経験がない中で業務を進める事はハードルが少し高いかなと私は感じています。

また、

* 1つのプロダクトを横断して開発出来るスキルを身に着けた上で自分の深堀をしたい技術領域を見つけていく
* それぞれの技術領域に入り込んで理解を深めてプロダクトマネージャを目指す

という志向のエンジニアも一定数いるので、技術領域の幅を広げやすい環境を作った上でそういったキャリアを目指す人に対してスキルを高めていけるようにする必要があります。

そのためには各技術領域に対するオンボーディングをしやすくする事がミッションとなってきます。

# オンボーディングの強化

入社後のエンジニアがプロジェクトや開発に入り込みやすくなるようにするために、オンボーディング資料の作成、更新とサポート体制を作り上げる必要があります。

ただ、こちらに関しては入社して数年経っているエンジニア向けにも同様に必要となってきます。

オンボーディング資料の作成についてはグループ毎にあったりなかったりした所もあり、2022年上期は各グループでオンボーディング資料の作成と更新を行ってもらった事でセーフィーで自分の携わっていない技術領域に入り込むために必要な要素に触れやすくはなりました。

また、2022年下期はフロントエンドグループからサーバグループの開発、イメージンググループからデバイスグループの開発に入り込みながらオンボーディングで必要な要素を再確認しながら改善していく取り組みも始めました。

セーフィーで働いているエンジニアの協力を受けながらエンジニア一人一人が成長していきやすいように、オンボーディングの強化に関しては来年度以降も継続して取り組んでいこうと思います。

## さいごに

今回はエンジニア組織の課題について１つをピックアップして記事にさせてもらいましたが、

* 他の課題について気になる！
* セーフィーではどのような経験が出来るか

等、セーフィーに興味を持ってもらえましたら、ぜひご連絡いただければと思います。
【Kotlin】 わからなかったCoroutineScopeを、なるべく短く理解する

# CoroutineScopeをざっくりと説明
コルーチンを起動するには、どのスコープで起動するかを指定する必要があります。このスコープこそがCoroutineScopeです。

# コルーチンビルダーはCoroutineScopeの拡張関数

コルーチンを起動するにはコルーチンビルダーを使用します。このコルーチンビルダーには`launch()`や`async()`といった関数が存在しますが、これらはすべて**CoroutineScopeの拡張関数**として定義されています。

そしてすべてのsuspend関数はコルーチンで実行しないといけないので、普段ViewModelでsuspend関数を呼び出し、UiStateを更新する場合は次のように書いたりします。

```kotlin
viewModelScope.launch {
    val result = repository.getActivities()
    viewModelState.update {
        it.copy(
            ...
        )
    }
}
```

# スレッドとかwithContextって何？

コルーチン内で、特定の処理を実行するときにコルーチンが起動されたときに指定されたスレッドとは別のスレッドに切り替えて処理を実行したい場合にはwithContext()を使用します。

```kotlin
viewModelScope.launch {
    ...
		withContext(Dispatchers.IO) {
        ...
    }
}
```

## コルーチンで使用できるスレッドの種類

Kotlinのコルーチンでは、ディスパッチャを使ってコルーチンの実行時に使いたいスレッドを指定します。

以下では、主な3つのディスパッチャを紹介します。

### Dispatachers.Main

`Dispatachers.Main`はメインスレッドを表します。メインスレッドで、手早くsuspend関数を呼び出したりUIのオペレーションを実行したい場合にのみ便利です。

### Dispatchers.IO

`Dispatachers.IO`では、デフォルトで64スレッド存在するため、最大64スレッドの並列実行を行うことが可能となります。

しかし、名前の通り、IOがブロックされることにより多くの待ち時間が発生する可能性があります。

### Dispatachers.Default

`Dispatachers.Default`は、メインスレッドの外部で、負荷の高い処理や、一極集中型のタスクを実行したい場合に向いています。しかし、実行端末のCPUのコア数の数のスレッドしか起動することはできないため注意が必要です。ただ、スリープはほとんど発生しないため、そういったメリットもあります。

# 参考にした記事

https://developer.android.com/kotlin/coroutines/coroutines-adv?hl=ja#main-safety

https://developer.android.com/kotlin/coroutines?hl=ja

https://android.suzu-sd.com/2022/02/coroutine_withcontext/

https://stackoverflow.com/questions/59039991/difference-between-usage-of-dispatcher-io-and-default

https://qiita.com/offwhite/items/94540e7cc3b330507c9c
Azure ADプライマリ更新トークンについてまとめてみた

## はじめに
Azure ADを利用していると一定期間後に認証画面が表示され、多少面倒に感じます。
今回は、利用者のPCの裏側で代わりに処理してくれるプライマリ更新トークンについて
まとめてみました。

## 登場人物紹介
##### (1) プライマリ更新トークン(PRT)
ざっくり言うと、マスターキーのようなものです。これがあれば、マスターキーに対応しているどのデスクトップアプリ/ブラウザでも認証の役割を果たします。
英語では、「Primary Refresh Token」なので、頭文字を取って、PRTと略されることが多いです。以降は、プライマリ更新トークンをPRTと記載します。

##### (2) Cloud APプラグイン/Web Account Manager/Web Account Managerプラグイン
ざっくり言うと、プライマリ更新トークンを処理する役割のプログラムの名称です。
デスクトップアプリ、ブラウザがこのプログラムと連携できる仕組みがあり、PRTが利用者PC内に存在すれば、利用する際に、認証画面が求められません。
![図3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/237637/532bc8e8-46c2-de24-3d65-a7e0093da2e7.png)

一方で、連携する仕組みがない場合は、認証画面が求められることがあります。
![図4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/237637/4bd27db3-a442-364f-81e5-d81444878485.png)


デスクトップアプリ利用時には、Web Account Managerを利用するのですが、略して、WAMと言います。以降は、Web Account ManagerをWAMと記載します。

## プライマリ更新トークンの利用条件
以下の条件でAzure ADにデバイス登録されていれば、利用できるようです。
(1) Azure AD参加もしくはハイブリッド Azure AD 参加済み
(2) Azure AD登録

ただし、(2) Azure AD登録の場合は特定の利用条件を満たさないとプライマリ更新トークンが失効するので、注意が必要です。詳しくは、「PRTの更新」章で解説します。

## 利用シーン1 ブラウザ利用
CloudAPに対応しているブラウザが利用できます。
Microsoft社の公式ドキュメントでは、Edge、Google Chrome、Firefoxが紹介されています。
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/concept-primary-refresh-token#how-is-a-prt-used

##### 落とし穴
上記の公式ドキュメントにも載っているのですが、Google Chrome、Firefoxの場合は
追加構成が必要です。

- Google Chromeの場合: Windows 10 Accounts または Office Online アドオンが必要です。
- Firefoxの場合: ブラウザ設定で、[プライバシーとセキュリティ]>[Windowsのシングルサインオンを許可する]をONにする必要があります。

## 利用シーン2 デスクトップアプリ利用
WAM対応のアプリケーションが利用できます。

##### 落とし穴
WAM対応アプリの一覧が見つからなかったので、アプリケーション毎に対応しているかの確認が必要となりました。
非対応の場合は、開発元に対応を依頼するか、諦めてAzure AD認証を行いましょう。
以下のサイトより、Microsoft 365アプリ(Power Point等のOfficeアプリ)は対応していることは確認できました。
https://learn.microsoft.com/ja-jp/microsoft-365/troubleshoot/administration/disabling-adal-wam-not-recommended#more-information

## PRTの更新について
PRTの有効期限は14日後であり、更新処理がなければ、失効します。
更新パターンとしては、(1) Azure AD登録の場合と(2) Azure AD 参加の場合があります。

##### (1) Azure AD登録の場合
WAM対応のアプリケーションの認証中にのみ、 PRT は発行および更新されます。 ブラウザー利用時には、PRTは発行、更新はされません。
そのため、WAM対応のアプリケーションを利用していなければ、PRTは14日後に失効し、ブラウザでは認証画面が定期的に表示されるようになります。
※デスクトップアプリは更新トークンがあるため、認証画面は求められる可能性は低いです。
詳しい仕組みを知りたい方は、「トークンの認証フローを詳しく知りたい方は」章のサイトの内容をご確認下さい。

Azure AD登録デバイスでプライマリ更新トークンを利用するには、利用者が日常的にWAM対応のアプリケーションを利用する環境が必要です。

##### (2) Azure AD 参加の場合
上記に加え、Windows サインイン中、CloudAP プラグインが 4 時間ごとに PRT を更新します。 
そのため、長期休暇等で、14日以上PCにサインインしないことがなければ失効しません。

## トークンの認証フローを詳しく知りたい方は

今回は、プライマリ更新トークンに絞って、解説しました。
その他の主なAzure ADトークンとしては、以下があります。
(1)  ブラウザ利用時に使用するセッショントークン
(2) デスクトップアプリケーション利用時に使用するアクセストークン/更新トークン

こちらを学習する際は下記サイトがおすすめです。
https://github.com/yusukekodama/PMActivities/blob/master/Webinar/Schedule.md

- Session 5-6 マイクロソフトサポート部門が送る 「Azure AD 認証情報のキャッシュを解き明かす」
- Season 6-2  Azure AD 認証情報のキャッシュを解き明かす 第 2 第 モバイルのシナリオ (Guest Speaker: Customer Support Services)

非常に分かりやすいYoutubeの解説とパワーポイント資料があり、こちらを反復して学習すれば、Azure ADの認証フローを習得できると思います。
【修正済？】MRTK3でRayを利用したボタン操作ができない

MRTK3の学習を行いながら作品を作っていた際
RayでのButton操作（Canvas操作）ができないことに気が付いたので調べてみました。

※ハンドトラッキングで直接ボタンを押す分には操作可能

## 試したこと
・Ray Interactor（csファイル）の設置→動作せず

・InputSystemの問題かと思い、EventSystemの旧バージョン、新バージョンをそれぞれ設置
　→動作せず

・Controller制御だったため、別のcsファイルで操作できるのかと思い検索
　→該当するcsファイルが見当たらず

## 結果
意図的に削除していたそうです（悲しい

■キャンバスのサンプル シーンでは、RayInteractor を使用した描画が許可されなくなりました
https://github.com/microsoft/MixedRealityToolkit-Unity/issues/10886

ボタン操作は直接押す形で実装するしかなさそうです...

## 2023.1.02追記
新しく環境構築をしていたところ、問題なく動作することが確認できました。
MRTKが用意してくれているボタンの種類を変更しただけなのですが、もしかしたら
ボタンによっては反応しないのかもしれません。
詳細はまた調査していこうと思います。
Amazon Managed Grafana で30日間無料のトライアルライセンスを購入する


[Amazon Managed Grafana](https://aws.amazon.com/jp/grafana/)で30日間無料のトライアルライセンスの購入でハマったので共有します。

## 公式ドキュメントの記載
[Upgrade a workspace to Grafana Enterprise](https://docs.aws.amazon.com/ja_jp/grafana/latest/userguide/upgrade-to-Grafana-Enterprise.html)に次の記載があります。

```
Note
The 30-day free trial option is only available in the All workspaces menu. The Grafana Enterprise license menu in the side bar does not have the 30-day free trial option.
```

## 具体的にどこのことかAWSマネジメントコンソールを確認する

AWSのマネジメントコンソールを見ると左側に```Grafana Enterprise license```と記載があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140658/8c3a5dff-5353-7f84-6af4-416161149e7d.png)
ここからGrafana Enterprise Licenseを購入した場合は30日間のトライアルオプションは選択できません。有償版(2022/12/21日時点では月3500ドル)を購入することになります。

30日間無料のトライアルライセンスを購入するにはAll workspacesからAmazon Managed GrafanaのWorkspacesを作成後購入できるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140658/1dbc7449-868d-54b5-b6be-9614bc4900f8.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140658/60580629-b4b7-7748-ed83-ed14c05cf7db.png)

## 誤って有償版を買ってしまった場合にどうすればいいのか？
これはAWSのサポートとGrafana側双方にお願いして返金が可能かどうか確認する必要があります。
AWSのサポートだけでは返金の判断はできず、Grafana側のサポートから返金の許可を取り付ける必要があります。
Grafana側で返金の許可を取り、返金リクエストをGrafana側からAWS側に発行してもらうことでAWS側でも返金処理が可能になるということでした。
Power Automateで、Power BI データフローの更新をトリガーにPower BI データセットを更新

# はじめに
　Power BI サービスには、データソースに接続しデータ分析に適した形にクエリで整形する**データフロー**、可視化用のデータモデルである**データセット**があります。Power BI サービス上でこれらの更新をスケジュール化して自動で行う場合、データフローを更新してから、データセットを更新し... とやっていました。
　この方法だとスケジュール更新の設定が30分単位で設定されるため、データフローの更新が終わってから約30分ほど待つことになります。
　今回の対応により、データフロー完了をトリガーにより、Power Automateのクラウドフローが発動し、データセットを更新するアクションを実行するので、**一連の処理に待ち時間のムダがなくなり、処理時間が大幅に短縮**されます。

### Before
　概要図で書くと以下です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/c250403d-544d-9259-7bd6-03bc49f820bf.png)

　こちらをPower Automateのクラウドフローを使い、データフローの更新が完了したことをトリガーにデータセットを更新するようにしました。

## 公式ドキュメント
　公式のLearn / ドキュメント（Docs）はこちらです。

https://learn.microsoft.com/ja-jp/power-query/dataflows/trigger-dataflows-and-power-bi-dataset-sequentially?WT.mc_id=DP-MVP-5004418

https://learn.microsoft.com/en-us/power-query/dataflows/trigger-dataflows-and-power-bi-dataset-sequentially?WT.mc_id=DP-MVP-5004418

## 概要図等
　Power BIのワークスペースの中身はこちら
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/7603affc-790c-c1a1-6a98-4bc74f24fcab.png)
　全体を概要図にするとこんな感じです

### After
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/e1f3044f-6478-baed-ac49-9fafbea03460.png)

## Power Automateのフロー
　トリガーとアクションの中身はこちらです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/75b670c9-5fad-0c0c-d883-60dbe878e9ff.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/2a7c0f4d-8617-08e2-32c8-c7c93738f707.png)

　アクションを追加して更新が終わったら、Teamsにメッセージを送信するなどもできますね。

### トリガー（データフローのスケジュール更新）
　こちらはPower BI サービスでスケジュール設定して実行するものです。設定時間後、（即座ではなく順次）実行されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/94c3ff97-bcce-2482-45b4-83243cc3917f.png)

　今回は9:00に設定していたものが、9:01に実行され、約1分で終わりました。データソースとなるAWS上のAthenaからのデータ取得です。

### Power Automateの実行履歴
　トリガーが発動し、無事アクションも呼び出してくれたようです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/edb9428b-80a6-0780-242a-d24a99396692.png)

### Power BI データセットの更新確認
　更新履歴を見ると、無事更新してくれていました。
　呼び出しはスケジュール更新の「計画済み」でも、手動で更新する「オンデマンド」でもなく、Power Automateからの実行は「API経由」となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/15af1854-fd32-6e19-a709-4759e10509a4.png)

## （参考）データ更新確認用のPower BIレポート
　管理用にデータの更新時間や件数確認用ボードを作っておくと、確認しやすく便利です～

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/2a63b218-af2c-4bef-27fd-2e7c762beac1.png)

## （参考）Power Appsのデータフローでも利用可能
　データフローの更新完了トリガーは、Power Appsのデータフローでも、もちろん使えます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/419691/a90f56ac-1cef-47c1-1304-a7b1c14c5997.png)
　グループの種類でどちらを使うかを決めます。

- **Workspace** Power BIの場合
- **Environment** Power Appsの場合

## 更新回数の制限は通常利用と同じ
　Power Automate経由の更新も、通常の回数制限と同じです。**Power BI Proなら8回/日、Power BI Premium系なら48回/日**です。

https://learn.microsoft.com/ja-jp/power-bi/connect-data/refresh-data?WT.mc_id=DP-MVP-5004418


https://powerbi.microsoft.com/ja-jp/blog/refresh-your-power-bi-dataset-using-microsoft-flow/

# おわりに
　Power Platform内での連携、シンプルにスマートにできてありがたいです。
Spring Boot JDBCであいまい検索

## はじめに
Spring BootのJDBCであいまい検索機能を作った時のSQL文を紹介します。

普通のSQL文でLIKEを使う場合(?はviewのフォームから送られてきたものが入ってくるものです)
```
SELECT *
FROM book
WHERE title LIKE '%?%';
```
こう書くと思っていましたが、こちらが正解でした。

```
SELECT * 
FROM book 
WHERE title LIKE '%'||?||'%';
```

%と？の間に||を入れることで、あいまい検索をしてくれるSQL文が完成します。
PostCSSでのz-indexの管理を簡単にしたい！

# PostCSSでのz-indexの管理を簡単にしたい！

## 背景
z-indexの管理がややこしすぎる、、、
どこが何より上なのかよくわからず、検証するとOverlayよりHeaderが上にある！！
やば！修正修正！
誰にもバレずに、即修正！
みたいなことがしょっちゅう、、、
特に自分で設計してないものだとすぐに迷子、、、
もちろん作っていても迷子

## やり方
### STEP 1. postcss-each をインストール
https://www.npmjs.com/package/postcss-each


### STEP 2. 下記のように記述

```
:root {
 @each $key, $value in (Swiper, Header, BackToTop, Overlay, Modal), (1, 3, 5, 7, 9) {
    --z-index-$(key): $(value);
  }
}
```

### STEP 3. 呼び出し方

```
header {
 z-ndex: var(--z-index-Header);
}
```

以上
Docker Apacheのコンテナが起動しない

:::note info
この記事は[miriwoお一人様 Advent Calendar 2022](https://qiita.com/advent-calendar/2022/miriwo)の21日目の記事です
:::

# 概要

- ApacheとPHPが入っているWebサーバーのDockerコンテナを起動しようとしたところApacheのエラーで起動できなかった。体験談をまとめる。

# ご注意

- 本記事はあくまで自分の環境でのトラブルシューティングです。さらに、後述するエラーのみののトラブルシューティングです。

# エラー内容

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using XXX.XXX.XXX.XXX. Set the 'ServerName' directive globally to suppress this message

# エラーまでの経緯

- 開発しようと思って既に用意されていた`$ make up`コマンドを実行してMySQLとWebのコンテナを一回で起動しようとした。

# エラー

- `$ docker ps`で確認したところMySQLのコンテナしか起動していない。
- Docker for DesktopでWebコンテナを見てみたら「エラー内容」で紹介したエラーが主力されていた。

# 解決までの経緯

- Docker for DesktopからWebコンテナの起動を試みるが、一瞬起動するものの、同様のエラーを出力しコンテナが落ちる。
- 参考文献に記載されている各リンクの内容を試してみた。apacheのconfで既に`ServerName localhost:80`は設定してあったが一旦コメントアウトしたりしたけど解決しない。
- エラーは同じだがWeb上の知見と自分の事象が乖離している。
- Dockerの設定と言ったらdocker-compose.yamlのイメージだったのでWebコンテナの設定を見てみる。
- 原因判明、Webサーバー用のポートフォワーディングの値が誤っていた。
- 下記の様に何故かコンテナ内の8099ポートをローカルの80にフォワーディングしていた。。

    ```docker-compose.yaml
    ports:
          - "8099:80"
    ```

- app.confではlocalhostを80ポートで提供するように設定していたので下記の様に修正した。

    ```docker-compose.yaml
    ports:
          - "80:80"
    ```

- 問題は解消しWebコンテナは起動した。

# 教訓

- Dockerコンテナが起動しなかったらDocker for Desktopで当該コンテナのログを見よう。
- エラーコードを検索する時、エラーコードすべてで検索するのではなくかいつまんで調べよう。（今回なら「httpd: Could not reliably determine the server's fully qualified domain name」とか`httpd:`を`apache2:`にして検索してみるとか）

# 参考文献

https://qiita.com/sachiko-kame/items/a6deebbad207d627b598

https://askubuntu.com/questions/256013/apache-error-could-not-reliably-determine-the-servers-fully-qualified-domain-n

https://help.ubuntu.com/community/ApacheMySQLPHP#Troubleshooting_Apache

https://onoredekaiketsu.com/apache-error-fully-qualified-domain-name/
AZ-900:Describe cloud concepts ⑦

AZ-900の試験を英語で受けるに至り、翻訳なしで勉強をしてまとめていく勉強ノートです。

自身の復習用としても記事を書くつもりではありますが、同じように英語で受講予定＆翻訳なしでそのまま英語で勉強した方がやりやすい方の参考に少しでもなることが出来ればと思います。


# 学習内容
 Describe cloud service types
- [学習内容](#学習内容)
- [Describe Infrastructure as a Service (Iaas)](#describe-infrastructure-as-a-service-iaas)
	- [Shared responsibility model](#shared-responsibility-model)
	- [scenarios](#scenarios)
			- [Lift-and-shift-migration:](#lift-and-shift-migration)
			- [Testing and development:](#testing-and-development)

<a id="#describe-"></a>

# Describe Infrastructure as a Service (IaaS)

What is it?:
* the most flexible category among cloud services.

What makes it most flexible?:
It provides you the maximum amount of control for your cloud resources...
It is up to you to decide what to do with the hardware rented from the cloud datacenter.
* cloud provider is responsible for maintaining the...
	* hardware
	* network connectivity (to the internet)
	* physical security
* You are responsible for everything else:
	* operating system - installation /configuration / maintenance
	* network configuration
	* database and storage configuration
	* etc.

<a id="#scenarios"></a>

## scenarios

Common scenarios where IaaS might make sense:

#### Lift-and-shift-migration:
**Situation:**
User is thiking of moving an on-prem infrastructure the the user made to cloud.

**Characteristic**
Movable to cloud as an on-prem infrastructure... without changing the structure.

**What the user should do:**
Lift-and-Shift-migration

#### Testing and development:
**Situation:**
User needs to rapidly delete and replicate configurations for development and test environments.

**Characteristic:**
Doable in the cloud environment!

**What the user wants to do:**
Struct using IaaS


---

AZ-900:Describe cloud concepts① はこちら：

https://qiita.com/fsd-lukapyon/items/0100596156d3abc7808e

AZ-900:Describe cloud concepts② はこちら：

https://qiita.com/fsd-lukapyon/items/99edd38b566f6ed0d096

AZ-900:Describe cloud concepts③ はこちら：

https://qiita.com/fsd-lukapyon/items/0324140f0b6c2034db68

AZ-900:Describe cloud concepts④ はこちら：

https://qiita.com/fsd-lukapyon/items/90ed9d652da29f19f06e

AZ-900:Describe cloud concepts⑤ はこちら：

https://qiita.com/fsd-lukapyon/items/3d489123078f765ccb87

AZ-900:Describe cloud concepts⑥ はこちら：

https://qiita.com/fsd-lukapyon/items/6b5e612044dd37b42386

AZ-900:Describe cloud concepts⑧ はこちら：

https://qiita.com/fsd-lukapyon/items/abfc398d55bf28160b90

AZ-900:Describe cloud concepts⑨ はこちら：

https://qiita.com/fsd-lukapyon/items/4881ce9db481dd4173eb
DatabricksのクラスターとSQLウェアハウスの違い

[Databricks Cluster vs SQL Warehouses \| by Ganesh Chandrasekaran \| Oct, 2022 \| Medium](https://ganeshchandrasekaran.com/databricks-cluster-vs-sql-warehouses-c0c159287dd7)の翻訳です。

:::note warn
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
:::

Databricksのプレミアムアカウントを使用しているのであれば、Data EngineeringとMachine Learningに加えてSQLペルソナを目にかけることでしょう。
![](https://miro.medium.com/max/1400/1*p8xU-cp_kKOAJEU9EWZwOA.webp)
*Databricks SQLペルソナ*

Data EngineeringやMachine Learningを使っているのであれば、(インタラクティブあるいはジョブ)クラスターを起動しますが、SQLペルソナを使っている場合には、標準のDatabricksクラスターではなくSQLウェアハウス(以前のSQLエンドポイント)であることに気づくことでしょう。

本書では、DatabricksクラスターとSQLウェアハウスの違いをクイックにまとめます。
![](https://miro.medium.com/max/1400/1*dfWNc9vPd2paeezUfGbCbA.webp)
*Databricks - SQLウェアハウスの作成*

- SQLウェアハウス(エンドポイント)はSQLコマンドを実行するために開発されており、Scala/R/PythonやSQLコマンドを実行するために開発されています。
- SQLウェアハウス(エンドポイント)ではJAR、PIP、WHLのようなライブラリのオーバヘッドがなく、クラスターではライブラリによるオーバヘッドが生じることがあります。
- SQLウェアハウス(エンドポイント)はSQLウェアハウスの管理を簡素化しており、起動時間を加速します。クラスターの設定は初めての方にとっては複雑なものになる場合があります。
- SQLウェアハウス(エンドポイント)はクラスターとしてスケールアップ/スケールダウンします。クラスターはノードごとにスケーリングし、最大範囲までスケールアップします。
- SQLウェアハウス(エンドポイント)には、起動時間を劇的に削減するサーバレスの機能(プライベートプレビュー)がありますが、クラスターではその機能はまだありません。

次の項目は違いではなく、両方で利用できる機能です。

SQLウェアハウス(エンドポイント)とクラスターの両方はTableauのようなBIツールからの接続に使用でき、自動起動の機能を有しています。

### Databricks 無料トライアル

[Databricks 無料トライアル](https://databricks.com/jp/try-databricks)
今すぐ出来るアウトプット

# はじめに
今回、初めての Qiita記事 であり、初めてのアドベントカレンダー記事を書いてみました！
至らない点もあると思いますが、ぜひ読んでいただけたら嬉しいです。

# 実際にやってみる
**「習うより慣れろ」**

**「身体で覚える」**

**「そんなことよりコードを書け」**

これらのことわざは、皆さんも聞いたことがあると思います。

漢字を覚える時に、ただ漢字ドリルの文字を眺めているだけで覚えられる人はいません。
恐らく、ノート等にたくさん書いて、やっと覚えられたのではないでしょうか？

それと同じで、ただ記事を読んだり、チュートリアルを眺めているだけでは、絶対に身につけられません。
実際に手を動かしてみると、自然に身につけることができます。
( まぁそのためのチュートリアルなんですけどね... )

とにかく、手を動かさないと**作れるものも作れません！**
やりたいと思ったことはまずやってみることです

# 記事を書く
今、世の中には便利なサービスがたくさんあります。
*Qiita*、 *Zenn*、*Note* 等、自分でWebサイトを作成しなくても、簡単に記事を書いて全世界に発信することが出来ます。
記事を書くということは、自分の経験や知識を他人に共有するということです。
記事というのは、**「今日こんなことがあったよ」** だったり、**「こうすればうまくいくよ」** などの日常会話の内の大事なところを抜き出した感じです。

**それで十分なんです。**

読む人がそれを理解し、**「なるほどね」** と思ってくれたり、誰かの役に、知識になれば、それは立派な **記事** なのです。

もしかしたら、あなたしか知らない知識があるかもしれません。
あなたにしか出来ない技術があるかもしれません。
人によっては、そのままでいいと思うかもしれません。

しかし、ここは *Qiita* の世界！
アウトプットしないことは罪なのです！ (そんなことは無い)
せっかくなんだから、共有しよう！

それで誰かの生活を救えるかもしれません (そんなことは無い)
ノーベル技術賞をもらえるかもしれません (そんなことはry)
知名度が爆アゲするかもしれません！ (そんなことある)

これも、手を動かすことです

# まとめ
* とにかく手を動かそう！
* 記事を書いてみよう！
* みんなと共有してみよう！

# おわりに
いやぁ〜 記事書くのって大変ですね笑
ちゃんとまとまりとか流れを考えて書かないと、すぐ文章崩壊してしまいます...
でも、そのおかげで頭が鍛えられたり、国語力が上がったりするかも？

そんなことはさておき、
今回、初めてこうやって世の中に情報を発信できて、すごい楽しかったです！
それでは、今後もよろしくお願いします！

あ、あとTwitterの宣伝していいですか？ (ダメです)
(プロフ欄から見れま〜s...)
MySQL関連で参考にした事

MySQLのリリースノートを見ていたら、今まで全く知らなかった用語・名称がたくさん出てきてそれらを調べるのが大変だった。なのでメモ。

### character_set_xx

https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0065

character_set_xxに関して丁寧に説明が記載されていた

### Performance Schemaのsetup_instruments

>Incompatible Change: Instrumentation in the Performance Schema setup_instruments table was revised as follows:

https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-24.html

setup_instrumentsって何。から始まったがこのブログがとても分かりやすかった

https://engineering.linecorp.com/ja/blog/mysql-research-performance-schema-instruments/

### pfs_plugin_table

プラグイン使用の為のコンポーネント、動的なパフォーマンス スキーマ テーブル操作のためのもの。
これほんと情報無かった、ググって検索結果2ページしかない。
今後削除されるものだから深掘りはしない。

https://denis.elib.ru/Documents/MySQL/MySQL_80/extending-mysql.html#component-plugin-services

### masterとslave

要約で背景を知れて理解が深まった
https://sakaik.hateblo.jp/entry/20200702/mysql_changes_some_terminologies_eg_master_slave

### master.infoファイル

MySQL８からは使わないけど。何なのか理解する必要がありこれで助かった

https://yoku0825.blogspot.com/2013/11/mysql-56.html

### クエリキャッシュ

https://qiita.com/mamy1326/items/d1548d8cf4528277172a#%E3%82%AF%E3%82%A8%E3%83%AA%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%81%A8%E3%81%AF
AIについて

＃あいさつ
　私は、情報テクノロジーで2022年の技術トレンドはなにかと考えGoogleで検索し、AIが、出てき
たのでAIの歴史、現在の技術について調べようと思いました。
![image1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2982407/be757836-fd53-5439-dae7-99dc7ae23204.png)


＃歴史
AIロボットが初めて出現したと言われている1960年代のロボットは、初の自動移動能力があるロ
ボット、Shakeyです。このロボットは障害物を避け、移動できる能力を持つロボットで、当時のAI
技術開発を促進したといわれています。
　動画：https://www.youtube.com/watch?v=7bsEN8mwUB8
＃ブーム
　第1次AIブームで、1966年にマサチューセッツ工科大学のジョセフ・ワンゼンバウムにより発明
された初の自然言語処理プログラム、イライザ（ELIZA）は有名で、Siriの起源になったともいわれ
ています。
　また第2次AIブームでは、1980年代で、ブームの引き金はエキスパートシステムの実現です。
（エキスパートシステムとは、人工知能に専門家のように「知識」をルールとして教え込み、問題
解決させる技術）エキスパートシステムは現在も導入され、大手企業の評価システムや、話題に
関するニュースを表示したりするレコメンドシステムなども、エキスパートシステムです。
![image2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2982407/e7810149-cf59-1c8f-1491-84954135857c.png)


＃現在
　１．機械学習の実用化
「ビッグデータ」と呼ばれているような大量のデータを用いることでAI自身が知識を獲得す
る「機械学習」が実用化された。
　２．ディープラーニングの登場
　　　　従来の機械学習では人間が特徴量を定義し、予測や推論の精度を上げていた。「ディープ
ラーニング（深層学習）」を活用することで、学習データから自動で特徴量を抽出し、精度を向上さ
せることが可能になった。
　ビックデータ：従来のデータベース管理システムなどでは記録や保管、解析が難しいよう　　　　
　　　　な膨大なデータ群のこと
　機械学習：コンピュータが大量のデータを学習し、分析や予測などのタスクを遂行するア　　　　
　　ルゴリズムやモデルを自動的に構築する技術のこと。
　ディープラーニング：機械学習の実装手法の一つで、人間が行うタスクをコンピュータに　　　　　
　　　　　　覚えさせ、複雑な問題を解決するための技術
　特徴量：機械学習における特徴量とは、学習の入力に使う測定可能な特性のこと。
参考文書：https://ledge.ai/history-of-ai/
＃歴史を調べてみて感じたこと
　私は今回AIの歴史を調べてみて、AIのこれからの発達に興味を持つきっかけになったらいいな
と感じました。これから、就職などで資格が必要になるかもしれないので頑張りたいです。
flutter 生年月日の入力欄実装（これドラムロールって言うんやの巻）


### はじめに
・筆者はflutter初心者です（flutter歴：約１ヶ月程度）
・元々バックエンドでJava/SpringBootを触っていましたが、
　機能横断的なスクラムチームを作るために先月フロントエンドに移動
・自分の復習、備忘録用に書きました

### 生年月日の入力をドラムロールでやりたいと思ったきっかけ
バリデーション実装の際、他のアプリでどのようなものがあるかみていた時に
生年月日の入力欄は、選択するもの（ドラムロール）が多く、
自分で入力するより確かに選択できた方がユーザーからすると楽で良いなと思い
バリデーションもつけなくて良くなるので（必須以外）やってみようと思ったのがきっかけです！

### まず、これドラムロールって言うんや


:mag:**「 flutter 生年月日入力 」** とかで検索するとまず出てくるのは、[DatePicker](https://www.choge-blog.com/programming/flutter-calendar-input/)を使ったカレンダー入力

ただこれだとUI的に良くないという記事を発見・・・:eyes:
確かに生年月日の入力には向いてなさそうだなと思いました

https://satoriku.com/android-uidesign/

なので、**DatePicker**ではなく、[DateTimePicker](https://pub.dev/packages/flutter_datetime_picker)というパッケージを使用します！

:point_down_tone4:よく見るこの西暦の選択式のやつはドラムロールってゆうんやって思いましたね（初耳

![スクリーンショット 2022-12-20 21.21.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2899739/d3e90609-8d7d-ace3-49e8-a0828165dbc5.png)

### ドラムロール実装参考記事(DateTimePicker)

参考記事もいくつかあって分かりやすく、実装できたのですが・・
Textで表示させるだけの記事が多くTextFieldに反映したいがやり方がわからず少し手こずりました

https://qiita.com/KKoichi51/items/d886b0e5894b5831dfa7

https://qiita.com/tewi_r/items/ca46fabb0420a14ca391

https://pub.dev/packages/flutter_datetime_picker/example

### TextFieldに選択した生年月日を反映させる

TextFieldの入力値を管理するのにcontrollerが必要みたいです

https://api.flutter.dev/flutter/widgets/TextEditingController-class.html

https://b1san-blog.com/post/flutter/flutter-text-field/

:point_down_tone3:TextFieldにTextEditingController()を設定する
```controller.dart
final controller = TextEditingController();
```
```controller.dart
TextField(controller: controller),
```


[こちら](https://qiita.com/KKoichi51/items/d886b0e5894b5831dfa7)の記事を抜粋すると

>onConfirm　ではユーザが完了ボタンを押した際の処理を記述します。
TextField の onSubmitted と似たプロパティです。

と記載があったので下記のようにonConfirm内に選択した値を反映させるように書きました！



```date_time_picker.dart
//〜ソースコード省略〜
DatePicker.showDatePicker(context,showTitleActions: true,
    minTime: DateTime(1950, 1, 1),maxTime: DateTime(2022, 8, 17),
    onConfirm: (date) {
    //ユーザが完了ボタンを押した際の処理
    textController.value = TextEditingValue(text: '${date.year}/${date.month}/${date.day}');
//〜ソースコード省略〜
}
```

### さいごに
flutterを触り始めてまだ１ヶ月程ですが、とても楽しく沼りそうです・・:ramen:
同じようにドラムロールを実装したい人の参考になれば幸いです。
GitHubのリリースノート自動生成とgit-pr-releaseの併用の仕方

## GitHubのリリースノート自動生成機能とは
[Automatically generated release notes](https://docs.github.com/en//repositories/releasing-projects-on-github/automatically-generated-release-notes)

サンプルそのままドキュメントから抜粋

```.github/release.yml
# .github/release.yml

changelog:
  exclude:
    labels:
      - ignore-for-release
    authors:
      - octocat
  categories:
    - title: Breaking Changes 🛠
      labels:
        - Semver-Major
        - breaking-change
    - title: Exciting New Features 🎉
      labels:
        - Semver-Minor
        - enhancement
    - title: Other Changes
      labels:
        - "*"
```

release.ymlを書いてからボタンポチポチすると

![スクリーンショット 2022-12-20 8.45.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/113504/6f31baa1-549b-a56f-55a5-c09d38a4865f.png)

こんな感じのリリースノートを生成してくれる。便利。


## git-pr-releaseとは

https://github.com/x-motemen/git-pr-release

![スクリーンショット 2022-12-20 8.42.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/113504/092ff664-8d3f-b96a-f533-f3ce13ccb2b7.png)

develop から mainにマージする用のプルリクエストを作るツール。
可視化に便利。

私はこのツールで`release`というラベルを作成されたPRにつけるようにしていた。
![スクリーンショット 2022-12-20 8.43.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/113504/c1f1095f-9f99-1839-3e21-bd420117ab54.png)

## 上記の2つをそのまま併用するとどうなるか。

![スクリーンショット_2022-12-20_8_57_47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/113504/b3bfb3db-105d-6306-203c-7533d1c38c0f.png)

リリースノートにRelease用PRが入る。いらない。

## 本記事について

リリースノートに「Release YYYY-MM-DD ~~」のPRが入らないようにするやり方を考えたので書く

## 結論

release.ymlの除外するラベルリストに「ignore-for-release-note」を追加

```.github/release.yml
changelog:
  exclude:
    labels:
      - ignore-for-release-note
  categories:
```

git-pr-releaseで以下のようにGIT_PR_RELEASE_LABELSにカンマ区切りでignore-for-release-noteを追加
(下記はGitHub Actionで実行する例)

```.yml
    - name: Create a release pull request
      env:
        GIT_PR_RELEASE_TOKEN: ${{ secrets.GIT_PR_RELEASE_TOKEN }}
        GIT_PR_RELEASE_BRANCH_PRODUCTION: main
        GIT_PR_RELEASE_BRANCH_STAGING: develop
        GIT_PR_RELEASE_LABELS: release,ignore-for-release-note
        GIT_PR_RELEASE_TEMPLATE: .github/git_pr_release_template
      run: |
        gem install -N git-pr-release -v "2.2.0"
        git-pr-release --no-fetch
```

![スクリーンショット 2022-12-20 9.57.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/113504/42ef8f5c-89da-2990-a07f-08552d1aa6e2.png)

これでリリースノートに含まれなくなる

## 他の選択肢

考えた候補は以下

- `ignore-for-release-note`ラベルを追加する(本記事)
- `release`ラベルがついているPRをリリースノートの対象から外す
- ReleasePRにラベルをつけない。

これらのうち一番上が最も汎用性高そうだったのでそれを選択した。
二番目のほうが楽なのでそっちでもいいとは思う。
Arduino UNOにAdafruit SSD1306をインストール

目的
OLEDのテスト

1.スケッチ
2.ライブラリ
3.ライブラリを
4.ssd1306を検索
5.Adafruit SSD1306を選択

![o_cop253.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/840352/64bfb419-1715-51a5-b9f0-4ec96410eb23.jpeg)



![o_cop259.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/840352/afcc8559-eb4b-71c7-f918-a309991dc98f.jpeg)