OmniAICreator/Qiita-1.07M huggingface dataset:
『人月の神話』を読んだ

Q. IT土方検定「以下の文から、現場の状況と乖離している箇所を述べよ」

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/581044/a5934dd5-0c9e-4e29-9f76-933c7a42876f.png)

https://www.itpassportsiken.com/kakomon/21_aki/q30.html

A.

- 「3ヶ月経過した時点で全体の50%が完了していた」
→ 実際は20～30%ほどしか完了していない。
- 「途中から増員するメンバーの作業効率は最初から作業している要因の70%」
→ 嘘。もし増員メンバが未経験者なら、いきなり70%も出せるわけがない。もし増員メンバが経験者のベテランなら、絶対に他の案件も抱えているので半分以上のリソースが割けるわけがない。仮に70%割ける想定で予定が組まれていたとしても、引継ぎに必ず不足があるし、本人の心理的にもヘルプより元業務を優先したくなる。

- 「最初の6人のグループの作業効率は残り2ヶ月も変わらないものとする」
→ あり得ない。追加作業者は、誰から作業を教わるのか？分からないことは誰に聞くのか？

最後の1つは『人月の神話』で（おそらく初めて）提示された主張だと思う。この本の表題論文の中で、人月という概念（=人と月が交換できるという考え）が神話だとして批判されている。面白かったのでまとめる。

https://www.maruzen-publishing.co.jp/book/b10111860.html



## 『人月の神話』 要旨

この論文の主題は「なぜプロジェクトが遅れるのか」である。

著者ブルックスは、プロジェクトが遅れる原因として、以下の5つを挙げている。

1. すべてうまくいくだろうという前提（楽観主義）
2. 人と月が相互に交換可能という考え（人月）
3. 見積もりに対する自信のなさ（勇気のない見積もり）
4. スケジュールの進捗がきちんと監視されていないこと
5. スケジュールの遅延が発生した場合に採られるる「要因を追加する」という対応（スケジュール変更の悲劇）

論文の中では4以外について詳細に記載されているため、それぞれについてまとめる。

### 1. 楽観主義

創作物はまず最初アイデアとして、時間と空間の制約を受けずに作者の頭の中で完成した形で生まれる。アイデアの不完全さや不整合は、実現段階になってはじめて明白になる。特にプログラムについては、他の創作活動にあるようなメディア（=ハード）の制約による困難（「ペンキがこすれてしまう」「電気回路が焼き付いてしまう」）がないため、実現が難しいことはないと考えてしまう。

感想：だからこそ設計は楽しくて実装はつまらない（自分もそう思う）。設計時点では間違いがほぼ明らかになることがないから。

### 2. 人月

「人月」という単位を用いると、仕事の大きさは以下の式で表される。

> 人数 × 月数
> 

仕事の大きさは人と月の掛け算なので、人と月は交換可能として扱われる。例えば、仕事の大きさが10の場合、2人で5ヶ月仕事をするのと、5人で2ヶ月仕事をするのは同じことである。ただこれは、作業者の間でコミュニケーションを取らなくても仕事が分担できる場合だけ。女性がどれほどたくさん動員されたところで、子供が10月10日かかるのと同じように、システム開発には当てはまらない。

コミュニケーションには、「教育・訓練」「相互コミュニケーション」の2つがある。

「教育・訓練」：テクノロジー、仕事のゴール、統括的戦略、作業計画の教育

「相互コミュニケーション」：お互いの仕事の個別調整。人の組み合わせのパターンだけ労力は増大する。

感想：相互コミュニケーションはめちゃくちゃ分かる。いわゆる「根回し」の時間もここに該当しそう。

### 3. 勇気のない見積もり

データの裏付けがなく見積もりを勘に頼っているため、自身の見積もりを堂々と主張できず、得意先の希望する納期に合わせてスケジューリングしてしまう。解決策は、生産性の数量化や見積もりの基準を開発すること。

感想：日本人なら分かるが、アメリカ人も忖度することがあるとは知らなかった。

### 5. スケジュール変更の悲劇

要因を増やすという解決策は悲劇を招く。2の人月の神話と似た話だが、ここでは「追加」に焦点があてられている。

プロジェクトが進行形で遅れている場合、取りうる選択肢は「要因を増やす」「スケジュールを立て直す」「仕事を縮小する」があるが、ブルックス曰く、「仕事を縮小する」が唯一の取りえる手段である。「スケジュールを立て直す」の選択肢は、別のコスト（おそらく顧客との信頼関係の低下など）があるため、実際は採られにくい。

「要因を増やす」は最悪で、追加された人はどんなに優秀でも経験者の1人から仕事に関する教育・訓練を受ける必要がある。これに1ヶ月かかるとすると、1人＋追加要因数の人月はもとの見積もりにはなかった仕事が増える。また、分割していた仕事をさらに細かく分割する必要が出てくるため、システムテスト（結合テスト）をより長くしなくてはならない。

## 感想
そもそも人月という考えはどこから来たのか。この本の別の論文「銀の弾などない」では、ソフトウェア開発のアナロジーの変遷が語られる。

この論文によると、ソフトウェア開発は、

書くもの　→　構築するもの　

に変化したらしい。

「構築」はソフトウェアを建築に見立てたアナロジーで、これによって「仕様書」「コンポーネント」「足場固め」という建築の概念がソフトウェアに持ち込まれた。おそらく「人月」もここで持ち込まれたのではないか。建築でいう「人工」の概念がソフトウェア版として変化して持ち込まれたような気がする。

「銀の弾などない」では、建築のアナロジーがとらえ損なている側面についても述べられている（前もって正確に指定できない、複雑すぎて欠陥なしで作れない、等）。これらを踏まえて、ブルックスは新たなアナロジーを提案している。

→　育成するもの

これはソフトウェア開発を生命に見立てている。ソフトウェアは不完全で生まれてきて、徐々に色々なものを身につけていく。その成長の方向性は開発者が全て決められるわけではない。実際には開発のしやすさやユーザーのニーズによって自然と形作られていく。そして時間とともに徐々に衰え、やがて誰にも使われなくなったとき、そのソフトウェアは「死」を迎えるのだ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/581044/c4e878da-4d15-419b-9a50-beaf9925d410.png)
【Python】pandasのdate_range関数

date_range関数は「開始と終了」の指定（startとendの表記は省略可）、もしくは「開始と期間（periods）」の指定が必要です。「開始と頻度（freq）」では作成できません。

なお、pandasで使用する主な頻度は以下となります。

D　日時
W　週次
M　月末ごと
Q　四半期末ごと
A　年末ごと
H　毎時
T　毎分
S　毎秒
Bootstrapとはなんだっけ

---

## 1. Bootstrap とは
- **Twitter 社発の OSS フレームワーク**。HTML・CSS・JS をひとまとめで提供。
- MIT ライセンスで商用利用もOK  
- **モバイルファースト & レスポンシブ設計**がコア思想。スマホ表示を前提にデザインを組める

### OSS
- **O**pen **S**ource **S**oftware（ソースコードを公開）
- 誰でも閲覧・改変・再配布できる（ライセンス条件あり）
- メリット  
  - 透明性：安全性を検証しやすい  
  - 参加型：世界中がバグ修正・機能追加に貢献  
  - 低コスト：ライセンス料が不要


---

## 2. 主要機能・特徴
| カテゴリ | 概要 |
|----------|------|
| **12カラムグリッド** | `container`→`row`→`col` で自在にレイアウト。 |
| **ユーティリティクラス** | 余白・表示切替・Flexbox などを 1 クラスで制御し、CSS を書く量を削減  |
| **UIコンポーネント** | NavBar／Card／Modal／Toast など 30 以上の部品を標準装備  ||
| **Bootstrap Icons** | 無料 SVG アイコン 2,000+ を同梱。|


### SVG
- **S**calable **V**ector **G**raphics（XML ベースのベクター画像）
- 拡大・縮小しても画質が劣化しない
- CSS / JS で色やアニメーションを直接操作可能
- 軽量・テキスト検索可 → Web アイコン・ロゴに最適

---

## 3. Bootstrap を学ぶメリット
- **学習コストが低い**：公式ドキュメントとサンプルが充実、初心者でも直感的に使える  
 
- **開発スピード向上**：ボタン・フォーム等の汎用 UI をコピペで追加→コーディング時間を短縮  
- **デザインの一貫性**：トークン化された色・余白で UI のバラつきを防止
- **モバイル対応が標準**：グリッド＋ユーティリティでスマホ表示が自動調整  
- **巨大コミュニティ**：Issue・ブログ・テーマが豊富で情報がすぐ見つかる  
---

## 6. 注意点（デメリット）
| 課題 | 回避策 |
|------|--------|
| **ファイルサイズが大きい** | 使わない JS/CSS を tree-shaking、未使用 CSS は PurgeCSS で削減 |
| **デザインが似通う** | Sass 変数とユーティリティで独自テーマを適用／コンポーネントをカスタム |
| **既存 Design System と衝突** | ガイドラインが厳しい案件では Bootstrap 採用を再検討 |

---
初めての自宅サーバーをしてみた話　低スペPC編

