OmniAICreator/Qiita-1.07M huggingface dataset:
【勉強記録】Qiita毎日投稿してから6カ月がたちました

# はじめに

こんにちは。アメリカに住みながら独学でエンジニアを目指しているTairaです。
2024年10月6日よりQiitaの毎日投稿を始め、2025年4月6日で半年が経過しました。

Qiitaという技術ブログサービスの存在を知り、興味本位でブログ投稿を始めたのをきっかけに、「せっかくなら毎日投稿してみよう」と思い切って挑戦しました。まさか半年も続くとは自分でも驚いています。

この半年の間、アメリカの大学で語学を学んだり、1カ月間日本に一時帰国したり、風邪をひいて思うように時間が取れないことも何度もありました。そんな中でも、記事投稿だけは続けようと心に決め、一度も「やめよう」とは思わず継続してきました。

さて、本日は「半年間の毎日投稿によって得られたこと」をまとめたいと思います。なお、1～2日ほど投稿が途切れている日がありますが、時差の関係やGitHub Actionsのトラブルが原因であり、実際には記事を毎日書いていましたのでご容赦ください。

## 半年続けて得られたメリット

### 1. いつでもプログラミングのことを考えられる
これをメリットと捉えるかは人それぞれですが、何かを達成したりスキルを磨いたりする上で「時間をかける」ことは必要不可欠です。もちろん効率化は可能ですが、結局ある程度の時間は必要になります。

私は毎日技術に触れ、時折コメントを通してフィードバックをもらい、その度に再考するプロセスを続けました。単に「勉強しておしまい」ではなく、より能動的なスタイルになったことは大きな収穫です。

### 2. 自分が理解した内容を記録しておける
自分が「腑に落ちた」と思える知識を記事にしています。人間は忘れる生き物なので、過去に悩んだことを思い出したいとき、Qiitaに残した記事が役立ちます。当時自分が納得した表現で残しているので、読み返すだけでも理解度が上がりやすいです。

さらに、過去の記事を振り返ることで、新たな疑問が湧いてくることもあります。そうした疑問を解消していくうちに、より深い理解へとつながります。

### 3. Markdown記法に慣れる
QiitaではMarkdown記法を利用しています。GitHubのREADME.mdもMarkdownなので、書き方に慣れておくといろいろな場面で役立ちます。もちろん、エンジニアの方でもMarkdownを書く機会が少ないケースはあるかもしれませんが、損はありません。

###  4. CLI操作に慣れる
QiitaはWebブラウザからの操作が一般的ですが、私はあえてQiita CLIを使って投稿しています。CLI操作に慣れると、ソフトウェアエンジニアっぽく振る舞うだけでなく、記事の編集をコード化・自動化できるのが大きな魅力です。

たとえば、Qiitaがサーバーメンテナンス中でも記事を編集できますし、クラウドサービスの設定をTerraformでコード化・自動化するのと同じように、ブログの投稿プロセスも自動化できます。

また、ちょうどGitの勉強中だったこともあり、記事をGitHubで管理しました。Gitの基本操作やPRの流れを学ぶ良い訓練にもなり、CLIやGitにはそこまで苦労せずに取り組めています。

### 5. Qiita記事投稿の自動化に取り組めるようになった
これは、誰もが半年続ければ自然に身につくわけではありません。ただ、毎日投稿をしているからこそ「自動化したい」と思えたのは大きな成果だと思います。

たとえば、日本に1カ月間一時帰国した際は、毎日PCを開いてブログを書くのは厳しいと感じました。しかし「日本滞在を楽しみながらブログも続けたい」という思いから、GitHub Actionsでcronを組み、記事を自動投稿する仕組みを作りました。さらにX（旧Twitter）への自動ポストも実装しています。

GitHub Actionsの理解はまだ十分とは言えませんが、実践を通じてかなり経験値が上がりましたし、何より自分が実装したものが動く瞬間はとても嬉しいです。

