OmniAICreator/Qiita-1.07M huggingface dataset:
【Go言語】ビルドタグgo:buildの使い方

# ビルドタグとは

ビルドタグとは、Goファイルの先頭にある特別なコメント。ビルドタグの後には1行の空行が入る。*Build Constraints* とも呼ばれる。ちなみに、`//`と`go`の間にスペースを入れると普通のコメントとみなされる。

```go
//go:build foo

package hoge
```

:::note
Go1.17以前では `//go:build` ではなく、 `//+build`が使えわれていました。
:::

## なんのためにビルドタグを使うのか

以下のようにすると、cgoが有効な場合にのみソースファイルを含む。

```go
//go:build cgo
```

## ビルドオプションの指定

例えば、以下のように **windows**　を指定すると、windows以外ではbuildされなくなる。

```go
//go:build windows
```

windows以外にもGOOSやGOARCHに指定できるアーキテクチャ、cgo、コンパイラ、goのメジャーバージョンを指定できる。例えば主な例を挙げると以下のようなものがある。

- windows, linux, darwin
- unix
- ignore(その他独自のカスタムタグでも可能) : build時に無視したいとき
- cgo : CGO_ENABLEDが1のときにbuild対象となる
- linux
- unix
- darwin
- go1.22 (マイナーバージョンは指定できない)
- gc, gccgo
- android, ios
- arm,arm.5, arm.6, arm.7
- amd64, amd64.v1, amd64.v2, amd64.v3
- mips64x, ppc64x, wasm

:::note warn
`go build main.go`のようにテストファイルを指定して、buildしたときはビルドタグに関係なく、buildされる。
:::

また、`&&`, `||` , `!`演算子が利用できる。
cgoが利用でき、linuxまたは、darwin

```go
//go:build cgo && (linux || darwin)
```

## テストの分類

例えば、結合テストと単体テストを分けたいとき
結合テストの対象ファイルには以下のようにビルドタグをつける。

```go
//go:build integration
```

次に、結合テストで動かしたくない単体テスト対象のファイルには、`!`のビルドタグを指定して無効にする。

```go
//go:build !integration
```

そして、テスト時にtagを指定して実行する。

```sh
go test -tags=integration -v
```

:::note warn
`//go:build !integration` をつけないと、`go test -tags=integration` とすると、タグがついていないものも実行される。
:::

ちなみに、ビルドタグでテストをスキップした場合、どのテストがスキップされたかは出力されない。対処法としては、環境変数を使用する方法がある。

以下の例では、環境変数`INTEGRATION`がtrueになっている場合は、テストをスキップする。

```go
func Test_hoge()(t *testing.T) {
 if os.Getenv("INTEGRATION") != "true" {
  t.Skip("skipping integration test")
 }
}
```

# ショートモード

ショートモードを使うと実行速度でテストを分類することができる。

```go
func TestLongRunning(t *testing.T) {
	if testing.Short() {
		t.Skip("skipping long-running test")
	}
	// ...
}
```

`testing.Short`を用いるとテスト実行中にショートモードが有効になっているか否かを取得し、`Skip`でスキップする。

テストの実行は`-short`を渡す。

```shell
go test -short -v .
```

# 参考文献