# 謝罪
この度は、主(img1982)が、管理不足により2FAファクタを紛失してしまい、その上リカバリーキーも紛失etc...、結構やらかしてしまって、アカウントへのアクセスができませんでした。
本当は、運営などへ、申請や申告(アカウント死にましたからねー)としなきゃいけないのですが、なんか、主が、嫌がってしまい放棄してました。全て主が悪いです。申し訳ございません。既に新アカウントでは2FAの設定なども厳重に管理しておりますので、このようなことが２度と起きないよう対策いたしました。
# 本編
果たしても素材不足のため、ほぼ自鯖紹介記事となっておりますが、どうぞ承知いたしていただけますと、こちらとしても嬉しいです。
### 主のサーバー構成
(※ほぼこれに書いてると思う)
![名称未設定ファイル.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4005104/19a09d3c-4875-4df3-b3f4-ebe102f55847.png)
### 主にやってること
#### 外出先の作業環境
学校支給のパソコンから、メールの返信やコーディングをする目的で構築
たまに使ってる。
#### Nextcloud
言わずもがな、自宅サーバー業界で有名な、ファイル共有サービス。主に、写真保存や、ファイル転送目的で利用してる。が、googledriveに寝返った()
じゃあなぜ立てた
#### ゲームサーバー
フレンドとゲームをするために構築。友達がいないという現実的理由で全く利用できてないが、たまに使ってる。
#### DiscordBot
不具合なく、利用できてる。
これが最初で最後の自作物の自宅サーバーでの運用。
# まとめ
この記事下書きだけは書いてたけど、めんどくさくて後回しにしてました。本当にすいません。
N+1問題の解決とEager Loading

Eager Loadingとは、リレーションを事前にまとめて取得することで、DBで無駄なクエリを減らすための方法であり、N+1問題の対処法の一つである。

### N+1が発生するコード

```php
$books = Book::all();

foreach ($books as $book) {
    $ratings = $book->evaluations; 
}
```

上記のコードの場合、例えば本が10冊あればforeachのループも合わせて計11回のSQLクエリが発行される。

SQLに表すと

```sql
//booksテーブルを取得
SELECT * FROM books;

//10冊あれば10回繰り返す
SELECT * FROM evaluations WHERE book_id = 1;
SELECT * FROM evaluations WHERE book_id = 2;
SELECT * FROM evaluations WHERE book_id = 3;
~続く
```

となる。

1回+N回のクエリが発行され、N+1問題になる。

### Eager Loadingを使用したコード

```php
$books = Book::with('evaluations')->get();

foreach ($books as $book) {
    $ratings = $book->evaluations; 
}
```

このようにwithを使用して事前にリレーションを読み込むやり方をEager Loadingという。

SQLに表すと

```sql
//booksテーブルを取得
SELECT * FROM books;

//evaluationsテーブルを book_id でまとめて取得する
SELECT * FROM evaluations WHERE book_id IN (1, 2, 3, 4, ...続く);
```

このようになる。

計2回のSQLクエリを発行するだけで済むため、処理が高速になりDBに優しいコードになる。

結果として、N+1問題を解決できる。
使用方法の確認

# 使用方法の確認

いったんメモ
使い方の確認です。

~~取り消し線~~


## ファイル・フォルダコピーマクロ
```Sub サブフォルダ含むファイル探索()
    Dim Original_folderPath As String
    Dim Clone_folderPath As String
    Dim LastRow As Long
    Dim i As Long
    Dim Target_fileList As Collection
    Dim Target_file As String

    Set Target_fileList = New Collection

    Original_folderPath = Worksheets("フォルダ").Cells(3, 1).Value
    Clone_folderPath = Worksheets("フォルダ").Cells(6, 1).Value

    If Right(Original_folderPath, 1) <> "\" Then Original_folderPath = Original_folderPath & "\"
    If Right(Clone_folderPath, 1) <> "\" Then Clone_folderPath = Clone_folderPath & "\"

    LastRow = Worksheets("フォルダ").Cells(Rows.Count, 1).End(xlUp).Row
    For i = 9 To LastRow
        Target_file = Trim(Worksheets("フォルダ").Cells(i, 1).Value)
        If Target_file <> "" Then Target_fileList.Add Target_file
    Next i

    ' 再帰的にファイル探索とコピー
    Call SearchAndCopyFiles(Original_folderPath, Clone_folderPath, Target_fileList, Original_folderPath)

    MsgBox "コピーが完了しました。", vbInformation
End Sub

Sub SearchAndCopyFiles(ByVal currentFolder As String, ByVal Clone_folderPath As String, _
                       ByVal Target_fileList As Collection, ByVal Root_folder As String)

    Dim fso As Object
    Set fso = CreateObject("Scripting.FileSystemObject")

    Dim file As Object
    Dim subfolder As Object
    Dim targetName As Variant

    ' このフォルダ内のすべてのファイルをチェック
    For Each file In fso.GetFolder(currentFolder).Files
        For Each targetName In Target_fileList
            If StrComp(file.Name, targetName, vbTextCompare) = 0 Then
                ' 相対パスを作ってコピー先を決定
                Dim relativePath As String
                relativePath = Mid(file.ParentFolder.path, Len(Root_folder) + 1)
                If relativePath <> "" Then relativePath = relativePath & "\"

                Dim destPath As String
                destPath = Clone_folderPath & relativePath

                If Not fso.FolderExists(destPath) Then fso.CreateFolder destPath
                file.Copy destPath & file.Name, True
            End If
        Next targetName
    Next file

    ' サブフォルダについても同様に処理（再帰）
    For Each subfolder In fso.GetFolder(currentFolder).SubFolders
        Call SearchAndCopyFiles(subfolder.path, Clone_folderPath, Target_fileList, Root_folder)
    Next subfolder
End Sub

```
![スクリーンショット 2025-06-23 002944.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4120514/9ebfa8e5-ce56-4b06-9c38-7cfbc7416010.png)
Google Gemini を使ってコンテンツ生成するユーティリティ関数の実装

# はじめに

最近話題の Google の生成AI「Gemini」。公式の npm パッケージ [`@google/generative-ai`](https://www.npmjs.com/package/@google/generative-ai) を使えば、Node.js や Next.js プロジェクトでも簡単に扱えます。

本記事では、Gemini API を使ってプロンプトからテキストを生成する関数 `generateWithGemini` を実装してみます。

# セットアップ

```bash
npm install @google/generative-ai
```

`.env` に API キーを設定：

```env
GEMINI_API_KEY=your_google_api_key
```

# 実装コード

```ts
// lib/gemini.ts
import { GoogleGenerativeAI } from "@google/generative-ai";

const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY || '');

export async function generateWithGemini(prompt: string) {
  try {
    const model = genAI.getGenerativeModel({ model: "gemini-2.0-flash-exp" });

    const generationConfig = {
      temperature: 0.7,
      topK: 40,
      topP: 0.9,
      maxOutputTokens: 1024,
    };

    const result = await model.generateContent({
      contents: [{ role: "user", parts: [{ text: prompt }] }],
      generationConfig,
    });

    const response = await result.response;
    return response.text();
  } catch (error) {
    console.error('Error in generateWithGemini:', error);
    throw error;
  }
}
```

**🧭 補足解説**

| パラメータ             | 説明                                                                           |
| ----------------- | ---------------------------------------------------------------------------- |
| `temperature`     | ランダム性。0.0 に近いとより決定的、1.0 に近いとより多様性あり。                                         |
| `topK` / `topP`   | 単語選択のサンプリング手法。生成の多様性に影響します。                                                  |
| `maxOutputTokens` | 出力される最大トークン数。                                                                |
| `model`           | 使用する Gemini モデル。例: `gemini-pro`, `gemini-2.0-pro`, `gemini-2.0-flash-exp` など |

**✅ 使用例**

```ts
const text = await generateWithGemini("ReactでTodoアプリを作る手順を教えて");
console.log(text);
```

# おわりに

今回は Google Gemini を Node.js プロジェクトで利用するための基本的なユーティリティ関数を紹介しました。OpenAI API に慣れている人にとっても扱いやすく、生成系のタスクに役立ちます。今後は画像生成やマルチモーダル対応にもチャレンジしていきたいですね！
OCIスタック:インスタンス作成→削除→再作成後にVNICをアタッチした際に削除したはずのインスタンスを読み込んでしまい再作成したインスタンスを読み込んでくれない問題の解決方法

# 背景
OCIのスタックAでインスタンスを作成→削除後に、スタックBで同じTerraformを使用してインスタンスを作成した。その後インスタンスにアタッチする用のVNICをスタックで作成しようとしたが、スタックAで作成した削除済のインスタンスを参照してしまいVNICのデプロイができない状況になってしまった。

# 解決方法
### 結論：dataブロックにフィルタを追加する。
削除済のインスタンスを参照しないように、'data'ブロックに'filter'を追加して'running'状態のインスタンスのみを参照するようにしたら治りました。

# 問題の原因

### 結論：削除済のインスタンス情報がOCI上に残っていてたこと

今回のケースでは同じTerraformを使用して2つのスタック（AとB）を使用してインスタンスを作成しました。
その為、OCI上で同一の設定を保持しているインスタンスが2つ作成されてしまいスタックAで作成したインスタンスを削除したにもかかわらず、そのままOCID等の情報がOCIに残ってしまいました。
その状態で、VNICのスタックにてデプロイを行い、VNICでインスタンスを参照しようとすると作成順に参照が実行されて削除済のインスタンスを見に行ってしまうという訳でした。

# まとめ
今回の問題を通じてインスタンスの再作成後に作成するオブジェクトでインスタンスを参照する際に旧インスタンスの情報を参照しないようにする方法を学ぶことができました。知っていると意外と使いそうなので皆さんのご参考になれば幸いです。
ierae CTF 2025 writeup

# イエラエCTFのWriteUp

## DiNo.1 / 96pt

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523062/0071372f-c31b-40c1-96a6-c86c932b6095.png)

Dinoを模したサイトがあります。

本家に関する情報はこちらです。

https://en.wikipedia.org/wiki/Dinosaur_Game

