OmniAICreator/Qiita-1.07M huggingface dataset:
2023年展示報告：BVEと連携する誤自宅運転台のススメ

2022年に作った自宅運転台を2023年は展示会にて展示することにしました。

https://qiita.com/usashirou/items/78599ea87ec8fb59dfdb

展示・発表場所は以下から選ぶことにしました。
# 主な展示・公表会場
- IoTLT
- MakerFaire
- NT東京
- WF
- RX Japan展示会
- 日経展示会
- 自己出展
- 店頭など

# NT東京の選定理由
この中からリアル展示会はNT東京を選択しました。
- 近距離
- 入場料無料
- 場所
- 出展料が安価
運転台は、大きく、車での移動が必要な為、近距離の会場である必要があります。
更に入場料が無料であり、子供や家族連れが来場する可能性が高い科学技術館はベストと判断しました。
さらに出展料が安価であることも大きな理由でした。
# MakerFaireを選定しなかった理由
- 出展は選考
- 出展料が高い
- 入場料が有料
- 会場を見て回れない

MakerFaireは出展ハードルが高いことが挙げられます。
また、入場料がかかることから、気軽に家族連れが来ないのでは？
と判断しました。
さらに重要なのは、自分が会場を見て回る時間が無いことが挙げられます。

# NT東京の結果
想定通り、家族連れが多く来訪し、予想以上に子供たちが遊んでくれました。
元々、子供が遊んで壊す可能性から壊れても良いように設計しており、想定通りでした。
![NT東京.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/fe2bdcbb-3aac-4c39-95c9-868fccb0cce6.jpeg)
# IoTLTでの事前発表
NT東京の前にIoTLTにて事前発表しました。
IoTLTはYoutubeでのオンライン配信もしており、事前告知の場としても大事な発表の場です。
# GUGENでの追加展示
NT東京も終わった11月にGUGENの選考通過の連絡がありました。
NT東京だけの展示予定でしたが、せっかくなのでGUGENでも展示することにしました。
なお、GUGENは選考において賞を取ることが無いことを理解しており展示をする場と考えました。
平日ではありますが。会場が秋葉原のダイビルという事で、Twitter(X)での告知により来訪して頂く方がいらっしゃったので出展した価値があったといえます。
![GUGEN.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/4755eef9-2018-28c4-2cdc-4af2e16cee9d.jpeg)
## 雑に扱われる
子供がガチャガチャ弄るという事を前提に運転に使用するマスコンはタイトーの電車でGoを使用しています。
これは子供が弄って壊しても、簡単に、安価に交換できるために選定しました。
別の展示会では展示していたマスコンが故障したり、子供には触らせないという対応でクレームがあったそうです。
# 総評
展示に際して、NT東京では、板金のフルバージョン、３Dプリンタの予備という2つの運転台を持ち込みました。
３Dプリンタ版はノートパソコンを横に置いたことと、画面が小さいことから運転がしにくい問題がありました。
GUGENは展示場所の制約からモニターを持ち込めない為、３Dプリンタ版と同じくノートパソコンを横に置きましたが
モニターを凝視ししてしまい、せっかくの運転台の意味を成さない状態となってしまいました。
このため、やはりモニターを正面に置かないといけないことがわかりました。
リアル展示会は学びが多いだけにチャンスがあるならやってみることをお勧めします。
【Go言語】マップ

## マップ
マップは、キーと値のペアを格納するためのデータ構造で、キーを使ってデータの検索、更新、削除ができる。
Pythonの辞書やJavaのハッシュマップに似ている。

### マップの作成
```go
package main

import "fmt"

func main() {
	// リテラルを使用する
	m1 := map[string]int{
		"foo": 1,
		"bar": 2,
	}
	fmt.Println(m1) // map[bar:2 foo:1]

	// `make`関数を使用する
	m2 := make(map[string]int)
	fmt.Println(m2) // map[]

}

```
### マップの操作
```go
package main

import "fmt"

func main() {
	m := make(map[string]int)

	// 追加
	m["foo"] = 1
	m["bar"] = 2
	fmt.Println(m) // map[bar:2 foo:1]

	// 更新
	m["foo"] = 3
	fmt.Println(m) // map[bar:2 foo:3]

	// 取得
	v1 := m["foo"]
	fmt.Println(v1) // 3

	// 存在の確認
	v2, ok2 := m["bar"]
	if ok2 {
		// 存在する
		fmt.Println(v2) // 2
	} else {
		// "bar"はマップに存在しない
	}

	// 削除
	delete(m, "foo") // fooを削除
	fmt.Println(m)   // map[bar:2]

}

```

## 参考
https://www.oreilly.co.jp/books/9784873119694/
IBM Cloud Carbon Calculatorで温室効果ガス排出量を見てみた

