OmniAICreator/Qiita-1.07M huggingface dataset:
なぜAPIは「叩く」のか？

みなさんAPIを作成したことはありますか？またはAPIを使用したことはありますか？日本ではAPIを使用する...APIに送る...とはいませんね？APIを「叩く」という表現をします．「APIを叩く」という表現は，一見すると乱暴で直接的な言葉遣いに思われそうですが，この言葉の背景には，プログラミングの歴史と人間のコミュニケーションの面白い進化が隠されてい偏微分可能ではないでしょうか？本記事では，「APIを叩く」という表現の由来，歴史的背景，そしてその意味合いを深く掘り下げていきます！

> 今回は少し短めです

# 「叩く」という動詞の技術的解釈

「叩く」という言葉は，本来，物を物理的に打つことを意味する．しかし，プログラミングの世界では，この言葉が比喩的に使われるようになった．これは，クリエイティブな言葉の使い方の素晴らしい例だと思う．

# 通信のアナロジー

初期のコンピュータ通信において，通信プロトコルは物理的な通信システムととても似かよっていた．電信や電話の世界では，メッセージを「送る」「叩く」「伝える」という表現が頻繁に使用されていた．この通信のアナロジーが，後にデジタル通信の世界にも持ち込まれたのである．

## APIの歴史的文脈

**1960年代：最初のAPI概念の誕生**

1960年代，メインフレームコンピューティングの時代に，APIの概念が生まれた．当時のプログラマーたちは，異なるソフトウェアシステム間のコミュニケーション方法を模索していた．

**1970年代：リモートプロシージャコール（RPC）の登場**

1970年代には，リモートプロシージャコール（RPC）の概念が登場し，異なるコンピュータ間でプログラムを実行できるようになった．この技術は，「送る」「叩く」「伝える」といったアクティブな動詞のイメージに近く，遠隔地のシステムと対話する方法を提供した．

**1990年代：WebAPIの爆発的普及**

1990年代，インターネットの普及に伴い，WebAPIが急速に発展した．ウェブサービスが増加し，APIを通じてデータをやり取りすることが一般的になっていった．

# APIを叩くという表現の起源(推論)

では，「APIを叩く」という表現はいつから使われ始めたのだろうか?正確な起源や誰が最初に使い始めたのかは明確ではない．しかし，2000年代初頭から中頃にかけて，日本のエンジニアコミュニティで徐々に広まっていったと考えられる．

**1. 迅速で直接的なインタラクション**

まるで扉をノックするというインタラクションを表すように，素早く明確なやり取りを意味しているのではないか？

**2. コマンドライン操作の比喩**

多くのエンジニアがターミナルでコマンドを入力してシステムとやり取りをしていた．その際にキーを「叩く」ことでコマンドを実行するイメージが，「APIを叩く」という表現に繋がったのではないか?

**3. 英語表現の翻訳**

英語圏では"hit an API"という表現が使われており，これを直訳して「APIを叩く」と言うようになった可能性がある．この"hit"には「アクセスする」や「問い合わせる」という意味合いが含まれているのではないか?

**4. 開発現場での俗語としての浸透**

エンジニア同士の会話やチャットで，手軽に状況を伝えるための俗語として「叩く」が使われ始め，それが次第に一般化していったと考えられのではないか？

# 具体的なエピソードと広まり

具体的に誰が最初に「APIを叩く」と言い始めたのかは定かではないが，ブログや技術書，勉強会などでこの表現が使われるようになり，エンジニアの間で広まっていった．特に，ウェブ開発が急速に進む中で，多くのエンジニアがAPIに対するリクエストを頻繁に行うようになり，その行為を手短に表現する言葉として定着していった

# 実際のAPIの使用例

**サーバーとのコミュニケーション**

```bash
GET example.com/hello
```

上記のようなリクエストは，まさに「APIを叩く」行為の典型的な例である．サーバーに対して特定のデータを要求するという，直接的で能動的な行動を表現している．

# シンプルなAPIの作成方法
では，簡単なAPIの実装を見てみよう．

Python(Flask)での例だ．

```python
from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/hello', methods=['GET'])
def hello():
    return jsonify(message='Hello World!')

if __name__ == '__main__':
    app.run(debug=True)
```

このコードでは/helloというエンドポイントを作っている．このエンドポイントにGETリクエストを送る，つまり「APIを叩く」と，「Hello World!」というメッセージがJSON形式で返ってくる．

「APIを叩く」という表現は，ただの技術用語ではない.人間とテクノロジーの創造的な相互作用や，言語の柔軟性，そしてプログラマーたちの独自のコミュニケーション方法を象徴していると思う．この表現は，冷たく見える技術の世界に，人間らしい温かさと遊び心をもたらす，素晴らしい言葉の工夫だと思う．
皆さんも，ぜひAPIを「叩いて」みて，テクノロジーとのインタラクションを楽しんでほしいです！

それではQiitaアドカレ.24企画の今日のクリスマスツリーです．

> 詳しくは[こちら](https://qiita.com/JavaLangRuntimeException/items/1f4a6febf957f522ba45)の記事から

![スクリーンショット 2024-12-14 10.15.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3757442/473268f7-b1d2-c2c2-79cb-d04ca05b2b76.png)
アジャイルを学習できる動画レコメンドサービスを試しに作ってみた

 この記事は[ニッセイ情報テクノロジーPS事業推進室アドベントカレンダー2024](https://qiita.com/advent-calendar/2024/nissay-it-xthinklab)の15日目の記事になります。

https://qiita.com/advent-calendar/2024/nissay-it-xthinklab

 
　前回のアドベントカレンダーで、アジャイルを学習するためのお勧めの動画を紹介しましたが、紹介に加えて、自動で動画をレコメンドしてくれるサービスを作ったので、どんなサービスか、どのように作成したのかを紹介します。

- - -
## サービス内容について
　「[チエノワ（知映の環）](https://recommend.insurtechlab.net/)」というサービスで、無料で公開しているカンファレンスの動画を紹介してくれるサービスとなります。

https://recommend.insurtechlab.net/


　現在は[ScrumTokyoチャンネル](https://www.youtube.com/channel/UCUcKR5NviFsfUgbVSEGncqg)のアジャイル関連のカンファレンス動画を紹介する機能となっており、PO,SM,Dev向けの動画をそれぞれランダムに選んでくれるというものです。
　現在対象となる動画を続々追加中ですので、使っていただきフィードバックがあれば連絡いただけると非常にうれしいです。


## つくるきっかけ
　プロジェクトは、開発者２人、スクラムマスター、PO(私)という体制で進めていて、全員兼務で他のプロジェクトも実施しながら回しています。

　開発者２名が他のプロジェクトの関係で週に４日間タスクが空くというのが実施のきっかけでした。今後の状況も不透明でこの先いつ埋まるかわからない状態のため、流動的に実施できて楽しいことをやりたいという事で、私が作りたいサービスを作らないかと持ち掛けて、企画が始まりました。
　わりと突貫で決まった内容な為、企画構想を１日で、その後デイリースプリントという形で、毎日計画～レビューまで実施しています。

　これが最初につくった仮説キャンバスになります。 

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939762/0cf14cf7-59b7-3fa6-861c-e61574aed29b.png)


　「社内外を繋いで学習する文化を形成する」という常々考えているテーマでサービスを検討しています。（評価指標より下の部分は、ビジネスを考えていないので、雑です・・・)


　もちろんインセプションデッキも作成しています。下記は作成した「我々はなぜここにいるのか」になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939762/a021ba9e-87d4-a340-c363-352769c32a0d.png)

　このプロジェクトは、他のプロジェクトの状況次第で、途中、止まってしまう可能性もあるので、流動的に実施することを大事にしつつ、文化祭のノリで進めようという事にしています。
 　そのため「1dayスプリント」を採用し、今までにやったことないやり方で実験的に進めることを重視しています。
  
  次は「やらないことリスト」です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939762/8f442441-755d-9ab7-dbd3-94e6063e02c7.png)




  
　「やらないことリスト」は皆でやりたい事をあげ、その後で、やりたい事とやらないことを上記マトリクス（やらないことリスト）に配置することで認識を合わせるようにしています。

## 1dayスプリント
　我々は1dayスプリントという事で、朝15分でプランニング、夕方30分でレビュー＋レトロという形で進めています。
　色々と試行錯誤しながらの状態ですが、メンバーがこじんまりとしていて意思決定が早く済むのととりあえず毎日何らかのサービスを上げて、積極的にフィードバックをもらおうという形でやっていて楽しく進められています。サービス自体がライトなので非常にマッチしていると思います。
 
　実施してみて、毎日のゴール設定が、その日のモチベーションやレビューの盛り上がりにつながるのでゴール設定大事だと改めて感じています。ゴール設定についてはスクフェス大阪2024の「「+JOY」はじめは熱々だったはずなのにだんだん硬くて冷たくなっていく目標に血を通わせる工夫」を参考にゴールとJOYという形で考えています。
 
　気後れするような高いゴールを設定しようと思いつつ、実際は日和って出来ることを上げがちですが、毎日ゴール設定が必要なので非常に良い練習になると感じています。（下記は具体的なゴールの事例です)

:::note info

<strong>GOAL</strong>：デザイン対応の内容が本番に反映できていて、良くなったことが確認できている

<strong>JOY</strong>：デザインの改善についてデザイナーさん無でも自分達でも一定出来る！ラボのメンバーにフィードバックを受けたカイゼン結果をアナウンス出来る
:::


　というわけでサービス内容や、実施している内容の紹介でした。12月中にSCRUMTOKYOの全動画を載せられると思いますし、12月中にもう少し使用者を意識した機能追加をできればと思っています。
 
 

　読んでいただきありがとうございます。是非サービス見てもらってお気に入りの動画見つけてもらったり、フィードバックをもらえると嬉しいです。
クライテリアコントロールの話

## 品質基準をコントロールする？
「普通にテストするだけでも大変なのに、コントロールなんてできるのか？」  
という疑問を持たれることもあるかもしれませんが、テストのボリュームは  
設計とポリシーに依存するため、ここのバランスをコントロールしたうえで  
調整するというやり方もあります。  
今日はそんなお話です。

## 目標を決める
"品質は、経営者が決定するもの"、とは古くから言われてきましたが、  
理由は、品質はタダではなく、保証にお金がかかるものであり、  
そのリソースに出資するかどうかは経営判断だから、ということでもあります。  
これを軽視したあまり、事故になってしまった例もあります。  
また、国際的なソフトウェアカンパニーにおいても、QAを解散した結果、
品質がガタ落ちし、  1か月後に再度QAチームを編成し直した、
という話を聞くこともあります。