ブラウザーで以下を開くと同様のゲームをプレイすることができます。

<a href="chrome://dino">chrome://dino</a>
<a href="chrome://network-error/-106">chrome://network-error/-106</a>

こちらは本家です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523062/75eb8faa-1ea9-4e72-9ced-f7ce0bbe111d.png)

こちらはCTFバージョンです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523062/f4fb4411-ea11-44a7-a72c-4fd95139befa.png)

画面下部分にある通り、5000点以上を獲得するとフラグが得られるようになっています。

🐻が👆とぶつかると、ゲームオーバーになってしまいます。

がんばって5000点を超えるようにプレイするとフラグが得られます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523062/32b1c249-41a5-4651-8207-5df0da99e3f5.png)

以上です。
GitLab CIの共通ジョブをテンプレート化して、複数プロジェクトで再利用する方法

## はじめに

CI/CD ジョブがプロジェクトごとにコピペされてメンテナンスが大変…  
そんな経験はありませんか？

- 複数のサービスで同じジョブ定義（デプロイや通知など）を使っている  
- 定義を変えたいが、いちいち全プロジェクトの `.gitlab-ci.yml` を直すのが面倒  
- テンプレートとして切り出したいが、どうやってやるのかよく分からない  

本記事では、**GitLab CI の共通ジョブを別リポジトリにテンプレート化し、複数プロジェクトから `include:` で呼び出して再利用する方法**をご紹介します。

## 想定読者

- GitLab CI を使って複数プロジェクトを運用している方  
- `.gitlab-ci.yml` の共通化・メンテナンス性に悩んでいる方  
- チームや組織全体で CI の品質を統一したい方  

## 1. なぜテンプレート化するのか？

プロジェクトごとに同じ処理をコピーしていると、以下のような問題が起こります。

- 変更のたびに全プロジェクトへ修正が必要  
- 記述ミスや更新漏れが発生しやすい  
- CIのルール・標準がバラバラになる  

一方、共通ジョブを **テンプレートとして別リポジトリで管理**すれば：

- ✅ 一元管理できる  
- ✅ バージョン管理できる（`ref:`）  
- ✅ 品質が揃う  

## 2. 例：EC2 に `git pull` を実行するデプロイジョブ

ここでは、**GitLab CI から AWS Systems Manager (SSM)** を使って、EC2 インスタンス上で `git pull` を実行するジョブを共通テンプレート化する例を紹介します。

### テンプレート構成（別リポジトリ）
```yaml
gitlab-ci-templates/
├── oidc-assume-role.gitlab-ci.yml # GitLab OIDC による IAM ロール引き受け
└── ssm-git-pull.gitlab-ci.yml     # SSM を使って EC2 に git pull 実行
```

## 3. テンプレート定義ファイルの中身

### `oidc-assume-role` テンプレート

