OmniAICreator/Qiita-1.07M huggingface dataset:
折角1週間の枠をもらったので…予告

# 今まで20年ほどのらりくらりと設計をしてきたので
その際にためになった…というかそういったことをメインに３～４記事ぐらいは書こうかと思ってます。
そのためにさっき昼食を食べてましたが何とか帰ってきました。

もちろんまだ３～４記事は書いてません🙇
ちゃんと設計の事について書いていこうとは…思ってます。
（ガイドラインに「日記などやめましょう」って書いてあるので日記で乗り切れなくなりました）

# 文献

記事の内容より、為になったと思うものを先に読んだほうが
急がば回れ、より為になると思います。

## RTL設計スタイルガイド-Verilog-HDL編

- ISBN-10 ‏ : ‎ 4563067865
- ISBN-13 ‏ : ‎ 978-4563067861
- URL : https://www.amazon.co.jp/RTL%E8%A8%AD%E8%A8%88%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%AB%E3%82%AC%E3%82%A4%E3%83%89-Verilog-HDL%E7%B7%A8%E2%80%95LSI%E8%A8%AD%E8%A8%88%E3%81%AE%E5%9F%BA%E6%9C%AC-STARC/dp/4563067865

### これ通りVerilogを書かなくても回路は動く…しかし
　大学4年の時、先輩はVHDL、自分はVHDLでよかったのにVerilogやれっていうことでやり始め、ある程度書けるようになった矢先に大学の講師（今は准教授だった、かと）から、
 **「この大学で誰一人Verilog使えないから、解らなくても一人で頑張ってね」** 
 という熱い言葉を頂きつつ、ちょうどアルバイトで今の会社であるロジック・リサーチにアルバイトだったかインターンシップだったかで通い始める。
　そんなある日、土屋さんからこの本を貸してくれるってことなので借りた…と思う。

 　電車の中で読んでると、だいたい2ページか4ページぐらいで眠たくなるのですごく便利だったイメージがある一方、 **「負論理の信号には後ろに_Xか_Nをつけろでこすけ！」（意訳）** といった本の一節を読んだとき「RESETでよくね？あと負論理とかじゃなくて全部正論理でよくね？ パイセンきようび何言ってんすか」という疑問を、一通り同じページ内でなんでなのか、を説明してあって（あたりまえだけど）、ふむふむと読み進め、とりあえず5章の「デザインコンパイラの使い方」（意訳）は意味不明すぎたので4章まで読み切るころには、名前の命名則などで困ることもなくなり、すっかりサクサク書けるようにはなって…たら
 **卒論で苦労しないんだよ！〇田！**

## 山浦恒央の“くみこみ”な話
- URL: https://monoist.itmedia.co.jp/mn/articles/1003/19/news097.html
- ダメな猫、普通の猫、優秀な猫

### SPICEもVerilogもなんだけど、何テストすればいいんだろうね
　自分が会社に入ったころにVerilogの設計者の方が土屋さんと喧嘩したらしく退職され、だれに何を聞けばいいんだろうかといったことにはなったのだけれどもとりあえずLTSPICEに回路エントリするという地味作業があったのでポチポチ…から始まる。もしかするとバイトの時のほうがVerilog触ってたかも…そんな中、どのお仕事もほぼほぼなあなあな感じでスパッと終わる事などあったかな？テストこんなんでいいのかな？と思いながら、ソフトウェアの知識を応用できるのではと思い、ググって見つけたここ。

　すごーくためになったのもそうなのだけども、最もは
 - ブラックボックステスト
 - ホワイトボックステスト

 というところで
 「これはSTARCであった『テストベンチとスケマティックを分けろ』と同じ事では？」と心躍ったりしたのだけども、実はあんまり関係なくてただただ **「LVS」するときにソース分けるのがすごく面倒なだけ**だった。オバークとかを見た時には「おお、気持ちホワイトボックステストなのでは？」とも思ったけど、電流が駄々洩れしているところしか見れない。それでも見れるだけすごく有難いんですけどね。

ただまあ、出来上がったチップに出来るテストというのは基本「ブラックボックステスト」しかない。LSIはPADの数で100本（電源込み）もあれば上々。動かないチップに対し、この出した100本にどういう電圧、電流、波形を与えれば問題の箇所を特定できるか？と頭を悩ませることになる

自分が関与していないプロジェクトなら「おっしゃ！原因特定して見せましょう！！」ってなるところ
もし、自分がメインのプロジェクトなら

**もう〇ぬしかない…**

ってぐらい落ち込むのでエンジニアには優しくしてね

## つまるところの予告
『テストベンチとスケマティックを分けろ』だけで３～４記事仕上げれれば、と思ってます。
図も入れます…多分きっと。
ワークフロー内でDigdag API に対してHTTPリクエストを送信する