## はじめに
IBM Cloudでは、[Carbon Calculator](https://cloud.ibm.com/docs/billing-usage?topic=billing-usage-what-is-cloud-calc)という新サービスを通じて二酸化炭素（CO2）を含む温室効果ガス（GHG）の排出量を確認することが可能になりました。
特に、企業がクラウドを利用する際、オンプレミス環境と比較して、間接的な電力消費に起因する温室効果ガスの計算は困難です。Carbon Calculatorは、これらのCO2および温室効果ガスの排出量を正確に把握するための有用なツールです。
またこの記事では、裏側ではどのような計算ロジックで算出されているのかも記載しています。

## Carbon Calculatorの概要
このサービスでは、ユーザーのIBM Cloudアカウントが利用する各サービスによって発生する温室効果ガスの排出量を確認できます。アカウント全体の排出量に加え、個別のサービス、ロケーション、リソースグループごとにフィルターをかけて排出量を確認することが可能です。
計算の基本的な考え方は、データセンターでの電力消費とそれに伴う温室効果ガス排出量に焦点を当てることです。特徴的な点として、ユーザーが直接使用するサービスだけでなく、間接的に利用する機器などの電力消費も計算に含まれます。データセンター全体の総排出量は、それぞれのサービスの使用率に基づいて各アカウントに配分されます。


## Carbon Calculatorを使ってみる
IBM Cloudの[Carbon Calculator](https://cloud.ibm.com/billing/carbon-calculator)ページにアクセスします。
または、IBM Cloud[ポータル](https://cloud.ibm.com)から「Manage」→「Billing and Usage」→「Carbon Calculator」へと進むことができます。
![スクリーンショット 2023-12-04 21.55.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2600839/7edcc973-3819-235f-022b-141ddbd4952d.png)

![スクリーンショット 2023-12-04 22.38.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2600839/0aff2758-037f-7d6f-d2a4-6341ff6b123f.png)


ここでは、アカウント全体の排出量だけでなく、サービス、ロケーション、リソースグループ別に排出量を確認できます。期間やサービス、ロケーションごとのデータフィルタリングも可能です。「Export」機能を使用すると、データをCSVファイルとして出力し、追加分析が可能です。
表示される排出量は、請求サイクル終了後のデータに基づくため、最新のデータが表示されるまでに約2ヶ月かかります。
さらに詳細なESGレポートについては、[IBM Envizi](https://www.ibm.com/jp-ja/products/envizi)を利用することもできます。
![スクリーンショット 2023-12-04 21.52.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2600839/fa8c9327-b991-028a-639b-0541f9b029eb.png)


## 排出量の計算方法とは

ロケーション、サービス、アカウントごとの温室効果ガス排出量は以下の式で求めることができます。
![スクリーンショット 2023-12-04 22.07.35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2600839/fbb14f92-11f7-d9f3-b015-fde48f39645f.png)

「**IT電力消費量**」とは、特定のアカウントが特定のロケーションで使用する特定のサービスに関連する電力消費量を指します。たとえば、東京リージョンで仮想サーバーを使用する利用者アカウントの電力消費量がこれに当たります。
この計算においては、まず、仮想サーバーの全ロケーションにおけるIT電力消費量を推定します。次に、この推定値を基にして、東京リージョンにおける具体的なIT電力消費量を算出します。その後、このロケーションでの消費電力を、そのロケーションを利用している各アカウントに割り当てることにより、個々のアカウントごとのIT電力消費量を最終的に算出します。
この計算方法は、一つのロケーションの消費電力を、そのロケーションを使用するすべてのアカウントに分配するという考え方に基づいています。

次に「**電力使用効率**(PUE：Power Usage Effectiveness)」というものは、IBM Cloudのデータセンターは通常は第三者のデータセンター事業者の共有施設でホストされているので、施設のインフラはIBMの管理下にはありません。そのため、データセンターの中の設備で発生する追加的な非IT電力消費を考慮に入れるために、電力使用効率という指標を使ってオーバーヘッドを反映します。
電力使用効率は各データセンターから提供されるデータを基に計算されます。

最後に「**炭素排出係数**(CEF：Carbon Emission Factor)」は、CO2排出量を測定するための指標で、地域固有の排出係数を用いて計算されます。これは、地域ごとの異なるエネルギー源や電力の需要供給差を考慮しています。

また、計算の対象外となる要素には、IBM Cloudサーバールームの外にある共用部分の電力消費、サーバールーム外で稼働するサービスの電力消費、機器の製造や原材料製造に伴う電力消費、機器の運搬や廃棄、再利用に伴う電力消費などが含まれます。


## まとめ
本記事では、IBM Cloud Carbon Calculatorの概要、利用方法、計算方法の裏側を紹介しました。
このツールは簡単に利用開始でき、さらに無料で利用可能です！
是非、自身のアカウントで温室効果ガス排出量を確認してみてください。
日本語は好きですか？　～日本語とTCP/UDP～

この記事は [Optimind Advent Calendar 2023](https://qiita.com/advent-calendar/2023/optimind) の7日目の記事となります。

https://qiita.com/advent-calendar/2023/optimind


# はじめに
最近、読解力低下を憂えるSNS発信を見かける。受け手の読解力が炎上原因とする主張も散見する。
読解力向上を扱う書籍も多く出版されている印象だ。

説明したのに理解してもらえない、説明されたが理解できない、いずれの場合も発受信の双方が不幸になる。
そうならないためには、発信者による「説明力」と受信者の「読解力」双方の工夫とバランスが必要である。

長い歴史を重ねたきただけあり日本語は機能豊富だ。しかし複雑で分かりにくい。そのためスキルや経験による活用の濃淡がある。
一方、たかだか60年かそこらの歴史しかないインターネットプロトコルはすこぶる効率的でシンプルだ。

この2つを同じフィールドで比較して考えるのは愚の骨頂だ。
だって、スノーボード履いてサッカーなんてしないだろう。
でも、並べてわかることもある。



# 「伝える」と「伝わる」
相手に何かを「伝える」ことは簡単でも、それが「伝わる」となると難しいと感じることがよくある。

- **「伝える」**：情報発信者は受信者に**伝わっているかどうか**わからない。
- **「伝わる」**：情報受信者は**伝わった**ことを情報発信者に伝えることができる

インターネットプロトコルに置き換えると少し面白い （細かい話はおいておいて）

- **「伝える」**：**UDP**
- **「伝わる」**：**TCP**

TCPはパケットが到着したことを受け手が報告する。あぁ伝わったなとなるのである。
一方、UDPは受け手にお構いなくパケットを送り付ける。
UDPが意地悪というわけでない。動画や電話のようにリアルタイムでデータを届ける場合はいちいち受け手の連絡を待っていたのではブツ切れになってしまう。



![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3634294/183b07bc-0902-f89e-7370-56052dae7e51.png)
　　（出典：https://qiita.com/daitasu/items/ae21b16361eb9f65ed43）



TCP/UDPはシンプルでいい。世の中の会話はもうこれでいいのではないか。
それに比べて日本語は難解で煩雑。尊敬語、謙譲語、丁寧語、敬語だけでも3つある。なくせばコミュニケーションコストも下がる。

と思うのは心得違いである。




# 日本語の妙と難解

どうやら日本語は不思議で奥ゆかしく妙であるらしい。

https://www.taishukan.co.jp/book/b198227.html

先日、外山滋比古氏の「国語は好きですか」という名著に出会った。
コミュニケーションツールとしての日本語の興味深い点をいくつか発見できたのは収穫であった。

 - **1人称（I）や2人称（you）が多彩**
    - わたし、ぼく、おれ、わがはい、小生　いろいろある
    - きみ、あなた、貴様　いろいろある
    - 西日本だけかもしれないが、相手をさして「自分」といったり。もう意味不明だ
- **2人称が多彩にもかかわらず、へりくだった敬称のボカシ表現がある**
    - 「殿」はその人の住居をさす、「様」はもやったとした様（さま）をさすとして失礼のないようボカシしているのだそう
- **にもかかわらず、失礼のないよう主語を省く**
    - 「わたしが食べます」ではなく「いただきます」
    - 「あなたが来ませんか？」ではなく「いらっしゃいませんか？」

Slackの使い初めで「@名前」は失礼かなと思ったり、慣れてきても「@名前 さん」としていた方も少なくないのではないか。

日本語にはインターネットプロトコルにはない相手を思いやる機能がある。
自らをへりくだって相手を立てるコトバをコミュニケーションのヘッダに載せる。言うなれば人間関係の潤滑油付きの意思疎通ツールだ。

素晴らしいコミュニケーションツールである。ただうまく使う必要はある。

ここ数年のAIに発達をみれば日本語なんて簡単　なのかもしれない。
でもAIに言われてもねと思うのは世代格差か歳のせいか。
いや、もしもそれができるAIなら、ブレードランナーの世界を味わえるかもと期待。


# 京都ことば
笑い話になっていたりする場合もあるのでご存じの方も多いと思う。
身内に京都人がいることもあり、ネタとしてからかったりもする。

- 商談が長引いたときなど「いい時計してますね」は「早く帰ってくれませんか」
- 屋外でのご近所同士で「お嬢さんのピアノとても上手ですね」は「ピアノがうるさくて迷惑」

相手に恥をかかすことなく、もやっと意思を伝える。
この要素は日本語コミュニケーションツールの特徴の１つであり、それは共通語としての日本語も同様である。

しかし、相手に通じなければプロトコル崩壊である。明確なエラーコードが出てこないばかりか、予期しない悲しい結果をもたらすこともある。
発信側は受信側の読解力を見極め、説明を工夫する必要があるのだ。ここは発信側の腕の見せ所とも言えるだろう。

なんだかネットワークエンジニアからは多くのツッコミが入りそうだが、本意を汲んでいただき何卒ご容赦願いたい。

拙筆を最後まで読んでいただき感謝申し上げる。
では、この辺りでTCP FINとさせていただきたく。
【Go言語】ゼロ値・スライス

## ゼロ値
変数宣言したが、値を設定していない変数は**ゼロ値**で初期化される。

### 型ごとのゼロ値

|型|ゼロ値|
|----|------|
|数値|`0`|
|ブール型|`false`|
|文字列|`""`|
|ポインタ、インターフェース|`nil`|

### サンプル
```go
package main

import "fmt"

func main() {
	var n int
	fmt.Println(n) // 0
	var b bool
	fmt.Println(b) // false
	var s string
	fmt.Println(s)  // ""
	var err error
	fmt.Println(err) // nil
}

```

## スライス
スライスは動的なサイズを持つ配列のようなデータ構造で、同じ型の要素を順序つけて格納する。
スライスは宣言時にサイズを指定する必要がない。
配列よりも柔軟で、スライスの方がより一般的に使用される。

### スライスの作成
スライスの作成には複数の方法がある
```go
package main

import "fmt"

func main() {
	// `make`関数を使用する
	a := make([]int, 5)
	fmt.Println(a) // [0 0 0 0 0]

	// リテラルを使用する
	s := []int{1, 2, 3}
	fmt.Println(s) // [1 2 3]
}

```
### スライスの操作
```go
package main

import "fmt"

func main() {
	s := []int{1, 2, 3}

	// インデックスによるアクセス
	fmt.Println(s[0]) // 1

	// 長さの確認
	fmt.Println(len(s)) // 3

	// スライスのスライス
	s1 := s[1:3]
	fmt.Println(s1) // [2 3]

}

```


## 参考

https://www.oreilly.co.jp/books/9784873119694/
【個人開発】ノートをフォルダ管理してパスワード付きで公開できるWebサービスをリリースしました

![スクリーンショット 2022-03-02 21.01.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/e378c300-bb0a-4106-8a53-d69bdf785416.png)

- Webで作成したノートをフォルダ分けして管理したい
- 勉強会の資料を参加者にだけ共有したい
- セミナー中だけアクセスできる資料を作りたい

なんてことあると思います。
こういう時、簡単で良い共有方法が意外とないんですよね。

そこでパスワード付きでマークダウンのテキストを公開できるサービス、**Text Online**を作ってみました。
公開しなければ個人の資料整理にも使えます。

https://text-online.net/

# できること
Googleアカウントさえお持ちなら、アクセス後、「ログイン」からすぐ利用できます。

## 1. フォルダで管理できる

「フォルダを作成する」ボタンで簡単にフォルダを作成できます。

![スクリーンショット 2022-03-02 21.19.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/8025ccb8-3d73-e8f9-233c-890c3306b49a.png)

その中にマークダウンで資料を保管していくことができます。

![スクリーンショット 2022-03-02 21.22.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/7788f2ed-d952-a47d-aff3-8e988f55491e.png)

### こだわりポイント
- アイコンをドラッグ&ドロップすることでフォルダの移動ができる

## 2. Markdownで資料を作成できる
「テキストを作成する」ボタンでMarkdown記法を使ってノートを作成できます。

![スクリーンショット 2022-03-02 21.26.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/6aa20f97-f6a2-52f2-416e-99648e8a3583.png)

### こだわりポイント
- 「Ctrl + s」「Cmd + s」で保存できる
- 画像をコピペできる

## 3. スマホでも使える
スマホからも閲覧、編集ができます。

![Screenshot_20231204-183306_Chrome.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/02aedbea-d96b-4105-820d-2cf2ac4c1438.jpeg)

![Screenshot_20231204-183213_Chrome.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/be5c4c43-11f2-c1bd-62cb-c32d400995ce.jpeg)

出先でメモっといて、家に帰ってから清書するなどの使い方も可能です。


## 4. パスワード付きで公開できる

テキストのデフォルトの公開設定は**非公開**です。
パスワード付き公開にして、公開用URLを共有することで、パスワードを知っている人だけがアクセスできるようになります。

![スクリーンショット 2022-03-02 21.32.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/ad379ab9-5a69-0a30-cbd5-568ba6b94c3c.png)

公開用URLにアクセスするとパスワード入力を求められます。

![スクリーンショット 2022-03-02 21.36.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/cfe029e4-8c76-4a6f-2d57-92af7d25e3ef.png)

パスワードを入力したユーザーだけが資料を閲覧できます。

![スクリーンショット 2022-03-02 22.20.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/130099/a8dca7fa-83ff-5a8b-4eee-43b5056c9371.png)

# 自分の使い方
- 研修や勉強会の資料づくり
- 開発中に遭遇したバグと解決方法のメモ（同じエラーに遭遇した人に共有できる！）
- 料理メモ（スーパーで買うものをスマホで確認できる！）

などなど使い方は自由です。

# 最後に
セミナー資料の公開に困っていたり、簡単に使えるメモサービスをお探しの方はぜひ使ってみてください。

スライドにコメントを送れるSlide Actというサービスも運営しております。
https://slide-act.web.app/

あと、たまに、Twitterで作ったものを公開しておりますのでフォローよろしくお願いします。
https://twitter.com/sanotyan1202
特定のフォルダーを素早く開きたい

## はじめに
　特定のフォルダーを素早くことができると、操作効率が爆上がりしますよね。そこで本日はフォルダを開く方法をいくつかまとめました。ぶっちゃけ、まとめだけで完結しています。

 ## エクスプローラーを開いて探す
 　特定のフォルダを開く方法その1としては `win + E`でエクスプローラを開きアクセスする方法です。すぐにアクセスできるところによく使うフォルダのショートカット集を作っておくことでGUIで素早くアクセスすることが可能になります。

## ファイル名を指定して実行を活用する

 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3601651/68977ed8-b805-b9f0-874c-32b20e9d3294.png)
　続いては **「ファイル名を指定して実行」** を使用する方法です。`Win + R`コマンドで「ファイル名を指定して実行」を開きそこにパスを入れることで直接フォルダを開くことができます。この方法の利点としては、一度アクセスしたフォルダは履歴に残るので、上下キーで選択することができます。

　便利なコマンドも用意されているので、うまく活用できるとかっこいいかもしれません。詳しくはこの記事を参照ください
 
 https://qiita.com/sta/items/4b70e6b130a1033dc2c5
## コマンドプロンプトを使用
　コマンドプロンプトを使用してCUIでアクセスする方法もあります。まずは「cmd」でコマンドプロンプトを立ち上げます。フォルダのパスが分かっている場合は、直接パスを入れて実行できます。パスが分からなくても1階層ずつ進めることもできます。

 | コマンド     | 動作   |
| :---------: | :-------- |
| dir    | 現在の階層のフォルダやファイルを表示する      |
| dir /b   | 現在の階層のフォルダファイルを簡潔に表示する      |
| cd パス     | 指定したパスに移動する     |
| cd..     | 一つ上の階層に戻る     |
| tree     | ファイル構造を確認する     |


## まとめ
　ショートカット専用のフォルダを作成し、よく使うフォルダやファイルなどのショートカットを入れておきましょう。そこでショートカット名を **短い入力しやすい名称** にします。あとは、`Win + R`コマンドで「ファイル名を指定して実行」を開いて、ショートカット名を入れることで、立ち上げることができます。これが私の思う最速で特定のフォルダを開く方法です。
plunkerでpdf.js

# 概要
plunkerでpdf.jsやってみた。

# 参考にしたページ

https://blog.emattsan.org/entry/2021/07/03/135014


# サンプルコード

```
class MyPdf {
  constructor(canvas, afterRendered) {
    this.canvas = canvas
    this.context = this.canvas.getContext('2d')
    this.pageNumber = 1
    this.rendering = false
    this.afterRendered = afterRendered
  }
  setAfterRendered(afterRendered) {
    this.afterRendered = afterRendered
  }
  loadDocument(path) {
    const renderPdf = (pdf) => {
      this.pdf = pdf
      this.getPage()
    }
    pdfjsLib.getDocument(path).promise.then(renderPdf)
  }
  setPage(pageNumber) {
    if (1 <= pageNumber && pageNumber <= this.pdf.numPages && !this.rendering) 
    {
      this.pageNumber = pageNumber
      this.getPage()
    }
  }
  nextPage() {
    this.setPage(this.pageNumber + 1)
  }
  prevPage() {
    this.setPage(this.pageNumber - 1)
  }
  getPage() {
    if (!this.rendering) 
    {
      this.rendering = true
      this.pdf.getPage(this.pageNumber).then(this.renderPage.bind(this))
    }
  }
  renderPage(page) {
    const viewport = page.getViewport({scale: 1})
    this.canvas.height = viewport.height
    this.canvas.width = viewport.width
    page.render({ canvasContext: this.context, viewport }).promise
      .then(() => {
        if (this.afterRendered) 
        { 
          this.afterRendered(this.pdf.numPages, this.pageNumber) 
        }
        this.rendering = false
      })
  }
}
const myPdf = new MyPdf(document.getElementById('the-canvas'))
myPdf.setAfterRendered((numPages, pageNumber) => {
  document.getElementById('page').innerText = `${pageNumber} / ${numPages}`
})
document.getElementById('next').addEventListener('click', myPdf.nextPage.bind(myPdf))
document.getElementById('prev').addEventListener('click', myPdf.prevPage.bind(myPdf))
myPdf.loadDocument('lib/slides.pdf')


```


# 成果物

https://embed.plnkr.co/plunk/h64V8ixZvrQwJScd


以上。
Could not configure the build properly (pkg_config). Please install either the `pkg-config` utility or the `pkg-config` rubygem.

## はじめに

Railsでbundle intall実行時に出るエラーの対応方法です。
コンソールの末尾には下記のように表示されました。

`An error occurred while installing sqlite3 (1.6.3), and Bundler cannot continue.`

## 内容

### 環境

- macOS 13.4
- Apple M1
- Ruby 3.2.0
- Bundler version 2.4.18
- asdf v0.13.1

### 解決方法

- `brew install pkg-config`を実行してから
- `bundle install`を再度実行

### 原因

エラーメッセージを添付します。

```sh
$ bundle install

...省略...

Building sqlite3-ruby using packaged sqlite3.
Extracting sqlite-autoconf-3420000.tar.gz into tmp/arm64-apple-darwin22.5.0/ports/sqlite3/3.42.0... OK
Running 'configure' for sqlite3 3.42.0... OK
Running 'compile' for sqlite3 3.42.0... OK
Running 'install' for sqlite3 3.42.0... OK
Activating sqlite3 3.42.0 (from /Users/takuzo/.asdf/installs/ruby/3.2.0/lib/ruby/gems/3.2.0/gems/sqlite3-1.6.3/ports/arm64-apple-darwin22.5.0/sqlite3/3.42.0)...

Could not configure the build properly (pkg_config). Please install either the `pkg-config` utility or the `pkg-config` rubygem.

*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

...省略...

An error occurred while installing sqlite3 (1.6.3), and Bundler cannot continue.

In Gemfile:
  sqlite3
```

ポイントは下記ですね。

> Could not configure the build properly (pkg_config). Please install either the `pkg-config` utility or the `pkg-config` rubygem.

ビルドを適切に構成できないからpkg_configを入れてくれとのことでした。
gemを入れてみたのですが上手く動かず、homebrewでインストールしたら上手く動きました。

### 補足：pkg_configとは

[Wikipedia pkg-config](https://ja.wikipedia.org/wiki/Pkg-config)

> pkg-configとは、ライブラリを利用する際に必要となる各種フラグやパス等を、共通したインターフェースで提供でするための手段である。

ビルド時に必要なライブラリやヘッダの所在などの情報を環境変数から取得する仕組みです。
今回はこれがなかったためにMakefileが作れずインストールに失敗していました。

### 参考

下記を参考にさせていただきました。

- https://ja.wikipedia.org/wiki/Pkg-config
- https://en.wikipedia.org/wiki/Pkg-config
- https://qiita.com/tomoyuki-nakabayashi/items/cab28ff7ccd717ae89cd
Swift&Metalで綺麗なクリスマスツリーを作る

## 概要

Life is Tech Advent Calendar Day7 の記事です！
メンターのゆるゆるです！

SwiftとMetalを使って流体シミュレーションで簡単にアートが作れるFluidSignageというmacOSアプリを作ってみました。
このアプリに実装した機能、そして内部実装についても軽く紹介していこうと思います。
流体を使ったアート表現や映像を作りたい、という方はぜひ見てみてください！

## とりあえずデモ

<iframe width="560" height="315" src="https://www.youtube.com/embed/Vs1XDhC_lNo?si=wwhgojff29L_Vzni" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

## FluidSignageアプリの使い方

アプリを起動するとこんな画面が出てきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/567236/2fdbd2b9-e58f-7c9c-045b-0da85864923d.png)

ここで、「セルの画像」と「セルの色画像」というボタンがあるので、それらをクリックしが流体アートにしたい画像を設定します。

「セルの画像」には下のような画像を設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/567236/1ccfa75b-ef48-fac2-0935-0e91fda40cb1.png)

「セルの色画像」には下のような画像を設定します。

![treeColor.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/567236/4c2c5e68-0d17-978e-6a07-e63d96d16120.png)

これらの画像を設定すると、自動的に流体シミュレーションが始まり、先程の動画のような綺麗なアニメーションが再生されます。

## 入力画像の作り方

Parameter Inspectorの画面でこのようにセルの種類を選択することができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/567236/4eae0e4f-cc9c-0efd-598f-c568eceb6c64.png)

セルの種類
- 流体：流体が流れるセル
- Out：流体が出ていくセル
- In：流体が入ってくるセル
- Spawn：流体が発生するセル
- 壁：壁

例えばInのセルを作りたければ、このようにInを選択した上で流入方向と流入速度を設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/567236/6879302d-8a81-26e1-361a-a49f1d528db1.png)

すると、画面上部にカラーコードが生成されます。
このカラーコードの色を使ってこのように色を塗っていくことでセルの画像が完成します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/567236/606c1724-33a5-8729-a923-f5deb7ffb258.png)