1. [Amazon.co.jp: Go言語 100Tips ありがちなミスを把握し、実装を最適化する (impress top gear) : Teiva Harsanyi, 柴田 芳樹: 本](https://www.amazon.co.jp/Go%E8%A8%80%E8%AA%9E-100Tips-%E3%81%82%E3%82%8A%E3%81%8C%E3%81%A1%E3%81%AA%E3%83%9F%E3%82%B9%E3%82%92%E6%8A%8A%E6%8F%A1%E3%81%97%E3%80%81%E5%AE%9F%E8%A3%85%E3%82%92%E6%9C%80%E9%81%A9%E5%8C%96%E3%81%99%E3%82%8B-impress-gear/dp/4295017531)
1. [Goのビルドタグの書き方が// +buildから//go:buildに変わった理由](https://zenn.dev/team_soda/articles/golang-build-tags-history)
1. [go command - cmd/go - Go Packages](https://pkg.go.dev/cmd/go#hdr-Build_constraints)
1. [go buildのオプションを調べてみた](https://zenn.dev/hiroyukim/articles/ccb937039e5747)
1. [Advanced Go Build Techniques - DEV Community](https://dev.to/jacktt/go-build-in-advance-4o8n)
Vim 9.1 patchダイジェスト (2024/05)

[Vim](http://www.vim.org/)のリリースされた[patch](https://github.com/vim/vim/commits/master)の説明です。
([9.1.0385](https://github.com/vim/vim/commit/b2e42b9be0ffa193ef32ad5a5846ef46f5cc4e8c) ～ [9.1.0454](https://github.com/vim/vim/commit/f3dd6f617c65a9b939697362efe6833eb2778612))
**新機能、大幅な仕様変更には、:four_leaf_clover:が付いています。**
runtimeファイルも直接commitされるようになりました。ただ、数が多いので基本的にはここでは取り扱わないことにします。

* [9.1.0418](https://github.com/vim/vim/commit/8e4c4c7d87def2b100a5d64dc518ef85d9de8765): :four_leaf_clover:ノーマルモードコマンド `]r` と `[r` を追加しました。カーソルの前/後の、"稀な" 単語に移動します。
* [9.1.0394](https://github.com/vim/vim/commit/b4757e627e6c83d1c8e5535d4887a82d6a5efdd0): :four_leaf_clover:`getregionpos()`を追加しました。`getregion()`と同じですが、{pos1} と {pos2} によって囲まれたバッファのテキストセグメントを表す位置のリストを返します。(関連patch: [9.1.0395](https://github.com/vim/vim/commit/b8ecedce79149ac6b994177e9a68979f86065cb1), [9.1.0423](https://github.com/vim/vim/commit/c95e64f41f7f6d1bdc95b047ae9b369743c8637b), [9.1.0430](https://github.com/vim/vim/commit/52a6f348874778cf315b47d9e8b5f818f4b97277), etc........)

---
#### 凡例

|表記|意味|
|:------|:------|
|:four_leaf_clover:|新機能、大幅な仕様変更|
|:alien:|Vim開発者向けの追加、変更|
|`'hoge'`|オプション (`:h options`参照)|
|`:hoge`|Exコマンド (`:h :index`参照)|
|`hoge()`|組み込み関数 (`:h functions`参照)|
|`v:hoge`|Vim定義済変数 (`:h v:`参照)|
|`+hoge`|feature (`:h +feature-list`参照)|

---
#### 方針
[こちら](http://qiita.com/h_east/items/23cd0d10932505072e6b#%E6%96%B9%E9%87%9D)を参照。
AWS エラー特集

# 只々只管 AWSで発生したエラーとその対処方法を書き連ねていくだけです！


## エラーその1

```
Deleting security group named: [security group name] failed Reason: [resource id] has a dependent object (Service: AmazonEC2; Status Code: 400; Error Code: DependencyViolation; Request ID: [request id]; Proxy: null)
```

### エラーの症状

1. 環境が単一のインスタンスだとアップロード出来ない．複数のインスタンスたとnginxは立つが 502 Bad Gateway が生じる．
1. コンソール上で環境を構築するときに色々なパラメータを弄っても駄目．
1. ネットワークのルーティングやファイアーウォールには問題なし．
1. CLI (Elastic Beans CLI)上で環境を構築しようとしても駄目．
1. ログが取得できない

### エラーの原因

ec2でのIAMのロール設定がおかしい．



##　エラーその2
```
Stack named 'awseb-e-pjnaxvmufh-stack' aborted operation. Current state: 'CREATE_FAILED' Reason: The following resource(s) failed to create: [AWSEBRDSDBSubnetGroup].
```

一番訳の分からないエラー

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1353403/988f00e2-e35a-a20b-c356-451826687a47.png)

### エラーの原因

(おそらく)データベースのサブネットを複数選択しないと発生するエラー．

インスタンスサブネットと同じデータネットサブネットを選ぶ必要があるので，1つから選べるような仕様になっていると考えられる．でも，2つ以上選ばないと失敗する．
データベースの名前にわざわざ正規表現使ってチェックする暇あるなら，こういった仕様についてデバックして欲しいお気持ちになってしまった．
Elasticbeansはとっても便利なんだけど．．．


#### 参考
https://repost.aws/questions/QUYEbFxL-eSGu7PLtCTwXfoQ/the-following-resource-s-failed-to-create-awsebrdsdbsubnetgroup
Perplexity ProでClaude 3.5 Sonnetを使う

# はじめに

話題のClaude 3.5 SonnetがPerplexity Proで使用できるようになっています。（Claude3 Sonnetは選べなくなりました）

設定は左下の歯車アイコンをクリックすると表示されます。
※Perplexityのアプリ版では「Claude 3.5 Sonnet」を選択することができませんでした。将来的に使えるようになるのではないかと思われます。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3343142/352f1dc8-8d41-8713-b1ca-8df8ef782868.png)

# さっそく使ってみる

:::note info
Perplexity に「Claude 3.5 Sonnet」を検索してもらいました。
:::

Claude 3.5 Sonnetは、Anthropic社が2024年6月21日に発表した最新の大規模言語モデルです。主な特徴は以下の通りです:
## 性能の向上:
大学院レベルの推論(GPQA)、学部レベルの知識(MMLU)、コーディング能力(HumanEval)などのベンチマークで、競合モデルやClaude 3 Opusを上回る性能を示しています。
ニュアンス、ユーモア、複雑な指示の理解が向上し、自然で親しみやすい口調で高品質のコンテンツを生成できます。
## 処理速度の向上:
Claude 3 Opusの2倍の速度で動作します。
## コスト効率:
Claude 3 Opusの5分の1のコストで利用可能です。
入力トークン100万あたり3ドル、出力トークン100万あたり15ドルの料金設定です。
## 視覚認識能力の向上:
画像認識やグラフ・チャートの解釈など、視覚的推論を必要とするタスクで性能が向上しています。
不完全な画像からのテキスト抽出も可能になりました。
## コーディング能力:
内部評価では、問題の64%を解決し、Claude 3 Opusの38%を大きく上回りました。
## 新機能「Artifacts」:
コード生成時にプレビューを表示したり、デザインやドキュメントを別ウィンドウで表示する機能が追加されました。※Perplexityではこの機能は使えません

# おわりに

Claude 3.5 SonnetはClaude 3 Opusの2倍の速度で動作するとのことですが、本当に体感できるレベルで早いです。
現時点では、Perplexityから「Artifacts」が使えないのが残念ですが、そのうち使えるようになるかもしれません。
もっと早く参加すべきだった！サポーターズキャラバン体験記

こんにちは，bearlです．
今日は「サポーターズキャラバン」に参加したので，その感想を共有したいと思います．
特にエンジニアを目指している方や，就活に不安を感じている方に，このイベントの魅力を伝えたいです．

# 目次
1. 紹介しようと思った背景
1. どういうことができる？
1. どんな人におすすめ？
1. おわりに

# 紹介しようと思った背景

私は情報系の大学3年生で，これまでサポーターズのオンラインイベントには何度も参加してきましたが、オフラインイベントは初めて参加しました。場所が遠いや、課題が忙しいなど色々言い訳をして...
そして、今回思ったことはなんでこんな素晴らしい機会をチンケな言い訳で見逃してきたんだという後悔です。

では、なぜ私がそう思ったのかを次の章で述べていきたいと思います。

# どういうことができる？
わたしはざっと5つができるとおもいます．流れ的には，企業さんの説明その後に質問に答えてもらうという形なので，これ以上にもまだまだできることが得られるものがあると思います．

### 企業さんとの繋がりができる

今回わたしが大きかったのはここですね。企業さんと直接お話できて，気になること，困ってることがあれば，後実でもメールやSNSで対応してくれます．なんでそんなに優しいのでしょうね？様々な方々が学生のためならと親身に対応してくれるので，新しいコネクションを築く絶好の機会です．

### 横とのつながりができる

みなさんは何か続ける時に1人で行っていますか？わたしは，1人だけでは続けられても1，2ヶ月ですかね？でも，友人がともに頑張っているなら，自分も頑張れるかなと思いませんか？このイベントには，そんな頑張っている学生がたくさん参加します．自分と同じぐらいのレベルで共に頑張っていこうと思える学生や自分よりもすごくて目標になる学生が参加しています．ぜひとも友人になってください！相手も繋がりを求めていると思います．それで，このイベント後にも関わりを持てたり，共にハッカソンに出場できると幸せですね〜〜

### 実際の体験を聞ける

実際の業務内容やそこでのいいところから大変なところまで、大体の企業の方が赤裸々にお話ししてくれます。それ言っていいの？と思うこともありながら、それでもこういうことがあるから続けているなどが聞けます．他には転職体験の話や会社の考えなど実際に働いているエンジニア，または人事の方から，様々な経歴の人のキャリアについて教えていただくことができます．これからのキャリア設計に絶対参考になると思います！！

### 自分の相談を聞いてもらえる
企業の人が親身になって相談に乗ってくれます．企業さんも学生だった方がほとんどです．そして，同じような悩みを持っていた方もいらっしゃいます．そんな大先輩からどう悩みを解決したのか，また今だったらどのようなことをするのか，実体験を踏まえて答えてくれます．加えて，サポーターズさんはエンジニア就活のプロです．就活に関する悩みならなんでも答えてくれます．ここにいけば，モヤっとしていることが晴れると思います．また，考えるヒントをくれると思います．わたしはもらえました．

# どんな人におすすめ

- キャリアプランや企業選びに困ってる人

- 継続開発をどのように進めたらいいのか悩んでいる人

- 何から始めたらいいのかわからない人

- いま自分が進めていることがあっているか不安な人

- 世の中にはどんな企業があるか知りたい人

- 気になる企業が参加してる人

# 最後に

オンラインイベントではできないことがたくさんあると思います．話しにくかったり，想いが伝わりにくかったり，学生同士で会話がしにくかったりなどなど．なので，ぜひオフラインイベントに参加しましょう。このような座談会形式のものからハッカソンなど様々なオフラインイベントがあります．オフラインでしか得られない体験がそこに転がっています．まずは行ってみることから，行ってみて合わなかったらそれ以上参加しないでもいいと思います．騙されたと思って行ってみてください！それではみなさんいいエンジニアライブを〜👋
Arduino UNO R4関係の記事のまとめ

Arduino UNO R4に関する記事で技プログにアップしたものをまとめました。
まずはArduino UNO R4について。
Arduino UNO R3のモデルチェンジ品なわけですが、何が大きく変わったのか？それは載っているSoCがAtmel⇒Renesasに変わっています。
<https://www.hobbyhappyblog.jp/arduino-renesas-chip>

機能としてR3からR4に変わったことで何が変わったのかについてはこちら
<https://www.hobbyhappyblog.jp/differences-between-arduinounor3-and-r4>

R3からR4に変わった機能のうち、analogReadが10bit階調から14bit階調にパワーアップした件を紹介しているのがこちら。
<https://www.hobbyhappyblog.jp/analogread-powered-up-to-14-bit-grayscale>

Arduino UNO R4 Wifiには基板上にマトリックスLEDが搭載されています。このマトリックスLEDを自由自在に点灯・消灯させる方法を紹介しているのがこちら。
<https://www.hobbyhappyblog.jp/arduino-uno-r4-wifi-matrix-led>
その読み方合ってますか？

## はじめに
最近、ニコニコ動画がDDoS攻撃で被害を受けていたと思います。
ニュースを聞いていて、あれと思ったことがありました。
DDoS攻撃(ディードス攻撃)と読まれていました。今まで、私は恥ずかしながらドドス攻撃と読んでしまっていました…。
こういう読み間違えって、そういえばよくあったと思い、今まで私が間違って読んでいたものをまとめてみようと思います。

## 単語の意味と正しい読み方
- **DDoS攻撃(ディードス攻撃)**
間違えた読み方→ドドス攻撃
正しい読み方→ディードス攻撃
DDoS攻撃（Distributed Denial of Service attack、分散型サービス拒否攻撃）とは、多数のコンピュータやデバイスを使用して特定のターゲット（ウェブサーバ、ネットワーク、アプリケーションなど）に対して大量のトラフィックを送りつけ、そのサービスを過負荷状態にさせて正常なサービスを妨害するサイバー攻撃の一種。

- **route53**
間違えた読み方→ルートごじゅうさん
正しい読み方→ルートフィフティースリー
Amazon Web Services（AWS）が提供する高可用性でスケーラブルなドメインネームシステム（DNS）ウェブサービス。Route 53は、インターネットドメイン名をIPアドレスに変換するDNSの機能を提供するだけでなく、ドメイン登録、トラフィック管理、ヘルスチェック機能も提供。

- **rubocop**
間違えた読み方→ロボコップ
正しい読み方→ルボコップ
RuboCopは、Rubyプログラムのコード品質を向上させるための静的コード解析ツール。RuboCopは、Rubyコミュニティで広く受け入れられているスタイルガイドやベストプラクティスに基づいてコードをチェックし、問題がある箇所を指摘する。また、多くの問題を自動的に修正する機能も提供。

- **ASUS**
間違えた読み方→エイサス
正しい読み方→エイスース
台湾に本社を置くコンピュータおよび電子機器メーカーで、正式名称は「ASUSTeK Computer Inc.」。

## 終わりに
意外と間違った読み方で読んでいて、恥ずかしいばかりです。
正しいと思っている読み方でも一度しっかり調べてみるのがよさそうですね。
運用保守のキャリアを振り返って

## はじめに
私は運用保守をメインに10年間の経験があります。様々な現場で経験を積んできました。

## 金融系 システム保守
JP1 AJSのオンプレミス環境でシステム保守を担当しました。
この現場では、スクリプトのタイムスタンプの誤更新すら許されない厳しい環境でした。
ファイル管理も厳重で、確認者を「再艦者」と呼び、少しでもタイムスタンプが変わると再チェックが必要でした。エビデンスは再艦者が赤枠でチェックし、その理由を記載してお客様に提出しました。
スクリプト作成は年に数回程度で、主に申請書作成やエビデンス整備を行い、平均残業時間は50時間でした。
**この経験から、運用作業後のエビデンスがいかに重要かを学びました。**

## 公共系 システム保守
朝から夕方までデータセンターで働き、夕方から23時までは自社で業務を行う環境も経験しました。
構築は未経験だったため、多くの困難がありましたが、有識者に助けを求めることの重要性を学びました。
残業時間は60時間に達し、辛い時期もありましたが、仲の良いチームの支えで乗り越えることができました。
**きつい時こそ楽しい話をし、笑顔を忘れないことの大切さを実感しました。**

## 流通系 システム運用
Gsuiteシステムの運用を1年半担当しました。
期限までにユーザーに連絡し、メールアカウントの登録と発行を行いました。
ユーザー情報が少なく、連絡が取れない時は焦りましたが、技術よりもコミュニケーション能力が求められる現場でした。
新人や年上の方々と協力して仕事を進める中で、コミュニケーションの難しさを実感しました。
**同じシステムでも部署ごとに呼び方が異なると誤解が生じ、アカウントを誤って停止すると重大なインシデントとなることを学びました。**

## 電気メーカー AWS システム運用保守
初めてAWSを実務で使用した際は理解に苦しみましたが、半年後には徐々に理解が深まりました。
金融系の厳しいセキュリティ環境での経験が、リモートワークでも役立ちました。
AWSに関するオンプレミスの経験も生かすことができました。
データセンターの寒さは辛かったですが、現在は自宅で仕事ができる夢のような環境になりました。
**フルリモートでは、お互いの状態が見えないため、能動的に質問し、不安があれば作業を中断することが重要です。一人で判断することの危険性を痛感しました。**

AWSなどのクラウドは昨日できないことが明日できるようになる可能性があるため、常に最新の技術を確認する必要があります。これがオンプレミスとは違う点です。
またメンテナンスについても強制的に適応されるため、AWSから提示されたスケジュールに沿って対応する必要があります。

## まとめ
システム保守の経験を振り返ると、セキュリティが厳しい金融系のオンプレミス環境での経験は非常に価値があったと感じます。これらの経験は、現在でも私の基盤となる重要な知識として役立っています。

システム運用保守として生き残るために重要だったのは、一人で仕事をしないことでした。チームで仕事をする意識を持つようになり、協力と連携の大切さを学びました。
markdown AIで遊んでみた：フォーム作成

### Markdown AIで作成したフォーム

マークダウンの参考サイトを見ながらとりあえず作成してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3533750/3ef99c63-aa99-2bbe-9bf4-94e62dd660c1.png)

### タイトル
h1,h2タグで実装するようなヘッダーはQiitaのマークアップと同様に「#」で表現します。

### チェックボックス

チェックボックスは「- []」で表現できます。
また、チェック状態にするには「[x]」とする必要がありますがこの「x」は「バツ」ではなく「(アルファベットの)エックス」です。(最初間違えました(笑))

### 入力欄、ボタン

入力欄はinputタグで表現できました。
ボタンもbuttonタグで表現できました。
要素をホバーした時に情報を表示したい

## はじめに
動作確認した環境
- svelte 

## やりたいこと
Webページの要素をホバーした時に情報を表示したい。

画像イメージ
![スクリーンショット 2024-06-23 0.44.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3812987/88177181-1bf8-cfc3-77fe-595942194408.png)

## 方法
`img`タグに`title`属性を付与してあげるだけ。
`img`タグに限らず他の要素にも指定してあげることができます。
```html
<img title="リーリアちゃん" src={imagePath} />
```

画像に関しては`public`においてあげましょう。

## 注意点
- 表示までに少し時間がかかるかも
- デザインを詳細に変更することはできないかも
    - 即座に表示したい、細かくデザインを作りたいとなったら別でコンポーネント作ってあげる方がいいかも
- 利用者にのPC環境によって見え方が異なるかも
    - プライマリーのPCカラーやダークモードかなどで変わるかも

## さいごに
属性を付与するだけで一瞬で実装できるので、
迫られた環境でどうしても！となったら選択肢として持っていてもいいかもしれません。
Slurmの認証にmungeが不要になった件

# TL;DL
Slurm v23.11 から従来コンポーネント間の認証に必須だった `munge` の代わりに組み込みのプラグインによる認証が使用可能となり、Slurm 構築がぐっと楽になりました。
# Slurm 認証方式
従来 Slurm クラスタを構築する際には Slurm コンポーネント（`slurmctld` `slurmd` `slurmdbd` `slurm-client` など）間の通信・認証に `munge` が必須であったため、Slurm とは別パッケージとして `munge` をインストールし、鍵のセットアップや構成を行う必要がありました。  

この `munge`、設定が難解 ... とまでは言わないのですが、そもそも認証機構を Slurm 外に持つこと自体が煩雑で、めんどくさい側面があったのは否めません。  

これについて、Slurm v23.11 から[自身のプラグインによる認証](https://slurm.schedmd.com/authentication.html#slurm)がサポートされるようになったため、Slurm 単独で通信・認証が完結するようになりました。  

### 注意
現在 `apt install` などでインストールできる Slurm はややバージョンが古いため、23.11 系を使用するには手動でビルドが必要な可能性があります。当方もソースからビルドしたうえで試していますので、ご注意ください。

# 手順
ドキュメント載っている通りですが、再記載します。
### キーを生成する
Slurm コンポーネントが認証に使用する共有キーとして、`slurm.key` を作成します。特殊なツールなどがあるわけではなく、中身はテキストデータ等でも問題ないようです。  
**なお、ファイルは `/etc/slurm/slurm.key` の一択となるようで、パスやファイル名の変更はできないようなので注意してください。**
  
ドキュメントでは、`/dev/random` からランダムデータを生成する方法が紹介されています。  
```bash
$ dd if=/dev/random of=/etc/slurm/slurm.key bs=1024 count=1
```

### キーのパーミッション設定
`slurm.key` が必要なすべてのノードでアクセス可能となるよう、`/etc/slurm` に配置してください。  
キーのパーミッションを適切に設定します（以下は Slurm ユーザが `slurm` の場合の例となるので `slurm.conf` の `SlurmUser` を参照うえ、適切に指定してください）。
```bash
$ chown slurm:slurm /etc/slurm/slurm.key
$ chmod 600 /etc/slurm/slurm.key
```
### コンフィグ設定
それぞれ `conf` ファイルを以下のように設定します。  
※ `AuthType` はデフォルトでは `auth/munge` になっているはずです。
* slurm.conf
```bash
AuthType=auth/slurm
CredType=cred/slurm
```
* slurmdbd.conf
```bash
AuthType=auth/slurm
```
設定後、各 Slurm デーモンを再起動してください。
### クライアント設定
上述の Slurm 認証プラグインは各 Slurm のデーモンに内包されています。  
もしいずれの Slurm デーモンが動作していないノード、**つまり `slurm-client` だけが入っているログインノードのような環境では、デフォルトで上記認証は動作しません。**  

この場合は認証用のデーモンとして `slurm-sackd` を追加でインストールしてください。ビルドした場合も特に追加のビルドオプションなしで作成されるはずです。  
ログインノードで Service として動作していれば OK です。
```bash
$ dpkg -i slurm-smd-sackd-xxxxx.deb
$ systemctl status sackd
```

### 動作確認
Slurm コマンドで各ノードやパーティションが見えていれば OK です。もしエラーになる場合は各デーモンのログを確認しましょう。
```bash
$ sinfo
NODELIST    NODES PARTITION STATE  CPUS MEMORY TMP_DISK WEIGHT FEATURES REASON
test[0-7]       8 sample*   idle      X   XXXX    XXXX     XX (null)   (null)
```
# まとめ
やや新しめのバージョン向けではありますが認証機構を一本化でき、非常にシンプルな構成が採れるためメリットは大きいと思います。  
これから構築される方はご検討ください。
KubernetesをalmalinuxでHA構成で構築する③ worker node編

# 最初に
この記事は下記urlの続きである。
HA構成をする前にsingle controller構成を構築した。
後のHA構成ではここで作成したconfigを書き換えて構築する。

https://qiita.com/nyahahanoha/items/e1106ef6b97617887310

# clusterに参加
control nodeでtokenを作り直す
`< >`で記述されているものは置き換えて考えて欲しい。
これはcontrol nodeで実行する。
```
$ kubeadm token list
TOKEN                     TTL         EXPIRES                USAGES                   DESCRIPTION                                                EXTRA GROUPS
abcdef.0123456789abcdef   23h         2024-06-21T14:35:06Z   authentication,signing   <none>                                                     system:bootstrappers:kubeadm:default-node-token
$ kubeadm token delete abcdef.0123456789abcdef
$ kubeadm token create --print-join-command
kubeadm join <controller nodeのip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>
```

worker nodeでconfigを作成する。
これはworker nodeで構築する。
```
$ kubeadm config print join-defaults > kubeadm-default.yml
$ vim kubeadm-default.yml

apiVersion: kubeadm.k8s.io/v1beta3
caCertPath: /etc/kubernetes/pki/ca.crt
discovery:
  bootstrapToken:
    apiServerEndpoint: <controol nodeのip>:6443
    token: <token>
    caCertHashes:
    - sha256:<hash>
    unsafeSkipCAVerification: true
  timeout: 5m0s
  tlsBootstrapToken: <token>
kind: JoinConfiguration
nodeRegistration:
  criSocket: unix:///var/run/containerd/containerd.sock
  imagePullPolicy: IfNotPresent
  name: worker-node0 # nodeの名前なので自由に変更して良い
  taints: null
  kubeletExtraArgs:
    node-ip: <worker nodeのip>
```

worker nodeをclusterに参加させる
これはworker nodeで実行する。
```
$ sudo kubeadm join --config kubeadm-default.yml
$ sudo systemctl restart containerd
```

# 動作確認
control nodeでworker nodeが参加したか確認する。
これはcontrol nodeで実行する。
```
$ kubectl get node
```

これでsingle controller構成の構築は完了した。
次回はHA構成の構築を行う。

# 参考
https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/
KubernetesをalmalinuxでHA構成で構築する① 全node編

# 環境
almalinux: AlmaLinux 9.4 (Seafoam Ocelot)
kubeadm: v1.29.6
kubectl: v1.29.6
kubelet: v1.29.6

# 参考
最初に参考を書くのも変な感じだが、下記のurlを参考にこの記事を作成した。

https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

# 最初に
本稿**KubernetesをalmalinuxでHA構成で構築する**は4部構成の予定だが、これらの記事に出てくる全てのnodeはこの記事の内容を設定している。

# selinuxの無効化
selinuxは検証環境には無用の長物。
ので、無効化する。
```
$ sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config
$ sudo reboot
```

# swapの無効化
kubernetesはswapを無効化しないと動作しない。
理由は知らない。
```
$ sudo swapoff -a
$ sudo vim /etc/fstab

# comment outする
#/dev/mapper/almalinux-swap none                    swap    defaults        0 0
```

## firewalldの設定
kubernetesが使うportを解放する。
securityを気にしないなら、disableにしても良い。
```
$ sudo firewall-cmd --add-port 6443/tcp --permanent
$ sudo firewall-cmd --add-port 2379-2380/tcp --permanent
$ sudo firewall-cmd --add-port 10250-10252/tcp --permanent
$ sudo firewall-cmd --reload
```

## ipv4 forwardingの有効化
ipv4 forwardingを行うためにmoduleをloadして有効化する。
```
$ sudo modprobe overlay
$ sudo modprobe br_netfilter

#moduleの確認
$ lsmod | grep br_netfilter
$ lsmod | grep overlay

$ sudo vim /etc/sysctl.d/k8s.conf

net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1

$ sudo sysctl --system

#kernel parameterの確認
$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward
```

## containerdのinstall
dockerはkubernetesから降ろされたため、containerdをinstallする。
```
$ sudo dnf install -y yum-utils
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
$ sudo dnf install containerd.io -y
$ sudo systemctl restart containerd
```

## containerdのconfig
containerdのcgroup driverにsystemdを設定する。
```
$ sudo sh -c "containerd config default > /etc/containerd/config.toml"
$ sudo vim /etc/containerd/config.toml

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

$ sudo systemctl restart containerd
```

## kubectl,kubeadm,kubeletのinstall
kubernetesのcommand群をinstallする。
repoのurlが参考と異なっているため注意。
```
$ sudo vim /etc/yum.repos.d/kubernetes.repo

[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/repodata/repomd.xml.key

$ sudo dnf install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
```

## kubeletの起動
```
$ sudo systemctl enable --now kubelet
```
おそらく、startしてもloadedのままだと思う。
kubeadmでkubernetesを構築したらkubeletもstartする。

次回は`control node`を構築する。
Django-NinjaでSchema内のフィールド値を動的に決定する！

# まえがき

お久しぶりです。
今も前回の記事同様にDjango-Ninjaを使ってAPIを作っています。
今回は、SchemaのフィールドをSchema内で定義した関数を用いて値解決する方法についてです。

レビューへ出す前に、しっかりとこのようなFW思想に沿ったやり方でコーディングしたかったのですが、このあたりは自分の知識が薄くて、仕事がいそがしかったこともあって、全然できていませんでした。

Django-NinjaのDiscussionsを見ていたら、いい感じに解決する方法があったため、そちらを試したよっていう記事です。

# やりたかったこと

- レスポンスを生成するSchema内で返却値を動的に解決する

例えば、データベースからORMを使って`{"id":1, "value": "value"}`を取得したとします。
ここでは、valueの値はvalueになってます。
これは、DB操作するときにSQLやORMで解決するには、あまりにも実装が面倒そうだったから、一時的にvalueという文字列を返している……ということにしてください。

そして、valueの値はidの数字に「だ🐘ﾊﾟｵｰﾝ!」とつけたものにするとします。

上記をまとめると、以下のような感じ。

- Schemaに渡される前(DBから取ってきたもの)

```json
{
    "id": 1,
    "value": "value"
}
```

- Schemaに渡された後(実際にAPIが返すもの)
```json
{
    "id": 1,
    "value": "1だ🐘ﾊﾟｵｰﾝ!"
}
```


伝わるでしょうか…。

# やり方

公式のDiscussionsを見ていたら、それっぽいことを聞いているスレッドがあったので、それを参考にしてみました。

自分で試してみた方法は2通りで、どっちが優れているとか、どういう状況で使うとか、そのあたりはわかっていないんですけど、とりあえずできたという感じです。

## resolve_xxx()を使う

staticmethodでデコレートされた`resolve_xxx()`を使う方法です。
これは、Django-Ninjaの公式のドキュメントにも似たようなことが書いてあったのかな。

### レスポンスSchemaのコード
```python
class TestOut(Schema):
    id: int = Field(
        description="ID",
    )
    value: str= Field(
        description="id + 'だ🐘ﾊﾟｵｰﾝ!'",
    )

    @staticmethod
    def resolve_value(input):
        return str(input["id"]) + "だ🐘ﾊﾟｵｰﾝ!"
```

こんな感じ。公式だと、`input["id"]`の部分が、`input.id`みたいなフィールドで書かれていて、これがちょっとよくわかんないんですけど、とりあえずこれでいけました。
（viewsでreturnしているのがインスタンスじゃなくて辞書型だからなのかな……。）

## pydanticのcomputed_fieldを使う

わたしが参考にしたDiscussionだと、これが勧められていました。
どうやら、NinjaがVer1.0になった際、`resolve_xxx(self, ...)`）が使えなくなって、pydanticの組み込み機能に置き換える必要があったみたいです。
上で書いた方法と何が違ったのか、selfが使えて何が嬉しかったのかがよくわかんないんですけど、とりあえず、そういう感じでした。。。

### レスポンスSchemaのコード

```python
class TestOut(Schema):
    id: int = Field(
        description="ID",
    )

    @computed_field
    @property
    def value(self) -> str:
        return str(self.id) + "だ🐘ﾊﾟｵｰﾝ!"
```

# どっちがいいんだろう？

できました。
どっちを使えばいいのかがよくわからないですけど。

ただ、computed_fieldを使った方法だと、例えばSchemaに既にvalueフィールドがある際に、それは書き換えられないよ！ってエラーが出ちゃうんですよね。

そうすると、openpaiを生成するときにSchema定義がちゃんとされていないみたいで、それはあまり嬉しくないです。。。
適当なフィールドを用意して、aliasでフィールド名をつけてあげたらいいのかもしれないんですけど、それはなんかちょっと、面倒というか回りくどいことをしている感じがします。。。


# あとがき

とりあえずこれで、Schemaの外でおりゃーと無理矢理に実装していた値解決のコードが、Schema内で定義できるようになりました。

へたに色々ファイルを増やしたり、どこに書いて値を書き換えたらいいんだろうと悩むくらいなら、Schemaでなんとかしたいなって思ってたので、スッキリしていい感じです。

最近、仕事自体は楽しいんですけど、上司とのコミュニケーションがしんどくて、そっちの悩みが日に日に大きくなっているので、久しぶりにこうしてたくさん文字を書いて、ちょっとリラックスできました。

今度、精神科を受診して色々相談するつもりです。
みなさんも心の健康には気をつけてくださいね。

そんな感じ。

じゃあね。
【Swift】シングルトンパターン

# この記事は何？

Swiftでシングルトンパターンを実装します。
**シングルトン** は「グローバルな共有オブジェクト」を作成する、一般的なデザインパターンの一つです。

> Swiftを基礎から学ぶには
自著、工学社より発売中の「[まるごと分かるSwiftプログラミング](https://amzn.asia/d/7YPWJwl)」をお勧めします。変数、関数、フロー制御構文、データ構造はもちろん、構造体からクロージャ、エクステンション、プロトコル、クロージャまでを基礎からわかりやすく解説しています。
> また、Swiftプログラミングを基礎から動画で学びたい方には、Udemyコース「[今日からはじめるプログラミング](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwii1qTuj_2BAxV4hlYBHbj5BqEQFnoECBYQAQ&url=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fstart-programming-today%2F&usg=AOvVaw2vs4Sccq-bpfA4ZD2rCyNm&opi=89978449)」をお勧めします。

### 実行環境

- Swift 6
- Xcode 15.4
- macOS Sonoma 14.5

## シングルトンオブジェクトのクラスを定義するには

まず、イニシャライザに`private`属性をマークして、型の外側からインスタンスを作成できないようにします。
そして、型プロパティとして`shared`定数を定義します。（一般的に、シングルトンオブジェクトの名前は`shared`をつける慣習がある。）
この`shared`プロパティにクラスのインスタンスを設定します。
 
```Swift: 
class Some {
    static let shared = Some()
    var value: String
    
    private init() {
        self.value = ""
    }
}
```

`Some.shared`にアクセスして作成できるインスタンスは、コードで唯一無二の存在です。

## シングルトンオブジェクトを共有する

次のコードは、「インスタンスのプロパティ」に「*これはシングルトンオブジェクトです*」と設定します。

```Swift:
let instance1 = Some.shared
instance1.value = "This is singleton object."
```

さらに、もうひとつのシングルトンオブジェクトを作成して、プロパティを参照します。
そして、そのプロパティ値を出力します。

```Swift:
let instance2 = Some.shared
print(instance2.value)
```

結果は、最初のインスタンスのプロパティから設定した「*これはシングルトンオブジェクトです*」が出力されます。

```console
This is singleton object.
```

これは、`Some.shared`で作成したシングルトンオブジェクトが「グローバルに共有されている」ことを示しています。
なお、この`Some`クラスのインスタンスは他の方法で初期化できないので、常にシングルトンオブジェクトです。
過去の勝ちパターンを速やかに捨てる段取り

## はじめに

エンジニアにとっての　__黒船__ となった技術やツールは、__インターネットの普及、オープンソースソフトウェア、クラウドコンピューティング、モバイル技術、DevOpsとCI/CD、人工知能と機械学習など__ があります。ここでいう __黒船__ とは、新たな技術が既得権益を駆逐してきた比喩である。いつでも過去の勝ちパターンを捨ざる負えないシーンに遭遇する可能性がある。今後は、ウェアラブルデバイスの発達、超高齢化社会、シンギュラリティと直ぐに到来する事が予測されています。

:::note info
あなたを望む人生へと導いてくれるのは変化しようとするマインド。あなたの運命が形づくられるのは、あなたが決断した瞬間。限定された経験は、限定された人生を生み出す。__人生を決定するのは条件ではなく決意。__　陳腐化する技術を見極め、もてる技術は、活かせる分野に都度、変更する勇気を持つ決意。大事なのは、技術を捨てる決意。
:::
「もっとこうしたかった、あの時こうしていれば・・・」では、遅い。

__「人生を決定するのは条件ではなく決意」__ という言葉は、私たちが直面する状況や環境よりも、自分自身の意志と行動が人生の結果を大きく左右するという考え方を表しています。この考え方は、自己責任と自己決定の重要性を強調し、どのような状況にあっても自分の人生を積極的にコントロールする力があることを示しています。この考え方を実践することで、困難な状況に直面しても前向きに行動し、目標を達成するための力を引き出すことができます。


**キャリアの選択**
厳しい経済状況や限られた教育機会に直面している場合でも、自分のキャリアを築くために努力し続けることができる。

**例えば、自己学習やネットワーキングを通じてスキルを磨き、目標を達成することができる。**

**人間関係の構築**
人間関係においても、他人の行動や態度に依存するのではなく、自分の態度や行動をコントロールすることで、より良い関係を築くことができる。

**例えば、コミュニケーションスキルを向上させたり、共感を持って接することができる。**

### カメラにとって、スマホは、黒船だった

#### なぜコダックは破綻し、富士フイルムは好調なのか？

もし、フィルム会社がカメラにこだわっていたら、倒産していただろう。
__もてる技術を活かせる分野に変更した。__

富士フイルムは、落ち目の産業に見切りをつけた。富士フィルムは、過去の成功パターンにこだわらなかった。富士フィルムの引き際は、見事である。蓄積された技術の周辺で応用分野を広げる形での事業・商品の広範な多角化によって生き残りに成功した。__富士フイルムは、枯れそうなエンジニアを活かした成功例である。__　富士フイルムは、1990年頃から、フイルム事業の衰退を認識し、デジカメで使われる半導体素子の内製化を行いデジカメの開発につなげて、商品化を推進。また、フイルム製造のコア技術を化粧品、医療機器関連でも展開。M&Aを行い、自社の弱点を補強した。

私の場合は、オンプレに見切りをつけ、クラウドに切り替えた。今後も、成功パターンを捨て、自分の強みを使う方向性を変え続ける必要があるだろう。

## 過去の勝ちパターンを速やかに捨てる段取り

__①装備を整える__
__③成功パターンのエッセンスを今に合わせる__
__③勘所だけ教わり、短期間である程度モノにする__

## ①装備を整える
軍事でいう、__兵站(補給・輸送・管理)__ です。
移動中のごはん。山で泊まるためのテント。一人で持てない荷物の分担。
危険な箇所を避ける先人が用意した地図。自分で賄う事が出来ないのは、明白。

__エンジニアの人生は、登れる山を登るのではなく、登りたい山を登りたい人と登るべきであると思います。__　

:::note info
情報(荷物)が多すぎるので、大胆に捨て続ける相談相手が必要。
既に持つ能力で、やれることではなく、
やりたい事をやれる人と __学ぶプロセスを楽しむ事が重要。__
:::

## ②成功パターンのエッセンスを今に合わせる
### 生き残るのは「変化できる者」ではなく「環境の変化に対応できた運が良かった者」

:::note info

エコシステムに入り、エコシステムの一部となる。
https://qiita.com/kimuni-i/items/7347f7539f3076cd7e7e
:::

#### 運が良かった参考例(私の場合)
All Certifications Engineers受賞

https://aws.amazon.com/jp/blogs/psa/2024-japan-aws-all-certifications-engineers/

## ③勘所だけ教わり、短期間である程度モノにする

自発的に、短期間で集中して、スキルを身に付けないと置いて行かれる時代になった。　
情報も横から入ってくるものが多く、キャッチアップしないとおいて行かれる。

__言われたことをがむしゃらにやっていると、種まきを忘れ、収穫物がなく、負け戦になり、死亡フラグがたつ事がある。__ 死亡フラグが立つと、転職を余儀なくされる。


:::note info
横社会に貢献する事で、横社会から学ぶ。(第一人者に接し、必要なものを学ぶ)

プロセスを通じて、「人に教えるネタが多い。独特な個性を持っている。あなただからこそ、というものがある。__新たな事でも、自分で調べて、自分なりの回答を導き出す事が出来る。__ ユニークな回答が出来る。」ようにする。

縦社会の上に立つ立場であれば、マネジメントの経験が必要。
横社会の場合は、ギブアンドテイク出来るノウハウを持っている事。
:::

#### 勘所だけ教わり、短期間である程度モノにした(私の場合)
インプット（知識や情報を取り入れること）とアウトプット（学んだことを使って何かをすること）を繰り返し行うことで、記憶を定着させる。

AWS Machine Learning資格取得、機械学習案件参画、案件に参画しながら、Pythonでコーディングを出来るようにした。あわせて、Azure Machine Learning資格を取得した。

### 結局、エコシステムを把握し、エコシステムに居場所を作り続けなければならない。
初心者から見たVue3コンポーネントの実装のしやすさについて Vision.9

# Vue3コンポーネントの実装のしやすさについて Vision.9
Vue3のコンポーネントの実装について、前回はVue3コンポーネントの詳細から、
props渡しの詳細について、まとめました。

前回：props渡しの詳細

https://qiita.com/babel_0101/items/46e14871f4fcff8c5349

今回は、一方向のデータフローを以下にまとめます。
## Vue3のコンポーネントの詳細5
公式ページ：[一方向のデータフロー](https://ja.vuejs.org/guide/components/props.html#one-way-data-flow)を読み進めながら、以下のように解釈。

### 一方向バインディング

全てのpropsは、子のプロパティと親のプロパティとの間に<br>**一方向バインディング**が形成されます。
<br>親プロパティの更新時、子プロパティに情報が伝達されますが<br>子から親への伝達はありません。<br>
一方向バインディングによって、親の状態が誤って子コンポーネントによって<br>変更される事態を防ぎ、アプリのデータフローが把握しにくくなるといった<br>事態を減らすことができます。

更にコンポーネント単位で見た場合、親コンポーネントの更新の都度<br>子コンポーネント内の全てのpropsは最新の値に、更新されます。<br><br>そのため、子コンポーネント内でpropsの値を更新するのは**厳禁**です。<br>もし子コンポーネント内でpropsの値を更新しようとすると<br>Vueがコンソールでエラーを発します。

![スクリーンショット (459).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3813799/369bf5db-0b16-b59e-e093-e55d2ff093c0.png)

実際に実装してみて、エラーが出ることを確認できました。

### propsを設定・変更するシチュエーション
通常、propsを設定・変更したい状況には以下の2つがあります。

1. 静的な初期値
    propsは静的な初期値を渡すために用いて、子コンポーネントを初期化する。<br>初期化処理以降、子コンポーネントではローカルのデータプロパティとして<br>親コンポーネントの更新から切り離して、固定値として利用したい。この場合、以下のようにローカルの<br>データプロパティを定義して、その初期値にpropsを使用するのが最も適切です。
    ```typescript:
    const props = defineProps(['initialCounter'])
    
    // props.initialCounter は counter の初期値を指定するためだけに
    // 使われ、今後発生するpropsの更新からは切り離されます。
    const counter = ref(props.initialCounter)
    ```
    <br>
1. 動的な変数値
    親コンポーネントがpropsの値を変更する都度、子コンポーネントのpropsも変更したい。<br>この場合、以下のような算出プロパティを定義して、その中でpropsの値を利用するのが最も適切です。
    ```typescript:
    const props = defineProps(['size'])
    
    // propsが変更されると自動的に更新される算出プロパティ
    const normalizedSize = computed(() => props.size.trim().toLowerCase())
    ```
### オブジェクト/配列のprops変更は許容されてしまう
親コンポーネントから、オブジェクトや配列をpropsとして渡した場合<br>子コンポーネント側でpropsの値を変更することはできません。<br><br>しかし、オブジェクトや配列のネストされたプロパティを変更することは可能です。<br>これは、JavaScriptの言語仕様では、今回のように呼び出し元と呼び出し先で<br>オブジェクトを共有することが理由です。<br><br>Vue側で、オブジェクトや配列の内部値の変更を防ぐ、基底機能を作るのは<br>コスト的に非現実的なため実装していません。

このような変更の主な欠点は、親コンポーネントにとって不明瞭な方法で<br>子コンポーネントが親の状態に影響を与えることを許してしまい、<br>後からデータの流れを見極めるのが難しくなる可能性があることです。<br><br>親と子を密に結合させる設計でない限り、ベストプラクティスとしては<br>そのような変更を避けるべきです。ほとんどの場合、子コンポーネントはイベントを発行<br>して、変更を親コンポーネントに実行してもらう必要があります。

上記、Vueの事情を汲み取って、実業務の上では、実装ルールとして制約を<br>設けるべき事項と考えました。
TrueNAS Scale app NextCloudのお引越し

# 背景
PowerEdge R730xd 2.5インチシャーシタイプをesxiサーバ兼TrueNASサーバとして変わった使い方をしておりました。
仮想サーバのディスク容量に少し限界がきており、某オークションサイトを覗いたところ、PowerEdge R730xd 3.5インチシャーシタイプが格安で売っており、運よく入手できたため重い腰を上げ移行作業を行ったものになります。
PowerEdge R730xd 2.5インチシャーシタイプはesxiのiscsi専用ストレージ化をする予定です。

# システム構成(殆ど変わりません)
|項目  |旧サーバ  |新サーバ  |
|---|---|---|
|メーカー  |DELL |DELL  |
|型番  |PowerEdge R730xd(2.5タイプ)  |PowerEdge R730xd(3.5タイプ)  |
|CPU  |Xeon E5-2620 v3  |Xeon E5-2620 v3  |
|メモリ  |196GB  |96GB  |
|HDD  |1.8TB(SAS)×16 +1TB(SSD)×8  |8TB×4(今後増える予定)  |
|データベース  |PostgreSQL|PostgreSQL |
|TrueNASバージョン  |記録失念|24.04.1.1 |
|ディスク使用量  |4.5TB|4.5TB |

# 手順
1.メンテナンスモードの有効化
2.dataフォルダのバックアップ
3.データベースのバックアップ
4.configフォルダのバックアップ
5.nextcloudフォルダのバックアップ
6.データコピー
7.データリストア
8.メンテナンスモードの無効化


# 1.メンテナンスモードの有効化
旧サーバ
```:Nextcloudコンテナにログイン
docker exec -it -u 33 "コンテナ番号" /bin/bash
```
```:メンテナンスモードの実行
php /var/www/html/occ maintenance:mode --on
```
```:メンテナンスモードの確認
php /var/www/html/occ maintenance:mode
```

新サーバ
※TrueNAS24.04.1.1からdockerコマンドが廃止になりkubectlコマンドになりました
```:Nextcloudコンテナにログイン
kubectl exec -it "コンテナ番号" -n ix-nextcloud -- sh -c "su -s /bin/sh www-data -c 'php /var/www/html/occ maintenance:mode --on'"
```
```:メンテナンスモードの確認
kubectl exec -it "コンテナ番号" -n ix-nextcloud -- sh -c "su -s /bin/sh www-data -c 'php /var/www/html/occ maintenance:mode'"
```

# 2.バックアップ作業
※ここでは詳細を割愛します。
・TrueNASのレプリケーション機能などでデータをバックアップ
・PostgreSQLは以下手順で実施
```:DBバックアップ
pg_dump -U user nextcloud > /path/to/backup/nextcloud_backup.sql
```

# 3.データリストア
・ファイルなどのデータ
　レプリケーション機能で取得したバックアップを所定のフォルダにリストア
　今回は諸事情により、
 　レプリケーションディレクトリ　→　新規NextCloudディレクトリにコピーを実施
  　※12Gbps SASということもありSATAよりコピーが早かった気がします。

・PostgreSQLは以下手順でリストア
```:postgresコンテナにログイン
kubectl exec -it ”コンテナ番号”-n ix-nextcloud -- /bin/bash
```
````:特権ユーザーに切り替え
psql -U ”特権ユーザー”
````
```:postgres データベースに接続
\connect postgres
```
```:nextcloud データベースの削除
DROP DATABASE nextcloud;
```
※既存のnextcloudデータベースがあるとリストア作業時にエラーが発生します。
```:nextcloud データベース再作成
CREATE DATABASE nextcloud OWNER nextcloud;
```
```:アクセス権限の設定
GRANT CREATE, TEMPORARY, CONNECT ON DATABASE nextcloud TO ”権限付与するユーザー”;
GRANT CONNECT ON DATABASE nextcloud TO ”権限付与するユーザー”;
```
```:PostgreSQLシェルを終了
\q
```
```:データベースのリストア
psql -U nextcloud -d nextcloud -f ”バックアップファイル保存先”
```

# 4.メンテナンスモードの無効化
```:旧サーバ
php /var/www/html/occ maintenance:mode --off
```

```:新サーバ
kubectl exec -it "コンテナ番号" -n ix-nextcloud -- sh -c "su -s /bin/sh www-data -c 'php /var/www/html/occ maintenance:mode --off'"
```
# 次のステップ
これまでNextCloudはVPN経由で使っていましたが、都度VPNをONも手間なので
cloudflareを使って簡易に接続できるようにしたいと思います。

# 参考にしたサイト
・https://denor.jp/nextcloud%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92%E5%BC%95%E8%B6%8A%E3%81%99%E3%81%AB%E3%81%AF
・https://www.reddit.com/r/truenas/comments/17h2iw4/docker_command_not_found_i_reinstalled_truenas/
・https://t-dilemma.info/truenas-scale-remote-replication/
XAMPPをインストールしphpの実行環境を構築する方法

## XAMPPのインストール
MacでXAMPPをインストールしてphpの実行環境を構築し、
Web上に「Hello Wild!!」と表示させましょう！

以下のURLからXAMPPをダウンロードします。
https://www.apachefriends.org/jp/index.html
![スクリーンショット 2024-06-22 23.06.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3804950/f77ebc1c-47bf-6079-f291-94d878b47628.png)

##### ダンロードしたXAMPPからインストーラーを起動します。
![スクリーンショット 2024-06-22 23.10.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3804950/e32618da-082e-88dd-3709-ba2c8cff8740.png)

もし、こんな表示されたら、、、
![スクリーンショット 2024-06-22 23.10.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3804950/9ec13a2b-28f8-7e4f-17e2-def4ff14b7a5.png)

Macのシステム設定から
「プライバシーとセキュリティ」でここから開きましょう
![スクリーンショット 2024-06-22 23.11.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3804950/a68683f7-ecca-69f9-774a-095bc041df35.png)

XAMPPのSetupウィンドウが開くので全て[Next]で進めます。
するとインストールが始まります。
![スクリーンショット 2024-06-22 23.21.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3804950/4034acad-6701-4b73-983a-6d5f08fa3c64.png)

#### XAMPPから実行環境を構築
XAMPPを起動します。
以下の階層にある「manager-osx.app」でXAMPPを開きます。
/Applications/XAMPP/xamppfiles/
歯車みたいなマークのやつ

##### XAMPを開いたら
「Manage Servers」タブから
①Apacheが起動しているの確認します、緑色になっていればOKです。
②ポート番号もこの時確認しておきます、画像だと80番ですね
![スクリーンショット 2024-06-22 23.41.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3804950/bfcc69de-6f25-e56c-309f-73c3c04cfcc4.png)

port番号は変更できますが今回は割愛します


##### プロジェクトのディレクトリを作成
以下の階層にプロジェクトのディレクトリを作成します。
今回は「qiita」とします.
/Applications/XAMPP/htdocs/qiita

##### phpファイルを作成
qiitaディレクトリに「index.php」を作成し、以下のコードを書きましょう。
/Applications/XAMPP/htdocs/qiita/index.php

```index.php
<?php
echo 'Hello Wild!!';
```

##### web上で確認
では実際にwebで確認しましょう。
webブラウザでURLに以下を入力します。
http://localhost/qiita/

「Hello Wild!!」 と画面に表示されているはずです。

これでXAMPPによる実行環境の構築は完了です！
DockerにUbuntuが侵食されていたのでやったこと

# はじめに

仕事や個人開発以外に使用できるマシンが欲しかったので、大学時代に使用していたSurface-Pro-6にUbuntuを入れて、なにをやってもいい環境を作って遊んでいました。

そもそもの容量も少ないのになにも考えず、dockerを使いまくっていたら`docker/overlay2`の中身が肥大化して容量がいっぱいになっていました。

容量を確保するためにやったことをまとめようと思います。

::: note warn
なにをやっても良い環境であると割り切っているので、普段使いのPCで実行するにはふさわしくないことをやっている可能性があります
:::

# やったこと

1. 容量を大きいディレクトリを特定する
    何が原因で容量の空きがなくなっているか特定します。
    以下のコマンドで容量の大きいディレクトリ上位10個をリストアップします。

    ```bash
    sudo du -S / | sort -rh | head -10
    ```

    私はこれでdockerが怪しいことに気づきました。

2. dockerイメージやコンテナが使っている容量を確認

    ```bash
    sudo docker system df
    ```

    上記コマンドでdockerが使っている容量を見ることができます。
    私はコンテナを作っては削除をしていましたが、キャッシュや動いていない状態で残ったままのコンテナが存在していることがわかりました。

    dockerを使用している方はこまめに確認すると良いかと思います。

3. 使っていないdockerコンテナやイメージなどを削除

    私の場合はほぼ使っていないコンテナばかりが残っていたので、すべて削除することにしました。

    ::: note warn
    以下のコマンドたちは起動していないコンテナやイメージなどすべてを削除していくコマンドなので、確認の上、使用するか決定してください
        :::
        
    起動していないコンテナをすべて削除
    ```bash
    sudo docker container prune
    ```
    起動していないイメージをすべて削除
    ```bash
    sudo docker image prune
    ```
    どのコンテナからも参照されていないボリュームを削除
    ```bash
    sudo docker volume prune
    ```
    上記とキャッシュ含めすべて削除する
    ```bash
    sudo docker system prune --all
    ```
docker コマンド 基本のキ（nginx のコンテナを実行してみる）[2024年7月最新]

こんにちは。
9年前に同じ内容で記事を書いた者です。
[当時](https://qiita.com/thirota/items/dcfc43cb042448a8f8aa)は VirtualBox と boot2docker でコンテナを実行していました。その後、Docker Desktop へと進化しているので、今回はそちらを用いて基本的な docker コマンドを復習したいと思います。

# 環境
* MacBook Air (Intel Core i5)
* macOS Sonoma 14.5
* Docker Desktop 4.32.0

# 準備
Docker Desktop は起動しているものとします。

![スクリーンショット 2024-07-12 23.36.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83323/4162bcfc-c784-8962-2ee4-a7863f2ea9ce.png)

# Docker イメージの取得
Docker Hub から最新の Docker イメージを取得します。

```
docker pull nginx:latest
```

取得済みのイメージは `docker images` で確認できます。

```
docker images
```

# コンテナの作成と実行
`docker run` でコンテナを作成して実行します。

```
docker run --name my-nginx -d -p 8080:80 nginx:latest
```

# コンテナの状態確認
```
docker ps
```

# nginx の動作確認
ブラウザで http://localhost:8080 へアクセスします。
ポート番号は `docker run` で指定した8080番です。
Welcome to nginx! で歓迎されたら成功です。

# コンテナの停止
```
docker stop my-nginx
```
```
docker ps
```

`-a` オプションを付けると終了したコンテナを確認できます。

```
docker ps -a
```

# コンテナの再実行
終了したコンテナを再度実行します。

```
docker start my-nginx
```
```
docker ps
```

# コンテナの削除
終了したコンテナを削除します。

```
docker rm my-nginx
```
```
docker ps
```

# Docker イメージの削除
不要な Docker イメージを削除します。

```
docker images
```
```
docker rmi nginx:latest
```
```
docker images
```

# まとめ
Docker イメージの取得からコンテナの実行と停止、イメージ削除までの一連の作業を確認できました。慣れるまでは多少わかりにくいので、コンテナのライフサイクルをご自分で絵に描いてみると理解が深まると思います。

# 参考
* Dockerエキスパート養成読本
    * http://www.amazon.co.jp/dp/4774174416
* https://registry.hub.docker.com/_/nginx/
実践するポモドーロ・テクニック

# はじめに
私が普段仕事で実践しているポモドーロ・テクニックについて紹介したいと思います。
仕事だけでなく勉強などにも適用でき、上手く使えば効率よくタスクを進めることができる手法だと思っています。

# ポモドーロ・テクニックとは
ポモドーロ・テクニックは、**時間管理** の方法の一つで、1980年代後半にフランチェスコ・シリロによって考案されました。このテクニックは、作業を短い集中時間（通常25分）に分け、その後に短い休憩（通常5分）を取ることで構成されます。この一連のサイクルをポモドーロと呼びます。
このテクニックは、集中力を高め、生産性を向上させるために設計されています。また、休憩を取り入れることで、精神的な疲れを軽減し、長時間の作業でも効率を保つことができます。

フランチェスコ・シリロの著書

https://www.amazon.co.jp/%E3%81%A9%E3%82%93%E3%81%AA%E4%BB%95%E4%BA%8B%E3%82%82%E3%80%8C25%E5%88%86-5%E5%88%86%E3%80%8D%E3%81%A7%E7%B5%90%E6%9E%9C%E3%81%8C%E5%87%BA%E3%82%8B-%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%BB%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80-%E3%83%95%E3%83%A9%E3%83%B3%E3%83%81%E3%82%A7%E3%82%B9%E3%82%B3%E3%83%BB%E3%82%B7%E3%83%AA%E3%83%AD-ebook/dp/B07NRKH13Z

ちなみに、著者がトマト（イタリア語で、ポモドーロ）型のキッチンタイマーで25分測っていたため、このようなネーミングになったそうです。

# 基本的なステップ
ポモドーロ・テクニックの基本的なステップは次の通りです。
1. 自らのタスクを分解し、どこまでを1つのポモドーロ（25分）の中でやるか計画を立てる
1. タイマーを25分にセットする
1. タイマーが鳴るまで、**選んだタスクだけを** 取り組む
1. 25分経ったら、**必ず** 5分間の休憩を取る
1. 4回のポモドーロが終了したら、**必ず** 長めの休憩（15〜30分）を取る

なお、1ポモドーロは基本25+5分の30分ですが、時間は変更しても大丈夫です（ポモドーロの途中で当初予定していた時間より切り上げたり追加したりするのはダメです）。

# ルール
以下を順守することで、逆に不便に感じることもありますが、個人的には厳しく守らないと得られるメリットも薄れてしまうと思っています。私がポモドーロ・テクニックを実践していて感じたことも含めて書いていきます。

## ポモドーロは分割できない
25分経って休憩せずに次の25分を始めてはいけません。**必ず1つのポモドーロは集中と休憩がセットです。**

なお、単純なタスクを一つのポモドーロに予め複数組み込んでおくのは大丈夫です。私の場合、朝のメール確認&就業登録などの作業を1つのポモドーロでやっています。
また、事務作業が溜まってきたら1つのポモドーロとして定義し、まとめて片づけたりしています。

## タイマーが鳴ったら途中でも必ず作業をやめなければならない
一気にタスクが片付きそうなときに中途半端なところで25分経つと本当に歯がゆい気持ちになります。5分休憩したくなくなります。それでも、**絶対に5分休憩してください。** その方が、より長く楽に、効率的に作業を続けることができるからです。

実際、そのように焦っている時ほど危険です。品質が悪くて後で修正が必要だったり、重要なことを見落としていて手戻りが発生したりします。5分休憩すれば、その時間に頭がクールダウンされ自分の作業を常に客観的に見ることができるようになります。

ポモドーロ・テクニックを実践していると、何度も何度も歯がゆい気持ちになりました。ですが、次第に**25分という短い時間を大切に使うようになっていきました。**



## タイマーが鳴るまで事前に決めたことだけをやらなければならない
作業時間を25分間と決めて作業をやっていると、事前に決めたことが終わって残り10分くらい暇なことがあります。そういう時は違う作業をやりたくなりますが、それをやってはいけません。

もし時間が余ったら、いまやった**作業の見直し**をします。ここで意外と誤字脱字やケアレスミスに気づけたりするので、忙しいときにもこれを厳守することで成果物の品質向上につながっていると思っています。

## 5分程度の中断ならポモドーロを続けてもよい
ポモドーロ中にチャットやメールの通知が来て今やっていることへの集中が薄れることがありますよね。そんな時は**完全に無視します。**「自分はポモドーロ中だから決めたこと以外やってはいけない」と自分に言い聞かせましょう。

とはいえ、直接話しかけられたり電話が来たりどうしてもポモドーロを中断せざるを得ないこともありますよね。そんな時はポモドーロを**一時的に中断しても大丈夫です。**
しかし、中断できるのは5分程度で、それ以上中断されるとそのポモドーロは無効となります。

ですので、私の場合は用件だけをメモして「後で確認する」と言って元の作業に戻ったり、ダラダラと話さないように意識しています。

また、アドバイスとして、ポモドーロ・テクニックをしていることを周りに言っておき、話しかけられたときはこれ見よがしにタイマーを止めるようにするというのも手です。そうすることで、集中している時は気を遣って話しかけないようにしてくれるケースもあると思います。

## 一つのタスクに対して4ポモドーロ以上かける見込みを立ててはいけない（タスクを分割する）
大きなタスクを分解したときに4ポモドーロ以上かかる計画になった場合、計画を再考してください。これ以上タスクを分けられないと思っても、**逆にどこまでなら4ポモドーロ（2時間）の中でできるかを考えてください。**

# その他実践していること
## 過去のポモドーロのタンキング
ポモドーロ・テクニックを実践していると、**自分が立てる作業見積もりの甘さに気づかされます。** それを精緻にしていくために、過去自分が1ポモドーロの中でどんな作業を行ったのか、また一つのタスクを何ポモドーロに分けたのかの予定・実績を全て表にしてタンキングしています。
同じような作業をする時にタンキングしている表を見て計画を立てることで、より正確な見積もりをすることができるようになったと思っています。

# さいごに注意点
一番重要なのは、この手法の**目的をしっかりと理解**して適材適所で使うことだと思っています。

個人的には、新入社員やまだ現場に慣れていない方などは特に小手先のテクニックに縛られず泥臭く仕事をして、慣れてきたら**まずは自分なりの管理の手法を実践してみるのがよいと思います。**

その後でポモドーロのような手法を実践してみて、良さそうな部分を吸収するイメージです。そうでないと、方法論に囚われてしまって自分の業務とフィットしない等の問題が出るからです。

# おわりに
皆さんも是非上記を参考にポモドーロ・テクニックをやってみてください！
【Python】Object of type is not JSON serializable

オブジェクトをjsonに変換しようとするとタイプエラーが発生したので記録
`TypeError: Object of type SampleClass is not JSON serializable`

## 原因
JSONへのエンコーダとしてはデフォルトで`json.JSONEncoder`を使用しており、変換の際の対応は以下になります。
|Python  |JSON  |
|---|---|
|dict  |object  |
|list,tuple  |array  |
|int,float  |number  |
|True  |true  |
|False  |false  |
|None  |null  |

つまり、ここにない型をエンコーディングしようとするとTypeErrorが出るというわけです
object, Enum, datetime型などをjsonにしようとした際に遭遇する問題でしょうか
```py
import json
from datetime import date
from enum import Enum
class Color(Enum):
    RED = 1
    GREEN = 2
    BLUE = 3

class SampleClass:
    def __init__(self, name):
        self.name = name

# datetime
json.dumps(date.today()) # TypeError: Object of type date is not JSON serializable

# Enum
json.dumps(Color.RED) # TypeError: Object of type Color is not JSON serializable

# object
json.dumps(SampleClass("bob")) # TypeError: Object of type SampleClass is not JSON serializable
```

## 対応
`JSONEncoder`クラスを拡張してデフォルト以外の型にも対応できるようにします。
サブクラスを用意し、default()メソッドをオーバーライドし、任意のオブジェクトを上記対応表の認識可能な型に変換します。

具体的には以下のように`JSONEndecoder`のサブクラスで`default()`を実装し、デフォルト以外の型の場合にどのような変換を行うかを定義します。
```py
class CustomJSONEncoder(json.JSONEncoder):
    def default(self, obj):
        # Enum -> str,int
        if isinstance(obj, Enum):
            return obj.value # or obj.name
        # datetime -> str
        if isinstance(obj, datetime):
            return obj.isoformat() # https://docs.python.org/ja/3.7/library/datetime.html#datetime.datetime.isoformat
        # object -> dict
        elif isinstance(obj, object) and hasattr(obj, '__dict__'):
            return obj.__dict__
        # dict,str,int,... -> default       
        return super().default(obj)
```

これを使って先ほどの例を試します
```py
class Color(Enum):
    RED = 1
    GREEN = 2
    BLUE = 3

class SampleClass:
    def __init__(self, name: str, color: Color, created_at: datetime):
        self.name = name
        self.color = color
        self.created_at = created_at


sample = SampleClass("bob", Color.RED, datetime.now())
sample_json = json.dumps(sample, cls=CustomJSONEncoder)
print(sample_json) # {"name": "bob", "color": 1, "created_at": "2024-07-12T14:34:53.927615"}
```
無事にシリアライズできるようになりました。
ref : https://docs.python.org/ja/3/library/json.html#module-json
xsltにおけるvalue-ofとcopy-ofのちがい

個人的「質はともかく継続する」35日目です。

## copy-ofとvalue-ofのちがい

こんなxmlから、descriptionの値を取得することを考えてみます。
```xml
<person>
  <name>しぶさわ　えいいち</name>
  <age>30</age>
  <description>すごい<br>実業家</description>
</person>
```

### value-ofの場合

value-ofの場合、タグは無視されて、値だけ取り出されます。
この例の場合、間にある<br>も出力されません。
名前の通り、valueのみ取り出すイメージです。

```xsl
<xsl:value-of select="person/description"/>
```

```html
すごい実業家
```

### copy-ofの場合

copy-ofの場合は、ノード全体を取り出します。
この例で言えば、前後や中にあるタグもそのまま出力されます。
こちらも名前の通り、copyするイメージです。

```xsl
<xsl:copy-of select="person/description"/>
```

```html
<description>すごい<br>実業家</description>
```
【セッションレポート】「実践導入！キャッシュレイヤによるOracleコスト削減」に参加しました

# はじめに

本記事はDB Tech Showcase 2024 の2日目(7/12)において AWS の堤さんが講演された「実践導入！キャッシュレイヤによるOracleコスト削減」のレポートです。

# 公式セッション紹介

> キャッシュレイヤはOracleやRDBMS等のコスト削減に対する強力な武器となります。しかしごく一部でしか使っていない、どの程度の効果があるか分からない、トレードオフが分からない、という方も多いのではないでしょうか。本セッションではキャッシュレイヤ導入に向けてユーザー事例、コスト試算、サンプルコード、実装時の注意点等を30分に凝縮してお伝えします。

# セッション資料

- 現時点(2024/7/12)では未公開？

# 概要／おすすめポイント

このセッションでは、RDS for Oracle を例に キャッシュ層 を利用することで全体としてコスト削減ができますよ、という話です。データベース自体はOracle Databaseに限られる話でもなく、例えば発表者の堤さんが昨年 「[Amazon ElastiCache を使用して RDS for MySQL ワークロードのコストを最適化し、パフォーマンスを向上させる](https://aws.amazon.com/jp/blogs/news/optimize-cost-and-boost-performance-of-rds-for-mysql-using-amazon-elasticache-for-redis/)」というタイトルでAWS blogを書かれてますし、ワークロードによってはキャッシュを利用することでコスト最適化を図ることができますよ、というお話でした(Oracle Databaseに限らず)。

リクエストが少ないシステムでキャッシュを入れてもTCOは削減されない、という話もあり、どのような場合に検討すると良いかもイメージできるようになっていました。
また、このセッションの中でOracle Databaseのワークロード調査ツールであるDBCSI(Database Current State Investigation)であったり、SQL Serverの調査ツールである RDStools が紹介されており、それらを利用することでキャッシュ導入を検討すべきかを判断できるような流れになっていました。

# セッション内容の紹介

次の図は今年のAWS Summitの堤さんの発表資料([NoSQL コスト削減⼤全](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-38_Database_AWS_Summit_JP_2024.pdf))からの引用なのでDBTS2024の資料とは若干内容が違いますが、イメージとしてはこの図と同様のお話になります。
キャッシュ層としてElastiCache for Redisを導入することで全体のコスト削減ができるというお話です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2313926/551d888c-a590-0a4f-b709-eda03fabce72.png)

また、このような構成でコスト削減が可能となるのはおおむね次の特徴のワークロードが該当する、という話でした。ようは、キャッシュが効率的に利用できるワークロードでないと、効果が出づらいという形になると考えてます。
- 読み取りが全体の7割以上
- リードレプリカをすでに複数利用している
- 同じデータの読み取りを繰り返すワークロード
- リクエストに対するスループット要件が高い

現在のシステムが上記のワークロードに該当するかは、DBCSIやRDStoolsを利用することで確認ができるとのことでした。ただ、DBCSIはAWSのサポート等に相談して入手し、一緒に調査するような形で使った方が良いとアドバイスされていました。

# まとめ

キャッシュを利用してメインのデータベースの負荷をオフロードして全体のコスト最適化を図る、というのはとてもシステムとしては美しいと感じますが、やはり複雑度が増すため難易度は高くなると考えてます。
実際に事例としても2023年のAWS Innovateで紹介されていた Oisix さんの事例(スライドは非公開)以外ではまだあまり聞いたことはありません。。

とはいえ、AWSのパーパスビルト的なデータベースの利用法からすると適切な形となるため、実装のノウハウがたまってきて事例が増えてくると、利用は増えてくるかもしれません。
1つの方式として今後もウォッチしていきたいと考えてます。
熱中症オープンデータAPIまとめ

熱中症のオープンデータAPIまとめ

|API名 | URL |
| ---- | ---- |
| 環境省オープンデータAPI | https://showcase.env.go.jp/opendata-api/ |

民間でも熱中症APIはありますが、オープンデータとしては環境省さんが提供しています。
『感想』Amazon Bedrock生成AIアプリ開発入門

## はじめに
この度はタイトルの「Amazon Bedrock 生成AIアプリ開発入門を読んだ感想を投稿します。

https://www.sbcr.jp/product/4815626440/

私は技術書が好きなのでよく購入して読むのですが、感想の投稿は初です。というか**Qiita投稿が初。**

Qiitaはこれが初投稿ですが、最近アウトプットを強化しておりZennもやってます。

https://zenn.dev/mkdevelop

Qiitaを始めた理由は投稿のイベントなどが、あり面白そうでした。うまく使い分けていこうと思います。

## 購入はKindle版
さて本題。私は紙の本も大好きですが会社用は紙。個人用は電子のように買い分けています。

https://x.com/mkdev_10/status/1805734346328097205

この本を書店で見たときはサイズ感に驚きましたが。
1週間ほどで読み切ったと思います。それぐらい内容が面白くのめり込める一冊でした。

移動中、休憩中、休日。ずっとお供って感じです。

## 書籍の構成
- 第1章　生成AIの基本と動向
- 第2章　Amazon Bedrok入門
- 第3章　生成AIアプリの開発手法
- 第4章　社内文章検索RAGアプリを作ろう
- 第5章　便利な自立型AIエージェントを作ってみよう
- 第6章　Bedrockの機能を使いこなそう
- 第7章　さまざまなAWSサービスとBedrockを連携しよう
- 第8章　生成AIアプリをローコード開発しよう
- 第9章　Bedrock以外の生成AIサービスの紹介
- 第10章　Bedrockの活用事例
- 第11章　お勧めの最新情報のキャチアップ

全11章の構成となっており、生成AIの基本からBedrockの基礎、利用できるモデルの特徴。作れるアプリや周辺サービスから事例だのキャッチアップ方法まで盛りだくさん。

**かつハンズオンで手をうごかして学べるのが良き!**

ここからは各章を簡単に紹介

:::note info
あくまでも個人の見解です。
:::

### 第１章 生成AIの基本と動向
生成AIについての基本知識が述べられていて、各用語の解説など述べられている。**絵付きでカラー**なのでフレンドリーに楽しめ、理解しやすくまとめられている。

### 第２章 Amazon Bedrok入門
Bedrockについての基本的な知識が述べられている、利用できるモデルの情報などが細かく紹介されていて、プロンプトの出力例やコスト感などが紹介されている。この章には簡単なハンズオンがありCLIからBedrockが利用できる!

### 第3章　生成AIアプリの開発手法
生成AIアプリ開発で重要なプロンプトやトークン。プロンプトエンジニアリングについて解説がある。この章にはハンズオンもあり。**ワクワクがマシマシになる章。**

### 第4章　社内文章検索RAGアプリを作ろう
今流行りのRAGについて学べ。なんとハンズオンまでついている!もうこのころには書籍に食いついているはず。ただしOpenSearch Serverlessを利用したハンズオンなので削除必須なのは要注意ポイント。

### 第5章　便利な自立型AIエージェントを作ってみよう
AIすごってなるエージェントを学べる章。ハンズオンが楽しく。個人的によかったのはエージェントの行動のトレース方法まで紹介があったこと。実践的なことに重きを置いてくれている。

### 第6章　Bedrockの機能を使いこなそう
カスタムモデルやガードレールなど。Bedrockの周辺機能について解説されており、キャッチアップ遅れていがちな情報を知れる。

### 第7章　さまざまなAWSサービスとBedrockを連携しよう
BedrockのAPIの呼び出し記録の確認方法やIaCでの構築などが紹介されている。そのほかのAWSサービスとの連携なども紹介されている。

### 第8章　生成AIアプリをローコード開発しよう

この書籍で私が一番お気に入りの章。Setp FunctionsとBedrockの組み合わせが紹介されており、この章のハンズオンが**本当に楽しくて楽しくて。**
紙の書籍をゲットして。チームのみんなとハンズオン大会をしようと思っている。
というか毎年新人には研修でこのハンズオンをやりたい。**BedrockやAWSを好きになってもらえると確信している。**

### 第9章　Bedrock以外の生成AIサービスの紹介
AWSの生成AIサービス群たちが紹介されている。たくさんサービスあるので役割理解が難しかったりするので助かる章。

### 第10章　Bedrockの活用事例
すでに活用されている事例紹介。ここで素晴らしいと思ったのは、なぜこのアーキテクチャなのか?のような細かい解説もある。

### 第11章　お勧めの最新情報のキャチアップ
キャッチアップ方法がたくさん紹介されている。著者の方々の素晴らしさが感じられる章。

## ハンズオンの注意点
### 環境依存問題
この書籍に限ったことではないけど、Cloud9を使わないと環境依存に困ることがある。この書籍だとLamndaレイヤーの部分で環境依存で困った。

私はローカル（Mac）でハンズオンするスタイルなので問題に生じたが、**この書籍の素晴らしいところはその部分も保管する解説があるところ。** 無事ローカル環境でもすべてのハンズオンを実施できた。

### 海外リージョン問題
サービスがリージョンを利用している点。もしかすると**会社で払い出されたアカウントとかだと利用できないケースがあるかも**。最近私のブログでこのてのエラーについて消化した記事のアクセスが増えているのでリンクだけ貼っておく。誰かのお役に立てば幸いです。

https://zenn.dev/mkdevelop/articles/1474051017e3b6



## まとめ
ぶっちゃけ、どの層も楽しめる書籍だと思う。個人的には**8章が好きすぎる**。BedrockとStep Functionsのプロンプトチェイニングのハンズオンは素晴らしい。そして各章にある。**薄ピンクのMemo。これは読みとばさずに全部読んでほしい。** 有益な情報が詰まっている。

## 最後に
こんな素晴らしい書籍を世に出してくれた著者の方々には感謝です。リモートではなんどもお目にしてる方々ですが、対面でお会いでそうでお会いできていないので。いつか会える日を楽しみに、今後もコミュニティへの参加。書籍の感想、キャッチアップした情報などブログや登壇でアウトプットしようと思います。
エンジニアにおすすめの本〜アウトプット大全

# きっかけ
1. 転職して案件にアサインされるまでに時間があった
2. 何か技術的に何か勉強する指針がない
3. youtubeでこの本の紹介を見た
4. 今までの経験上、技術ではなく仕事の進め方に問題があると感じていた


今までできていなかったアウトプットをしようと思える本に出会えました

qiitaで記事を書かれている方はアウトプットされていると思いますが読んでいるだけの方もぜひ記事を書かなければとせかされるような内容でした

まずはトレーニング部分に触れて細かい内容を書こうと思います

# 本の紹介

https://www.amazon.co.jp/gp/aw/d/4801400558

https://youtu.be/ZRo6SGlT9Bk?si=ZAumk7pYsjN1SMm2

- エンジニアおすすめ度:⭐︎⭐︎⭐︎
- 社会人おすすめ度:⭐︎⭐︎⭐︎⭐︎⭐︎

本の構成がとてもわかりやすくみやすいです

基本見開き1ページで話が完結しています。結論から書かれていてそれを捕捉する内容や研究結果などが書かれています。

# アウトプットトレーニング
## 日記を書きましょう

いまさら日記なんて書けるわけないじゃんと思われるかもしれません

日記を書く理由は以下になります

### アウトプットの練習になる
3行または5分でいいので今日あったことを書いてみましょう

正直私は書けません

1日の出来事を覚えていないことはないですが何を書く？どう書く？を考えすぎてしまってなかなか書けません

自分用なのでとにかくなんでも書きましょうそれ自体が練習ですし意外に漢字かけません

私は妻宛の手紙を書いてみましたが捻り出してなんとか書きました

日頃からアウトプットしているとスラスラかけるようになると思います


### ポジティブになれる

日記を書く人は楽しかったことを思い出して書くのでポジティブになれるようです

研究結果などは実際の本書を読んでみてください

本当はプログラムやりたいのに設計、テストやっている私のような人間は日々無駄に過ごしてしまうので毎日些細な業務を少しでも自動化できないかなど考える機会になると思います

## 読書感想文を書く

私は本も好きですが映画も好きです

結構覚えている方ですがこの本を読んでハッとさせられました

結局自分の血肉になっていないんですよね

1000円ぐらいの本でも学びはたくさんありますし3000円超えるような技術書はもっと学びがあります

それをインプットしただけでは自分で使えるように離れません

読書感想文は

1. ビフォー
2. 気づき
3. TODO

上記のような形で書きましょう

ブログに起こす場合は少し変えてもいいかもしれませんね

読書感想文を書くことで思い出し記憶に定着してきます

さらに読書感想文を書くためには内容を理解しなければなりません

より深い理解につながるのでぜひ挑戦してみてください


# 本文

ここからは具体的な本文の内容に移ります

## アウトプットとは運動である

確かにそうですね

インプットは食事、アウトプットは運動（カロリー消費？）と考えれば

勉強であれば

インプットは本または参考書を読む、アウトプットは問題を解くブログなどに書くに置き換えることができそうです

確かにアウトプットしないと自分で技術を扱えるようにならないですね

# 話す

話すことも立派なアウトプットです

1. 話す（ポジティブ、ネガティブ）
2. 相談する
3. 伝える
4. 説明する
5. 議論する
6. プレゼンする
7. 教える

全て話しています

話すためには自分の中で話し方、構成を考えると思います

話した結果のフィードバックをもらうことでより早く、伝わりやすく、正確な話し方になると思われます

特にエンジニアは話すことが必須なので積極的に話しましょう

# 書く

## 手で書く

研究により手で書く方が記憶になりやすいそうです

社会人になったエンジニアは特に書くことが減ってきていると思うのでとにかく書くようにしましょう

私は手帳を持つようになり案件の内容を書くようにしていますが忘れなくなった気がします

PCと両方管理しなければなりませんがPCはスケジュール系、手帳は案件の詳細など書くようにしてもいいかもしれません

手帳に書く時は絶対にどう書こうか考えます

より綺麗に残したいと思うはずなので本質を理解していないと書けません

本質を理解するきっかけにもなるのでぜひ手で書きましょう

## 書き出す

脳は三つのことしか同時にできないようです

なにか急に頼まれた時は話を聞きながらメモを残し少し整理して残しておくことで安心して「忘れることができる」とおもいます

付箋などでタイピングしがちですが手で書きましょう

# 終わりに

この本を読んだおかげで今までできていなかったアウトプットを
1. しないと！
2. したい！
3. しないとやばくね？

こんな感じに思えるようになりました

少しでもエンジニアとして、社会人として、人間として成長できるようにアウトプットをしていきましょう