この記事は [MicroAd Advent Calendar 2024](https://qiita.com/advent-calendar/2024/microad) 9日目の記事です。
内容は、Digdag APIに対して```http```オペレーターを使用してみたという話です。


### DigdagのHTTPオペレーターとは
Digdagで使用できるネットワーク操作の一つで、指定したURIに対してHTTPリクエストを行うことができます。

主なパラメータとして以下を指定できます。
* http>
    * リクエスト送信先のURIを指定できます。
    * 例：```http>: https://api.example.com/foobar```
* method
    * ```POST```や```DELETE```などリクエストのメソッドを指定できます。デフォルトは```GET```メソッドです。
* content
    * リクエストのボディを設定できます。

まとめるとこのような形でタスクの中でhttpリクエストを送信できます。
```Digdag:request.dig
+request:
  http>: https://api.example.com/foobar
  method: POST
  content: 'hello world'
```

他にも、JSONフォーマットを指定したりヘッダーを変更するパラメータもあります。
詳しくは公式Docを参照してください。↓

https://docs.digdag.io/operators/http.html


### Digdag APIに対して使ってみる

HTTPオペレーターはもちろんDigdagAPIにも使用できます。
```Digdag:api_request.dig
_export:
  digdag_host: host_name:8000

+fetch:
  http>: http://${digdag_host}/api/version
  store_content: true

+process:
  echo>: ${http.last_content}
```
```log:結果
{"version":"0.9.42"}
```

上記のように```store_content```というパラメータをつけると後続のタスクで返却された内容を使用することができます。

### 他にも

稼働しているワークフロー一覧を取得したい場合↓
```digdag:request.dig
http>: http://${digdag_host}/api/sessions
```

指定したワークフローを実行したい場合↓
```digdag:request.dig
http>: http://${digdag_host}/api/sessions
method: POST
content: '{"workflow_name": "my_workflow"}'
```

など様々な使い方がありそうですね。
技術が目的化する事は悪なのか？

# はじめに
[Hubble Advent Calendar 2024](https://qiita.com/advent-calendar/2024/hubble)の7日目[^1]です！
[^1]:平日のみの投稿なので10日ですが7日目の記事としています。

Hubbleでバックエンドエンジニアをしている @power3812 です。オブジェクト指向大好きマンで、神クラスを作れないかと模索の日々です:innocent:

今回は技術が課題解決手段から目的化することに対して自身の考えを書いてみようと思います。

# 前提
よくWeb系の事業会社の採用において、エンジニアにおいても**ユーザー志向**や**サービス志向**であることが、求められることが多いと思います。

> 自社サービスを開発している企業に入社しても、好きなものを好きなように作れるわけではありません。サービスにはそれを使うユーザーがいるため、「ユーザーを意識した仕事ができる人」が求められます。
[不採用理由で「〇〇志向が足りない」と言われてしまう人の対策より引用](https://paiza.jp/career/advice/Interview-tips-orientation)

これは自分自身も新卒・中途転職の際に下記のような質問を受けました。
- あなたはこのサービスのどこに共感しましたか？
- あなたが入社したらこのサービスのどこを直しますか？
- もしこのサービスがクローズしても弊社に勤める理由はなんですか？

# エンジニアはサービス視点を持つべきか
エンジニアである以上、ビジネスドメインよりも技術に目が行きがちです。

自分自身も、Hubbleに転職する際に、契約書のバージョン管理というビジネスドメインよりも、Wordのバージョン管理をWebでやっている技術に興味を最初持ちました。
そして実際に、[WebDAV](https://ja.wikipedia.org/wiki/WebDAV)や[Aspose](https://www.xlsoft.com/jp/products/aspose/index.html)と言った普段のWeb開発では使用しないであろう技術を使っています。

ここで表題のエンジニアはサービス視点を持つべきかですが、そもそもサービス視点だったり技術志向だったりはどちらに重きをおいても良いと思います。

大事なのはその考えをどうやって他人に伝えるかです。

例えば、そのまま`「自分は最新技術にしか興味がありません」`と言うのと`「自分は最新技術に興味があるので、最新技術でユーザの課題を解決できます」`と言うのだと全然印象が違います。
相手目線の目的に立って、自分の考えを言い換えるだけでかなり印象が違います。

自分がやっていきたいことがある場合は、相手の考えや目的を汲み取ってそれとどういう関連性があったりメリットがあるのかを提示することが大事です。

# 自分の場合
今の自分自身もサービス視点を持てるようになりたいなと思う一方、技術に重きを起きがちです。

Hubbleでは、技術的にやってみたいことであれば何でも挑戦することができます。

例えば、Hubbleでは主にRubyでアプリケーションを作成していますが、[過去にGoで新規アプリケーションを作成しました。](https://note.hubble-docs.com/n/ne807b5627dcd)
その当時Go人気がかなりあったため挑戦しました。特段、要件としてGoにする必要はなかったですが、プロダクションレベルのGoを学びたかったので選定しました。

結果として、Goとしてのメリット、デメリット、付随してDDDの知見が貯まりました。
そのため、今後要件毎にユーザビリティが高い言語を選ぶ幅が広がりました。

また、GPT-4が発表された当時早々に[アプリケーションに組み込んだり](https://hubble-docs.com/news/doc-list-ai)など、最新技術に触れつつユーザの課題を解決しました。

このように個人のやりたいこととユーザの課題解決はクロスするのでどこに目的を置くかだけの差でしかないのです。

# まとめ
今回は技術が課題解決手段から目的化することに対して自身の考えを書いてみました！
これからも最新技術に触りつつユーザの課題解決できていければなと思っています！

次回はQAの @miney さんです！
【QA】仕様読み合わせによるプロジェクト貢献と改善の可能性

本記事は[「MIXI DEVELOPERS Advent Calendar 2024」](https://qiita.com/advent-calendar/2024/mixi)の11日目の記事です。

# はじめに
MIXIで、あるQAグループのマネージャーをやっているYutoMです。
私たちのグループは、プロジェクトの品質向上を目指して様々な取り組みを行っています。
今回は特に効果が現れている取り組みについて、そのアンケート結果と見えてきた課題を紹介します。

# 取り組みについて
QAグループでは「仕様読み合わせ」を行っています。
これは、仕様書やデザイン案などの開発ドキュメントが共有された際に、QAメンバー全員で疑問点や改善案を議論するためのミーティングです。
そこで出た内容をスプレッドシートにまとめ、企画担当者、デザイナー、エンジニアへフィードバックしています。
「上流の段階からQA視点を取り入れることで、仕様検討漏れを早期に発見し手戻りを防ぐこと」が狙いです。

この取り組みがどれだけ貢献しているかを把握するために、今回アンケートを実施しました。
# アンケート概要
 - 対象者：プロジェクト内のQA以外の職種（企画担当者 / デザイナー / エンジニア）
 - 回答数：8件（企画担当者：1名、デザイナー：4名、エンジニア：3名）
 - 目的：仕様読み合わせがプロジェクトにどれだけ貢献しているかの可視化
 - アンケート内容 
    - 以下の3点についてヒアリング
        - 仕様検討漏れの削減になっているか
        - 職種間の認識齟齬の削減になっているか
        - 開発チーム全体の工数削減になっているか
    - 以下の5段階による回答
        - そう思う
        - ややそう思う
        - わからない
        - あまりそう思わない
        - そう思わない

# アンケート結果
![2024-12-09_12h55_14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2984275/e95e4655-a43e-6dcd-7956-7e6d3cbc9ae9.png)



# わかったこと・見えてきたこと
- 仕様検討漏れの削減には貢献できていそう
- 一方で、工数削減できているか？については疑問符が付く
    - 仮説
        - 読み合わせ実施のタイミング
            - 手戻りを防ぐにはもう少し早いタイミングでの実施＆フィードバックが必要？
        - 疑問点や改善案の伝え方
            - 仕様書やデザイン案に直接書いた方が参照しやすい？
            - 「QA担当」と「質問した相手」に閉じており、開発チーム全体の認識合わせになっていないのでは？
        - 伝えられた側の回答コスト
            - 1つ1つの質問に目を通し、回答するコストがかかっている可能性が？
 
実際、「デザインを詳細化する頃にはフィードバックがあると良い」「QA以外も巻き込んで行うと良い」といったように、フィードバックのタイミングや伝え方に関する要望がいくつかありました。
このように一定の評価をいただいている一方で、実施タイミングとフィードバック方法の面で改善の余地があると分かりました。

# おわりに
開発ドキュメントから仕様検討漏れを洗い出すのは難しいですよね。
そんな時は一人で黙々とやるより、誰かと会話しながら進めることで新たな発見が生まれ、
より多角的な視点で洗い出すことができると思います。

今回の取り組みを通じて、上流の段階からQA視点を取り入れる効果を実感しました。
この経験を基に、さらに効果的な方法を模索し続けることで、プロジェクトの成功に貢献したいと考えています。

本記事が少しでも皆様のQA活動に役立てば幸いです。
Oracleの文字列連結

## 発端
姓と名でカラムが分かれているテーブルから、
氏名として１カラムで出力したい時ちょっとハマったことがありました。

CONCAT関数を使用して、
```sql
SELECT CONCAT(last_name, first_name) FROM table;
```
とすると無事に下記のように表示されます。

|氏名|
|---|
|山田太郎|

## 問題
ところが、姓と名の間にスペースを入れたいと思い

```sql
SELECT CONCAT(last_name, ' ', first_name) FROM table;
```

とすると `ORA-00909: 引数の個数が無効です。` でエラーとなります。
他のDBMSですとこれで問題ないのですが、OracleではCONCAT関数の引数は2個までなんですね。
## 解決
調べたところ、Oracleでは下記の様にすることでも文字列連結ができ、無事に目的を達成できました。

```sql
SELECT last_name || ' ' || first_name FROM table;
```

|氏名|
|---|
|山田 太郎|

ここら辺は統一してほしいですね…
Lambdaのレイヤーに自作したPythonパッケージを追加して使用する

# はじめに
個人開発でLambdaのレイヤーに自作したPythonパッケージを追加する機会があったためメモ


:::note warn
本稿ではGitHubのpublic repositoryに作成したPythonパッケージを使用することを前提としています。
:::

# 手順
### Githubからクローン

```
git clone https://github.com/{your-username}/{your-package}.git
```

```
cd {your-package}
```

### 必要なパッケージをインストール

Pythonがパッケージを読み込むためのパスを作成
```
mkdir -p python/lib/python3.xx/site-packages
```

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/python-package.html#python-package-create-dependencies


作成したパスに必要なパッケージのインストール
```
pip install . -t python/lib/python3.xx/site-packages
```

### レイヤー用のzipファイルを作成

```
zip -r layer.zip python
```

### Lambdaのレイヤーを作成

```
aws lambda publish-layer-version \
    --layer-name {your-custom-layer} \
    --description "hogehoge" \
    --zip-file fileb://layer.zip \
    --compatible-runtimes python3.xx \
    --compatible-architectures "x86_64" or "arm64"
```
【Goで学ぶコンピューターサイエンス】グラフの基礎

## グラフ

グラフは以下の要素で構成されます。
- **頂点（Vertex）**
    - グラフの中のポイントで、ノードとも呼ばれる
- **辺（Edge）**
    - 頂点間の接続のことで、関係性やリンクを表す

グラフは通常、$G = (V, E)$ と表されます。
- (V): 頂点の集合
- (E): 辺の集合

## グラフの種類

### 1. 有向グラフ
各辺に方向があるグラフ。例えば、Xの「フォロー」関係は有向グラフで表現できます。

### 2. 無向グラフ
辺に方向がないグラフ。Facebookの「友達」関係のように双方向でつながっています。

### 3. 重み付きグラフ
各辺に重み（値）が割り当てられているグラフ。重みは距離、コスト、時間などを表します。

### 4. サイクルの有無
- 非巡回グラフ
    - サイクル（同じ頂点に戻るパス）が存在しないグラフ
- 巡回グラフ
    - サイクルが存在するグラフ

## グラフの表現方法

### 1. 隣接リスト
各頂点に対して、その頂点に接続されている隣接頂点をリストで持つ形式。
```plaintext
A: B, C
B: A, D
C: A
D: B
```

### 2. 隣接行列
頂点を行と列に持ち、接続されていれば1、そうでなければ0を持つ2次元配列。
```plaintext
   A B C D
A [0 1 1 0]
B [1 0 0 1]
C [1 0 0 0]
D [0 1 0 0]
```

### 3. エッジリスト
辺をリストとして持つ形式。
```plaintext
[(A, B), (A, C), (B, D)]
```

## グラフアルゴリズム

### 1. 幅優先探索 (Breadth-First Search, BFS)
レベル順にグラフを探索。

### 2. 深さ優先探索 (Depth-First Search, DFS)
一つの経路を深く進んでいき、戻ることを繰り返して探索。

### 3. 最短経路探索
- **ダイクストラ法**
    - 重み付きグラフの最短経路を求める
- **ベルマンフォード法**
    - 負の重みが存在する場合の最短経路

### 4. 最小全域木
- **クラスカル法**
- **プリム法**

## 無向グラフGoサンプルコード

```go
package main

import "fmt"

// グラフ構造体
type Graph struct {
	adjacencyList map[string][]string
}

// グラフの作成
func NewGraph() *Graph {
	return &Graph{
		adjacencyList: make(map[string][]string),
	}
}

// 頂点の追加
func (g *Graph) AddVertex(vertex string) {
	if _, exists := g.adjacencyList[vertex]; !exists {
		g.adjacencyList[vertex] = []string{}
	}
}

// 辺の追加 (無向グラフ)
func (g *Graph) AddEdge(v1, v2 string) {
	g.adjacencyList[v1] = append(g.adjacencyList[v1], v2)
	g.adjacencyList[v2] = append(g.adjacencyList[v2], v1)
}

// グラフの表示
func (g *Graph) Display() {
	for vertex, edges := range g.adjacencyList {
		fmt.Printf("%s -> %v\n", vertex, edges)
	}
}

// メイン関数
func main() {
	graph := NewGraph()

	// 頂点を追加
	graph.AddVertex("A")
	graph.AddVertex("B")
	graph.AddVertex("C")
	graph.AddVertex("D")

	// 辺を追加
	graph.AddEdge("A", "B")
	graph.AddEdge("A", "C")
	graph.AddEdge("B", "D")

	// グラフを表示
	fmt.Println("グラフの構造:")
	graph.Display()
}
```

```
A -> [B C]
B -> [A D]
C -> [A]
D -> [B]
```
ChatGPTとGoogleドキュメントを組み合わせて使う

# MicrosoftよりGoogleの方が好きだった自分のために…
(Microsoftでも同じようにできる機能あります)

Googleアカウントを持っているユーザーなら誰でも使用できる無料アプリケーションとして、Googleドキュメントやスプレッドシートがあります。それぞれ、GoogleドキュメントはMicrosoft Office Word、スプレッドシートはExcelに相当するサービスです。

本記事では、これらとChatGPTをシームレスに組み合わせることで作業を効率的に進める方法を解説します。

GoogleドキュメントやスプレッドシートとChatGPTを組み合わせて活用する際には、Google Workspace Marketplaceから取得できる"拡張機能"を利用します。

## 1. **導入方法**
本拡張機能をインストールするには、Google Workspace Marketplace(https://workspace.google.com/marketplace/app/gpt_for_sheets_and_docs/677318054654) にアクセスし、アドオンを取得します。

例として、"GPT for Sheets and Docs"などがあります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3923358/f144d72f-82de-224a-cd11-842016ec92d5.png)

導入したアドオンに、ChatGPTのAPIキーを取得して登録すれば使用可能になります。
:point_right_tone2:ChatGPTのAPIキーは、OpenAI社の(https://platform.openai.com/account/api-keys) にアクセスし、「API keys」欄のページで、「Create new secret key」をクリックして取得します。

## 2. **いいところ**
GoogleドキュメントとChatGPTを組み合わせる用途としては、以下のようなものがあります。

- 文書内で選択したテキストをもとに改善の提案
- 空白の文書からテーマやキーワードを指定しドラフトを生成
- 長文を簡潔に要約

などが挙げられますが、 

::: note 
ドキュメント内で直接利用することで、ブラウザの別途ウィンドウなどで開いたChatGPTのプロンプトに指示を出してからコピー&ペーストを行うよりも素早く、
文章作成の手間を大きく省きながら作業を行うことができる
:::
というところがポイントですね。

## 3. **使い方詳細(雑)**

### 1. Googleスプレッドシートでセルに直接回答

Googleスプレッドシートでは、セルに「=GPT(入力データ)」のように入力することでカスタム関数を使用し、ChatGPTに直接、計算や生成を指示することが可能になります。
質問や指示が多ければ多いほどスプレッドシートを利用した方が手軽に回答を得ることができます。

### 2. Googleスプレッドシートで回答をセルにリストアップ

また、関連するカスタム関数が複数存在しており、たとえば「=GPT_LIST(入力データ)」という関数では、ChatGPTから箇条書きで出力された回答を、リスト形式で各セルに分けながらリストアップすることができます。
これらの関数をうまく組み合わせながら活用することで、スプレッドシートそのものの活用範囲がより広がります。
windowsでiverilog その161

# 概要　
windowsでiverilogやってみた。
練習問題やってみた。

# 練習問題
zundokoを書け。

# サンプルコード

```

module test;
	integer p;
	integer stdin = 'h8000_0000;
	integer a,
		b;
	integer ch;
	reg [7:0] pc;
	reg [7:0] str[0:9];
	integer v;
	initial
	begin
		pc <= 10;
		v = 0;
		a = 0;
		b = 0;
	end
	always #1
	begin
		case(pc)
		10:
		begin
			b = 234;
			pc <= 20;
		end
		20:
		begin
			b = (b * 5 + 1) % 256;
			pc <= 30;
		end
		30:
		begin
			if (b < 120)
			begin
				pc <= 60;
			end
			else
			begin
				pc <= 40;
			end
		end
		40:
		begin
			$write("%s ", "zun");
			a++;
			pc <= 50;
		end
		50:
		begin
			if (a > 3)
			begin
				pc <= 70;
			end
			else
			begin
				pc <= 20;
			end
		end
		60:
		begin
			$write("%s ", "doko");
			a = 0;
			pc <= 20;
		end
		70:
		begin
			$write("%s\n", "doko kiyosi!!");
			pc <= 80;
		end
		80:
		begin
			$finish(0);
		end
		endcase
	end
	initial
	begin
		//$monitor(" %d", pc);
	end
endmodule



```

# 実行結果

```
>vvp a.out
zun zun doko zun zun zun doko doko zun doko zun zun doko doko doko doko zun zun doko doko zun doko doko zun zun doko doko doko doko doko zun zun zun zun doko kiyosi!!
```

以上
配列を使用した修正に強いなぞなぞプログラム

<h1>結論：とても難しい</h1>
変数を代入するだけでも自分の脳みそのメモリはガリガリ削られているのに、さらに仕組みを考えたり綺麗にしたり、新しい箱を用意してそれが入れ替わりながらシャキシャキ動くプログラムを組み立てるなんて無理。＝無理。

[][]　＝　配列
これは二つあるため二次元配列となる。
※[]を増やすことで三次元、四次元と配列を複雑化して凄いことも出来るが、常人では無量空処を食らった状態になるので非推奨だと教わりました。

<details><summary>サンプルコード</summary>


```rb
public class Q4 {
	public static void main(String[] args) {
		int okCount = 0;	// 正解数

		// クイズ・なぞなぞ内容（内側の配列は最初の要素が問題内容、次の要素が答えの情報）
		String[][] quizArray  = {
				{"ぼうしの中にはいっている動物は？", "うし"},
				{"9匹のトラが乗っている乗り物は？", "とらっく"},
				{"お茶はお茶でも、子供がよろこぶおちゃは？", "おもちゃ"},
				{"食べると安心するケーキはなーんだ？", "ほっとけーき"},
				{"どんなに頼んでも、売ってくれない人のお仕事は？", "うらないし"}
//				{"お父さんがきらいな食べ物なーんだ？", "ぱぱいや"}
		};

		System.out.println("今から、クイズ・なぞなぞを" + quizArray.length + "問出題します。");
		System.out.println("答えは全て\"ひらがな\"で答えてください。");

		for (int i = 0; i < quizArray.length; i++) {
			// クイズを出題する
			System.out.println("[第" + (i + 1) + "問]");
			System.out.println(quizArray[i][0]);

			// プレイヤーに回答させる
			System.out.print("答えをひらがなで入力>>");
			String answer = new java.util.Scanner(System.in).nextLine();

			// 回答と答えがあっているかのチェック
			if (answer.equals(quizArray[i][1])) {
				System.out.println("正解です！");
				okCount++;
			} else {
				System.out.println("残念。不正解です");
			}
		}

		System.out.println("終了！！");
		System.out.println("結果 正解：" + okCount + " 不正解：" + (quizArray.length - okCount));

		// 正解率に応じて結果メッセージを変化
		double okPercentage = okCount / (double)quizArray.length;
		if (okPercentage >= 0.8) {
			System.out.println("すばらしい！クイズ博士ですね！！");
		} else if (okPercentage >= 0.6) {
			System.out.println("優秀ですね！");
		} else if (okPercentage >= 0.4) {
			System.out.println("普通の人です");
		} else if (okPercentage >= 0.2) {
			System.out.println("次は、頑張りましょう！");
		} else {
			System.out.println("クイズは苦手ですか？");
		}
	}
```
</details>

<h2>修正に強いプログラム</h2>
上記のサンプルコードは、例えば問題が増えた際に二次元配列の{}内に問と解を書けばもう修正完了となるので利便性が良く、自分以外が修正を行うことになってもわかりやすいプログラムだと感じました。
凄すぎる。
ISUCON14に参加したログ

2024年12月8日に開催されたISUCON14に出場しました。
ISUCONへの参加は初です。

### ISUCONとは？

端折って説明すると、決められた時間内でアプリケーションをどこまで高速化できるかを競う大会です。

スタートと同時にアプリケーションが動作する CloudFormation が渡されるのですが、このアプリが非常に重い。
アプリの動作を変えぬままあらゆる手段を用いて高速化していきます。

高速化の手法はルールの範囲内なら何をしても構いません。ソースコードをチューニングするなり、DBにインデックスを張るなり自由です。

また、出場者には複数台のサーバーが与えられます。これを全て使うも使わないも またどのように使うのかも自由になります。

詳しくは「ISUCON とは」でググって下さい。

### 練習

過去問があるのでとりあえず触って雰囲気を掴みます。
AMIが公開されているので、AWSアカウントがあれば簡単に環境構築ができるようになっています。

https://github.com/matsuu/aws-isucon

過去問を解いていて困ったことがあるならば、ベンチーマーカーの問題です。
AMI内にアプリケーション、DB、ベンチマーカーが全て内包されているので 高速化していくにつれベンチマーカーの処理がボトルネックになりスコアが伸びないといった状態に陥りました。

複数台起動してベンチマーカーを分離するよう試みたものの、外部サーバーに向けてベンチマーカーをうまく実行することができずに四苦八苦。

ISUCON13のDNS水責め等、特殊なリクエストをしていそうな年度のものは 避けた方がいいかもしれません。
年度によっては簡単に外部からベンチを実行できる場合もあるようです。

また、ISUCON本とprivate-isuで素振りをしました。

https://amazon.co.jp/%E9%81%94%E4%BA%BA%E3%81%8C%E6%95%99%E3%81%88%E3%82%8BWeb%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0-%E3%80%9CISUCON%E3%81%8B%E3%82%89%E5%AD%A6%E3%81%B6%E9%AB%98%E9%80%9F%E5%8C%96%E3%81%AE%E5%AE%9F%E8%B7%B5-%E8%97%A4%E5%8E%9F-%E4%BF%8A%E4%B8%80%E9%83%8E/dp/4297128462

https://github.com/catatsuy/private-isu

ボトルネック検出のためのアクセスログ解析、スロークエリログの出力など役立つ情報が掲載されています。
とりあえず何やればわからんという方は、本を買って読んでいくのがいいのではないでしょうか。

### 準備

本番までに準備できるものはしておきます。

- 計測ツールなどのインストール方法
- GitHubのリポジトリ事前作成
- ソースをgitに追加するまでの手順書
- ISUCON本などで得た、各種高速化テクニック手法
- MySQLをGUIで表示するまでの手順

この辺りをメモしておきます。

本番前に一度、リハーサルを行なって上記メモがきちんと正しく書かれているか確認しました。

### 当日

CloudFormationを使って環境を作成しました。
レギュレーションやアプリケーション仕様が公開されているので、読み込んでいきます。
あとは事前作成したメモに従って、ssh接続から各種計測ツールのインストール、GitHubにソースをプッシュするまで進めていきます。

一通りできたらベンチ実行、初期スコアが低すぎて真顔になりましたが 自分たちだけではないと思うので気にしないことにします。
ここからチューニングスタートです。

私はインフラに偏って担当をしていたので、まずはベンチマーカーを実行させつつサーバー内のCPU使用率の遷移を見ていました。

MySQLのCPUがとんでもなかったのでスロークエリログを確認。重いクエリにインデックスを貼っていきます。
また、検出されたクエリの書き方自体に問題があることも気づいたので、アプリケーションを見てくれているメンバーにお願いして直してもらうことにしました。

MySQLの負荷が下がってきたら私もアプリ側を確認。重そうなクエリ書き換えようかと試みたものの、そこまでスコア変わらず。
しばらく時間を溶かしてしまいました。

中盤でアプリケーションサーバーとDBサーバーを分離しました。
スコアは想像していたよりも上がりませんでしたが、特に事故なく対応できたので満足です。

後半はwebサーバーを触っていることが多く、アプリケーションサーバーを2台構成にしようと試みましたがうまくできず断念。
ラウンドロビン的に振り分ける設定をしようとしたものの、ベンチが失敗の連続になってしまいました。

最後にサーバーを全て再起動してベンチマーカーを再実行。
エラーになって焦るものの、直前のアプリケーションの修正をrevertしたり、設定ファイルの内容を変更することにより回避。

最終スコアは7500点でした。
順位に関してはまだ公表されていないので伏せておきます。公開されたら追記します。

### 反省

途中無駄にクエリをいじろうとして時間を溶かしたのと、webサーバーを2台構成にできなかったのは反省ポイントです。
webサーバーに関してはコアとなる原因が分かっておらず、自分の考えの甘さが露呈してしまいました。

再起動してベンチ実行ももう少し余裕をみて行なっておけばよかったかなと思いました。
やらずに結果発表時に0点にならなかっただけマシでしたが。

ISUCON出場を通して、多くの知識を取り入れることができたと思います。
最終スコアはさておき、スキルアップのためにも興味があればぜひ参加することをお勧めします。

また、この感想文では具体的な技術エッセンスは残していません。（何のツールを使ったのか、適切なインデックスの貼り方等）
ぜひ本を買いましょう。
DOMの操作、要素の取得(getElementById, getElementsByClassName, querySelector)

[Edgeの拡張機能を自作する(プルダウンの中身を削る)](https://qiita.com/Ki2neudon/items/db6b1fc5dcd882ac6406)にて見様見真似で使ってみたけれど、`DOM`(Document Object Model)においては「要素を取得する」という行為が重要らしい。

もうちょっとココを改めて学んでみる。

# タグで取得する

以前の記事でやってたもの。これしかないと思ってた。

```js
const pObject = document.querySelector("p");
```

[属性セレクター](https://developer.mozilla.org/ja/docs/Web/CSS/Attribute_selectors)を使うともうちょっと細かい条件をつけて取得できる。

```js
const pObject = document.querySelector('p[class="btn"]');
```

# クラスで取得する

先述の[タグで取得する](https://qiita.com/drafts/7523e04a819ad7bbe092/edit#%E3%82%BF%E3%82%B0%E3%81%A7%E5%8F%96%E5%BE%97%E3%81%99%E3%82%8B)にて`class="xxxx"`という属性セレクターをつけてしまったが、最初からクラスを対象に取得する場合は以下のように書けるらしい

```js
const pObject = document.querySelector(".btn");
```

`.`から始まるクラス、みたいな指定の仕方。

# idで取得する

これもきっと属性クラスターにて`[id="xxx"]`っって指定できるのだろうけど、個別の実装がある。

```js
const pObject = document.querySelector("#menu");
```

# querySelectorとgetElement...の違い

参考:[要素を取得する3つのJSメソッド 〜挙動の違いをまとめてみた〜](https://zenn.dev/harryduck/articles/e3e6c9d37e0169c05096)

使いやすいやつ使って良さそう。

## 例題

```html:sample.html
<div id="title" class="style-a">わらびもち</div>
<div class="style-a">さくらもち</div>
```

## getElementById

`id`で唯一を特定して取得。`getElementById`のなかでid名は`#`をつける必要がない。

```js
'use strict'
const title = document.getElementById("title");
console.log(title);
```

```text:出力結果
div#title.style-a
0 = 'わらびもち'
[[Prototype]] = Object
ノード属性 = ...
```

## getElementsByClassName

`class`が一致するものを配列で取得。なのでgetElement<font color="red">s</font>ByClassNameになる。

```js
'use strict'
const classes = document.getElementsByClassName("style-a");
console.log(classes);
```

```text:出力結果
HTMLCollection(2) [div#title.style-a, div.style-a, title: div#title.style-a]
0 = <div id="title" class="style-a">...</div>
1 = <div class="style-a">...</div>
(以下省略)
```

## querySelector

柔軟にできるやつ

### idで取得

こっちは`#`をつける必要がある。

### classNameで取得

こっちは`.`をつける必要がある。

### classNameで全部取得

ただのクラス名指定だと1個しか取れない。全部とるときは`querySelectorAll()`らしい。

### 実践

```js
'use strict'
const title = document.querySelector('#title');
console.log(title);
console.log("------------");
const classMono = document.querySelector('.style-a');
console.log(classMono);
console.log("------------");
const classes = document.querySelectorAll('.style-a');
console.log(classes);
```

```text:出力結果
div#title.style-a
0 = 'わらびもち'
...
------------
div#title.style-a
0 = 'わらびもち'
...
------------
NodeList(2) [div#title.style-a, div.style-a]
0 = <div id="title" class="style-a">...</div>
1 = <div class="style-a">...</div>
...
```
バリデーション：RailsとLaravelのフォームリクエストの違い

### はじめに

プログラミングを学び始めると、多くのフレームワークにおいてバリデーション（入力値の検証）が重要な役割を果たすことに気づくでしょう。この記事では、Rails（Ruby on Rails）とLaravel（PHPのフレームワーク）におけるバリデーションの実装方法と特徴の違いを、例を交えながら解説します。

### バリデーションとは？
バリデーションは、ユーザーから送信されたデータが正しい形式であるか、期待する条件を満たしているかを検証する仕組みです。これにより、不正なデータが保存されたり処理されたりすることを防ぎます。

### Railsのバリデーション
#### Railsの基本的なバリデーション
Railsでは、モデルに直接バリデーションを定義することが一般的です。以下に、簡単な例を示します。

**モデル定義:**

```ruby:ruby
class User < ApplicationRecord
  validates :name, presence: true
  validates :email, presence: true, format: { with: URI::MailTo::EMAIL_REGEXP }
end
```

#### バリデーションの特徴
**モデル中心:** Railsではバリデーションがモデルに紐づいており、データベースレベルで整合性を保つのに適しています。

**シンプルな記述:** `validates`メソッドを使えば、わずか数行で複雑なルールを定義できます。

**カスタムバリデーション:** 独自のルールが必要な場合、カスタムメソッドを定義できます。

**カスタムバリデーション例:**

```ruby:ruby
class User < ApplicationRecord
  validate :email_domain_check

  private

  def email_domain_check
    unless email.ends_with?("@example.com")
      errors.add(:email, "must be from the example.com domain")
    end
  end
end
```


### Laravelのバリデーション
#### フォームリクエストでのバリデーション
Laravelでは、**フォームリクエスト**という専用のクラスを使ってバリデーションを管理します。

**フォームリクエストクラス作成:**

```bash
php artisan make:request UserRequest
```

**フォームリクエストの内容:**

```php:php
namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UserRequest extends FormRequest
{
    public function rules()
    {
        return [
            'name' => 'required|string',
            'email' => 'required|email',
        ];
    }

    public function authorize()
    {
        return true;
    }
}
```

### コントローラーでの使用

フォームリクエストをコントローラーで利用することで、バリデーションのロジックを分離できます。

```php
namespace App\Http\Controllers;

use App\Http\Requests\UserRequest;

class UserController extends Controller
{
    public function store(UserRequest $request)
    {
        // バリデーション済みのデータを使用
        $validated = $request->validated();
        // データ保存処理
    }
}
```

### バリデーションの特徴
**専用クラスでの管理:** バリデーションルールをクラスに切り出すことで、コントローラーがスッキリします。

**多機能なルール:** Laravelではバリデーションルールが豊富で、複雑な条件を定義できます。

**翻訳対応:** エラーメッセージの多言語対応が簡単にできます。

### RailsとLaravelの違い
		
| 特徴           | Rails                             | Laravel                               |
|---------------------|--------------------------------------|--------------------------------------|
| バリデーションの場所             | モデル内	                               | フォームリクエストクラス                                 |
| バリデーションの記述量    | 簡潔 (`validates`メソッド)           | 詳細なルールを定義可能                         |
| カスタムバリデーション        | メソッドを使った柔軟な定義が可能                      | バリデーションルールやクラスで対応可能                       |
| エラーメッセージの翻訳    | 独自設定が必要                 | デフォルトで多言語対応                   |


### まとめ
RailsとLaravelでは、バリデーションの実装方法に違いがありますが、どちらも強力な機能を持っています。Railsはモデル中心のシンプルなバリデーションを特徴とし、Laravelはフォームリクエストによる分離と多機能性が魅力です。プロジェクトの要件に応じて、適切なフレームワークを選ぶことが重要です。

### 参考記事

[Railsガイド - バリデーション](https://railsguides.jp/active_record_validations.html)
[Laravel公式ドキュメント - バリデーション](https://laravel.com/docs/11.x/validation)
UiPath Document Understandingのためのプロンプトエンジニアリング

# はじめに
ChatGPTなどの普及により、生成AIを使うときはプロンプトエンジニアリング（プロンプトの工夫）が最も重要だと認識している方も増えたかと思います。AIから「ほしい結果」を得るためには、優れたプロンプトが必要です。
一方、UiPath Document Understandingには「生成AI抽出」という機能があり、ここでもプロンプトエンジニアリングが重要になります。
今回は、Document Understandingのためのプロンプトエンジニアリングを考えてみたいと思います。


# つかうもの
※2024年12月時点
Automation Cloud(Document Understanding) Enterprise版
OCRエンジン：Extended Languages OCR


# 生成AI抽出とは
Document Understandingには正規表現、ML、フォーム抽出など様々な抽出メソッドが用意されています。生成AIは文字通り生成AIを使った抽出方法となり、プロンプトで具体的な抽出の指示を行います。MLのような事前トレーニングは不要で、専門知識がなくとも扱えるのが特徴です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/89445/71ad1e6c-b738-b5a8-7ec9-f2e028c08d34.png)


# プロンプトエンジニアリングを何もしないと…
今回は請求書を例に、その中から「取引日（請求日）」、「取引金額（請求金額）」、「取引先（請求元）」の3つのフィールドを抽出してみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/89445/1f2f17a4-4978-8221-e2dd-9ed8958ead2b.png)

まず最初に、何もプロンプトを工夫せずに実行してみます。

|抽出対象|プロンプト|
|:-|:-|
|取引日|取引日です。|
|取引金額|取引金額の合計金額です。|
|取引先|取引先の企業名です。|

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/89445/f9b92282-731b-a0a4-1610-b327c34cad4a.png)

抽出結果です。

:::note warn
精度はあくまで参考です。請求書フォーマットやLLMによって変動します。
:::

|抽出対象|正答率|
|:-|-:|
|取引日|57.1%|
|取引金額|90.5%|
|取引先|74.6%|

やはり、何も工夫しないと精度は良くありません。特に取引日と取引先の改善が必要です。


# プロンプトの工夫の仕方
:::note warn
以下は実際にやってみて精度向上が確認されたTipsですが、すべてのケースで効果があるわけではありません。ご了承ください。
:::


## 別名の候補も記載する
フォーマットによって、抽出対象のフィールド名が一意に決まらないケースがあります。例えば、商品名、品名、品目などです。この場合、別名の候補も含めて記載することを推奨します。

> 発行日、請求日と書かれている場合があります。

> 取引金額ではなく請求金額と記載される場合もあります。


## 場所を指定する
特定の場所に出現することが多いのであれば、その旨を記載しても良いです。

> 通常、右上に記載されています。

また、別のフィールドがセット（場所的に近い位置に記載）になる場合は、その旨を記載しても良いかと思います。

> 取引先企業名は取引先住所の近くに記載されていることが多いです。


## 複数の候補が存在する場合の条件を指定する
ドキュメント中に類似した値を複数抽出するケースはよくあります。その場合、生成AIがどっちの項目を選ぶか迷ってしまうので条件を指定します。

> 複数の値が存在する場合は最も上に記載された値を抽出します。

> 金額が一番大きい値を選びます。


## 除外（対象外）の条件を指定する
ドキュメント中に類似した値を複数抽出する可能性がある場合、選ぶ方の条件を指定する他に、除外（対象外）となる方の条件を指定することもできます。

> 「御社」や「様」が付いた会社名は自社なので別の会社名を抽出してください。

> ○○株式会社は自社なので抽出対象外です。

> 表形式（json形式）で抽出される金額は対象外です。

> 「税」や「税抜」の金額は抽出対象外なので、別の金額項目を抽出してください。


## プロパティ（必須・型・桁・表示形式など）を指定する
必ず値がある場合は、必須であることを指定することで抽出結果がブランク（Null）になる確率を下げることができます。

> 抽出する値はnullではありません。

型や桁が固定されている場合も条件を追加しても良いです。

> 顧客番号は10桁の数字です。

精度向上とは違いますが、抽出した結果をシステムへ登録することを考慮して、単位などを削除したりするなど形式を指定しても良いかと思います。
※抽出後のRPAで変換してもOKです。

> 西暦に変換し、yyyy/MM/ddの形式で抽出してください。

> 抽出する金額は単位とカンマを削除してください。


## 例示する
例を示せる場合は追加しても良いと思います。

> 顧客番号は「A-99999」のように、大文字英字1桁＋ハイフン＋数字5桁で構成されています。


# おわりに
以上のことを踏まえ、プロンプトを工夫して再度抽出してみた結果です。

|抽出対象|正答率（改善前）|正答率（改善後）|
|:-|-:|-:|
|取引日|57.1%|100%|
|取引金額|90.5%|100%|
|取引先|74.6%|85.7%|

ちゃんと改善がみられました。やはり、良い結果を得るにはプロンプトが重要だと分かりますね。
QAの多様な役割を活かす：特化型チーム編成のすすめ

この記事は[ソフトウェアテストの小ネタ Advent Calendar 2024](https://qiita.com/advent-calendar/2024/software-testing-koneta) 11日目の記事です。

皆さんは、QA業務と聞いてどんな活動を思い浮かべますか？
テスト、プロダクトやプロセスの改善提案、テスト自動化、メトリクスの分析、品質文化の醸成などなど...その回答は十人十色ではないでしょうか？

そんな幅広い活動であるQA業務だからこそ「何かに特化してみては？」というのがこの記事で述べたいことです。

----
筆者は今、6人のQAチームのマネージャーをやっています。
マネージャーのお仕事は「チームの価値の最大化」であり、
そのために普段から「メンバーの強みの活かし方」について度々考えます。

この人はどういうところに強みを持っていて、
それをどう生かせばこの人の価値を発揮できるか...。
それぞれの持つ強みを最大限引き出すことで、チームとしての価値も最大化できると思っています。

（そう考えると、マネージャーという仕事にはプロデューサー的な側面もあるんだなぁと思ったりします）

そしてこの特化した領域のことを、筆者は「役割」と呼んでいます。

---
ここで、筆者のQAチームメンバーの役割について一例を挙げてみましょう
- UI/UXデザインに特化した（個人でWebページのUI/UXデザインもやっている）人
    - デザイナーさんのMTGやslackに参加し、デザインレビュー観点を吸収
- ドメイン知識に特化した人
    - 豊富な知識を活かして、チーム内の「わからない」を華麗に解決
    - QAチーム内だけでなく、他職種の方からも仕様を聞かれているほど
- ドキュメント化に特化した人
    - 見聞きした情報はとにかくドキュメントに！
    - 蓄積されたナレッジが、PJ全体に活用されています

などなど、こんな役割があります。

---
個人的な意見ですが、チーム全体の能力がバランスよく整っているとした場合、
「全員がバランス型」よりも 「それぞれが異なる分野に特化している」方が理想的だと思います。
その方が、各メンバーの強みが特定の状況で効果的に生かされ、より大きな価値を発揮できるからです。

---
多岐にわたるQAの活動。
その広がりの中で、方向性を明確にしながら進むことは重要だと思います。
何か一つ特定の領域を見つけ、その強みをさらに磨いていくことで、
新たな価値を生み出すことができるのではないでしょうか。
git stashで変更を退避させよう![Git]

git stash使いこなせていますか?

`stash`コマンドはかなり便利だと思うのですが、あまり使い方がわかっていないので、今回はstashコマンドについてまとめてみようと思います。

# git関連の記事

https://qiita.com/maooz4426/items/b547f8474e3a83f96336

https://qiita.com/maooz4426/items/510f17015b479c31b667

# git stashとは?

一言で言うと`一時的な変更退避`を行うことができます。

コミットされていない変更差分を退避させることができます。

# git stashを使うケース

### 1.作業中に別ブランチで作業したい
例えば、別ブランチに移動して作業をしたい場合に、コードが完全に書き終えることができておらず、コミットせずに作業をしたいとなった場合にstashコマンドを使用します。

### 2.バグ対応
バグの修正対応が迫られた際に、作業中の内容を退避させる時に使います。

### 3.バックアップとして取っておきたいとき
複数のコードの書き方があって悩む時に使えます。
stashコマンドで退避させておくことで、別の書き方で書いたら動かなくなってしまったというケースに対応できます。


# 使用方法

## 変更の一時的な退避
下のコマンドで以下のファイルをstashさせることができます。

- ステージングされたファイル
- 追跡済みのファイル

```zsh:git
git stash
```

未追跡(`Untracked`)のファイルの場合は-uオプションでstashします。

```zsh:git
git stash -u
```

addコマンドでステージングされたファイルを除外したい場合は、-kを使用します。
```zsh:git
git stash -k
```

saveコマンドを使うとstashさせた履歴に説明をつけることができます。
```zsh:git
git stash save "memo"
```


## 一覧

stashさせたものの一覧は次のように確認します。
```zsh:git
git stash list
```

下のように表示されます。
```zsh:zsh
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log
```

:::note
### 履歴に残さずstashしたい場合

単なるstashコマンドだけだと履歴として残ってしまいますが、createコマンドを使用すると履歴に残さずにstashすることができます。
```zsh:git
git stash create "message"
```

これを使うとハッシュ値として返してくれます。

これをstoreコマンドを使うことでstashの履歴として残せます。

```zsh:git
git stash store -m "作業中の変更" <hash>
```

あまりこの方法は使わないような気がしてます。
:::

## 変更の詳細を確認する

stashさせたものの変更ファイルの一覧を確認するには、showコマンドを使用します。

```zsh:git
git stash show stash@{2}
```

ソースコードなどのファイルの内容も見るには`-p`を使用します。

```zsh:git
git stash show stash@{2} -p
```

## stashの復元

復元には`apply`と`pop`コマンドを使います。

applyコマンドを使うと最新のstashされた履歴が復元されます。
```zsh:git
git stash apply
```

特定の履歴を復元したい場合は、`list`から確認してインデックス番号を指定します。
```zsh:git
git stash apply stash@{2}
```

もしstashさせたものを適応させた後、その履歴を削除したい場合はpopコマンドを使用します。
```zsh:git
git stash pop
```

こちらも特定の履歴から戻すには、下のように指定します。
```zsh:git
git stash pop stash@{2}
```

ただこれらのコマンドはコミットせずステージングしていたものを、ステージングから外してしまいます。
ステージングさせたままにしたい場合は`--index`を使用します。

```zsh:git
git stash apply --index
```

## 履歴の削除

dropコマンドで最新のstashさせた内容を捨てることができます。
```zsh:git
git stash drop
```
特定のstashに対して行うにはpop等と同じようにstashを指定します。

```zsh:git
git stash drop stash@{2}
```

全てを捨てるにはclearコマンドを使います。
```zsh:git
git stash clear
```

## 変更した内容をブランチで復元する

branchコマンドでstashした内容を新しいブランチとして復元できます。

```zsh:git
git stash branch <branch_name>
```

# まとめ

stashを使うことで変更を退避して、安全に自分が行った変更を保持しながら作業することができます。

今回紹介したコマンド一覧は下のようになっています。

|コマンド|機能
|---|---
|stash|ステージング・追跡済みのファイルの変更を退避
|stash -u|未追跡のファイルの変更を退避
|stash -k|ステージングされたファイル以外の変更を退避
|stash save|stashにメッセージをつけて保存
|stash list|stashの一覧
|stash show <stash_id>|stashのファイル一覧確認
|stash show <stash_id> -p|stashしたファイルの中身確認
|stash apply|最新のstashを復元
|stash apply <stash_id>|特定のstashを復元
|stash apply --index|ステージングさせたままstashを復元
|stash pop|最新stashを復元し、履歴から削除
|stash pop <stash_id>|特定のstashを復元し、履歴から削除
|stash drop|最新のstashを削除
|stash drop <stash_id>|特定のstashを削除
|stash clear|すべてのstashを削除
|stash branch <branch_name>|stashを新しいブランチで復元
o1に「生命はデジタルでできている」というタイトルの新書を書かせてみた

ちまたではo1 proばかり話題になってますがo1もpreviewじゃなくなってそこそこ性能が上がっています。今回はproじゃないo1に新書を書かせてみたら驚きの出来栄えだったので。

普通にo1に

>「生命はデジタルでできている」というタイトルで一般の人向けの新書を１０万字でお願いします。

と投げてみました。返事は

>申し訳ありません、その分量のテキストはこの場ではご提供が難しいです。以下に本書の構成案と冒頭部分のサンプルをお示ししますので、ご参考としてご覧ください。もしより長い原稿が必要でしたら、章ごとに分けてご要求いただくことは可能です。

>【書籍タイトル案】
>「生命はデジタルでできている　——バイオロジーの再発見とデータ的思考」

>【想定文字数】
>約10万字（本回答では構成と冒頭サンプルのみ提示）

>【想定読者層】
>大学生以上の一般読者、科学・技術・生命科学分野に興味のある読者

>【本書の狙い】
>・生命現象を「デジタル的」な視点から捉える試みを紹介
>・遺伝情報や分子機構をデータとして理解することで、新たな生命観を提示
>・進化、生態系、脳、情報処理などを一貫して「デジタル性」という観点で考察

>【目次案】

>序章　生命を「デジタル」として捉える視点
>生命の捉え方：アナログからデジタルへ
>DNA発見以降の生命観の変遷
>デジタル生命論の萌芽
>本書の狙いと構成

>第1章　生命情報の基本：DNAと遺伝子
>DNAという「コード」
>四種類の塩基が紡ぐ情報世界
>転写と翻訳のデジタル的プロセス
>ゲノム編集技術とデータ操作

>第2章　デジタル的進化観：情報の書き換えと自然選択
>進化と突然変異：ランダムビットフリップ仮説
>情報圧縮としての適応
>分子進化と中立説における情報的意味
>計算機シミュレーションが描く進化の「設計図」

>第3章　細胞ネットワークの情報処理
>シグナル伝達系：入力、演算、出力
>遺伝子ネットワークとロジックゲート
>合成生物学と細胞プログラミング
>エピジェネティクス：データ書き換えのレイヤー

>第4章　脳と知能：デジタル的演算の震源地
>ニューロンのスパイクはデジタル信号か
>シナプス結合の重みと情報コード
>脳を計算機モデルで理解する試み
>人工知能との対話：生命的知能と計算的知能

>第5章　情報エコシステムとしての生態系
>食物網と情報フロー
>ミクロからマクロへ：階層的データ構造
>適応戦略の情報理論的解釈
>情報生態学：データが紡ぐ生態系の安定性

>第6章　医療とバイオテクノロジーにおけるデジタル生命論
>パーソナルゲノムとビッグデータ医療
>遺伝子データバンクと創薬プロセスの高速化
>遺伝子編集と倫理的問題
>生命情報を守るサイバーセキュリティ

>第7章　「生命はデジタルでできている」再考
>デジタル生命論の限界と可能性
>生命理解の深化：アナログ性との融合
>デジタル的世界観が示す未来像
>新たな哲学的問い：生命とは何か

>終章　生命観の地平線を超えて
>20世紀的生命像から21世紀的生命像へ
>科学・技術と社会の共創
>本書を通じた読者へのメッセージ
>さらなる探求への呼びかけ
>【冒頭サンプル（約5,000字相当）】
>以下略

もう目次だけですごいのですが、本当にこんなに長いものをかけるのか疑問だったので

>序章　生命を「デジタル」として捉える視点
>生命の捉え方：アナログからデジタルへ
>の部分を書いてください。


みたいな感じで一節ずつ書いてもらいました。それをただまとめたのが[こちら](https://docs.google.com/document/d/1vHWzB2yG-ruPiM6RSd-P8oWVEb3kPGWfL0vryFjOCbM/edit?usp=sharing)です。正直うならされました。この長さの物を破綻せず（ぱっと見大きな間違いもなく）首尾一貫書けるとは思いませんでしたができてしまいました。

文書として人を引き付けるような魅力があるかというとそれは無いとは思うのですが、情報をまとめてわかりやすく伝えるという意味ではもうできているのでは、と思いました。

人間、ヤバいっすね。
windowsでiverilog その160

概要　
windowsでiverilogやってみた。
練習問題やってみた。

# 練習問題
fizzbuzzを書け。

# サンプルコード

```


module test;
	integer p;
	integer stdin = 'h8000_0000;
	integer i;
	integer ch;
	reg [7:0] pc;
	reg [7:0] str[0:9];
	integer v;
	initial
	begin
		pc <= 10;
		v = 0;
		i = 0;
	end
	always #1
	begin
		case(pc)
		10:
		begin
			i++;
			pc <= 20;
		end
		20:
		begin
			if (i > 100)
			begin
				pc <= 100;
			end
			else
			begin
				pc <= 30;
			end
		end
		30:
		begin
			if (i % 15 == 0)
			begin
				pc <= 70;
			end
			else
			begin
				pc <= 40;
			end
		end
		40:
		begin
			if (i % 5 == 0)
			begin
				pc <= 80;
			end
			else
			begin
				pc <= 50;
			end
		end
		50:
		begin
			if (i % 3 == 0)
			begin
				pc <= 90;
			end
			else
			begin
				pc <= 60;
			end
		end
		60:
		begin
			$write("%0d\n", i);
			pc <= 10;
		end
		70:
		begin
			$write("%s\n", "FizzBuzz");
			pc <= 10;
		end
		80:
		begin
			$write("%s\n", "Buzz");
			pc <= 10;
		end
		90:
		begin
			$write("%s\n", "Fizz");
			pc <= 10;
		end
		100:
		begin
			$finish(0);
		end
		endcase
	end
	initial
	begin
		//$monitor(" %d", pc);
	end
endmodule





```

# 実行結果

```
>vvp a.out
1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
16
17
Fizz
19
Buzz
Fizz
22
23
Fizz
Buzz
26
Fizz
28
29
FizzBuzz
31
32
Fizz
34
Buzz
Fizz
37
38
Fizz
Buzz
41
Fizz
43
44
FizzBuzz
46
47
Fizz
49
Buzz
Fizz
52
53
Fizz
Buzz
56
Fizz
58
59
FizzBuzz
61
62
Fizz
64
Buzz
Fizz
67
68
Fizz
Buzz
71
Fizz
73
74
FizzBuzz
76
77
Fizz
79
Buzz
Fizz
82
83
Fizz
Buzz
86
Fizz
88
89
FizzBuzz
91
92
Fizz
94
Buzz
Fizz
97
98
Fizz
Buzz

```


以上。
【ChatGPT】生成AIに『うまく問いかける』ためのヒントになるプロンプトのご紹介です。


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

　今回は、生成AIに『うまく問いかける』ためのヒントになるプロンプトのご紹介です。

:::note info
本記事は、ChatGPT（Plus版）
で行なっております。画像は
ありません。　あしからず。
:::
　ChatGPT等の動作状況を知らせる
　　OpenAIのステータスページ。
　　　[OpenAIステータス](https://status.openai.com/)

***
　まずは、謝罪します。

　昨日（2024/12/08）
　　OpenAIのクリスマスイベントが
　　　お休みでしたが、
　　　　今日もお休みでした。

　アメリカ時間を勘違いして、
　　“月曜日の3時”と
　　　書いてしまいました。

　日本時間では
　　“火曜日の3時”になります。

　失礼いたしました🙇

　昨日の記事は
　　すでに書き直してあります。
***
　次に、ニュースです。

　OpenAIのクリスマスイベントは
　　お休みですが、OpenAI絡みの
　　　ニュースが飛び込んできました。

　Sora V2の映像が
　　ロンドンで披露されました。
　　　映像の最後にOpenAIのロゴも
　　　　ありますので間違いないかと。

[Ruud van der Lindenさんポスト](https://x.com/RuudNL/status/1865425438991945938?t=ClfhazX4fJJduFqEx4xQBQ&s=19)
>（DeepL翻訳）
>Sora v2リリース間近：
>
>* 1分間のビデオ出力
>* テキストからビデオへ
>* テキスト+画像→動画
>* テキスト+動画→動画
>
>OpenAIのChad Nelsonは、ロンドンのC21Media Keynoteでこれを披露した。 そして、@samaが予言したように、私たちは非常に近いうちにこれを目にすることになるだろうと語った。
***
　ニュースでもありませんが、
　　ほぼ日の糸井重里さんが
　　　ChatGPTを使っていました😅
　　　　[糸井重里さんポスト](https://x.com/itoi_shigesato/status/1865802323139924046?t=qeEQ7DwpfFyNTa_y5p6b5w&s=19)

　　「英単語で、
　　　“B”ではじまり
　　　　“B”で終わる単語はあるか？」
　　　　　のポストへの返答として
　　　　　　使っていました。

　　糸井重里さんのポストには
　　　四つだけでしたが、
　　　　私がしつこくやってみたところ
　　　　　六つ出てきました😸
***
　さて、【本題】です。

　今回は、
　　生成AIに
　　　『うまく問いかける』ための
　　　　ヒントになるプロンプトの
　　　　　ご紹介です。

　今回も木内翔大さんのポストを
　　参考にさせていただきました。
　　　[木内翔大さんポスト](https://x.com/shota7180/status/1865901968490914106?t=vruiyVknWCesdz4jLYQreQ&s=19)

　そのままでは
　　申し訳ありませんので、
　　　ChatGPTに尋ねる
　　　　Promptからご紹介。
```Text:問いかけヒント20Prompt
おすすめの「生成AIに『うまく問いかける』ためのヒントになるプロンプト20選をお願いします。
```

　これで出力されたのが、こちら。
　　表記を一部修正しています。
```Text:Prompt結果
以下は、生成AIに「うまく問いかける」ためのヒントになるプロンプト20選です。これらのプロンプトは、質問内容を具体的かつ明確にすることで、AIの応答を最大限に活用できるよう設計されています。

●クリエイティブなアイデアを引き出すプロンプト

1. 「〇〇をテーマにした斬新なアイデアを3つ提案してください。」

2. 「未来の〇〇業界について、予想されるトレンドを分析してください。」

3. 「〇〇を元に、映画のあらすじを200文字で作成してください。」

4. 「〇〇に関連するユニークな製品コンセプトを考えてください。」


●問題解決を助けるプロンプト

5. 「〇〇という課題を解決するための5つの方法をリストアップしてください。」

6. 「〇〇業界でよくある問題に対して、解決策を戦略的に提案してください。」

7. 「コストを削減しながら〇〇を実現する方法を教えてください。」

8. 「特定の条件下で〇〇を効率的に行う方法を考えてください。」


●具体的な情報を引き出すプロンプト

9. 「〇〇の定義を簡潔に説明してください。」

10. 「〇〇の歴史的背景を5行以内でまとめてください。」

11. 「〇〇に関する最新の研究やデータを教えてください。」

12. 「〇〇のメリットとデメリットをリスト化してください。」


●文章やコンテンツ作成を助けるプロンプト

13. 「〇〇について、500文字のブログ記事を書いてください。」

14. 「〇〇というテーマでキャッチコピーを5つ提案してください。」

15. 「〇〇に関する質問集を作成してください。」

16. 「〇〇のマーケティング用スクリプトを作成してください。」


●比較やリスト化のためのプロンプト

17. 「〇〇と△△を比較して、どちらが優れているか説明してください。」

18. 「〇〇に必要なスキルを10個挙げてください。」

19. 「〇〇のトップ10ツールをリストアップしてください。」

20. 「〇〇と似たコンセプトを持つアイデアをいくつか教えてください。」


これらのプロンプトを活用すれば、AIからより具体的で価値のある情報を引き出しやすくなります。プロンプトを組み合わせたり、詳細を追加したりしてさらに洗練された質問に仕上げてみてください。
```

　もちろん、これはヒントであって
　　用途に合わせて変更するなり、
　　　条件や設定を加えるなど
　　　　してください。

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

　今回は、ここまで。
シングルトンパターンが「アンチパターン」と言われる理由とは？

オブジェクト指向プログラミングにおいて有名な「シングルトンパターン」。開発初学者からベテランエンジニアまで、一度は耳にしたことのあるデザインパターンではないでしょうか。

「シングルトン」は、あるクラスに対してアプリケーション全体で唯一のインスタンスしか存在しないことを保証するパターンです。一見、「グローバルな共有オブジェクトがあれば便利そう！」と思うかもしれませんが、実は長期的な視点で見た時、シングルトンはしばしば「アンチパターン」として扱われます。

なぜシングルトンパターンが避けられる傾向があるのか。その理由について、今回は分かりやすく解説していきます。

## シングルトンがアンチパターンとされる理由

### 1. 将来的な拡張に弱い「柔軟性の欠如」

シングルトンは「このオブジェクトは1つだけ」とクラス内部で決め打ちする設計です。そのため、後から新たな要求が生まれ、複数インスタンスが必要になった場合、コード全体を大幅に書き直す羽目になります。

例えば、当初は「ウィンドウは一つしか開かない」前提でウィンドウ管理クラスをシングルトンで実装したとしましょう。ところが後で「マルチウィンドウ対応したい」という要件が出てきたらどうなるでしょう？

シングルトン前提の作り込みによって、あちこちで Window.getInstance() のような呼び出しが散在しています。これらを全て「複数ウィンドウを扱えるような形」に書き換えるには、相当なリファクタリングが必要です。「単一インスタンス」という思い込みが、将来的な変更に対する柔軟性を奪ってしまうのです。

### 2. テストが難しくなる「依存関係の不透明化」

シングルトンはグローバルな状態を提供するため、コード中のどこからでもアクセスできるようになります。この一見便利な点が、テストを書く際に大きな障害となります。

通常、テスト容易性を高めるには「依存するオブジェクトを引数で受け取る」ことが重要です。なぜなら、テスト時にモックオブジェクトやテスト用の代替実装を簡単に差し替えることができるからです。

しかし、シングルトンを利用すると、テスト対象のクラスは内部的にグローバルなシングルトンオブジェクトへ依存し、そこを書き換えたり差し替えたりするのが困難になります。結果的に、テストが難しくなり、バグの特定や品質向上が妨げられてしまいます。

### 3. スレッドセーフティ対応の複雑化

アプリケーションがマルチスレッドになってくると、シングルトンはさらに頭痛の種になります。

唯一無二のインスタンスに複数のスレッドが同時にアクセスすると、状態管理で競合やデッドロックを引き起こしかねません。シングルトンをスレッドセーフに保とうとすると、複雑な同期処理が必要です。しかし、スレッドによって動作が変わるような設計は保守が難しく、潜在的なバグを生みがちです。

一方、シングルトンを避け、必要なときに必要な数のオブジェクトを生成する設計であれば、並列処理を前提とした実装も柔軟になります。スレッド安全性を考慮したオブジェクトや、逆に軽量でスレッド同期の不要なオブジェクトを選択でき、設計の自由度が高まります。

## 代替策：依存関係を明示的に渡す設計へ

シングルトンを使わず、必要な場所で必要なインスタンスを生成し、コンストラクタやメソッドの引数として依存性を明示的に渡すアプローチを取れば、多くの問題を回避できます。

```java
// シングルトンを使わない良い例
public class CloseButtonHandler implements ButtonHandler {
    private final Window window;

    public CloseButtonHandler(Window window) {
        this.window = Objects.requireNonNull(window);
    }

    @Override
    public void buttonPressed() {
        window.closeWindow();
    }
}
```

このようにすれば、もし後でウィンドウを増やしたい場合でも、
* CloseButtonHandler に対して別の Window インスタンスを渡すだけで済む
* テスト時にはテスト用の Window 実装を注入することも簡単

となります。

「依存関係が多すぎる！引数が増え過ぎる！」という悩みがある場合は、以下の対処が可能です。
* 真に必要な依存関係だけを渡しているか、再考する
* ファクトリやビルダーを利用して複数の依存オブジェクトをまとめる
* DaggerなどのDIフレームワークで依存注入を自動化する

これらの手法によって、明確な依存関係管理を行いつつ、将来的な変更にも柔軟に対応できます。

## まとめ

シングルトンパターンは一見シンプルで便利に見えますが、
* アプリケーションの成長や拡張による柔軟性不足
* テスト容易性の低下
* マルチスレッド対応の困難さ

といった問題を抱えています。

そのため、シングルトンはしばしば「アンチパターン」として避けることが推奨されます。代わりに、依存関係を明示的に受け渡し、必要であれば依存注入ツールを活用することで、コードの可読性・保守性・テスト容易性が大幅に向上します。

「将来の変更に強く、テストしやすいコード」を目指すなら、シングルトンに安易に飛びつくのではなく、依存関係を明確に、柔軟に扱える設計を検討してみてください。

## 参考文献

https://www.michaelsafyan.com/tech/design/patterns/singleton
OpenChain Japan WG 教育SGのこの1年の活動のご紹介 - 2024

OpenChain Japan WG 教育SGのリードを務めている小泉です。教育SGのこの1年の活動を紹介します。

今年は（というか今後しばらくは）幅を広げるよりも深めることを主眼に活動しています。具体的には、毛色の異なる教材を新しく作成することよりも、既存の教材を周知したり、実際に研修で使ってみたり、そこからフィードバックを得たり、それをもとに改善したりすることを優先する、ということです。

# 教育資料応用編作成

そうは言っても、今現在作成中のものを投げ出すわけにはいきません。
一昨年のアドベントカレンダーから書いているように「OSS教育資料(サプライチェーンリスクマネジメント･バージョン)応用（仮称）」を絶賛作成中です。昨年書いた方針から大きな変更はなく、以下の4章構成で作成しています。（昨年から変わってないです。が、わざわざ昨年のアドベントカレンダーの記事を見直す人もいないかな、ということで再掲です。決して文字数稼ぎではありませんよ。）

1. OSSライセンスの調査
1. ライセンス義務の履行
1. SBOM
1. 脆弱性への対応

各章に担当者を割り振って書き進めているのですが、みなさん、ようやく一通り書けたようです。現在、全体を通してのレビュー中です。「SBOM」までは目を通して、最低でもレビューに対する修正の方向付けまでは済んでいます。残りは「脆弱性への対応」だけですが、今月末に開催される月例の会合できっと終わる（といいな！）と思います。来年度にはGitHubに載せて一般公開できるようになっている（といいな！）と思います。ということで、皆さん期待していてください。

# OLL研修「基礎からオープンソースライセンスを知る！」での発表

自分たちの作った資料を実際に研修で使ってみよう！ということで、[オープンソースライセンス研究所](https://osll.jp/)の[7/16の研修「基礎からオープンソースライセンスを知る！」](https://www.osll.jp/jo89ba1kg-10/#_10)の前半の時間を使わせてもらう形で、[OSS教育資料(サプライチェーンリスクマネジメント･バージョン)ライセンス基礎](https://github.com/OpenChain-Project/OpenChain-JWG/blob/master/Education_Material/Training/OSS%E6%95%99%E8%82%B2%E8%B3%87%E6%96%99(%E3%82%B5%E3%83%97%E3%83%A9%E3%82%A4%E3%83%81%E3%82%A7%E3%83%BC%E3%83%B3%E3%83%AA%E3%82%B9%E3%82%AF%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%EF%BD%A5%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3)%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E5%9F%BA%E7%A4%8E-jp.pptx)を用いて実際に研修を行ないました。
いくつかフィードバックがありましたが、その中に「OSSを社内で使う場合に注意すべきことを教えてほしい」というものがありました。OSSを社内で使うだけなら、ライセンスのことは普通は気にしなくていい（というのは自明だと思っていた）ので、上記の教育資料では触れていませんでした。ただ、同様の質問を最近社内でも受けたので、私たちが思っているほど自明ではないのかもしれません。上記の教育資料は（暗黙の裡に）「そう言うことがすでに分かっている人たち」向けに作っていたことになります。これはこれで悪くないと思っています。が、「自明ではない」と言われると、どこかで説明しておくべきで、そう言えば「そう言うレベルから理解してもらうための資料」って教育SGとしては作ってないように思います。さて、どうしたものか、うーん。

# Open Compliance Summit での発表
すみません。これ、私の勘違いで発表できませんでした。
昨年からの継続で、今年は今年の分の進捗状況を報告するような形で発表しようかな、という構想はあったのですが、私が発表の申し込みをするのを忘れて、結局発表できませんでした。来年頑張ります（かもしれません）。

# 最後に

以上、OpenChain Japan WG 教育SGのこの１年の活動について簡単に紹介しました。現在も、引き続き応用編の作成とレビューを行なっています。皆様の参加をお待ちしています。また、公開済みの教育資料について「実際に社内教育で使った」「業務委託先に参考資料として紹介した」などの声ももらっています。ぜひ皆さんも使ってみてください。そして、感想や意見をいただけると嬉しいです。応用編も完成したら実際に使って研修をしたいと考えています。
さらに、上にも書いたように、「作った資料を実際に使ってセミナー・研修を開催したい」と考えていますので、「セミナー・研修の場を用意できるよ！」とか「セミナー・研修の場として〇〇が適当なのでは」とかあれば教えてください。連絡お待ちしています。
Progate環境でNew Relicを学ぶ - 初心者のための一歩

# はじめに

New Relicは強力なオブザーバビリティプラットフォームですが、「難しそう」「どこから始めればいいかわからない」という声をよく聞きます。
この記事では、Progateの演習環境を使って、New Relicの基本的な使い方を学んでいきます。

## 1. 環境準備

### 1.1 必要なアカウントの作成

1. [Progateのアカウント作成](https://prog-8.com/)
   - 無料プランで十分です
   - 「New Relic を使ってアプリケーションを改善しよう」コースを選択

2. [New Relicの無料アカウント作成](https://newrelic.com/signup)
   - サインアップ時の「主な目的」で「Qiita記事・実践」を選択
   - 無料プランを選択（クレジットカード不要）

### 1.2 Progate環境の概要

Progateの演習環境は以下の特徴があります：
- Ruby on Railsアプリケーションが用意されている
- 基本的なCRUD機能を持つブログアプリ
- 開発サーバーが既に起動している状態

## 2. New Relicエージェントの導入

### 2.1 APMエージェントのインストール

```ruby
# Gemfileに追加
gem 'newrelic_rpm'
```

```bash
# インストール実行
bundle install
```

### 2.2 設定ファイルの作成

`config/newrelic.yml`を作成：

```yaml
common: &default_settings
  license_key: YOUR_LICENSE_KEY
  app_name: "Progate Blog App"
  
development:
  <<: *default_settings
  app_name: "Progate Blog App (Development)"
```

## 3. 基本的なモニタリング

### 3.1 アプリケーションパフォーマンスの確認

1. トランザクション（アクション）毎の応答時間
2. Apdexスコア（ユーザー満足度指標）
3. エラー率

### 3.2 主要な監視項目

1. レスポンスタイム
   - アクション別の平均応答時間
   - スロークエリの特定

2. データベース
   - クエリの実行時間
   - クエリの発行回数

3. エラー監視
   - エラーの発生頻度
   - エラーの種類と詳細

## 4. パフォーマンス改善の実践

### 4.1 N+1問題の検出と改善

Before:
```ruby
def index
  @posts = Post.all
  @posts.each do |post|
    post.user.name  # N+1問題の発生
  end
end
```

After:
```ruby
def index
  @posts = Post.includes(:user).all  # Eager Loading
end
```

### 4.2 キャッシュの導入

```ruby
# コントローラーでのキャッシュ
def show
  @post = Rails.cache.fetch(['post', params[:id]], expires_in: 1.hour) do
    Post.find(params[:id])
  end
end
```

## 5. カスタムメトリクスの追加

### 5.1 ビジネスメトリクスの計測

```ruby
# 投稿数を計測
def create
  @post = Post.new(post_params)
  if @post.save
    ::NewRelic::Agent.record_metric('Custom/Posts/Created', 1)
    redirect_to @post
  end
end
```

## 6. アラートの設定

### 6.1 基本的なアラート条件

1. レスポンスタイムのしきい値アラート
   - 平均応答時間が500ms以上
   - エラー率が1%以上

2. エラー監視アラート
   - 5分間で3回以上のエラー発生

### 6.2 アラート通知の設定

1. Slackへの通知設定
2. メール通知の設定

## 7. ダッシュボードの作成

### 7.1 基本的なダッシュボード項目

1. アプリケーション概要
   - トランザクション応答時間
   - エラー率
   - Apdexスコア

2. データベース状態
   - クエリ実行時間
   - スロークエリ一覧

3. カスタムメトリクス
   - 投稿数推移
   - ユーザーアクティビティ

## 8. 次のステップ

1. 本番環境での活用
2. より詳細なパフォーマンス分析
3. 分散トレーシングの導入

## まとめ

Progate環境でNew Relicを試すことで、以下が学べました：
1. 基本的な監視設定の方法
2. パフォーマンス問題の発見と改善
3. アラートとダッシュボードの活用

この経験を活かして、実際のプロジェクトでNew Relicを活用していきましょう。

## 参考リンク

- [New Relic公式ドキュメント](https://docs.newrelic.com/)
- [Ruby Agent Installation Guide](https://docs.newrelic.com/docs/apm/agents/ruby-agent/installation/install-new-relic-ruby-agent/)
- [Progate New Relicコース](https://prog-8.com/)
windowsでiverilog その159

# 概要　
windowsでiverilogやってみた。
AtCoderやってみた。

# 参考にしたページ

https://qiita.com/mikecat_mixc/items/b8aadfc3053c49feaf18


# サンプルコード
整数 a,b,cと、文字列 s が与えられます。 a+b+c の計算結果と、文字列 s を並べて表示しなさい。
```

module test;
	integer p;
	integer stdin = 'h8000_0000;
	integer a,
		b,
		c;
	integer ch;
	reg [7:0] pc;
	reg [7:0] str[0:9];
	integer v;
	initial
	begin
		pc <= 10;
		v = 0;
	end
	always #1
	begin
		case(pc)
		10:
		begin
			p = $fscanf(stdin, "%d", a);
			pc <= 20;
		end
		20:
		begin
			p = $fscanf(stdin, "%d%d", b, c);
			pc <= 30;
		end
		30:
		begin
			ch = $fgetc(stdin);
			pc <= 40;
		end
		40:
		begin
			ch = $fgetc(stdin);
			str[v] = ch;
			if (ch == 'ha) 
			begin
				pc <= 50;
			end
			else
			begin
				v++;
				pc <= 40;
			end
		end
		50:
		begin
			$write("%0d ", a + b + c);
			v = 0;
			pc <= 60;
		end
		60:
		begin
			ch = str[v];
			$write("%c", ch);
			if (ch == 'ha) 
			begin
				pc <= 70;
			end
			else
			begin
				v++;
				pc <= 60;
			end
		end
		70:
		begin
			$finish(0);
		end
		endcase
	end
	initial
	begin
		//$monitor(" %d", pc);
	end
endmodule



```

# 実行結果

```
>vvp a.out
1
2 3
test
6 test

```

以上
Pythonのsysについて

アウトプット用です

## `sys`ライブラリって何？
`sys`ライブラリはPythonの標準ライブラリの1つでPythonシステムの操作をすることができます。

実行環境に関する情報の取得やコマンドライン引数を使用できたり、エラーメッセージを発生させプログラムを終了させることも可能です。

## 使用方法
以下でモジュールを読み込むことができます。
```Python
import sys
```
## どうやって使うことが多いのか
今回はよく使われるsysモジュールを紹介します。
1. argv()
1. exit()
1. path()

### 1. argv
`sys.argv`はコマンドライン引数をリストとして取得するためのプロパティです。`argv[0]`にはスクリプト名（実行されるファイル名）が入りその後に引数がリストに入っています。

以下は例です。
```practice_sys.py
import sys

argv = sys.argv
print(f"スクリプト名 : {argv[0]}")
print(f"1つ目の引数 : {argv[1]}")
print(f"2つ目の引数 : {argv[2]}")
```
以下が実行結果です。
```
スクリプト名 : practice_sys.py
1つ目の引数 : -n
2つ目の引数 : taro
```

### 2. exit
exitはプログラムを終了させることができるメソッドです。
以下が使用例です。
```squared.py
import sys

def squared_over_twenty(x):
    if x * x <= 20:
        print(f"{x}の2乗は20以上ではありません")
        sys.exit(1)
    else:
        return x * x


if __name__ == "__main__":
    result = squared_over_twenty(3)
    print(result)
```
上記のコードを実行すると以下の結果になります。
```
3の2乗は20以上ではありません
```
exitの引数で
- 0は正常終了
- 1は異常終了(エラー発生)
このようにすることが多いです。

また、exitにそのままエラーメッセージを入れることも可能です。
```python
sys.exit(f"{x}の2乗は20以上ではありません")
```
### 3. path
`sys.path`はリストで格納されている環境変数のPathを確認することができます。以下が使用例です。

親ディレクトリに自作ライブラリが入ったディレクトリがあり、そこからimportしたい時
```
..
|-- python
|   |--x.py
|
|-- sample
|   |--example.py
```
x.pyからsample/example.pyをimportしたい時
```python
import sys
sys.path.append("../sample")
from sample import example
```

このように記載することでimportすることができます。
(備忘録) Node.jsのform-dataモジュールとブラウザのFormDataの違い

安易にAPIのform-dataを消したら、エラーが起きたので、備忘録的に残します。

## 概要

- `FormData`はブラウザで使い、Blob型でデータを渡す
  - Blobはファイルやバイナリデータをブラウザ側で操作する際の標準的なオブジェクト形式
- `form-data`はサーバサイドで使い、buffer型でデータを渡す
  - BufferはNode.jsでバイナリデータを操作するための標準的な形式
- `form-data`は明示的にインポートする必要があるが、`FormData`は標準で使えるので、インポートする必要なし

## FormDataとform-dataの違い

| 特徴                 | form-data (Node.js)                                                | FormData (ブラウザ)                                      |
|----------------------|--------------------------------------------------------------------|----------------------------------------------------------|
| 利用環境             | Node.jsサーバーサイド専用                                          | ブラウザ環境                                              |
| サポートデータ型     | Buffer、ファイルストリーム、通常のテキスト                         | Blob、Fileオブジェクト、テキスト                          |
| getHeadersメソッド   | あり（ヘッダー生成が自動）                                        | なし（fetchやXHRが自動で生成）                             |
| 典型的な使用場面     | サーバーから別のAPIへのファイルアップロード                         | ブラウザからサーバーへのフォームデータ送信                 |
| 明示的なインポート   | 必要 | 必要なし                         |

## 使用例

### Node.js (form-dataモジュール)
  
  ```ts
// 明示的にimport
import FormData from 'form-data';
import fs from 'fs';

const fileData = new FormData();
fileData.append('file', fs.createReadStream('/path/to/file.txt'), 'file.txt');

// リクエストに必要なヘッダーを取得
const headers = fileData.getHeaders();

axios.post('<https://example.com/upload>', fileData, { headers });
  ```

###  ブラウザ (FormData)

```ts
// ブラウザのFile型 (Blobのサブクラス)
const fileInput = document.querySelector('input[type="file"]');
const formData = new FormData();
formData.append('file', fileInput.files[0]);

fetch('https://example.com/upload', {
 method: 'POST',
 body: formData
})
.then(response => response.json())
.then(data => console.log(data));
```

## 参考

https://developer.mozilla.org/en-US/docs/Web/API/FormData/FormData

https://www.npmjs.com/package/form-data