```yaml
.oidc-assume-role:
  image:
    name: amazon/aws-cli:latest
    entrypoint: [""]
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.com
  before_script:
    - |
      export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" \
        $(aws sts assume-role-with-web-identity \
          --role-arn "${ROLE_ARN}" \
          --role-session-name "GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}" \
          --web-identity-token "${GITLAB_OIDC_TOKEN}" \
          --duration-seconds 3600 \
          --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
          --output text))
```
[AWSでのOIDC(Open ID Connect)の設定に関する参考記事](https://gitlab-docs.creationline.com/ee/ci/cloud_services/aws/)

### `ssm-git-pull` テンプレート
```yaml
.ssm-git-pull:
  extends: .oidc-assume-role
  script:
    - |
      aws ssm send-command \
        --document-name "AWS-RunShellScript" \
        --instance-ids $EC2_INSTANCE_ID \
        --comment "$COMMENT" \
        --parameters commands=["cd $DIR_PATH && git switch $BRANCH && git pull"] \
        --region $REGION \
        --output text
```
[AWS CLIでSendCommandを使用する参考記事]()

## 4. 実際に使うプロジェクト側の .gitlab-ci.yml
```yaml
include:
  - project: your-group/ci-templates
    file: gitlab-ci-templates/oidc-assume-role.gitlab-ci.yml
    ref: v1.0.0
  - project: your-group/ci-templates
    file: gitlab-ci-templates/ssm-git-pull.gitlab-ci.yml
    ref: v1.0.0

deploy-ec2:
  extends: .ssm-git-pull
  stage: deploy
  variables:
    ROLE_ARN: "arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
    REGION: "ap-northeast-1"
    EC2_INSTANCE_ID: "i-xxxxxxxxxxxxxxxxx"
    DIR_PATH: "/var/www/html"
    BRANCH: "main"
    COMMENT: "Git pull from CI"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
```

## 5. 運用のコツ
- テンプレートを変更したら ref: を bump（例: v1.0.1）
- 本番・開発で異なる変数を使う場合は rules + variables で切替
- 共通テンプレートは専用の GitLab リポジトリで管理する

## 6. その他の応用例
- Slack 通知
- S3 バケットへのファイルアップロード
- Lambda 実行
- ECS / EKS デプロイ
- Datadog ログ送信
どれもテンプレート化することで CI 設計が楽になります。

## まとめ
CI/CD のテンプレート化は、単なる効率化にとどまらず、品質統一・セキュリティ強化・メンテナンス性向上に直結します。
チームや組織で共通するジョブが増えてきたと感じたら、ぜひテンプレート化を検討してみてください！
【ABC408】D問題 - Flip to Gather　考察から実装(c++)まで

AtCoderBeginnerContest408の解説＆感想です。
[コンテストリンク](https://atcoder.jp/contests/abc408)

# 問題一覧
- [【ABC408】A問題 - Timeout　考察から実装(c++)まで](https://qiita.com/hoppii007/items/8fc75600a5fce528db17)
- [【ABC408】B問題 - Compression　考察から実装(c++)まで](https://qiita.com/hoppii007/items/543c54697f49edde711e)
- [【ABC408】C問題 - Not All Covered　考察から実装(c++)まで](https://qiita.com/hoppii007/items/36b35d668d5c5143e7d5)
- 【ABC408】D問題 - Flip to Gather　考察から実装(c++)まで <- イマココ
- [【ABC408】E問題 - Minimum OR Path　考察から実装(c++)まで](https://qiita.com/hoppii007/items/87c7215b01e27f6a24c5)
- [【ABC408】F問題 - Athletic　考察から実装(c++)まで](https://qiita.com/hoppii007/items/7d504c0a17d98ad4a268)

# D問題 - Flip to Gather
[問題リンク](https://atcoder.jp/contests/abc408/tasks/abc408_d)

## 問題概要
長さ$N$の```0```と```1```からなる文字列$S$が与えられる。
- 任意の場所の```0,1```を反転させる

という操作を好きなだけ行い、**```1```が連続する区間を高々1つ**にしたい時、最小の操作回数を求めよ。
$T$個のテストケースにそれぞれ答えよ。

### 制約
- $ 1 \le T \le 2 \times 10^4 $
- $ 1 \le N \le 2 \times 10^5 $
- $ 各テストケースのNの総和は2 \times 10^5以下 $

## 考察
貪欲にやろうと思って、うんうん唸ってたけど全然思いつかず時間を溶かす。
大きい方向転換が必要だと思い、解法ローラーで「DPで行くぞ！」と決めたら割とすぐに思いついた。

$i$番目を```0```にするか```1```にするか考えるんだけど、素直に
- $dp[i][j] := i番目まで見て、i番目をjにした時の最小操作回数$

とするとだいたい良さそう。
「だいたい」と言うのは、$i-1$番目が```0```だったとして、$i$番目を```1```にするかどうかは、「今までに```1```の島があったかどうか？」によるから。

$i-1$番目が```0```だったとしても、今までにすでに```1```の島があったなら$i$番目を```1```にはできないし、```1```の島がまだないなら$i$番目を```1```にしたっていい。

まとめると、
- $dp[i][j][k] := i番目まで見て、i番目をjにして、$
    - $今までが全て0の時の最小操作回数 \ (k==0) $
    - $すでに1の島があるの時の最小操作回数 \ (k==1)$

とすればいい。

遷移は
- 今見てる場所を```1```にして、1の島がすでにある状態にするには、今回を最初の```1```にするか、前回まで続いていた島を引き継ぐかのどちらか。

$ dp[i][1][1] = min(dp[i-1][0][0], dp[i-1][1][1])+(S[i] \ != \ 1) $

- 今見ている場所を```0```にしてすでに```1```の島があった状態にするには、一つ前まで続いていた島をちょん切るか、2つ以上前に作った島の時の最小を引き継ぐか。

$ dp[i][0][1] = min(dp[i-1][1][1], dp[i-1][0][1])+(S[i] \ != \ 0) $

- 今見ている場所を```0```にして、全部```0```にするには、今までも全部```0```だったところから来るしかない

$ dp[i][0][0] = dp[i-1][0][0] + (S[i] \ != \ 0) $

## 実装
```cpp
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using vll = vector<long long>;
using vvll = vector<vll>;
using vvvll = vector<vvll>;

const ll inf = 1000000000000000000LL;

int solve(){
    //入力
    ll N;
    string S;
    cin>>N>>S;
    
    //はじめは全てクソデカコストで初期化
    vvvll dp(N, vvll(2, vll(2, inf)));
    
    //dp[0]は丁寧に初期化(番兵とか上手く使えばもっと綺麗にできそう)
    if(S[0] == '0'){
        dp[0][0][0] = 0;
        dp[0][1][1] = 1;
    }
    else {
        dp[0][0][0] = 1;
        dp[0][1][1] = 0;
    }
    
    for(int i=1;i<N;i++){
        dp[i][1][1] = min(dp[i-1][0][0], dp[i-1][1][1]) + (S[i] != '1');
        dp[i][0][1] = min(dp[i-1][1][1], dp[i-1][0][1]) + (S[i] != '0');
        dp[i][0][0] = dp[i-1][0][0] + (S[i] != '0');
    }
    
    //N-1番目の状態としてあり得る全パターンの中で最小が答え
    cout<<min({dp[N-1][1][1], dp[N-1][0][1], dp[N-1][0][0]})<<endl;
    return 0;
}

int main(void){
    ll T;
    cin>>T;
    while(T--) solve();
    return 0;
}
```
【ABC408】C問題 - Not All Covered　考察から実装(c++)まで

AtCoderBeginnerContest408の解説＆感想です。
[コンテストリンク](https://atcoder.jp/contests/abc408)

# 問題一覧
- [【ABC408】A問題 - Timeout　考察から実装(c++)まで](https://qiita.com/hoppii007/items/8fc75600a5fce528db17)
- [【ABC408】B問題 - Compression　考察から実装(c++)まで](https://qiita.com/hoppii007/items/543c54697f49edde711e)
- 【ABC408】C問題 - Not All Covered　考察から実装(c++)まで <- イマココ
- [【ABC408】D問題 - Flip to Gather　考察から実装(c++)まで](https://qiita.com/hoppii007/items/b5763b69e1bd673109b9)
- [【ABC408】E問題 - Minimum OR Path　考察から実装(c++)まで](https://qiita.com/hoppii007/items/87c7215b01e27f6a24c5)
- [【ABC408】F問題 - Athletic　考察から実装(c++)まで](https://qiita.com/hoppii007/items/7d504c0a17d98ad4a268)

# C問題 - Not All Covered
[問題リンク](https://atcoder.jp/contests/abc408/tasks/abc408_c)

## 問題概要
$1$から$N$まで番号付けられた$N$個の城壁と、$M$個の砲台がある。砲台$i$は城壁$L_i$から$R_i$を守っている。
どの砲台にも守られていない城壁ができるまでには、最小でいくつの砲台を壊す必要があるか？

### 制約
- $ 1 \le N \le 10^6 $
- $ 1 \le M \le 2 \times 10^5 $
- $ 1 \le L_i \le R_i \le N $

## 考察
愚直解はかなり素直に考えればよくて、各城壁についてそこを守っている砲台の数を出して、その中の最小値を求めればいい。
「区間$(L_i, R_i)$全てを+1する」という処理を$M$回やればいいけど、愚直にやると$O(NM)$となり間に合わない。これをどう高速化しますかという問題。

「区間に定数を足す」というのは典型で、**imos法**で高速化できる。
計算量は$O(N+M)$

## 実装
```cpp
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using vll = vector<long long>;
int main(void){
    //入力
    ll N,M;
    cin>>N>>M;
    
    vll imos(N+1,0);
    for(int i=0;i<M;i++){
        ll L,R;
        cin>>L>>R;
        //L-1番目 ~ R-1番目に+1したい
        imos[L-1]++;
        imos[R]--;
    }
    for(int i=0;i<N;i++) imos[i+1] += imos[i];
    
    //0番目からN-1番目の中で、一番小さいところを表示
    cout<<*min_element(imos.begin(), imos.end()-1)<<endl;
    return 0;
}
```
【ABC408】B問題 - Compression　考察から実装(c++)まで

AtCoderBeginnerContest408の解説＆感想です。
[コンテストリンク](https://atcoder.jp/contests/abc408)

# 問題一覧
- [【ABC408】A問題 - Timeout　考察から実装(c++)まで](https://qiita.com/hoppii007/items/8fc75600a5fce528db17)
- 【ABC408】B問題 - Compression　考察から実装(c++)まで <- イマココ
- [【ABC408】C問題 - Not All Covered　考察から実装(c++)まで](https://qiita.com/hoppii007/items/36b35d668d5c5143e7d5)
- [【ABC408】D問題 - Flip to Gather　考察から実装(c++)まで](https://qiita.com/hoppii007/items/b5763b69e1bd673109b9)
- [【ABC408】E問題 - Minimum OR Path　考察から実装(c++)まで](https://qiita.com/hoppii007/items/87c7215b01e27f6a24c5)
- [【ABC408】F問題 - Athletic　考察から実装(c++)まで](https://qiita.com/hoppii007/items/7d504c0a17d98ad4a268)

# B問題 - Compression
[問題リンク](https://atcoder.jp/contests/abc408/tasks/abc408_b)

## 問題概要
長さ$N$の数列$A=(A_1,A_2,...,A_N)$が入力される。重複を除いて小さい順に出力せよ。

### 制約
- $ 1 \le N \le 100 $
- $ 1 \le A_i \le 100 $

## 考察
「重複削除」「小さい順」はどっちも標準ライブラリの```set```の得意技なので、$A$の要素を全部```set```に突っ込んで表示すれば良さそう。
c++なら```vector```に入れていって```sort```して```unique+erase```でも良さそう。どっちも実装しておこう。
計算量はどちらも$O(NlogN)$


## 実装 (set ver)
```cpp
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using vll = vector<ll>;

int main(void){
    //入力
    ll N;
    cin>>N;
    
    //入力を全部setにぶち込む
    set<ll> s;
    for(int i=0;i<N;i++){
        ll a;
        cin>>a;
        s.insert(a);
    }
    
    //setの要素を表示していく
    cout<<s.size()<<endl;
    for(ll t: s) cout<<t<<" ";
    return 0;
}
```

## 実装（unique+erase ver）
```cpp
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using vll = vector<ll>;

int main(void){
    //入力
    ll N;
    cin>>N;
    
    //入力を全部setにぶち込む
    vll a(N);
    for(int i=0;i<N;i++) cin>>a[i];
    
    //unique+eraseで重複を全部削除する
    sort(a.begin(),a.end());
    a.erase(unique(a.begin(), a.end()), a.end());
    
    //aの要素を表示していく
    cout<<a.size()<<endl;
    for(ll t: a) cout<<t<<" ";
    return 0;
}

```
【ABC408】A問題 - Timeout　考察から実装(c++)まで

AtCoderBeginnerContest408の解説＆感想です。
[コンテストリンク](https://atcoder.jp/contests/abc408)

# 問題一覧
- 【ABC408】A問題 - Timeout　考察から実装(c++)まで <- イマココ
- [【ABC408】B問題 - Compression　考察から実装(c++)まで](https://qiita.com/hoppii007/items/543c54697f49edde711e)
- [【ABC408】C問題 - Not All Covered　考察から実装(c++)まで](https://qiita.com/hoppii007/items/36b35d668d5c5143e7d5)
- [【ABC408】D問題 - Flip to Gather　考察から実装(c++)まで](https://qiita.com/hoppii007/items/b5763b69e1bd673109b9)
- [【ABC408】E問題 - Minimum OR Path　考察から実装(c++)まで](https://qiita.com/hoppii007/items/87c7215b01e27f6a24c5)
- [【ABC408】F問題 - Athletic　考察から実装(c++)まで](https://qiita.com/hoppii007/items/7d504c0a17d98ad4a268)

# A問題 - Timeout
[問題リンク](https://atcoder.jp/contests/abc408/tasks/abc408_a)

## 問題概要
単調増加な自然数列$T=(T_1,T_2,...,T_N)$が与えられる。
$T_0=0$として、$T_i + S \lt T_{i+1}$となる場所があるか判定せよ。

### 制約
- $ 1 \le N,S \le 100 $
- $ 1 \le T_i \le 1000 $
- $ T_i < T_{i+1} $

## 考察
問題文の読解がちょっと難しいけど、問題概要くらいまで簡略化したら解きやすそう。
隣り合う二つで条件を満たす場所が欲しいので、```adjacent_find```が使えそう。
計算量は$O(N)$

## 実装
```cpp
#include <bits/stdc++.h>
using namespace std;
using ll = long long;
using vll = vector<ll>;

int main(void){
    //入力
    ll N,S;
    cin>>N>>S;
    
    vll T(N+1,0);
    for(int i=1;i<=N;i++) cin>>T[i];
    
    //Tの中で、初めてT[i] +S < T[i+1]となるインデックスを取得
    ll idx = adjacent_find(T.begin(), T.end(), [&](ll a, ll b){ return a+S < b; }) - T.begin();
    cout<<(idx==N+1?"Yes":"No")<<endl;
    return 0;
}
```
W55RP20-EVB-Picoを使ってみよう～Arduino編～

W55RP20-EVB-PicoをArduinoで使ってみましょう。

https://maker.wiznet.io/mason/projects/how-to-build-w55rp20-evb-pico-on-arduino/?serob=rt&serterm=year
# ボード設定
Arduinoを起動し、__ファイル→基本設定__
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/710f68b7-c289-41e2-b53b-11e62042d761.png)

__追加のボードマネージャのURL：__

    https://github.com/earlephilhower/arduino-pico.git
を入力し、OKをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/587ed8c2-866c-45b9-a521-b7d51ca6b991.png)
ツール⇒ボード⇒ボードマネージャ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/d80b49a0-a5ac-4fe0-878e-26191c2a1003.png)
Wiznetと入力し、Raspberry Pi Pico/RP2040/RP2350のインストールをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/c4875b0f-5080-4fb4-bf38-e9f4fee6dae8.png)

# ボード指定
ボードを選択をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/ebc1abed-74ec-4b48-8a94-c66848ff09c6.png)
ボード WIZnet W5500-EVB-Pico　ポートは接続されているポートを指定し、OKをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/883d5412-fb41-4bfd-9fdb-ec432d3c603d.png)
ファイル⇒スケッチ例⇒lwp_w55rp20⇒WiFiClient-W55RP20を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/ea400d86-2b3d-4b14-8c6f-0897626e96d8.png)
⇒でビルドして実行します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/02da1be3-3ace-419d-b471-b47af7b12506.png)
シリアルモニタにIPアドレスが表示されたら完了です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/285344/442c0f97-5f7f-43bd-8f83-94bc60667621.png)
JavaScriptの特殊な配列のお話


## はじめに

本格的にJavaScriptでロジックを書く機会が増えて、「配列」と出会う機会が増えました。  
困ったことにJavaScriptでは単なる配列のみならず、「配列ライク」や「反復可能なオブジェクト」といったものが存在し、その種類によって実行可能な制御文やメソッドが異なります。

この記事では配列・配列ライク・反復可能なオブジェクトを基本的な概念から順に紐解き、それぞれの特徴や違いについて説明します。

:::note info
information
この記事ではそれぞれの特徴や関係性を中心に説明するため、対応するメソッドなどの詳細な説明は省略します。
:::

## 目的

- 複数要素を格納・操作するオブジェクトにも種類があり、その違いを理解する
- それぞれの特徴を理解した上で最適な実装アプローチを目指す

## 対象者

- JavaScript初学者
- 「`forEach()`でまわせない！なんで？」と悩んでいる方

## 1. 配列リテラルとオブジェクトリテラル

ますは基本的なデータ型からの説明です（説明不要の方は読み飛ばしてください）。  
JavaScriptのデータ型は大きく基本型（プリミティブ型）と参照型（構造型）に分けられます。その中で、参照型に属する`配列リテラル`と`オブジェクトリテラル`がいわゆる"配列"として扱うことができます。

JavaScriptのオブジェクトリテラルは**連想配列**と同一の概念であり、他言語では**ハッシュ**と呼ばれたりもします。配列の観点において両者は以下の違いがあります。

| データ型 | 特徴 |
|:-|:-|
| 配列 | ・個々のデータ = "値" <br> ・キーはindex番号 <br> ・順序を保証する |
| オブジェクト <br> （連想配列） | ・個々のデータ = "プロパティ" <br> ・文字列をキーとしてアクセス可能 <br> ・順序は保証しない |

「スタック」や「キュー」などのデータ取得処理や`map`や`filter`メソッドを用いた順序あるリストを想定した処理は配列のみ可能です。

データ型を見ると配列と連想配列が区別されていることがわかりました。

## オブジェクトの概念

続いてJavaScript上のオブジェクトの概念です。  
「オブジェクト」という単語には狭義/広義的の2種類の意味で使用されます。

|  | 特徴 |
|:-|:-|
| 狭義 | ・実装的な視点。いわゆる連想配列（ハッシュ）としての意味 |
| 広義 | ・オブジェクト自体を一つの"モノ"として扱う |

広義的に扱うオブジェクトとはオブジェクト指向に通ずる概念です。  
以降の説明ではデータ型としてのオブジェクトを"連想配列"と呼び、オブジェクトと区別して扱います。

### 反復可能なオブジェクト

`Array`や`String`, `Map`, `Set`など、配列リテラルでなくても配下の要素を列挙できるオブジェクト = **反復可能なオブジェクト**があります。例えば`for...of`命令での反復処理が可能なのは、それらのオブジェクトが規定で**イテレーター**を備えているからです。
イテレーターの説明については割愛しますが、内部的に`[Symbol.iterator]`メソッドを持つことが条件となります。

> ▼ MDNより
> 反復可能であるために、オブジェクトは \[Symbol.iterator\]() メソッドを実装する必要があります。これはつまり、オブジェクト（または、プロトタイプチェーン上のオブジェクトの一つ）が\[Symbol.iterator\]キー（Symbol.iterator 定数にて利用可）のプロパティを持つ必要があります。

[イテレーターとジェネレーター
](https://developer.mozilla.org/ja/docs/Web/JavaScript/Guide/Iterators_and_generators)

留意すべきは**配列リテラルもイテレーターを備えている**（から要素を列挙できる）ことです。

### 配列ライクなオブジェクト
「配列のようで配列ではない、けど一部配列と同じ処理ができる」ものをしばしば配列ライクなオブジェクトと呼びます。

- `length`プロパティを持っていること
- `0`から`length - 1`までの添字つき要素を持つこと

DOMオブジェクトである`NodeList`や`HTMLCollection`、引数情報を管理する`arguments`などのオブジェクトは配列ライクなオブジェクトになります。注意すべきは、**配列ライクなオブジェクトにはイテレーターをもつものともたないものがある**ことです。
配列・反復可能なオブジェクト・配列ライクなオブジェクトの関係をベン図で表すと以下の通りになります。

<img width="400px" alt="explain_relation.jpg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3828182/7f9776ab-467b-4698-bd4c-6b0206d1db8a.jpeg" />

反復可能なオブジェクトに対して部分集合の関係をとり、それ故一部利用できない配列用のメソッドがある場合があります（利用できる配列ライクなオブジェクトも存在するのでどうしても曖昧な説明になりますね）。

## まとめ

JavaScriptにおいて、複数要素を格納・操作するオブジェクトにいくつか種類があり、以下の順序で考えると整理できました。

1. データ型の配列リテラルとオブジェクトリテラルの存在
2. 「オブジェクト」指向の概念 => 連想配列とオブジェクトの分離
3. オブジェクトの中には反復可能なオブジェクトがある => イテレーターの有無で判断
4. 配列ライクなオブジェクト => 反復可能なオブジェクトに対して部分集合の関係

あとは実際に手を動かして慣れること、ですね！
【Mac】コマンドでQRコードを生成する方法

## qrencodeをインストール

以下のコマンドで`qrencode`をインストールする。

```terminal
brew install qrencode
```

## qrencodeの使い方

文字列をQRコードに変換してファイルに保存する。

```terminal
qrencode -o path/to/output_file.png 'string'
```

入力ファイルをQRコードに変換し、ファイルに保存する。

```terminal
qrencode -o path/to/output_file.png -r path/to/input_file
```

文字列をQRコードに変換してターミナルに表示する。

```terminal
qrencode -t ansiutf8 'string'
```

パイプからの入力をQRコードに変換してターミナルに表示する。

```terminal
echo 'string' | qrencode -t ansiutf8
```
【Python】pandasのread_csvメソッド

read_csvメソッドは多数の引数が用意されています。例えば引数「header」でカラム名として使う行番号を指定したり、引数「index_col」でインデックス名として使う列番号を指定することができます。

次のCSVファイルで、先頭行をカラム名に指定し、先頭列をインデックス名に指定する場合を考えます。

sample.csv
-------------------------------
,A列,B列,C列
1行,1,2,3
2行,4,5,6
3行,7,8,9
-------------------------------

df = pd.read_csv('sample.csv')
▶︎
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/1f501d8c-2cb2-4641-a6e3-12972a0218bb.png)


引数がない場合、先頭行がカラム名になり、インデックス名は連番が付与されます。引数で「header=None」とすると、カラム名も連番が付与されます。


df = pd.read_csv('sample.csv', index_col=0)
▶︎
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/56e3875e-e402-4012-b7fe-0f41cc497f46.png)


引数「index_col=0」で、先頭列をインデックス名にするよう指定しています。
cliborについて



### 整形
```clibor:連続した改行を削除
(\r\n)+
->
\r\n
```

```clibor:改行をパイプに置換
\r\n
->
|
```


### 定型
```clibor:FIFOモード
<$CLB_TFIFO/>
```

```clibor:yyyy/mm/dd hh:mm 
<$CLB_HDATE>yyyy/mm/dd hh:mm </CLB_HDATE>
```

```clibor:X きかん検索クエリ
since:<$CLB_HDATE><$CLB_INCDAY>-3</CLB_INCDAY>yyyy-mm-dd</CLB_HDATE> until:<$CLB_HDATE><$CLB_INCDAY>1</CLB_INCDAY>yyyy-mm-dd</CLB_HDATE> 
```

```clibor:

```
🚀 なぜ見積もり通りに進まないのか？遅延ゼロを目指すための7つの秘訣＋実用テンプレート付き！

# はじめに

プロジェクトにおいて「予定通りに終わる」は理想ですが、実際には**見積もり通りに行かない＝遅延する**ことが少なくありません。
この記事ではその原因と、今日から実践できる「遅延しないための対策」をわかりやすく解説し、**見積もりテンプレート**もご紹介します。

---

## 🔍 なぜ遅延は起きるのか？見積もりがズレる4つの理由

### 📌 1. 希望的観測で見積もっている

* 経験上「前はこれくらいだったから今回も」という思い込み。
* 特に新規開発や初めての技術には危険です。

### 📌 2. 作業範囲を正確に把握できていない

* 要件定義が曖昧だったり、実装対象があいまいなまま始めてしまう。
* 後から「あれも必要だった」と追加工数が発生。

### 📌 3. リスクを見込んでいない

* 技術的な不確実性、仕様変更、人員変更など「予想外」が発生。
* 予備の時間（バッファ）が無ければ即遅延。

### 📌 4. 見積もりにチーム全体の視点がない

* 一人の感覚だけで見積もると、他のメンバーの得手不得手や稼働状況を考慮できない。

---

## 🛠 遅延しないための7つの実践ポイント

### ✅ 1. タスクは細かく分割する

* 見積もり精度UPと進捗の可視化に効果的。
* 例：「API実装」→「ルーティング定義」「コントローラ作成」「DB接続処理」

### ✅ 2. 見積もりは「最悪パターン」も考慮

* 楽観パターン／通常パターン／最悪パターンの3段階で工数を想定。
* それぞれに確率をかけて「期待値」を出す方法も有効。

### ✅ 3. 調査タスクを明示して確保する

* 「わからないけど多分大丈夫」はNG。
* まずは調査→把握→見積もりの流れで安全運転。

### ✅ 4. 実績と比較し続ける

* スプリントや週単位で「見積もりと実績の差」をレビュー。
* 定期的な見直しで精度を高めるサイクルを作る。

### ✅ 5. 作業工数＋確認・レビュー工数も含める

* 実装時間しか入れていないケースが多い。
* コードレビュー・単体テスト・ドキュメント更新なども忘れずに。

### ✅ 6. チーム全体で見積もりをすり合わせる

* プランニングポーカーやレビューで複数人の視点を活かす。
* 「そのやり方なら3日じゃ無理だよ」など気づきが得られる。

### ✅ 7. バッファ時間を組み込む

* 見積もり全体の10〜20%をバッファとして確保。
* 変更対応、予期せぬ遅れに対応可能。

---

## 📄 実用テンプレート：簡易見積もりシート（Markdown形式）

```markdown
# 📋 見積もりテンプレート

## 概要
- プロジェクト名：〇〇システム開発
- 担当者：山田太郎
- 作成日：2025-06-22

## タスク一覧

| タスク名               | 説明                       | 担当者 | 工数（人日） | 状態 | 備考       |
|------------------------|----------------------------|--------|---------------|------|------------|
| 要件整理               | ヒアリング・要件の洗い出し | 山田   | 1             | 済   |            |
| 認証API設計            | パラメータ・レスポンス定義 | 田中   | 1             | 未   | POSTのみ  |
| 認証API実装            | ロジック・DBアクセス       | 田中   | 2             | 未   |            |
| 単体テスト              | テストコード作成           | 鈴木   | 1             | 未   |            |
| コードレビュー         | 他メンバーによる確認       | 山田   | 0.5           | 未   |            |

## バッファ設定
- 想定リスク：仕様変更、新人参加、データ遅延など
- バッファ工数：合計見積もりの15%（例：6人日 × 0.15 = 0.9人日）

## 合計工数
- 作業合計：6人日
- バッファ：0.9人日
- 合計：6.9人日（切り上げで7人日）
```

---

## ✅ チェックリスト：あなたの見積もりは大丈夫？

| チェック項目                 | YES/NO |
| ---------------------- | ------ |
| タスクを分割して工数を見積もっているか？   |        |
| 調査タスクを事前に明記しているか？      |        |
| 最悪パターンの工数も考慮しているか？     |        |
| バッファ時間を確保しているか？        |        |
| 見積もりにレビューやテストの時間も含めたか？ |        |
| チームでのレビューを行っているか？      |        |

---

## ✏️ 最後に：見積もりは「精度を上げる努力」と「余白を持つ設計」

遅延は仕方ない部分もありますが、**準備と見直しの習慣で確実に減らせます**。
この記事で紹介したテンプレートと7つの対策を、ぜひ次のプロジェクトから試してみてください。
Edge-to-edge対応していたらstyle設定が意外に大事だった

# 概要

先日やっとEdge-to-edgeの対応を一旦終えました。

自分のアプリでは結構`setStatusBarColor`によってステータスバーを動的に変えている部分が複数あったのですが、こちらもAndroid15以降では無効になったので対応が必要でした。

# 実装

私のアプリではapplicationレベルで以下のテーマを設定していました。

```styles.xml
    <style name="MyTheme" parent="Theme.MaterialComponents.Light.NoActionBar">
        <item name="colorPrimary">@color/WHITE</item>
        <item name="colorPrimaryDark">@color/BLUE</item>
        <item name="android:actionMenuTextColor">@color/WHITE</item>
    </style>
```

上記によってステータスバー部分が青、文字が白くなっていました。
これを全体で適用して、APPバーの色をBLUE以外にする必要があれば`setStatusBarColor`を使用してステータスバーもその色に合わせ、ステータスバーとAPPバーが一体になっているように見えるという形です。

ただ`setStatusBarColor`が廃止されたので、Activityごとに設定する形に変更しました。

MyThemeを継承したテーマを必要な色の分作ります。

```styles.xml
    <style name="GreenStyle" parent="MyTheme">
        <item name="colorPrimaryDark">@color/GREEN</item>
    </style>

    <style name="PurpleStyle" parent="MyTheme">
        <item name="colorPrimaryDark">@color/PURPLE</item>
    </style>
```

そして、これを必要なActivityに対して適用します。

```AndroidManifest.xml
        <activity
            android:name="..."
            android:theme="@style/PurpleStyle" />
```

私のこのアプリはマルチアクティビティかつ、それぞれのアクティビティのまとまりごとに色使いが結構はっきり分かれているので、このやり方は理にかなっているように思いました。

以上です。
Figma初心者が挑戦！タンパク質記録アプリのUIデザイン初期設計と学びの記録

![Screenshot 2025-06-22 at 17.01.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924737/739e6c50-bd62-4c2a-a192-4d1aa2cef01a.png)


皆さん、こんにちは。現在UI/UXデザインとiOS開発を学習中の私が、最初のプロジェクトとして取り組んでいるシンプルなタンパク質記録アプリについて、ここまでの道のりを共有したいと思います。

なぜこのアプリを作ろうと思ったか：トラッキングのシンプルさを求めて

フィットネスに関心のある多くの方と同じように、既存のカロリー・マクロ管理アプリ（MyFitnessPalなど）は機能が豊富すぎる反面、時に情報過多で圧倒されると感じていました。私のニーズはもっと単純で、「日々のタンパク質摂取量を、他の多くの指標に惑わされることなく素早く記録したい」というものでした。この効率化された体験への渇望が、このプロジェクトの原動力となりました。

初期デザインコンセプトとFigmaでの学び

初期のデザインコンセプトは、主に2つの「モード」を中心に展開しました。新しいタンパク質を入力するための「追加モード」と、日々の目標達成までにあとどれくらいタンパク質が必要かを確認する「減算モード」です。小学生が算数の計算をするような、明確で計算的なインターフェースを思い描いていました。演算記号を切り替えることで状態を変化させるアイデアでした。また、入力のための仮想キーボードが操作画面を邪魔しないように、クリック可能な「履歴 (History)」や「お気に入り (Favorite)」タブ（これらも一種の入力手段です）と位置的に密接に連携させることも考えました。そして、正直に言うと、現状では私のお気に入りのアプリ「Strong」のキーボードのスクリーンショットを一時的なプレースホルダーとして使用しています。

初めてFigmaに触れたのはまさに冒険でした！モダンでエレガントなツールが大好きです！以下は、私がこれまでに培ってきた主要なスキルです。

レイヤー構成と命名規則: やや雑然としていたレイヤーパネルから、セクション分けにフレームを活用し、記述的な命名規則（例: Text / Label / Goal, Component / History List Item）を採用することで、より構造化されたアプローチへと移行し、明瞭性が格段に向上しました。

![example.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924737/0240bbea-8f5c-4ebd-a456-62d5a2c10548.png)

コンポーネントベースのデザイン: リストアイテムやおそらくタブボタンのような再利用可能な要素に対して、コンポーネントの力を実感したのは「アハ体験」でした。インスタンス を使用することで、既に時間を節約し、一貫性を確保できています。

![components.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3924737/8dd4dc0a-ba3a-4f25-b972-00ac65b741aa.png)

Auto Layoutとの最初の出会い: Auto Layoutの探求を始め、方向、間隔、配置について学びました。これは間違いなく強力なツールですが、子要素のサイズ変更動作（Hug contents, Fill container, Fixed width/height）が最終的なレイアウトにどう影響するかを掴むのにはまだ苦労しています。時々、要素が少しごちゃ混ぜになってしまうこともありましたが、今では基本的に期待通りに動作させることができるようになりました。

デザイン原則とUXの課題についての考察

この初期デザインフェーズは、Figmaの使い方だけでなく、ユーザーについて考える上で非常に大きな学習体験となりました。

可読性の探求: 現状のモックアップに対する自己批判の最大のものは可読性です。主要な数値（目標、摂取済み、残り必要量）の表示方法が、特にモード間で同じ位置の数値が異なる意味を持つ場合、ユーザーが素早く理解するには認知的負荷が高すぎるかもしれないことに気づきました。
モードの明確性: 「追加」モードと「集計」モードを区別するために色（赤/緑）を使ってみましたが、十分に明確でなく、アクセシビリティの問題もあるかもしれないと懸念しています。モード切り替えという概念自体が、簡略化の余地があるかもしれません。
反復型デザインの重要性: これまでの最大の学びは、デザインは真に反復的なプロセスであるということです。最初のバージョンを完成させた直後は、正直かなりがっかりしました。自分で作ったアプリなのに、画面上のデータを読み解きたくないとさえ思ったのです！でも、まあ、それならそれで、ここ数日の努力を最大限に活かそうと思い直し、全てを公に投稿することに決めました。そうです、最初のバージョンが完璧でなくても、あるいはその瞬間には「完全な失敗」に見えたとしても、全く問題ないのだと信じています。なぜなら、最も重要なのは「ついに始めた！」ということだからです。これらの課題を発見すること自体が、より良い解決策への道のりの一部なのです。

現在の課題と次のステップ

現在、明確さと使いやすさを優先するために、主要な情報表示とモードのインタラクションを再考する必要があると感じています。「加算/減算」という計算フレームワークに初期段階で焦点を当てすぎたために、瞬間的な可読性という主要なニーズが見過ごされてしまったのかもしれません。

では、次は何をするか？

コアUIの反復改善: メイン画面の代替レイアウトを探求し、複雑なモード切り替えなしに「残り必要量」と「摂取済み」の数値を即座に分かりやすく表示することに焦点を当てます。
Figmaスキルの深化: Auto Layoutの練習を続け、これらの画面に命を吹き込むためにプロトタイピング (Prototyping) を学ぶ準備をします。
SwiftUIへの準備: もうすぐこれらのデザインをSwiftUIを使って機能するiOSアプリに落とし込めると思うと、非常にワクワクしています！
この Build in Public の旅は私にとって新しいものですが、進捗、つまづき、学びを共有していく所存です。同じく学習中の方や経験豊富なプロの方からのフィードバックやアドバイスがあれば、とても嬉しいです！

読んでいただきありがとうございました！
Kubernetes運用前に勉強していること基礎編03-04

# Kubernetes運用前に勉強していること基礎編03-04

> **注意**  
> 本記事の内容は個人的な勉強・備忘録を目的としており、勤務先や関係者とは一切関係ありません。

---

## はじめに

Kubernetesの本番環境での運用を始めるにあたり、個人で勉強している内容を整理した記事です。構築や運用に必要な知識、注意点、実践して学んだことを随時更新していきます。基礎編の想定読者はコンテナの知識があり、Kubernetesでコンテナ運用したいがどうすればいいかを迷っている人です。今回は前回の引き続きで、Kubernetesのリソースカテゴリを学ぶことを目的としています。

## 勉強中の主な内容

- 基礎編
  - クラウドネイティブとは
  - Kubernetesのアーキテクチャ概要
  - <font color="Red">Kubernetesのリソース（今回の話）</font>

# Service APIs

Service（サービス）リソースおよび関連するネットワークリソースは、Kubernetes上のアプリケーション間の通信や、外部からのアクセス経路を抽象化するためのものである。複数のPodを1つの論理的なサービスエンドポイントに束ねたり、ロードバランシングやサービスディスカバリを行う役割である。Kubernetesにおけるサービス周りの代表的リソースは次のとおりである。

* Service
  * ClusterIP
  * NodePort 
  * LoadBalancer
  * ExternalName
  *  Headless
* Ingress

サービス関連リソースはクラスタ内外の通信を管理するための抽象レイヤを提供し、動的に変化するPod群に対して安定したアクセス方法を確立している。以下、それぞれのリソースとその関係、ユースケースを解説する。

# 前提知識

サービスディスカバリーパターンはサービスを提供するインスタンスに対して、そのサービスの利用背がアクセスできる、安定したエンドポイントを提供する。サービス指向アーキテクチャにおいて、サービスプロバイダー（Pod）はそのサービス機能を提供するのに加えて、自身をサービスレジストリに登録する必要があり、サービスコンシューマーはそのサービスへ到達するためのレジストリ情報にアクセスできる。図はkubenetesによって登録と検索がお紺われているかを示している図である。

![サービスディスカバリーパターン01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3976553/cdccb2f0-97a0-4b2b-9453-676e59af7a12.png)


# Service

Serviceは、一連のPodに対するシングルなアクセスポイント（仮想IPとホスト名）を提供するKubernetesリソースである。通常、Serviceはラベルセレクタにより対象となるPod群（たとえばapp: frontendというラベルを持つ全Pod）を動的に紐づけ、その集合に対して仮想的なIPアドレス（ClusterIP）とDNS名を割り当てる。クラスター内部では、他のPodはそのClusterIPやDNS名を使ってサービスにアクセスすれば、背後にいる実Podへとリクエストがロードバランシングされる。要するに、ServiceはPodの集合に対するネットワークフロントエンドの役割である。これから、サービスの主な型（Type）と用途について説明する。

## ClusterIP

![サービスクラスタIP01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3976553/dd30ca62-4b5e-4c0f-823c-acc66b46746b.png)


デフォルトのタイプで、クラスター内部にのみ有効な仮想IP（ClusterIP）を付与する。サービス発見は自動登録されるDNS名（<サービス名>.<namespace>.svc.cluster.local）で行う。他のPodからはこのDNS名かClusterIP宛に通信すれば、Serviceが背後のPodにトラフィックを流れる。図のように内部的なサービスディスカバリーとして用いられるリソースである。

## NodePort

![ノードポートサービス01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3976553/b1500b57-8550-4c35-ae91-6bbfb96e8a19.png)


各ワーカーノードの特定ポート（30000-32767の範囲から割り当て）を開放し、そのポートへの通信をServiceに転送する。NodeのIP:NodePortでクラスター外からアクセス可能になるが、負荷分散はクライアント側で各ノードに振り分ける必要がある。シンプルな開発用途や、独自のロードバランサを別途配置する場合などに利用している。

## LoadBalancer

![ロードバランサーサービス01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3976553/08f2c9f0-c464-40a0-873a-73f66ba44ae9.png)


クラウドプロバイダ統合されたロードバランサをプロビジョンし、外部アクセスをServiceに流すためのタイプである。AWS EKSでは、このServiceを作成するとAWSのElastic Load Balancer (ELB)が自動的に割り当てられる。
結果として、インターネットからのアクセス用にAWS側のパブリックIPやDNS名を持つLB（クラシックロードバランサー）が用意され、受信した通信をクラスタ内の各Podに配分される。本番環境で外部公開する際によく使われる。

# 所感
kubenetesを運用するうえで、ネットワークトラブルで運用が難しいと聞く、今回のサービスについて説明しているが、本質的には一般的なネットワーク設計の知識を持っていれば、理解しやすいと思われる。今後、別記事でネットワークに対する記事も書いていきたいと思う。次の記事は引き続き、サービスの説明を行います。
2024年に発表された円周率の公式

# はじめに
https://arxiv.org/pdf/2401.05733

この論文Field theory expansions of string theory amplitudesの
pp.9のAPPENDIXに、ほんの少し書かれている円周率の公式についてのメモ記事です。
主に、収束率の速さを知りたいと思っています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/510257/d7218485-8322-446e-a0c3-e98e7ad0f014.png)

自動翻訳(式のn-1の位置は下付きが正しい)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/510257/011d2bd7-1b6b-49de-92ef-e72951696fc7.png)

λは複素数ですが、本記事では、エクセルのCOMPLEX関数では計算できなかったので、整数のみ試します。


# ポッホハマー記号

公式中の「n-1」が下付きで、後ろに点「・」が書いてあるのがそうです。
見たことありませんが、以下のような意味です。


| wolfram | 式 |
|:-:|:-:|
|Pochhammer[x,1]|x|
|Pochhammer[x,2]|x(x+1)|
|Pochhammer[x,3]|x(x+1)(x+2)|
|Pochhammer[x,4]|x(x+1)(x+2)(x+3)|
|Pochhammer[x,5]|x(x+1)(x+2)(x+3)(x+4)|


これをエクセルで実現するには、
```
=IF(Q4=0,1,PRODUCT(P4+ROW(INDIRECT("1:"&Q4))-1))
```
となり、P4セルの部分には、ポッホハマーのxに相当する値が入ります。
同様にQ4がポッホハマーの数字部分。

# 収束速度は？

λの取り方によって収束速度が変化します。

20項にしたとき「λ=10」で、小数点以下8桁。
この公式の中では、早く収束するパラーメータでした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/510257/da3999dd-9a65-4403-9f59-c74347fabb07.png)
(桁溢れ)

# 参考サイト

https://keisan.casio.jp/exec/user/1721737569
Sharepoint 内での移動を楽にする Navigator を bookmarklet で作ってみた

# 背景

情シだったころに、Sharepoint Site 内のいくつかのパスに移動するのが面倒なことがあった。
で、個別に bookmarklet 作ったりしてた。

ふと、まとめた方が便利じゃね？って思ったので作ってみた。

正直、情シ以外の人が使うイメージはあまりないけど・・まぁ、もしかしたら役立つかも？

同様に API Navigator も作る予定

# 動きのイメージ

1. bookmarklet 起動
1. フィルターするなりして目的のものを探す
1. 該当ページへ

![SharepointNavigator.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/120072/30fabcce-9bbe-4ea1-83b5-1d296f362d60.gif)

子サイトでも動くようにはしてみたけど、存在しないページなんかもあって、その辺は未対応

# 参考情報

url については、以下を参考にしました。

https://sharepointstuff.com/2021/03/30/useful-sharepoint-urls/

# 使ってみる場合

GitHub で公開してみたので、
以下から、Sharepoint Navigator を D&D でお気に入りバーへ

https://baku2san.github.io/bookmarklet-gallery/

# あとがき

情シ時代に気付いてたら実際に使ってフィードバックしてよいものにしていけたかもなぁ・・なんて
現状とこれから

## 初めまして、タクといいます！

今回、JISOUに入ることとなりました。新卒4年目のフロントエンドエンジニアで普段はエンタメ系のECサイトの運用の業務をしております。
## マンネリ化
これまでサイトを作ってきて、1年目から2年目の途中までは新しいことばかりでやりがいや楽しさを感じていたのですが、技術や経験の積み上げを感じなくなり始めていました。
2年目の後半や現在は場所異動し、大きなサイト構築やECサイトの不具合の修正など新しいこともやるようにはなりましたが、これからの自分の成長につながるイメージは持てませんでした。
## 将来のなりたい自分
3ヶ月後
まずは、Reactの基礎知識をしっかり固めて、記事投稿を完全に習慣化する。
6ヶ月後
記事投稿100個を達成。
ReactやNextで1人でウェブアプリケーションを1から作れるようになる。
1年後
課題やアウトプットをきっかけに案件を獲得できるようになる。

## 最後に
自分のキャリアが大きく変わるきっかけになる1年にします！よろしくお願いします！
Amazon Q CLIを使ってフォントの違和感を指摘するゲームを作成しました

## はじめに

Amazon Q CLIを使ったゲーム開発キャンペーンでTシャツがもらえるということで、AIとの協働で「フォント違和感ゲーム」を作ってみました。このゲームは、流れるてくる文書の中からフォントの違いを見つけてクリックするゲームです。2,3時間でゲームを完成させた開発過程を、5つのステップに分けて紹介します。なお著者はこのゲームで使われているHTML, CSS, javascriptに関する知識は全くありません。なので実装はすべてAmazon Qが行っています。

## Amazon Q CLIのインストール（WSL）

WSL環境でAmazon Q CLIをインストールします。詳細な手順は[公式ドキュメント](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html)を参照してください。インストールが終わっていればターミナルで `q` を打ち込めば対話形式で開発していくことができます。

## 🎯 Step 1: ゲームの構想の壁打ち、仕様の決定

「文字列の中の違和感があるフォントを指摘するゲーム」の開発をAIと会話しながら決定しました。最初は普段使っているpythonで開発を考えていましたがWebブラウザで動かしたかったため断念しています。

**策定された基本仕様：**
- ゲーム名：フォント違和感ゲーム
- コンセプト：文書内のフォント異変を発見するゲーム
- 技術：HTML + CSS + JavaScript
- ルール：制限時間内にフォントの違いを見つけてクリック


## 🛠️ Step 2: プロトタイプ開発

まずざっくりとプロトタイプをAIにつくってもらいます。作ってもらった機能は以下です。
- 文書のテンプレートのランダム生成
- 異なるフォントをランダムに紛れ込ませる仕組み（Noto Sans JP vs Noto Serif JP）
- クリックを判定するシステム

プロトタイプを触っているうちに以下の課題が見えたので追加で対応してもらいます。
- 全ての文書に必ず異変を配置（はじめは異なるフォントが入っていないパターンも用意していた）
- 異変文字への直接クリック方式を採用

---

## ✨ Step 3: 難易度の調整

基本的な箱はできたため、難易度を徐々に上げていくようにしました。当初は明朝体とゴシックを見分けるだけでしたが、デザイン書体のようなわかりやすいものから始めていくことにしました。
**難易度:**
- Easy：Noto Sans JP vs Courier New（等幅フォント）
- Normal：Noto Sans JP vs Noto Serif JP（ゴシック vs 明朝）
- Hard：Noto Sans JP（通常 vs 太字）

また、デザイン書体はより初級向けとして違いの分かりやすいフォントを選択するように変更しました

## 🍣 Step 4: ゲームシステムの変更

最初は無限にリトライができて、一定問題を解き終わるとクリアの仕組みでした。これを変更して時間内に何問とけるかというシステムに変更しました。またミスのペナルティは持ち時間が減る仕組みに変更しました
**新システム仕様：**
- 制限時間：60秒
- 誤答ペナルティ：-5秒
- レベルアップ：3正解ごと

また問題が流れるようなアニメーションの調整や、正解した時のポップなどの調整も行ないました。

## 🔧 Step 5: 完成とデプロイ

不要なファイルを削除してもらったり、コードに適切なコメントをつけてもらったりを行ってもらいました。
またS3で静的ホストするための手順についてまとめてもらいました(AWSの権限を渡すのは少し怖かったので手順書だけ作成してもらっていました)

## ゲームの内容

ゲーム画面はこんな感じで、違和感のある部分 `S` の部分をクリックしていきます

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413830/30e322f0-1713-4e82-97a5-d592d8c64634.png)

正解するとポップアップが出ます！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413830/92afb986-3109-4631-ab75-1a476a7a88c3.png)

間違えると怒られてペナルティで5秒減らされます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413830/af56e053-749c-4f23-9152-c69dd998421b.png)

最後にハイスコアが出ます

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1413830/3053a9cd-4788-4b5e-a91b-dc3f9cdd2d00.png)

## まとめ

ゲームや、関連する周辺知識が全くなくてもゲームを作成することができました！Agentを使ったコーディングが初めてだったので、次行うときに気を付けたいこととしては
- チャットで行われた内容は要約してログ用にファイルに記載してもらうようにAIに依頼する。セッションがきれると過去の履歴データが吹っ飛ぶので、その場合をログを読んでこれまでの流れを理解してもらう
- 〇〇の機能を戻してや、一つ前に戻しても完全に同じ状態に戻るとは限らないので、チャットのファイルのたびに `git commit` してもらうように依頼する。ひとつ前に戻してといわずに、ひとつ前のコミットに戻してというように依頼する
- できるだけ具体的に指示を行うようにする。例えばスタートボタンを削除してというとスタートボタンの要素だけが削除されてゲームを始めれないようになってしまう...
になります。AIに限らず人間とチームで開発しているときには気をつけないといけないことですね...
本業はゲーム作成ではなくSQL書いたりPython書いたりがメインですが、そちらでも利用できそうなので業務にAgentを使ってみようと思います！
標準出力からの文字列を置換、変換して表示する（tr、sed）

（自身の備忘録用です）

標準出力で文字列置換を行い表示する方法をいくつかメモ

## 置換したい文字数が同じ場合：tr
``tr '置換したい文字列' '置換後の文字列'`` で可能

以下はCSV形式の出力を例にしたもの（可読性のため行数をつけてます）
```
$ echo "c0","c1","c2" | tr ',' '\n' | nl
     1	c0
     2	c1
     3	c2
```
以下は任意の文字列を例にしたもの（可読性のため行数をつけてます）
```
$ echo aaabbbccc | tr 'bbb' '\n' | nl -ba
     1	aaa
     2	
     3	
     4	ccc
※空行をわかりやすくするためnlコマンドにオプションを付与
 -ba(全ての行に対して行番号を付ける)
```
aaaとcccの2行のみ出力されて欲しかったが想定と違う結果に。
マニュアルを見ると、置換したい文字列と置換後の文字列は同じ文字数の想定で使われる模様。
そのため置換したい文字列の方が長い場合は、溢れた文字数分、置換後の文字列で指定した最後の文字で変換されてしまう。
この場合改行文字のみ指定しているのでbbb1つずつ全て改行になってしまう。

## 任意の文字列を変換したい場合：sed
置換したい文字列と置換後の文字列の文字数が一致しない、任意の文字列で変換したい場合はsedが使える。

``sed 's/[置換したい文字列]/[置換後の文字列]/'`` で可能

```
$ echo aaabbbccc | sed 's/bbb/\n/' | nl
     1	aaa
     2	ccc
```
オンライン開発環境まとめ

自分のメイン機器がchromebookでlinuxを入れてないので色々なオンライン開発環境を使ってきました。そしてここでは自分か使ってきたオンライン開発環境を紹介します。

# [1.paiza.io](https://paiza.io/ja)
paizaはCやJava,Rubyなどの有名な32個のプログラミング言語が揃っていますが例えばDartやElixirなどの最近できた言語はありません。しかし下のようにタブサイズやテーマ、フォントサイズなどの見た目をとても変えやすいところがとても便利です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4046456/e61baa7b-68de-44cf-9bd8-c3044573cebe.png)

# [2.mycompiler](https://www.mycompiler.io/ja)
mycompilerはpaizaよりは少ない27言語ですが一般的に使われる言語は入っています。また、PythonやRでは下のようにグラフを表示できる機能もあります
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4046456/bd1cf786-f24b-4677-8ddb-a83764421f4c.png)

# [3.onecompiler](https://onecompiler.com/)
onecompilerはCやJavaはもちろん、BrainfuckやDartなど新しかったり珍しい言語も入っています。また、下の図から分かる通りWEB開発ができるHTMLやReactのエディターもあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4046456/bdda5f09-bc77-4360-9de7-a0d2722b5ce0.png)

# [4.Runstart](https://runstant.com/)
Runstantは、すぐにHTMLのコーディングができるサイトです。また、コンソールが画面に出ているためデバッグが簡単にできます

# [5.Replit](https://replit.com/~)
Replitはブラウザ型のIDEでonecompilerと同じくらいの言語があり、pygameなど普通のオンライン開発環境ではできないようなことができます。また、AIによるコード補完ができます。

# [6.tutorialspoint](https://www.tutorialspoint.com/compilers/index.htm)
tutorialspointはonecompilerと同じくらいの言語数があり、mycompilerのようにmatplorlibが使えます。

# [7.VScodeWEB版](https://vscode.dev/?vscode-lang=ja)
これはHTML,CSS,JSを書くために使っています。

- - -
# 個人的ランキング
## 7位 [Runstart](https://runstant.com/)
VScodeでもできるから

## 6位：[tutorialspoint](https://www.tutorialspoint.com/compilers/index.htm)
あまり使ったことがなかったから

## 5位：[paiza.io](https://paiza.io/ja)
普通だった

## 4位：[mycompiler](https://www.mycompiler.io/ja)
matplotlibが使える

## 3位：[VScodeWEB版](https://vscode.dev/?vscode-lang=ja)
HTMLなどがとても書きやすい

## 2位：[Replit](https://replit.com/~)
いろいろな言語が使えるが無料版では機能が制限されている

## 1位：[onecompiler](https://onecompiler.com/)
いろいろな言語があって無料版でも制限されているという感覚がない

以上がオンライン開発環境まとめ、個人的ランキングでした。