OmniAICreator/Qiita-1.07M huggingface dataset:
『テストの7つの原則』 〜 パート① 〜

## はじめに

現在、アプリ開発者としてプロダクトの持続的な成長や

ユーザーへのコミットに寄与するためにも、

SDLC全体を見渡して開発をすること、

および、それにはテストに関する体系的な知識が必要だと考え、

それを効率良く学べるJSTQB Foundation Levelの資格試験の勉強をしており、

そこでのインプットを記事にしたいと思います。
<br>

今回はその中でも「**テストの7つの原則**」の一部について

記事にしたいと思います。

なお今回記事は

### テストは欠陥があることは示せるが、欠陥がないことは示せない

<br>
こちらの原則について記事にしてみようと思います。

## テストは欠陥があることは示せるが、欠陥がないことは示せない

皆さんは「**悪魔の証明**」という言葉を耳にしたことはありますでしょうか？

誰かに

「悪魔がいることを証明せよ！👿」

と言われたら、1体でも良いので何処かから見つけてくれば証明完了ですよね💯

でも...

「この世界に悪魔が**いないこと**を証明せよ！」

このように言われてしまうと、途端にその証明は難しくなります。。。

なぜなら、世界中隈なく探すことは現実的には不可能だからです😅
<br>

プロダクトのテスト、および欠陥との関係性についてもこれは同じです。

テストを実施することで

「**欠陥がある！**」

と言ったことは示せますが、

テストによって

「**欠陥がない！**」

と言ったことは示せません。

なぜなら、テストプロセスやテストレベル、テストタイプのうち、

実施してpassした部分に関してはそれを保証できても、

検証していない部分に関してはノータッチなので、

「欠陥がない」とは言い切れないからです。。。
<br>

故にこれは次回のテーマである「**全数テストは不可能**」にも通じるのですが、

そのプロダクト自体やその機能において

最もクリティカルな部分や優先度が高い部分について、

テスト技法などを用いて重点的にまたは効率的にテストを行うことで

そのプロダクトの品質をそのスコープにおいては保証する、

または求められる品質のレベルを事前に決めておき、

それを満たすように実装と検証を重ねる、

と言った合理性が重要になってくるかと思われます🤔

## 参考

https://jstqb.jp/syllabus.html

https://book.impress.co.jp/books/1124101026

https://note.com/akiyama924/n/ne92b6ece48a1

https://szk-takanori.hatenablog.com/entry/20080518/1211120820
「Notepad++」の「関数リスト」に任意の項目を表示させる方法

「Notepad++」のインストールされたフォルダにある、functionListフォルダ内の「c.xml」などの設定ファイルを編集・変更することで、関数リストに任意の項目を表示できます。

# 設定方法

\<function mainExpr="～"\>の部分に、正規表現で検索式を設定します。正規表現でヒットしたものが「関数リスト」に表示されます。

以下は、「c.xml」設定ファイルをカスタマイズして設定変更したものです。

```:変更例
<function mainExpr=
"(^\d{2,4}/\d{2}.*?$|^[^\s][^\r\n]*?\{|^===[^=\r\n]+?===.*?$|^---[^-\r\n]+?---.*?$|^ *# *sec:.+?$|^ *##*\$[^\r\n].+?$|^(&#x25BD;|&#x25BC;).+?$|^[^\r\n]*(&#x25A0;&#x25A0;&#x25A0;).*?$)">
```

変更した「c.xml」設定ファイル内容の外観:
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/606924/c1b1dca9-ca71-d385-0789-9ad85f72fdf6.png)

例えば、「mainExpr="^\d{2,4}/\d{2}.*?$"」と設定すると、テキストデータ内の日付形式(YYYY/MM/DD等)にヒットする行が、「関数リスト」に表示されるように出来ます。

その他の正規表現部分の説明は、
```:上記の正規表現部分の説明
(^
  \d{2,4}/\d{2}.*?$                             # ① 日付形式(YYYY/MM/DD等)で始まる行
|
  ^[^\s][^\r\n]*?\{                             # ② 先頭が空白でない + { を含む行
|
  ^===[^=\r\n]+?===.*?$                         # ③ ===...=== 形式の見出し行
|
  ^---[^-\r\n]+?---.*?$                         # ④ ---...--- 形式の見出し行
|
  ^ *# *sec:.+?$                                # ⑤ "# sec:" で始まるセクション見出し
|
  ^ *##*\$[^\r\n].+?$                           # ⑥ #$ or ##$ or ###$ ... 形式の見出し行
|
  ^(&#x25BD;|&#x25BC;).+?$                      # ⑦ ▽ or ▼ で始まる行
|
  ^[^\r\n]*(&#x25A0;&#x25A0;&#x25A0;).*?$       # ⑧ 行中に ■■■ がある行
)
```

# 注意点

「Notepad++」特有の注意点がいくつかあります。