色画像に関しては、パーティクルが発生したときにそのパーティクルの色が、発生した座標の色画像のピクセルの色になります。

## 内部実装

流体シミュレーションには「格子ボルツマン法」という手法を用いています。
実装が簡単な上に並列計算に適していてとても高速なアルゴリズムです。
また、他の流体シミュレーションのアルゴリズムよりも渦ができやすく映えやすい気がしています。

今回のクリスマスツリーの映像では40万個のパーティクルをリアルタイム(60fps)でシミュレーションしています。
CPUのみで40万個のパーティクルをリアルタイムで計算するのは現実的ではないので、シェーダーというツールを使って高速化しています。
今回の場合は、シェーダーにはMetalを用いており、アプリ全体はSwiftで書いています。

シェーダーを使った物理シミュレーションや並列計算に興味がある方は、GPGPUと検索してみると面白いと思います。

## さいごに

メタラー(Metalでシェーダーを書く人)増えるといいな
Ubuntu 24.04LTS 開発速報2023年末版!!!!!! 第1回 22.04LTSからの変更点

# はじめに
こんにちは。くりもちです。全国学生対抗戦AdventCalendar 2023の8日目の投稿です。今回から、Ubuntu 24.04LTSの2023年末時点での情報をお伝えするシリーズを開始します。第1回では**22.04LTSからの変更点をリリースノートからお伝えします。**

