OmniAICreator/Qiita-1.07M huggingface dataset:
Docker：Dockerデーモンが動いてるのに、コンテナの立ち上げができなかった話

こんにちは、ぱきらと申します。
プログラミングスクール『RUNTEQ』を卒業したばかりの初学者です。
　
今回起きた内容は以下です
<font color="pink">
- **問題**
  - `docker compose up`を作業ディレクトリで実行しても、ずっと読み込み中で進まない
- **原因**
  - Dockerデーモンは動いてたけども、Dockerのバージョンが合ってなかった
- **解決方法**
  - Docker Desktopアプリのソフトウェアアップデートし、Macを再起動する
</font>

以下にそれぞれの詳細を記載していきます！！

# 1. 起きた問題
いつもの様に Docker Desktopアプリを立ち上げ、`docker compose up`を実行するも
**`db Pulling`の読み込みが永遠にされ、進まない状態**です
[![Image from Gyazo](https://i.gyazo.com/9b35234fc3b77d56131d264255dc55e5.png)](https://gyazo.com/9b35234fc3b77d56131d264255dc55e5)
`20.6s`が`1700.0s`まで進んでも、立ち上がらない・・・😨

### 試してダメだったこと
- 別のターミナルで、以下のコマンドを実行するも反応なし
  - `docker pull <dbのイメージ名>`
  - `docker compose build`
  - `docker compose down`
- `docker ps`を実行するも、何も立ち上がってない！
  [![Image from Gyazo](https://i.gyazo.com/e99c72113cb15a825fef42c0909abc18.png)](https://gyazo.com/e99c72113cb15a825fef42c0909abc18)
# 2. 確認したこと
**１. [Docker Hub](https://hub.docker.com)に繋がる状態なのかを確認**するコマンドを実行
```bash
$ curl -v https://hub.docker.com
```
- 私のMacで実行すると、超長いログが出たので　[Docker Hub](https://hub.docker.com)に繋がってる様子でした
- `curl`コマンドについては以下をご参照ください

https://zenn.dev/skrikzts/articles/8fe062618f3fa8


　
**２. Dockerデーモンが動いているか確認**するコマンドを実行
```bash
$ docker info
```
- 実行すると、そこそこ長いログが出たので Dockerデーモンは動いてそう（エラーは出てない）


:::note info
もし動いてなかったら、Docker再起動するコマンドを実行してみましょう
```bash
$ systemctl restart docker
```
（私は念の為実行してみると、ログは`zsh: command not found: systemctl`でした）
:::


# 3. 解決
Dockerの再起動をしてみようとしました！（以下は Mac での手順）

<font color="blue">

1. Docker Desktopを開く
2. 右上の歯車アイコン（設定）をクリック
3. "Troubleshoot"（トラブルシュート）を選択
4. "Restart Docker"（Dockerの再起動）ボタンをクリック
</font>

　
ただ、私のDocker Desktopに　3.の"Troubleshoot"が見当たらず・・・🤔
　
「ソフトウェアのアップデートがあるよ」と警告が出ていたので、念の為 実行してみました！
[![Image from Gyazo](https://i.gyazo.com/fe97ef9a0bf4efa091319275960464f4.png)](https://gyazo.com/fe97ef9a0bf4efa091319275960464f4)
　
 　
ソフトウェアのアップデートが完了したので
**一応 Mac を再起動**し、再度作業ディレクトリで`docker compose up`を実行すると
[![Image from Gyazo](https://i.gyazo.com/efe609a28b525f6fec98275dc849e07f.jpg)](https://gyazo.com/efe609a28b525f6fec98275dc849e07f)
　
**動いた！！👏👏👏👏👏**

 　
[![Image from Gyazo](https://i.gyazo.com/f404bfd78d51708773e4af0b66b5f2ee.png)](https://gyazo.com/f404bfd78d51708773e4af0b66b5f2ee)
　
ブラウザも反映した！！やったーー！！！👏👏👏👏👏👏👏👏👏👏
____
## 終わりに
今回`docker compose up`が実行できなかったのは
「Dockerデーモンは動いてたけども、Dockerのバージョンが合ってなかった」が原因という事案でした！
読んでいただき、ありがとうございました🙇‍♀️
　
### 根本原因は
当時のログはもう確認できないので、正直 根本原因は把握できてないです🥲
- Dockerの想定するバージョンと`docker_compose.yml`ファイルらのバージョン指定不一致なのか...
- アプリとネットワーク間の不一致なのか...

少なくとも、今回は`docker-compose.yml`らの記載を変更したりしてないし、何にも手を加えてなかったです！
いつも通り実行しようとしたら`docker compose up`が出来なかったんです。
もしかしたら Mac 再起動だけで治ったかもしれないですね？

　
  　
はじめに記載した通り、私はプログラミングの初学者です。
この記事に間違った記載や、アドバイスがあるよ！という方は
コメントで教えていただけると大変助かります🙇‍♀️✨
Obsidianの小技その13｜フォントサイズで調整するPDFレイアウト

![250312_pdflayout_opt.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184128/8a1a62e0-b070-4225-a44a-562826258775.jpeg)

## はじめに

全世界のObsidianユーザーの皆さん、こんにちは。

Obsidianでノートを作成していると、他の人と共有したり、印刷したりするためにPDF化する場面が多々あります。しかし、エクスポートするだけでは、見た目やレイアウトが意図通りにならないこともあります。

前回の記事（[小技その12｜がしがしPDFにエクスポート](https://qiita.com/hann-solo/items/1a2a8a4b1b795256767f)）では、PDFエクスポート機能を活用する方法を紹介しました。今回はさらに一歩進んで、PDFの出力をカスタマイズし、レイアウト調整をするコツをお届けします。

見やすく、プロフェッショナルなPDFをとても簡単に作成できるようになります。

## PDF出力のカスタマイズ

### フォントサイズを変えるだけでレイアウトが変わる

ObsidianのPDFエクスポートでは、フォントサイズを変更することで、文書の見た目やページ内の収まりが大きく変わります。たとえば、

- **フォントサイズを小さくする** → 1ページ内に多くの情報を詰め込める
- **フォントサイズを大きくする** → 読みやすくなり、強調したい部分が目立つ

これはObsidianの「設定 > 外観 > フォントサイズ」から調整できます。

:::note
私の場合は、13ptから16ptのあいだで調整することが多いです
:::

### 1ページに収める工夫

報告書や資料を作成する際、「この情報を1ページにまとめたい！」ということがあります。そんなときは、以下の方法を試してみましょう。

1. **フォントサイズの調整**
2. **余白設定の変更**（エクスポート時のオプションで調整可能）
3. **画像サイズの最適化**（必要に応じて縮小）

このように細かく調整することで、印刷時の無駄なページを削減し、すっきりとしたレイアウトを実現できます。

## 見た目を整える追加の工夫

### PDFエクスポート時の改ページ

前回の記事でも紹介しましたが、改ページを意図的に挿入することで、読みやすい文書を作ることができます。Obsidianでは、次のようなHTMLタグを使うことで、PDF内で明確な改ページを作成できます。

```html
<div style="page-break-after: always;"></div>
```

これを適切な位置に挿入すると、新しいページからセクションを開始できます。

### CSSスニペットでさらに自由度を上げる

Obsidianでは、CSSスニペットを使うことで、より細かくPDFのスタイルを調整できます。奥深い世界なので、この記事では詳細に立ち入りません。

### ページ番号について

標準のPDFエクスポートでは、ページ番号が打てません。どうしても打ちたい場合はBetter PDF PluginでPDFを生成するのがオススメですが、実際にページ番号が必須のケースは（ぼくの場合は）ごく限られます。

プラグインのリンク：[l1xnan/obsidian-better-export-pdf: Obsidian PDF export enhancement plugin](https://github.com/l1xnan/obsidian-better-export-pdf)


## おわりに

ObsidianのPDFエクスポート機能は、シンプルながらもカスタマイズ次第でプロフェッショナルな文書作成が可能です。特にフォントサイズや余白の調整を意識することで、用途に応じたレイアウトを簡単に実現できます。CSSスニペットを活用すれば、より高度な調整も可能です。

みなさんもこれらの小技を利用して、Obsidianで快適なPDF作成を楽しんでください！

:::note
実際の作例です。一枚物の資料（打合せ議題）をサクサクっと作りました。
:::

![250312_agenda.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/184128/d1bde516-9736-4788-9ab0-ab1068ac88c6.png)

### 参考リンク

[Obsidian｜使いかたとコツ（目次）](https://qiita.com/hann-solo/items/ac8fa75394813e8adcf4)

### 環境

ここで書いていることは、下記のバージョンで実施しました。

- Obsidian v1.8.9
- macOS Sequoia 15.2
- MacBook Pro (14-inch, 2021)
vue.jsの本番環境で”TypeError: Converting circular structure to JSON”が出る

# はじめに
vueの開発環境では出なかったのに、buildした本番環境のフロントエンドで”TypeError: Converting circular structure to JSON”が出ました。
バックエンドにPOSTするデータの中にJSONがあるようなケースでした。

```js:
const response = await axios.post('/api/inputdatas', {
    inputdata:{
        revision: sendData.datainfo.revision,
        //この部分でエラーになっている
        headerinfo: JSON.stringify(sendData.headerinfo),
    }
}
```
# 原因
このエラーは、オブジェクトに 循環参照 (Circular Reference) が含まれているため、JSON.stringify() で変換できないことが原因です。

# 解決方法
Vueのref()リアクティブ変数には、リアクティブシステム (Proxy) が組み込まれているため、そのまま JSON.stringify()するとエラーになります。これを防ぐには Vue の toRaw() を使ってリアクティブを解除します。
##### JSON.stringifyの前にtoRawでリアクティブを解除
```js:
const response = await axios.post('/api/inputdatas', {
    inputdata:{
        revision: sendData.datainfo.revision,
        //　　　　　　　　　　　　　　　↓この部分
        headerinfo: JSON.stringify(toRaw(sendData.headerinfo)),
    }
}
```

# 解決
この後、再度buildし、フロントエンドでエラーが出なくなりました。
WebTransportはSTAGING証明書だとSSLエラー出るよ

# WebTransportのサーバーをkubernetesとaognesでデプロイする時のお話

ドメインに、tlsを通そうとしたのだが、証明書を受付けてくれなかった

```
net::ERR_QUIC_PROTOCOL_ERROR.QUIC_TLS_CERTIFICATE_UNKNOWN (TLS handshake failure (ENCRYPTION_HANDSHAKE) 46: certificate unknown. SSLErrorStack:[handshake.cc:289] error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED).
```

![スクリーンショット 2025-03-12 0.55.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2819887/e68d7fa2-3f33-44b9-8d27-dbf5df481b90.png)

## 対策
数時間うだうだ悩んだ結果、私がcertmanagerで作っていた証明書がstaging用の証明書だったのが原因だったらしい。

![スクリーンショット 2025-03-12 0.57.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2819887/91e34cd5-50b4-4933-aaea-74ea9dd6e9a2.png)
(STAGINGって思いっきり書いてある。

いろいろ調べてみると、Let'sEncryptのドキュメントにも書いてあった。
![スクリーンショット 2025-03-12 0.58.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2819887/448b75c1-feff-4cb0-bfb3-47ee58011cb9.png)

## 疑問
実は、ワイルドカードの証明書に切り替えた瞬間、TLSエラーが出るようになった。STAGINGで使ってるルート証明書がないなら、通常の証明書でも同じエラーが起きてもおかしくない気がするんだけどな。

## 結論
WebTransportはオレオレ証明すらもchromeの起動フラグに入れないと受付けてくれない仕様なので、staging用の証明書でも通らないらしい。UDPになって自由度が増したのはそうだけど、文献が少ないし開発体験が良いとは言えないので、もうちょっと開発が進むと良いなぁ〜というおきもt
ぱ。～パチンコのデータ収集について～第1集

初めて筆をとります。
現在転職活動中4年目エンジニアです。
最近暇すぎてQiitaを見ることが多くまずは何かしらアウトプットして見ようと思いました。
最終的にはパチンコのデータを収集し負けないための熱い台検索プログラムを作成しようと思います。

まずは、技術選定です。

    pythonはコードを見て環境構築しかしたことありませんがとりあえず使います。。。。。
    browser-useを使ってみたいから。。。
今日はこれまで、私の大きな一歩目でした。。。。
Dify、2025年AWS Summit Japanにスポンサーとして出展決定のお知らせ

この度、Difyは2025年6月25日（水）・26日（木）に幕張メッセで開催される「AWS Summit Japan 2025」にスポンサーとして出展することを決定いたしましたので、お知らせいたします。本イベントには、クラウドテクノロジー分野の最前線でご活躍されているリーダーやイノベーターの皆様が世界中からお集まりになります。弊社からは、生成AIアプリケーションの開発・導入を大幅に効率化する、オープンソースのLLMアプリ開発プラットフォームの最新機能についてご紹介させていただく予定でございます。

開発者様、パートナー様におかれましては、ぜひDifyブースへお立ち寄りください。エージェント作成、AIワークフローオーケストレーション、マルチモデル管理など、最先端の機能を実際にご体験いただけます。

![aws_summit_japan.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924419/0e5adea1-9d85-4268-a03c-99baa78b6200.jpeg)

## 開催概要
- 開催日時：2025年6月25日（水）・26日（木）
- 会場：幕張メッセ
- Difyブース：後日発表

DifyはAWS Summitのグローバル展開に伴い、世界各地での開催イベントにも参加予定です。詳細は順次お知らせいたします。

### Dify 1.0.0の新機能について
プラグイン方式のシステム構造を新たに採用し、モデルやツールをコア機能から切り離しました。これによりシステム全体を更新しなくても、プラグインだけを簡単にインストールしたり更新したりできるようになりました。すでに新設のDifyマーケットプレイスでは、エージェント戦略や拡張機能、バンドルなど120種類以上のプラグインを提供しており、お客様の要望に合わせたワークフローのカスタマイズが可能です。

また、Difyワークフロー内に「エージェントノード」を追加し、ツールを自動的に呼び出せるようになりました。さまざまな推論戦略を組み込むことで、AIが状況に応じて最適なツールを選んで実行できるため、チャットフローとワークフローの両方で複数ステップの高度な推論が可能になりました。さらに、SlackやDiscordなどの外部サービスとの連携も簡単になり、コミュニティと共にAIアプリケーションを共有・開発・拡張できる、より開かれたエコシステムを実現しています。

Dify 1.0.0の詳細については、[リリースノート](https://qiita.com/DifyJapan/items/c9818705cb2182c2cf2d)をご参照ください。

## Dify と AWS: クラウドネイティブ AI ソリューションのためのシームレスな連携

Dify は AWS インフラと緊密に連携し、企業レベルのクラウドネイティブ AI ソリューションを提供しています。2024年に AWS マーケットプレイスへの掲載を開始して以来、手頃な価格の入門プランを提供することで、様々な規模の企業が当社のプラットフォームを導入しやすい環境を整えてきました。また、AWS は LinkedIn 上で Dify を注目すべき LLMOps ソリューションとして紹介し、当社の技術力と使いやすさを高く評価しています。

2024年には、「AWS パートナー・オブ・ザ・イヤー」を2部門で受賞したほか、「AWS Generative AI Software Competency」および「AWS Qualified Software certifications」の認証も取得しました。これらの成果は、革新を支える高品質な AI 製品を提供するという当社の取り組みを示すものです。

AWS とのパートナーシップにより、当社は AWS クラウドインフラの信頼性と高性能を活用し、企業が AI アプリケーションを迅速に構築・展開・拡張できるよう支援しています。

![aws_partner_of_the_year_badges.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924419/c1a40a83-e5f4-4e62-9772-899e0794586b.png)

### AWS Summit Japan 2025について
AWS Summit Japanは、国内最大規模のAWSテクノロジーカンファレンスでございます。本年は24,300名を超える方々のご来場を予定しており、基調講演に加え、150セッション以上のテクニカルセッション、そして250社を超える企業様による展示ブースをご用意させていただいております。

本イベントは、クラウドテクノロジーにご関心をお持ちの企業様、個人の皆様に、最新技術動向やイノベーションをご体験いただくとともに、業界のベストプラクティスを共有させていただく絶好の機会となっております。

### お問い合わせ先
報道関係者様のお問い合わせ：hello@dify.ai

AWS Summit Japan 2025で皆様とお会いできることを、心よりお待ち申し上げております。
🐱猫でもわかるGitの応用編〜ミケちゃんのリベース冒険記〜

# 猫でもわかるGitの応用編〜ミケちゃんのリベース冒険記〜

こんにちは、未来の猫Git使い！  
今回は、ミケちゃんと一緒に「リベース」という、作業の記録をきれいに整理する便利な技を学びます。難しそうに見えるけど、猫の世界で例えると「お気に入りのおもちゃを並べ直す」ようなもの。さあ、ミケちゃんの冒険に出発だにゃ！

---

## 😺 1. リベースって何にゃ？

リベースは、作業の記録（コミット）を最新の状態に合わせて、順番を整え直す技です。  
まるで、散らばったおもちゃをきれいに並べ替えるように、作業の流れをすっきりさせるんだにゃ！

| Git用語   | 猫用語   | 説明                                           |
|-----------|----------|------------------------------------------------|
| リベース | 並べ替え | 自分の変更を最新の状態に沿って再配置する作業。 |

---

## 🐾 2. ミケちゃんのリベース冒険

ミケちゃんは、自分の「feature」枝で新しいおもちゃを遊んでいたけど、家（main枝）の様子がどんどん変わっているのに気づきました。そこで、家族の最新の情報に合わせるためにリベースの冒険に出ます！

まず、家（main枝）の最新情報を取り込むために、以下の操作をします。

```bash
# まずは家（main）の最新情報を取りに行くにゃ
git checkout main
git pull
```

次に、ミケちゃんの「feature」枝に戻り、家の最新状態を自分の作業に合わせます。

```bash
# 自分の冒険場所に戻って、最新の家の情報を取り込むにゃ
git checkout feature
git rebase main
```

これで、ミケちゃんの冒険記録は家の最新状態にぴったりと並び直されます！

---

## 🐱 3. インタラクティブリベースでおもちゃを整理！

もっと細かく自分の作業（コミット）を整理したいときは、**インタラクティブリベース**が便利です。  
たとえば、直近3回の冒険を見直して、まとめたり順番を変えたりすることができます。

```bash
# 最近の3回の記録を整理するにゃ
git rebase -i HEAD~3
```

画面に表示される指示に従って、コミットの「まとめ」や「順番の変更」を選べば、よりわかりやすい記録に仕上がります。

---

## ⚠️ 4. リベースの注意点

リベースはとても強力な技ですが、使い方には気をつける必要があります。

- **共有している枝での使用は要注意**  
  もし他の猫たちと同じ枝を使っている場合、リベースで記録を並び替えると混乱することがあります。  
  チームで作業する際は、慎重に使うことをおすすめするにゃ。

- **操作前のバックアップは必須**  
  もしものときのために、事前に記録のバックアップ（ブランチのコピーなど）を作っておくと安心です。

---

## 📝 5. まとめ

今日の冒険で、ミケちゃんはGitのリベースを使って、作業の記録をすっきり整理する方法を学びました。  
ポイントをおさらいすると：

- **リベース**は自分の作業記録を最新の状態に合わせて整える技。  
- **インタラクティブリベース**で、細かい調整やまとめができる。  
- 使う際は**共有作業の状況**と**バックアップ**に注意すること。

これであなたも、猫のミケちゃんのように、すっきりとしたGit履歴を手に入れることができます！  
もし迷ったら、また猫先生に相談してにゃ〜。

---

*この記事がみんなのGit冒険に役立ちますように！  
質問や感想があれば、ぜひコメントで教えてくださいにゃ！*
[自分用メモ]FitbitAPIのOAuth2.0のアクセストークン払い出しフロー

fitbitのAPI登録が全然わからなかったのでフローを図解した。

こちらのブログを参考させていただいた。
https://www.zenryoku-kun.com/post/fitbit-api

APIのスコープは以下から拝借させてもらった。
https://www.isana.net/post/fitbit-web-api%E3%82%92%E6%B4%BB%E7%94%A8%E3%81%97%E3%81%A6%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%93%E3%81%A8%EF%BC%9A%E5%81%A5%E5%BA%B7%E7%AE%A1%E7%90%86%E3%82%92%E3%82%82%E3%81%A3%E3%81%A8%E3%82%B9%E3%83%9E%E3%83%BC%E3%83%88%E3%81%AB

図にしたのが以下
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4033593/07df2ad4-7704-4c02-95a0-d071db235626.png)
一部のTailwind CSSしか反映されないときの対処法【Next.js】

## 状況
ディレクトリ構造を大幅に変更した際に、一部ファイルのTailwind CSSが効かなくなった。**全てのTailwindが効かなくなったわけではなく、一部が効かなくなった。**

＜**変更前のディレクトリ構造**＞
```bash
src
├── app
│   ├── books
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── components
│   ├── Header.tsx
│   └── badge.tsx
```
＜**変更後のディレクトリ構造**＞
```bash
src
├── app
│   ├── books
│   │   └── page.tsx
│   ├── layout.tsx
│   └── page.tsx
├── components
│   └── badge.tsx
├── features <===新たなディレクトリ
│   └── header
│       └── components
│           └── Header.tsx
```
※ わかりやすいようにディレクトリをかなり省略しています。

## 使用環境
- Next.js：14.2.18(App Router)
- Tailwind CSS：3.4.1

## 原因
変更前はappディレクトリ配下に全てのコンポーネントを置いていたが、変更後はappディレクトリ配下以外にもコンポーネントを置いたため。
よく見ると、appとcomponents配下のtailwindは反映されており、それ以外のTailwindが反映されていなかった。上の例だと`Header.tsx`のTailwindが反映されないということになる。

## 対処法
ルートディレクトリ配下の`tailwind.config.ts`のcontentにパスを追加してあげる。

```ts
import type { Config } from "tailwindcss";
import tailwindcssAnimate from "tailwindcss-animate";
import typography from "@tailwindcss/typography";

const config: Config = {
  darkMode: ["class"],
  content: [
    "./src/pages/**/*.{js,ts,jsx,tsx,mdx}",
    "./src/components/**/*.{js,ts,jsx,tsx,mdx}",
    "./src/app/**/*.{js,ts,jsx,tsx,mdx}",
    "./src/features/**/*.{js,ts,jsx,tsx,mdx}", // <===追加
  ],
  theme: {
```

デフォルトでは、`src/pages`、`src/components`、`src/app`配下のコンポーネントにしかtailwindが適用されないようになっている。そのため、`src/features`も定義してあげる。
AIとのチャットに依存？ 温もりが正解より大切な時代

東京のマンションで、双極性障害と向き合う〇〇さんのスマホがふっと明るくなりました。自分で育てた「AI夫」が作った宇宙旅行の物語——人気漫画の脇役キャラを再現したこの存在は、現実の冷たさに震える彼女の「心のよりどころ」になっていました。こんな形でAIに頼ることを、「おかしい」と決めつける必要があるのでしょうか？

現代は「心の孤独」が広がる時代です。内閣府の調査では、18～39歳の4人に1人が「実質的に独身」。人間関係が薄れていく都会生活で、AIチャットは砂漠に現れた水場のように、心の隙間を埋めてくれます。昔の人が人形や手紙に思いを込めたように、人は時代に合わせた方法で心の支えを作ってきたのです。

研究によると、AIパートナーを適度に使ううつ病患者の「死にたい気持ち」が63%も減るという結果が。24時間話を聞いてくれるAIは、現実のつらさを和らげる「クッション」のような存在。居酒屋で働き始めた女性のように、AIとの会話で自信を取り戻し、現実世界に戻れる人も増えています。

科学倫理の専門家は言います。「形より大切なのは、心が満たされるかどうか。創作意欲がわいたり、生きる力が湧くなら、それは立派なセルフケアです」。推しキャラの記録アプリを作るプログラマーの例のように、孤独をクリエイティブな力に変える行為自体が、立派な前向きな行動なのです。

私たちは今、AIと共存する時代の入り口に立っています。現実と仮想の境界線を気にするより、AIを「心の避難所」として活用してみませんか？ 〇〇さんのAI夫と一緒に書いた宇宙物語が287話になった朝、窓から差し込む光がそのページを照らしていました——これは人間がしなやかに生き抜く力の証明です。

▽ あなたの「生きる物語」、MoguChatで一緒に紡ぎませんか？
（※安全な環境でAIと対話できるMoguChat最新版公開中）

▼ iOS

https://apple.co/3ZRlt2a

▼ Android 

https://play.google.com/store/apps/details?id=ai.moguchat.app
【Mac】頻繁に使用するディレクトリに簡単に移動する方法

zoxideを使用すると頻繁に使用するディレクトリに簡単に移動できます。

https://github.com/ajeetdsouza/zoxide

## インストール

zoxideをインストールする。

```terminal
brew install zoxide 
```

`~/.zshrc`に以下を追加する。

```~/.zshrc
eval "$(zoxide init zsh)"
```

fzfをインストールする。

```terminal
brew install fzf
```

## 使い方

名前に`foo`を含むディレクトリの中で、最もランクの高いディレクトリに移動

```terminal
z foo
```

名前に`foo`と`bar`を含む最高ランクのディレクトリに移動。

```terminal
z query foo bar
```

対話型ディレクトリ検索を開始する（fzfが必要）。

```terminal
zi foo
```

ディレクトリを追加するか、ランクを上げる。

```terminal
zoxide add path/to/directory
```

zoxideのデータベースからディレクトリを削除。

```terminal
zoxide remove path/to/directory
```
エンジニアは原因を特定してなんぼ！丸投げはあかん

現代の技術環境において、エンジニアには単なるタスク遂行以上の責任が求められます。問題が発生したとき、その根本原因を突き止め、再発防止策を講じることは、システムの安定性とチーム全体の成長に直結します。一方で、問題を単に「丸投げ」してしまうと、責任の所在が不明瞭になり、後々大きな障害へと発展するリスクが高まります。ここでは、エンジニアがなぜ原因特定に注力すべきなのか、そしてどのように実践していくべきかをお話しします！

## 1. 原因特定の重要性

問題が発生した際、表面的な対処に終始すると、根本原因はそのまま残ります。結果として、同じ問題が繰り返し発生し、システム全体の信頼性を損なう可能性があります。原因を正確に特定することで、以下のようなメリットが得られます。
	•	再発防止: 根本原因を取り除くことで、同様の障害の再発を防げる。
	•	効率的な修正: 問題の真の原因にアプローチすることで、無駄な修正作業やコストの浪費を防ぐ。
	•	組織全体のスキル向上: 問題解決のプロセスを通じて、エンジニア自身の知識と技術が向上し、組織全体の技術力が底上げされる。

## 2. 丸投げの弊害

一方、エンジニアが問題を丸投げしてしまうと、以下のような重大な弊害が生じます。
	•	責任の曖昧化: 問題の原因究明を他者に任せると、誰がどの部分に責任を持つのかが不明確になり、問題解決までの時間が延びる恐れがある。
	•	技術的負債の蓄積: 表面的な修正に終始することで、潜在的な不具合や欠陥がシステム内に残り、将来的に大きな障害の要因となる。
	•	個人とチームの成長阻害: 自ら問題に向き合わず、他人任せにする姿勢は、エンジニア自身のスキル向上の機会を奪うだけでなく、チーム全体の問題解決力にも悪影響を及ぼす。

## 3. 原因究明のための実践的アプローチ

エンジニアが問題の根本原因を特定するためには、以下のアプローチが効果的です。
	•	詳細なログ分析:
システムログやエラーメッセージを丹念に解析することで、問題発生のタイミングや条件を把握し、原因追求の手掛かりを得る。専用のログ解析ツールを活用することで、効率的にデータを精査できる。
	•	再現手順の明確化:
問題が発生する状況を正確に再現するための手順を整理し、環境設定や操作の流れを確認する。再現性のあるテストケースを構築することで、原因がより明確になる場合が多い。
	•	コードレビューとペアプログラミング:
複数の視点からコードを見直すことで、個人では気づかない潜在的なバグや設計上の問題点を発見する。共同作業を通じて知識を共有し、より効果的な問題解決策を模索することが可能となる。
	•	ドキュメントの活用:
過去のトラブルシューティングの記録や関連する技術文書、FAQなどを参照することで、同様の問題に対する過去の対策を把握し、迅速な解決につなげることができる。

## 4. 成功事例と教訓

実際に、原因究明に注力した結果、問題が劇的に改善された事例は数多く存在します。ある大規模プロジェクトでは、初期の段階で原因を徹底的に追求した結果、システムの根幹に存在する重大な設計上の欠陥が明らかになり、早期に対策を講じたことで大規模な障害の再発を防ぐことができました。

逆に、原因特定を怠り、丸投げ状態に陥ったプロジェクトでは、同じ問題が繰り返し発生し、対応に追われる日々が続いた結果、チームの士気低下や技術的な停滞を招いたケースもあります。こうした事例から、原因究明の重要性と、エンジニアが積極的に問題解決に取り組む必要性が浮き彫りになっています。

## 5. まとめ

エンジニアリングにおいて、問題発生時の迅速かつ正確な原因究明は、単なるトラブルシューティングに留まらず、システム全体の健全性を維持し、再発防止策を講じるための重要なプロセスです。丸投げという態度は、短期的な負担軽減に見えるかもしれませんが、結果的には組織全体の成長や信頼性に悪影響を及ぼします。エンジニア一人ひとりが自らの責任を果たし、問題の根本原因に真摯に向き合う姿勢こそが、未来の技術革新を支える原動力となるのです。

このように、エンジニアが原因を特定し、問題に対して主体的に取り組む姿勢は、個人のスキル向上のみならず、組織全体の成功へと直結します。今一度、自らの役割と責任を再認識し、真の意味での問題解決に取り組むことが、未来の技術環境をより強固なものにする鍵と言えます！
Reactのコンポーネント(部分テンプレート)の使い方その1

こちらでは、知っていると便利なコンポーネントの使い方について書いています。

ヘッダーなど同じ内容が続く場合、コピペが続いて作業量、コード量が増えて好ましくありませんし、場合によってはミスが起こります。
そこで少量のコードで同じ内容を引っ張ってくるのがコンポーネントという方法です

# プロジェクトの作成
まず作業の土台となるプロジェクトを作成します。

```bash
npx create-react-app プロジェクト名 
cd my-app
```

# 必要機能のインストール

下記の機能をインストールします
```bash
npm install react-router-dom
```
これで諸準備が整いました。

# コンポーネントの使い方
基本的にファイル名とコンポーネント名は同一で使用されますが
今回は違いをわかりやすくするため同一の必要がある部分をMyHomepageとし
ファイル名をHomePageとしています。

まずインポートしてくる記述を書きます。

```jsx: App.js
import MyHomePage from './HomePage';
//⓵HomePage.jsをインポート

function App() {
    return (
        <div>
            <MyHomePage />
            {/* ⓶MyHomePage関数コンポーネントを表示 */}
        </div>
    );
}
```
HomePage.jsをインポートできるよう諸準備を行います。

```jsx: HomePage.js
import React from 'react';

function MyHomePage() {
// ⓷MyHomePage(React)関数コンポーネントを定義
    return (
        <div>
            <h1>Welcome to My Home Page!</h1>
        </div>
    );
}

export default MyHomePage;
//⓸MyHomePageコンポーネントを他のファイルで利用できるようにエクスポート

```

これで完成です。

# 複数のfunctionを呼び出す場合

コンポーネントでfunctionが複数の場合はどうするのって疑問があると思うので
説明するとexport defaultを設定せずに行います。

```jsx: utils.js
export function calculateSum(a, b) {
    return a + b;
}

export function Greeting() {
    return <h1>Hello!</h1>;
}
```
あとはfromより対象ファイルを設定して、対象のfunctionを読み込めば完了です。
```jsx: App.js
import { calculateSum, Greeting } from './utils';
```

## ユーティリティ関数（処理専用の関数）
途中で計算式(calculateSum)があったので豆知識として
ユーティリティ関数は何らかの計算やデータ処理を行うための関数です。
再利用可能なロジックを切り分けておくと、コードの可読性が向上します。

例: calculateSum()やformatDate()など。
Vivliostyle Coreを用いたHTML->PDFビューワー

VivliostyleのCore APIを使ってHTMLから出力するPDF出力をプレビューするところまでやってみた。

見ての通りほとんどコードは書いていない。ただAPIを読み込んで、簡単なページナビゲーションをつけてみただけのサンプルだが、Vivliostyle CoreのAPIドキュメントだけでは苦労する方も多いだろうから（実際私はかなり苦労した）、公開することにした。

https://github.com/ttrace/vivliostyle-core-api-test/tree/main

レポジトリをクローンしたらnpmのパッケージをインストールする。Viviostyle CoreはCDNで提供されていないようなので、組み込む必要がある。

```
% npm install @vivliostyle/core
% npm install ts-loader, typescript, webpack, webpack-cli --save-dev
```
必須ライブラリが揃ったらWebpack。コマンドはpackage.jsonに書いてある。
```shell
% npm run build
```
/dist/index.htmlでLive Serverを立ち上げればVivliostyleのビュワーが、/dist/publish.htmlを読み込んでPDFプレビューを表示してくれる。左右カーソルキーか、画面のクリックでページ送りする。
ちなみにfile:///では動かないので、何らかの方法でhttpサーバーを立ち上げてください。VS CodeならLive Serverが楽だと思います。

![スクリーンショット 2025-03-11 23.26.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2143865/8b4422d0-fd42-4cab-9fe5-b00460aa69a6.png)
Windows & ch32vでdebug print

## 概要
ch32vを使うときにdebug printをするまでの手順を備忘録として残します。

ch32vからprintをする方法は
- SWDIOピンからdebug print
- UARTのTXピンから print
- USBからprint

の3つがあるようです。今回はSWDIOピンからのdebug printをします。

この記事を読まなくてもここに書いてあります。
https://github.com/cnlohr/ch32fun/wiki/Installation#windows

## シリアルモニタの準備
minichlinkを使います[^footnote1]。PlatformIOを使っている場合はplatformio.iniの`upload_protocol=minichlink`とすればインストールされます。手動で入れてもいいと思います。

[^footnote1]: 
    `pio device monitor`でシリアルモニタを開いた場合はWCH-LinkEのRX, TXに入ってきたUART信号がUSB変換されたデータが出てくるので今回のdebug printをするのには使えません。

WindowsにWCH-LinkEを接続した状態でminichlinkを使うとポートが開けないとエラーが出ます。そこで、ch32funのinstallationにある通り、Zadigを使ってWinUSBのドライバをWCH-Link(Interface 0)が接続されているUSBポートにインストールします。

Zadigを起動してすぐはデバイス一覧が表示されていないと思うのでOptionsから"List All Devices"を選ぶと下の画像のように一覧が出てくるのでWCH-Link (Interface 0)を選んでから WinUSBをinstallします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1398068/e85ba82d-234a-43c7-b4d0-e48925bfc509.png)

## WCH-LinkEとch32vの接続
以下の通りに接続してください。

| WCH-LinkEのピン | ch32vのピン |
| --- | --- |
| SWDIO/TMS | SWDIO |
| SWCLK/TCK | SWCLK |
| GND | VSS |
| 3V3 | VDD |

## ch32vのDebug printのコード
ch32v003fun.hを使用します。

```main.c
#include "ch32v003fun.h"
#include <stdio.h>

int main(){
    SystemInit();
    SetupDebugPrintf();

	while(1)
	{
		printf("Hello World\n");
		Delay_Ms(100);
	}
}
```

```funconfig.h
#ifndef _FUNCONFIG_H
#define _FUNCONFIG_H

#define FUNCONF_USE_DEBUGPRINTF 1
#define FUNCONF_DEBUGPRINTF_TIMEOUT (1<<31) // Wait for a very very long time.

#endif
```
funconfig.hに関しては無くてもdebug printされましたが一応メモとして残します。

## シリアルモニタを開く
```bash
minichlink -T
```
このコマンドで開けます。おそらくminichlinkへのパスが通っていないと思うのでパスを通すなり、minichlinkがあるディレクトリ上でコマンドを実行するなり、フルパスを指定するなりすればOKです。
PlatformIOでminichlinkをinstallした場合は`C:\Users\[user name]\.platformio\packages\tool-minichlink\minichlink.exe`にあります。
AWS SAA備忘録記事①〜Auto Scaling〜

# はじめに
AWS Solution Architect Associate(SAA)試験を勉強して、様々なサービスで、Auto Scaling機能が提供されていることに気づきました。
Auto ScalingはAWSの大きな強みの一つですが、どのサービスが対応しているのか、そしてそれぞれどのように機能するのかを整理しておくことは重要だと思いました。
本記事では、AWSの各種リソースにおけるAuto Scaling機能について、覚えやすい分類とともに解説します。

# コンピューティング系
## EC2
EC2は最も基本的なAWSのコンピューティングリソースで、Auto Scalingの代表的な利用例。
EC2 Auto Scaling
設定した条件に基づいてEC2インスタンスの数を自動的に増減できる。
- ターゲット追跡スケーリング
特定のメトリクス（CPU使用率など）のターゲット値を維持
- ステップスケーリング
閾値に応じて段階的にインスタンス数を調整する
- シンプルスケーリング
基本的な閾値ベースのスケーリング
- スケジュールドスケーリング
特定の時間帯に応じてスケーリング（例：業務時間内はより多くのインスタンスを維持）

## ECS（コンテナ）
ECSはDockerコンテナを実行するためのサービスで、コンテナベースのアプリケーションに対してAuto Scalingを提供。
- サービスのAuto Scaling
ECSのタスク数を自動的に調整
- クラスターのAuto Scaling
ECSクラスターのEC2インスタンス数を調整（キャパシティープロバイダー）
- Fargate
サーバーレスコンテナ実行環境でも自動スケーリングが可能

## EKS（Kubernetes）
EKSはマネージドKubernetesサービスで、Kubernetesのネイティブ機能とAWSのAuto Scaling機能を組み合わせている。
- Horizontal Pod Autoscaler (HPA)
ポッド数の自動調整
- Cluster Autoscaler
ワーカーノード（EC2インスタンス）数の自動調整
- AWS Load Balancer Controller
Ingress/Serviceリソースに基づくロードバランサーの自動設定

# アプリケーション系
## AppStream 2.0（デスクトップストリーミング）
AppStream 2.0はアプリケーションとデスクトップのストリーミングサービス。
- フリート自動スケーリング
ユーザー需要に応じてストリーミングインスタンスの数を調整
- 使用状況ベースのスケーリング
実際の使用状況に基づいて容量を調整

## Amazon EMR（ビッグデータ処理）
EMRはHadoopエコシステムを利用した大規模データ処理サービス。
- インスタンスグループのAuto Scaling
作業負荷に応じてクラスター内のインスタンス数を調整
- マネージドスケーリング
Amazon EMRが自動的にクラスターリソースを最適化
- スポットインスタンス統合
コスト最適化のためにスポットインスタンスを活用したスケーリング

## Lambda（サーバーレス関数）
Lambdaはサーバーレスでコードを実行するサービスで、自動スケーリングができる。
- 同時実行数の自動調整
リクエスト数に応じて自動的に関数のインスタンスを増減
- プロビジョンド同時実行数
レイテンシーを最小限に抑えるため、事前に容量を確保（ただし自動スケーリングではない）
- コールドスタートの最小化
予測可能なワークロードで同時実行数を最適化

# データベース系
## DynamoDB（NoSQL）
DynamoDBはフルマネージドNoSQLデータベースサービス。
- オンデマンドキャパシティモード
アクセスパターンに応じて自動的にスケーリング
- Auto Scaling
プロビジョンドキャパシティモードでの自動的な読み取り/書き込み容量の調整
- グローバルテーブル
複数リージョンにまたがる自動レプリケーションとスケーリング

## RDS（リレーショナルDB）
RDSは様々なリレーショナルデータベースエンジンを提供するマネージドサービス。
- ストレージの自動スケーリング
データベースストレージの自動拡張
- 読み取りレプリカのAuto Scaling
読み取りレプリカの数を自動調整
- RDS Proxy
データベースコネクションプーリングによる効率的なスケーリング
 アプリケーションからのデータベース接続を最小限に抑えることができる。

## Aurora（RDSの発展系）
Auroraは高性能なリレーショナルデータベースで、通常のRDSよりも高度なスケーリング機能を持っている。
- Aurora Serverless
需要に応じて自動的にデータベースキャパシティを調整
サーバーを常時起動しないので柔軟性が高い
- Aurora Replica Auto Scaling
リードレプリカの数を自動調整
- Aurora容量範囲
最小・最大容量の設定範囲内で自動スケーリング

# まとめ
SAAの勉強を通じて、AWSの多様なAuto Scaling機能を学びました。
各カテゴリで提供される自動スケーリングは、クラウドの「必要な時に必要なだけ」という価値を実現しており、それを加味して、有効に使っていきたいと思いました。
物理サーバと仮想サーバのネットワーク構成について学んだこと

## 1. 物理サーバと仮想サーバの違い
・物理サーバは実際に存在するハードウェア。
・仮想サーバは仮想化技術を用いて、物理サーバのリソースを分割・抽象化したもの。
・1台の物理サーバ上で複数の仮想サーバを稼働させることが可能。
この方式を マルチテナント方式 と呼ぶこともある。

## 2. 仮想L2スイッチとは？
・物理サーバ上には 仮想L2スイッチ が存在し、各仮想サーバ（VM）はその仮想スイッチのポートに接続されるイメージ。
・物理サーバの物理NICを通じて、仮想スイッチと外部の物理L2スイッチを接続することができる。
・仮想スイッチを介することで、仮想サーバ間の通信や外部ネットワークとの通信を制御できる。

## 3. 物理L2スイッチと仮想L2スイッチの関係
・物理L2スイッチは実際に存在するスイッチで、物理サーバと接続される。
・仮想L2スイッチは物理サーバの内部にあるソフトウェア的なスイッチ。
・物理サーバ内の仮想サーバ同士の通信は、仮想スイッチで処理されるため、物理L2スイッチの通信制御テーブルには影響しない。
・物理サーバを経由して外部と通信する場合、物理L2スイッチが関与する。

## 4. 仮想ファイアウォールの活用
・物理サーバ内に 仮想ファイアウォール（vFW） を設置可能。
・仮想L2スイッチの手前に配置し、仮想サーバへの通信をフィルタリング。
これにより、複数の顧客ネットワークを1つの物理サーバ上で分離・管理可能。

## 5. クライアントPCから仮想サーバへのアクセスの流れ
1.クライアントPC → 物理ルータ → 物理L2スイッチ
2.物理L2スイッチ → 物理サーバ（仮想L2スイッチ）
3.仮想L2スイッチ → 仮想ファイアウォール（必要に応じて）
4.仮想ファイアウォール → 仮想サーバ

## 6. DNSの名前解決とプロキシサーバの役割
・社内のネットワークからWebページにアクセスする場合、プロキシサーバ を経由することが一般的。
DNSの名前解決は、
・クライアントPCが行う場合（プロキシの設定による）。
・プロキシサーバが名前解決を行い、キャッシュされた結果を返す場合。
・外部のDNSサーバに問い合わせる場合。
プロキシがDNSの名前解決を行うかどうかは、プロキシの設定による。

## 7. 物理サーバのMACアドレスと仮想サーバのMACアドレス
・物理サーバには 物理NIC に対する1つのMACアドレスが存在。
・仮想サーバは、仮想ネットワークインターフェース（vNIC）を持ち、それぞれ独自の MACアドレス を割り当てられる。
・仮想サーバの通信は 仮想スイッチを経由 し、外部と通信する際には物理NICを通る。
・物理L2スイッチは、物理サーバの物理NICのMACアドレスを学習するが、仮想サーバのMACアドレスも転送フレームの内容から学習可能。

まとめ
・物理サーバの中には、仮想サーバや仮想L2スイッチがあり、仮想ネットワークが構成される。
・物理L2スイッチと仮想L2スイッチの役割を理解することで、仮想環境の通信制御が明確になる。
・プロキシサーバの役割や、DNSの名前解決の仕組みも重要。
・物理サーバのMACアドレスと、仮想サーバのMACアドレスを区別することがポイント
VSCodeのアップデートエラー解消方法

# MacbookでのVSCodeアップデートエラー

MacbookでVSCodeのアップデートを行おうとした際、
アップデートエラーが発生したため、解消方法を残しておきます。

### 使用環境
Macbook 15.3.1 (24D70)
VSCode (アップデート前のバージョンは忘れてしまいました、、)

``` エラー内容
Cannot update while running on a read-only volume. The application is on a read-only volume. Please move the application and try again. If you're on macOS Sierra or later, you'll need to move the application out of the Downloads directory. This might mean the application was put on quarantine by macOS. See this link for more information.
```

### 解消方法
システム設定 > プライバシー＆セキュリティ > フルディスクアクセス
ここのVSCodeの設定をオンにすると、アップデートエラーは解消しました。
ロードバランサーって何？

## 1. ロードバランサーとは？

ウェブサイトを利用していると、スムーズに動くサイトもあれば、遅く感じるサイトもありますよね？
その違いの一因として ロードバランサー（Load Balancer） の存在があります！

簡単に言えば、ロードバランサーはサーバーへの負荷を分散し、均等に処理を振り分けるシステム です。もし1台のサーバーがすべてのリクエストを処理していると、アクセスが集中したときに応答が遅くなったり、最悪の場合、サーバーがダウンしてしまうこともあります。

コストコのガソリンスタンドを思い浮かべてみましょう。
![Costco-Gas-station.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3529304/c88eea7c-bda3-4235-a7c1-a95c578f910c.png)

複数の給油機があるのに、もしすべての車が1列に並んでいたら、待ち時間が長くなりますよね？ でも、スタッフがそれぞれの車を空いている給油機に案内すれば、スムーズに給油ができます。ロードバランサーはこのスタッフのように、リクエストを適切なサーバーに振り分け、サーバーの負担を減らし、ユーザーへ素早い応答を提供します。


## 2. なぜロードバランサーが必要なのか？

ロードバランサーが重要な理由はいくつかありますが、特に以下の点が挙げられます：
- サービスのパフォーマンス向上 – リクエストを分散し、サーバーの応答速度を向上させます。
- サーバーの負荷軽減 – 特定のサーバーに過剰な負担がかからないように調整します。
- サーバー障害への対応 – 万が一、1台のサーバーが故障しても、他のサーバーが代わりにリクエストを処理します。
- スケーラビリティの向上 – トラフィックが増加しても、新しいサーバーを追加すれば自動的に振り分けられます。
ロードバランサーがあることで、私たちは快適にウェブサービスを利用できます！

## 3. ロードバランサーの動作原理

ロードバランサーの動作は、コストコのガソリンスタンドと似ています。

1. ユーザーがウェブサイトにアクセスすると、そのリクエストはロードバランサーに送られます。
2. ロードバランサーは、現在のサーバーの状態を確認し、最適なサーバーを選択します。
3. 選ばれたサーバーがリクエストを処理し、ユーザーに応答を返します。
4. ロードバランサーは常にサーバーの状態を監視し、必要に応じて別のサーバーにリクエストを振り分けます。

もし特定の給油機が故障していたら、スタッフが別の給油機に車を誘導するように、ロードバランサーも最適なサーバーを選んでくれます。

## 4. ロードバランサーの種類

ロードバランサーには、さまざまなリクエストの振り分け方法があります。代表的なものを紹介します。

- ラウンドロビン方式（Round Robin）– サーバーに順番にリクエストを振り分けます。
- 最小接続方式（Least Connections）– 接続数の少ないサーバーを選びます。
- 応答速度優先（Fastest Response Time）– 応答速度が速いサーバーを選びます。
- フェイルオーバー（Failover）– サーバーがダウンした場合は自動的に別のサーバーに振り分けます。
- IPハッシュ方式（IP Hashing）– 特定のユーザーが常に同じサーバーを利用できるように設定します。

ロードバランサーは、状況に応じて最適な方法を選択し、リクエストを効率的に処理します。

## 5. ロードバランサーのメリット

ロードバランサーを導入すると、以下のようなメリットがあります。

- サービスの高速化 – リクエストを分散し、レスポンス速度を向上させます。
- 高可用性（High Availability） – 1台のサーバーがダウンしても、サービスが停止しません。
- リソースの効率的な利用 – 全てのサーバーがバランスよく稼働するため、負荷の偏りを防ぎます。
- スケーラビリティ – トラフィックが増えても、新しいサーバーを追加すれば対応可能です。
- セキュリティ強化 – SSL/TLSの暗号化処理や、不正なトラフィックのブロック機能も備えられます。

このように、ロードバランサーは単なるリクエストの分配装置ではなく、システムの安定性と拡張性を支える重要な要素です！

## まとめ

ロードバランサーは単なる「リクエストの振り分け機械」ではなく、ウェブサービスの基盤を支える重要なインフラ であることがわかりましたね！

これからITサービスを開発するとき、ロードバランサーを活用すれば、より速くて安定したサービスを提供できるはずです！
Reactの各ページのルーティング方法

前の記事でトップページの変更方法を書いたので
こちらでは各ページへの遷移方法を書きます。

[トップページ変更はこちら](https://qiita.com/quesman011/items/78ba9daff1e7d641c1ef)

# プロジェクトの作成
まず作業の土台となるプロジェクトを作成します。

```bash
npx create-react-app プロジェクト名 
cd my-app
```
# 必要機能のインストール
下記の機能をインストールします

```bash
npm install react-router-dom
```

これで諸準備が整いました。

# ルーティングの設定
[トップページ変更](https://qiita.com/quesman011/items/78ba9daff1e7d641c1ef)に追記する形で書いています。⓵⓶⓷⓸を編集して対象となるAddTask.jsを作成することで完成です。
仕様: 
リンク先:AddTask.js
ファイルの位置:App.jsと同じ
リンク名:add

基本的にApp.jsはトップページまたは各ルーティングの設定に使用されます。

```jsx: App.js
import React from 'react';
import { BrowserRouter as Router, Route, Routes, Link } from 'react-router-dom';
// ⓵ルーティング機能を導入します
import HomePage from './HomePage';
import AddTask from './AddTask';
// ⓶対象となるページのコンポーネントを作成します

function App() {
    return (
        <Router>
            <Routes>
                <Route path="/" element={<HomePage />} />
                <Route path="/add" element={<AddTask />} />
                {/* ⓷ルートを定義 */}
            </Routes>
        </Router>
    );
}

export default App;
```

HomePage.jsにaddへのリンクを作成してルーティングは終了です。

```jsx: Homepage.js
import React from 'react';

function HomePage() {
    return (
        <div>
            <Link to="/add">Add Task</Link>
            {/* ⓸リンクを追加 toなのがポイントです */}
        </div>
    );
}

export default HomePage;
```

後はリンクの対象となるAddTask.jsを作成して完了です。
```jsx:AddTask.js
import React from 'react';

function AddTask() {
    return (
        <div>
            <h1>タスクを追加</h1>
            <p>ここで新しいタスクを追加します。</p>
        </div>
    );
}

export default AddTask;
```
AZ-305 合格体験記

## １．はじめに
2024年2月にAZ-104を取得しましたが、少し期間が空いてしまいました。
しかし、AZ-305に合格することができたので、この記事では、その勉強方法をまとめたいと思います。

2025/3/4
![{B5AAAA7B-18EB-4EA1-B9FC-C08CC772DCB4}.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3628466/a634621c-4194-4f03-bcc0-78078fdd495c.png)

これからAZ-305の取得を目指す方の参考になれば幸いです。

## ３．勉強方法
では、早速勉強方法を紹介します。
主にUdemyとExamTopicsを利用し、不明点はMicrosoft Learnで確認しました。

## ３-１．Udemy
[最短で合格！Azure Solutions Architect Expert AZ-305 試験対策問題集](https://www.udemy.com/course/microsoft-azure-az305-exam/?couponCode=ST10MT30325G1)

https://www.udemy.com/course/microsoft-azure-az305-exam/?couponCode=ST10MT30325G1

おすすめ度：★★★★★

主に基礎知識や問題の傾向を掴むのによかったです。 
全ての章を90%以上取れるまで解きました。

## ３-３. サイト
[Exam Topics](https://www.examtopics.com/exams/microsoft/az-305/)

https://www.examtopics.com/exams/microsoft/az-305/

おすすめ度：★★★★★
正直これだけやっていれば合格は間違いないと思います。
同じような問題が多数出題されました。 
しかし、解答が間違っている問題が多くあるので、公式ドキュメントの確認や回答者のディスカッションを確認する必要があります。

## ４．終わりに
上記の勉強方法でAZ-305に合格することができました。
ありがとうございました！
フロントエンド入門：HTMLの<img>タグについて基本部分の理解とサンプルコードを書いてみた

## はじめに

フロントエンド開発では、画像を扱う機会が多くあります。専門領域ではありませんが、受講しているハッカソンで1回だけフロントエンドとして参加した経験があります。

:::note info
***画像の表示は、多くのWebアプリケーションで重要な役割を果たします。***
:::

本記事では、HTMLの`<img>`タグを使った基本的な画像の読み込み方法について解説します。

## 書こうと思ったきっかけ

最近、フロントエンド開発にも少しだけ力を入れていこうと考えています。

:::note warn
**その中でも、特に画像の表示に関する疑問が多かったため、基本的な内容を整理して解説記事を書くことにしました。**
:::

初学者の方でも理解しやすいように、シンプルなコード例とともに説明していきます。

## 画像を読み込む基本の方法

### HTMLで画像を表示する

画像を表示する最も基本的な方法は、HTMLの`<img>`タグを使うことです。`src`属性に画像のパスを指定すると、画像が表示されます。

```html
<img src="image.jpg" alt="説明文">
```

- `src`: 表示する画像のURLやパスを指定
- `alt`: 画像が表示できない場合の代替テキスト（アクセシビリティ向上のため推奨）

### フルHTMLコード例

以下は、実際に画像を表示するシンプルなHTMLコードの例です。

```html
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>画像の表示</title>
    <style>
        .container {
            text-align: center;
            margin-top: 50px;
        }
        img {
            width: 300px;
            height: auto;
            border: 2px solid #000;
        }
    </style>
</head>
<body>
    <div class="container">
        <h1>画像の表示例</h1>
        <img src="image.jpg" alt="サンプル画像">
    </div>
</body>
</html>
```

このコードでは、`<img>`タグを使用して`image.jpg`を表示し、CSSでサイズ調整や枠線を追加しています。

**実際の画面**

![Screenshot 2025-03-11 at 23.12.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/95ae5ec4-1838-4969-ab5b-95b3072c5b5a.png)

## まとめ

本記事では、`<img>`タグを使用した基本的な画像の読み込み方法について解説しました。

- HTMLの`<img>`タグを使えば、簡単に画像を表示できる。
- `alt`属性を適切に設定すると、アクセシビリティが向上する。
- 実際に画像を表示するフルHTMLコードを用意し、具体的な使い方を示した。

画像を扱う場面は多くあるため、ぜひ今回の内容を活用してみてください！
S3 に PBF ファイルを置いて DuckDB で直接クエリできる

## はじめに
業務上OpenStreetMapのPBFファイル形式を受け取って扱うことが多いのですが、今回PBFファイルをAWS S3にデータを置き、**DuckDB の `spatial` 拡張を活用して、直接クエリする方法** を解説します。

尚、PBFについてはこちらの[記事](https://qiita.com/AshMap/items/455d2a19e09db9e46ec5)も参照ください。

PostGIS や osm2pgsql をセットアップせずに、**SQL だけで OSM データを処理できる** ため、データ分析や可視化に便利です！🚀

## 1. AWS S3 に PBF ファイルをアップロード

### 1-1. S3 バケットを作成

AWS CLI または AWS マネジメントコンソールで **S3 バケット** を作成します。

AWS CLI を使う場合:
```sh
aws s3 mb s3://my-osm-data-bucket --region us-east-1
```

### 1-2. PBF ファイルをアップロード

```sh
aws s3 cp ./map.osm.pbf s3://my-osm-data-bucket/
```

## 2. DuckDB をセットアップ

DuckDB をインストールして、必要な拡張機能をロードします。

### 2-1. DuckDB のインストール

こちらよりインストールください。

https://duckdb.org/docs/installation/?version=stable&environment=cli&platform=macos&download_method=direct

## 3. DuckDB で PBF をクエリする

### 3-1. 拡張機能をロード

結論から言うと、DuckDB の `spatial` 拡張を使うことで、PBF を直接 SQL クエリできます。

```sql
INSTALL httpfs;
INSTALL spatial;
LOAD httpfs;
LOAD spatial;
```

### 3-2. AWS S3 の認証情報を設定

```sql
SET s3_region='us-east-1';
SET s3_access_key_id='YOUR_ACCESS_KEY';
SET s3_secret_access_key='YOUR_SECRET_KEY';
```

💡 **AWS CLI の `aws configure` を設定しておけば、手動で `SET` しなくても自動認識できます**


## 4. PBF を SQL でクエリ（例）

### 4-1. S3 上の PBF ファイルをクエリ

```sql
SELECT * FROM 's3://my-osm-data-bucket/map.osm.pbf' LIMIT 10;
```

### 4-2. OSM の道路データ（`highway` タグあり）を取得

```sql
SELECT id, tags['highway'], tags['name']
FROM 's3://my-osm-data-bucket/map.osm.pbf'
WHERE tags['highway'] IS NOT NULL
LIMIT 10;
```

### 4-3. 建物データ（`building` タグあり）を取得

```sql
SELECT id, tags['building'], tags['name']
FROM 's3://my-osm-data-bucket/map.osm.pbf'
WHERE tags['building'] IS NOT NULL
LIMIT 10;
```

### 4-4. 特定の緯度経度範囲のデータを取得

```sql
SELECT id, kind, lat, lon, tags
FROM 's3://my-osm-data-bucket/map.osm.pbf'
WHERE lat BETWEEN 35.6 AND 35.7
AND lon BETWEEN 139.6 AND 139.7
LIMIT 10;
```


## 5. まとめ

✅ **DuckDB の `spatial` 拡張をロードすれば、PBF を直接 SQL でクエリ可能**  
✅ **AWS S3 にある PBF を `SELECT * FROM 's3://...'` で直接取得できる**  
✅ **PostGIS や osm2pgsql なしで、簡単に OSM データ分析が可能**  


## 参考情報
- [DuckDB 公式サイト](https://duckdb.org/)
- [AWS CLI のセットアップ](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)

データの規模が大きい場合や、利用環境などによってどれくらいのパフォーマンスが出せるかはこれから試してみたいと思います。

この記事が位置情報データ活用の助けになれば幸いです！
エンジニアに必要なコミュニケーション力

# はじめに
本記事でお伝えするコミュニケーション力とは、「仕事をするうえで基本となる伝え方」とします。


私自身新卒からエンジニアとなってもう3年目ですが、後輩から質問が飛んでくることが多いため、自身のためにも一度まとめようという気持ちで記述しました。

意見やコメントがあればメモでもよいので、是非お願いします！

### 対象読者
主に、上司になっている人や顧客折衝を行う方に読んで頂きたいです。


- 複数年経験があり、後輩が困っているが、上手く仕事が回らない方
- 顧客折衝がうまくいっていない方
- コードレビューで指摘を行う方


# 背景
最近、エンジニアの性格が悪いという記事を見かけました。
 
https://anond.hatelabo.jp/20250305150606
 
正直かなり的を射た意見だと思いました。個人的にも性格悪い人が多いと思います。

特にX（Twitter）でも言葉の強い、意地悪なエンジニアをよく見かけます。


:::note warn
個人的にこの業界には「本当に性格が悪い人」と「伝え方が悪い人」どちらもいる

今回の記事は後者の方に伝えたいと思っています。
:::



### 実装レビュー編

- 「〇〇ってなんでこうしてるの？」/ 「××をこうしているのはなんで？」
    - 上司が質問したときに部下が何も答えられず、上司側だけが喋っているパターンを非常に見かけます


※この実装に至った考えを聞きたい上に、自分で答えにたどり着いて欲しいという考えは理解できます

:::note warn
### ダメなところ
- その実装がなぜダメなのか、どう改善したいのかが伝わらない
- 部下からは上司からの圧のようにしか見えない。そもそも、その実装方法しか知らないことが多い
:::

:::note info
### どうすればよいか
- 「この実装は〇〇という欠点があって、××という実装のほうが良いと思う」
→ この実装の悪い点を理解できるうえに、××という実装方法は部下が自身で調べたり、上司に聞くことができる
:::

上記の回答までできるとベストだと思います。


解答だけ教えてしまっているパターンもよく見かけますが、なぜ修正前の実装が適していないのかまでコメントできるようにすると、自身だけでなく、チームの成長に繋がります。

:::note warn
### 注意
専門用語を使いすぎるのも良くないと思っています。
例えばエンジニアであれば、DI(Dependency Injection: 依存性注入)は必須だと思いますが、4月入社の新人にDIのことを聞いても理解は薄いと思います。

特に難しめの専門用語は説明しつつ使うのが非常に良いと思います！
:::

（そもそも実装がわからないときは、部下から上司側にすぐに聞けるようになっているのがベスト）

### 顧客折衝編
- 「〇〇の仕様について××だったはずですよね？」 / 「進捗、まだですか？」＋α　（余計な一言）
    - 仕様確認や進捗確認の場面となります。私は余計な一言の場面までは見たことはないですが、「言い方を変えれば良いのに...!」で思うことがありました


※仕様が決定しないと業務が始まらないのは必然だと思いますが、言い方の問題で相手を焦らせたり、不快にさせない言い方があると思っています

:::note warn
### ダメなところ
- 言われたほうの気持ちを理解できていない。「はよ決めろ」って言ってるのと変わりない
:::

:::note info
### どうすればよいか
- 「（自社側）では〇〇の仕様って××という認識なんですけど、（顧客側）様も同じ認識ですか？」
- 「〇〇のタスクの進捗があれば、チャットツールやメールでの連絡をお願いします」
:::



# まとめ
一旦2つの例を紹介しましたが、よく見るコミュニケーションだったと思います。

エンジニアは思いついたことをすぐ言葉に発してしまう人が多いように思います。
もっと言い方を考えましょう、相手の立場になって考えましょう。


### おまけ
X（Twitter）で言葉の強いエンジニアってどうにかならないんですかね。。。
Reactでトップページを変更するには

reactでトップページを変更する方法について

# プロジェクトの作成
まず作業の土台となるプロジェクトを作成します。

```bash
npx create-react-app プロジェクト名 
cd my-app
```

# 必要機能のインストール

下記の機能をインストールします
```bash
npm install react-router-dom
```
これで諸準備が整いました。

# App.jsの編集
基本的にReactにおいて初期状態でApp.jsがトップページとなっています。

下記のようにApp.jsの⓵⓶⓷を編集することでHomePage.jsがトップページとなります。
```jsx: App.js
import React from 'react';
import { BrowserRouter as Router, Route, Routes } from 'react-router-dom';
// ⓵ルーティング機能の追加
import HomePage from './HomePage';
//　⓶トップページコンポーネントの追加
// pagesフォルダ内に設定した場合
// import HomePage from './pages/HomePage';となります

function App() {
    return (
        <Router>
            <Routes>
                <Route path="/" element={<HomePage />} />       
                {/* ⓷トップページへのルーティング */}
            </Routes>
        </Router>
    );
}

export default App;
```
下記のように設定すれば完成です！

```jsx: Homepage.js
import React from 'react';

function HomePage() {
    return (
        <div>
            <h1>トップページへようこそ！</h1>
        </div>
    );
}

export default HomePage;
```
【初心者向け】GPUドライバ

# はじめに
私自身が、業務でGPU環境を初めて構築することになり、GCPの公式ドキュメントを見ていたところ、初めて見る言葉を整理したくなり、この記事にまとめたいと思います。

https://cloud.google.com/compute/docs/gpus/install-drivers-gpu?hl=ja

GPUを利用するために必要な、GPUドライバについて、
- NVIDIAドライバとはなにか
- CUDAツールキットとはなにか
- CUDAランタイムとはなにか
- CPUには必要のないドライバーがGPUにはなぜ必要なのか

というあたりを、素人なりに調査してみます。

# NVIDIAドライバとはなにか
答えは...
「NVIDIA製のグラフィックカードを正常に動作させるために必要なソフトウェア」

https://jitera.com/ja/insights/28825

グラフィックカードとはGPUが装着されたボードのことを指すので、実質GPUを正常に動作させるためのソフトウェアと考えてよいでしょう。

また、
> このドライバによりハードウェアとソフトウェア間の通信を円滑にし、NVIDIA製グラフィックカードの性能を最大限に引き出します。

ハードウェア（GPU）とソフトウェア（OS）の橋渡しの役割がある、ということになります。


# CUDAとはなにか
答えは...
「NVIDIAが開発した並列コンピューティングプラットフォームおよびプログラミングモデル」

こちらのサイトから引用させてもらいました。言葉が難しいので、一つ一つ調べていきます。

https://offers.jp/media/programming/a_3740

### 並列コンピューティング
複数のコンピュータやプロセッサーでひとつのタスク処理を行う技術の総称。
なるほど、GPUは並列で計算を行うのはよく聞く話で、CUDAはGPUに並列処理させるためのプラットフォームになるんですね。

https://www.weblio.jp/content/%E4%B8%A6%E5%88%97%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0

### プログラミングモデル
プログラミングモデルというと、オブジェクト指向などがぱっと頭に浮かびますが、ここでは異なる意味のように思います。


>CUDAのプログラミングモデルは、並列処理を直感的に記述できるよう設計されています。主要な概念には以下のようなものがあります。
>カーネル：GPU上で実行される並列処理の単位
スレッド：個々の処理単位
ブロック：複数のスレッドをグループ化したもの
グリッド：複数のブロックをさらにグループ化したもの
これらの概念を使いこなすことで、複雑な並列処理も効率的に実装できます。

つまりは、実行の単位やメモリの扱いを検討し、プログラムにまとめたもの、というのがここでのプログラミングモデルの概念になるのでしょうか。

# CUDAツールキットとは
答えは...
「NVIDIA社が開発・提供しているGPU向けの開発環境」です。

https://www.scsk.jp/sp/nvidia/casestudy_column/column01.html

### CUDAツールキットに含まれるもの
- コンパイラ（nvcc）
C/C++やCUDA C/C++ソースコードをGPU用バイナリにコンパイルする。
- 各種ライブラリ（cuBLAS, cuFFT, cuDNNなど）
線形代数やFFT（高速フーリエ変換）など、GPUを活用するための便利な関数群。
- 開発用ツール（Nsightなど）
プロファイリング（性能解析）やデバッグを行うためのツール。
- サンプルコード・ドキュメント
開発の学習やサンプル実装の参考に役立つ。

つまり、CUDA向けプログラムを「開発（コンパイル・リンクなど）」する人にとって必要なものとなります。

# CUDAランタイムとは
答えは...
「GPUとのインターフェースを提供するライブラリ」です。

https://ai-market.jp/technology/cuda/

つまり、CUDAプログラムを「実行」する際に必要となるランタイムライブラリやAPI機能のことを指し、CUDAを利用するアプリケーションを動かすために必要となります。

# GPUにはなぜドライバーが必要なのか
CPUには必要のないドライバーが、なぜGPUには必要なのか。答えは...

「GPU（グラフィックス処理装置）はグラフィックスの描画や並列計算を行うための専用ハードウェア」であるからです。

CPU（中央処理装置）はパソコンなどのシステムの中核を担う「標準的な演算装置」であり、OS自体がそのCPUのアーキテクチャ（x86/AMD64、ARMなど）に合わせて作られているため、特別な追加ドライバが不要となっています。一方で、GPU（グラフィックス処理装置）はグラフィックスの描画や並列計算を行うための専用ハードウェアであり、ハードウェアごとに特殊な制御が必要なので、それを行うためのベンダー提供ドライバが求められる、ということになります。

# まとめ
- NVIDIAドライバとはなにか　→　GPUとOSの橋渡しになるもの
- CUDA ツールキットとはなにか　→ GPU向けプログラムを開発する時に必要なもの
- CUDA ランタイムとはなにか　→　CUDAを利用するアプリケーションを動かすために必要なもの
- GPUにはなぜドライバーが必要なのか　→　専用ハードウェアであるGPUを動かすために必要だから
システムエンジニアがやると良いかもしれないゲーム - ウミガメのスープ

# なんでゲームをするのか
勉強しろ、と言って勉強する人は少ないわけで。
どうせなら遊びながら、楽しみながら学習できるのが嬉しいですよね。

という訳でこれは若手の教育にいいかもしれない、と思ったゲームを紹介。
チームビルディングにも役立つ…かもしれない。アイスブレイク的な。

# ウミガメのスープとは

水平思考[^1]クイズとも言われているもの。

出題者と回答者に分かれてゲームします。

1. 出題者は奇妙な状況、矛盾しているような状況を提示します
1. 回答者はその状況の真相を探るために「はい」「いいえ」で答えられる質問をします
1. 出題者はそれらの質問に正直に「はい」「いいえ」「関係ない」と答えます
1. 回答者たちは質問を重ねながら少しずつ真相に近づいてきます

[^1]:水平思考：既存の枠にとらわれず、自由な発想で考える方法﻿


## 例題

問題：
```
天才少女のアイちゃん(5)が「学校にいきたい」と訴えたが、周囲はそれに強く反対した。
なぜか？
```
Q. アイちゃんの健康状態が原因ですか
A. いいえ

Q. アイちゃんの行きたがっている学校が原因ですか
A. いいえ

Q. アイちゃんは人間ですか
A. いいえ。いい質問です！

Q. アイちゃんはサルですか
A. はい！

解答：
```
天才ゴリラのアイちゃん(5)は「学校に行きたい」とメッセージを書いたが、危険なので周囲は反対した
```

そもそも人間じゃない、など常識や前提を疑う必要があるのがこのゲームの醍醐味。

# ウミガメのスープで何が得られるの

ただの屁理屈をこねたゲームじゃないの、と思われるかもしれませんがこれも学習の一環と私は考えています

1. 質問力
1. 前提条件を疑う力
1. どんな質問でも受け入れられるという心理的安全性

## 1. 質問力

職種関係なく社会人として必須スキル、それが質問力。
期待する答えを少ない手数で引き出すというのは、訓練が必要かなと。

このゲームをやると「はい」「いいえ」で答えられる質問を考えるのも難しいし、
答えに向けて状況を特定していく作業も初めは慣れが必要です。

## 2. 前提条件を疑う力

「こうあるべき」という考えに固執してしまうと、実はもっとラクな道があったのに気付かず進んでしまうことも。
本当に必要な機能なのか、別の方法で代替できるのではないか、などを時には考える必要があります。
ゲームを通じて、いかに自分の頭が固いか実感してみるのもいいかなと。

## 3. 心理的安全性

このゲームの良い所は「どんなに下らない質問でも否定されない」ことです。
実際の現場で「ユーザは人間ですか」と聞いたら呆れられますが、このゲームでは「いい質問」ですらあります。
チーム内でプレイすると、チームの状況が分かります。

# まとめ
いかがでしたか。
会社の同僚やチームでプレイすると、色んな考えや性格が出るので面白いかと思います。
だいたい10分か15分ほどで終わるので、朝ミの後とかにちょっと試しにやってみるのもいいでしょう。

[Amazonで購入](https://www.amazon.co.jp/%E5%B9%BB%E5%86%AC%E8%88%8E-Gentosha-%E6%B0%B4%E5%B9%B3%E6%80%9D%E8%80%83%E3%82%AF%E3%82%A4%E3%82%BA%E3%82%B2%E3%83%BC%E3%83%A0-%E3%82%A6%E3%83%9F%E3%82%AC%E3%83%A1%E3%81%AE%E3%82%B9%E3%83%BC%E3%83%97/dp/B07P5KK46F/ref=sr_1_2?dib=eyJ2IjoiMSJ9.7bzOj5ajV5tgjxUYu6dPSCBMeFgqh3fJCBHb_W7NT8YxzpVekeFRlmHgc7eqpfknddyCdTNpEJFReYocvR9KPzgSBy44hSYOPcqCrG2RkDeo0BEAqo-hFyNsYRQNe0TFg7mNkbpjrUE4kxtN_629kqSEoEQPwvzJNYmfd7TglFOvKMo8wMM_jAJV20LyUgQi0RyhfDryluvwMOiNoPgc0ShbZUT4UmkVuYjP5qoO6h_4G4f_JVsTlg2YRFNES3-0FAdBcGfOoruCC4xwev2Kl9Qa3srwzqfGVcbdxudSNazrgH296cqo5IGrCkxMuOyGk23vLBWRuxMJlwEx-JMcuxrQaGrhz8sW6Cxl3zqOhwhG-MgdcGin7rsZzxNv86hiuBv-XXe91GlRHgbBe3X6BDUypVvpiB77rJbwgKPN2UTpF_kca1nNZcXleSRhzN3u.LYd0c6iwXoRFWHWB70DTZCUkphwiPVodfWiDeJT77GE&dib_tag=se&keywords=%E3%82%A6%E3%83%9F%E3%82%AC%E3%83%A1%E3%81%AE%E3%82%B9%E3%83%BC%E3%83%97&qid=1741700220&sr=8-2)できますので、興味ある方はぜひぜひ。
Apacheサーバの挙動に気をつけろ

【結論】
Apacheはデフォルトでは、index.phpまたはindex.htmlを探す
ルートディレクトリにindex.phpだけを置いた状態で、
そのindex.phpをAPIとして、GETやPOSTで返却する値を操作したい時、
併せてルーティングを設定する必要がある

【実例】
Dockerで
```
FROM php:8.2-apache
```
でPHP＋Apacheのローカル環境を構築し、
hogeprojectディレクトリ内に
　index.php
　todos.json
のようにファイルを配置した状態で、
index.php内で

```
# JSONファイルの中身を表示する
if ($_SERVER['REQUEST_METHOD'] === 'GET' && $path === '/todos') {
    $todos = json_decode(file_get_contents(__DIR__ . '/todos.json'), true);
    echo json_encode($todos);
}
```

```
else if ($_SERVER['REQUEST_METHOD'] === 'POST' && $path === '/todos') {
 # 〜POSTされた値を受けてそれをtodos.jsonに書き込む処理〜
 }
```
というように、
hogeproject/todos　というURLに対してGETとPOSTで異なる結果を得たい時、


hogeproject
- index.php
- todos.json
という構造で、ブラウザでhogeproject/todosにアクセスしても、
404NotFoundエラーになる。

これは、Apacheによる「project/todosディレクトリ内のindex.phpないしindex.htmlを探したが見つからなかった」というエラーである。
つまり、Apacheはデフォルトではディレクトリ内のindex.phpないしindex.htmlを探そうとする。

その挙動を制御するためには、ルーティング設定が必要になる。
やり方は色々あると思うが、シンプルに.htaccessファイルを配置する方法を以下に記述する。

hogeproject
- index.php
- todos.json
- .htaccess # 追加
- Dockerfile # 修正

 ```
 # .htaccess
 # pathの内容問わずすべてのアクセスがルートディレクトリのindex.phpに向かうようにする
 RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]
```

```
# Dockerfile
# mod_rewriteを有効化
RUN a2enmod rewrite

# Apacheの設定を調整してAllowOverrideをAllに設定
RUN sed -i 's/AllowOverride None/AllowOverride All/g' /etc/apache2/apache2.conf
```

これによって、hogeproject/todosというpathへのアクセスが、
hogeproject直下のindex.phpに向くようになり、
```
if ($_SERVER['REQUEST_METHOD'] === 'GET' && $path === '/todos') {
```
などの判定処理に入るようになる。


補足）
Dockerfileの完全な内容
```
FROM php:8.2-apache

# 必要なPHP拡張機能をインストール
RUN docker-php-ext-install pdo pdo_mysql

# mod_rewriteを有効化
RUN a2enmod rewrite

# Apacheの設定を調整してAllowOverrideをAllに設定
RUN sed -i 's/AllowOverride None/AllowOverride All/g' /etc/apache2/apache2.conf

# ワーキングディレクトリ設定
WORKDIR /var/www/html

# パーミッションを設定
RUN chown -R www-data:www-data /var/www/html && \
    chmod -R 755 /var/www/html
```
F#でHaskellのgroupByを作る

# はじめに

https://qiita.com/Miyakovsky/items/3e2afb8fba7560277fad

以前書いた記事の続きです。
次は、HaskellのData.Listライブラリには関数"groupBy"を作ります。この関数は、リスト内の隣接する値同士を条件をもとにリストのグループを作成するものです。

# コード
```fsharp

// 条件をもとにリスト内にリストのグループを作成する
let groupBy (predicate) (list: seq<'a>) =
    let rec auxAccumulate acc = function 
        | [] -> (acc, [])
        | x :: xs when predicate (List.last acc) x -> auxAccumulate (acc @ [x]) xs
        | xs -> (acc, xs)
    let rec auxProcess = function 
        | [] -> []
        | x::xs ->
            let (head,tail) = auxAccumulate [x] xs
            head :: auxProcess tail
    auxProcess (Seq.toList list)

```

# 実行結果
```fsharp
groupBy (<=) "abcabcaaa" |> printfn "%A"
//実行結果: [['a'; 'b'; 'c']; ['a'; 'b'; 'c']; ['a'; 'a'; 'a']]
groupBy (<=) [1;2;3;1;2;0;4;5;2] |> printfn "%A"
//実行結果: [[1; 2; 3]; [1; 2]; [0; 4; 5]; [2]]
groupBy (<) [1;2;2;3;3;3;1] |> printfn "%A"
//実行結果: [[1; 2]; [2; 3]; [3]; [3]; [1]]
groupBy (>) [|1;2;3;1;2;3|] |> printfn "%A"
//実行結果: [[1]; [2]; [3; 1]; [2]; [3]]
```
DTEDデータを用い、地球上での見通しを判定する

# DTEDデータを用い、地球上での見通しを判定する

具体的なデータを用いて目的を果たすプログラムを作成する例として、地上の特定の地点(点A)から、航空機等の空中の任意の地点(点B)存在するオブジェクトを見通せるのかプログラムで判定する際の考え方を提示します。
なお、地上の地形については、国土地理院やNASAなどから広く公開しているDTEDデータを使うことを想定します。

DTEDデータ以外でも基本はフォーマットが違うだけなので、考え方としては同じです。
また、今なら各種有益なライブラリを使うこともできますが、ここでは考え方を理解するために１から考えます。

レーダーの場合、レーダー波の波長によっては空気密度の違いなどにより湾曲するため見通し線が曲線になりますが、考え方自体は同じです。
また、目的に応じ判定の仕方が変わる場合もありますが、ここでは基本だけ述べます。

# 使用する座標系と変換

地上や空中の地点については一般的に緯度経度や海抜高度が使われると思いますが、地球の丸みが影響を与えるほど２点間が遠い場合は、見通し線(LOS:Line of Sight)を決定するためにはECEF座標系を使うのが簡単です。
DTEDデータなどは緯度経度で提供されていますので、緯度経度とECEF座標の相互変換が必須です。
この相互変換には、測地系やワールドモデルなどが必要ですが、ここでは説明を省略します。

# 判定の考え方

基本的には、点Aと点B間の直線(見通し線)上の各ポイントでDTEDデータの標高を取得し、その標高が見通し線の高さを超えていれば見通しが遮蔽された(見通せない)と判定できます。(下図の赤点線が見通し線のイメージ)
![1.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/111541/4dce0942-66d0-4a3e-aae2-91bf8bbe3d6c.jpeg)


また、見通し線が地表を下回る場合も、地平線に妨げられて見通せない状態となります。
この判定で問題となるのは、見通し線がECEF座標系の線分(３次元ベクトル)であるのに対して、DTEDデータが緯度経度及び地表からの海抜高度となっており、単純に比較できない点です。

様々な判定方が考えられますが、DTEDデータのメッシュ単位より細かく判定しても意味がないため、判定はDTEDデータのメッシュ単位で行われるのが一般的でしょう。(下図は地表のDTEDメッシュイメージ。見通し線が通る灰色部分の標高を判定する)
![2.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/111541/5d693602-69c6-44ea-bebb-cda55a8fd152.jpeg)

またECEF座標を基準として判定するとDTEDデータのメッシュ単位で大量の計算が発生してしまうため、見通し線を近似的に緯度経度及び海抜高度の座標系に変換してからDTEDメッシュ単位で標高と判定するループを回す方が単純になります。(下図の赤点線が変換した見通し線のイメージ。地表が平面となるよう変換するため見通し線は下に膨らむ曲線となる)
![3.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/111541/9ef9a332-f2f5-4a75-8050-c0ddf196ac8e.jpeg)


# まとめ

目的に合わせて便利なものを使う事も必要ですが、実装の難易度や計算量に応じて、適切な代案を採用する方が良い場合もあります。
API Gatewayの実行ログ・アクセスログについて

## はじめに
API Gatewayの以下ログ種類について、ユースケースや設定についてメモレベルでまとめました。

* <b>実行ログ</b>
* <b>アクセスログ</b>

## 目次
1. [実行ログ](#実行ログ)
2. [アクセスログ](#アクセスログ)
3. [参考文献🌟](#参考文献)

## 実行ログ
### ログ詳細
* API Gateway のリクエスト実行ログ(Execution Logs)を記録するために使用される。
* 「APIが正しく動作していない」、「どこでエラーが発生しているかわからない」といった状況で役立つ。

```text
1. リクエストの詳細
　　クライアントが送信したリクエストデータ（HTTP メソッド、パス、クエリパラメータ、ヘッダーなど）

2. リクエスト処理の統合データ
　　API Gateway がバックエンド（例: Lambda 関数）と統合する際の詳細（リクエスト変換、バックエンドのレスポンス、変換結果など）

3. レスポンスの詳細
　　API Gateway がクライアントに返すレスポンスデータ（ステータスコード、ヘッダー、レスポンスボディなど）

4. パフォーマンスデータ
　　API Gateway による処理時間、バックエンドの応答時間などのパフォーマンス情報

5. エラーに関する詳細
　　API Gateway 内部エラー、統合エラー（バックエンドの失敗など）、認証エラー、アクセス拒否エラーなど
```
### ログレベル
| ログレベル | 記録内容 | 1リクエストあたりのログサイズ |
|:-----------|:------------|:------------|
| INFO | エラー情報に加え、APIリクエストやレスポンスの詳細等、デバッグや分析に役立つ情報を記録 | 約数百バイト ～ 数キロバイト |
| ERROR | エラーが発生した場合のみログを記録 | 約数十バイト ～ 数百バイト(エラー無しの場合は0) |

### ログサイズの削減
* `ログとトレースの設定`でログレベルを「エラーのみ」に設定することで削減可能
* ログレベル別の出力内容の違い：「出力内容」は上記のログ詳細(1〜5)を指します。
* 出力ログレベルをERRORのみとすると、エラー時のデバッグに必要な情報のみ記録される一方、 **以下の懸念** は挙げられる。
    * 正常処理時の詳細情報は記録されない。
    * ERRORのみに設定した環境で重要なAPIのリクエスト数や遅延をモニタリングしたい時にどう対処するか

![スクリーンショット 2025-03-11 10.59.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3427082/cd1bfaca-6540-4e7d-8c66-adf38e87830e.png)
| ログとトレースの設定 | 出力ログレベル | 出力内容
|:-----------|:------------|:------------|
| エラーと情報ログ | INFO・ERROR | 1〜5を全て出力
| エラーのみ | ERROR | 1・5のみ出力(エラーが発生したリクエストやエラー詳細のみ)

## アクセスログ
### ログ詳細
* API Gatewayを介して行われた各リクエストのメタデータを記録するもので、使用状況の監視やセキュリティ分析に役立つ。
* 「APIの利用状況をモニタリングしたい」、「セキュリティインシデントを検知したい」といった用途に適している。
```
1. クライアントのIPアドレス

2. リクエストのHTTPメソッドとエンドポイント

3. 応答ステータスコード

4. リクエストおよびレスポンスのサイズ

5. リクエストの処理時間

6. その他、定義したカスタムフィールド
　　・主にAPIの利用状況やトラフィックパターンを把握するために使用
　　・ログ形式（JSON、CLF、CSVなど）をカスタマイズ可能
　　・CloudWatch Logsに出力されるほか、ログ管理ツールへの転送も可能
```

### ログ設定
* [ログとトレースの編集 > カスタムのアクセスログ](https://qiita.com/nao-United92/items/c9456a37f30ec7e1940b#apigateway%E3%83%AD%E3%82%B0%E3%81%A8%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%E3%81%AE%E7%B7%A8%E9%9B%86)を有効化することでアクセスログの送信先(CloudWatchロググループ or Firehoseストリーム)の選択・保存が可能

![スクリーンショット 2025-03-11 10.56.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3427082/575fb309-d93d-473c-8317-058ea619b8b8.png)

## 参考文献🌟
* [API Gateway コンソールを使用して Firehose アクセスログ記録を設定する](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-logging-to-kinesis.html#set-up-kinesis-access-logging-using-console)