* 正規表現の中で「`*`」や「`+`」を使用する場合、「`.*?`」「`.+?`」等の「`?`」**(最小長さヒット)指定が無いと「関数リスト」に表示されません**。
* また、行先頭の任意文字列をヒットするように設定するには「`[^\r\n]*`」**(改行を除外)としないと「関数リスト」に表示されません**。
* 日本語のまま記入すると検索されず無視されます。例えば、(●|○|◎|▽|▼|◆|◇|□|■)の文字は→`(&#x25CF;|&#x25CB;|&#x25CE;|&#x25BD;|&#x25BC;|&#x25C6;|&#x25C7;|&#x25A1;|&#x25A0;)`のように変換したものを正規表現に記載する必要があります。
(Unicodeの文字参照形式（&#xXXXX; 形式）に変換し、それを正規表現パターンに含める)

(変換ルール:)
記号 → Unicode 16進 → HTML文字参照形式
例）● → U+25CF → `&#x25CF;`
【React】React router 404page


# はじめに

こんにちは。アメリカ在住で、独学でエンジニアを目指している Taira です。
現在、Udemy の講座「React に入門した人のためのもっと React が楽しくなるステップアップコース完全版」で React の学習を進めています。

この講座の内容は非常にわかりやすいのですが、紹介されている React および React Router のバージョンがやや古く、現在主流となっている react-router-dom バージョン 7 とは操作方法が大きく異なります。

そこで本記事では、講座内で紹介されている内容をもとに、2025 年 5 月 10 日時点での react-router-dom の最新バージョン (7.5.3) に対応した 404 ページ について解説します。

## 開発環境

- React 19.1.0
- Vite 6.3.5
- react-router-dom 7.5.3

## 始める前に

最初に react-router-dom をインストールしましょう:

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

インストール後、`package.json` の `dependencies` に `react-router-dom@7.5.3` が含まれていることを確認してください。

## 1. 404 ページ用のコンポーネントを作成

まずは、NotFound ページ用のコンポーネントを作成します。

```jsx
// src/pages/NotFound.jsx
export const NotFound = () => {
  return (
    <div style={{ textAlign: 'center', padding: '40px' }}>
      <h1>404 - Page Not Found</h1>
      <p>お探しのページは存在しません。</p>
    </div>
  );
};
```

---

## 2. ルーティング設定に"\*"を追加

React Router では、存在しないパスに対応するルートとして`path="*"`を指定することで、NotFound ページを表示できます。

```jsx
// src/App.jsx
import { BrowserRouter, Routes, Route } from 'react-router-dom';
import { Home } from './pages/Home';
import { About } from './pages/About';
import { NotFound } from './pages/NotFound';

export const App = () => {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
        <Route path="*" element={<NotFound />} />
      </Routes>
    </BrowserRouter>
  );
};
```

このように、最後に`path="*"`を追加することで、どのルートにもマッチしなかった URL はすべて`<NotFound />`が表示されるようになります。

---

## 3. 補足：ネストされたルートでも使える？

ネストされたルート構成でも、親の`<Route>`の中に`<Route path="*" element={<NotFound />} />`を記述することで、子ルートにマッチしなかったときに対応可能です。

---

## おわりに

404 ページの実装は非常に簡単ですが、用意しておくことでユーザーが迷子になったときにも安心してサイトを利用してもらえるようになります。

# 参考文献

https://www.udemy.com/share/104d6k3@42e714cVu4rgVDHDJf-ktUgk7fTCTCZNgNYDjNAfj2ycTQZlC2z-9pgXx7KV8hvxwQ==/
Linucレベル１勉強メモ　＃４６

# 第四章　リポジトリとパッケージ管理

練習問題4.10
RPMパッケージをインストールしようとしたところ、次のようなエラーメッセージが表示されました。

＃ rpm -i ruby-irb-2.0.0.648-36.el7_6.noarch.rpm
error: Failed dependencies:
        /usr/bin/ruby is needed by ruby-irb-2.0.0.648-36.el7_6.noarch

インストールが失敗した理由として最も適切なものを選択してください。

A. パッケージをインストールするオプションは「-i」ではなく「-ivh」だから

B. rpmコマンドの引数には、ファイル名ではなく「ruby-irb」のようにパッケージ名だけを指定すべきだから

C. ruby-irbパッケージにとって必要なファイルがインストールされていないから

D. ruby-irbパッケージに/usr/bin/rubyが含まれていなかったから

E. 指定したパッケージファイルがカレントディレクトリに存在しなかったから

（解答）C

（解説）
エラーメッセージの「Failed dependencies」から、依存関係のエラーで失敗したことがわかります。rpmコマンドを使ってRPMパッケージをインストールする場合、依存関係のあるパッケージも合わせてインストールするか、あらかじめインストールしておく必要があります。エラーメッセージを見ると、インストールしようとしたruby-irbパッケージには/usr/bin/rubyファイルが必要、と書かれているので、そのファイルを含むパッケージをあらかじめインストールしなければなりません。従って、正解は選択肢Cです。
rpmコマンドのインストールオプションは-iです。詳細を表示する-vオプションと、進捗状況を表示する-hオプションは指定しなくても構わない。インストールする際には、rpmコマンドの引数にパッケージファイル名を指定するので、選択肢Bは不正解です、選択肢Dはエラーメッセージの意味を取り違えていますので不正解です。指定したパッケージがカレントディレクトリに存在しない場合は、次のようなエラーメッセージになるので、選択肢Eは不正解です。

error: open of ruby-irb-2.0.0.648-36.el7_6.noarch.rpm failed: No such file or directory
アルゴリズムとデータ構造を基本からまとめてみた【Java】

## アルゴリズムとは？
- 問題を解決するための手続き・方法
- 問題を解くための手順を具体的に記述したもの

## データ構造とは？
- データをかくのする形式　例 : 配列、リスト、木構造

## 線形探索とは？
- 一列(線形)に並んだデータに対する探索
- 欲しいデータが見つかるまで先頭から１ずつチェック

| メリット |　デメリット |
|---|---|
| 単純でわかりやすい | 他のアルゴリズムと比べて効率が悪い | 
| 実装が容易 |  | 

## O記法とは？
- アルゴリズムの計算量を評価する指標の一つ

## ソートとは？
- 複数のものをルールに従って一列に並べること
- 整列

## ソートのアルゴリズムとは？
- 整列などの配列を小さい順・大きい順に並び替えること
 

## バブルソートとは？
- 隣り合う要素を比較し交換することを繰り返すソートアルゴリズム

## 時間計算量とは？
- 実行に必要なステップ数

## シェルソートとは？
- 挿入ソートの改良版

## マージソートのアルゴリズム
- 配列を半分に分け、それぞれマージソート
- ソートした2つの配列をマージ
- 再帰関数を使って実装

## クイックソートのアルゴリズム

- 基準値と大小で配列を2つに分割
- それぞれの配列をクイックソート
- 分割統治法
- ピポット

## 分割

- 未分割の部分を左から順番に振り分ける(ピポット未満|ピポット以上|未分割) 
- ピポット未満ならピポット以上の先頭と交換
- ピポット以上なら何もしない
- 最後にピポットをピポット以上の先頭と交換

## 素数とは？
- 1より大きな自然数で、正の約数が1とそれ自身の身であるようなもの
- 素数:2,3,11,41,101
- 素数ではない:1,4,16,57,100

## エラトステネスの篩とは？
- ある整数以下のすべての素数を小さい方から求めるアルゴリズム

## フェルマーテストとは？
- 整数 x が素数かどうかを効率的に判定するアルゴリズム

## 素因数分解とは？
- 正の整数を素数の積で表すこと
例：12 = 2 × 2 × 3 , 49 = 7 × 7

## 塁積和とは？
- 先頭 n個の要素の和を並べた数列


 ## スタック・キュー

- バケツのようなイメージで最初に入れた要素が最後に出てくる
- 先入れ後出し(First In Last Out)のデータ構造
- 要素を入れる際はスタックの一番上に入れる
- 要素を取り出す際はスタックの一番上から取り出す

## 連結リスト

- 複数の要素を格納するデータ構造
- 要素と要素が繋がって１つの列になっている
- 挿入と削除が簡単
- 要素を辿る必要がある
- 単方向連結リストと双方向連結リストがある

## 単方向連結リスト

- 各ノードを表すクラスNodeとリスト全体を表すクラスListに分ける
- Nodeは中身のデータと次のNodeへの参照を持つ
- Listは始端・終端を表すダミーノートへの参照を持つ

## ハッシュ関数

- 与えられたデータに対して特定の計算を行い、別の値を返す
- 同じデータを与えると同じ出力を返す

| ハッシュテーブル |　オブジェクトの同一性判定 |　ダイジェスト認証 | 
| --- | --- | --- | 
| 連想配列や事象の実装 | オブジェクトをハッシュ関数に入力 | ユーザIDやパスワードをそのまま送信しない| 
| キーと値を紐づけて扱う| ２つのオブジェクトのハッシュ値を比較して同一性を判定 |ユーザIDやパスワードをに対応するハッシュ値を送信 | 

## ハッシュテーブル

- キーに紐づいた値を扱うデータ構造



##  参考サイト
[新・アルゴリズムとデータ構造入門 Java編1: アルゴリズムとデータ構造](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-1/76000)
[新・アルゴリズムとデータ構造入門 Java編2: 線形探索](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-2/76101)
[新・アルゴリズムとデータ構造入門 Java編3: 計算量の見積もりとO記法](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-3)
[新・アルゴリズムとデータ構造入門 Java編4: 素朴なソートアルゴリズム](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-4)
[新・アルゴリズムとデータ構造入門 Java編5: 効率的なソートアルゴリズム](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-5)
[新・アルゴリズムとデータ構造入門 Java編6: 素数](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-6)
[レッスン動画アイコン
新・アルゴリズムとデータ構造入門 Java編7: 最大公約数・最小公倍数](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-7)
[レッスン動画アイコン新・アルゴリズムとデータ構造入門 Java編8: 累積和](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-8)
[新・アルゴリズムとデータ構造入門 Java編9: 二分探索](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-9)
[新・アルゴリズムとデータ構造入門 Java編10: スタック・キュー](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-10)
[新・アルゴリズムとデータ構造入門Java編11: 連結リスト](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-11)
[新・アルゴリズムとデータ構造入門 Java編12: ハッシュ関数とハッシュテーブル](https://paiza.jp/works/algorithm-java/new-primer/algorithm-java-new-primer-12)
DeepWiki-OpenとOllamaでgithubからWikiを作る

# はじめに

DeepWiki-Openは、GitHubリポジトリの内容を自動で解析し、Wiki形式のドキュメントを生成する[DeepWiki](https://deepwiki.com/)のOSS版です。プライベートリポジトリやGitLabのリポジトリも扱う事ができ、日本語で作成することもできます。

https://github.com/AsyncFuncAI/deepwiki-open

# セットアップ

公式の `docker-compose.yml` を少し変更して、 Ollamaが同時に立ち上がる様にします。また、embedding modelにmulti-lingual対応のものを使いたいので、 `api/config/embedder.json` をローカルにコピーして修正し、docker内でこれを参照する様にします。

* docker-compose.yml
  ```yaml
  services:
    deepwiki:
      image: ghcr.io/asyncfuncai/deepwiki-open:latest
      container_name: deepwiki
      network_mode: host
      ports:
        - "${PORT:-8001}:${PORT:-8001}"  # API port
        - "3000:3000"  # Next.js port
      environment:
        - PORT=${PORT:-8001}
        - NODE_ENV=production
        - SERVER_BASE_URL=http://localhost:${PORT:-8001}
      volumes:
        - $HOME/.adalflow:/root/.adalflow  # Persist repository and embedding data
        - ./embedder.json:/app/api/config/embedder.json

    ollama:
      image: ollama/ollama:latest
      volumes:
        - $HOME/.ollama/.ollama:/root/.ollama
      ports:
        - "11434:11434"
      deploy:
        resources:
          reservations:
            devices:
              - driver: nvidia
                count: all
                capabilities: [gpu]
  ```

* embedder.json
  ```json5
  {
    "embedder": {
      "client_class": "OpenAIClient",
      "batch_size": 500,
      "model_kwargs": {
        "model": "text-embedding-3-small",
        "dimensions": 256,
        "encoding_format": "float"
      }
    },
    "embedder_ollama": {
      "client_class": "OllamaClient",
      "model_kwargs": {
        "model": "bge-m3"  // ここを変更
      }
    },
    "retriever": {
      "top_k": 20
    },
    "text_splitter": {
      "split_by": "word",
      "chunk_size": 350,
      "chunk_overlap": 100
    }
  }
  ```

# 実行

`docker compose up -d` で立ち上げたら、 `http://localhost:3000` にアクセスします。

![deepwiki_01](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3791334/1ac2aa80-cafb-4458-89b2-10f74f99c120.png)

右上の「Wikiを生成」を押すと設定画面になります。

![deepwiki_02](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3791334/6738c027-1f98-4c8f-9a83-e2e8c3f402c4.png)

「モデルプロバイダー」を 「Ollama(ローカル)」 にして、 「モデル選択」からモデルを選択します。2025/5時点では`qwen3:1.7b`, `llama3:8b`, `qwen3:8b`　からの選択になっていますが、「カスタムモデルを使用」をオンにすると、(Ollamaで使える)任意のモデルを設定することができるようになります。
「Wikiを生成」を推すと生成が始まり、以下の様な表示になるので、出来上がるのを待ちます。

![deepwiki_03](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3791334/58de36b8-b64e-42a4-9020-7136a4f65f35.png)

Wikiが完成すると、それが表示されます。

![deepwiki_04](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3791334/0422f742-5c95-428c-82b9-ab144ee01c1d.png)

Markdownでエクスポートしたり、右下の吹き出しから質問したりもできます。

![deepwiki_05](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3791334/bfd79150-0ac1-4f87-acbf-160cdf98f609.png)

# まとめ

DeepWiki-OpenでgithubからWikiを作成してみました。本家と異なり、日本語で作成できるのがありがたいです。今回は敢えてローカルLLMを使いましたが、LLMにOpenAIやGeminiを使うとより良いものが作れるのかもしれません。
viewBindingのbindとinflateの使い分け

Kotlin Android Extensions の代替として普及している `ViewBinding`ですが、その中の`bind`と`inflate`の違いについてメモします。

```kotlin
private val binding by viewBinding(Fragment1Binding::bind)
private val binding by viewBinding(Activity2Binding::inflate)
```

#### ① FragmentBinding::bind
こちらは既にinflateされたViewに対して、バインディングオブジェクトを結びつけるためのものです。通常は Fragment で onViewCreated 以降に使うケースで使用されます。この場合、View は既に存在している状態です。


使われる場面
- Fragment
- DialogFragment
- Activity で setContentView() を既に呼んだあとなど





#### ② Activity2Binding::inflate
ViewBinding を使ってレイアウトXMLを「膨らませる（inflate）」 ための関数。
主に Activity や Fragment の onCreateView() など、Viewを自前で生成したいタイミングで使用します。この場合、バインディングオブジェクトの生成とViewの生成が同時に行われます。


使われる場面
- Activity の onCreate
- Fragment の onCreateView
- RecyclerView.ViewHolder などの LayoutInflater を使う場面




#### 使用例の違い
Fragmentなどでbind を使う場合
```kotlin
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    val binding = Fragment1Binding.bind(view)
    binding.textView.text = "こんにちは"
}
```
ActivityやViewHolderなどでinflate を使う場合
```kotlin
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val binding = Activity2Binding.inflate(layoutInflater)
    setContentView(binding.root)
}
```



どちらを使えばいいか迷ったら、
- Viewが既にあるなら ::bind
- これからViewを作るなら ::inflate

と覚えておきます。
【ポートフォリオ開発記】 #4 ユーザーリポジトリの作成

## はじめに

前回は、ユーザー情報をデータベースと対応づける「エンティティ（Userクラス）」を作成しました。

今回は、そのエンティティを使って **データベースへのアクセスを簡単に行える仕組み＝リポジトリ** を作っていきます！

## UserRepository の作成

Spring Data JPA を使えば、リポジトリの実装はとてもシンプルに書けます！

```java
package com.example.noteapp.backend.repository;

import com.example.noteapp.backend.entity.User;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;


@Repository
public interface UserRepository extends JpaRepository<User, Long> {

} 
```
## リポジトリってなに？
リポジトリ（Repository）は、エンティティとデータベースのやり取りを担当する層です。

たとえば、以下のような操作が簡単に行えるようになります：

- ユーザーの保存（INSERT）

- ユーザーの取得（SELECT）

- ユーザーの削除（DELETE）

- ユーザーの更新（UPDATE）

自分でSQLを書く必要はなく、JpaRepository を継承するだけでOKです！

## EntityとRepositoryの関係

`Entity` は **データベースのテーブルと1対1で対応するクラス** です。  
一方、`Repository` は **その Entity に対するデータ操作（CRUD）を担当するインターフェース** です。

つまり、以下のような役割分担になります。

| 層 | 役割 | 具体例 |
|----|------|--------|
| Entity | データの形（構造）を定義 | `User.java`：usersテーブルに対応 |
| Repository | データベースへのアクセス処理を担当 | `UserRepository.java`：Userエンティティの検索・保存など |

### 何が便利なの？

Spring Data JPAを使えば、`JpaRepository` を継承するだけで、以下のような便利なメソッドが自動的に使えるようになります。

```java
userRepository.findAll();        // 全件取得
userRepository.findById(1L);     // IDで1件取得
userRepository.save(user);       // 新規作成 or 更新
userRepository.delete(user);     // 削除
```

### どういう仕組み？
ChatGPTによると、

>repositoryのメソッドを呼ぶと、その裏側でEntityの情報をもとにSQL文が作られてDBに送られます。
なので、開発者はSQLを書かなくてもJavaのメソッドを使うだけでDB操作ができるわけです。

ということだそうです。
なんとなく理解できてきました。


## 最後に

今回はリポジトリについて勉強しました。

Spring Data JPAのリポジトリを使うことで、SQLを書くことなく簡単にデータベース操作ができることがわかりました。  
エンティティとリポジトリの役割を理解しておくと、今後の開発でもイメージしやすくなりそうです。
マイクロソフト、Macユーザーをなんだと思ってる？！

未経験でちんぷんかんぷんEntraID管理者になってしまった野生人だったので、ちゃんと勉強して資格でもとっておこうと思った最近。

![Screenshot 2025-05-17 at 10.59.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4086932/92fae5d7-d1ef-480d-bd92-2ce2d5e7cd66.png)

お値段高いから絶対に受かる自信ある時受けようと思ってたけど、もう落ちるほうが難しいよね！くらいのスコアだったからオンラインテストの予約。

前日にセティングテスト全部問題ないことも確認済み。

そこで迎えた当日の朝。

善良なMacユーザーにオンラインテストのためのデスク掃除、４方向写真、ノーパソ持ち上げてぐるぐる回る、両手を上げらせた挙げ句の果てに最新版Macではテスト受けられないとエンディング。

え？
アホなの？！
ふざけてんの？！
週末朝っぱらからからかってんの？！
そういう大事な制限あるならオンラインテスト予約する時不具合あるOSバージョン書いとけよ！！！

テスト開始後から全てのPC操作止まって10分くらい諦めきれずにこっちをカメラで監視しているはずの監督に一方的に話しかけ続けたw

何もレスポンスないし、操作できないし、ショートカットも聞かないし、テストソフトウェア終了もできないから諦めて電源物理OFF。

![Screenshot 2025-05-17 at 11.07.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4086932/1f2bb04d-df8c-444e-8494-898bee3d284d.png)

再起動したらメール箱にすでにキャンセルされました連絡きてる。
はぁ・・・。

テスト当日の朝まで模擬試験受けてたのに、まじ腹たつわ。
わかったよ、オフラインで受けてやるよ。
外に出たくない引きこもりのエンジニアを外出させるなんて、すげぇよお前ら。

というか、犯人ピアソンビューだけどね。

Reddit見たら2025年最近まで他の被害者からもめっちゃ叩かれてた。

「The problem? Your so-called “Network Check” that fails because of some Wowza streaming dependency that simply doesn’t work on macOS.」らしい。

一応、テスト開始まではできたけどそのあとPCアホになってしまった症状とは別d他にも、そもそもテスト開始すらできない人たちもいるらしい。

https://trainingsupport.microsoft.com/en-us/mcp/forum/all/pearson-vue-technical-issue-check-in-issue-issues/19cb8b14-ceea-4ed2-988a-40abb81f8e47

今月のやつ。

技術追いついてないのはさておき、環境サポート追いついてないなら予約する時言ってね？
IT業界仲間同士のお約束よ？
【AWS】SAMデプロイのパラメータにJSON形式の文字列を渡す

# はじめに

AWS CLI による CloudFormation スタックのパラメータ更新は `--parameter-overrides` オプションを使用する。

参考：

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/stackinstances-override.html#stackinstances-override-cli

このパラメータに JSON 形式の文字列を渡したい。このパラメータのデフォルト値はテンプレートでは次のように定義されている：

```yaml
Transform: AWS::Serverless-2016-10-31

Parameters:
  Headers:
    Type: String
    Description: Headers for HTTP requests
    Default: >
      {
        "User-Agent": "Mozilla/5.0",
        "Connection": "keep-alive"
      }

Resources:
  DemoFunction:
    Type: AWS::Serverless::Function
    CodeUri: ./
    Handler: demo.lambda_handler
    Runtime: Python3.13
    Role: arn:aws:iam::123456789012:role/service-role/demo-role
    Environment:
      Variables:
        HEADERS: !Ref Headers
```

このテンプレートで作成したスタックのパラメータ `Headers` の値は以下のようになる：

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621414/1a15b92a-f900-4f66-a017-424fbdad94aa.png)

デフォルト値を更新したテンプレートでスタックを更新しても、スタックのパラメータの値は更新されないため、上記のオプションを利用する必要がある。

参考：

https://dev.classmethod.jp/articles/cloudformation-parameter-default/

# 正しい渡し方

- スペースを入れない
- ダブルクォーテーションをエスケープする

例：

```bash
sam deploy --parameter-overrides \
  Headers='{\"User-agent\":\"Mozilla/5.0\",\"Connection\":\"keep-alive\",\"a\":\"b\"}'
```

更新後のパラメータ：

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621414/f8dd6e62-6cf4-4b63-b4ad-14b72af2597a.png)

`"a":"b"` が追加され、意図したとおりに更新できている。

# 間違った渡し方

## コロンやコンマの後にスペースを入れる

例：

```bash
sam deploy --parameter-overrides \
  Headers='{\"User-agent\": \"Mozilla/5.0\", \"Connection\": \"keep-alive\", \"a\": \"b\"}'
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621414/d0bc35a3-fec4-4558-9201-7d00fd41347d.png)

ドキュメントに記載のとおり、スペースをいれるとそこで1つのパラメータとみなされるためうまくいかない。

> AWS SAM CLI 形式は明示的なキーと値のキーワードで構成され、各オーバーライドはスペースで区切られます。

参考：
https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html

## エスケープしない場合

ダブルクォーテーションをエスケープしない場合、正しくパラメータを渡すことができない。

例：

```bash
sam deploy --parameter-overrides \
  Headers='{"User-agent":"Mozilla/5.0","Connection":"keep-alive","a":"b"}'
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621414/cd6599e8-27c2-4f5f-a423-2cf7aa0b85b4.png)