では、経営とも切っても切り離せない品質について、  
どうやって目標を決めるのでしょうか？  
これには、いくつかの基準があると思っていて、  
- 最低限お客様が使えればよい  
- 多種多様なお客様が使えなくてはならない  
- 社内の人間が使えればあとは困らない  

など、製品のユーザーに対しての品質要件から、必要なクライテリアを設定します。

例えば、一瞬見れば仕様としては足りるものであれば、複雑な操作はいらないかも
しれませんし、  十分に知識のあるエンジニアが使うのであれば、
すべてのコンパチビリティ環境で動作しなくてはいけないような、
過剰な品質はいらないでしょう。

ユーザーにとって必要十分な品質を想定し、それを守るための戦略を組み立てます。  
その一つが、以前記述した、[[自分のテストフレームワークを作ろう！]](https://qiita.com/EgaSaQA/items/1eb643ebda0cceafa4bb)  
にも載せた、マップがそれで、これはテストストラテジーに合わせてどういった  
テストを当てるかのマップです。
（このマップは、どちらかというと戦術に近いものになります。）

![TestStrategy2023.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/156898/ad18428b-4ae7-605e-daf8-d1f4f0ec9f7b.png)

## どうやって品質をコントロールするか
さて今日のテーマの、「どうやって品質をコントロールするか」ですが、  
最初にやることは、「守るべき品質を定める」です。

これには、  
- 当たり前品質か、できれば品質か（狩野モデル）  
- 夜も眠れない心配な事（インセプションデッキ）  

など、テストしようとしている内容が、どのくらいシステムにとって
重要かを見通しておきます。

### リスクコントロール
リスクを許容できる、「やらないこと」を決めることも大事です。  
これは、IEEE29119でも重要視された内容です。  
私は、  
- プロジェクトリスク  
- プロダクトリスク  
- カンパニーリスク（29119外）  

の3つを、テスト計画を作る際に決めています。

IEEE29119の説明は、この[リンク](https://www.veriserve.co.jp/asset/approach/column/test-technique/software-test04.html)が良いでしょう。

「やらないこと」を決めるということは、やらないことによるリスクを
判定しているわけで、  これをステークホルダーに共有し、合意を得ます。  
スクラムの開発現場では、長い連携の中で、合意が重なって  
不文憲法のような決まり方をしている場合もあります。  
各チームのやり方で、守るべき品質と、守らない場合のリスクを整理しておきます。

### リソースとの兼ね合いを見極める
こうして、「守るべき品質」が決まったら、実際に守っていく戦略を立てます。  
これには、自分たちの手持ちのリソースの分析と、実際に手を動かしながら調整する  
テストコントロールが鍵になります。

### チームのテスト消化のスピードを確認する
とはいえ、無限に風呂敷を広げてテストを増やすわけにはいかないため、  
どうしても守らなければいけないものを考えます。  
普段のテスト消化率、スピードを把握し、全体のパフォーマンスを  
母数として持っているうえで、以下の要点から、全体のQA活動を調整します。  
テストの内容・かかる時間は不定ですから、私はシンプルに、  
テストケースの消化数と時間の相関関係、テストの個別の難易度を、  
テストの種類ごとに、普段のチームのパフォーマンスから見ています。  
これと、作業に使える時間を計算して、どのくらいのテストができるかの
総量を見積もります。

### テストの階層と品質の関係を見極める
クオリティコントロールのポイントの一つに、組み合わせテストの階層をどこまで見るか、  
というのがあります。単純に、組み合わせが多いと、"組み合わせ爆発"という言葉が
あるように、テストの工数が膨大に膨れ上がってしまいます。

一方で、Web系製品の不具合は、複数の原因から起こる不具合が多いという  
特徴がありますので、単純に減らすわけにはいきません。  
組合せテストと、ユースケースのテストのバランスで、ボリュームを整えます。

そして、守るべき品質を確保するのに期日が足りない場合、  
テストを削るか、スケジュールを伸ばすかの選択を求められるでしょう。  
この際に、リスクを合わせて説明し、決定するための資料を作ることが
できるようになります。

### テストの進捗をコントロールする
実際のテスト実行フェーズでは、意図せずインフルエンザが流行したり、  
家族の体調不良など、不測の遅延リスクが発生することは通常の事です。  
このため、テストケースの優先順位をつけて対処したり、リカバリープランを  
常に柔軟に用意することになります。ここでも、先に決めておいたリスクについての  
合意事項が判断の役に立ちます。

テストコントロールは、QAエンジニアとしては、わりと上級のスキルとなるでしょう。

こうして、クライテリアと現実的なリソースをコントロールしながら  
リリースまで進めます。

#

### 用語解説
#### 狩野モデル
QAエンジニアの間では、あまりにも有名。  
品質には、当たり前に守られるべきものと、製品を使う動機になるような、
魅力的品質があるというお話。  論文は数千円から買えます。  
https://ja.wikipedia.org/wiki/%E7%8B%A9%E9%87%8E%E3%83%A2%E3%83%87%E3%83%AB

#### クライテリア
ここでは、開発で守ると定めた基準。
『入門 監視』第二章 メモ

# はじめに
アプリケーションの「監視」についてまとめた名著である、[『入門 監視』](https://www.oreilly.co.jp/books/9784873118642/)を読み始めました。
記憶定着のため、簡潔に各章をまとめてアウトプットしてみようと思います。
第一章も読みましたがメモが手元に無いのでひとまず二章から…

# 項目まとめ

## 2-1 組み合わせ可能な監視
### 監視サービスのコンポーネント
下記項目によって構成されるが、モノリシックなツールでもこれらの要素が含まれる。
- データ収集
- データストレージ
- 可視化
- 分析とアラート
- アラート 

印象的なのは可用性の項目。
仮にシックスナイン(99.9999%)の可用性であっても、__年間ダウンタイム31秒__ を考慮しておく必要がある。
__可用性100%は現実的でない。__

## 2-2 ユーザー視点での監視
### ユーザーに最も近い部分で監視する
__ユーザーに最も近い部分__ とは下記のようなものが挙げられる。
- レスポンスコード(500系エラー)
- リクエスト時間(レイテンシの状況)

当たり前ではあるが改めて大切であると実感できる。
また当然、上記だけではなくミドルウェアやDB領域へも監視を広げていくことを意識すること。

## 2-3 作るのではなく買う
監視の初歩としてSaaSを使う形から自作ツールへ移行することもある。
ただし、下記理由から基本的にはSaaSを使う方が良い。
### コスト
結局のところ自作ツールは作成に対しても、保守に対してもコストが掛かってくる。
- 作成工数
- 保守コスト

### 私たちはSaaSの専門家ではない
__餅は餅屋である。__
専門で監視のことを考えている人たちに頼るのが吉。

### プロダクトフォーカス
自作ツールを作成する場合、どんなに早くても数日は掛かってしまう。
ドキュメント等の準備も考えるとSaaSを使うほうが手っ取り早く、プロダクト自体にフォーカスすることができる。

### 結局SaaSの方が良い
下記のような理由からSaaSを敬遠する人もいるかもしれない。
- プロダクトに対してSaaSの監視機能が物足りない
- セキュリティ・コンプライアンスの点を懸念

しかしながら上記については実際には __稀な話__ である。
コスト面が理由になることもあるが、これも __偏った考え__ で拒否しているに過ぎない(アメリカ政府ですらSaaSを使用している…)
__自前の構築チームの方が低コスト__ とでも言うのだろうか…

## 2-4 継続的改善
どのような企業でも1週間程度で監視環境を構築してきたのでない。
__年単位での継続改善__ によって現在の環境を作り上げてきている。
変化に応じて改善を継続することが重要だ。

# おわりに
当たり前のことから、「言われてみれば…」という点までためになる章でした。
特に __2-4 継続的改善__ には一人のエンジニアとして励まされると同時に、「努力しないとな…」となる項目でした。
今後も監視についての勉強を継続していきます。
今一度基礎からアウトプットしていこう。バイナリファイル・拡張子編

### 「exeファイルがunixで動く訳ないじゃん！！」
恥かいた。
## バイナリファイル
コンピュータが読み込めるように0と1で分解したファイル。
OSによって読み込めるバイナリファイルの違いがある。
以下はこのバイナリファイルの種類だ。

### 実行可能ファイル（Executable Files）
**概要**  
プログラムとして直接実行可能なファイル。

**例**  
- Windows: `.exe`  
- Linux/Unix: ELF形式のバイナリファイル  
- macOS: Mach-O形式  

**特徴**  
- 機械語で書かれた命令が含まれており、CPUが直接実行可能。  
- OSに依存する形式で、他のOSでは実行できない場合が多い。

---

### ライブラリファイル（Library Files）
**概要**  
プログラムから利用される関数やリソースを含むファイル。

**例**  
- Windows: `.dll`（Dynamic Link Library）  
- Linux/Unix: `.so`（Shared Object）  
- 静的ライブラリ: `.lib`（Windows）、`.a`（Linux/Unix）

**特徴**  
- プログラムから呼び出されて利用されるため、単独では実行できない。

---

### データファイル（Data Files）
**概要**  
特定のアプリケーションが利用するデータを格納。

**例**  
- 画像ファイル: `.png`, `.jpg`, `.bmp`（画像データ）  
- 動画ファイル: `.mp4`, `.avi`, `.mov`（動画データ）  
- オーディオファイル: `.mp3`, `.wav`（音声データ）  
- 圧縮ファイル: `.zip`, `.tar.gz`（圧縮されたデータ）

**特徴**  
- ファイル形式に応じたアプリケーションでのみ適切に解釈される。

---

### 設定ファイル（Configuration Files）
**概要**  
プログラムやシステムが利用する設定情報を含むバイナリファイル。

**例**  
- `.bin`, `.dat`（独自形式での設定データ）

**特徴**  
- 特定のソフトウェアで読み取られる専用形式で保存。

---

### 仮想マシンやエミュレータ用ファイル
**概要**  
仮想マシンやゲームエミュレータで使用されるバイナリデータ。

**例**  
- 仮想マシンディスクイメージ: `.vmdk`, `.qcow2`  
- ROMファイル: `.iso`, `.gba`, `.nes`（ゲームやCD/DVDのデータ）

**特徴**  
- 仮想環境やエミュレータで実行・読み込み可能。

---

### ドライバファイル（Driver Files）
**概要**  
ハードウェアを動作させるためのソフトウェアを含むファイル。

**例**  
- Windows: `.sys`  
- Linux: カーネルモジュール（`.ko`ファイル）

**特徴**  
- OSがハードウェアを制御する際に使用。

---

### フォントファイル（Font Files）
**概要**  
フォントデータを格納するバイナリファイル。

**例**  
- `.ttf`（TrueTypeフォント）  
- `.otf`（OpenTypeフォント）

**特徴**  
- テキストを特定の書体で表示するために使用。

---

### バイナリ形式のドキュメントファイル
**概要**  
ドキュメントデータを効率的に保存するためにバイナリ形式で格納。

**例**  
- Microsoft Word: `.doc`, `.docx`  
- Microsoft Excel: `.xls`, `.xlsx`  
- Adobe PDF: `.pdf`

**特徴**  
- ドキュメントの内容を圧縮したり、リッチな形式を保存する。

---

### 仮想実行環境用ファイル
**概要**  
バイトコード形式で保存された中間形式のファイル。

**例**  
- Java: `.class`（JVM用）  
- .NET: `.dll`, `.exe`（CIL/IL形式）

**特徴**  
- 仮想マシン上で実行可能。

---

### バイナリファイルとテキストファイルの違い
| 項目        | バイナリファイル              | テキストファイル                  |
|-------------|-------------------------------|-----------------------------------|
| **内容**    | 0と1で構成されたデータ        | 人間が読める文字列               |
| **編集**    | 専用のツールが必要            | テキストエディタで編集可能       |
| **例**      | `.exe`, `.dll`, `.png`, `.zip`| `.txt`, `.csv`, `.json`, `.xml` |
| **用途**    | 実行可能ファイルやリソース、データの保存 | 設定やデータの記述、プログラムのソースコード |

いやごめんChatGPTさんの力を使ってしまった。
極力ソースは参考書や技術書から引用したいけど、たまにこのような事もします。

### 所感
そう思うとbatファイルやcshファイルはテキストファイルでありながら実行することができて中身もすぐに閲覧編集可能・・・めちゃ使いやすいんだなって痛感したよ。
起業するならElixirシリーズSTEP16. 事業戦略

https://qiita.com/Yoosuke/items/49b92163971cfce08e5c

前回の続きです

経営戦略を作り、経営戦略に必要な機能を特定し、機能を実現する組織を設計したら次は、事業戦略と機能戦略を創る必要があります。

今回は事業戦略について考えていきましょう。

## 事業戦略

事業戦略とは、企業が各事業分野で競争優位性を確立し、持続的な成長を実現するための具体的な計画です。以下の要素を中心に展開していきます

### 事業ドメインの定義
* 顧客は誰か（Who）
* 顧客のどのようなニーズに応えるのか（What）
* どのような方法・技術で提供するのか（How）
を明確にし、事業の範囲と方向性を定めます。


### 競争戦略の策定
* 市場での位置づけ（ポジショニング）の明確化
* 差別化要因の特定（品質、コスト、スピード、ブランド等）
* 競合他社との関係性の設定（競争、協調、すみ分け等）

### ビジネスモデルの構築

* 収益構造の設計（収益源、価格設定、コスト構造）
* バリューチェーンの最適化
* リソース配分の決定（人材、設備、資金等）

### 成長戦略の立案

* 市場浸透（既存市場・既存製品）
* 市場開発（新市場・既存製品）
* 製品開発（既存市場・新製品）
多角化（新市場・新製品）

### リスク管理

* 市場リスクの分析と対応策
* 技術リスクの評価と対策
* 競合リスクへの対応

### KPIの設定と評価システム

* 財務指標（売上、利益、ROI等）
* 非財務指標（顧客満足度、市場シェア、品質指標等）
* PDCAサイクルの確立

このような内容を作成していきます。このシリーズで伝えてきたプロセスでは、最初のターゲットを決めて、MVPを作り、起業フェーズを終えて経営戦略を作ってきての流れを説明してるので、この事業戦略については経営フェーズを扱います。

この段階になると、持続的な成長とスケールを実現するための体系的なアプローチが必要になってきます。

### 【Phase 1: 現状分析と目標設定】
* これまでの実績の体系的な分析
* 売上の内訳（顧客セグメント、製品・サービス別）
* 利益構造（固定費、変動費の詳細分析）
* 顧客フィードバック、解約理由の整理
* 成功事例・失敗事例の要因分析
* 市場環境の詳細分析
* 市場規模と成長率の把握
* 競合他社の動向調査
* 業界トレンドの分析
* 規制環境の確認
* 中期目標の設定（3-5年）
* 売上・利益目標
* 市場シェア目標
* 顧客数目標
* 組織規模目標

### 【Phase 2: 成長戦略の策定】
* コアビジネスの強化
* 既存製品・サービスの改善点特定
* 価格戦略の最適化
* 顧客満足度向上施策
* オペレーション効率化
* 新規事業展開の計画
* 新規市場への展開計画
* 新製品・サービス開発計画
* クロスセル・アップセル戦略
* 戦略的提携の検討
* リソース配分計画
* 必要な人材の特定と採用計画
* 設備投資計画
* システム投資計画
* 研究開発投資計画

### 【Phase 3: 実行体制の構築】

* 組織体制の整備
* 部門構成の設計
* 役割・責任の明確化
* 意思決定プロセスの確立
* 評価・報酬制度の設計
* マネジメントシステムの構築
* KPIの設定と管理体制
* 予算管理システム
* リスク管理体制
* 品質管理体制
* 人材マネジメント体制
* 採用システムの確立
* 教育研修制度の整備
* キャリアパスの設計
* 評価制度の確立

### 【Phase 4: モニタリングと改善の仕組み作り】

* 進捗管理の仕組み
* 定期的なレビュー会議の設定
* 報告システムの確立
* 課題管理の仕組み
* フィードバックループの確立
* 市場動向の把握体制
* 顧客の声を集める仕組み
* 競合情報の収集体制
* 市場トレンド分析の定期実施
* 技術動向の把握
* 改善・修正プロセス
* 戦略の見直しタイミングの設定
* 計画修正の判断基準
* 緊急時の対応プロセス
* イノベーション促進の仕組み

まぁ、並べるとたくさんありますよね。実際にはこれ全部を一気に準備するほど優秀な人はいないので、少なくとも僕は無理なので、優先順位をつけてミルフィーユを作るような形でサイクルを回しながら作成していく形で進めています。

当然、先に進む中で新たな条件や知見が得られて、戦略を見直すような動きもしてるので、３歩進んで２歩下がるというイメージで進んでるような気がしてます。
Docker Compose Fileにversionsは書くなって話

docker desktop for macをupdateしたら警告文が出るようになりました

## 今回発生した警告文
the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion

![画像.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1390680/dd8f5184-bda8-ad21-fc05-6cabb476f38f.png)


上記は`compose.yml`でversionsは古いから使わないでねと言う警告でした
```shell
versions: '3.8' ← # 廃止
```

じゃどのversionが使われるのよ。と思ったのですが、常に最新のものが使われるようです。

## docker-compose.yml 
ついでに知ったのですが、docker-compose.ymlはもう古いらしいです。
compose.ymlに命名を変更する必要がありそうです。

## 参考
https://forums.docker.com/t/docker-compose-yml-version-is-obsolete/141313
【TS】Classについて


## シングルトン
```ts
class Person {
  // シングルトンインスタンス用のプロパティ
  private static instance: Person;
  
  // staticはクラスそのものに属し、インスタンスには属さない
  // getter,setterはインスタンスに属する
  get name() {
    return `${this._name}です`;
  }

  set name(value) {
    this._name = value;
  }

  // コンストラクタを外部非公開
  private constructor(private _name: string) {}

  static getInstance() {
    if (!this.instance) {
      this.instance = new Person("KEN");
    }
    return this.instance;
  }
}

const person = Person.getInstance();
console.log(person.name);
```


## Static（クラスメソッド/クラスプロパティ）
Staticはclassに属し、インスタンスには属さない。
そのためstaticメソッド内の`this`はクラスの

```ts
class Person {
  // インスタンスプロパティ
  name: string;
  age: number;

  constructor(_name: string, _age: number) {
    this.name = _name;
    this.age = _age;
  }

  getName() {
    console.log(this.name);
  }

  // staticメソッド
  static getAge() {
    // エラー発生：このthisはクラスプロパティなのでageが存在しない。
    console.log(this.age);
  }
}
```

利用したいプロパティをクラスプロパティ(static修飾子をつける)にすればOK
```ts
class Person {

  // インスタンスプロパティ
  name: string;

　// クラスプロパティ（staticプロパティ)
  static age: number = 30;

  constructor(_name: string) {
    this.name = _name;
  }

  getName() {
    console.log(this.name);
  }

  static getAge() {
    console.log(this.age);
  }
}
```

## NULL許容なコンストラクタ
```ts:
class Animal {
  constructor(
    public name: string,
    public age?: number,
    public gender?: string
  ) {}
}

const kotaro = new Animal("kotaro", 5);

// 第2引数をスキップしたいなら、undefinedを指定
const shiro = new Animal("shiro", undefined, "man");
```

```ts:NULL許容は非NULLの前にはつけられない

// 必須パラメーターを省略可能なパラメーターの後に指定することはできません。
class Animal {
  constructor(
    public age?: number,
    public name: string,
    public gender?: string
  ) {}
}

```
Arty A7で自作riscv-rv32iを動かす②　DRAMでDキャッシュのみ版

# 始めに
前回Tang Primer用にriscv-rv32iのコアを起こしてから3年、Aary A7であれば情報が多いため、DRAMを使ってより広いスペースでプログラムを動かせるように拡張をしてみました。機能は前記事[Tang PrimerまたはArty A7で自作riscv-rv32iを動かす](https://qiita.com/yoshiki9636/items/f6043556439b5df7d8ce)と大きくは変わらず、data ramをデータキャッシュ化してDRAMを接続し、data ramとして128MBの空間を使えるようにしました。これに伴い、instruction ram側にBRAMリソースを割り振り、より大きなCプログラムが動作するようになりました。安定動作しつつあるので、公開することにしました。今回レポジトリを新たに作成して前のSRAM版と共存させていくことにしました。

# レポジトリ

[https://github.com/yoshiki9636/my-riscv-rv32i-dc](https://github.com/yoshiki9636/my-riscv-rv32i-dc)

# 参考URL

[Tang PrimerまたはArty A7で自作riscv-rv32iを動かす](https://qiita.com/yoshiki9636/items/f6043556439b5df7d8ce)
[Arty A7でAXIバス簡略仕様でDDR3 SDRAMへ読み書きしてみる](https://qiita.com/yoshiki9636/items/aaf06d56749ad161fbcd) ※MIG設定の参考
[VivadoでMIG+DDR3のシミュレーションの走らせ方メモ&ModelsimでのMIGシミュレーションの走らせ方追加](https://qiita.com/yoshiki9636/items/804dd22848ad924fda85) ※MIGシミュレーション参考


# Ver 0.4の機能・制約
- 単純なダイレクトマップのDキャッシュを実装
- instruction memoryはSRAMのままのため、ハーバートアーキティクチャのまま
- I/Oは4セットのRGB LED、12ピン
- uartモニターにzコマンド(Dキャッシュのパージ)を追加
- Uartでの表字をI/Oで実現
- interruptピンを使った外部割込み（単体）、mretの実装を追加
- illegal operations exceptionを追加
- privilegeはM-modeのみ
- fence系、ecall以外のecall系未実装
- gccのrisc-vツールチェーンでのベアメタルCの動作確認済み

# 使い方
特に変わっていないので、[githubページ]([https://github.com/yoshiki9636/my-riscv-rv32i-dc)のReadmeまたは、[前回のページ](https://qiita.com/yoshiki9636/items/f6043556439b5df7d8ce)を参考にしてください。以下は連立方程式を解くプログラムsimequ_test.cを実行してみたところです。4元１次方程式を解いています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/575990/b8821c15-7f65-0f97-d392-1763d412eb8b.png)

# 終わりに
手抜きの短い記事ですが、論理の方は2024年1月に着手してうまくいかずだいぶ放置していたため、非常に時間がかかってしまいました。次はIキャッシュですが、いつになるかはちょっと想像つかないところです。あとはタイマーやアトミック命令などサポートが必要と考えられますが、趣味のプログラミング、ぼちぼちやっていこうと思います。
教育現場でも活用されるFigJamを初心者が試してみた

## はじめに
今回下記アドベントカレンダーに参加したのでFigmaに関する記事を書きたいと思います。

https://figjamqiita.com/advent-calendar/2024/figma-design


Figjamというものを適当に触るだけでは意味がないかと思ったので👇YouTubeを参考に進めていきたいと思います。（再生数が多く、最新版のものを選択してみました。）

[【2024年最新】FigJamの教科書〈最速で使い方をマスターするFigJamの教科書〉](https://www.youtube.com/watch?v=e6iDiJJAvt0)



## さっそく使ってみる
・ログイン後ファイル一覧の右側「新規作成」ボタンを押すと「Figjam」が表示されるのでこちらを選択します。
・すると、ドット方眼紙と下にツールタブが配置された新規ページへ遷移します。
[![Image from Gyazo](https://i.gyazo.com/590f9aafc13c0b23dd64f58308c2a60d.png)](https://gyazo.com/590f9aafc13c0b23dd64f58308c2a60d)


## テンプレートの利用
[![Image from Gyazo](https://i.gyazo.com/a7c2845e8238ce910a2ff420b440a6a0.png)](https://gyazo.com/a7c2845e8238ce910a2ff420b440a6a0)

👆上記画面の下にあるツールバーから「+」ボタンを選択するとテンプレートが表示されることを確認できます。（動画内では左上から選択していました。）

・次に、**Figjamの公式テンプレート**を自分の所に反映させて編集できるようにしていきます。
・まずは動画内のとおり[教育向けテンプレート](https://www.figma.com/@education_japan)へ移動。「FigJamの使い方」を選択し、「FigJamで開く」をクリックします。すると下記画面のようになります。

[![Image from Gyazo](https://i.gyazo.com/129701e273b70bec1e75af946dc0e942.png)](https://gyazo.com/129701e273b70bec1e75af946dc0e942)


## 描画ツール
[![Image from Gyazo](https://i.gyazo.com/ccee3099d62eccb07d024b92caedc1b3.png)](https://gyazo.com/ccee3099d62eccb07d024b92caedc1b3)
・描画ツールではペン、マーカー、和紙テープ、消しゴム等があります。
・マーカーは重ね塗りをすることが可能で、重ね塗りをすることで色の濃さが増します！
・和紙テープでは選択後、ツール一番右にある「+」ボタンを押すことで自分のファイルからインポートすることが可能です。
・ペンのサイズや色の変更、沢山あって便利です。


## 付箋と図形
[![Image from Gyazo](https://i.gyazo.com/6b203682de08c7311d482a7d534785d1.png)](https://gyazo.com/6b203682de08c7311d482a7d534785d1)
・ツールバーの付箋を選択して好きなところにドラッグすることで貼ることができます
・配置してから付箋の色、図形の形を変更することが可能。
・付箋は状況に応じて作成者の名前の表示非表示が可能です！

## テキスト/コネクター
[![Image from Gyazo](https://i.gyazo.com/4bb78bda286c1191d944b9e47dce7185.png)](https://gyazo.com/4bb78bda286c1191d944b9e47dce7185)
・文字を配置した後、その文字をクリックするとFigjamAIというものを選択することが可能。自動で内容を生成してくれる（ただし英語）
・図形同士をコネクターでつなげることができる。


## セクション/テーブル
[![Image from Gyazo](https://i.gyazo.com/3dbeaaf0c4299c353176dac9fe0d8ef9.png)](https://gyazo.com/3dbeaaf0c4299c353176dac9fe0d8ef9)
・セクションの中に配置したものはまるごと移動できる。
・テーブルは後から「+」ボタンでどんどん拡大することが可能！


## スタンプ/ステッカー
[![Image from Gyazo](https://i.gyazo.com/b71277fca4c37c023a3d3245117e53f6.png)](https://gyazo.com/b71277fca4c37c023a3d3245117e53f6)

[![Image from Gyazo](https://i.gyazo.com/cb24a46b5563a2fb02deac037ab20ff6.png)](https://gyazo.com/cb24a46b5563a2fb02deac037ab20ff6)
・スタンプと顔文字は8種類から選択可能。大きさの変更もできます
・ステッカーはスタンプに比べ種類が豊富です！こちらもサイズ変更が可能


## 画像と動画の挿入
・画像はドラッグアンドドロップで持ってくるだけ！！
・動画もURLをコピペして貼ればいいだけ！！


## ファイル共有とウィジェット
動画参考。
・ウィジェットはいろんなものがあるので楽しめそうです


## さいごにまとめ
FigJamを使ってみて、直感的な操作性や豊富な機能に驚きました。また、Figma公式の教育向けテンプレートを活用すれば、初心者でもスムーズに始められると感じました。さらに、教育現場で小学生も活用していることを知り、ツールの可能性の広さに感動しました。これからもFigjamだけに限らず、さまざまなツールを試してみたいと思います。
TypeScriptの型アノテーション(:)と型アサーション(as)は違いって?

TypeScriptで型を宣言するときに

```typescript
const data :Datatype 
```
とする方法と
```typescript
const data = getData() as Datatype;
```

の二つあると思います。

これ2つとも似たようなことできるけど、どう使い分けたらいいのか気になったので調べてきました。

# 型アノテーション

>アノテーションは注釈という意味を持ちます。

型アノテーションでは、コンパイラに対してこの変数はどのような型であると明示的に伝えることができます。

```typescript
let num :number;
num = 123;
num = 123.456;
num = '123'; // Error
```

:::note
### コンパイラとは
プログラミング言語をコンピュータが読めるように別言語に書き換える作業のこと。

TypeScriptではJavaScriptに変換している。
:::

# 型アサーション
>アサーションは自己主張という意味を持ちます。

型アサーションは、すでに変数に対して型推論された型を上書きすることを言います。

:::note
### 型推論
変数に対して、型アノテーションで型を明示的に宣言していない場合に、コンパイラが型を予測して決定してくれる機能のこと
:::

asをつけることで、その後に指定した型に上書きしてくれます。

```typescript
const user = {} as User;
```

# あまり型アサーションは使わない方がいい!

型アサーションの説明でなんとなく「上書きかぁ~なんかそれだと最初から宣言してる型アノテーションの方が良さそう」となった方が多いと思います。

一般的に型が決まっているなら型アノテーションで統一した方がいいと言われています。

## コンパイルエラーを出してくれない

TypeScriptの強みはなんといってもJavaScriptと違ってコンパイルエラーを出してくれるので、ランタイムエラーを起こしにくくしている点です。

型アノテーションでは、しっかり型が違っていたらコンパイルエラーを出してくれます。

しかし、型アサーションはどのような型も上書きしてしまうことができるため、ランタイムエラーを引き起こす可能性があります。

## プロパティの追加を忘れてもコンパイラが指摘してくれない

型アノテーションを使うとプロパティに値を入れていなかった時にコンパイラはエラーを吐きます。

```typescript
type User {
    name: string
}

const user: User = {};
```

```zsh:zsh
TS2741: Property 'name' is missing in type '{}' but required in type 'User'.
```

しかし、下のようにasを使うとコンパイラは指摘せず、動作してしまいます。

```typescript
type User =  {
    name: string
}

const user = {} as User;
```

# まとめ
型アノテーションと型アサーションの違いは下のようになっています。

|名前|役割
|---|---
|型アノテーション|型を明示的に宣言できる
|型アサーション|型を上書きできる

コンパイラがあることによるランタイムエラーの軽減がTypeScriptの良い点だと思うので、基本的に型アノテーションを使った方が良さそうですね。
AtCoder ABC 384 E - Takahashi is Slime 2

はじめてコンテスト中に、4完の後、5問目の解法までたどり着いたけど、時間切れで実装しきれなかったのが悔しかったので、やりたかった解法があっているのか確認するために実装したコードを晒しておきます。

## 考えたこと

* （入力例 1の解説を見ながら）高橋くんの強さの上がり方は単純な加算だから、取り込むスライムの順は関係ありません、と
* ということは、単純に一番弱いスライムを取り込んでいって、まったく取り込めなくなったら終了でいいかな？
* （しばらく考察）うん、問題に「ありえる最大値」とはあるけど、複数のケースから最大値を探すとかは必要なくて、単純にいくつまで強くなるか考えればいいやつ
* 基本の BFS の queue を priority_queue に変えて、何もできなくなったら終了するようにすればいいかな
* （入力例3が WA になったのでログ入れて観察） ああ、吸収済みのマスの情報が前に別の契機でキューに入っちゃってるパターンがあるのか
* 面倒くさいから、吸収済みのマスの情報が出てきたらスキップすればいいや

![que-13304336973.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798407/40cb515e-45ea-c705-1848-c7b47dfbde13.png)
↑ 脳内の高橋くんのイメージ(諸星大二郎『生物都市』より)

## サンプルコード

```c++:Main.cpp
#include <bits/stdc++.h>
using ll = long long;
using namespace std;

// フロア  マスにはスライムの強さ
//  高橋くん吸収済み: -1
//  未使用マス      : LLONG_MAX
ll gFloor[509][509];

// スライム
struct Slime
{
	int p;		// いる座標
	int q;		// いる座標
	ll power;	// 強さ
};


int main( void )
{
	// フロアの状態を初期化
	//  使っていない部分が高橋くんに吸収されないように
	//  極大の値を入れておく
	for( int i = 0; i < 509; ++i)
	{
		for( int j = 0; j < 509; ++j)
		{
			gFloor[i][j] = LLONG_MAX;
		}
	}

	// 入力
	int H, W, X, P, Q;
	cin >> H >> W >> X >> P >> Q;
	for( int i = 1; i <= H; ++i)
	{
		for( int j = 1; j <= W; ++j)
		{
			cin >> 	gFloor[i][j];
		}
	}

	// BFS もどきを実施
	// 高橋くんの初期化
	ll takaPower = gFloor[P][Q];
	gFloor[P][Q] = -1;

	// priority_queue に弱い順に並べてもらうための比較関数
	auto CompSlime = [](const Slime & a, const Slime & b)
	{
		return a.power > b.power;
	};

	// スライムを弱い順に取り出すためのキュー
	priority_queue<Slime, vector<Slime>, decltype(CompSlime)> pq(CompSlime);

	// 最初に隣あっているスライムをキューに突っ込む
	//  ちゃんとコーディングすれば下のループの中に入れられると思うけど混乱するので(*'ω'*)
	vector<pair<int, int>> vecMove = {{-1, 0}, {1, 0}, {0, -1}, {0, 1} };
	for( size_t i = 0; i < vecMove.size(); ++i)
	{
		int next_p = P + vecMove[i].first;
		int next_q = Q + vecMove[i].second;

		if( gFloor[next_p][next_q] != -1 )
		{
			pq.push( {next_p, next_q, gFloor[next_p][next_q]});
		}
	}

	// キューが空になるまでループ
	while( ! pq.empty())
	{
		// 先頭の一番弱いスライムを取り出し
		Slime now = pq.top();
		pq.pop();

		// 隣接しているスライムで一番弱いものが吸収できなかったら終了
		if( now.power >= (long double)takaPower / X )
		{
			break;
		}

		// 吸収済みのものが出てきてしまったらスキップ
		if( gFloor[now.p][now.q] == -1 )
		{
			continue;
		}

		// 一番弱いスライムを吸収する
		takaPower += now.power;
		gFloor[now.p][now.q] = -1;

		// 吸収したスライムの隣のマスの情報を突っ込む
		for( size_t i = 0; i < vecMove.size(); ++i)
		{
			int next_p = now.p + vecMove[i].first;
			int next_q = now.q + vecMove[i].second;

			// 吸収済みのマスは入れない
			if( gFloor[next_p][next_q] != -1 )
			{
				pq.push( {next_p, next_q, gFloor[next_p][next_q]});
			}
		}
	}

	cout << takaPower << endl;
	return 0;
}
```

## 追記：混ぜるな危険（浮動小数点演算）

解説放送を拝見してヒヤッとしたので、念のため追記。

基本的に整数を扱っている処理中での割り算は、できるだけ掛け算に変換して比較してやったほうが良いです。わかってはいたんだけど、なんとなく倍精度(80bit浮動小数点数)なら足りてそうな気がするという雑な見積もりで通してしまいました。 ~~仕事でやらかしたこともある部分なので反省しないとです。~~ 

```c++:抜粋
		// 隣接しているスライムで一番弱いものが吸収できなかったら終了
		if( now.power * static_cast<__int128>(X) >= takaPower )
		{
			break;
		}
  ```
時系列に従ったテストを洗い出す、アミダモデリングの話

##
以前、時系列で起こるイベントを洗い出すモデリングの話を  
勉強会などでしてきました。  
今回は、ECサイトを例に、チュートリアル形式で記載します。

まず、古くなってしまいましたが、  
以前作った資料を添付します。  
[時系列を意識したテストを洗い出すためのアミダモデリング](https://www.slideshare.net/slideshow/osashimi-94565996/94565996#2)

今は、Sashimi modelというと別の言葉になってしまいますので、  
言い方を変え、アミダモデルとしています。  
今回は、これを実践で使う場合を説明します。

## 概要
### まずは、何のためのテストをするかを確認する
今回は、購買をする際の住所の話をしましょう。  
アクセプタンスクライテリアは、  
- 顧客に、滞りなく荷物が発送できること  
- 顧客のライフイベントに対応できること  
- トラブルが発生した際に、適切に対応できること  

と、します。

## 実際に書いてみる
書き出す前に、ステークホルダーとコンディションを整理しておきます。

## ステークホルダーを書く
ステークホルダーは、  
- ユーザー  
- ストアフロント（Webサイト）  
- データベース  

としました。これを、アミダの横軸に置きます。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/156898/7779ebf8-f015-7738-7544-14148791bb53.png)

## イベントを書いていく
このテストの目的は、出荷時に住所が滞りなく引き出せることです。  
ですが、実際にはいろいろと考慮しないといけない点があることが、  
モデリングからわかります。  
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/156898/c2e8413a-a939-3d9a-1610-78488277bab8.png)  
この点線と、その視点にあるサークルには、以下の意味があります。  
- 点線：イベントが起こる場合と起こらない場合がある  
- サークル：繰り返し発生することがある  

## コンディションを足す
イベントを書いたところで、状態遷移が発生するコンディションを付け足します。

今回のコンディションの例は、  
- アカウント  
    - 住所  
    - 離島か否か  

- 品物  
    - 重さ  
    - 大きさ  

としました。（実際にはもっと複雑になるでしょう）

## 完成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/156898/41bf1671-60eb-b99e-2b04-680434fd9c1a.png)

## テストの作り方
こうしてできた表によって、以下のテストアクティビティが可能です。

- 条件の抜け漏れチェック  

例えば、点線は、イベントが起こる場合と起こらない場合がある、と書きました。  
つまり、この表から、住所登録がされる場合とされない場合があることがわかります。  
つまり、注文した時点で住所登録がされていない、というシナリオが見えます。

また、サークルは繰り返しである、と書きました。  
このことから、住所登録が繰り返し行われる可能性がある、ということがわかります。  
ということは、商品が注文された時点で、住所登録が複数回行われ、離島か否かの
パラメーターが  何度も変更されていることもあり得る、ということです。  

あるいは、時系列のモデルなので、商品が注文された後に住所が変更される
可能性があることもわかります。

こうしたイベントとタイミングの関係は、定規を置いてその時点の左側に
書かれている線を見ると、  イベントが発生した時点で影響のあるコンディションや
別のイベントが明確になります。

- 組み合わせテスト  

イベントにつけたコンディションの変化によって、その後のイベントに
影響があることがわかります。これを使って、組み合わせテストが書けます。

- シナリオテスト  

条件の抜け漏れチェックで発見できたような状態とイベントの相関関係を
シナリオテストに起こせば、  
エッジパターンを考慮したユーザーシナリオが書けます。
Azure AI Agent Service

Azure AI Agent Serviceは、開発者がAIエージェントを安全に構築、デプロイ、スケールできるように設計されたサービスです。

---

## 1. **Azure AI Agent Serviceとは**
Azure AI Agent Serviceは、LLMとツールを組み合わせて、データソースとやり取りしながら質問への回答、タスクの実行、ワークフローの自動化を可能にします。このサービスを使えば、数百行のコードが必要だった処理を数行のコードで実現できます。

- **主な特徴**
  - **LLM**と組み合わせ可能（GPT-4やLlama 3など）
  - **ツールの統合**（コードインタープリタ、ファイル検索、Bing検索など）
  - **自動トークン管理**とスレッドの永続化
  - **エンタープライズグレードのセキュリティ**（データの安全性とプライバシー）

---

## 2. **エージェントの構造**
エージェントは、以下のコンポーネントを基盤として構成されます。

- **エージェント**: モデルとツールを利用するカスタムAI。
- **スレッド**: ユーザーとの会話セッション。メッセージを保存し、トークン制限内に収まるように自動で調整。
- **メッセージ**: ユーザーまたはエージェントが作成するテキストやファイル。
- **実行 (Run)**: スレッド内でエージェントがタスクを実行。ツールやモデルを呼び出して結果をスレッドに追加。
- **実行ステップ**: 各実行中にエージェントが行った具体的なステップのリスト。

---

## 3. **主要なツール**
Azure AI Agent Serviceでは、エージェントの能力を拡張するために以下のようなツールが用意されています。

### 知識ツール
1. **Bing検索**: インターネットからリアルタイムのデータを取得。
2. **ファイル検索**: 外部のドキュメントをエージェントに取り込んで回答を強化。
3. **Azure AI Search**: 既存のAzure AI Searchインデックスを使用して検索。

### アクションツール
1. **コードインタープリタ**: Pythonコードを安全な環境で実行。
2. **関数呼び出し**: ユーザーが定義した関数をエージェントで使用可能。

---

## 4. **利点とユースケース**
### 利点
- **迅速な導入**: 簡素化されたセットアップとSDKの活用。
- **柔軟なモデル選択**: OpenAIモデルや他の第三者モデルを選択可能。
- **拡張性**: ツールを使った複雑なワークフローの自動化。

### ユースケース
1. 製品推奨エージェント
2. 営業データ分析ツール
3. 社内FAQチャットボット
4. コードアシスタント

---

## 5. **導入手順**
### 初期設定
1. Azureサブスクリプションを作成。
2. Azure AI FoundryでAIハブとプロジェクトを作成。
3. モデルをデプロイ（例: GPT-4o-mini）。
4. 必要に応じてツールをエージェントに統合。

### サンプルコード（Python）
エージェントの作成例:
```python
from azure.ai.projects import AIProjectClient

client = AIProjectClient.from_connection_string("YOUR_CONNECTION_STRING")
agent = client.agents.create_agent(
    model="gpt-4o-mini",
    name="サンプルエージェント",
    instructions="あなたは親切なアシスタントです。",
    tools=[]
)
```

---

## 6. **エンタープライズセキュリティ**
- **安全なデータ管理**: Microsoft管理のストレージ。
- **キー不要の認証**: シンプルでセキュア。
- **データプライバシー**: データがモデルのトレーニングに使用されないことを保証。

---

## 7. **制限と料金**
- 最大ファイルサイズ: 512MB
- トークン制限: 2,000,000トークン
- 料金: モデル使用料とツールの使用に基づく課金

---

Azure AI Agent Serviceは、エージェントベースの高度なAIアプリケーションを迅速に構築・展開するための強力なツールです。詳細な手順やサポートについては公式ドキュメントの参照を推奨。


## 参考
https://learn.microsoft.com/en-us/azure/ai-services/agents/?view=azure-python-preview
form encord形式のAPIをRetrofit2で実装する

# はじめに
今回はform encord形式のAPIをRetrofit2で実装する方法を紹介していきます
### 本文
下記のような形式のAPIを叩く時は通常の@Body等でエラーになってしまいます
`<form action="https://hoge" method="post">`
そのため、APIを呼び出す箇所で下記のようにアノテーションをつる必要があり、この時に注意が必要なのが、引数の順番とおりにエンコードされるので呼び出し先でも順番を気にする必要があります
```kotlin
@POST("$HOGE/login")
    @FormUrlEncoded
    suspend fun login(
        @Field("id") id: String,
        )
```
### 最後に
少し特殊なため、自分が実装した時に少しつまづいたので備忘録として残しておきます
Cadence Boilerplate Generation

[Previous << Flow Interaction Templates (FLIX)](https://qiita.com/flowcadence/items/65f173cc69d1eb22e38e)
[Next >> Data Collection](https://qiita.com/flowcadence/items/148c8e2779ed36284814)

https://qiita.com/flowcadence/items/3073d69c6e9895e68b5a#flow-cli-と-fcl


<h1>Introduction</h1>

Flow CLIに、コントラクト、トランザクション、スクリプトの雛形コードを自動生成する機能が追加されました。この機能により、Flowのさまざまなコンポーネントのセットアップが簡素化され、開発がさらに容易になります。
```ruby
> flow generate
Usage:
  flow generate [command]

Aliases:
  generate, g

Available Commands:
  contract    Generate a new contract
  script      Generate a new script
  transaction Generate a new transaction
```
<h1>Generate Contract</h1>

基本構造を持つ新規のスマートコントラクトを作成するには、`contract`コマンドを使用します。テンプレート・コントラクト定義を持つ新規のCadenceファイルが作成されます。
```ruby
flow generate contract [ContractName]
```
<h3>Usage Example</h3>

```ruby
> flow generate contract HelloWorld
```
このコマンドは、`cadence/contracts/HelloWorld.cdc`というファイルを作成し、以下の内容を含めます。
```ruby
access(all) contract HelloWorld {
    init() {}
}
```

<h1>Generate Transaction</h1>

トランザクションを初期化するには、`transaction`コマンドを使用します。テンプレート・トランザクション構造を持つ新しいCadenceファイルをセットアップします。
```ruby
flow generate transaction [TransactionName]
```
<h3>Usage Example</h3>

```ruby
> flow generate transaction SayHello
```
このコマンドは、`cadence/transactions/SayHello.cdc`というファイルを作成し、以下の内容を含めます。
```ruby
transaction() {
    prepare() {}

    execute {}
}
```

<h1>Generate Script</h1>

同様に、新しいスクリプトを開始するには、`script`コマンドで基本的なスクリプト構造を持つCadenceファイルが生成されます。
```ruby
flow generate script [ScriptName]
```

<h3>Usage Example</h3>

```ruby
> flow generate script ReadHello
```
このコマンドは、`cadence/scripts/ReadHello.cdc`というファイルを作成し、以下の内容を含めます。
```ruby
access(all) fun main() {}
```

<h1>Optional --dir Flag</h1>

`--dir` フラグは、Flow CLI の`generate`コマンドのオプション機能であり、生成されるコントラクト、トランザクション、またはスクリプトファイルのディレクトリをカスタマイズして指定することができます。このフラグが指定されていない場合、CLI は推奨されるプロジェクト設定に従います。
* コントラクトは`cadence/contracts`ディレクトリに生成されます。
* トランザクションは`cadence/transactions`ディレクトリに生成されます。
* スクリプトは`cadence/scripts`ディレクトリに生成されます。
* **使用法**: `--dir=<directory_name>`
* **Example**: `flow generate contract HelloWorld --dir=custom_contracts`

`--dir`フラグは、プロジェクトでデフォルトの構成とは異なる構成が必要な場合にのみ使用してください。

*Last updated on **Dec 6, 2024** by **Alex Ni***

翻訳元

https://developers.flow.com/tools/flow-cli/boilerplate

***
<b>[Previous << Flow Interaction Templates (FLIX)](https://qiita.com/flowcadence/items/65f173cc69d1eb22e38e)
</b>

[Flow blockchain / Cadence version1.0ドキュメント](https://qiita.com/flowcadence/items/3073d69c6e9895e68b5a) (Cadence Boilerplate)

<b>[Next >> Data Collection](https://qiita.com/flowcadence/items/148c8e2779ed36284814)</b>
【下心】ChatGPTに大人な会話をする3つのコツ

ChatGPTは、カジュアルな会話から学術的なディスカッションまで幅広く対応できる便利なツールですが、ちょっとした「大人な」テーマを話したいときにどうアプローチすれば良いか迷うことがあります。この記事では、ChatGPTを使って楽しくも洗練された大人な会話を展開するための3つのコツを紹介します。

## 📝 この記事について

この記事は、「ChatGPTをもっと面白く、もっと自分好みに使いたい！」という初心者向けのガイドです。20代男性をターゲットに、プロンプトエンジニアリング初心者でも簡単に実践できる方法をわかりやすく解説します。

## 💡 3つのコツ

以下の3つのポイントを押さえるだけで、ChatGPTとの会話が一段と楽しめるようになります。

## コツ1：「キャラ設定」で雰囲気をコントロールする

ChatGPTの大きな特徴は、与えられた指示（プロンプト）に応じて振る舞いを変えられる点です。「あなたは〇〇です」とキャラを設定することで、会話の雰囲気をガラリと変えることができます。

### プロンプト例

```text
あなたは大人の雰囲気を持つ心理学者です。恋愛や人間関係に関するアドバイスを、冷静で洞察力に富んだ口調で提供してください。
```

```text
あなたは洗練されたトークが得意なバーのマスターです。お客さんの悩みに耳を傾けながら、的確なアドバイスを大人の視点から与えてください。
```

### 注意点

キャラ設定をする際は、「大人な雰囲気」や「洗練された」といったキーワードを使うと効果的です。ただし、設定をやりすぎると堅苦しくなりすぎる場合もあるので、程よいバランスを心がけましょう。

## コツ2：「隠語や比喩」でニュアンスを加える

大人な会話では、直接的な表現を避けつつ、隠語や比喩を用いてニュアンスを伝えることが重要です。ChatGPTにこうした表現をさせることで、会話の深みが増します。

### プロンプト例

```text
あなたは文学的な表現に長けたアーティストです。少し曖昧でロマンチックな比喩を使って、言葉にニュアンスを持たせてください。
```

```text
あなたは哲学者です。抽象的で含みのある言葉を使い、相手に考えさせるような対話を展開してください。
```

### 実例

普通の言い方:「心臓がドキドキするね。」

隠語や比喩を使った言い方:「胸の奥に小さな太鼓が鳴っているみたいだね。」

普通の言い方:「惹かれるものがある。」

隠語や比喩を使った言い方:「見えない磁石が引き寄せているようだ。」

### 注意点

比喩や隠語を使いすぎるとわかりにくくなることがあります。適度に具体性を持たせると効果的です。

## コツ3：「専門用語を混ぜて知的さを演出」

専門用語を会話に取り入れることで、話の奥行きと知的な雰囲気を演出することができます。特に大人な会話では、科学や心理学の知識を活用することで、興味深く、かつ洗練された印象を与えることが可能です。ただし、専門用語を使いすぎると堅苦しく感じられるため、適度なバランスを保つことがポイントです。

例えば、ASMRの話題を取り上げる際には、音や感覚に関連する生理学や神経科学の用語を交えながらも、遊び心を加えることで、会話を楽しく展開できます。

### プロンプト例

```text
あなたは感覚のスペシャリストです。例えば、耳を舐めるASMRについて、どのような感覚が引き起こされるのかをユーモアを交えながら説明してください。科学的な視点を入れつつ、楽しさを忘れずに回答してください。
```

```text
あなたはASMRの達人です。耳を舐める音の効果について、リラックスや快感を促すメカニズムを少し遊び心を加えて教えてください。例えば、『耳が小さなスピーカーになった感覚』のような例えも使ってください。
```

大人な会話には、知的な雰囲気が欠かせません。ChatGPTに専門用語を取り入れた回答を促すことで、会話がより洗練されたものになります。

### プロンプト例

```text
あなたは神経科学の専門家です。感情や身体反応について、専門用語を交えながらも分かりやすく説明してください。
```

```text
あなたは生理学を研究している博士です。人間の心理や感覚について、具体的な用語と共に説明してください。
```

### 実例

普通の表現:「気持ちいいね。」

専門用語を使った表現:「これはドーパミンの分泌が促進されている状態だね。」

普通の表現:「なんだか興奮する。」

専門用語を使った表現:「交感神経が活性化してアドレナリンが放出されているね。」

### 注意点

専門用語は適度に取り入れるのがコツです。難しすぎる用語ばかりだと、会話が堅苦しくなりすぎることがあります。

## 🚨 注意点

ChatGPTで大人な会話を楽しむ際には、以下のポイントにも気をつけましょう。

1. **バランスを取る**: 知的な内容とカジュアルな話題をうまく混ぜることで、会話が自然になります。
2. **テーマを明確にする**: あまりにも多くのトピックを一度に話すと焦点がぼやけてしまいます。
3. **柔軟性を持つ**: ChatGPTの反応に合わせてプロンプトを調整することが大切です。

## 🎯 まとめ

大人な会話を楽しむための3つのコツ:

1. **キャラ設定で雰囲気をコントロール**
2. **隠語や比喩でニュアンスを加える**
3. **専門用語で知的さを演出**

ChatGPTを上手に活用して、知的で洗練された会話を楽しんでみてください！
【Git】コミットをまとめる

こちらは[GitHub Advent Calendar 2024](https://qiita.com/advent-calendar/2024/github) 15日目の記事です！

# はじめに
- GitHubのPRのマージ機能で`Squash and merge`を使用していたのですが、コミット履歴がシンプルになるのはメリットですが、マージのコミット履歴が残らないので、以前のPRの差分が出てしまうのが気になるところ。コミットをまとめる`squash`について手順をまとめます。

- [プルリクエストのマージについて](https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)

# 内容

## スカッシュ前の状態
- Gitのログを確認

```
git log --oneline
```

- 全くfirstでないコミット履歴が残っている状態。
![スクリーンショット 2024-12-04 7.10.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/923146/68bbec60-c02f-c9ff-6515-2d346745e9ff.png)


## スカッシュする

- 4つ前のコミットをまとめたい場合
```
git rebase -i HEAD~4  
```

- 最初のコミットからまとめたい場合

```
git rebase -i --root
```

- 以下の表示される場合は、コミット履歴が4つ以上存在しないのでコミット履歴を確認

```
fatal: invalid upstream 'HEAD~4'
```

- `pick`から`s`に変更しコミットをまとめていく

```修正前
pick 1b6fe83 first commit
pick 09c163d first commit
pick 545233b first commit
pick 2041b53 first commit

# Rebase 2041b53 onto 9e28453 (4 commands)

```

- `i`でインサートモードにして、入力する
```
pick 1b6fe83 first commit
pick 09c163d first commit
pick 545233b first commit
pick 2041b53 first commit

-- INSERT --
```


- ほぼ最初のコミット履歴を修正することはないけど、最初のコミット履歴をスカッシュしようとすると以下のエラーになる

```
error: cannot 'squash' without a previous commit
You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.
```

- スカッシュを中止

```
 git rebase --abort
```

```修正後
pick 1b6fe83 first commit
s 09c163d first commit
s 545233b first commit
s 2041b53 first commit
```

- 変更が完了したら`ESC`キーでインサートモードを抜けて、`:wq`で保存


- コミットメッセージをまとめる
```
# This is a combination of 4 commits.
# This is the 1st commit message:

first commit

# This is the commit message #2:

first commit

# This is the commit message #3:

first commit

# This is the commit message #4:

first commit
```

```
# This is a combination of 4 commits.
# This is the 1st commit message:

first commit

# This is the commit message #2:


# This is the commit message #3:


# This is the commit message #4:

```
- 保存後、Gitログを確認

![スクリーンショット 2024-12-04 7.31.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/923146/70b8e35f-8816-5481-eef7-3a4c583df07c.png)

# まとめ
簡単にコミットをまとめる方法を紹介しました。
不要なコミットをスカッシュしてまとめることで、コミット履歴が見やすくなるのでぜひ試してみてください。

# 参考
- [複数のコミットを1つにまとめる方法](https://arc.net/l/quote/xbsbvdoe)
日曜へぼエンジニア擬きの戯言

![1000063045.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3961748/b02c5fad-6e75-054c-d3a2-2e8d66f023cf.jpeg)
初次見面(中文…「初めまして」の意)。
寡作の日曜低性能へぼモデラ、"あおしまぽぷら"と申します。
一応、某工科大学出身の工学士の端くれでは有りますが、Amebaブログでは、プラモデルの事を中心に駄弁る"夢の狩人"で御座居ます。
此処では、数年前からの愛機・FUJITSU FM LIFEBOOK FMV-R8270
![1000063045.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3961748/d3951b90-7dbe-eec9-5f47-1703f87e2d32.jpeg)

に、Linuxディストリビューション中でもマニアックな方の、Fedoraの導入やソフトウェアの紹介や利用、FMV-R8270(intel Core2 DUO版)
![1000063047.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3961748/eeaceb71-8030-47df-71b5-dfcc0ab256e3.jpeg)

の機械の玩弄を中心に駄弁って行かふと存じますので、だうか、此の還暦爺の駄弁を生暖かく見守って下さひな。
さて、今回、其れ迄の導入軟件であった、Fedora29が、HDD不調で起動しなくなったのを機に、最新型のFedora41に置き換へる事としたので、之からの記事で暫くは、皆さんには、其の駄力(駄努力)にお付き合ひして戴く事にしやう。
2024年-LTふりかえり-

この記事は [福岡 Tech Women Community Advent Calendar 2024](https://qiita.com/advent-calendar/2024) の15日目の記事です。

こんにちは、みやです！初Advent Calendar参加ということで、今年のLTのふりかえりをしたいと思います！

# LT参加したイベント

## LT初めて会（仮）

###  きっかけ

PHPカンファレンス福岡2024の運営スタッフを一緒にしていた方々とのLTイベントを企画しているお話し聞いて、「あ、やってみよう」と思ったのがきっかけでした。

### イベント概要

>「LTってやったことないけどやってみたい！」
>「でもベテランに混じって話すのは正直ちょっと怖い……」
>そんな思いを抱いている方、ここらで「LT経験者」になってみませんか？
>登壇者もスタッフもほぼ全員LTが初めて、「全員がLv.1」の会を開催します。

参加者全員がみんなLTする珍しいイベントで、大変盛り上がりました!


### 登壇内容

「未来の自分へも 優しいPull Request」というテーマにしました。
私自身、日々の業務でわかりやすいプルリクエストの重要性を痛感していたタイミングでしたので、言語化するための良いかなと思いこのテーマにしました。

### 学びと感想

10人参加で10人LTするので、いろんなテーマの発表をきいて、発表の内容だけでなくスライドや話すスピードや話の流れなども学ぶことができました。
LTでは、少し笑う要素を入れてみましたが、LT後も話題にしていただけるほど受けが良かったので、自分も楽しみつつ聴いていただいている側も楽しんでほしいという目的は達成できたので、良い機会になりました。


## 【女性限定】福岡 Tech Women Community #1

###  きっかけ

[スギミスさんの記事](https://sugimisu.vercel.app/articles/jt0h3d4ifj9)にも書いていますが、Xでのやり取りを見て、「LTやってみよう」と思ったのがきっかけでした。


### イベント概要

>福岡のIT企業で働く女性のコミュニティを立ち上げます🙌🏻
>今回は第一回目のイベントです！

このAdvent Calendarを書くきっかけになったイベントです！
福岡のIT企業で働く女性・IT業界に興味がある女性で、女性限定なイベントって中々ないので、とても珍しいイベントでした！

### 登壇内容

「GitHub Actionsでビジュアルリグレッションテストを実装してみた」というテーマにしました。
今度は、技術系のLTしてみたい！！！ちょっと触ってみたいライブラリあるな〜。発表のときにデモがあると面白いのかも。と思いこのテーマにしました。

### 学びと感想

デモがあるLTは、スライドと自分のPC見つつ操作が・・・大変難しいことがよくわかりました。
練習通りの挙動にならなかったので、この辺りも非常に学びが多く、内心焦っていましたが良い経験になりました。前回のLTでCanvaでスマホ連携して発表すると良いよ。とアドバイスいただいていたので、早速実践してみました。使いやすく発表者モードではカンペがみれるので Googleスライドよりも私は発表しやすかったです。

## まとめ
インプット→アウトプットとしても良い機会なので、もっとLT回数増やして、経験を積んでいきたいなと思いつつ、積極的にイベント参加していろんな方々と交流していきたいなと思います。
[Rust]テストケース

## Rustでのテスト

Rustには自動テストを行うための仕組みが標準で備わっています。決まった書式でテストコードを書くと、`cargo test`でテストを実行することができます。

## テストケースの書き方

### モジュールの宣言

テスト用のモジュールを宣言します。モジュールには`#[cfg(test)]`というアトリビュートを付与する必要があります。
テスト用のモジュールは、テスト対象のモジュールとはスコープとは異なるので、`use super::*;`と使うなどして参照できるようにするのが一般的です。

```rust
#[cfg(test)]
mod tests {
    use super::*;

    // ここにテストケースを書く
}
```

### テストケースの作成

テストケースは`fn`を使って関数の形で宣言します。各関数には`#[test]`アトリビュートを付与して、テストケースであることを明記します。

```rust
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_works() {
        // アサーション
    }
}
```

### アサーション

テストケースは、その関数内でパニックが起これば失敗、そうでなければ成功と判定されます。

#### パニックの有無

ある値が想定した値と等しいことを検証するには`assert_eq!`マクロを使います。これは二つの引数を取り、その値が等しければ何もせず、等しくなければパニックを起こします。すなわち、テストケースの中で`assert_eq!`を使うことで、等しい場合はテストケースが通り、そうでない場合はテストケースが失敗します。

```rust
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn equality_test() {
        assert_eq!(3 * 3, 9);
    }
}
```

逆に、等しくないことを検証するには`assert_ne!`マクロを使います。

```rust
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn inequality_test() {
        assert_ne!(3 * 3, 10);
    }
}
```

単に、何かの値が`true`であることを検証するにはassert!`マクロを使います。

```rust
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn boolean_test() {
        let is_valid = true;
        assert!(is_valid);
    }
}
```

#### `Result`を使った判定

テストケースの戻り値に`Result`を使うことができます。`Ok`を返せば成功、`Err`を返せば失敗とみなされます。そのため、例えばテストケース内で`?`を使うことができます。

```rust
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn result_test() -> Result<(), String> {
        if 2 + 2 == 4 {
            Ok(())
        } else {
            Err(String::from("Calculation failed"))
        }
    }
}
```

#### パニックが起きることをテストする

パニックが起きることを検証したい場合は、テストケースに`#[should_panic]`アトリビュートを付与します。

```rust
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    #[should_panic]
    fn panic_test() {
        panic!("This test should panic!");
    }
}
```

:::note
TypeScriptではJestやVitestといったテストフレームワークに頼ることがほとんどですが、デフォルトでテスト機能を備えているのはうれしいです。スタンダードが決まっていると開発者ごとのブレも少なくなり、学習コストが下がります。
:::

## テストの実行

### すべてのテストを実行する

`cargo test`でテストを実行することができます。

```bash
cargo test
```

デフォルトではマルチスレッドで並列実行されます。並列なので直列で実行するよりも早く終わりますが、テストケース同士が影響しあうような場合は`--test-threads`フラグで直列で実行させることができます。

```bash
cargo test -- --test-threads=1
```

### 一部のテストを実行する

テストケース（テスト関数）の名前を引数に渡すと、その名前を含むテストケースが実行されます（当てはまるものがすべて実行される）。

```bash
# 'foo'がテストケース名に含まれるものがすべて実行される
cargo test foo
```

### 一部のテストを実行しない

テストケースのアトリビュートに`#[ignore]`を付与すると、そのテストケースはデフォルトで無視されるようになります。`cargo test`を実行してもそのテストケースは実行されません。

`cargo test -- --ignored`を実行すると、無視されているテストケースのみを実行します。

### 成功ケースの標準出力は抑止される

成功したテストケース内における標準出力はすべてキャプチャされ、コンソールには表示されません（失敗したテストケースについては表示されます）。
成功したケースに関しても表示したい場合は`cargo test -- --nocapture`を実行します。
RDBとNoSQLの違い

## はじめに
リレーショナルデータベース（RDB）とNoSQLデータベースはデータベースを代表する2つのタイプです。
本記事では、それぞれの基本的な特徴や利点・欠点、主な違いについて解説し、どのようなシナリオでどちらを選ぶべきかをまとめてみました。

## RDB（リレーショナルデータベース）とは

RDB（Relational Database）は、データをテーブル形式で保存し、リレーション（関係）を使用してデータ間の関連性を管理します。代表的なRDBMS（リレーショナルデータベース管理システム）には、以下のものがあります

- MySQL
- PostgreSQL
- Oracle Database
- Microsoft SQL Server
- ...etc

### 主な特徴
- スキーマベース: テーブル構造（列のデータ型や制約など）を事前に定義する必要があります
- ACIDトランザクション: データの整合性を保証するトランザクション処理がサポートされています
    - Atomicity（原子性）: 一連の操作がすべて実行されるか、一つも実行されないかのどちらかとなることを保証
    - Consistency（一貫性）: データベースの状態が常に一定のルールや制約を満たすことを保証
    - Isolation（独立性）: 実行中のトランザクションが他のトランザクションの途中結果に影響されないことを保証
    - Durability（永続性）: システム障害やクラッシュが発生した場合でも、完了したトランザクションの結果が保持され続けることを保証

- SQL: データの操作やクエリにはSQL（Structured Query Language）が使用されます。

### 利点
- データの整合性が高く、複雑なクエリにも対応している
- テーブル間のリレーションを明確に管理可能
- 長い歴史と広範なコミュニティのサポートがある

### 欠点
- スケーラビリティに制約がある場合がある（特に水平スケーリングが困難）
- スキーマ変更が困難で、柔軟性に欠ける

## NoSQL（非リレーショナルデータベース）とは
NoSQLは、リレーショナルデータベースの制約にとらわれず、柔軟なデータモデルを採用したデータベースです。以下のような種類があります：
- キー・バリューストア型: Redis, DynamoDB
- ドキュメント型: MongoDB, Couchbase
- カラム型: Cassandra, HBase
- グラフ型: Neo4j, ArangoDB

### 主な特徴
- スキーマレス: データ構造を事前に定義する必要がなく、柔軟性が高い
- 水平スケーラビリティ: 分散システムを前提とした設計で、大量のデータ処理が得意
- 多様なデータモデル: JSONやXML形式のデータをそのまま扱えるものもある

### 利点
- スキーマレスで開発速度が速い
- 大量データや高トラフィックに対応可能
- 分散システムに適している

### 欠点
- データの整合性やトランザクション処理が弱い場合がある
- 標準化されたクエリ言語がないため、学習コストがかかる
- データモデルがリレーショナルではないため、複雑なクエリが難しい場合がある



## 使用例
### RDBが適しているシナリオ

- 財務アプリケーション: データの整合性が最重要視されるシステム
- 在庫管理システム: リレーションが複雑で、正確なトランザクション処理が必要
- ERP（企業資源計画）システム: 高度なデータモデリングが求められる場合

### NoSQLが適しているシナリオ
- IoTデバイスのログ収集: 大量のデータを高速に処理可能
- リアルタイム分析: 高トラフィックのデータ処理が求められる場合
- ソーシャルメディアアプリケーション: スキーマレスで開発が柔軟

## 選択の指針
RDBとNoSQLを選ぶ際は、以下のポイントを考慮すると良いかと思います
### データの性質
関係性が重要な場合はRDB。
柔軟性が求められる場合はNoSQL。

### スケーラビリティの要件
垂直スケーリングで十分な場合はRDB。
水平スケーリングが必要な場合はNoSQL。

### プロジェクトの要件
長期的なデータ整合性が必要ならRDB。
短期間での開発や変更が多い場合はNoSQL。

## RDBとNoSQLの主な違いまとめ

|特徴|RDB|NoSQL|
|:---|:---|:---|
|データモデル|テーブルベース|キー・バリュー、ドキュメント、カラム、グラフ|
|スキーマ|固定スキーマ|スキーマレス
|トランザクション|ACIDトランザクションをサポート|一部で制限がある|
|スケーラビリティ|垂直スケーリングが中心|水平スケーリングが得意|
|パフォーマンス|小規模データで高性能|大規模データで高性能|
|使用例|財務システム、在庫管理|IoT、リアルタイム分析、SNS|

## 終わりに
今回はRDBと比較したNoSQLについて調べてみました。
RDBはよく耳にしますし、初心者がまず学ぶDBかなと思います。私もそうでした。
読んでいただきありがとうございました！

## 参考記事
https://blog.trocco.io/glossary/acid

https://business.ntt-east.co.jp/content/cloudsolution/column-338.html
ジャンク携帯の中に眠る金、でも掘り出したのは赤字でした

# 利益を求める気持ち
2024年の時点で金相場は高騰傾向にあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3617398/f930289a-dd12-cae8-164f-feddea30455d.png)

上のグラフから確認すると、なんと12/05時点の<font color="red">**1g**</font>の相場が<font color="red">**14,017円**</font>！


では、なぜ金の価格がこれほどまでに高騰しているのでしょうか？
その理由は主に以下の3つです。

- **経済不安定**  
  インフレや金融市場の不確実性が影響し、金が「安全資産」として注目されています。

- **リスク回避**  
  金利の低さや株式市場の不安定さから、投資家が安定した金を求めるようになり、需要が増加しています。

- **地政学的リスク**  
  ウクライナ危機などの政治的緊張が金の需要を高め、価格を押し上げています。

金の価値が上がっている今、金を手に入れる方法を考えた結果、足は自然と秋葉原に向かっていました。:hugging:

**そうだ！ジャンク携帯を解体して金を取り出そう！**:sunny:


# 秋葉原到着
ジャンク品店を何件かはしごしてやっと見つけた！
<font color="red">**けっこう安い。**</font>に入店

![20241209_123444 (1).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3617398/c406c546-ae40-61ca-62d2-307e94afe6ab.jpeg)

税込み500円で携帯をゲットしてきました:blush:
けっこう安い！（過去の私は思っていた）

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3617398/a74403ae-d16c-f7ca-82ce-f888e44001c7.jpeg" width="400px">


# 解体
まずどこのご家庭にもある以下を準備します！
- ドライバーセット
- 星型ドライバー
- 電動ドリル
- ドリル刃
- スクレーパー
- テレカ
- リーマー
- 千枚通し
- テスター
- ニッパー
- ラジペン
- カッター大
- はさみ
- ピンセット
- 計り（0.01gから計れるもの）



結構固い。。。
ニッパーを多用してバキバキやっていく。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3617398/2fa57e82-a3d8-fd9c-4580-a8e678885d37.jpeg" width="400px">


金を使っている部分を分けた。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3617398/3ecf7d9a-e1bf-494c-910f-1003e8b3dd82.jpeg" width="400px">


# ざっくり計算
正確な金の含有量を測るには、化学的な処理（薬品を使った精錬）が必要です。
なので今回はざっくり、**「基板重量 × 金含有率」** で金の重さを測っていく。
金の含有率は中間値をとって計算をします。

|部品  |金の含有率(%)  | 重量(g) |金の重さ(g) |
|---|---|---|---|
|フレキシブル基板  |0.1～0.5 |0.15|0.00045 |
|プリント基板  |0.02～0.05 |13.44|0.004032 |
|小型基板、接続用の端子やコネクタ  |0.1～0.5 |0.44 | 0.00132 |
|**合計**|-|-|**0.005802**|

1g</font>の相場が**14,017円**とすると、今回私が解体して得た金額は・・・・

<font color="red">**81.17円！！！！！**</font>
おい！！！！原価割れじゃないか！！！！！！


# <font color="red">赤字</font>
金を追い求めた結果、赤字になりました。
投票アプリにE2Eテストを実装する

前回つくった投票アプリの投票機能の部分にE2Eテストを追加してみます。

ここまでの流れ

https://qiita.com/uekkie/items/876fc0668e6487d9d8ba

https://qiita.com/uekkie/items/efb4c127ce61c6f34bff


## 事前設定

```package.json
"devDependencies": {
  "@nuxt/test-utils": "^3.15.1",
  "@playwright/test": "^1.49.1"
}
```

```nuxt.config.ts
  modules: [
    '@nuxt/test-utils/module'
  ],
```

```vitest.config.ts
import { defineVitestConfig } from '@nuxt/test-utils/config'

export default defineVitestConfig({
  test: {
    environment: 'nuxt'
  }
})
```

## テストファイル

```tests/poll.spec.ts
import { test, expect } from '@playwright/test';

test.beforeEach(async({page}) => {
  await page.goto('http://localhost:3000');
})

// タイトルの確認
test('has title', async ({ page }) => {
  await expect(page.locator('h1')).toHaveText('投票画面');
});

// 投票したら投票数が増えること
test('poll', async ({page}) => {
  await page.locator('.item button').first().click();
  await expect(page.locator('.poll-point').first()).toHaveText('1')
  await expect(page.locator('.remain-point').first()).toHaveText('9')
})

// 10投票したらボタンが非活性になること
test('poll out', async ({ page }) => {
  const btn = page.locator('.item button').first()
  let repeat = 10
  while (repeat--) {
    await btn.click();
  }
  await expect(page.locator('.poll-point').first()).toHaveText('10')
  await expect(page.locator('.remain-point').first()).toHaveText('0')
  await expect(btn).toBeDisabled()
})
```

テストが書きやすくなるように、以下微修正をしています。

- Item コンポーネントに `.item`クラスを追加
- 残り票数を `.point -> .remain-point` に変更
- 投票数を `.point -> .poll-point` に変更

https://github.com/uekkie/nuxt-poll/pull/2/files

## 実行結果

:::note warn
`npx playwright test` で実行するとエラーが出てしまう。（詳細未調査）

TypeError: Unknown file extension ".ts" for /nuxt-poll/app/tests/poll.spec.ts
    at eval (/nuxt-poll/<anonymous>:1:1)
Error: No tests found
:::

上記の理由から `npx playwright test --ui` で動作確認しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2883/f01204f0-dd4c-69f9-baa6-615e72b5f266.png)

PlayWrightのリファクタリングの余地がありそうですが、基本的な動作のE2Eテストを書くことができました。