- [GitHub Actions + Qiita CLI + Xで自動投稿した記事1](https://qiita.com/Taira0222/items/857177b14f469040d874)
- [GitHub Actions + Qiita CLI + Xで自動投稿した記事2](https://qiita.com/Taira0222/items/a805dcac364112d1fc6e)
- [GitHub Actions + Qiita CLI + Xで自動投稿した記事3](https://qiita.com/Taira0222/items/9766a095785a467367b0)

## まとめ
今回は、半年間の毎日投稿を続けて得られたメリットを振り返りました。

もちろん、情報の正確性にこだわる方もいるかと思います。「その情報のソースは？ 確定していない情報は投稿しないでほしい」といった声は確かにもっともです。

しかし、それに縛られて「ソースを探すのが大変だし、批判されるのが怖いから投稿をやめよう」と考えるのは、少しもったいないと感じます。今はAIを使えば初期調査も効率よくできますし（AIの情報を鵜呑みにしてはいけませんが）、記事を見て指摘してくださる方もいます。

もちろん、コメント任せにするのは良くありません。しかし、臆せず投稿することで得られるメリットは非常に大きいです。この投稿を読んで、もう一度記事投稿を検討してもらえたら嬉しいです。

私自身は、就職できるまでこの毎日投稿を続けるつもりなので、温かい目で見守っていただけると幸いです。
【L4への道】Terminal編

:::note info
変更履歴
+ 2025/05/07：[Ctrl] ＋ [U]、[Ctrl] ＋ [A]、[Ctrl] ＋ [K]のショートカットを追加。
:::

### 概要

[世界一流エンジニアの思考法　牛尾剛【著】
](https://qiita.com/irom999/items/05ed437232e90ff5bc7d)の記事のTerminal編として、投稿。
なお、OSは、MacOSに対応。

### L4としたい内容
#### [command] ＋ [L]

ターミナルのスクリーンをクリア。

#### [command] ＋ [C]

実行中のプロセスを中断。

#### cdコマンド
+ ユーザーのホームディレクトリ（例: /Users/username）に移動。
~~~
cd
~~~

+ 現在のディレクトリの一つ上のディレクトリに移動。
~~~
cd ..
~~~

+ 直前のディレクトリに戻る。
~~~
cd -
~~~

#### [Ctrl] ＋ [U]

コマンドラインのカーソルから左側の入力を削除

#### [Ctrl] ＋ [A]

コマンドラインのカーソルから左側の入力を削除

#### [Ctrl] ＋ [K]

コマンドラインのカーソルから右側の入力を削除
matplotlibでset_matplotlib_formatsがimportできない

# 経緯
大学の授業で「Pythonではじめる機械学習；scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎」を使うので環境構築してたらこんなエラーが出た
```zsh
ImportError: cannot import name 'set_matplotlib_formats' from 'IPython.display'
```
`set_matplotlib_formats`が見つからないとのこと
たしかに`IPython.display`にはなかった

# 環境
関係ありそうなのはこの辺り
```
ipython==9.0.2
matplotlib==3.10.1
matplotlib-inline==0.1.7
```

# 原因
どうやら`set_matplotlib_formats`の場所が移動したらしい
importの部分をこのように変更すると解決できる
```python
from matplotlib_inline.backend_inline import set_matplotlib_formats
```
【備忘録】圧縮、アーカイブ、解凍、展開の違い

## 圧縮とは
ファイルサイズを小さくすること
## アーカイブとは
複数ファイルを一つにまとめること
## 解凍とは
圧縮ファイルを圧縮前の状態に戻す
## 展開とは
アーカイブファイルをまとめる前に戻す
【ChatGPT＋4o Image Generation】でお化粧指南をお願いしました。


　どうも、カーブミラーです。

　今回は、4o Image Generationでお化粧指南をお願いしました。いや、私は男ですけどね😅

:::note info
本記事は、ChatGPT（Plus版）
で行なっております。
画像はあります。　あしからず。
:::
　ChatGPT等の動作状況を知らせる
　　OpenAIのステータスページ。
　　　[OpenAIステータス](https://status.openai.com/)
***
　こちらも載せますね。
　　[ChatGPTが使えない？ログインできない・反応しない原因やエラー時の対処法を解説](https://aismiley.co.jp/ai_news/chatgpt-error-resolution-explanation/)
***
　まずは、ニュースです。

　すでにお気付きの方も
　　いらっしゃるかと思いますが、
　　　画像生成AIのMidjourneyが
　　　　バージョンアップして
　　　　　V7になりました。

　同時期に
　　動画生成AIのRunwayも
　　　Runway Gen4に
　　　　バージョンアップ。

　私は使っていませんので、
　　使い方は、KEITOさんの
　　　こちらの動画をごらんください。
　　　　[Midjourney V7で生成した画像をRunway Gen-4で4K解像度のAI動画にする流れ](https://youtu.be/LoDzG8zuYDQ?si=ySXYlL49TbcY7Cv8) 
***
　では、【本題】です。

　今回は、
　　4o Image Generationで
　　　お化粧指南をお願いしました。

　はい、
　　私は男です。
　　　普段から、お化粧には
　　　　関係していません😅

　たまたま、ネットで
　　すっぴん女性を見まして、
　　　“化粧したら、化けるんだろうな”
　　　　と思いまして😅

　そこで
　　架空のすっぴん女性を生成して、
　　　化粧を施してもらうことに
　　　　しました。

　結果が、こちらです。
![side_by_side_result.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3457238/dd7876da-d538-47ee-aa0d-b9df8b9fb80b.jpeg)


　Promptがこちら。
```Text:お化粧Prompt
ファッション雑誌用に撮影します。化粧を施して
```

　Promptを
　　見ればおわかりのように
　　　これは、ファッション雑誌用の
　　　　お化粧の依頼です。

　人によっては、
　　オフィス用のお化粧を
　　　施して欲しいかもしれませんね。

　あるいは、
　　デートのときのお化粧とか。

　そこは、適切に
　　書き換えてください。

　そして、
　　お化粧の仕方も
　　　アドバイスしてもらいましょう。

```Text:メイク・アドバイスPrompt
どのようにメイクすれば、こうなりますか？
```

　以下の点を教えてくれます。
　・ベースメイク
　・アイメイク
　・チーク＆ハイライト
　・リップ

　最後に、
　　**お化粧は、通勤の電車の中で
　　　やらない方がいいですよ。
　　　　そこに好きな相手がいたら
　　　　　相手の自分に対するランクが
　　　　　　下がります。**

　まぁ、これを
　　読んでいる女性が
　　　いるとも思えませんけどね😅

　みなさんの
　　作品制作の糧に
　　　なれば、幸いです。

　今回は、ここまで。
***
　PS.
　　画像のダウンロードの際の
　　　ファイル形式が
　　　　WebPから、
　　　　　PNGに戻りました。
PG（プログラマー）とSE（システムエンジニア）の違いって？ 

## 自己紹介
株式会社PRUMという会社の代表をしています。岩本です。  
[PRUM公式サイト](https://prum.jp/)  

SES企業でエンジニアとして就業したのち、ヤフーでもエンジニアとして働いておりました。  
2019年、PRUMを創業し、組織を5期目の途中で70名の規模まで成長させました。  
エンジニアの成長について、誰よりも考え抜いてきた自信があります。  


## はじめに  

エンジニアという職業の中にも、さまざまなレベルや役割があります。  
特に「PG（プログラマー）」と「SE（システムエンジニア）」はよく比較されるポジションですが、具体的に何が違うのか？  

この記事では、PGとSEの違いをわかりやすく解説します！

![ChatGPT Image 2025年4月7日 11_42_10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668950/7c758012-da17-4a7b-9980-eddf3ccb6daf.png)

---

## **エンジニアのレベルの違い**  

エンジニアってひとくくりにされがちですが、その中でも **レベル** があります。  

ざっくり分けると、こんな感じ。  

- **PG（プログラマー）** → 設計書をもとにコードを書く人  
- **SE（システムエンジニア）** → 要件定義・設計・プログラミング・テストまで全部できる人  

「エンジニア＝プログラミングする人」ってイメージがあるかもしれませんが、実際には **開発ってプログラミングだけじゃない** んです。  


---

## **開発はプログラミングから始まるわけではない**  

システム開発では、「開発依頼を受けたらすぐにプログラミングをする」というわけではありません。  

まずは、徹底的に要件を詰めることから始まります。  
これを **「要件定義」** といいます。  

### **開発の流れ**  

1. **要件定義** → どんなシステムを作るのか、仕様を決める  
2. **設計** → 仕様をもとに、システムの構造を考える  
3. **プログラミング（実装）** → 実際にコードを書く  
4. **テスト** → 動作確認をしながらバグを修正  
5. **納品・運用** → お客様に提供し、必要に応じて改善  

こんな感じで、システム開発は **「考える工程」** → **「作る工程」** → **「確認する工程」** の順に進んでいきます。  

---

## **PG（プログラマー）の役割とは？**  

プログラマーは、システムエンジニアが作成した設計書をもとにプログラムを書いていく役割を担います。  
主に **「実装」** や **「テスト」** を担当することが多く、開発の中でも **「下流工程」** に位置します。  

### **プログラマーの主な仕事**  
- 設計書をもとにプログラムを書く  
- テストを行い、不具合を修正する  
- フレームワークやライブラリを活用し、効率的に開発する  

**プログラミングは、開発の中で最も手を動かす作業ですが、実は一番簡単な工程とも言われています。**  

なぜなら、設計がしっかりしていれば、あとはそれをコードに落とし込むだけだからです。  

---

## **SE（システムエンジニア）の役割とは？**  

一方で、システムエンジニアは **「要件定義」** や **「設計」** を含む **上流工程** を担当します。  

### **システムエンジニアの主な仕事**  
- クライアントと打ち合わせをして、どんなシステムを作るか決める（要件定義）  
- システムの設計を行い、どのように作るかを考える  
- 必要に応じてプログラミングやテストも担当する  

要件定義や設計は、**技術だけじゃなくて、クライアントとのコミュニケーション能力も必要** です。  
「お客さんが本当に求めているものは何か？」をしっかりヒアリングして、認識のズレをなくすのがSEの重要な役割と言えます。  


---

## **開発は「家づくり」と同じ**  

システム開発の流れは、家づくりとよく似ています。  

### **家づくりの流れ**  
1. どんな家にするか話し合う（要件定義）  
2. 設計図を作る（設計）  
3. 大工さんが家を建てる（実装）  
4. 建てた家の確認・手直しをする（テスト）  
5. 完成した家を引き渡す（納品・運用）  

家は目に見えるので、設計段階と実際の仕上がりが大きく違うことは少ないですよね？  
でも、**システム開発は目に見えない** ので、「思ってたのと違う…」ってことが起こりやすい。  

特に、**知識の少ないクライアントの場合、具体的なイメージを持っていないことが多い** ので、SEから **「こういう機能は必要ではないですか？」** と細かな提案をするなど、認識のズレをなくすことが大事なんです。  


---

## **要件定義ができるエンジニアは価値が高い**  

要件定義は **「何を作るか」** を決める最も重要な工程です。  
でも、いきなり要件定義をやろうと思っても、経験がないと難しいんですよね。

知識が浅い状態では、クライアントの要望を整理したり、的確な提案をすることはできません。  
システムエンジニアとして成長するには、まず **プログラマーとして実務経験を積むことが大切** です。  

---

## **まとめ**  

| 項目 | PG（プログラマー） | SE（システムエンジニア） |
|------|-----------------|-------------------|
| 主な役割 | プログラムを書く | 要件定義・設計・管理 |
| 工程 | 下流工程（実装・テスト） | 上流工程（要件定義・設計）＋下流工程もできる |
| 必要なスキル | コーディング能力 | 設計力・提案力・コミュニケーション能力 |
| 例 | 大工さん | 建築士 |

1. **PG（プログラマー）** → 設計書をもとにプログラムを書く（下流工程）  
2. **SE（システムエンジニア）** → 要件定義・設計・管理を行い、開発をリードする（上流工程）  

どちらも重要な役割ですが、システム開発は、 **プログラミングだけでなく、全体の流れを理解することが大切**。  
PGとしての経験をしっかり積んでSEへとステップアップすることで、より価値の高いエンジニアになれるでしょう！  

---


PRUMのエンジニアの95%以上は、未経験からの採用です！
エンジニアに興味のある方、転職を考えている方
ぜひ求人をチェックしてみてください！


▼ Wantedly求人
https://www.wantedly.com/projects/626662

▼ コーポレートサイト
https://prum.jp/

VISION 『日本で一番エンジニアが成長する会社を創る』

ご応募お待ちしておりますー！
【L4への道】Excel編

### 概要
[世界一流エンジニアの思考法　牛尾剛【著】](https://qiita.com/irom999/items/05ed437232e90ff5bc7d)のExcel編として、投稿。
なお、OSは、MacOSに対応。

### L4としたい内容
#### 列・行の「挿入」を、ショートカットで操作したい

:white_check_mark:　[command]
:white_check_mark:　[shift]

+ [command] + [shift] + [+]

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978560/10e9d586-c3d9-4e91-9dfe-7055737a2ef3.png" style="width: 100px; height: 75px;">

#### 列・行の「削除」を、ショートカットで操作したい

:white_check_mark:　[command]

+ [command] + [-] 

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978560/78b578ca-a65f-4849-9d7d-5edf020c95c5.png" style="width: 100px; height: 75px;">

#### 罫線の追加をショートカットで操作したい

:white_check_mark:　[command]
:white_check_mark:　[option]

+ [command] + [option] + [0]
+ [command] + [option] + [↑] 
+ [command] + [option] + [↓] 
+ [command] + [option] + [→] 
+ [command] + [option] + [←] 

#### セルの「結合」「解除」をショートカットで操作したい

MacOSだと、カスタムショートカットキーしか使えないようなので、一旦スキップ。
[Wordpress]WP_Queryでページネーションが404になる理由と正しい使い分け

WordPressでカスタム投稿やタクソノミーの一覧ページを作っていて、
**ページネーションで途中までうまく行っているのに4ページ目,5ページ目などそれ以降にアクセスしたら404になる:frowning2:**ということが起こったことはありませんか？？

その原因、実は `WP_Query` の使い方にあるかもしれません。
この記事では、WordPressにおける「メインクエリ」と「カスタムクエリ（WP_Query）」の違いと、
**それぞれの正しい使い分け**についてわかったことをまとめます!


---

## 今回起こった事象：「ページ4目以降に行ったら404になる」
1,2,3ページ目までは指定のポストタイプ記事が表示されているのに4ページ目になったら404になってしまうという現象が発生しました。
タクソノミーごとに表示していたので、別のグループも見てみると4ページ目になっても上手くいっているものと7ページ目になると404になってしまうなど必ずしも特定のページで発生するという感じではなさそうでした。


この事象が起こった時に作成していたコードを一部変更して以下に記載します。:point_down_tone2:
カスタム投稿 `type-projects` とタクソノミー `type-projects_tag` を使って、
一覧ページを作成しようとしています。

```php
$args = array(
  'post_type' => 'type-projects',
  'posts_per_page' => 4,
  'paged' => get_query_var('paged') ? get_query_var('paged') : 1,
  'tax_query' => array(
    array(
      'taxonomy' => 'type-projects_tag',
      'field'    => 'slug',
      'terms'    => 'news',
    ),
  ),
);
$query = new WP_Query($args);
```

これだけみると普通に動きそうです。
実際に3ページ目までは正常に動いていたし、、、、
でも `/type-projects_tag/news/page/4/` にアクセスすると……**404 Not！Found**:angel_tone2:

---

## なぜ404になるのか？

WordPressは、URLからそのページが「どの種類のページか（アーカイブ？投稿？検索？）」を判断し、
**自動で `$wp_query` にクエリを組み立ててくれています。**

つまり、`/type-projects_tag/news/page/4/` というURLにアクセスした時点で、
WordPressは内部的に：

```php
$wp_query = new WP_Query(array(
  'post_type' => 'type-projects',
  'taxonomy'  => 'type-projects_tag',
  'term'      => 'news',
  'paged'     => 4,
));
```

をもうやってくれてるんです。

そこへさらに `new WP_Query()` で自前のクエリを実行すると、
**WordPressは "URLに対応する中身がない" と判断して404にしてしまう** というわけです。

---

## アーカイブページではメインクエリを使うべき！

タクソノミー一覧、投稿タイプのアーカイブ、検索結果ページなどでは、
**WordPressが用意したメインクエリ（`have_posts()`, `$wp_query`）を使うのが正しいようです。**

```php
<?php if ( have_posts() ) : ?>
  <?php while ( have_posts() ) : the_post(); ?>
    <!-- 投稿表示 -->
  <?php endwhile; ?>
<?php endif; ?>
```

### 投稿数や条件をカスタマイズしたい場合は？

そんなときは `functions.php` に `pre_get_posts` を追記すればOK

```php
add_action('pre_get_posts', function($query) {
  if (!is_admin() && $query->is_main_query() && is_tax('type-projects_tag')) {
    $query->set('posts_per_page', 4);
    $query->set('post_status', 'publish');
  }
});
```

---

## じゃあ WP_Query は使っちゃダメなの？

WP_Queryには他の場所で活躍できる！！
WP_Query は「今のURLと関係ない別の投稿グループを出したい」ときに使います。

### たとえば：

- トップページに "おすすめ投稿" を表示
- サイドバーに "最近のお知らせ"
- 固定ページに特定カテゴリだけの投稿一覧を表示

これらはすべて `WP_Query` が使える場合です。

---

## まとめ：どっち使う？ 

| 目的 | 使うべきクエリ |
|------|-----------------|
| 今のURLに応じた投稿を表示（カテゴリ、タクソノミー、アーカイブなど） | メインクエリ（have_posts）|
| 今のURLと関係ない投稿を表示（ピックアップ、サイドバーなど） | WP_Query |

---

## 最後に：ハマりがちな404は「URLとクエリの整合性」が原因

WordPressは便利だけど、**自動でやってくれてることを無視すると途端に崩れる**仕組みです。
だからこそ、「どのページではメインクエリを使うべきか」を意識して使い分けることで、
**安定したテーマ作り・表示崩れのない実装**ができます！

このあたりでハマってる人がいたら、ぜひこの記事が参考になれば嬉しいです💡
LinkedHashMapの機能の個人的まとめ (removeEldestEntry、挿入順とアクセス順)

# はじめに

LinkedHashMapはいろいろな機能が用意されています。たまに利用するのですが、そのたびにググって時間を費やしているので、自分用に少しまとめておきます。


# removeEldestEntry

removeEldestEntryはputと同時に呼び出されるメソッドで、このメソッドの戻り値がtrueの場合、もっとも古いエントリを削除します。このメソッドは通常、オーバライドして利用します。たとえばエントリ数を最大100個に設定し、それを超えると古いエントリを削除する場合、以下のなコードになります。

```java
new LinkedHashMap<Integer, Integer>() {
    @Override
    protected boolean removeEldestEntry(java.util.Map.Entry<Integer, Integer> eldest) {
        return size() > 100;
    }
};
```

注意したいのはputとremoveEldestEntryの関係性です。このメソッドは以下の順番で呼び出されます。

1. putが呼び出され、新しいエントリが追加される。
2. 内部的にremoveEldestEntryが呼び出される
3. removeEldestEntryがtrueになった場合、もっとも古いエントリを削除する

# 挿入順とアクセス順

LinkedHashMapには挿入順とアクセス順というふたつのモードが用意されています。コンストラクタの第3引数accessOrderにtrueを設定するとアクセス順、falseを設定すると挿入順です。ちなみデフォルトコンストラクタでLinkedHashMapオブジェクトを生成すると、挿入順になります (accessOrder=false)

アクセス順の場合、以下のすべてでそのエントリを利用したと判定します。

1. getでそのエントリを取得する
2. putでそのエントリを更新する
3. putで新しいエントリを追加する

一方、挿入順の場合、「putで新しいエントリを追加」した場合のみ、エントリを利用した判定とします。

|モード|①getでそのエントリを取得する|②putでそのエントリを更新する|③putで新しいエントリを追加する|
|:-|:-|:-|:-|
|アクセス順|〇|〇|〇|
|挿入順|×|×|〇|

# 環境情報

```
C:\>javac -version
javac 17.0.5

C:\>java -version
java version "17.0.5" 2022-10-18 LTS
Java(TM) SE Runtime Environment (build 17.0.5+9-LTS-191)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.5+9-LTS-191, mixed mode, sharing)
```
[GitHub]gitignoreについて

# gitignoreの作成方法
今回はgitignoreの作成について纏めます。
gitignoreは追跡したくない、あるいはGitの管理下に置きたくないディレクトリやファイルを指定することができます。
このgitignoreに追跡したくないディレクトリやファイルを指定すると、add、commit、pushなどされず、Gitの管理対象から外すことができるのでリポジトリに反映されることはありません。

## 参考文献
https://blog.since2020.jp/uncategorized/git%E3%81%AE%E3%82%B9%E3%83%9E%E3%83%BC%E3%83%88%E3%81%AA%E4%BD%BF%E3%81%84%E6%96%B9-%E3%80%8C-gitignore%E3%80%8D%E3%81%A7%E4%B8%8D%E8%A6%81%E3%81%AA%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92/

https://thincle.com/git_swift/#rtoc-6

## gitignoreの作成手順
### 1️⃣`.gitignore`ファイルを作成していきます
対象のリポジトリのルートディレクトリにcdコマンドで移動します。
そのPJフォルダに対して`touch .gitignore`を実行

```bash
touch .gitignore
```

作成できたか確認を行います。
```bash
ls -la
```

Finderでは隠しファイル（ドットで始まるファイル）は表示されません。  
`Shift + Command + .（ドット）` を押すと表示・非表示の切り替えができます。

### 2️⃣管理対象外にしたいファイルを指定
では実際に管理対象に外したいファイルを指定していきます。
ここで指定することによりGitの差分監視対象から除外されます。
Gitの管理対象はチームで共有すべき「ソースコードやリソース」だけにします。

例えば`.DS_Store`や`Pods/`などがあります。

-  **自動生成ファイル：「アプリが勝手に作るファイル」**（`Pods/`、`build/`, `DerivedData/`など）
    -  例えば`Pods/`はCocoaPodsで追加したライブラリ群です
  このような自動生成ファイルは数千〜数万のファイルになることもあります。
これをGitで管理するとクローン・プッシュ・プルが重くなってしまいます。

-  **個人の環境ファイル：「自分のMacにしか関係ないファイル」**（`.DS_Store`など）
    -  例えば`.DS_Store`はMacのフォルダ設定ファイルです
これを毎回上げると無意味な変更がGitに表示されて、レビューがめんどくさくなります。

- **秘密情報・設定ファイル：「個人の鍵」や「金庫の暗証番号」**（`GoogleService-Info.plist`、）
    - 例えば`GoogleService-Info.plist`はFirebaseなどの設定ファイルになり、アプリの秘密鍵が入ってる可能性あります
APIキー、DBパスワード、Firebase情報などが公開リポジトリにアップロードされる可能性があります。

- **Xcodeプロジェクト特有のファイル：「人によって違う設定」**（`UserInterfaceState.xcuserstate`、`xcdebugger`、`xcschememanagement.plist`など）
    - 例えばカーソル位置やタブの開き具合など個人のエディタ状態を記録する`UserInterfaceState.xcuserstate`や、ブレークポイントなどXcodeデバッグ設定を含むファイルの`xcdebugger`があります
    - このような個人設定ファイルを共有すると、他の人のXcodeが変な挙動をすることもあります
「チームメンバーのビルドできない or 動作がおかしいと連絡してくる」など問題が発生します。

このように容量が重くなり作業が遅くなる、秘密情報が漏れセキュリティリスクが高まる、設定の不一致が発生し他の人がうまく動かせない、差分がゴチャゴチャになりレビューが大変になる。など様々な問題が発生するため含めないようにします。

今回は下記を含めないよう指定します。

- `Pods/`
- `.DS_Store`
- `*/ios/GoogleService-Info.plist`
- `UserInterfaceState.xcuserstate`
- `xcdebugger`
- `xcschememanagement.plist`

**注意**：最後に空白行を1行追加するのがおすすめです。これは、最終行が正しく読み込まれない場合を防ぐためです。

ここまで対応したら`command + S`で保存して閉じれば完成です。

## ⚠️対象外となるファイル
gitignoreに追加したファイルは、以降Gitの監視対象から除外されましたが、既に過去でコミットしてしまった物に関してはgitignoreに登録しているものは正常に除外されたわけではありません。
なので既にコミットしたことのあるファイルやディレクトリに関しては、下記のコマンドを実行してください。

```bash
 git rm -r --cached <ファイル名>
```
ファイル自体はローカルから削除されず、Gitの管理からだけ外されます。
これを行うことでキャッシュが削除され、以降は完全に監視対象から除外されるようになってます。

## まとめ
今回は`gitignore`ファイルについてまとめました。これも開発PJなどにより変更されると思いますが、何を入れる入れないの判断ができるように、ファイルの種類や影響を理解しておくことが大切だと感じました。
プロジェクトごとの特性に応じて柔軟に対応していくことも意識したいです。
javaを実行した際、Eclipseとcmdで文字コード関係の挙動が違う

# 発生した問題

文字コードがUTF-8の`utf8-in.txt`というファイルがあります。内容は以下の通りです。

```utf8-in.txt
あいうえお
かきくけこ
```

`Main.java`は`utf-in.txt`をすべて読み込み、内容を修正。それを`out.txt`に出力します。

```Main.java
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;

public class Main {
	public static void main(String[] args) throws IOException {
		byte[] bytes = Files.readAllBytes(Paths.get("utf8-in.txt"));
		String content = "@@@" + new String(bytes) + "@@@";
		Files.write(Paths.get("out.txt"), content.getBytes());
	}
}
```

これをEclipseから実行します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/105859/ee93f534-c699-0513-b193-b5ca85600a11.png)

すると想定通り、`out.txt`が作成されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/105859/cc2bca4e-b319-cf59-b835-c64a82727b44.png)

次にこのプロジェクトを`sample.jar`としてエクスポートし、cmd上から実行します。

```cmd
D:\temp>java -cp sample.jar Main
```

処理は正常に終了しますが、作成した`out.txt`は文字化けを起こしました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/105859/95143781-e0fa-4fc3-af13-9bc8334cf180.png)

# 原因

原因はEclipseとcmdでJVMのデフォルトの文字コードが違うことです。

まずEclipseではUTF-8が利用されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/105859/11b8005e-10c3-e9d0-4547-94a703f4a5d1.png)

対して、cmdではMS932が利用されます。

```cmd
D:\temp>jshell
|  JShellへようこそ -- バージョン17.0.8.1
|  概要については、次を入力してください: /help intro

jshell> System.getProperty("file.encoding");
$1 ==> "MS932"
```

# 対応方法

対応方法としてはデフォルトの文字コードを適切に設定することです。今回はcmdで実行する際の文字コードをUTF-8にしました。

```
java -Dfile.encoding=UTF-8 -cp sample.jar Main
```

# 環境情報

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/105859/10b75ff3-22c4-acac-8541-e284b21403b2.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/105859/ec21f46c-7f6d-3fda-4f73-e1e2a2be3713.png)

```
D:\temp>java -version
openjdk version "17.0.8.1" 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)
```
世界一流エンジニアの思考法　牛尾剛【著】


### 概要
牛尾剛による書籍「世界一流エンジニアの思考法」で、印象に残ったフレーズを引用して、今後に繋げる。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3978560/cd5d66aa-ec5d-48ef-bc88-92a3feb81c43.png" width="400" height="300">


### 書籍からの引用
P103、図9　仕事の難易度

:::note info
仕事の難易度
L4 自分では無理
L3 スパイクソリューションがあれば何とかなる
L2 ググれば解決できる
L1 何もググらず即実装できる
:::

### 今後の展望
まずは、Excel、ターミナルでL4としたい内容があるので、Qiitaに投稿して、習得の足がかりとする。
【応用情報】ポートスキャン

## ポートスキャン
　**ポートスキャン**は、攻撃者が攻撃に先立ち行う事前調査（フットプリンティング）の段階でよく使われる手法である。ここでは、試験対策として押さえておきたい主なポートスキャンをまとめておく。

## TCPスキャン
　対象サーバの特定のポートに対して、3ウェイハンドシェイクによるTCPコネクションの確立を試みる。コネクションが確立されれば、対象サーバにおいて当該サービスが稼働していること、そして接続可能であることが確認出来る。**TCPフルコネクトスキャン**ともいう。

## SYNスキャン
　3ウェイハンドシェイクの最初のSYNだけを送信する。SYN/ACKが返ってくればポートは開いていて、RST/ACKなら閉じていることが確認出来る。なお、SYNスキャンは、完全なTCP接続を行わないため**ハーフオープンスキャン**とも呼ばれる。

## FINスキャン
　TCP接続完了のFINを送信し、RSTが返ってくるか否かでポート開閉の判断やOSの種類の推測を行う。

## UDPスキャン
　UDPパケットを送る。ICMPの"Port Unreachable"メッセージが返ってくればポートは閉じていて、何も返ってこなければ開いている可能性があることが確認出来る。

## おわりに
ここまで読んでいただきありがとうございます！

## 参考文献
令和06-07年 応用情報技術者 試験によくでる問題集【午後】 単行本（ソフトカバー） – 2024/3/22
大滝 みや子 (著)
p.40
Azure Functionsの発行に失敗して「BadRequest」しか情報が無い場合、リソースグループのログに情報があるかも

# 概要

VisualStudioでAzureFunctionsを作成して発行すると、BadRequestエラーで失敗する。しかし、それ以外の詳細情報が無い。どうしよう・・・？という問題を解決した事例紹介です。

# 最初に結論まとめ

詳細情報は、Functions発行先の「リソースグループ」のログに入っていました。VisualStudioやAzure Functionsのログを見ても情報無しです。

ついでに、OpenApi用のNuGetパッケージは、インプロセスモデルと分離ワーカーモデルで使い分ける必要があるので、注意です。これがエラーの原因でした。

- **インプロセス モデルの場合:**
    
    `Microsoft.Azure.WebJobs.Extensions.OpenApi`
    
- **分離ワーカー モデルの場合:**
    
    `Microsoft.Azure.Functions.Worker.Extensions.OpenApi`
    

# 詳しく

## 背景

普段Windowsアプリをメインに作っていますが、Azureにチャレンジ中です。すると、基本的なところで次々と躓きます。基本的すぎて意外と情報が見つからなかったりするので、躓いたところと解決策を、この記事のように1つずつ書いていこうと思います。

## Functionsの作成と発行

Azure Functionsを作ることになりまして、慣れているVisualStudioで作成を開始しました。

「インプロセス」と「Isolated（分離ワーカーモデル）」という聞き慣れない用語の選択でいきなり悩みます。ざっと調べて・・・使おうとしている機能の都合と、今後は分離ワーカーモデルが推奨になっていくようなので、「Isolated（分離ワーカーモデル）」を選択して作成します。

色々とコーディングしてデバッグ実行での動作もOK。いよいよAzureへ発行です。実験用に分離しておきたいので、リソースグループ・ストレージアカウント・Application Insights等、全て新規作成します。一通り設定したら、発行です。

## 発行のエラー

失敗しました。さてエラー内容は・・・

「Azure で API を更新できませんでした。(状態コード: BadRequest)」

### エラー原因の調べ方で苦戦

うーん、これでは失敗したことしか分かりません。VisualStudioの画面ではこれ以上のエラー情報は無いようです。エラー内容からするとAzureへリクエストは届いた上でAzureからエラーを返されたように見えるので、Azure側のログを見てみます。

Azureポータルで見たところ、Functionsは作成されていました。しかし、Functionsのアクティビティログを見てみますが、何も出ていません。Functionsに紐付けたApplication Insightsのログを見ても、何のログもありません。困った。

### 解決！

Functions発行先のリソースグループのアクティビティログを見たところ、エラーのログがありました！

```csharp
Parsing error(s): Failed to import from specified resource [https://<function name>.azurewebsites.net/api/swagger.json:](https://gptsembeddingsearchisofunc.azurewebsites.net/api/swagger.json:) Response status code does not indicate success: 404 (Not Found).
```

ソースコード上でOpenApiの属性を付けていたのですが、swagger.jsonが出ている事から考えてそれ関連のエラーだったようです。このエラーだけだと原因が分かりづらいですが、結論としては使うNuGetパッケージを間違えていました。

上で触れましたが、今回は「Isolated（分離ワーカーモデル）」を選択しました。なのに、インプロセス向けのNuGetパッケージを使っていたのが原因です。次のように使い分ける必要があります。

- **インプロセス モデルの場合:**
    
    `Microsoft.Azure.WebJobs.Extensions.OpenApi`
    
- **分離ワーカー モデルの場合:**
    
    `Microsoft.Azure.Functions.Worker.Extensions.OpenApi`
    

# まとめ

Functionsの発行エラーでしたが、Functionsのログではなくリソースグループのログを見る必要があったという話でした。Azureに慣れていないため、エラーが起きた時にどこを見れば良いかという基本的なところでまず躓いてしまったようです。もしかして常識かもしれませんが、同じところで躓いた人の役に立つと嬉しいです。
Bulletproof React の原則を Next.js に適用する：状態管理編

Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるのでシェアします。

https://github.com/alan2207/bulletproof-react


## 1. 集中的なステート管理

アプリケーションの状態管理は、最も重要な設計上の決定の1つです。

### ベストプラクティス
- **グローバルステート**：React QueryやZustandを使用
  ```typescript
  // グローバルステートの例（Zustand）
  const useStore = create((set) => ({
    user: null,
    setUser: (user) => set({ user }),
    logout: () => set({ user: null })
  }));
  ```

- **ローカルステート**：useStateやuseReducerを活用
  ```typescript
  // ローカルステートの例
  const [isOpen, setIsOpen] = useState(false);
  ```

### キーポイント
- 状態管理はシンプルに保つ
- 必要な場所でのみステートを使用
- 適切なライブラリの選択

## 2. フィーチャーベースのファイル構成

プロジェクトの構造は、開発効率とコードの保守性に直接影響します。

### 推奨されるディレクトリ構造
```
src/
├── features/
│   ├── users/
│   │   ├── api/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── types/
│   │   └── utils/
│   └── products/
│       ├── api/
│       ├── components/
│       ├── hooks/
│       ├── types/
│       └── utils/
└── common/
    ├── components/
    ├── hooks/
    └── utils/
```

### メリット
- 機能単位での開発が容易
- コードの見つけやすさが向上
- スケーラビリティの確保

## 3. 明確なデータフロー

データの流れを明確にすることで、バグの発見と修正が容易になります。

### 実装例
```typescript
// APIレイヤーの抽象化
export const userAPI = {
  getUser: async (id: string) => {
    const response = await axios.get(`/api/users/${id}`);
    return response.data;
  }
};

// React Queryの使用
export const useUser = (id: string) => {
  return useQuery(['user', id], () => userAPI.getUser(id));
};
```

### 重要な要素
- データフェッチングの一元化
- エラーハンドリングの標準化
- ローディング状態の適切な管理

## 4. コンポーネントの分割

適切なコンポーネント分割は、コードの再利用性と保守性を高めます。

### コンポーネント設計の例
```typescript
// Presentational Component
const UserCard = ({ name, email }: UserCardProps) => (
  <div className="card">
    <h3>{name}</h3>
    <p>{email}</p>
  </div>
);

// Container Component
const UserCardContainer = ({ userId }: { userId: string }) => {
  const { data, isLoading } = useUser(userId);
  
  if (isLoading) return <Spinner />;
  
  return <UserCard name={data.name} email={data.email} />;
};
```

### ポイント
- ロジックと表示の分離
- 再利用可能なコンポーネント設計
- 明確なプロップスインターフェース

## 5. 一貫性のある設計パターン

プロジェクト全体で一貫したパターンを使用することで、開発効率が向上します。

### 実装例
```typescript
// エラーバウンダリ
class ErrorBoundary extends React.Component {
  state = { hasError: false };
  
  static getDerivedStateFromError() {
    return { hasError: true };
  }
  
  render() {
    if (this.state.hasError) {
      return <ErrorMessage />;
    }
    return this.props.children;
  }
}

// フォーム実装
const UserForm = () => {
  const { register, handleSubmit } = useForm();
  
  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("name")} />
      <button type="submit">送信</button>
    </form>
  );
};
```

### 重要なポイント
- エラー処理の標準化
- フォーム実装の一貫性
- UIコンポーネントの統一

## まとめ

Bulletproof Reactの5つの原則は、モダンなReactアプリケーション開発の基礎となります。これらの原則を適切に適用することで：

- メンテナンス性の高いコードベース
- 開発効率の向上
- バグの少ないアプリケーション
- チーム開発の円滑化

を実現できます。

ただし、これらの原則は絶対的なものではなく、プロジェクトの要件や規模に応じて柔軟に適用することが重要です。
ハッカソン個人備忘録⑨：Next.js（TypeScript） + Docker ローカル開発環境構築（Docker Compose対応）

## はじめに
Next.js + Docker の開発環境を構築し、**ホットリロード**（Hot Reload）が快適に動作するように設定する手順を紹介します。

:::note info
**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**
:::

コードを編集した際に自動でブラウザが更新されるような、ストレスのない開発環境の構築の参考になれば幸いです！

## 書こうと思ったきっかけ
複数人での開発やOS間の環境差異を減らすために Docker を活用する場面が増えました。

:::note warn
***しかし、Docker 環境で Next.js のホットリロードが効かないという悩みをよく聞きます。***
:::

実際に自分もその問題に直面したため、設定方法を整理して記録として残しておくことにしました。

## ✅ 構成概要
- **Next.js**: React ベースのフレームワーク
- **Docker**: コンテナで環境を統一
- **ホットリロード**: 開発中の変更がリアルタイムで反映される

**実際のリポジトリ**

https://github.com/2025SpringTeamA/frontend

## 📁 ディレクトリ構成（例）
```
next-app/
├── Dockerfile
├── docker-compose.yml
├── next.config.js
├── package.json
├── postcss.config.js
├── public/
├── pages/
└── styles/
```

## 1️⃣ Next.js アプリの初期化
```bash
npx create-next-app@latest next-app
cd next-app
```

## 2️⃣ Dockerfile 作成
```Dockerfile
# Dockerfile
FROM node:18-alpine

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["npm", "run", "dev"]
```

## 3️⃣ docker-compose.yml 作成
```yaml
# docker-compose.yml
version: '3.8'
services:
  next-app:
    container_name: next-app
    build: .
    ports:
      - "3000:3000"
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      - CHOKIDAR_USEPOLLING=true
```
🔁 `CHOKIDAR_USEPOLLING=true` によってファイル変更を正確に検知できるようになります。

## 4️⃣ .dockerignore 作成（重要）
```gitignore
node_modules
npm-debug.log
```

## 5️⃣ 開発サーバー起動
```bash
docker compose up --build
```

## ✅ 動作確認
1. ブラウザで `http://localhost:3000` にアクセス
2. `pages/index.js` を編集して保存
3. ホットリロードが反映されることを確認

## 📝 補足：ホットリロードが効かない場合の対処
- `volumes:` の設定が正しいか確認
- `CHOKIDAR_USEPOLLING` が有効か確認
- 特に Windows の場合、ファイル変更がコンテナに伝わらないケースがあるので注意

## まとめ
この構成を使えば、チーム全体で同じ環境を再現でき、開発効率もアップします。今後のプロジェクトでスムーズなスタートを切るためにも、ぜひ活用してみてください。

必要に応じて GitHub テンプレート化するのもおすすめです！
VMWareで仮想マシンを作成する(WinSV2025編)

仮想マシン作成ソフトとしてあるVMWare。
こちらで新規仮想マシンを作成する手順を記述

OSはWinSV2025を採用
※ISOファイルは事前に準備済み

①VMWare workstation pro 17　を起動し、"新規仮想マシンの作成"をクリックする
![1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/ebb5287e-3c76-45b6-b460-dec7c51b3804.jpeg)
②"標準(T)(推奨)"を選択し、"次へ(N)"をクリック
![2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/6c0934c7-f35c-429f-85d7-4174035bac2d.jpeg)
③該当するものを選択し、"次へ(N)"をクリック　※ここでは事前に用意したISOファイルを選択
![3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/e51a0264-5e65-494e-8728-a0b770b91964.jpeg)
④必要な情報を入力し"次へ(N)"
![4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/450f9e36-0e70-414e-b425-e0f36df15328.jpeg)
⑤"仮想マシン名(V)"と"場所(L)"を指定して"次へ(N)"をクリック
![6.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/03163eef-c1ab-4595-ba21-81f109eb60f5.jpeg)
⑥ディスク最大サイズを指定し仮想ディスクの格納方法を選択し"次へ(N)"をクリック
![7.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/053736fa-7a97-4258-9aad-f04770521f21.jpeg)
⑦仮想マシンのHWは変更できるので"ハードウェアをカスタマイズ(C)"をクリック
![8.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/3802159a-acd8-4583-a799-0b866ba31ad1.jpeg)
⑧メモリーの設定はこちら
![9.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/f9c0f9a1-1646-475d-8cb8-b81e5c6bcb80.jpeg)
⑨プロセッサーの設定はこちら
![10.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/d74704bd-759f-4e5f-802c-c28c0107b7fd.jpeg)
⑩設定終わったら下部にある"閉じる"をクリック
⑪最終の設定確認で問題なければ"完了"をクリック
![11.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/15ad128a-27c7-4501-8019-740eaba7d465.jpeg)
下記画像のように仮想マシンが作成される
![12.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3827128/f3f526a2-7f54-4a98-9c62-54f8289fa3bd.jpeg)
DisplayLink が反応しない

## 発生した事象
DisplayLink Manager Graphics Connectivity を v1.10.3 から v1.12.1 にアップデートしたところ、ディスプレイの片方が 30fps の HDMI ポートでしか反応しなくなった

## 結論
DisplayLink Manager Graphics Connectivity を v1.10.3 に戻したところ直った
気軽にアップデートしてはいけない
DisplayLink のソフトウェアをアップデートして反応しないとか映らないとかの症状が出たらまずは元のバージョンに戻してみy

## 環境
- MacBookPro 2020 M1
- macOS Sequoia 15.3.2
- Anker 564 USB-C ドッキングステーション (10-in-1, for MacBook)
- EX-LD4K271DB 2枚

## 試したこと
1. HDMI ポートの抜き差し -> ダメ
2. DisplayLink 端末の再起動 -> ダメ
3. DisplayLink Support Tools for mac でディスプレイレイアウトを初期化 -> ダメ
4. 他のポート -> HDMI の 60fps ポートのみ反応しない、30fps ポートは反応する
【初心者】シグネチャ型とアノマリ型の違いをイメージで忘れないようにする。

:::note info
資格試験で学んだもののあれこれどっちだっけとなるのでここではっきりさせる。
:::

### シグネチャ型
そもそも語源としてラテン語の「signatus（署名する、印をつける）」からきている。
転じて、悪い通信パターンやウイルスの挙動に印をつけて、登録しておくこととイメージ出来る。

**指名手配ポスター的なイメージ**

### アノマリ型
これも語源としてギリシャ語の「anomalos（不均一、変則）」からきている。
転じて、規則に反した行動や挙動をしたウイルスなどを検知し学習する。

**街の見守り隊的なイメージ**

### 違いについて箇条書きでまとめる。

**検出原理の違い**
・シグネチャ型：既知の脅威パターンのデータベースと照合して検出
・アノマリ型：通常の行動パターンからの逸脱を検出

**事前知識の必要性**
・シグネチャ型：既知の脅威の特徴を事前に定義する必要がある。
・アノマリ型：「正常」な状態を学習するだけでよく、脅威の事前知識は必ずしも必要ない。

**新種の脅威への対応**
・シグネチャ型：新種の脅威は検出できない。
・アノマリ型：未知の脅威でも異常行動として検出できる可能性がある。

**誤検出**
・シグネチャ型：パターンが一致するかの二択なので、誤検出は比較的少ない。
・アノマリ型：正常な動作の変動も「異常」と誤検出しやすい。
ハッカソン個人備忘録⑧：Docker Composeで楽をするなら？モノレポ構成が便利な理由をまとめてみた

## はじめに
フロントエンドとバックエンドを組み合わせたアプリケーションをGitHubで管理する際、リポジトリを1つにまとめるか、それぞれ別々にするかは悩みどころです。

:::note info
**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**
:::

この記事では、モノレポ（1つにまとめる）とリポジトリ分離（分ける）それぞれのメリット・デメリットを比較しながら、どんな構成が自分の開発スタイルに合っているかを考えていきます。

## 書こうと思ったきっかけ
ChatGPTとの会話で、「GitHubでフロントエンドとバックエンドを一緒のリポジトリにするべきか？」という疑問が出てきました。回答が非常にわかりやすかったので、備忘録としてまとめておきます。

## モノレポ構成（1つのリポジトリにまとめる）

### ディレクトリ構成例
```
my-app/
├── frontend/   # フロントエンド（例: Next.js）
├── backend/    # バックエンド（例: Express, Djangoなど）
├── docker-compose.yml
└── README.md
```

### メリット
- Docker Compose で全体を一括で立ち上げやすい
- フロントエンドとバックエンドの連携が簡単
- シンプルなCI/CD構成を組める
- 個人開発や小規模チームに向いている

### デメリット
- プロジェクトが大きくなると変更履歴が複雑化
- チームが完全分業体制の場合、運用が難しくなる可能性あり

## リポジトリ分離構成（フロントとバックを分ける）

### ディレクトリ構成例（GitHub上でそれぞれ別リポジトリ）
```
github.com/your-org/frontend-app
github.com/your-org/backend-app
```

### メリット
- フロントとバックを独立して管理可能
- チームで責任分担を明確にできる
- CI/CD を個別に設定できる
- 一部のみ外部公開したい場合に柔軟に対応できる

### デメリット
- 初期セットアップがやや手間（同期設定が必要）
- ローカルで2つのリポジトリを同時に管理する必要あり
- 連携部分でのトラブルが起きやすい

## 結論（おすすめ構成）
個人開発〜小規模チームであれば、最初は1つのリポジトリ（モノレポ）がおすすめです。

- 管理がシンプル
- Docker Compose で連携が簡単
- 将来的に必要であれば、後からリポジトリを分けることも可能です

## まとめ（選び方の目安）
| 条件 | モノレポがおすすめ | 分離構成がおすすめ |
|------|----------------------|-----------------------|
| 開発規模 | 小〜中規模 | 中〜大規模 |
| 開発人数 | 1人〜少人数 | 複数チーム |
| デプロイ | 一括管理 | 個別管理したい |
| CI/CD | 共通でOK | 分けたい |
| 学習・個人PJ | おすすめ | やや面倒 |

どちらの構成でも対応できるような設計にしておけば、運用中の変更も難しくありません。

:::note warn
**まずは一緒に管理しておいて、必要に応じてリポジトリを分けるスタイルでも問題ありません。**
:::

もしリポジトリを分ける方向で考えている場合は、「どんな運用を想定しているか」を明確にすると判断しやすくなります！
SQLで全文検索を実装してはいけない理由【アンチパターン：プアマンズ・サーチエンジン】

## はじめに
全文検索をSQLの`LIKE`演算子で代用していませんか？  
小規模なシステムでは一見動作しているように見えるこの設計は、実は「プアマンズ・サーチエンジン（Poor Man's Search Engine）」という有名なアンチパターンの一つです。

この記事では、この設計の問題点と、実際に取り入れるべき対策について具体的に解説します。



## プアマンズ・サーチエンジンとは？

データベースの`LIKE`や`REGEXP`を使って、あたかも全文検索のような動作を実現しようとする設計のことを指します。  
特に以下のようなクエリが典型的です。

```sql
SELECT * FROM articles
WHERE title LIKE '%AI%' OR content LIKE '%AI%';
```

この方法は簡単に導入できる一方で、以下のような大きな問題を抱えています。



## 問題点

### 1. インデックスが使えない

`LIKE '%キーワード%'`のような前方一致ではない検索は、インデックスを活用できず、フルテーブルスキャンになります。  
レコード数が増えるほど、検索速度が著しく低下します。

### 2. 検索の精度が低い

語幹（stem）や複数形、類義語などに対応できません。  
たとえば「AI」で検索しても、「人工知能」や「機械学習」に関する記事がヒットしない可能性があります。

### 3. 表現の限界

関連度順のソート、マルチワード検索、ハイライト表示など、高度な検索機能をSQL単体では再現できません。

## 解決策

全文検索が必要であれば、SQLの機能に頼らず、適切な手段を選びましょう。

### 方法1：MySQLのFULLTEXT検索

```sql
ALTER TABLE articles ADD FULLTEXT(title, content);

SELECT * FROM articles
WHERE MATCH(title, content) AGAINST ('AI');
```

基本的な全文検索が可能になります。ただし日本語や特殊な言語では精度に課題があることも。

### 方法2：PostgreSQLの全文検索機能（tsvector）

```sql
ALTER TABLE articles ADD COLUMN document tsvector;

UPDATE articles
SET document = to_tsvector('english', title || ' ' || content);

CREATE INDEX idx_document ON articles USING GIN(document);

SELECT * FROM articles
WHERE document @@ to_tsquery('AI');
```

多言語対応や構文の柔軟性、検索の精度でMySQLよりも優れた選択肢です。

### 方法3：専用の全文検索エンジンを導入する

- Elasticsearch
- Apache Solr
- Meilisearch

これらは本格的な全文検索機能を提供し、検索速度・精度・拡張性の点で非常に優れています。

## まとめ

| 方法 | メリット | デメリット |
|------|----------|------------|
| LIKE演算子 | 実装が簡単 | 遅い、精度低い |
| FULLTEXT（MySQL） | 高速で基本機能に対応 | 日本語処理に限界 |
| tsvector（PostgreSQL） | 精度・速度ともに良好 | 実装がやや複雑 |
| 検索エンジン | 多機能で拡張性抜群 | 学習・導入コストあり |

一時しのぎの検索ではなく、**長期的に使える検索体験**を設計するために、今すぐ「プアマンズ・サーチエンジン」から卒業しましょう。
家計簿アプリを作る＃３０

![スクリーンショット 2025-04-07 102516.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4012588/3635648e-7be8-4dc9-9aca-d8b3059d1bd4.png)
メニューの内容を表示しているのは、drawerの中の、Listとして表示していました。

![スクリーンショット 2025-04-07 102801.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4012588/7ebe8ac0-fc85-4ae4-9168-8672270a4074.png)
表示する内容をmap関数で一つ、一つ展開してます。

![スクリーンショット 2025-04-07 102903.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4012588/c71bb57c-b16d-4723-a5a1-2088f6c78ce1.png)
textとiconはこちら👆で表示してます。
iconは、indexが偶数であれば、InboxIcon、奇数であれば、MailIconを表示してます。
ハッカソン個人備忘録⑦：FastAPI × Next.js × Fargate構成で作れるWebアプリまとめメモ

## はじめに
モダンなWebアプリケーション開発を目指す際、技術選定はその将来性や保守性、開発体験に直結します。

この記事では、以下の技術スタックを採用した場合にどのようなアプリケーションが構築されるのか、具体的な想定と特徴を整理していきます。

- バックエンド：FastAPI
- フロントエンド：Next.js（TypeScript）
- インフラ：AWS Fargate + Terraform

## 書こうと思ったきっかけ
自分自身が新しい技術スタックを組み合わせて開発を進めるにあたって、「この構成でどんなアプリが作れるのか？」という視点で整理しておきたいと考えました。

:::note info
**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**
:::

特に、クラウド環境での実運用や、スケーラビリティを意識した構成を選ぶ理由も含めて記録することで、他の開発者の参考にもなればと思います。

---

## 🔧 バックエンド：FastAPI
### 特徴：
- Python製の高速APIフレームワーク
- 非同期処理対応で、軽快なパフォーマンス
- 型ヒントから自動的にSwagger UIやOpenAPIドキュメントを生成
- 少ないコード量で高機能なAPI構築が可能

### 用途例：
- ユーザー認証（JWTなど）
- データのCRUD操作（DB連携）
- AIや機械学習モデルの推論API
- 外部APIとの連携処理

---

## 🧑‍💻 フロントエンド：Next.js（TypeScript）
### 特徴：
- サーバーサイドレンダリング（SSR）対応でSEOに強い
- 静的サイト生成（SSG）やクライアントサイドレンダリング（CSR）も柔軟に切り替え可能
- TypeScript による型安全な開発体験
- API Routes や Middleware 機能によって、軽量なバックエンド処理も内包可能

### 用途例：
- 管理ダッシュボード
- チャットUI、SNS投稿機能
- ブログやポートフォリオなどの静的コンテンツ
- 商品一覧・決済ページを含むECサイト

---

## ☁️ インフラ：AWS Fargate + Terraform
### 特徴：
- Fargate：サーバーレスなコンテナ実行環境 → EC2管理が不要
- Terraform：Infrastructure as Code により構成の再現性が高く、チーム開発やCI/CDに向く
- オートスケーリングやログ監視（CloudWatch連携）とも親和性高い

### 用途例：
- 本番環境の安定運用
- 自動デプロイ・自動スケーリング対応のアプリ環境
- 環境構築・破棄の自動化（ステージング/本番の切り分けなど）

---

## 🎯 想定されるアプリの種類
| アプリの種類             | 解説 |
|--------------------------|------|
| SaaSアプリ              | タスク管理、勤怠管理などの業務支援系ツール。
| チャット・SNS系         | WebSocket + FastAPI でリアルタイム通信にも対応可。
| ポートフォリオ/ブログ   | Next.js の SEO強みを活かして静的コンテンツ構築。
| 管理画面付きのWebサービス | モダンなUIとAPI連携で効率的にデータ管理が可能。
| AI・データ解析アプリ     | FastAPI で推論APIを提供、Next.js で可視化や操作UI。

---

## 💡補足Tips：
- 認証は FastAPI で JWT ベースが定番。
- Terraform で ECSサービスとALBを自動構築。
- GitHub Actions や CodePipeline との連携でCI/CDを実現。
- CloudWatch Logs や Datadog を使えば、ログ監視も容易。

---

## おわりに
この技術スタックは、学習コストを抑えながらも拡張性と実用性の高いモダンWebアプリを構築できる組み合わせです。

個人開発やハッカソンなどのチーム開発にも、チームでのプロジェクトにも十分対応できる構成なので、参考資料にしてみてください！
ハッカソン個人備忘録⑥：コード変更が反映されない？FastAPIのホットリロード設定をまとめてみた

## はじめに

FastAPIをDockerで開発する際、コードの変更をリアルタイムに反映させたい場面が多々あります。

:::note warn
**そんなときに便利なのが「ホットリロード」です。**
:::

本記事では、FastAPIでホットリロードを有効にする方法について、実例を交えて解説します。

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

FastAPI + Docker構成で開発を始めたとき、「コードを変更しても反映されない」という悩みに直面しました。

:::note info
**個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。**
:::

調べてみると、`--reload` オプションや `volumes:` の設定が必要だと分かり、「これって意外とつまずく人多いのでは？」と思い、この記事を書くことにしました。

## ホットリロードはどこ？

FastAPIのホットリロード（コードの変更がリアルタイムに反映される仕組み）は、`uvicorn` の `--reload` オプションで実現されています。

https://github.com/2025SpringTeamA/backend

✅ ホットリロードが有効な場所:

- `docker-compose.yml` の `command:`

```yaml
command: uvicorn main:app --host 0.0.0.0 --port 8000 --reload
```

- または `Dockerfile` の `CMD:`

```dockerfile
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]
```

✅ ホットリロードを有効にするポイント:

- `--reload` を指定すること（すでに指定済み）
- `volumes:` でローカルコードをマウント

```yaml
volumes:
  - ./app:/app
```

これで、`app` フォルダの変更が即時コンテナに反映され、ホットリロードが機能します。

🔁 実際に試すには：

```python
@app.get("/")
def read_root():
    return {"message": "🔥 Hello from FastAPI with hot reload!"}
```

保存するだけで、ターミナルに `Reloading...` と表示され、変更が反映されます。

💡補足:
- `--reload` は開発専用です。本番では削除しましょう。
- 開発中は若干パフォーマンスに影響しますが、非常に便利です。
- `uvicorn[standard]` をインストールしていれば、内部で `watchgod` によりホットリロードが有効になります。

## まとめ

FastAPIのホットリロードは、ちょっとした設定で大きく開発効率を向上させてくれます。`--reload` の指定と `volumes:` のマウント、この2点を押さえるだけでOK。

:::note alert
***もし反映されないときは、`command` の書き方やマウント設定を見直してみてください！***
:::

Docker + FastAPIの組み合わせで快適な開発ライフを送りましょう！
BigQueryのビュー情報のバックアップについて

# はじめに

どうも、@to-fmakです。最近BigQueryに作成されたビューの情報のバックアップを取得する必要があったので、その方法について共有できればと思います。

# やりたいこと

BigQuery 内に複数のビューが存在しており、移行作業などに伴い、以下の情報のバックアップを取得したい

- データセットのメタデータ
- 各ビューのスキーマ情報
- 各ビューのクエリ定義

これらをファイルとして出力し、Cloud Storageなどに保存できるようにしたい

# 対応方法

データが格納されたテーブルの場合、Cloud Storage へのエクスポート機能を利用できます。しかし、ビューの場合はbqコマンドラインツールや SDKを使って情報を取得し、ファイルに保存する必要があります。
今回はCLIで実施します。（CloudShellから実行）

## CLIでの情報取得

以下のコマンドで、データセットのメタデータやビューの情報を取得できます。

```bash
# データセットのメタデータを取得
bq show --format=json <PROJECT_ID>:<DATASET_ID>

# スキーマやクエリなどを含めたビューの情報を取得
bq show --format=prettyjson <PROJECT_ID>:<DATASET_ID>.<VIEW_ID>
```

## スクリプト化

対象データセット内の複数のビュー情報を一括で取得する必要があったので、上記のコマンドをもとにシェルスクリプトを作成しました。

```bash:export_view_info.sh
#!/bin/bash

# プロジェクトとデータセットを指定
PROJECT_ID="xxxx"
DATASET_ID="$1"

# ディレクトリ作成
mkdir -p "$DATASET_ID"

# データセットのメタデータをエクスポート
bq show --format=json $PROJECT_ID:$DATASET_ID > $DATASET_ID/dataset_metadata.json

# データセット内の全テーブルとビューをリスト
bq ls --format=json $PROJECT_ID:$DATASET_ID > $DATASET_ID/tables_list.json

export_view_queries() {
    # bq lsの出力から各ビュー名を取得し、エクスポート
    bq ls $PROJECT_ID:$DATASET_ID | tail -n +3 | while read -r line; do
        # lineから最初のカラム（tableId）を抽出
        TABLE_ID=$(echo "$line" | awk '{print $1}')

        # ビューの場合のみエクスポート
        if [[ "$line" == *"VIEW"* ]]; then
            echo "Exporting view: $TABLE_ID"

            # ビューの情報を取得
            bq show --format=json "$PROJECT_ID:$DATASET_ID.$TABLE_ID" > "${DATASET_ID}/${TABLE_ID}_view_details.json"
        fi
    done
}

export_view_queries
```

上記スクリプトでは、DATASET_IDをコマンド引数から渡すようにしています。また、ビュー情報取得する際に、対象データセット内の全テーブルとビューをリストアップし、ビューの場合のみエクスポートするようにしています。

```bash
./export_view_info.sh <データセット名>
```

スクリプトを実行すると、<データセット名>/のディレクトリが作成され、取得したメタデータやビュー情報が格納されます。このディレクトリをCloud Storageなどにアップロードすることでバックアップとして活用できます。

あくまで一例なので、実際に利用する際は要件に応じてカスタマイズしていただければと思います。

# エンジニア募集

Gakken LEAP では教育をアップデートしていきたいエンジニアを絶賛大募集しています！！
ぜひお気軽にカジュアル面談へお越しください！！

https://gakken-leap.co.jp/recruit/
Googleで管理されているサービスアカウントについて

# はじめに

どうも、@to-fmakです。Google Cloudの一部のサービスでは、サービス利用時にGoogleが管理するデフォルトのサービスアカウントが作成されることがあります。これらのサービスアカウントは、一般的に「サービス エージェント」とも呼ばれ、必要な権限を付与することで利用することができます。今回は、Googleが管理するサービスアカウント（サービス エージェント）の確認方法と、権限を付与する方法について簡単に共有したいと思います。

# 管理コンソールの表示について

IAMの管理コンソールでは、ユーザが作ったもの以外はデフォルトでは非表示になっています。表示するには、「Google 提供のロール付与を含める」にチェックを入れる必要があります。

![Screenshot 2025-04-03 at 13.54.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2954734/dc152ca9-6888-4b89-990d-a432b2a7139a.png)

また、CLIでサービスアカウントを含めたIAMポリシーを確認する場合、以下のコマンドが使用できます。

```bash
gcloud projects get-iam-policy <PROJECT_ID>
```

# 権限付与について

管理コンソールから権限を付与する場合、以下の手順で設定できます。

- IAM画面にアクセスし、「アクセスを許可」をクリック
- 「プリンシパルの追加」で対象のサービスアカウントを入力
- 適切なロールを選択し、「保存」をクリック

または、既存のサービスアカウントの権限を変更する場合は、対象プリンシパルの横にある「編集」アイコンをクリックして、ロールを追加・削除できます。

CLIで権限を付与・削除する場合、以下のコマンドを使用します。

```bash
# ロールの追加
gcloud projects add-iam-policy-binding <PROJECT_ID> --member='serviceAccount:xxxxx@xxxxx.iam.gserviceaccount.com' --role=<ROLE_NAME>

# ロールの削除
gcloud projects remove-iam-policy-binding <PROJECT_ID> --member='serviceAccount:xxxxx@xxxxx.iam.gserviceaccount.com' --role=<ROLE_NAME>
```

また、Terraformでロール割り当てを行うことも可能です。以下は一例です。

```hcl
resource "google_project_iam_member" "example" {
  project = "<PROJECT_ID>"
  member  = "serviceAccount:xxxxx@xxxxx.iam.gserviceaccount.com"
  role    = "<ROLE_NAME>"
}
```

# 参考URL

https://cloud.google.com/iam/docs/service-account-types?hl=ja&_gl=1*101q18r*_ga*MTg0NDcxNjg2Ni4xNzI1OTI5MDk3*_ga_WH2QY8WWF5*MTc0MzY1NDcwNC4yMDguMS4xNzQzNjU3MzIyLjU3LjAuMA..#google-managed_service_accounts

https://cloud.google.com/iam/docs?hl=ja

https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam

# エンジニア募集

Gakken LEAP では教育をアップデートしていきたいエンジニアを絶賛大募集しています！！
ぜひお気軽にカジュアル面談へお越しください！！

https://gakken-leap.co.jp/recruit/
mcp-rb で1ファイルで動く MCP サーバーを書く

LLM の機能を拡張するプロトコルとして MCP がある。(LSP みたいな感じ)

https://modelcontextprotocol.io/introduction

Ruby だと mcp-rb を使うことで実装が簡単にできる。

https://github.com/funwarioisii/mcp-rb

以下のように簡単な DSL で MCP サーバーが作れる。

```ruby
require 'mcp-rb'

name 'local-mcp'
version '0.1.0'

resource "file://how-to-calculate-square" do
  name "how-to-calculate-square"
  description "Show how to calculate the square of a number"
  call { "Use calculate-square tool" }
end

tool "calculate-square" do
  description "Calculate the square of a number"

  argument :number, Integer, required: true, description: "The number to be squared"

  call do |args|
    args[:number] * args[:number]
  end
end
```

Claude, Cline, Copilot Agent など、様々なクライアントで MCP の対応が行われている。

https://modelcontextprotocol.io/quickstart/user

https://docs.cline.bot/mcp-servers/configuring-mcp-servers

https://code.visualstudio.com/docs/copilot/chat/mcp-servers

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7048/8718054b-81a2-46fa-bf1d-668abf8860cc.png)

## `bundler/inline` と併用するのがおすすめ

利用する際には `bundler/inline` と併用するのがおすすめ。
依存関係をファイル内に記述できるので、単体で実行しやすくなるのと、特定プロジェクト用の MCP サーバーを実装して、関係者に配るとかでは便利。

こんな感じで外部 API を叩くような MCP サーバーが簡単に書ける。

```ruby
#!/usr/bin/env ruby

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'

  gem 'mcp-rb', require: 'mcp'
  gem 'octokit'
end

name 'twitter-from-github'
version '0.1.0'

tool "twitter-from-github" do
  description "Tell me about the twitter name of the user from GitHub status"

  argument :username, String, required: true, description: "The name of GitHub user that you want to know the twitter name"

  call do |args|
    client = Octokit::Client.new
    user = client.user(args[:username])
    user.twitter_username
  end
end
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/7048/33d1ae1f-af9c-407b-ac2d-7a53ab0fbf90.png)
Ubuntu24.04にDockerをインストールしよう。

本日はタイトルにもある通り、Ubuntu24.04にDockerをインストールしてみます。
今回もインストール手順だけを紹介しますので、コンパクトな記事にしようと思います。
## Ubuntu24.04にDockerをインストールする手順
### ①Dockerのインストール環境を準備
KAGOYA CLOUD VPSからOSでUbuntu24.04を選択。
![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3993170/627f7dc8-469e-4702-a492-664f8a00349b.png)

スペックは2コア/2GB/200GB(日額28円)を選択。
![2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3993170/dbe2f8a8-b9db-48c6-beb5-a2530123d21e.png)

この内容でインスタンスを作成します。

### ②インストール作業
パッケージリストの準備。
```ruby:
sudo apt update
sudo apt install -y ca-certificates curl gnupg
```
DockerのGPGキーを追加。
```ruby:
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
```
公式のDockerリポジトリを追加。
```ruby:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
```
再度、パッケージリストを更新。
```ruby:
sudo apt update
```
ここでようやくDockerをインストール。
```ruby:
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
```
これでDockerのインストールが完了となります。
念のため、正常に動くか試してみます。
```ruby:
sudo docker run hello-world
```
![3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3993170/da923aa7-9c36-46fb-8b21-a49eb438610b.png)
問題なく稼働していることが確認できました！

## 最後に
はじめ、油断して何も考えずにUbuntu20.04と同じコマンドを叩いたところ、正しくインストールが走らず焦りました。
が、基本的な流れはUbuntu24.04でも同じでしたので、そこまで苦労することなくインストールができました。

ただ、この状態ではsudo権限が無いとDockerを使えない状態ですので、必要に応じて追加でコマンドを叩きましょう。
（この辺りのコマンドは本家サイトの方でご紹介しております。）
進化型フレームワーク

自分で開発しようとしていたら、同じようなコンセプトのリポジトリを発見
とりあえず、CURSOR-AIがバカなのでコーディングは中断した

https://github.com/matiasmolinas/evolving-agents/

https://github.com/HKUDS/AutoAgent

ひとまず、この方の取組を参考にしつつ、私は早く動画編集アプリとブログ記事作成アプリに取りかからなければ。。。
DOSバッチによる　クリップボード格納(ログイン的な使い方)


#

## 環境

※win7以上は使えるらしいです。

実行環境：win11 (64bit)


## クリップボード格納


```dosbatch:ログイン.bat
@echo OFF

REM =========================
REM === メイン
REM =========================

rem アドレス
call :setClipBoard "999 888 777 666"

rem パスワード
call :setClipBoard "pass"
rem 名前
call :setClipBoard "UserName"

exit /b

REM =========================
REM (Sub)クリップボード格納
REM =========================
:setClipBoard

REM  %1=>""込みの文字列 
REM  %~1=>""外しの文字列 
echo.
echo クリップボードに格納しました
echo ----------------------------
echo %~1
echo ----------------------------
echo %~1|clip

pause

cls
exit /b

```
## 実行画面

```console:コンソール画面１

クリップボードに格納しました
----------------------------
999 888 777 666
----------------------------
続行するには何かキーを押してください . . .

```

```console:コンソール画面２

クリップボードに格納しました
----------------------------
pass
----------------------------
続行するには何かキーを押してください . . .

```

```console:コンソール画面３

クリップボードに格納しました
----------------------------
UserName
----------------------------
続行するには何かキーを押してください . . .

```



::: note 
### 説明(Dosコマンドより)

コマンド ライン ツールの出力を Windows クリップボードにリダイレクトします。
その出力されたテキストをほかのプログラムに貼り付けることができます。

### パラメーター一覧:
 /?                  このヘルプを表示します。

### 使用例

文字列をクリップボードに貼り付けます。

```console:コンソール画面
> echo クリップボード保存| CLIP          
```

クリップボードには「`クリップボード保存`」と保管されています

---
readme.txt ファイルのテキストのコピーを Windowsクリップボードに貼り付けます。

```console:コンソール画面
> CLIP < README.TXT
```



:::
宣言的UIの理解とReactにおける実装

## はじめに

ウェブフロントエンド開発において、「宣言的UI」というパラダイムが主流になっています。特にReactのような人気フレームワークでは、この宣言的アプローチが採用されています。本記事では、宣言的UIとは何か、なぜそれが重要なのか、そしてReactでどのように実装されるのかについて解説します。

## 宣言的UIとは

宣言的UI（Declarative UI）とは、「どのように（how）」ではなく「何を（what）」宣言するアプローチです。つまり、UIの状態がどうあるべきかを記述し、その状態変化に伴うUIの更新はフレームワークが自動的に処理します。

対照的に、命令的UI（Imperative UI）では、開発者がDOMを直接操作し、要素の追加・削除・更新など、UIの変更方法を一つ一つ指示する必要があります。

## Reactにおける宣言的UI

Reactは宣言的UIの代表的な例です。以下に、Reactにおける宣言的UIの実装例を示します：

```jsx
import React, { useState } from 'react';
import Todo from './components/Todo';

const TodoList = ({ todos }) => {
  const [value, setValue] = useState('');
  
  const handleChange = (e) => {
    setValue(e.target.value);
  };
  
  return (
    <>
      <input 
        type="text" 
        value={value} 
        onChange={handleChange} 
      />
      {todos.map(todo => (
        <Todo 
          key={todo.id} 
          text={todo.text} 
        />
      ))}
    </>
  );
};

export default TodoList;
```

この例では：

1. `useState`フックを使用して`value`という状態を宣言しています
2. 入力値が変更されると`handleChange`関数が呼び出され、状態を更新します
3. 状態の更新により、Reactが自動的にコンポーネントを再レンダリングします
4. 開発者はDOMを直接操作することなく、UIがどうあるべきかを宣言するだけです

## 命令的UIとの比較

命令的UIでは、同様の機能を実装するためには、以下のようなコードが必要になります（jQuery風）：

```javascript
// 入力フィールドの値を取得
let value = '';

// 入力フィールドの変更イベントハンドラー
$('#todo-input').on('input', function() {
  value = $(this).val();
  // UIを更新するための追加コード...
});

// 新しいTodoを追加する関数
function addTodo(text) {
  $('#todo-list').append('<li>' + text + '</li>');
}

// UIの初期化
function initUI() {
  $('#todo-container').html(
    '<input id="todo-input" type="text">' +
    '<ul id="todo-list"></ul>'
  );
}

// 初期化実行
initUI();
```

宣言的アプローチと比較すると、命令的アプローチでは：

1. DOMの操作順序が重要になる
2. コードが冗長になりがち
3. 状態管理が複雑になる
4. コードの保守性が低下する

## 宣言的UIの利点

宣言的UIには以下のような利点があります：

1. **コードの可読性向上** - UIがどうあるべきかを記述するため、理解しやすい
2. **バグの減少** - DOMの操作順序などの複雑さを抽象化
3. **再利用性の向上** - コンポーネントベースの設計により、コードの再利用が容易
4. **テストの容易さ** - 純粋な関数として扱えるため、テストが容易
5. **開発効率の向上** - 「どのように」ではなく「何を」に集中できる

## なぜReactは人気なのか

Reactが人気である理由の一つは、この宣言的UIのパラダイムにあります。開発者はUIの見た目とロジックを宣言的に記述するだけで、DOMの更新はReactが効率的に処理してくれます。これにより、開発者は以下のことに集中できます：

1. ユーザー体験の向上
2. ビジネスロジックの実装
3. コンポーネントの再利用性と保守性の向上

## まとめ

宣言的UIは、現代のフロントエンド開発において重要なパラダイムです。特にReactのようなフレームワークでは、この宣言的アプローチが採用されており、開発効率と保守性の向上に大きく貢献しています。

宣言的UIを理解することで、より効率的で保守性の高いフロントエンド開発が可能になります。Reactを使った開発経験を持つ方も、これからReactを始める方も、この宣言的UIの概念を理解することで、より効果的なコードを書くことができるでしょう。

## 参考資料

- [React公式ドキュメント](https://reactjs.org/docs/thinking-in-react.html)
- [Declarative vs Imperative Programming](https://ui.dev/imperative-vs-declarative-programming)