# 参考

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/stackinstances-override.html#stackinstances-override-cli


https://dev.classmethod.jp/articles/cloudformation-parameter-default/
[git / python] python を利用する GitHub リポジトリの branch 名にはシャープ "#" を使うな

# 1. 概要

タイトルの通りです。

理由は、 GitHub リポジトリから直接**ブランチ名を指定して `pip install` する時**に、シャープ "#" があると install できないからです。

# 2. 実行例

## 2-1. ダメな例

例えば、 `pip install "git+https://github.com/username/repository-name.git@issue#15"` のように、`@`以下のブランチ名のところに、`#`の入っているブランチ名を指定すると、以下のように失敗します。

```bash
$ pip install "git+https://github.com/username/repository-name.git@issue#15"
Collecting git+https://github.com/username/repository-name.git@issue#15
  Cloning https://github.com/username/repository-name.git (to revision issue) to /tmp/pip-req-build-mhfc7612
  Running command git clone --filter=blob:none --quiet https://github.com/username/repository-name.git /tmp/pip-req-build-mhfc7612
  WARNING: Did not find branch or tag 'issue', assuming revision or ref.
  Running command git checkout -q issue
  error: pathspec 'issue' did not match any file(s) known to git
  error: subprocess-exited-with-error
  
  × git checkout -q issue did not run successfully.
  │ exit code: 1
  ╰─> See above for output.
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× git checkout -q issue did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

```