# 22.04LTSからの変更点
不明なところは空欄にしています。

|変更点|22.04LTS|>|24.04LTS|
|----|----|----|----|
|GNOMEのバージョン|GNOME42|>|GNOME44|
|Linuxカーネルのバージョン|5.17|>|6.x|
|GCC(GNUコンパイラーコレクション)のバージョン||>||
|Pythonのバージョン||>||
|Perlのバージョン||>||
|LLVMのバージョン)||>||
|デフォルトのインストールソフト|完全|>|最小限|
|ZFSガイド付きインストール|なし|>|あり|
|TPMでバックアップされたFDE(フルディスク暗号化)|なし|>|あり|
|設定ファイルの場所|/etc/netplan/01-...|>|/lib/netplan|
|NetworkManagerのデフォルトのストレージバックエンド||>|Netplan|
|ADSys Active Directory証明書の自動登録|なし|>|あり|
|インストーラー|Ubiquity|>|Ubuntu Desktop Installer|
|アプリセンター|SnapStore|>|UbuntuAppCenter
|ファームウェアのアップデーター||>|Firmware Updater|
|Firefoxのバージョン|103|>|120
|LibreOfficeのバージョン||>||
|Thunderbirdのバージョン||>||

他にも新機能やバグ修正があるそうですが、時間と記事の長さの都合上詳しくは[24.04LTSのリリースノート](https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890)でご覧ください。