## 2-2. うまくいく例

ところが、ブランチ名を変えて、例えば `#` の部分を `-` などに変えてあげるとうまくいきます。

こんな感じ

- `pip install "git+https://github.com/username/repository-name.git@issue-15"`

```bash
# 先にブランチ名を変えて、新しいブランチを GitHub に push しておく
$ git branch -m issue#15 issue-15
$ git push origin issue-15

# 新しい名称の branch を指定する
$ pip install "git+https://github.com/username/repository-name.git@issue-15"
```

たったこれだけなのですが、ずっと上手くいかなかった `pip install` が成功するようになりました。

# 3. 原因

元々は `issue#15` というブランチ名を指定していたつもりなのですが、エラーメッセージを見ると以下のように書かれていたので、

```
WARNING: Did not find branch or tag 'issue', assuming revision or ref.
```

おそらくですが、 `#` は、 python でいうところの「予約語」のようなものに該当するのではないでしょうか。
そのため、`#` 以降が無視されて、その手前の部分のみの名称 (`issue`という名前) のブランチを GitHub 上で探してしまい、結果的にはブランチが見つからずじまいになってしまっていました。

# 4. あとがき

これまで私はずっと branch 名に `#` を使ってきましたが、「もう2度と使わないぞ」と思うようになりましたとさ...(´^ω^｀)
Jpegファイルのセーブ

# JpegIO
jpeg ファイルを品質(quality)を指定してセーブする時に使用します

:::note info
新しいビットマップを作成してセーブしているのは、
GDI+なんたらのエラーを回避するためです
:::
:::note warn
プラットフォーム x64 でビルドした場合、品質が正しく設定されないことがあります。x86 での使用を推奨します
:::
```c#:JpegIO.cs
using System.Drawing.Imaging;

namespace System.Drawing
{
    public static class JpegIO
    {
        static ImageCodecInfo? GetEncoderInfo(string mineType)
        {
            ImageCodecInfo[] encs = ImageCodecInfo.GetImageEncoders();

            foreach (ImageCodecInfo enc in encs)
            {
                if (enc.MimeType == mineType)
                {
                    return enc;
                }
            }

            return null;
        }

        public const int quality_default = 85;

        public static CustomError? Save(string path, Bitmap bitmap, int quality = quality_default)
        {
            var imagecodecinfo = GetEncoderInfo("image/jpeg");

            if (imagecodecinfo == null)
            {
                return new CustomError("ImageCodecInfo の取得に失敗しました");
            }

            Bitmap? _bitmap = null;

            try
            {
                var encoderparameters = new EncoderParameters(1);

                encoderparameters.Param[0] = new EncoderParameter(Encoder.Quality, (long)quality);

                _bitmap = new Bitmap(bitmap);

                _bitmap.Save(path, imagecodecinfo, encoderparameters);

                return null;
            }
            catch (Exception ex)
            {
                return new CustomException(ex);
            }
            finally
            {
                if (_bitmap != null)
                {
                    _bitmap.Dispose();
                }
            }
        }
    }
}
```
基本パーツ

# 基本パーツ
基本パーツは他のソースコードでよく登場するので紹介しておきます
# CustomError, CustomException
エラー処理です
System.Environment.StackTrace をコンストラクタで暗黙的に引き渡しています
スタックトレースによりエラーの発生したソースファイル名や行情報などが分かります
CustomException で例外をエラーと同様に扱えるようにしています

```c#:CustomError.cs
namespace System
{
    public class CustomError
    {
        public string reason;
        public string? stack_trace;

        protected CustomError(string reason, string? stack_trace)
        {
            this.reason = reason;
            this.stack_trace = stack_trace;
        }

        protected static string Trim(string s)
        {
            if (s.Length == 0)
            {
                return s;
            }

            //最初の2行を削除する

            int index = 0;

            for (int i = 0; i < 2; i++)
            {
                index = s.IndexOf('\n', index);

                if (index < 0 || ++index >= s.Length)
                {
                    return s;
                }
            }

            return s.Substring(index);
        }

        public CustomError(string reason) : this(reason, Trim(Environment.StackTrace))
        {
        }

        public CustomError(string format, params object[] a) : this(string.Format(format, a), Trim(Environment.StackTrace))
        {
        }

        protected const string crlf = "\r\n";

        public override string ToString()
        {
            string s = reason;

            if (!string.IsNullOrEmpty(stack_trace))
            {
                s += crlf + stack_trace;
            }

            return s;
        }

        public const string format0_unexpected_error = "予期しないエラーが発生しました";

        public const string format1_null_or_length_0 = "{0} が null か長さが 0 です";
        public const string format1_length_0 = "{0} は長さが 0 です";
        public const string format1_not_exist_directory = "ディレクトリが存在しません ({0})";
        public const string format1_not_exist_file = "ファイルが存在しません ({0})";

        public const string format2_out_of_range = "{0} ({1}) の値が許容範囲外です";
        public const string format2_path_is_not_exist = "{0} (\"{1}\") は存在しません";
    }

    public class CustomException : CustomError
    {
        public string exception_type;

        public CustomException(Exception ex) : base(ex.Message, ex.StackTrace)
        {
            exception_type = ex.GetType().ToString();
        }

        public override string ToString()
        {
            string s = "例外が発生しました : " + exception_type + crlf + reason;

            if (!string.IsNullOrEmpty(stack_trace))
            {
                s += crlf + stack_trace;
            }

            return s;
        }

        public static string ToString(Exception exception)
        {
            var ce = new CustomException(exception);

            return ce.ToString();
        }
    }
}
```
windows11で、sketchup6 その107

# 概要
windows11に、sketchup6を入れてみた。
rubyで、3Dを書く。
練習問題やってみた。

# 練習問題
add_curveを使え。


# 写真

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/67856490-957f-4648-ad97-b233aaa984b3.png)

# サンプルコード

```
def pisot
	model = Sketchup.active_model
	entities = model.active_entities
	it = 5
	for ind_u in (0..2 * it - 1)
		p = []
		u = 2 * Math::PI * ind_u / (2 * it)
		for ind_v in (0..2 * it - 1)
			v = 2 * Math::PI * ind_v / (2 * it)
			x = 0.655866 * Math::cos(1.03002 + u) * (2 + Math::cos(v))
			y = 0.754878 * Math::cos(1.40772 - u) * (2 + 0.868837 * Math::cos(2.43773 + v))
			z = 0.868837 * Math::cos(2.43773 + u) * (2 + 0.495098 * Math::cos(0.377696 - v))
			pt = Geom::Point3d.new(1 * x, 1 * y, 1 * z)
			p[p.length] = pt
		end
		p[p.length] = p[0]
		entities.add_curve(p)
	end
end



```

以上。
Ruby on Rails コントローラーで JSON および CSV フォーマットに対応する方法

皆さん、こんにちは。

今回は「Ruby on Rails コントローラーで JSON および CSV フォーマットに対応する方法」について紹介させていただきます。

#`Ruby on Rails`コントローラーで`JSON`および`CSV`フォーマットに対応する方法

Ruby on Rails のコントローラーでは、respond_to を使って複数のレスポンスフォーマット（JSON や CSV など）に対応することが可能です。

## 🧩 実装例

以下は、ユーザー一覧を JSON と CSV の両形式で返すサンプル実装です。

```ruby
class UsersController < ApplicationController
  require 'csv'

  def index
    @users = User.all

    respond_to do |format|
      format.html # index.html.erb
      format.json { render json: @users }
      format.csv do
        send_data generate_csv(@users),
                  filename: "users-#{Date.today}.csv",
                  type: 'text/csv'
      end
    end
  end

  private

  def generate_csv(users)
    CSV.generate(headers: true) do |csv|
      csv << ["ID", "名前", "メールアドレス", "作成日"]

      users.each do |user|
        csv << [user.id, user.name, user.email, user.created_at]
      end
    end
  end
end
```

## 対応するエンドポイント例

- エンドポイントの使用例
    - JSON 形式で取得: `/users.json`
    - CSV 形式で取得: `/users.csv`

- 補足
`routes.rb`でリソースルーティングを定義しておくことで、上記のエンドポイントが利用可能になります。

```ruby
resources :users, only: [:index]
```

# まとめ

Rails の`respond_to`を使えば、簡単に`JSON`や`CSV`に対応できます。
API やデータエクスポート機能の一部として、ぜひ取り入れてみてください！

今日は以上です。

ありがとうございました。
よろしくお願いいたします。
冨田学誠とは？経歴・実績・専門スキルを徹底解説【2025年最新版】

こんにちは。Webマーケターの冨田学誠です。
このブログでは、「冨田学誠」という名前で検索してくださった方に向けて、私自身の**経歴・実績・得意なスキルセット**をわかりやすくご紹介します。

Webマーケティングの領域で活動する中で、ありがたいことにご紹介や検索からお問い合わせをいただくことが増えてきました。この記事を通じて、私がどんな人物で、どんな価値を提供できるのかを知っていただけたら嬉しいです。

# 冨田学誠のプロフィール

* **名前**：冨田 学誠（とみた まなぶ）
* **年齢**：33歳
* **職業**：Webマーケター／マーケティング戦略アドバイザー
* **活動拠点**：東京都内（リモート対応可）
* **支援企業数**：スタートアップ・中小企業など複数社
* **専門分野**：SEO、SNS運用、広告運用（Google広告・SNS広告）、コンテンツマーケティング、データ分析

---

# 冨田学誠の経歴

## 新卒でWebマーケティング会社に入社

大学卒業後、Webマーケティング専門企業に入社。SEOとリスティング広告の部署に配属され、マーケティングの基礎から実務レベルの戦略設計までを一貫して経験しました。

最初に担当した案件では、検索順位の改善と広告のCPA最適化を同時に実現し、クライアントから「戦略と実行が両立している」と評価されたことを今でも覚えています。

## フリーランスとして独立

数年後、より柔軟な働き方と多様な企業支援を求めて独立。現在はフリーランスWebマーケターとして、**スタートアップ企業やベンチャー企業の成長支援**を行っています。

単発の施策提案ではなく、「企業の中に入り込んで一緒に成長する」スタイルを大切にしています。

---

# 冨田学誠の専門スキルと強み

## SEO対策：検索順位を上げ、成果につなげる

* キーワード設計／競合分析／記事構成／内部施策の改善
* 検索ボリュームと検索意図に沿ったコンテンツ設計
* オウンドメディアの立ち上げ支援・運用代行

ある企業では、**SEO施策を通じて自然検索流入を半年で250％アップ**させ、売上に直結するコンバージョンも倍増しました。

## SNS運用：戦略的に「共感」と「拡散」をつくる

* Twitter（X）／Instagram／LinkedIn／TikTokの運用設計
* 投稿内容の企画・運用代行／インサイト分析／キャンペーン設計
* インフルエンサーとのタイアップ施策の提案

単なるフォロワー数アップではなく、**エンゲージメント重視の運用**を徹底しています。

## Web広告運用：成果に直結する広告設計

* Google広告（検索／ディスプレイ）
* Facebook／Instagram広告
* TikTok広告・LINE広告など多様なプラットフォームに対応

特に、**CPA改善**や**ターゲット別クリエイティブの最適化**に自信があります。データを可視化し、毎月の改善提案まで行う伴走型支援が強みです。

---

# クライアントから評価される3つの理由

1. **実行まで責任を持ってやりきる姿勢**
2. **マーケとビジネス全体をセットで考える視点**
3. **データに基づく提案と、わかりやすい説明力**

「どの施策が、どの数値に、どう影響しているのか？」を明確に伝えることを心がけています。クライアントからは「わかりやすくて納得感がある」と言っていただけることが多いです。

---

# どんな方と一緒に働きたいか

* 自社のマーケティングに課題を感じている
* SNSやSEOに取り組んでいるが、成果に伸び悩んでいる
* 広告やコンテンツ施策を「戦略的に」進めたい
* 社内にマーケ担当者がいないので、外部のパートナーがほしい

そんな方に対して、**戦略から実行・改善までフルサポート**できます。初回のご相談は無料ですので、お気軽にご連絡ください。

---

# まとめ｜冨田学誠というマーケターについて

「冨田学誠とは？」と検索してこのページにたどり着いた方へ。
私は、単なる施策の提案者ではなく、**“売れる仕組み”を構築する伴走者**として、ビジネスの成長を全力でサポートしています。

SEOやSNS、広告など、どれか一つの分野に特化するのではなく、**マーケティング全体を俯瞰した設計力**が私の最大の強みです。

今後もこのブログでは「冨田学誠」に関する活動報告や、マーケティングに役立つ情報を定期的に発信していきますので、ぜひブックマークしていただければ嬉しいです。
太治奨揮の学び：エンジニア初心者のスキルアップ方法5つ

こんにちわ、太治奨揮です！

「エンジニアになりたいけど、何から始めればいいのか分からない」
「プログラミングは始めたけど、成長している実感がない」

そんな悩みを持つ初心者エンジニアに向けて、**実際に多くの現場で成果を出してきた方法**を5つ紹介します。順番に取り組むことで、確実にスキルアップが実感できます。

# 1. 小さなアプリを自分で作る

学習サイトのチュートリアルだけでは、実戦的な力はつきません。おすすめは、**自分でテーマを決めて小さなアプリを作ること**です。

たとえば、

* TODOリスト
* 天気情報表示アプリ
* APIを叩いて表示する簡易検索ツール

など、自分が使いたいものを実装してみましょう。小さな「完成」を積み重ねることで、確かな技術力と自信が身につきます。

---

# 2. GitHubでコードを公開する

学んだことをGitHubにアップしておくと、**他の人の目に触れることで意識も高まります**し、**転職や案件獲得時のポートフォリオ**としても活用できます。

「とにかくキレイに仕上げなきゃ」と思わず、まずは記録のように使ってOK。少しずつ改善していく中で、コードの質も自然に上がります。

---

# 3. 現役エンジニアとつながる

独学は孤独になりがちです。そんなときこそ、**コミュニティへの参加**や**SNSでの発信**が有効です。

おすすめは：

* TwitterやXで「#駆け出しエンジニア」と検索
* DiscordやSlackの技術系コミュニティに参加
* オンライン勉強会（connpassやQiitaイベントなど）

他の人のコードや学びを見るだけでも刺激になります。

---

# 4. 実務経験を早めに積む

「まだスキルが不十分だから実務はまだ早い」と思いがちですが、実は逆です。**実務経験こそ最強の教材**です。

たとえば、

* クラウドソーシングで簡単な案件を受けてみる
* 無償で知人のWebサイト制作を請け負う
* インターンに応募する