# このシリーズについて
最後に、このシリーズの構成です。
このシリーズは**第1回から第4回まであり**、今回の第1回は22.04LTSからの変更点を、第2回はインストール方法などを、第3回はUbuntuフレーバーの新機能を、第4回では開発状況とこれからの開発予定についてお伝えします。**乞うご期待ください**(完結は12月18日を予定しています)。
Ruby芸160チャレンジ(#9)ログ上の日付文字列に対する範囲抽出

## この記事は何
[shellgei160を通じて言語習得 Advent Calendar 2023](https://qiita.com/advent-calendar/2023/learning-via-shellgei160)に参加しています。

書籍「シェル芸ワンライナー160本ノック」の例題をRubyで解いてみて、Rubyの学習に役立てようとするものです。

例題はこちらのリポジトリで公開されているものに限ります。
https://github.com/shellgei/shellgei160

## 実行環境など
- Docker image: ruby:3.0.2
- 上記リポジトリをクローンした上で、リポジトリのルートディレクトリ直下に`answer-ruby`ディレクトリを作り、その中に解答となるファイルを作成していきます。

## 今回のテーマ
https://github.com/shellgei/shellgei160/blob/master/answer/9.md

```bash
$ cat log_range.log | sed -n '/24\/Dec\/2016 21:..:../,/25\/Dec\/2016 03:..:../p'
```

時間順にソート済みのログファイルに対し、開始日時にマッチした行から、終了日時にマッチした行までを抽出します。`sed`の使い方の勉強になりますね。

## 解
```ruby
re_start = %r{24/Dec/2016 21:..:..}
re_end = %r{25/Dec/2016 03:..:..}

records = File.readlines('qdata/9/log_range.log')
idx_start = records.index { |record| record.match(re_start) }
idx_end = records.index { |record| record.match(re_end) }
puts records[idx_start..idx_end]
```

愚直に指定した文字列にヒットするインデックスを調べ、その範囲を抽出しました。

もし関数型っぽくやるなら、(left, matched, right)みたいにログを分割する関数を作って、startの方で (matched, right) を残し、その結果に対してendの方で (left, matched) を残す、とかでも良さそうです。

## 所感
- 条件に合うインデックスを探すには `array.index {block}`。なるほど。
- メタ文字を含む正規表現には`%r{ }`が便利。なるほど。※`{`じゃなくても`@`とか他の記号でも良い。
VSCodeのPrettierでTypeScript5.2（using句等）をサポートさせる 

TypeScript5.2で導入されたusing句を使ってみたところ、VSCodeのPrettierが以下のようにエラーを吐いて整形してくれませんでした。

```
SyntaxError: Unexpected keyword or identifier. (17:5)
> 17 |     using db = await DataBase.connect();
```

色々調べたところTypeScript5.2はPrettier V3からサポートされているようです。

Support TypeScript 5.2 · Issue #15004 · prettier/prettier · GitHub
https://github.com/prettier/prettier/issues/15004

Prettier V3を使用させる場合は以下の手順が必要でした（勘違いがあればご指摘ください）。

1. 以下のコマンドでプロジェクトにPrettier V3をインストールする

    ```
    npm install prettier@3
    ```

2. プロジェクトの`.vscode/settings.json`に以下の設定を追加（パスはプロジェクトごとに合わせる）

    ```:json
    {
        //
        // 省略
        //
        "prettier.prettierPath": "./path/to/node_modules/prettier"
    }
    ```
MDN の全ページの Browser Compat Data (BCD) を一覧するツールができました

# はじめに

この記事は [2023 年の MDN 翻訳 Advent Calendar](https://qiita.com/advent-calendar/2023/mdn-translation-community-japan) 向けに作成したものです。

こんにちは。debiru です。好きな Web ブラウザは Firefox で好きなエディタは Emacs です。Firefox のことを Fire**Fox** と書かれているのを見ると爆撃したくなります。同様に略称を Fx ではなく FF と書かれると何の略なのだろうって思ってしまいます。

さて、このアドベントカレンダーで数日前に「Firefox でも `:has()` 疑似クラスが使えるようになる」という話と「Firefox で未実装の `Intl.Segmenter`」の話をしました。

そこで、今日は、その他の「Firefox だけ未実装シリーズ」をお送りしたいと思い、Firefox だけ実装されていない機能を一覧するツールを作ってみました。

# できたもの：「BCD一覧表」

こちらです。

https://mdn-bcd.lavoscore.org/

このツールを使うことで、ブラウザの実装状況について色々調べることができます。

## 近々リリースされる Firefox によって、全ブラウザで使えるようになるもの

- [全ブラウザでサポートされているものを、Firefox 降順で表示](https://mdn-bcd.lavoscore.org/?chrome=NotNull&firefox=NotNull&edge=NotNull&opera=NotNull&safari=NotNull&safari_ios=NotNull&sort=firefox.desc)

少しスクロールすると、Firefox バージョン`121` の行が見られます。ここから、Firefox 121 の登場でようやく全ブラウザで使えるようになる機能がわかります。

![Firefox のバージョン 121 の登場によって、「iFrame の loading プロパティ」と「CSS の has 疑似クラス」が全ブラウザで使えるようになることがわかる。](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178936/3282b35e-9117-9765-d932-38e6991199ad.png)

iFrame の loading プロパティと、CSS の :has() 疑似クラスが次の Firefox リリースによって全てのブラウザで使えるようになりますね！

## Firefox だけ実装されていない機能

- [Firefox 以外ではサポートされているが、Firefox で未サポートのものを表示](https://mdn-bcd.lavoscore.org/?chrome=NotNull&firefox=Null&edge=NotNull&opera=NotNull&safari=NotNull&safari_ios=NotNull&sort=chrome.desc)

![700項目が Firefox のみ未実装ということがわかる。](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178936/d97369a5-ae7e-77dc-a915-c003e73fc743.png)

Firefox だけ実装されていない機能は 700 項目あることがわかりますね。

## Chrome だけ実装されていない機能

- [Chrome 以外ではサポートされているが、Chrome で未サポートのものを表示](https://mdn-bcd.lavoscore.org/?chrome=Null&firefox=NotNull&edge=NotNull&opera=NotNull&safari=NotNull&safari_ios=NotNull)

なんと、0 件です。「Chrome だけが実装されていない機能」というものはないということです。

ただこれは、「他の全てのブラウザでサポートされている機能」に限った話です。

![Firefox では実装されているのに Chrome で実装されていない機能は 845 項目あることがわかる。](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/178936/a01cd3a8-25b4-5493-e049-9cafc177defc.png)

例えば、Firefox では実装されているのに、Chrome 含むその他のブラウザでは実装されていないという機能は 845 項目あります。

# Firefox だけ実装されていない待望の機能

数日前のアドベントカレンダーで紹介した `:has()` 疑似クラスや `Intl.Segmenter` の他に、何か気になる機能はあるでしょうか。面白いものがあれば紹介したいと思ったのですが、何かあるかな。

もし「この機能」を待望しているというものがあればコメントなり Twitter なりで教えてください！コメントいただけた場合は、その機能の実装状況についての詳細なレポートをお届けしたいと思います。

# さいごに

このツール、二晩で作ったのですが、開発をしていたらアドベントカレンダーを書くのが遅くなってしまいました。12 月 7 日のアドベントカレンダーとしてこの記事をお届けします。

明日は別の方の [2023 年の MDN 翻訳 Advent Calendar](https://qiita.com/advent-calendar/2023/mdn-translation-community-japan) が予定されています！もっと他の人も参加してほしいな……。というか 9 日目以降、ネタがないのでもう私は書けないかもしれません。

そんなわけで、MDN に少しでも興味をお持ちの方がいたら [MDN コミュニティ Slack](https://mozilla-japan.github.io/mdn-translation-guide/meetup/community-slack.html) にぜひ参加してくださいね。MDN の記事をメンテナンスし続けるにはあなたの力が必要です。

そうそう、翻訳作業をしなくても MDN に貢献することができます。修正や翻訳されるべき記事を見つけて報告するだけでよいのです！報告は [MDN 日本語コミュニティリポジトリの Issue](https://github.com/mozilla-japan/translation/issues) まで、お気軽にお寄せください！コントリビューターはしばしば、次にどの記事を翻訳しようかと悩んでいます。そんなとき、あなたの報告があれば、コントリビューターはそのトピックに着手することができるでしょう。

皆様からの MDN への貢献をお待ちしております。

おわり。
なぜ容量だと1GB=1024MBなのに速度だと１GB/s=1000MB/sなのか？

# はじめに
えか太郎です。JK（情報大好き高校生）です。本記事ではタイトルにあるように「なぜ容量だと1GB=1024MBなのに速度だと１GB/s=1000MB/sなのか？」という疑問についてまとめました。
。
# そもそもなぜ1024という数が出てくるのか
おそらくQiitaを見るような人はコンピューターは2進数で動いているためキリの良い２進数で１K＝１０００（キロ）に一番近いのが2^10 = 1024だからという理由を知っていると思います。後述しますが二進数で数字を扱う場合２＾ｎで表せる数はすごくシンプルに二進数でかけるのです。
### もし1024が1000のなら
* １K＝1000を2進数で表すと「001111101000」。
＞人間には複雑。
*    １ｋ＝1024を二進数で表すと「010000000000」。
＞わかりやすい。
##### このような理由で昔決められて以降、ずっとこの規格は生きているためいまも１K＝1024なのだ
### 1024を1000にしようとする動き
コンピューター上で使われている1024を1000にするために１KB（キロバイト）の代わりとして１KIB（キビバイト）というものが作られた。しかし、普及率はいまいち。

# 本題：なぜ通信速度では1Kが1000なのか？
まずそもそもの前提としてSI接頭語においての1k=1000=10^3であり2^10ではない
国際単位系（SI）第8版（2006年）国際文書日本語版 に、これについての記述があります。

    これらの SI 接頭語は 10 の整数乗を表す.
    それらを決して2のべき乗を表すために用いてはならない
(つまり,1キロビットは 1000 ビットであり,1024 ビットではない)

コンピューターのように1k=1024は本来の用法ではなく、1k=1024は二進数で動作するコンピュータ（CPU、RAMなどなど）でのみ使用されるものなのです。
通信をする際には人間がそれらを確認する必要は少ないため2進数で表記したとき美しい1024(2^10)を用いる必要がありません。したがって通信速度での単位は1k=1000と策定されており１GB/s=1000MB/sとなる。

## 謝辞
正直言って結局SI接頭語は基本的に10のN乗といった形で使いコンピュータのように2の10乗で1024＝1kとして使うのは正しい使い方ではないという結論に帰結しそれらしい理由しか導くことができませんでした。間違いがある場合は教えてくださると助かります
form要素のonSubmit属性について

:::note
`onSubmit`属性は、HTMLの`form`タグに使われるイベントハンドラー属性。
フォームが送信される際（例えば、ユーザーが送信ボタンをクリックしたり、Enterキーを押したりした場合）に指定されたJavaScript関数を実行する。
`onSubmit`を使用する主な目的は、フォーム送信前にデータを検証したり、デフォルトのフォーム送信動作（通常は新しいページへのリクエストやページの再読み込み）を防止すること。
:::

使用例
```html
<script>
  function handleSubmit(event) {
    event.preventDefault(); // デフォルトのフォーム送信を防止
    alert('フォームが送信されました！');
  }
</script>

<form onSubmit="handleSubmit(event)">
  <input type="text" name="name" required>
  <input type="submit" value="送信">
</form>
```
送信しようとすると、handleSubmit関数が呼び出され。アラートが表示される。
ミリ秒？マイクロ秒？接頭語による単位の違いまとめ

# はじめに
えか太郎です。
先日投稿したpingコマンドについて書いたときに思った応答速度の19msのミリ秒って何？と思ったので情報について学ぶ上で避けられない接頭語について勉強したときの備忘録です

https://qiita.com/EkaTaro3/items/4c13b5bed593bbd424aa

https://qiita.com/EkaTaro3/items/a111d6cb13e848a4fac1
# 接頭語とは
接頭語とは大きすぎる数または小さすぎる数を表すときに単位に一つだけつけることでその単位自体を視覚的にわかりやすくするためにあります。国際単位系（SI）では24個の単位が設定されています。（2022年以前は4個すくない20個でした）
## 実用例
### T（テラ）＝10^12を使う
以下の式を見てほしい
##### 1000000000000B/s = 1TB/s
0ばかりで数えたくないような13桁の数がわずか1桁で表示することができるようになりました。わかりやすくなるだけではなくヒューマンエラーのリスクを減らすという利点もあります。
### 逆に接頭語を使わないという選択（マーケティング的な選択）
また以下の式も見てください
##### 1000GB（1024GB） = 1TB
知識のない人が見た場合どちらのほうが大きいと判断するでしょうか。単純に考えたら「1000＞１」と思う可能性がそれなりにありそうだと私は勝手に思っています。

さらに、これは2010年代中頃のチラシに多く見られた表現ですがTB（テラバイト）の名称の普及度があまり高くなかったからかあえて1000GBと販売するものも見られました。必ずしも接頭語を使えばわかりやすくなるわけではないことに留意したほうが良いのではないでしょうか？

![スクリーンショット (14).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3120367/4e7261f1-8e32-f325-90d2-49b6801d5ddb.png)
# 非常に短い時間を表す単位
### 1s
基準となる接頭語を付けないもの。10^0と考えることもできる。
### 1ms(ミリ）
10^-3秒＝0.001秒
人間が反応できる速度は0.2秒程度とされているため相当早いことがわかる。1000ミリ秒が1秒と覚えれば問題ないと思います。
### 1μs（マイクロ）
10^-6秒
### 1ns（ナノ）
10^-9秒
# 先述したように接頭語は24個ある。

![si.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3120367/7f5891eb-c76b-5807-cf2d-89b930e4680b.jpeg)
ネットのまとめられた表を見たほうが理解しやすい。
#### 画像の出典
https://kotobank.jp/word/SI%E6%8E%A5%E9%A0%AD%E8%AA%9E-36433
エンジニアコミュニティとメンター

[CA Tech Lounge](https://www.cyberagent.co.jp/careers/special/students/tech_lounge/) にて、バックエンド職種のメンターをやっている しゅん です。

サイバーエージェント社員としての実業務の傍ら、バックエンド職種のメンターをしていて普段考えていることを書きます。

# メンターのミッション
サーバントに尽きます。

いわゆる「メンター」の言葉の意味通り、会員のメンタリングや活動支援がミッションの大部分を占めます。
同時に、ことエンジニアコミュニティにおいては、活動の主体である会員自身による取り組みや文化の醸成をサポートするのがメンターのミッションだと考えています。

# メンターの活動領域
そういう意味で、会員の目標達成を指導的に管理したり、コミュニティの活動を主導するようなことはあえてしないようにしています。（あくまで「トレーナー」領域にまで手を出さないようにしているという意味です。）

会員から声が上がれば最大限にサポートし、会社が提供しているエンジニアコミュニティとして小石になりそうなものは事前に取り除き、並走する形で必要な活動をしているイメージです。

# メンターのつらさ
「トレーナー」業をしないことが歯がゆさを生むことがあります。

エンジニアコミュニティを積極的に盛り上げていきたいと思いつつも、自分が旗を振って何かに取り組むのは何か違う気がしています。
じゃあ、会員にそういう気持ちになってもらうために画策するのも何か違う気がしています。

正解がない問いですが、メンターとしてのかかわり方の線引きでかゆいところに手が届かない思いをすることがあるということです。

# メンターの楽しさ
純粋にエンジニアコミュニティに関われているが故、技術的な刺激や関係性の構築には楽しさを感じます。

会社のもとでのエンジニアコミュニティという文脈では、このコミュニティを通じて知り合った社員がいて実業務に結び付くような情報共有ができた事例もありました。対外のエンジニアコミュニティにはなりますが、内部の横の繋がりの拡大にも寄与しているのは間違いないです。その点で、実業務では関わりようのないコミュニティの広がりに楽しさを感じています。

# メンターとしての今後
もっといろいろな会員と繋がりたいです。

会社が提供しているエンジニアコミュニティに応募をする方というのは、大小あれど志を持っています。技術的な志もあれば、ビジョナルな将来像もあります。こうした方々と思いやビジョンを共有するのは知的好奇心をかき立てられます。

そういう意味でも、会員に対するサーバントを続けてコミュニティのより一層の活性に期待します。
gitをインストールしたらやるべきこと

# はじめに
Gitをインストールした際に、毎回設定している事をまとめました。
すべて必要というわけではないので、各自お好みで設定してみてください。

# 設定一覧

## ユーザー名とメールアドレスの設定

まずはお馴染みの設定から。
コミットログとして表示されるユーザー名とメールアドレスを設定します。

```bash
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
```

適当な名前やメールアドレスでも登録できますが、基本的にはgithubなどに登録している情報と合わせるようにしましょう。

## デフォルトのエディタの設定

コミットする際などに表示されるエディタを変更します。

```bash
git config --global core.editor vim
git config --global sequence.editor vim
```

この`vim`の部分には他に、`emacs`, `nano`, `'code --wait'`, `hx`, `micro`などが指定できます。
※`'code --wait'`はVSCodeの事です。末尾の`--wait`オプションを指定するとファイルを閉じるまで待機させることが出来ます。

## デフォルトのブランチ名の変更

デフォルトで作成されるブランチ`main`に変更します。

```bash
git config --global init.defaultBranch main
```
`git init`を実行した際に自動的に`master`ブランチが作成されてますが、現在は`main`を使うことが多く、毎回ブランチを削除するのは面倒ですよね。

※Gitのバージョンが 2.28.0より前の場合、この機能は利用できません。

## 改行コードの設定

改行コードを自動的に変換するようにします。

```bash
# Mac及びLinuxの場合 (LF)
git config --global core.autocrlf input

# Windowsの場合 (CRLF)
git config --global core.autocrlf true
```
チームで開発している場合、OSがmacの人もいればWindowsの人もいます。
そうした場合に改行コードの問題はつきものですが、自動変換をオンにすることで、意識することなく進められます。
チーム全員がWindowsの場合は`false`と指定しても問題ありません。


## コミットメッセージにテンプレートを設定

毎回お決まりで入力しているメッセージがある場合、テンプレートを利用することで、`git commit`を実行した際にテンプレートを呼び出すことが出来ます。

```bash
git config --global commit.template ~/.config/git/.gitmessage
echo 'テンプレート化したいメッセージ' > ~/.config/git/.gitmessage

# プロジェクト毎に指定したい場合
git config --local commit.template .gitmessage
echo 'テンプレート化したいメッセージ' > .gitmessage
```

チーム開発などで、コミットメッセージのフォーマットを徹底したい場合に便利です。

## グローバルな.gitignoreの設定

`.gitignore`をグローバルに設定します。
デフォルトでは`~/.config/git/ignore`の内容が反映されます。

```bash:~/.config/git/ignore
*~
.DS_Store
```
`*~`はExcelなどのロックファイル、`.DS_Store`はMacお馴染みのファイルです。


任意のファイルを指定したい場合は以下のように指定出来ます。

```bash
git config --global core.excludesfile ~/.gitignore
```

基本的にはプロジェクト毎に管理することが多い為、利用している人は少ない印象です。


## コマンドのタイプミス時にいい感じに実行してくれるように設定

コマンドの綴りミスがあった際にGitは正しいコマンドを提案してくれますが、実行までしてくれるようになります。
ミスタイプから実行までの感覚を0.1秒単位で指定します。

```bash
git config --global help.autocorrect 1
```
私はよく`checkout`をミスタイプすることが多いです。


# 参考

https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E8%A8%AD%E5%AE%9A

https://qiita.com/ucan-lab/items/9b442e042988e2d7a35d

https://qiita.com/ueokande/items/e0409219e7c68e4277b9
ドキュメンテーションコメントに画像を入れたら便利だった話

# はじめに
この記事は、Swift Advent Calendar 2023 の 5 日目の記事になります。

Swift とは少し離れてしまいますが、とあるコメントアウトの活用について思いついたので、書いていきます。

# ドキュメンテーションについて

皆さんはドキュメントコメント、書いていますか？

Swift ではドキュメンテーションを Markdown で書くことができます。

詳細については、iOS Advent Calendar 2023 2 日目の記事をご参照ください。

https://qiita.com/KaitoMuraoka/items/b2588ff9fbf1100610b3#markdown

# ドキュメンテーションに画像を入れると便利だった話

アプリケーションの作成やライブラリを作成していると、「言葉で説明しにくい」という場面があります。
例えば、図形や info などの GUI での設定が必要な場合など。

先日、実際に仕事中で「iOS のアラートを修正する作業」をしていました。
そのコードにはコメントアウトで「タイトルとメッセージ、そして OK ボタンのみを表示する」とありました。(実際はもう少し複雑でした。)

そのままでもわかるのですが、直感でわかりにくいと考えました。
ドキュメンテーションが Markdown で書けるのを思い出し、「画像を入れると便利では？」と考え、ドキュメンテーションに画像を入れると便利だったので紹介します。

# ドキュメンテーションに画像を入れる方法

通常の Markdown に画像を挿入するのと全く同じ方法で挿入できます。
公開されている画像のリンクを貼ることで表示されます。

```swift
/**
こんな感じで表示することができます。

 ![sampleAlert](https://docs-assets.developer.apple.com/published/0cff729929299215768582c2a1e8a21c/SwiftUI-Alert-OK~dark@2x.png)
 */
```

または以下のように書いても出力されます。

```swift
///
///こんな感じで表示することができます。
///
///![sampleAlert](https://docs-assets.developer.apple.com/published/0cff729929299215768582c2a1e8a21c/SwiftUI-Alert-OK~dark@2x.png)
///
```

出力結果は以下のようになります。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/707293/72387be3-02eb-e45b-2563-19d7bc150df7.png" width=50%>

## 使用する場所
上記の通り、「言葉で表現し難い処理」で使うのが良いです。
例えば、アラートや GUI 操作するもの。

また、コードブロックで書くことが多くなるので、Utils などの tools を格納する場所で使用することをお勧めします。

つまり、⌥ + クリックでプロパティやメソッドを確認する際です。

## 問題点

問題点として、公開されている画像ではないと表示できない点です。

サンプルの画像は、公式リファレンスからリンクを取得して表示しました。

https://developer.apple.com/documentation/swiftui/alert#overview

そのため、Private のプロジェクトの場合は代替の画像を Public リポジトリか、技術記事等から選ぶ必要があります。
IchigoJam で砂嵐もどき

<iframe width="560" height="315" src="https://www.youtube.com/embed/6mgOsb9k4I4?si=prdA8kiZaCp3mCaI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

「テレビも既に砂嵐」…？
そういえばうちのテレビ環境、放送休止のときなぜかケーブルテレビ局への連絡を要求してくることがあるんだよなあ。
どういう連絡をするのがいいんだろう…？

![放送休止時にケーブルテレビ局への連絡を要求するテレビ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99656/0f656c06-1f96-e543-8e43-85853eedce35.jpeg)

というわけで(？)、[IchigoJam](https://ichigojam.net/) で砂嵐もどきを作ってみた。

※IchigoJamはjig.jpの登録商標です。

# プログラム

```
10 ' ｽﾅｱﾗｼ
20 CLS
30 FOR I=#700 TO #7FF
40 POKE I,0
50 NEXT
60 FOR I=#900 TO #BFF
70 POKE I,RND(#20)+#E0
80 NEXT
90 FOR I=#700 TO #7FF
100 POKE I,RND(#100)
110 NEXT
120 GOTO 90
```

このプログラムは、[CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/deed.ja) でライセンスする。

# 解説

1. 最初の見た目が悪くならないよう、画面を0で埋め、続いてキャラクターRAMを0で埋める。(20～50行目)
2. 画面をキャラクターRAMに対応する文字でランダムに埋める。(60～80行目)
3. キャラクターRAMをランダムに書き換える処理を繰り返す。(90～120行目)

よく見ればパターンが使い回されているのがわかるかもしれないが、よく見なければ画面全体がランダムなドットで埋まっているように見えるだろう。

# 実行結果

IchigoJam Q では、画面 (キャラクターRAM) を少しずつ書き換えているのが目立ってしまった。

<iframe width="640" height="480" src="https://www.youtube.com/embed/zmEhF1knhL0?si=etUSGpydQN_TtqyI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

IchigoJam R では、同じキャラクターコードが隣接している場所では繰り返しが目立つが、書き換え位置は目立たなかった。

<iframe width="640" height="480" src="https://www.youtube.com/embed/rKDByYLWjFw?si=I1KGVxG36R3zRf4n" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

# 改良

同じキャラクターコードが隣接している場所で繰り返しが目立ったので、同じキャラクターコードが8方向で隣接したら弾く処理を追加した。

```
10 ' ｽﾅｱﾗｼ 2
20 CLS
30 FOR I=#700 TO #7FF
40 POKE I,0
50 NEXT
60 FOR I=#900 TO #BFF
70 POKE I,RND(#20)+#E0
80 IF I%32>0 IF PEEK(I-1)=PEEK(I) GOTO 70
90 IF I>=#920 IF PEEK(I-32)=PEEK(I) GOTO 70
100 IF I%32>0 AND I>=#920 IF PEEK(I-33)=PEEK(I) GOTO 70
110 NEXT
120 FOR I=#700 TO #7FF
130 POKE I,RND(#100)
140 NEXT
150 GOTO 120
```

このプログラムは、[CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/deed.ja) でライセンスする。

IchigoJam R で実行すると、以下のようになった。

<iframe width="640" height="480" src="https://www.youtube.com/embed/QImJgg1Ixls?si=-SEk0HFiXGAjMQt9" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
初めてのチーム開発〜最終章〜

---
2023年Apprentice第2期生としてチーム開発-第1回目-を行いました！

このブログは私が所属したチームが様々な課題を解決し、アプリを作成する一つの物語です。

私たちは、スケジュールアプリ「スケミ」を開発しました！

スケミの概要は[コチラ](https://qiita.com/HACHI32/items/06bf7c07f72061a16615)

---
さて、私たちの物語もここで最終章を迎えます。

[第2章](https://qiita.com/HACHI32/items/88748d92385c5ca25438)では私たちはガントチャートを作成し、リーダーを決めました。

しかし、実装の期限を決めたにもかかわらず、開発はなかなかスケジュール通りに進みませんでした。

このような時こそ、リーダーの役割が重要になります。チームリーダーとして、私が行ったことは以下の通りです。

- アプリ開発の進捗確認：どこまで完成していて、次に何をするかを把握。
- 毎日10分のミーティング提案：プロジェクトの進捗と問題点を迅速に把握するため。
- プルリクエストの確認：コードの品質と統合の管理。
- ゴールの再確認：プロジェクトの目標を明確に保つ。

私が重視したのは、アプリの完成だけでなく、メンバーがエンジニアとして成長することでした。Apprenticeプログラムに参加しているのは、エンジニアになるためです。チーム開発では、メンバーそれぞれがエンジニアとしてのエピソードを作ることが大切です。

期限があるからといって、ただアプリを開発するのではなく、エンジニアとしての経験を積むことが目的であることをチームメンバーと再確認しました。

その後、Team Dodoのメンバーは、アプリを形にするために必死に開発しました。形にしたい、動かしたいという強い意志があったからです。

しかし、さらにまた問題が発生します。

GitHubでのチーム開発の仕方がわからない状況で進めてしまったため、コンフリクトが発生しました。ミーティングで一緒に調べ、を無事解決することができました。

結果、私たちは自分たちが思い描いていたアプリを完成させることができました!!

そして、いよいよプレゼン当日です！

チームメンバーが最高のプレゼンをしてくれたのですが、いろいろな思いが頭をよぎります。

- チーム開発の過程をリサーチしてから開発を始めればよかった事
- コーディングルールが曖昧だった事
- お互いの技術レベルを確認してなかった事

しかしこの経験は、私たち全員にとって価値あるものです。上記を熟知していればもっと素晴らしいものになったかもしれません。その反面、わからなかったからこそ何が起きるかを知る事が出来ました。

プレゼンも終わり、メンターさんや２期生からの投票の集計が行われます。

他のチームのアプリもとても素晴らしかったです。それぞれに着眼点が違い、あったらいいな、使いたいなと思えるものばかりでした。

ということで結果発表！！！

なんとTeamDodoは受講生からの評価が最も高いチームに送られる『Best Student Award』を受賞しました(´;ω;｀)!!

本当に嬉しかったです。

これで私たちのチーム開発の物語は終わりますが、まだまだ私たちのエンジニアへの道は続きます。この経験は次回のチーム開発にも生かして行きたいと思います！

TeamDodoのメンバーのみんな、本当にありがとうございました。これからも共にエンジニアを目指す仲間として精進していきましょう！


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3579151/f5194707-d3ec-f773-6066-713718a1d187.png)
curl でクエリパラメータをURLエンコーディング

ISO8601形式の日付をクエリパラメータで受け取るAPIがあるとして, curl で次のように呼び出そうとすると, 失敗します.

```bash:curlによるリクエスト
curl -v -G \
    -d"until=2023-12-31T00:00:00+09:00" \
     "http://localhost:8000/samples"
```

```plaintext:エラー
{
  "detail": [
    {
      "type": "datetime_parsing",
      "loc": [
        "query",
        "until"
      ],
      "msg": "Input should be a valid datetime, invalid timezone sign",
      "input": "2023-12-31T00:00:00 09:00",
      "ctx": {
        "error": "invalid timezone sign"
      },
      "url": "https://errors.pydantic.dev/2.5/v/datetime_parsing"
    }
  ]
}
```

URLエンコーディングによって, `+` がスペース文字に置き換えられているためです.

その場合は, `-d` オプションの代わりに `--data-urlencode` オプションを使うといいようです.

```bash:curlによるリクエスト 2
curl -v -G \
    --data-urlencode "until=2023-12-31T00:00:00+09:00" \
     "http://localhost:8000/samples"
```

このくらいのこと, curl がよしなにやってくれているものだと思ってましたが, そうではなかったようです.

なお, httpie ならURLエンコーディングを意識せずにリクエストできます.

```bash:httpie によるリクエスト
http get "http://localhost:8000/samples" \
    until==2023-12-31T00:00:00+09:00
```
文章力の基本を読んで Part1

# 文章力の基本を読んで

## はじめに
- 昨今、チャットコミュニケーションが増える中で自分の文章力がひどいものであると認識するときがいくつもある
- これを読んでまとめることで文章力向上を目指しつつ、こんな本があるんだという気づきを得られる人が増えると嬉しい

## この本はなに？
- 伝わりにくい文章を例に挙げて、それの修正と何が伝わりにくいのか。なぜこのように書き換えたのかを解説してくれるヒントを77個乗せてくれている

## 第1章を読んで(ヒント1~4)
:::note info
1. 文章は短く区切ってだらだら書かない
2. 5W1Hを意識して誤解を生まない文章を作る
:::

### 1. 文章は短く区切ってだらだら書かない
- 句点(。)が付いておらず、区切りがわかりにくい文章は
    - 言い切る文章を避ける傾向があるという話もしています
        - 言い切ることで断定を避け責任から逃げる傾向がある
        - そのような文章は長くなりがちという話もしています
        ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266246/aa80cdb4-0b3c-d1fc-af86-86b37ea5b770.png)

- 一度に多くの情報を運ばない
    - 多くの情報を入れてしまうと、読み手に大きな負担をかけてしまいます
        - 書き手としてはバーッと書いてしまったほうが楽なんですよ
        - ただ、読み手に伝わらなければ意味がありません
        - 不要な情報を省いたり、適度に話す内容を区切って伝えましょう
        ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266246/674ec634-f379-d3fe-7c8f-428d26549a81.png)

### 2. 5W1HのWho,Whatを意識して述語との関係を明確にする
- Who,Whatを幹としてここがしっかりしていないと
    - 相手が考える必要がある文章が出来上がる
    - まずは、何の話をしているのか土台をしっかり用意して文章を作るようにしよう！


### まとめ
この回では、文章を短く区切ったり、Who,Whatを意識するなど普段の会話でも使えるようなテクニックが多かった気がします！
英語では、結論が先に来ることが多いので長くても理解しやすい。
しかし、日本語は長くなればなるほど結論が遠ざかる傾向にあるので注意したいですね
まずは、ここから意識できるようにしよう！
明日は正しい表現についての章になります。
金欠高校生はPythonでAPIを作ってみたい！

# PythonでAPIを作るなら

そもそもAPIを作るのにPythonである必要があるのかどうか、ということはかなり議論の余地がありそうですがPythonは何といってもほかの言語と比べて書きやすい！読みやすい！言語であり初心者に優しい言語です(個人の感想です)

他にも機械学習やデータの処理などPythonが得意としている分野の処理を組み込む予定があればPythonでAPIを作る需要はある程度あるのではないでしょうか

# なぜFastAPIの何が魅力的か

## 1. **高速で型安全:**
   - FastAPIはASGI（Asynchronous Server Gateway Interface）を採用しており、非同期処理により高いパフォーマンスを提供します。
   - Pydanticを使用してリクエストやレスポンスの型ヒントを提供することで、型安全性が向上します。
   (公式ホームページ曰く、Go言語にも匹敵する速さだとか)
   かなり早いといわれているGo言語に匹敵することはかなり魅力的なのではないでしょうか
   (この記事では実行速度の比較までは扱いません...)

## 2. **自動生成されたドキュメンテーション:**
   - FastAPIはSwagger UIとReDocをサポートしており、APIエンドポイントのドキュメンテーションを自動生成します。
   この機能のおかげて、ブラウザ上で動作テストができます、ログイン機能を実装してエンドポイントごとに制限をかける場合でもドキュメント上でログインしてAPIを実行することができます！
   フロントエンド実装前やちょっと動作確認したいときにはとても重宝します
:::note warn
本番環境ではこの機能をオフにすることを強く推奨します
```python
app = FastAPI(docs_url=None, redoc_url=None, openapi_url=None)
```
で無効化することができます
:::

## 3. **データバリデーションとシリアライゼーション:**
   - Pydanticを使用して、リクエストのデータバリデーションとレスポンスのシリアライゼーションを簡単に行うことができます。
   これによって、意図しないデータの入力が防げるので入力データの整合性が保たれ、安全性が向上します。
   
# なぜFastAPIなのか

#### 1. **Flask**
   - Flaskはシンプルで軽量なWebフレームワークであり、初学者向けや小規模なプロジェクトに適しています。
   - 一方でFastAPIは非同期処理や型安全性など、より高度な機能を提供します。

#### 2. **Django**
- Djangoは全体的なWeb開発フレームワークであり、ORMやテンプレートエンジンなどが組み込まれています。
    一方でFastAPIはAPI開発に特化しており、高速な処理や型安全性が強調されています。
    （大規模なプロジェクトだとDRFがよく使われているイメージです）

#### 3. **Express (Node.js)**
   - ExpressはNode.jsのWebフレームワークであり、非同期処理や柔軟性があります。
   - FastAPIとの違いは言語であり、Pythonを使用するかどうかが大きな違いです。
   Pythonの開発経験がある場合は、FastAPIをお勧めします

# FastAPIでHelloWorld

1. **FastAPIのインストール:**
   ```bash
   $ pip install fastapi uvicorn
   ```

2. **HelloWorldアプリケーションの作成:**
   ```python
   # main.py
   from fastapi import FastAPI

   app = FastAPI()

    # エンドポイントパスとメソッドの定義
   @app.get("/")
    # 引数がある場合はここで定義する   
   def read_root():
       return {"Hello": "World"}
   ```

3. **Uvicornを使用してアプリケーションの実行:**
   ```bash
   $ uvicorn main:app --reload
   ```

4. **ブラウザまたはcurlを使用して確認:**
   - [http://127.0.0.1:8000/](http://127.0.0.1:8000/) にアクセスするか、以下のようにcurlを使用して確認できます。
   ```bash
   $ curl http://127.0.0.1:8000/
   ```

これでFastAPIのHelloWorldが完成しました。
この例では、"/"エンドポイントにアクセスすると{"Hello": "World"}というJSONが返されることが確認できます

# 終わりに

今回は、簡単にFastAPIの布教をさせていただきました
プロジェクトにあった技術選定をするためにもいろいろなフレームワークに触っておきたいですね
【AWS】CI/CDの権限不足を防いで開発体験を向上する

クラウド環境の構成管理ツールとしてIaCを使う場合、GitHub ActionsやAWS CodeBuildなどを活用することで構成管理を自動化して運用の安定性を高めることができます。

しかし、**CI/CDパイプラインが権限不足でコケる**というのはあるあるなのではないでしょうか（ぼくは~~稀に~~よくにやります）
特にリポジトリの初期化や、CI/CD周りの仕組みを改修する際、修正のコミットを多く重ねて何度もトライ&エラーする必要が出るハメになったり・・・。

上記の悩みを解決するTipsを紹介します。
本記事ではAWSの利用を前提とします。

# TL;DL - AWS Providerのassume_roleを使おう

`provider "aws"`の設定に`assume_role`セクションを追加します。

```diff:provider.tf
provider "aws" {
  region = "ap-northeast-1"

+ assume_role {
+   role_arn = "arn:aws:iam::12345678910:role/role-to-assume"
+ }
}
```

これを使うと`terraform plan`や`terraform apply`の実行時に内部的にロールを切り替えて（assume role）処理を続行します。
切り替えた後のロールに権限不足がある場合、その時点で気づける**可能性があります**。しかし、これでも絶対に防げるとは限りません…。

通常CI/CDを自動化している場合、原則はローカルで`terraform apply`は実行せず`terraform plan`を確認するのみ、という運用ルールが考えられます。
`terraform plan`と`apply`とでは実際に実行するアクションは異なるため、やはり権限不足の可能性は残ることになります。

# 設定方法

上述の`assume_role`に指定するIAMロールの作成方法も紹介します。

## 前提知識：IAMロールの信頼関係

AWS IAMにおいて「あるIAMユーザー or ロールが別のロールを使用する（= **引き受ける**）」操作はAssume Roleと呼ばれます。
Assume Roleを実現するために必要な設定が信頼関係（または信頼ポリシー）で、引き受ける対象のロールに設定します。

## サンプルコード

このようなIAMロールをTerraformで作成する例です。
ローカル作業用にIAMユーザー（`kokado-iam-user`）を使っているケースを考えます。

参考 - [terraform-aws-modules/iam/aws | iam-assumable-role Submodule | Terraform Registry](https://registry.terraform.io/modules/terraform-aws-modules/iam/aws/latest/submodules/iam-assumable-role)

```hcl:role_to_assume.tf
data "aws_caller_identity" "current" {}

# --- 信頼ポリシーに設定する「Assume Role可能な（= 信頼できる）IAMユーザー」
data "aws_iam_user" "user" {
  user_name = "kokado-iam-user"
}

# --- terraform plan/apply の中で切り替えるIAMロールを定義する
module "role_to_assume_for_cicd" {
  source  = "terraform-aws-modules/iam/aws//modules/iam-assumable-role"

  create_role = true

  role_name         = "role-to-assume-for-cicd"
  role_requires_mfa = false

  trusted_role_arns = [
    # 1. ローカル用のIAMユーザーを信頼する
    data.aws_iam_user.user.arn,
    # 2. ここで作成するロール自体も信頼する（自己信頼）
    "arn:aws:iam::${data.aws_caller_identity.current}:role/role-to-assume-for-cicd",
  ]

  custom_role_policy_arns = [
    # Assume Roleの際に iam:GetUser が必要であるため追加
    "arn:aws:iam::aws:policy/IAMReadOnlyAccess",
    # 以降は構成管理に必要なポリシーを追加する
    # arn:aws:iam::aws:policy/AmazonS3FullAccess,
    # ...
  ]
}
```

`2. ここで作成するロール自体も信頼する（自己信頼）`の解説は割愛します。詳しくは以下をご覧ください。
参考 - [[仕様変更] IAM ロール信頼ポリシーの挙動が変更になり IAM ロールの「暗黙的な自己信頼」がなくなりました | DevelopersIO](https://dev.classmethod.jp/articles/announcing-an-update-to-iam-role-trust-policy-behavior/)

なお、このIAMロール自体は事前に手動で作成しておくといった準備が必要です。
最後に動作確認です。

```hcl:main.tf
data "aws_caller_identity" "current" {}
output "caller_identity" {
  value = data.aws_caller_identity.current.arn
}
```

簡単ですが、上記のコードを実行すると、outputで使用中の認証情報がIAMユーザーではなくassumed-role`に変わることが確認できます。

```
$ terraform plan
data.aws_caller_identity.current: Reading...
...
module.role_to_assume_for_cicd.aws_iam_role_policy_attachment.custom[0]: Refreshing state... [id=role-to-assume-for-cicd-20231206153119131500000001]

Changes to Outputs:
  + caller_identity    = "arn:aws:sts::12345678910:assumed-role/role-to-assume-for-cicd/aws-go-sdk-xxx"
```
「豊岡市・地方都市の暮らしハッカソン」に参加してみて良かったこと

CivicTech ＆ GovTech Advent Calendar 2023　7日目の記事です。

## 「豊岡市・地方都市の暮らしハッカソン」に参加してみました。
開催日時　2023年3月3日(金) 13:00～3月5日(日)～15:00　
平日の金曜日に始まり日曜日までの2泊3日の大型イベントです。

## どんなイベントだったのか？
豊岡スマートコミュニティ推進機構が主催し、豊岡市役所やトヨタ・モビリティ基金が協賛しコード・フォー・ジャパンが運営しているイベントです。
上限があるものの、交通費も補助されますし、現地での宿泊ホテルも用意されています。
ホテルが朝食付きのプランだったり、地元の美味しいおにぎり屋さんの昼食が出されたりと、現地滞在中の食事も用意されているような、至れり尽くせりでした。
また、商品も用意されていました。

下記の記者会見で公開されたのですが、私はPeatixと言うサイトを通じて開催を知りました。

イベントの流れとしては
豊岡市在住の市民が課題を持ち寄ります。
参加者は課題を聞いてい同じ課題に共感したメンバーでチームを結成し、その課題を解決するプロダクトを作ってみると言うものです。

つまり、チームを作ってから参加するタイプのハッカソンではなく、参加者は個人で申し込み、初日にチームビルディングを行います。

https://www.city.toyooka.lg.jp/mayor/mayorkaiken/mayorkaikenbn/1021275/1024944.html



## どんな課題があったのか
豊岡市は有名は観光地ではあるものの、多くの地方都市と同様に過疎などに悩んでいる町でした。

### チーム名 移動
移住や観光客など土地勘のない人たちに対して気象状況や交通規制、渋滞情報を反映させた目的地までのルート提案と、移動に関するローカルな情報を投稿するアプリの試作を行った。

### チーム名 居場所づくり
「社会的処方」の考え方を軸に、社会的に孤立している人たちに社会的に繋がれるコミュニティを紹介する仕組みを地元の医師や保健師が参加し試作した。

### チーム名 読書と自然
自然の中での読書を推進し、野外で本を読むのに適した場所や、気象情報、経路、本の感想等を共有するアプリの試作を行った。市内の高校生がテーマの発案を行った。

### チーム名 里山活用
担い手が不足し、農業用水や有害鳥獣の問題に繋がる里山管理のためのシミュレーションゲームの試作を行った。市内の高校生がテーマの発案を行った。

### チーム名 地 蔵
豊岡の地蔵文化に着目し、市内に点在するお地蔵さんについて由来など関連情報を地図にマッピングし、アプリ上で検索したり、スマホから各地蔵に割り振られた電話番号に電話を掛けて各お地蔵さんの説法を自動音声で聞いたりすることができるアプリの試作を行った。

### チーム名 スナック
街の賑わいを取り戻すためのコンテンツとして、市街地に集積している豊岡のスナックに着目し、NFT（※５）を活用した会員証発行など若者がローカルな飲食店を訪れ、街の人々と結びつくためのアプリを試作した。


## どのチームが優勝したのか？

「居場所づくり」チームが優勝しました
今どきの60歳以上の方はスマホや携帯電話を持っている人の方が多く、LINEなどでコミュニケーションを取っているという実態があります。
地域のサークル活動でチャットの利用を促し、その内容を ChatGPT（※４）（AI）が要約・分析しリンクワーカーへ繋ぐなど、最新の AI 技術の活用が評価された。


## 参加して何が得られたのか？
私自身は　「地蔵」チームに参加しました。
最優秀賞や優秀賞には届きませんでしたが、twillioをうまく使えたという事でtwillio賞や参加者の人気投票一位ということでオーディエンス賞の景品として、保冷カップとエコバックをいただきました。
ただ、それよりも、チームビルディングをできたという経験が良かったです。
チームビルディンが大切だとはよく言いますが、実践形式で体験できる場はほとんどありません。
その貴重な機会を得られたということがとても大きかったです。
チームメンバーに大学生がいたり、デザイナーがいたりして、専門分野も年齢も違う人たちでチームを組むことになったので、関係ができていない時からガツガツ行くと、関係が壊れしまい全く何も作るこができない可能性があります。
しかし、遠慮しすぎて関係が深まらないと良いものが作れないというリスクもあります。
その中で、みんなが探りながら関係を作り、形になったという経験は非常に良かったです。


## 最後に
私はチームビルディングがとても良い経験になったと感じました。
これ以外にも良い経験が詰まっていると思うので、ぜひ皆さんもハッカソンを恐れずに参加してみてください。
外から見ると敷居が高く見えますが、実はそれほどではありません。