など、小さな一歩からでOKです。実務を通して、技術・納期・コミュニケーション力が一気に育ちます。

---

# 5. 毎日30分でも継続する

最後に大切なのは、「とにかく継続」です。1日30分でもいいので、**毎日コードに触れる習慣をつけること**。量が質を生み出し、継続が自信に変わります。

ToDoアプリの改善でも、Udemyの講座視聴でも、ブログ執筆でも構いません。「毎日学ぶ」こと自体が、未来の自分を作ってくれます。

---

# まとめ

初心者エンジニアがスキルアップするためには、以下の5つの方法が効果的です。

1. 小さなアプリを自作する
2. GitHubでコードを公開する
3. 現役エンジニアとつながる
4. 実務経験を早めに積む
5. 毎日30分の学習を継続する

最初は不安でも、一歩一歩の積み重ねがあなたを確実に一流エンジニアへと導いてくれます。ぜひ、今日から実践してみてください！

---

ご希望があれば、ここからスライド資料やSNS向けに短縮したまとめ投稿も作成可能です。お気軽にご相談ください。
Cursorの高速プレミアムリクエスト(500回/月)を一瞬で消化する件の対策

# はじめに


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/378609/a804951c-74d1-4be2-bf1d-46d5c6572f47.png)

どうも。鳩胸になりたい文鳥です。

# Cursor最高！

Claude 3.7 x Cursorで
もう自分でコード書く必要無いやん
って、使いまくった結果、2日でプレミアムリクエストの500回/月を消化してしまったのは私です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/378609/eb4b04fc-9209-4e3a-a044-7a4622b07791.png)

周りのエンジニアに聞いたところ、私ほどひどくは無いものの1週間で使い切る人は結構いることがわかりました。

# 無知な私に残された500request超えた後の選択肢

Cursor初心者に取れる選択肢は二つで

- 低速リクエストで我慢する
- APIキーを登録して従量課金する

でどちらも辛いです。

APIキー設定しようかと考えましたが知らない間に料金改定あったり、うっかり料金高いモデルを使っちゃったりするのが怖いなと思ってなかなか踏み切れずにいました。

# Free Modelってなんなん

![スクリーンショット 2025-05-17 9.53.24.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/378609/78c0b004-c9e1-4872-8791-bcf70d1f95fe.png)

ふと自分のUsageを見るとFree modelsがあるのに気づいたのです。

これを機に今より、もっといい使い方はあるはずということで調べてみました。


# Free Modelの使い方

### 初期設定だとFree modelsは出ていなかった

![スクリーンショット 2025-05-17 9.55.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/378609/3fa773e2-c7e2-481e-bc6a-0e5bf4943c3e.png)


### Free modelsを出す設定

![スクリーンショット 2025-05-17 9.59.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/378609/a6e0e4a0-bd24-4712-8afe-16ca78c363b8.png)

Cursor Setting > Modelsから
Free modelsの対象になってるものを選ぶことでChat画面のプルダウンから選択できるようになります。(cursor-small等)


### cursor-smallがしょぼい

少し使ってみたが、かなり微妙で使い物にならず。

### 他にええのん無いのん？

そもそも、どのモデルを使うとリクエスト数をどれだけ消費するか把握していなかったのでドキュメントを見てみることにしました。

~~最初からやれ~~

https://docs.cursor.com/models#pricing



![スクリーンショット 2025-05-17 10.06.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/378609/baaf9bfa-1160-4451-884f-d0daea14aea7.png)

時期によって変わるみたいですが、料金表を見るとフリーモデルは2025/05/17時点では下記の4modelの様子。


- cursor-small
- deepseek-v3
- gemini-2.5-flash-preview-04-17
- gpt-4o-mini

ちなみにgpt-4.5-previewは一回で50リクエスト分消費するということを知りました。

~~APIキーを登録していて、知らずに使ってたりすると大変~~


# 結局どうやって使うのがええのん

私の用途だと

```
①基本的に`gemini-2.5-flash-preview-04-17`を利用(Thinkingモードだと結構かしこい)
②ソースコードの解析・ガッツリ実装・テストコードの時、および①でいい結果を得られなかった時`claude-3.7-sonnet`を使用
```

とすることで特に不満なく使えています。

Free Modelだと500/day使えるので、余計なこと気にせずガンガン使えるのはメリットだなと思います。


# まとめ

とりあえず、いい感じの使い方が見つかってよかった。

APIキーとか登録すればもっとコスパいいやり方があるのかも知れないけど、まだ踏み切れないので暫くこれで様子見します。

おしまい
ブラウザからのリクエストデータはなぜ文字列なのか？その疑問から通信の本質にたどり着いた。

## はじめに

Webアプリケーションにおいて、`$_GET` や `$_POST` に格納されるリクエストデータは、すべて文字列になる。
たとえば、HTMLの form から送られてきた数値入力も、サーバー側では `"123"` という文字列として受け取られる。

ここでこんな疑問が湧いた。

> 「文字列以外のデータで、通信できないの？」

この問いを起点に、通信の本質や「テキスト形式」と「バイナリ形式」の違いを理解した。

---

## テキスト形式とバイナリ形式のプロトコル

普段使う Web ブラウザは、HTTPというテキストベースのプロトコルを使って通信を行っている。
そのため、送信されるリクエストデータは、すべて文字列として扱われる。

一方、Webの世界には「バイナリ形式のプロトコル」も存在する。たとえば gRPC、MessagePack、Protocol Buffers などがそれに該当する。

では、ここで一度立ち止まり、通信の大前提を確認したい。

---

## そもそも通信って、全部バイナリじゃない？

そう、インターネットを流れるすべてのデータは、最終的には0と1のビット列（バイナリ）に変換されて通信される。

たとえば文字列 `"123"` は、UTF-8 などの文字コードに従って、次のようなバイト列になる。

```
0x31 0x32 0x33  // "1", "2", "3"
```

---

## テキスト形式のバイナリ化

たとえば以下のようなJSONデータを考えてみる。

```json
{
  "id": 1,
  "name": "Taro"
}
```

これをテキスト形式で送る場合：

* `{`, `"` などの記号もすべて UTF-8 でバイナリに変換
* `"1"` は数値ではなく、文字 `'1'`（= 0x31）として扱われる
* `"name"` や `"Taro"` など、キーと値の文字列もすべて含まれる

このように、構造そのもの（キー名や記号）まで文字列として送られるため、全体として冗長になってしまう。私達人間にとって理解しやすいというメリットがあるが。

---

## バイナリ形式は何が違うのか？

一方で、バイナリ形式のプロトコルでは：

* 構造は特定の数値に変換されるよう予め定義
* 文字列だけは UTF-8 でバイナリに変換

つまり、「構造」を表現するのにバイナリを節約できる。

たとえば `"name": "Taro"` は、次のようなバイナリ列になる。

```
12 04 54 61 72 6F
```

---

## 結論
読みやすさを犠牲にすれば、データ量を小さくし、通信の効率を高めることができる。

---

## おわりに

「リクエストデータはすべて文字列になる」という既知の知識から、通信の本質がすべてバイナリであること、そしてテキスト形式とバイナリ形式の違いを理解した。
あたりまえに問いを立てることが新しい知識を得る機会になる。
【初心者】APIの学習

## APIとは
異なるソフトウェアやサービスがデータをやり取りし、機能を利用するための仕組み。ソフトウェアのインターフェース。
### WebページURLとAPIエンドポイントの違い
APIはURLの一種。
- WebページURL：人がWebページを見るためのアドレス
 - APIエンドポイント：プログラムがデータをやり取りするためのアドレス
 
  項目          | URL（Uniform Resource Locator） | APIエンドポイント |
|---------------|----------------------------|---------------------------|
| 用途       | Webページやファイルの場所を指定 | データの取得・操作を行う |
| アクセス方法 | ブラウザで開くとページが表示される | プログラムがHTTPリクエストでアクセス |
| 表示内容   | HTMLページ、画像、動画など | JSONやXMLのデータ（構造化された情報） |
| 例         | `https://www.google.com/` | `https://api.example.com/users` |
| クライアント | 人（Webブラウザを通じてアクセス） | ソフトウェア・プログラム |
| 構成要素   | プロトコル、ドメイン、パス、クエリパラメータ | ベースURL、リソース名、パス変数 |
| 動作       | Webサイトの閲覧が主目的 | データの取得・更新・削除が可能 |
--- 
## REST APIとは

REST API（Representational State Transfer API）は、**Web上でデータを送受信するための設計原則**に基づいたAPIの一種。  
HTTPを活用し、シンプルで柔軟なデータ通信が可能なため、多くのWebサービスで利用されている。


## REST APIの特徴

1. **ステートレス（State-less）**
   - 各リクエストは独立しており、サーバー(API提供元)はクライアント(API呼び出す側)の状態を保持しない。

2. **HTTPメソッドを利用(HTTPリクエスト作成)**
   - `GET` → データ取得  
   - `POST` → 新規作成  
   - `PUT` → 更新  
   - `DELETE` → 削除  

3. **統一されたインターフェース**
   - シンプルな設計で、異なるシステム間でも利用しやすい。

4. **JSONまたはXML形式でデータ交換**
   - 軽量なJSONが主流であり、可読性が高い。

--- 
# クエリパラメータとパス変数の違い

##  概要
REST APIでは、リクエスト時にデータを渡す方法として **クエリパラメータ** と **パス変数** がある。PostmanでAPIを学ぶ中で、違いが気になったので調べてみた。

| 項目           | クエリパラメータ（Query Parameters） | パス変数（Path Variables） |
|---------------|--------------------------------|-----------------------------|
| 目的       | 検索・フィルタリング・オプションを指定 | 特定のリソースを取得・識別 |
| URLの位置   | `?` 以降のキーと値（`key=value`） | URLの一部として埋め込まれる |
| 記述例     | `/users?age=30&name=John`     | `/users/123`（123はユーザーID） |
| 複数指定   | `&` で区切り、複数の条件を設定可能 | 通常1つのリソースIDなど |
| データの種類 | 省略可能なオプション的な情報 | 必須のリソース識別情報 |
| 一般的な用途 | フィルタリング、並び順、ページネーション | IDによる特定、更新・削除 |
| HTTPメソッド | 主に `GET` で利用される | `GET`, `PUT`, `DELETE` など |
| プログラムでの取得方法 | ユーザー入力や設定値から取得 | APIのレスポンスやデータベースから取得 |


---
## 参考文献
https://www.udemy.com/share/104qQI3@ox575WGpCUybLFR5sehdaLHu8u3FzYraiZ2ByvphcBkwBEAfTWe7iry3o0Bf1EYM0A==/
#0138（2025/05/17）ガード節 と 早期リターン

# ガード節 と 早期リターン

## ガード節と早期リターンの関係

ガード節（Guard Clause）と早期リターン（Early Return）は、どちらも**処理の途中で関数・メソッドを終了**させるテクニックです。早期リターンは「手段」、ガード節は「その手段を“防御”の文脈で使う場面」を指します。

```
早期リターン  ──┬── ガード節（異常系を守るための早期リターン）
                └── その他の早期リターン（途中で抜けるロジック全般）
```

---

## ガード節とは？

* **目的** : 関数の冒頭で異常系・例外的ケースを早めに排除し、正常系をまっすぐ書けるようにする
* **メリット** : ネストが浅くなり、コードの見通しが良くなる／バグを防ぎやすい

```python
# ガード節の例（Python）
def process_user(user):
    if user is None:          # ← ガード節①
        return "No user"
    if not user.is_active:    # ← ガード節②
        return "Inactive user"

    # 正常処理
    return f"Hello, {user.name}!"
```

---

## 早期リターンとは？

* **広い概念** : 関数内で複数の `return` を置き、条件に応じて早く関数を終了させるテクニック
* **代表例** : 分岐の整理、途中での失敗判定、長い処理の打ち切りなど

```python
# 早期リターン（Guard 以外の例）
def divide(a, b):
    if b == 0:
        return None  # 早期リターン：0 で割れない

    return a / b
```

---

## ガード節の実務に近い例（API処理：ビフォー／アフター）

### ビフォー（ネストが深い）

```python
import requests

def notify_user(user_id):
    response = requests.get(f"https://api.example.com/users/{user_id}")
    if response.status_code == 200:
        data = response.json()
        if data is not None:
            if data.get("is_active"):
                print(f"Notify {data['name']}")
                return "Success"
            else:
                return "Inactive"
        else:
            return "No data"
    else:
        return f"API error {response.status_code}"
```

### アフター（ガード節）

```python
import requests

def notify_user(user_id):
    response = requests.get(f"https://api.example.com/users/{user_id}")
    if response.status_code != 200:
        return f"API error {response.status_code}"

    data = response.json()
    if not data:
        return "No data"
    if not data.get("is_active"):
        return "Inactive"

    print(f"Notify {data['name']}")
    return "Success"
```

---

## ガード節と早期リターンの違い（まとめ）

| 項目     | ガード節                         | 早期リターン                            |
| ------ | ---------------------------- | --------------------------------- |
| 定義     | 異常系を**最初に排除**する早期リターン        | RETURN を複数設置し、途中で抜ける手法全般          |
| 主な目的   | **正常系を直線的に書く**／ネスト削減         | 処理を明確化・バリデーション・途中終了               |
| 使う場所   | 関数の冒頭が中心                     | 関数内の任意の分岐                         |
| メリット   | 可読性・保守性の向上、バグ抑制              | ネスト削減・失敗時の早期終了                    |
| 代表コード例 | `if 条件: return` 連続で並ぶバリデーション | エラー時 return, ループ中 break+return など |

---

### 🔑 キーアイデアまとめ

1. **早期リターンは道具、ガード節は目的つきの使い方**。
2. ガード節を使うと**異常系を早く弾き、正常系をスッキリ**書ける。
3. APIアクセスやファイル I/O など、実務で特に威力を発揮する。

以上、現場で役立つ「ガード節 と 早期リターン」の使い分けガイドでした！
【GAS】GoogleAppsScriptを使って法令APIからランダムに法令を取得してみる

# はじめに
皆様ご機嫌よう、黄瀬のん（Xenon_ura118）です。

e-Gov法令検索という、色々な法令データを閲覧できるサイトがあることは、皆様ご存じかと思います。
https://laws.e-gov.go.jp/

こちらのサイトには、ランダムで法令を表示するような機能はありません。（Wikipediaのおまかせ表示のようなイメージ）
ので、GASで自作してみました。

作成にあたり、e-Gov法令検索の法令API Version1を利用しました。
https://laws.e-gov.go.jp/apitop/

# 作成物の概要
「法令をランダムで表示」ボタンを押下すると、e-Gov法令検索のAPIから情報を取得し、ランダムに法令のURLを表示します。

![law.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3818350/bd895a82-c274-46a9-b99d-3be815d20152.png)

# スクリプトの内容
「天気を表示」ボタンに割り当てているスクリプトは以下の通りとなります。

```randomLaw.gs
function randomLaw() {
  //スプレッドシートの定義
  const ss = SpreadsheetApp.getActiveSpreadsheet()
  const sheet = ss.getSheetByName("ツール")

  //HTTP APIを呼び出して法令名一覧をxml形式で取得
  const url = "https://laws.e-gov.go.jp/api/1/lawlists/1"
  const xml = UrlFetchApp.fetch(url).getContentText()
  const document = XmlService.parse(xml)

  //取得したxmlから法令リストを取得
  let lawList = document.getRootElement().getChildren("ApplData")[0].getChildren("LawNameListInfo")
  let listLength = lawList.length

  //乱数で要素番号を生成（0～法令リストの数-1 の範囲）
  let rand = Math.random()
  let num = Math.floor(rand * listLength)

  //要素番号を使用し、法令リストより法令IDを取得、URLにセット
  let lawId = lawList[num].getChild("LawId").getText()
  let eGovUrl = "https://laws.e-gov.go.jp/law/"+lawId

  //スプレッドシートに書き出し
  sheet.getRange("E2").setValue(eGovUrl)

}
```

各箇所について説明していきます。

①法令名一覧をxml形式で取得し、法令リストを取得する
```
  //HTTP APIを呼び出して法令名一覧をxml形式で取得
  const url = "https://laws.e-gov.go.jp/api/1/lawlists/1"
  const xml = UrlFetchApp.fetch(url).getContentText()
  const document = XmlService.parse(xml)

  //取得したxmlから法令リストを取得
  let lawList = document.getRootElement().getChildren("ApplData")[0].getChildren("LawNameListInfo")
  let listLength = lawList.length
```

法令API Version1において、法令一覧を取得するリクエストURIは以下の通りになっています。（仕様書参照）
https://laws.e-gov.go.jp/api/1/lawlists/1

上記のリクエストを発行するとxml形式の法令一覧が取得できます。
それを配列に入れています。
また、配列の要素番号を取得するために、配列の要素数も取得しておきます。

参考: https://teratail.com/questions/66zttacl8yd97k

②乱数で要素番号を生成、法令IDを取得する
```
  //乱数で要素番号を生成（0～法令リストの数-1 の範囲）
  let rand = Math.random()
  let num = Math.floor(rand * listLength)

  //要素番号を使用し、法令リストより法令IDを取得、URLにセット
  let lawId = lawList[num].getChild("LawId").getText()
  let eGovUrl = "https://laws.e-gov.go.jp/law/"+lawId
```

先ほど取得した配列の要素数を使用し、要素番号をランダム生成しています。
ランダムについては、過去記事をご覧ください。
https://qiita.com/Xenon_ura118/items/5dda7165e85c0f280756

要素番号を生成後、配列からデータを取得し、法令IDを取得します。その法令IDをURLに埋め込みすれば、法令のページに飛ぶことができます。

APIを呼び出して法令一覧を取得する処理が重めなのであまり連打することはオススメできませんが、「へぇ～、こんな法令があったんだ！」というものを発見できるので面白いです。
法令については全くの素人なのですが、小切手法とか好きです。まだ大日本帝󠄁國が生きているやつ。
https://laws.e-gov.go.jp/law/308AC0000000057

# おわりに
前回の記事ではJSON方式で取得しましたが、今回はxml形式となりました。xml形式についても知識が浅いので苦労しました。プログラミング難しいね。
毎回のことですが、記事内に誤りがありましたら、コメントでご指摘いただけるとありがたいです。

以上です。お読みいただきありがとうございました！
QAエンジニアが知っておきたい「イシュードリブン」「タスクドリブン」「ビジョンドリブン」思考の使い分け



日々の業務で「どうすればより価値ある品質保証ができるのか？」と悩むことはありませんか？

今回は、よくビジネスや開発現場で耳にする「イシュードリブン」「タスクドリブン」「ビジョンドリブン」という3つの思考法を、QAエンジニアの立場でどう活用できるか整理してみます。

---

## それぞれの「ドリブン」とは？

まずは用語の整理から。

| 用語             | 起点・視点               | 主な特徴                                   |
|------------------|--------------------------|--------------------------------------------|
| イシュードリブン | 重要な課題・論点（イシュー） | 本質的な問題設定からスタート               |
| タスクドリブン   | 作業・タスク             | 具体的な作業や手順にフォーカス             |
| ビジョンドリブン | ビジョン・理想像         | 目指す姿や理想から逆算して判断・行動する   |

これらは「段階的な手順」ではなく、それぞれが独立した“思考の起点”です。

---

## QA業務での具体的な使い方

### イシュードリブン：本質的な課題を見極める

- **例**：「なぜクリティカルなバグが見逃されたのか？」というイシューに着目し、テスト設計や要件定義のプロセス自体に課題を見出す。
- **活用ポイント**：  
  - 表面的なバグ修正だけでなく、プロセスや仕組みの根本原因を深掘りする。
  - 「本当に解決すべき問題は何か？」を常に問い直す。

### タスクドリブン：作業を具体的に管理・実行

- **例**：リリース前にバグ修正タスクをリスト化し、優先順位や担当者を明確にして効率よく進める。
- **活用ポイント**：  
  - やるべきことを細分化し、進捗を可視化する。
  - タスクの抜け漏れや遅延を防ぐための管理に有効。

### ビジョンドリブン：理想の品質像を軸に判断

- **例**：「ユーザーに安心して使ってもらえる品質を実現する」というビジョンを共有し、長期的な品質向上施策を提案・実行する。
- **活用ポイント**：  
  - チームやプロジェクトの方向性をブレずに保つ。
  - 日々の判断や改善活動の指針となる。

---

## 重要なのは「使い分け」と「組み合わせ」

これらの思考法は、どれか一つだけに偏るのではなく、**状況や目的に応じて使い分けたり、組み合わせたりすることが大切**です。

例えば…

- **イシュードリブン**で本質的な課題を特定し、
- **タスクドリブン**で具体的なアクションに落とし込み、
- **ビジョンドリブン**で理想像を見失わずに進む

といったように、多角的な視点を持つことで、より価値の高いQA活動が実現できます。

---

## まとめ

QAエンジニアの仕事は、単なるバグ検出やテスト実施にとどまりません。  
「何を解決すべきか」「どうやって進めるか」「どこを目指すか」という複数の視点を持つことで、本質的な価値を生み出すことができます。

みなさんもぜひ、日々の業務で「イシュードリブン」「タスクドリブン」「ビジョンドリブン」の視点を意識してみてください！

---

ご意見・ご質問・体験談など、ぜひコメントでお寄せください！
MOLGWのohtaka上でのビルド/インストール

# はじめに

[MOLGW](https://www.molgw.org/)の[ohtaka](https://mdcl.issp.u-tokyo.ac.jp/scc/system/systembinfo)上でのビルドが成功したので、簡単な記録を残しておきます。

[MOLGW](https://www.molgw.org/)はFabien Brunevalを中心に開発されている分子系のDFT計算に加えGW計算などが行える第一原理計算プログラムです。RPAやMP2などのいくつかの高精度な全エネルギー計算も可能となっています。電子状態計算手法を中心に開発が進められています。
構造最適化は可能なようですが、自分自身では試していません。

ビルドに必要なライブラリ:
- libxc
- libcint

libintも使用可能ですが、ビルドに困難を伴う可能性が高いため推奨されていないようです。

## ライブラリのインストール

ISSPのohtakaでは以下のようにMOLGWをビルド／インストールしました。

### libcint

ソースディレクトリでビルド用ディレクトリを作成
```
mkdir build; cd buld
```
以下を実行します。
```
cmake -DCMAKE_INSTALL_PREFIX:PATH=${HOME}/local -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc -DWITH_RANGE_COULOMB=1 -DBUILD_SHARED_LIBS=0 -DPYPZPX=1 ..
```
デフォルトではgcc、g++が使用されるためiccとicpcを使用したい場合には上記のように指定します。

makeの実行
```
make
```
makeで問題がなければ、make installを実行します。
```
make install
```

### libxcのインストール
libxcのインストールに関しては以前GPAWのビルド／インストールの記事に記載したので省略します。

## MOLGWのインストール
- バージョン：3.4 (molgw-3.4)


ソースディレクトリで``config``以下にあるMakefileのインクルードファイルを自分の環境に合わせて適当に選び``my_machine.arch``を以下のように編集します。
（Intel MPIを使用する場合の例）
```
OPENMP=-qopenmp -parallel
PYTHON=python3

# Parallel MPI SCALAPACK compilation
FC=mpiifort

CPPFLAGS=-DHAVE_SCALAPACK -DHAVE_MKL

# maybe use icx instead icpc if using a recent version of Intel OneAPI
CXX=icpc -std=c++11
FCFLAGS= -fpp -O3 -xhost -qopt-matmul
CXXFLAGS= -O3 -xhost

SCALAPACK= -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core

LIBXC_ROOT=${HOME}/local/

LIBCINT=-L${HOME}/local -lcint -lquadmath
```
makeの実行
```
make
```

上記で``-lquadmath``を指定するのが重要です。しばらくうまくいかず困っていたのですが、MOLGWのFAQページに記載がありました。

（OpenMPIを使用する場合の例）
```
OPENMP=-qopenmp -parallel
PYTHON=python3

# Parallel MPI SCALAPACK compilation
FC=mpif90

CPPFLAGS=-DHAVE_SCALAPACK -DHAVE_MKL

# maybe use icx instead icpc if using a recent version of Intel OneAPI
CXX=icpc -std=c++11
FCFLAGS= -fpp -O3 -xhost -qopt-matmul -g -traceback
CXXFLAGS= -O3 -xhost
LDFLAGS=-g -traceback

SCALAPACK= -lmkl_scalapack_lp64 -lmkl_blacs_openmpi_lp64 \
           -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core \
           -liomp5 -pthread -lm

LIBXC_ROOT=${HOME}/local/

LIBCINT=-L${HOME}/local -lcint -lquadmath
```
使用している環境に合わせて、コンパイルと実行のときにOpenMPIの使用を可能にしておく必要があります。
私の場合、以下を実行しています。
```
module purge
```

```
module load oneapi_compiler/2023.0.0 openmpi/4.1.5-oneapi-2023.0.0-classic
```
# 注意
molgwを実行するとき環境変数``OMP_STACKSIZE``を設定していない場合、出力に警告が表示されます。
実際、post-SCF計算を実行するときには適切に設定しておくのが良いようです。
``bash``を使用している場合にはジョブスクリプト内で以下のよう``OMP_STACKSIZE``を設定します。
```
export OMP_STACKSIZE=1G
```
出力ファイルに使用するメモリの見積りが表示されるので、適切に調節すると良いと思います。

# まとめ

MOLGWは物理系の方が開発されたものだからか、使い勝手が良いと感じています。分子系に限られますが、既に色々と計算を行っていて、自分自身はMOLGWを大いに使って楽しんでいます。
[Linux][command] メッセージ送信_wall

# wallコマンド  
~~~terminal
$ wall [ファイル]

or 

$ wall
メッセージ

Ctrl + D (終了)
~~~

| オプション | 由来 | 説明 |
|:--|:--|:--|
| default | write all | - ログイン中のすべてのユーザーにメッセージを一斉送信する。<br>- 標準入力またはファイルを使用 |
| `-n` | no banner | - ユーザー名やホスト名などのヘッダ（バナー）を省略して送信 |
| `-t` | timeout | - ターミナルへの書き込みタイムアウト（秒）を指定 |

# 参考リンク
- [wallコマンドの使い方まとめ【Linuxコマンド集】](https://eng-entrance.com/linux-command-wall)

# Ping-t
- [3315_wall](https://mondai.ping-t.com/question_subjects/31/question_sessions/32569047/progressing_questions/499039912)