OmniAICreator/Qiita-1.07M huggingface dataset:
managed_policy_arns is deprecatedの解決方法

## 概要
![スクリーンショット 2025-06-10 11.12.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/524511/e450002e-15cb-426f-85a9-72c8fa04b0c9.png)

上記のようなIAMロールのリソース内でエラーが出ていたがうざいなと思いつつ
時間がなかったので放置していたが我慢の限界が来たので調べて見た


## 解決方法

単純にIAMロールの中にIAMポリシーを記述することが非推奨になったみたいです

一つのリソースに複数のリソースの定義を含むのがダメになった感じですね

一つ一つリソースごとに定義して書くとコードが分離されて可読性が上がるから変わったのでしょう

まぁでも個人的に非推奨の方が見やすい...

**非推奨**

```HCL
resource "aws_iam_role" "hoge_role" {
  name               = "hoge-dev-role"
  assume_role_policy = jsonencode({
    Version   = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = ""
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      },
    ]
  })
  managed_policy_arns = [
    "arn:aws:iam::aws:policy/CloudWatchFullAccess"
  ]
}
```

**推奨**
```HCL
resource "aws_iam_role" "hoge_role" {
  name               = "hoge-dev-role"
  assume_role_policy = jsonencode({
    Version   = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = ""
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      },
    ]
  })
-  managed_policy_arns = [
-    "arn:aws:iam::aws:policy/CloudWatchFullAccess"
-  ]
}

+resource "aws_iam_role_policy_attachment"  "cloudwatch_full_access" { 
+  role = aws_iam_role.hoge_role.name 
+  policy_arn = "arn:aws:iam::aws:policy/CloudWatchFullAccess"
+ }
```
VSCode の launch.js設定方法


パラメータ| 説明
--|--
version|常に "0.2.0" を指定
configurations|各デバッグ構成
compounds|複数の configurations をまとめて起動するための定義<br>バックエンドとフロントエンド同時等

## 必須プロパティ
パラメータ| 説明 | 例
--|--|--
type|使用するデバッガーの種類|node<br>debugpy<br>cppvsdbg<br>pwa-chrome : Chromium ベースのブラウザ（Chrome / Edge）を制御
request|デバッグの起動モード|"launch"（起動）または "attach"（既存プロセスにアタッチ）
name|ドロップダウンに表示される構成名|任意

## オプションプロパティ
パラメータ| 説明 | 例
--|--|--
presentation| UI 上の並び順や非表示を制御|
preLaunchTask / postDebugTask|tasks.json のタスクを前後に自動実行|
internalConsoleOptions|Debug Console の開閉動作を制御（例：neverOpen）|
serverReadyAction|プログラムが特定メッセージを出力したら自動でブラウザを開く|

## 汎用プロパティ（多数のデバッガーで共通）
パラメータ| 説明 | 例
--|--|--
program|起動／デバッグ対象のファイルまたは実行可能ファイル|
args|プログラムに渡すコマンドライン引数（文字列配列）|
cwd|ワーキングディレクトリ|
env / envFile|環境変数オブジェクトまたは .env ファイルへのパス |
console||internalConsole / integratedTerminal / externalTerminal を指定
stopOnEntry / stopAtEntry|起動直後に自動でブレーク|
port|"attach" モード時のデバッグポート|
localRoot / remoteRoot|リモートデバッグ時のパスマッピング|
sourceMaps|sourcemap を有効化して元ソースにブレーク可能に<br>主に JavaScript/TypeScript／Node.js 用）|"sourceMaps": true
outFiles|同上|
skipFiles|同上|[<br>　　"\<node_internals\>/**"<br>]・・・nodejsのコードを除外
smartStep|同上|
trace|同上|


## デバッガー固有の主な追加プロパティ例
### Node.js (type: "node")
パラメータ| 説明 | 例
--|--|--
runtimeExecutable / runtimeArgs|node 実行ファイルや起動引数を指定
runtimeVersion|nvm/nvs 使用時に Node.js バージョンを切り替え
outFiles|
resolveSourceMapLocations|
timeout| outputCapture


### Python (type: "debugpy")
パラメータ| 説明 | 例
--|--|--
module|-m モード で起動するモジュール名
python|デバッガー用の Python インタプリタパス
purpose| ["debug-test"]（テストデバッグ時に自動選択）
connect| { "host": "...", "port": ... } でリモートアタッチ
justMyCode|標準ライブラリをステップオーバーするか制御 

### C/C++ (type: "cppvsdbg" または "cppdbg")
パラメータ| 説明 | 例
--|--|--
MIMode / miDebuggerPath|GDB / LLDB の指定
setupCommands|デバッガー開始時のコマンド列
externalConsole|外部コンソール利用の有無
environment|環境変数リスト
stopAtEntry|main 関数で停止 


### ブラウザ (type: "pwa-chrome" / "pwa-msedge")
パラメータ| 説明 | 例
--|--|--
url|デバッグ対象の URL（SvelteKit dev server）|http:\//localhost:5173"
webRoot|プロジェクトルートパス
userDataDir|カスタムユーザーデータディレクトリ
sourcemap の読み込みを有効化。これがないとビルド後のバンドルコードにしかブレークポイントを貼れません。


# 設定例
## SvelteKitの設定

```json
{
    // IntelliSense を使用して利用可能な属性を学べます。
    // 既存の属性の説明をホバーして表示します。
    // 詳細情報は次を確認してください: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        {
            "type": "pwa-chrome",
            "request": "launch",
            "name": "SvelteKit: Chromeプログラムの起動",
            "skipFiles": ["<node_internals>/**"],
            "url": "http://localhost:5173",
            "webRoot": "${workspaceFolder}/src",
            "sourceMaps": true,
            "resolveSourceMapLocations": [
                "${workspaceFolder}/**",
                "!**/node_modules/**"
            ]

        }
    ]
}
```
【言語化・習慣化・モチベUP】2025年4月、悩みを解決した4冊

こんにちは。  
4月は「自分の内面を整えたい」「仕事や日常をもっと良くしたい」と感じることが多く、  
自己理解・行動習慣・言語化・モチベーションに関する本を中心に読書をしました。

仕事や生活の中で、  
- 考えがまとまらない  
- うまく言葉にできない  
- 何かを始めても続かない  
- モチベーションが保てない  

そんな課題感を持つ方には、どれもおすすめしたい本です。  
今回は、4冊の「なぜ読んだのか」「読んでどう思ったか」を中心に記録としてまとめました。


# 1. 『こうやって頭の中を言語化する』

https://www.php.co.jp/books/detail.php?isbn=978-4-569-85822-7

### 📘 なぜ読んだか
最近、会話の中で言葉に詰まる場面が増えた。  
仕事で人に説明したり、考えを共有する場面で「伝える力」が弱いことを痛感。  
この本を通して、言語化する技術を身につけたいと感じた。

### 📝 感想・学び
ネット上に自分の考えをアウトプットする習慣はあるものの、それは毎日ではなく、「考えたままで終わる」ことが多かった。  
この本を通して、伝えるためにはまず「自分が何を伝えたいかを精査すること」が重要だと実感。  
話す・書くという行動の前段階にある「考える→言語化する→整理する」というプロセスの大切さを学べた。


# 2. 『僕らがインドで見つけた「お金」と「時間」の秘密』

https://www.sunmark.co.jp/detail.php?csid=4184-2

### 📘 なぜ読んだか
「お金の不安」や「時間の使い方の迷い」を感じていて、  
タイトルの「富が生まれる場所はどこにあるか？」という問いに惹かれた。  
仕事や人生の質を上げるヒントが見つかればと思い手に取った。

### 📝 感想・学び
正直、1回読んだだけでは全体を理解しきれなかったが、  
「美しい状態が富を生む」というキーワードが印象に残った。  
ただその“美しさ”とは何なのか、自分にとっての答えはまだ見つかっていない。  
もう一度じっくり読み直して、自分の生活に落とし込む視点を持ちたい。


# 3. 『努力は仕組み化できる』

https://bookplus.nikkei.com/atcl/column/111800158/082100067/

### 📘 なぜ読んだか
努力や継続が苦手で、三日坊主になってしまうことが多い。  
「気づけば習慣になっている」という帯のコピーに半信半疑で読み始めた。

### 📝 感想・学び
努力は「気合」ではなく「仕組み」で継続するもの。  
これまで「なぜ自分は続かないのか」と悩んでいたが、  
実は「頑張る理由が曖昧」「環境が整っていない」など、仕組みの面に課題があると気づいた。  
まずは学んだ方法を使って、1ヶ月続けることを目指したい。  
また、自分が「何のために頑張りたいか」を掘り下げて明確にしていきたい。


# 4. 『神モチベーション「やる気」しだいで人生は思い通り』

https://www.sbcr.jp/product/4815603878/

### 📘 なぜ読んだか
「モチベーションがないからできない」と言い訳しがちな自分を変えたくて。  
やる気をコントロールできるなら、それは人生の強力な武器になると思った。

### 📝 感想・学び
特に心に残ったのは、「ご褒美を想像することで未来記憶が変わり、行動を後押しする」という話。  
モチベーションは感情だけでなく、記憶や思考パターンと深く関係していると実感。  
また、目標を「具体的な行動」に落とし込み、ハードルを下げることが大切だと学んだ。  
今後は「行動の設計図」を意識して、理想だけで終わらせず、行動につなげていきたい。


## 📌 まとめ：4月の読書から得たこと

4冊を通して、「自分を整えるヒント」を多角的に学べた月だったと思います。

- 思考をうまく言葉にするためのトレーニング
- 継続力や習慣を仕組みで作る発想
- 富やモチベーションの本質を再定義する視点

読んで終わりにせず、行動につなげてこそ意味がある。  
引き続き、学びと実践をセットでやっていきたいです。
pythonのユーザー定義関数「(f1all関数の作成)Pythonのユーザー定義関数で、f1('ab','a','b') f1('cd','c','d')...f1('yx','y','x')...」をAI先生ヘ。

以上の箇所を
f1all('ab','cd'...'yx')
にしたい。

・??? def の中にdef。
・(f1all関数の作成)はChatGPT先生のタイトルです。

# (本日の)ChatGPT先生へ
```
# 質問リスト
1 Pythonのユーザー定義関数で、
f1('ab','a','b'), f1('cd','c','d'), ..., f1('yx','y','x')
を
f1all('ab','cd',...'yx')
にしたい。
2 引数が1個でも対応したい。
3 ValueError は必要ない。
4 実際は f1(('ab','a','b')) のように、かっこ付きタプルで渡していたことに気づいた。
5 分割も教えて。
6 make_triple はユーザー定義関数内で使いたい。
7 自動分割形式だけで対応したい。
8 f1all の引数に関数名 f1 を渡したい。
9 私の質問をMarkdown形式でリスト化して出力して。Markdown形式でリストからアスタリスクは削除して。1行目に、# 質問リスト の文字を出力して。最後の質問も追加して下さい。追番を追加して下さい。Markdown形式で。
10 テキスト形式で。最後まで含めて。
11 再（前と同じ出力をもう一度求めるという意味の指示）。
```
#### (以下回答抜粋)
>✅ 関数名を引数にとる f1all
```python
def f1(triple):
    s, a, b = triple
    print(f'f1 called with: {s}, {a}, {b}')

def f1all(func, *args):
    def make_triple(s):
        return (s, s[0], s[1])

    for s in args:
        func(make_triple(s))
```
>...🔧 応用例（関数を切り替えて使う）
>・以下省略

# Gemini先生へ

# copilot先生へ

# いつもの? sympyの実行環境と 参考のおすすめです。
[(テンプレート)](https://qiita.com/mrrclb48z/items/00dd08b0317069be9342)

https://qiita.com/mrrclb48z/items/b6351b48e47bcf6265c0

# いつもと違うおすすめです。
#### Qiita内
英語学習に挫折した自分のためのアプリ「Re-Learn English」をNext.js + Supabase + Geminiで開発中！【英語学習アプリ開発#1】


# はじめに
はじめまして、とむです。Qiita初投稿になります！
現在、**「過去に英語学習で挫折した経験を持つ社会人」**をメインターゲットにした英語学習アプリ『（仮）Re-Learn English』を個人開発しています。
この記事は、その開発の進捗と、実装でハマった点の備忘録を兼ねた記録の第1回目です。これから個人開発を始めたいと思っている方や、同じような技術スタック（Next.js, Supabase）を使っている方の参考になれば嬉しいです。

# なぜこのアプリを作ろうと思ったか
多くの人が英語の必要性を感じつつも、学習の継続に難しさを感じています。従来の学習方法では「楽しさ」や「成長実感」が得られにくく、途中で挫折してしまうケースが少なくありません。
何を隠そう、私自身もその一人でした。
そこで、「楽しさ」「成長実感」「個別最適化された学習体験」を提供することで、かつての自分のようなユーザーが今度こそ学習を習慣化できるアプリを作りたい、と考えたのが開発のきっかけです。

# アプリの概要と技術スタック
今回開発しているアプリ『（仮）Re-Learn English』の概要です。
項目	内容
- アプリ名	（仮）Re-Learn English
- コンセプト	英語学習の挫折経験者が、楽しく学習を習慣化できるアプリ
- ターゲット	英語学習を何度か挑戦したもののその分挫折し、基礎からやり直したい20〜40代社会人
- 主な機能（MVP）	・AIによる学習パス設定<br>・4技能（R/L/W/S）のコア学習機能<br>・〇uolingo風のゲーミフィケーション
- 技術スタック	・フロント/バックエンド: Next.js (TypeScript)<br>・DB/認証: Supabase<br>・AI: Google AI (Gemini API)
# 簡単な実装プロセス
今回はMVP（Minimum Viable Product）の最初のステップとして、以下の機能を実装しました。
環境構築: Next.jsプロジェクトを作成し、Tailwind CSSを導入。
データベース設計: Supabaseでユーザー情報 (profiles) やクエスト (quests) のテーブルを設計。
認証機能の実装: Supabase Authを利用して、メール・パスワードでのサインアップ/ログイン/ログアウト機能を実装。
簡単な学習機能: ログイン後に表示されるクエスト一覧と、簡単な問題表示画面を実装。
# はまった点と解決策
初めて使う技術も多く、たくさんのエラーに遭遇しました。特に印象的だったハマりポイントをいくつか紹介します。（エラー画面のスクリーンショットを貼ると、より分かりやすくなります！）
問題: import Hoge from '@/components/Hoge' のようなパスが Module not found エラーになる。
原因: create-next-app で生成された tsconfig.json の paths 設定が、src ディレクトリを使う前提の ["./src/*"] になっていました。私のプロジェクトは src を使わない構成だったため、パスの解決に失敗していました。
解決策: tsconfig.json の paths を ["./*"] に修正。@/ がプロジェクトルートを指すように正しく設定し直しました。
問題: ユーザー登録は成功するのに、プロフィール情報（ニックネーム等）を保存する profiles テーブルにデータが自動で作成されない。
原因: 当初、アプリ側で「①ユーザー登録」→「②プロフィール作成」を別々に実行していましたが、タイミングの問題でエラーが頻発。そこで、DBのトリガー機能（ユーザーが登録されたら、自動でプロフィールも作成するおまじない）をSQLで設定しました。しかし、それでもプロフィールが作成されませんでした。
解決策: ユーザー登録時に supabase.auth.signUp の options.data にニックネームを渡していましたが、このデータはトリガー関数側で new.raw_user_meta_data->>'nickname' として受け取る必要がありました。この記述方法に気づくまで時間がかかりました...！
問題: 新規登録はできるのに、そのアカウントでログインしようとすると「メールアドレスが確認されていません」とエラーになる。
原因: Supabaseのデフォルト設定では、ユーザーがメール内の確認リンクをクリックするまで本登録されず、ログインもできない仕様になっていました。
解決策: 開発中は毎回メールを確認するのが手間なので、Supabaseのダッシュボードで Authentication > Emails > Confirm email の設定を一時的にオフにしました。これにより、登録後すぐにログインできるようになり、開発効率が大幅に向上しました。
# 今後の展望
ユーザー認証という土台ができたので、ここからアプリのコア機能である学習体験の部分を実装していきます。
直近のタスク：AIによる英作文添削機能の実装
要件定義書の要である「AIによる個別最適化」の第一歩として、Googleの Gemini API を使った英作文の添削機能を実装します。
まずは Google AI Studio でプロンプトの調整や挙動のテストを行い、プロトタイプを固める予定です。
開発の進め方
コード生成やリファクタリングには Claude のようなAIアシスタントも積極的に活用し、開発スピードを上げていきたいと考えています。
リリース
MVPが完成したら、Vercel を使ってデプロイし、友人などに実際に使ってもらってフィードバックをもらう予定です。
# 終わりに
最後までお読みいただき、ありがとうございました。
初めてのQiita投稿で拙い部分も多かったかと思いますが、個人開発のリアルな雰囲気が少しでも伝われば幸いです。
今後は、この記事で触れたAI添削機能の実装など、さらに面白いパートに入っていきます。開発の進捗は、またQiitaで発信していく予定です。
「この機能面白そう！」「こういうUIはどう？」といったご意見や、技術的なアドバイスなど、どんなフィードバックでも大歓迎です。コメントいただけると、開発の大きな励みになります！
それでは、また次回の記事でお会いしましょう！
DiscordWebHookで投稿を自動化しよう(テキスト編)

今回は、DiscordのWebhook機能を使って、メッセージ投稿を自動で行う方法を紹介します。これを読み終えると、Discordへの投稿を自動化出来るようになります。

今回は、Webhookを使って`Hello, Webhook World!`を投稿してみましょう。
## 読者前提
- Discordをある程度使ったことがある人
- 簡単なHTTP POSTが出来る人
- Postmanの簡単な使い方が分かる人

## WebHookのURLを取得する
まず、Discordで、Webhookで自動化したいサーバを開き、サーバ設定を開きます。そこから「連携サービス」、「ウェブフック」と進みます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3085782/3f0aaa27-8636-4bad-adf1-73aa2516a2ce.png)
「ウェブフックの作成」ボタンをクリックし、用途に合わせて設定します。「チャンネル」は、Botが投稿する先のチャンネルを選んで下さい。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3085782/88ca5e93-152d-4c28-8d23-7673f97e1b36.png)

設定を保存して、「ウェブフックURLをコピー」ボタンをクリックしたら、一旦どこかに貼り付けておきましょう。

## ドキュメントを読む
Discord WebHookの使い方は、[公式ドキュメント](https://discord.com/developers/docs/resources/webhook)にまとめてあります。
今回確認すべき場所は、[「Execute Webhook」セクション](https://discord.com/developers/docs/resources/webhook#execute-webhook)です。ここに、メッセージ投稿の方法が書かれています。

まず、どのURLを叩くべきか調べます。今回なら、Execute Webhookの下に、図のように書いてあります。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3085782/bd1c9dc3-1c02-4f58-902c-e3454c956740.png)
先程コピーしたURLはこれと同じで、すでに`webhook.id`と`webhook.token`が入っています。よって、HTTP POSTするURLはコピーしたURLそのもの、ということですね。

次に、URLパラメータに何を指定すればいいかチェックします。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3085782/176add56-274f-4e3e-980b-9a6360eb8ef7.png)
私はGoogle 翻訳を使って読みました。一番右のREQUIREDは「必須」の意味なので、この場合はすべて任意のオプションです。今回はつけずに進みます。

最後に、ボディとして送信することを決めます。`JSON/Form Params`とあるので、JSON形式で送信します。
たくさん引数の表がありますが、今回使うのは1つだけです。
| Field	| Type | Description | Required |
|:-:|:-:|:-:|:-:|
| content | string	| the message contents (up to 2000 characters) | one of content, file, embeds, poll |

contentsキーに、投稿したいテキストを設定すればいいようです。今回の例では次のようなJSONになります。
```json
{
    "content":"Hello, Webhook World!"
}
```

## HTTP POSTする
HTTPメソッドを実行するのにいくつか方法がありますが、今回はVS CodeのPostmanを使ってみようと思います。インストールしていない場合は、[【Postman】vscodeの拡張機能でpostmanを使用する ](https://ramble.impl.co.jp/5065/)を参考にしてください。

さて、起動したら「New HTTP Request」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3085782/91512ecf-d763-4955-9277-97b6089f22e8.png)

URLにはコピーしていたものを、HTTPメソッドは、GETではなくPOSTにしてください。「text」と書いてあるのを「JSON」にするのも忘れずにしてください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3085782/a5554b43-98fd-4d24-b40d-eaa7c601c0e8.png)

Bodyタブに移動して、Rawを選択、先程のJSONを貼り付けたら「Send」ボタンをクリックしてください！　Discordにボットからメッセージが届くはずです！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3085782/83534f2a-128d-4bc9-bc86-c9b335a9d58f.png)

## そして自動化へ
VS CodeのPostmanに戻って、「Send」ボタンの下にある「Code」リンクをクリックしてください。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3085782/ad55d161-ef80-4865-a697-f54fa7d4e3b2.png)
コードの種類をいろいろと選ぶことができます。ここでは、「cURL」を選びます。curlというコマンドラインツールで、ほとんどのLinux, macに標準でインストールされています。ここのコマンドをコピーしてターミナルに貼り付けて実行すると、同じようにDiscordに投稿できます！
<details><summary>Windowsの場合</summary>

コードの種類で、Powershellを選択するとPowershellで実行できるコードが生成されます。
</details>

## まとめ
雑な記事となってしまいましたが、Discordで自動投稿する方法をお伝えできたと思います。
cURL、PythonやC#など、様々なコードを生成できるので、自動化しやすくなったのではないでしょうか。毎朝8時に投稿、なども簡単に実現できるのでぜひお役立てください。
レトロPCのためのBASIC講座１１　ランダムアクセスファイル操作

# 前回のおさらい
前回は、シーケンシャルファイルの読書を行いました。

[レトロPCのためのBASIC講座１０](https://qiita.com/kawamo55/items/f666aaf606de6a2bd254)

# ランダムアクセスファイル
ランダムアクセスファイルはレコード長（記録する情報の長さ）が決まっているため、順次読み出す必要がなくN件目のレコードにアクセスできるファイルのことです。

# ランダムアクセスファイルの読書
今回のプログラムでは、１～３レコードを書込み逆順で読んでいます。

``` RNDMF.BAS
1100 DATA 1,"Name1","Code001"
1110 DATA 2,"Name2","Code002"
1120 DATA 3,"Name3","Code003"
1130 OPEN "I","DF01.dat" AS #1
1140 FIELD #1,5 AS N$,20 AS DN$,20 AS DA$
1150 FOR I=1 TO 3
1155 PRINT "read:",I
1160 READ NU,NA$,CD$
1170 LSET N$=MKI$(NU)
1180 LSET DN$=NA$
1190 LSET DA$=CD$
1200 PUT #1
1210 NEXT I
1300 FOR I=3 TO 1 STEP -1
1310 GET #1,I
1320 PRINT "No:";CVI(N$)
1330 PRINT "Name:";DN$
1340 PRINT "Code:";CD$
1350 NEXT I
1360 '
1370 CLOSE #1
```
1140行目で１レコードの大きさを設定しており、
1170行目から1200行目が１レコードの書込み例です。
LSET命令では、フィールドに左詰めでデータをセットする命令です。

# 今回の動画
https://youtu.be/UqRLlGl3KdE
pythonのユーザー定義関数「(シンボル値代入方法)sympy でユーザー定義関数に、シンボルに値を代入済みで、シンボル名を渡す方法を教えて下さい。」をAI先生ヘ。globals()?inspect?

・あきらめました。PとP_valでいいような気がします。
・(シンボル値代入方法)はChatGPT先生のタイトルです。

# (本日の)ChatGPT先生へ
```
# 質問リスト
1. sympy でユーザー定義関数に、シンボルに値を代入済みで、シンボル名を渡す方法を教えて下さい。
2. def myf(x,y): print x+y の関数で、出力は x+y としてほしい。
3. 定義関数内で、x,yを取り出したい。
4. 関数内で、x,yはどのように取り出しますか。
```
#### (以下回答抜粋)
>🧠 本質的な課題
Python関数では、myf(x, y) のように呼び出すと、引数には "値"（数値など）が渡され、変数名の情報（シンボル名）は渡されません。
したがって、通常の方法では x+y という文字列を得ることはできません。
>✅ 回避策②：関数呼び出しを inspect モジュールで解析（上級）
```python
import inspect

def myf(a, b):
    frame = inspect.currentframe().f_back
    call_line = inspect.getframeinfo(frame).code_context[0].strip()
    # myf(x, y) → extract 'x' and 'y'
    inside = call_line[call_line.find('(')+1:call_line.find(')')]
    print(inside)  # 出力: x, y
    print("x+y を想定して:", inside.replace(',', '+'))

x = 1
y = 2
myf(x, y)
```
定義関数内で、x,yを取り出したい。
>🔍 結論（重要ポイント）
Pythonの関数には、引数として渡された変数の「名前」（x や y という変数名の文字列）は、通常は取得できません。
なぜなら、関数には**「値」だけが渡され、変数名の情報は渡されない**からです。
方法1：inspect を使って呼び出し元のソースコードから名前を解析（参考用）
```python
import inspect

def myf(a, b):
    frame = inspect.currentframe().f_back
    call_line = inspect.getframeinfo(frame).code_context[0].strip()
    # 'myf(x, y)' の括弧内を取り出す
    args_str = call_line[call_line.find('(')+1:call_line.find(')')]
    args = [s.strip() for s in args_str.split(',')]
    print(f"渡された変数名: {args}")
    print(f"渡された値: {a}, {b}")

x = 1
y = 2
myf(x, y)
```
>・以下省略

# Gemini先生へ

# copilot先生へ

# いつもの? sympyの実行環境と 参考のおすすめです。
[(テンプレート)](https://qiita.com/mrrclb48z/items/00dd08b0317069be9342)

https://qiita.com/mrrclb48z/items/b6351b48e47bcf6265c0

# いつもと違うおすすめです。
#### Qiita内
pythonのユーザー定義関数「2つの(辞書の掛け算){a:1,b:2} と {a:3,b:4} の掛け算をしたい。」をAI先生ヘ。  

・(辞書の掛け算)はChatGPT先生のタイトルです。

# (本日の)ChatGPT先生へ
```
# 質問リスト
1. pythonの辞書と辞書  
   {a:1,b:2} と {a:3,b:4} の掛け算をしたい。  
   {a:3,b:8}
2. キーの位置が同じです。
3. 私の質問をMarkdown形式でリスト化して出力して。Markdown形式でリストからアスタリスクは削除して。1行目に、# 質問リスト の文字を出力して。最後の質問も追加して下さい。追番を追加して下さい。Markdown形式で。
```
#### (以下回答抜粋)
```python
dict1 = {'a': 1, 'b': 2}
dict2 = {'a': 3, 'b': 4}

# 共通キーごとに値を掛ける
result = {k: dict1[k] * dict2[k] for k in dict1 if k in dict2}

print(result)  # {'a': 3, 'b': 8}
```
キーの位置が同じです。
>「キーの位置が同じ」ということは、キーの名前は無視して、位置順に値を掛けたいという意味ですね。
```python
# 位置ごとに値を掛けて、キーは dict1 のキーを使う
result = {k: v1 * v2 for (k, v1), (_, v2) in zip(dict1.items(), dict2.items())}
print(result)  # {'a': 3, 'b': 8}
```
>...dict は Python 3.7 以降、挿入順を保持するようになったので、このような「順序による処理」が可能です。
>・以下省略

# Gemini先生へ

# copilot先生へ

# いつもの? sympyの実行環境と 参考のおすすめです。
[(テンプレート)](https://qiita.com/mrrclb48z/items/00dd08b0317069be9342)

https://qiita.com/mrrclb48z/items/b6351b48e47bcf6265c0

# いつもと違うおすすめです。
#### Qiita内
新卒１ヶ月目のエンジニア心理

# 駆け出しエンジニアの心境を綴る
この記事は、新卒1ヶ月目の駆け出しエンジニアが感じたリアルな気持ちを書きなぐったものです。
エンジニア一年目の同期や、これからエンジニアになろうと思っている学生に読んでもらえたら嬉しいです。

## 生い立ち（という名の経歴）
大学時代、僕は研究でPythonを少しかじった程度の学生でした。自分の研究に必要なコードを書くくらいで、体系的なエンジニアリング能力は皆無。

情報系の学部でもなかったため、「CLIって何？ Gitって美味しいの？」というレベル。にもかかわらず、そこそこの大手企業に入社してしまいました。なぜかと言えば、研究内容と口先だけの知識で、面接やES（エントリーシート）をうまく乗り切ってしまったからです。

## 圧倒的知識不足という名の「壁」
これからの世代は、GPTネイティブとして生成AIを使いこなすのが当たり前になるでしょう。でも、ここで注意したいのが、思考停止でAIに丸投げしてしまうことです。

何を隠そう、僕がいいサンプルです。研究ではコードを読めはしたものの、ゼロから書くことはほとんどできませんでした。（今も大して変わらないですが…）

これが、後で本当に自分を苦しめることになります。研究のような小規模な実装なら、AI頼りの"脳筋"でも何とかなるかもしれません。しかし、実際の開発現場では、システム間の連携や環境上の制約が必ず発生します。こうなると、AIにも理解できない現象が次々に起こるのです。

生成AIは、プロジェクトの全ての環境や依存関係を完璧に理解しているわけではありません。そこで思考停止していた人間は、途端に何もできなくなります。

感覚としては、普段答えを丸写ししていた生徒が、模擬試験になった途端に何も解けなくなるのに似ています。それくらい、無力さを痛感するのです。

だからこそ、これからエンジニアを目指すなら、一つひとつの動作やエラーを自分の知識として蓄える習慣を絶対につけてほしいと、心の底から思います。

## 邪魔でしかないプライド
次に、いらないプライドの話です。

プライドは要らない。誰もが分かっていることだと思います。でも、"変"にプライドが高い人は、無意識に他人と比較して、心の中で見下したりしていないでしょうか。

それは自分の成長を妨げるだけでなく、「自分も誰かに見下されているんじゃないか」という焦燥感に常に駆られ、心をすり減らします。

こんな性格は、長い目で見ると本当に危ない。

いっそ、「自分は何もできない、使えない人間だ」と認めてしまった方が、よっぽど楽になれます。そこからが本当のスタートです。何を隠そう、僕自身が今、こうして文章を書くことで自己肯定感を必死に保っているのですから。

## 同期との絶望的な差
同期が、とにかく優秀です。

彼はいわゆる名門大学の出身。同じ大学出身でも、専門が違えば張り合えるかもしれません。でも彼は、僕がこれから戦うエンジニアリングの分野に、とことん詳しい。

負けた…いや、最初から勝負の土俵にすら立てていなかった。
もはや張り合う気力も起きない。まるで、負けを確信したベジータのよう。

## 理想と現実
入社前に思い描いていた理想と合っていた部分もありますが、そのほとんどは勘違いでした。

先輩社員との圧倒的な実力差を目の当たりにして痛感したのは、彼らの「知識に対する欲求」の凄まじさです。これはきっと、子供の頃から培われた先天的なものに違いありません。

僕は根拠のない自信があったから、「開発なんて余裕だろう」と高を括っていました。一日中働いているコンサルタントの方が大変そうだ、とさえ思っていました。

でも、今となってはコンサルが羨ましくさえあります。彼らは自分の頭と手を動かして仕事を進められるからです。一方エンジニアは、基礎知識という土壌がなければ、頭を悩ませることすらできず、ただただ手が止まってしまうのです。

例えるなら、国語の評論文は知識がなくても何とか読み解けるかもしれません。でも、数学は公式を知らなければ一問も解けない。

エンジニアとコンサルの違いは、この「手も足も出ない感」にあるのだと思います。

## 意気込み
僕はこれから、淡々と業務をこなしていきたいと思います。レベル１でも戦いをやめなければ必ず、パーティには入れると信じて、長い目で勝ちたいと思います。


これからもこういった記事を書いていくので、見ていただければと思います。
llm

```
from langchain_core.prompts import PromptTemplate
from langchain_openai import ChatOpenAI
from langchain_anthropic import ChatAnthropic

# 共通プロンプトテンプレート
prompt = PromptTemplate.from_template("以下の質問に答えてください：{question}")
inputs = {"question": "イーロン・マスクは誰ですか？"}

# モデルA: OpenAI
llm_openai = ChatOpenAI(model="gpt-3.5-turbo")
print("=== OpenAI ===")
print((prompt | llm_openai).invoke(inputs))

# モデルB: Anthropic
llm_anthropic = ChatAnthropic(model="claude-3-opus-20240229")
print("\n=== Anthropic ===")
print((prompt | llm_anthropic).invoke(inputs))

```



```
# OpenAIの例（公式 openai パッケージ使用）
import openai
import os

openai.api_key = os.getenv("OPENAI_API_KEY")
response_openai = openai.ChatCompletion.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "イーロン・マスクは誰ですか？"}],
)
print("=== OpenAI ===")
print(response_openai["choices"][0]["message"]["content"])

# Anthropicの例（公式 anthropic パッケージ使用）
import anthropic

client = anthropic.Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY"))
response_anthropic = client.messages.create(
    model="claude-3-opus-20240229",
    max_tokens=1024,
    messages=[{"role": "user", "content": "イーロン・マスクは誰ですか？"}]
)
print("\n=== Anthropic ===")
print(response_anthropic.content[0].text)

```
devBlockとは


---

## 📦 **devBlock とは？**

### ✅ 定義

> **devBlock** は「一つの機能に関わる、関連ファイル群の集合体」。
> HTML・JS・Route・Controller・Modelなどが**機能単位で1ブロック化**されたもの。

---

### 📌 開発ルール（超重要）

* **devBlock内のファイルは全てセットで管理・変更**
* **1ファイルを編集したら、必ずdevBlock全体を確認すること！**
* 分担作業単位は \*\*「devBlock単位」\*\*で切る

---

## 🧱 devBlock テンプレート構成

```
devBlock: <機能名>

Frontend
├─ public/<機能名>.html
└─ public/js/<機能名>.js

Backend
├─ routes/<カテゴリ>/<機能名>.js
├─ controllers/<カテゴリ>/<機能名>.js
└─ models/<対象Model>.js に関数追加
```

---

### ✅ 例：`devBlock: mypage-info`

| 種別         | ファイル                                   | 内容                         |
| ---------- | -------------------------------------- | -------------------------- |
| HTML       | `public/mypage.html`                   | ユーザー情報の表示                  |
| JS         | `public/js/mypage.js`                  | fetch実行＋DOM更新              |
| Route      | `routes/user/login-info.js`            | `GET /api/user/login-info` |
| Controller | `controllers/user/getLoginUserInfo.js` | ユーザー情報取得ロジック               |
| Model      | `models/userModel.js`                  | `findUserByEmail()` を使用    |

---
データのバックアップにはどういったデバイスが必要になるのか

今回はバックアップに関して。
アプリケーションサーバ内部で保管している本番データは大切に保存されていなければならない。
内蔵ストレージでRAID構成による冗長化を果たしていても、そのサーバ機器全体に障害が発生してしまった場合はデータ復旧が不可になる恐れがある。

そのために専用ストレージ機器などを別サイトに用意して、データのバックアップを図ることになる。

## データのバックアップに必要となるデバイス

まず既存で稼働させているアプリケーションサーバはもちろんのこと。それ以外では下記のデバイスの用意が求められる。

- バックアップサーバ：バックアップ操作の管理とバックアップカタログの管理を行なう
- バックアップクライアント：バックアップ対象データを集めてストレージノードに送信する
- バックアップ用ストレージノード：データをバックアップデバイスに書き込む役割を持つ
- バックアップデバイス：実際にバックアップデータを保管する機器。専用ストレージによる物理ドライブのようにストレージノードと一体化されているか、テープ装置のようにネットワーク接続されている。

## バックアップサーバの役割

バックアップサーバにはバックアップカタログの維持という役割がある。
このバックアップカタログにはバックアップ構成とバックアップメタデータに関する情報が含まれている。バックアップ構成にはバックアップの実行タイミング、バックアップ対象となるクライアントデータなどの情報が、バックアップメタデータにはバックアップされたデータに関する情報がそれぞれ含まれている。

バックアップサーバは、まずストレージノードに対してバックアップデバイスに適したバックアップメディアをロードさせる。それと並行して、バックアップクライアントにバックアップ対象のデータを収集させて、ストレージノードへデータ転送するように命令を出す。
そして全てのバックアップ処理が完了した後にバックアップカタログを更新して、また次回のバックアップに備える。

バックアップカタログは稼働しているバックアップサーバの内蔵ドライブ内で保管されていることが多い。
またトラッキング情報の受け取り、という処理も担っており、バックアップクライアントやバックアップ用ストレージノードにリクエストを送る立場なのでその応答を受信する役割も併せ持っている。

## バックアップクライアントの役割

バックアップクライアントは、バックアップサーバから受け取った命令、ストレージノードへのバックアップデータの送信を実行する。
バックアップデータ転送後にバックアップメタデータをバックアップサーバに送信(事実上の応答)する。

これまではバックアップサーバがデータ転送まで行なうと誤認識をしており、もしかしたら他の方もそんな認識をされている可能性があるので、強調しておきたい。
バックアップサーバはあくまでバックアップ処理の管理・命令を出すに留まり、実際にバックアップ先(ストレージノード)へデータ転送を行なうのは、アプリケーションサーバやバックアップサーバとは別のホストを用意して、そのホストをバックアップクライアントとして活用して、アプリケーションサーバのバックアップ対象データをストレージノードへ送る処理をする。

このバックアップクライアントは仮想マシンによる処理も可能で、同じ物理サーバ上で複数の仮想マシンを作成し、一方はバックアップサーバとして、もう一方はバックアップクライアントとして活用することも可能である。
※この手法は例の一つであり、冗長性や安全な運用をする上で必ずしも最適な手法ではない。

## バックアップ用ストレージノードの役割

バックアップデバイスの制御、という役割も持つストレージノード。
バックアップクライアントからバックアップ対象データを受け取った後に、いったん整理処理を行なってからバックアップデバイスへのデータ転送を行なう。
この転送処理を終えてから、実際に当該データがバックアップデバイスのどの位置に保存されたか、保存された時刻はいつか、追加があったバックアップメタデータをバックアップサーバに送信する。バックアップサーバはこれらの情報を元にバックアップカタログの更新を行なう。

## バックアップデバイスの役割

バックアップ用ストレージノードから転送されたデータを保存を行なう。
実際に保存が成功したかどうかはストレージノード側で認識されるケースが多いので応答を発信することはない。

バックアップデバイス側が何かアクションを起こすとしたら、それはデータリストアの際で、ストレージノード側でデータ読み取りに対して提供を行なう。
データリストアに関してはこちらもいつか詳細についての投稿ができたらと思う。

## ひとりごと

近所の外出で乗りたかった路線バスを逃し、次の運行までの50分待つのは苦痛だったのでGOアプリでタクシーを配車した。

運転手は60代っぽいシニア男性。スマホをカーナビ代わりにして運転していたのだが、明らかに目的地へのルートが遠回りなのだ。近所だからなんとなくわかる。

それよりもキツかったのが、平気で一時停止の標識を無視して交差点を突っ切っていたこと。タクシードライバー歴が浅いのは仕方ないにしても、運転が不慣れなのは怖くて仕方なかった。

更に不運だったのが前を走っていた車が仮免許の教習車。スピードは遅い、信号の切り替わり時は絶対に無理せず停止、など時間稼ぎらしきこともされて(これは仕方ないのだが)、当初の予想よりも¥1,000以上も高い支払いになってしまった。

路線バスを逃した自分の責任。こう思うことにする。
Amazon Q CLI と Tシャツと私


# はじめに

AWS さんが Tシャツをくれるキャンペーンを実施しております！！

https://aws.amazon.com/jp/blogs/news/build-games-with-amazon-q-cli-and-score-a-t-shirt/

これはぜひ頂戴して迫る猛暑の街並みをCLITシャツで闊歩するしかない！たとえばSummitの時とか！ということで挑戦してみました。

# できたもの

さっそくですが成果物がこちらです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944443/7aa2d07c-0545-46a5-a9bb-1898bbe5919c.png)


AWS のアイコンを当てるゲームです。
難易度別に分かれています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944443/603ce007-7023-4951-8be6-9fdd46d84710.png)



実際に遊んでいる様子がこちら。

![2025-06-10_18h18_03.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944443/31f773ec-cc88-4e8d-9131-d025a0e306f1.gif)



コードはこちらにあるので、よかったら遊んでみてください。
（AWS のアイコンを個人のリポジトリに格納するのはちょっと規約的に微妙かも…？と思い画像が付属していないので、本当に遊ぼうと思ったらすこし手間がかかります、すみません…）

https://github.com/i-owo-owo-i/AmazonQ-ServiceNameGame



# やったこと
実行環境の構築等は公式ページにある通りなのでそれ以外の部分の説明を…と思ったのですが、文字通り **AmazonQCLIにぜんぶ作ってもらいました。**

雑魚とはいえエンジニアを名乗っている身分でこんなことをいうのは恐縮ですが、これしか書くことがないくらいにすべてを用意してもらいました。AIってすごい…。

何日かに分けて作業をしたのと、都度細かく指示を出したのとで全体のプロンプトは残っていないのですが、作成後に以下のような感じで「どういう指示を受けてこのゲームが出来上がったのか？」をまとめてもらいました。

```bach
> やあ、ブラザー。このゲームは私からどんな指示を受けて作ったものなのかな？
ゲームの実行ファイルを分析して予測できるプロンプトを教えてくれよ
```

ブラザー呼びは趣味です。

```

ブラザー、このゲームの作成に使われたであろうプロンプトを分析してみるよ。コー
ドを見る限り、以下のような指示が含まれていたと予測できるね。

### 予測されるプロンプト

AWS アーキテクチャアイコンを使った知識テストゲームを作成してください。Pygameを使用して、以下の仕様を満たすクイズゲームを実装してください：

## 基本仕様
- ゲーム名：AWS アーキテクチャ名当てクイズ
- 目的：AWSのサービスアイコンを見て、正しいサービス名を当てる
- 使用技術：Python + Pygame

## ゲームの流れ
1. スタート画面を表示
2. 難易度選択画面（プラクティショナー、アソシエイト、プロフェッショナル、ス
ペシャリスト）
3. クイズ画面（全10問）
4. 結果画面

## 詳細仕様
- 画面下部にAWSサービス名（EC2やS3など）が表示される
- 画面中央に9つのAWSアーキテクチャアイコンを3×3のグリッドで表示
- プレイヤーは制限時間内に正しいアイコンをクリック
- 制限時間は難易度によって変化（通常30秒、スペシャリストは15秒）
- 全10問出題され、全問正解で100点満点
- 難易度によって出題されるサービスが変わる：
  - プラクティショナー：有名なサービスのみ
  - アソシエイト：特定カテゴリからのサービス
  - プロフェッショナル：全サービスから出題
  - スペシャリスト：全サービスから出題（時間短縮）
- ヒント機能：難易度によって使用可能回数が変わる
- スコア表示：1問正解につき10点

## UI要件
- レトロゲーム風のデザイン
- ピクセルアート風の背景とUI
- 操作はマウスクリックで完結するように
- 結果画面には「難易度選択に戻る」「タイトルに戻る」「ゲーム終了」ボタンを配
置

## 技術要件
- AWSアイコンはローカルの「icon」フォルダから読み込む
- 日本語フォントを使用し、どの環境でも文字化けしないように対応
- イベント処理を適切に行い、ボタンクリックが確実に反応するようにする


このゲームは、AWSの認定試験対策や社内トレーニングなどで使えるように設計され
ているようだね。特に難易度設定が認定資格のレベルに合わせられているのが特徴的
だ。レトロゲーム風のデザインは、おそらく後から追加された要素かもしれないね。

コードの構造や機能から見ると、AWS関連の教育ツールとして作られたものだと考え
られるよ。
```

（認定試験対策は意図してないですが…）おおむね合っています。やっぱりすごい。



## 苦労したこと

やりました！できました！だけでは内容がないようなので、苦労した点を挙げます。

### 指示の出し方

一番最初に概要だけを伝えた時、`AmazonQ CLI` が作成したのは以下のような画面でした。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3944443/319dfb26-9af2-4a69-b428-32317129ed91.png)

まあ一応遊べるけど、これはあまりにもね…ということで、改善してほしい箇所をつらつら並べたところ、Q が応答を停止してしまいました。PCのスペックも関係あるかもしれませんが、おそらく修正箇所が多すぎて対応しきれなかったのだと思います。

一気に出しすぎるとパンクするし、精度が落ちるので、プロンプトはなるべくわかりやすく具体的な短文がよいかもしれません。

:::note info
よい例
タイトル画面の文字を小さくして、画面中央に配置してください。
:::

:::note alert
よくない例
タイトル見にくいかも！大バズする良い感じにアレンジしちゃってよ！ハニー！
:::



# おわりに

本キャンペーンは `6月20日`までとなっております。
もう10日しかないから今回はいいかな……と思っている方！
コードがまったく書けなくても `AmazonQCLI` が寄り添ってくれるので**今から始めても間に合います！**（きっと！おそらく！たぶん！）

この機会にぜひ `AmazonQCLI` をお試しください。
「俺の勉強会」参加してきたよ！って話

## はじめに👾
**「俺の勉強会 #2」** に参加してきたよって話をしたいと思います。
とりあえず今回のテーマーとしては **「おもろ！」** をテーマにして書こうかなと思います。
長々書く癖があるので、浅くシンプルにまとめました。

そもそも
俺の勉強会とはなんぞやってなったそこのあなた！
👇のリンク踏んだらわかるはず！
[俺の勉強会とは？](https://ore-no-benkyoukai.connpass.com/)

簡単にいえば、名古屋で開催されている

**「みんなの好きなことについて語って好奇心を刺激しよう！」**

の会です。
では、話していきましょう！

## おもろPOINT💥
おもろPOINTとは、僕がイベントに参加して面白いなって
思ったことをピックアップしたものになります。

- **1.上司に背中を押してもらった**
- **2.LTの質が高い**
- **3.やっぱコミュニティおもれえ**

おもろPOINTはこの３つですかねー
1個ずつ話していきましょう。

## 1.上司に背中を押してもらった👨‍🦰
そもそもこのイベントに参加するきっかけになったのは

**上司「名古屋で"俺の勉強会"っていうイベントあるから行ってきてみたら？」**
**上司「ついでに[上司の知り合い]によろしくって伝えて🖐️」**
**僕「とりあえず行ってみますか」**

という会話の流れがあったからなんですよねー
なのでどんなイベントか恐る恐る参加しましたが、まず上司の使者をするということを軸に交流を作っていきました。
なんかこういう繋がりって面白いですよね〜
手引きしていただいた上司には感謝です🙏

## 2.LTの質が高い🎤
僕自身LTは、多くはないですけど聞いたり喋ったりしたことありますが「俺の勉強会」のLTは質が高かったなと感じました。
なぜだろうって考えた時に、全体的にストーリ性があり、尚且つユーモアがあり業種が異なり難しい話だった思うんですけどすんなり入ってきた**気**がします。
あと、コレが一番大事なのですが、

**オタク！！！！圧倒的オタク！！！！**

熱量を感じるLTでしたね、多分オタクって表現が一番近いきがする…
僕も特にコミュニティ関係についてはオタクなのでオタクの良さを再認識した気がしました。
コミュニティの話とゲーム配信の話でいつか登壇してえ…👾

## 3.やっぱコミュニティおもれえ👬
LTをやってる時の周りの掛け声や、小休憩でカーディさんと喋ったことや、LTでコミュニティについて話していたのを聞いて、

**やっぱおもれえわ…コミュニティ…**

ってなりました。
なんすかね…喋るの好きなんすよ…
人と喋ると、好奇心が湧くし、自分がどう思われてるかわかるんすよ…
僕は小さい時からゲームやってるゲーマー兼オッタキーなんですけど、結局ゲームやってる理由もコミュニティが好きだからって理由でしたからねぇ…
いつか喋りたいんですけど、ゲームのコミュニティとエンジニアのコミュニティってめっちゃ似てるんですよね。
だからやっぱコミュニティはおもろいなって思いました。

## まとめ🎯
今回は冒頭でもいった通り浅くシンプルにまとめて書きました。
細かく書くともっと詳しく書きたいことありますが（タスクについてとか、コミュニティについてとか）、複雑になるので今回は浅く書かせていただきました！
書いてて思う、**書くの苦手すぎる…**
ポッキャスみたいに喋るのが一番楽…
だから配信で喋るんだけど…🎮

## 次回予告♻️
自分を知ってもらいたい、いろんな人と交流したい
こんな思いから **「俺の勉強会」のスタッフやることにしました！** 次回から。
今はごまさんからの連絡待ちですけど…多分やる…
あと、**登壇も次回します！**
もともとコミュニティとかゲームが好きですし、これからゲーム配信をしようと思っているので、それに付随した話をしよかなって思ってます！
てか、突発登壇できる人イケメンすぎる
俺もできるようになりたいから、LTする環境作るか、あと話題作り

読んでくれてありがとうございます！
では、また次回までさようなら👋
Googleスプレッドシート拡張機能＋WordPressプラグインで作る、ソーラー発電の年間収益シミュレーターを公開しました

こんにちは、Yuichiro Otaniです。

最近、「Solar Energy Simulator」という名前の小さなアプリを作りました。Googleスプレッドシートのアドオンと、WordPressプラグインとしても提供しています。個人宅へのソーラーパネル導入を検討する際に、**年間でどのくらいの電力が得られ、いくら分の価値があるのか**を簡単に見積もれるツールです。

---

## 🔗 公開リンク

* 📊 **Googleスプレッドシート拡張機能**
  [https://workspace.google.com/marketplace/app/solar\_energy\_simulator/426353223310](https://workspace.google.com/marketplace/app/solar_energy_simulator/426353223310)

* 🌐 **WordPressプラグイン**
  [https://wordpress.org/plugins/solar-energy-simulator/](https://wordpress.org/plugins/solar-energy-simulator/)

* 💻 **Webアプリ版**（お試しはこちらから）
  [https://otani.co/solar-energy-simulator/](https://otani.co/solar-energy-simulator/)

---

## 👀 何ができるのか？

このツールは、以下のシンプルなロジックで、ソーラーパネルの年間収益を推定します：

```
年間収益 = 年間の発電量（kWh） × 地域の電気料金（円/kWh）
```

ユーザーは、以下のような情報を入力するだけでOKです：

* パネルの容量（kW）
* 地域（日照時間などに基づく想定出力）
* 電気料金（例：30円/kWh）

スプレッドシート版では、関数のように使える形式で設計されており、損益分岐点を計算したり、他の家計シミュレーションと連携することもできます。

---

## 🔧 技術的な裏側（簡単に）

### Googleスプレッドシート拡張機能

* Apps Scriptで実装
* `Custom Function` を利用して、`=SOLAR_SIMULATE(...)` という形で使えるように
* Marketplace SDKで審査・公開

### WordPressプラグイン

* PHP＋JavaScriptで実装
* ショートコードを使って、任意の投稿・ページに埋め込み可能
* フロントエンドでの入力フォーム＋リアルタイム計算

---

## 🧩 なぜ作ったのか？

再エネやソーラーパネルに興味があっても、初期コストが高くて踏み切れない…という声をよく聞きます。実際、**「いくら得するのか？」が見えにくい**のがハードルになります。

私はソフトウェアエンジニアとして、

* 「誰でも使える」
* 「シンプルに、数字で判断できる」

ツールがあれば、少しでも意思決定の後押しになるのでは？と考えて開発しました。

---

## 💬 フィードバック歓迎！

Qiitaの読者の皆さんからの技術的なフィードバック、または機能アイデアなどがあれば大歓迎です！スプレッドシート派も、WordPress派も、ぜひ一度使ってみてください。

コメント、または [X（旧Twitter）](https://twitter.com/yuichiro_otani) などでも気軽に声をかけてください！

---

## 🚀 今後の展望

* 世界各国の電気料金データとのAPI連携
* 導入コストとの比較グラフ表示
* モバイル向け軽量UI版の展開

---

以上、ご覧いただきありがとうございました！
スターや「LGTM」、拡散いただけるととても励みになります 🙏
GitHubを使わないチーム開発の難しさ

# **初めに**

　私はGASを使ってチーム開発をする機会がありました。ただ、なんとGitHubを使うことができませんでした。未経験の方もいたのでGitHubのキャッチアップまで時間を確保するのも難しいですし、多くの理由から使えないようになっていたんだと思います。
　まず、このチーム開発では未経験3人と経験者1人(自分)でチームを組んで開発していきます。そして、前提として経験者はアドバイザー的な立場となってチーム開発をするように言われます。つまり、企画とか発表を押し付けて経験者1人が開発することは推奨されないということです。

 ### これは困った！！
 いい物を作るなら1人で作った方が早い様に思えてしまう。GitHubもないから別々で作ってもコードをくっつけるもめんどくさいし、キャッチアップの時間も必要になる。良い結果を残そうとすると一人でやった方が早いし、チームメンバーも薄々そう思っているのではないかという疑心暗鬼になってしまう。

### ただ本当に大事なこととは
結果的に1人で開発することはせずに、全員の今後のためになるにはどうしたらいいかを一番に考えて行動することにしました。一人でカタカタして得られた良い製品ではなんとなく罪悪感が残りそうです:hugging:チームメンバーが開発を通して経験者がやってくれたから達成感はあんまりないとかなったら悲しいですよね:sob:
せっかくだから開発ってちょっと楽しいと思えるくらいの最初のお手伝いができたらと思ってみんなで開発するにはどうしたらいいか考えてました。

## 本題

### GitHubの役割

チーム開発で必要なことはざっくりこの二つだと考えています。

・環境を分けることができる
・書いたコード簡単に？統合することができる

環境を分ける
→複数人で同じファイルを触ると間違って人のコードを消してしまったり、同じ変数を使っていたりトラブルが起きてしまいます。そのため、同じファイルを複製して各々専用のファイルとして扱う必要があります。これを、環境を分けると表現しています。

書いたコードを統合する
→環境を分けたことで実際の製品の状態にするには統合しないといけません。GitHubならいい感じに統合してくれます。GitHubがないと変数名とか関数名が被ってなくて、このコードを何行目に入れたらよくて、ここは同じ機能だから無視してくて等々、考えるだけでめんどくさそうなのでこれ以上の例は上げません。考慮する要素が多くあるため、見逃してしまうことが多いです。人為的ミスを極力減らしてくれるGitHub君は素晴らしいということですね:thinking:

### 問題点

環境を分けるのはコピペで何とかなります。問題は、コードを統合する事です。これがめんどくさいわけです。開発の成功体験をみんなが積むための壁となって立ちふさがるわけですね:frowning2:

## 改善案

分担する前に機能を関数まで落とし込んで関数ごとの入力、出力を明確にしておくことが大切だと思っています。

これは、前提としてついついスプレッドシートから値を取得する機能の人、カレンダーにスケジュールを入れる機能の人みたい感じで機能ごとに分担してしまうと入力、出力が統一されておらず統合がしにくくなります。


A関数→B関数→C関数みたいな感じで繋がりを意識できるところまで設計を落とし込むことができたら、関数をコピペするだけでほぼ統合が終わることになります。こうなると人為的ミスはかなり起こりにくいいですね。なんなら他のファイルから関数を呼び出す方法がわかっているならmainファイルに1行書くだけで統合が終わりみたいなものです。

以下は、かなり抽象的ですが関数を動かすmainを用意しておいて先に関数を繋げて、関数さえ正しく動けば完成する状態まで全体を設計しておく。そして、関数ごとに仕事を分けて開発を進めることでGitHubが無くても簡単に統合できると思いました。

```
main.gs

int a = 〇;

Num = A(a);
Ans = B(Num) + C(Num);

return Ans;

```
```
A(a){
int x;
ここにAさんが機能を書く
return x
}

B(b){
int y;
ここにBさんが機能を書く
return y
}

C(c){
int z;
ここにCさんが機能を書く
return z
}
```

## 振り返り

では、開発中にここまで考えてきれいに進められていたかというと自分できていませんでした。mainファイルは頭の中にはできていてメンバーにはこんな感じで機能を作ってほしいと頼んでいました。今思うと、ちゃんとここまでmainファイルを作り込んだものを見せて頼んだ方がわかりやすかったのですが、ややこしい話よりも機能を実装するという方に集中させてあげたいという気持ちを盾にめんどくさがりな部分がでていました。

この記事を書いているときにGitHubがとか関係なくチーム開発はこうやってちゃんと考えた方がいいよねって話になってる気がしましたが許してください。
チーム開発をこうして振り返るとやっぱり難しいチャレンジだと思います。実際のチーム開発ではもっと適当だったのでこんなのでもしっかり機能を作ってくれたチームメンバーには感謝しかありません:sunglasses:1人では見られなかった景色をみせてくれて良い機会となりました。
ローカルから docker コンテナにファイルをコピーするコマンド

# これなに

- ローカル環境から docker コンテナ内にファイルをコピーするまでに必要なコマンドをまとめました
- 単なる基礎的な個人的なメモなのですが、興味がある人は読んでいただいても大丈夫です

# 基本コマンド

### コンテナIDまたは名前を確認する

```zsh
$ docker ps
CONTAINER ID   IMAGE         ...   NAMES
container-id   your-image    ...   your-container
```

### `docker cp` でファイルコピー

ダブルクオーテーションは便宜的に書いているだけなので、実際のコマンドには必要ありません

```zsh
$ docker cp "ファイルパス" "image-id":"コンテナ内のコピー先ディレクトリパス"
```

# 複数コンテナに一気にコピーさせたい時のコマンド

### コンテナ ID がすでに明確になっている時

```zsh
for cid in <container_id1> <container_id2> <container_id3>; do
  docker cp "ファイルパス" "image-id":"コンテナ内のコピー先ディレクトリパス"
  docker cp "ファイルパス" "image-id":"コンテナ内のコピー先ディレクトリパス"
done
```

### キーワードで引っ掛けてコピーする時

```zsh
for pod in $(kubectl get pods -n <namespace> -o jsonpath='{.items[*].metadata.name}' | tr ' ' '\n' | grep your-keyword); do
  kubectl cp "ファイルパス" "image-id":"コンテナ内のコピー先ディレクトリパス"
  kubectl cp "ファイルパス" "image-id":"コンテナ内のコピー先ディレクトリパス"
done
```

# さいごに

ひさしぶりに Qiita に記事投稿しました…

最近コーディングよりアーキテクト的な動きとかマネジメント寄りの動きばっかりしてたので社外向けにさっと書けるネタが無かったのですが、アプリ実装設計で色々やってた時に「あれ、これなんだっけ」ってなったのでメモついでに記事として書きました

今後またコンスタントに記事投稿できたらなあ、と思いながらまた次回は数ヶ月後とかになりそうな雰囲気（ぐぬぬ）
Vibe Codingのフロントエンド技術選定、なぜNext.jsなの？

# はじめに
昨今、生成AIを用いたフルスタック開発ツールがあると思いますが、技術選定時に毎回Next.jsになるのがすごく気になったのでChatGPTに聞いてみました。


# :person_with_blond_hair_tone1:
生成AIを用いたフルスタック開発では、Next.jsを選定することが多いと思うのですが、その理由を教えてください。

# 🤖
とても本質的な質問ですね。生成AIを活用したフルスタック開発において、Next.js がよく使われる理由はいくつかの技術的・実用的な要素が重なっています。以下に代表的な理由を挙げます。

## ✅ 1. フロントエンドとバックエンドを一体で構築できる（フルスタック対応）
Next.jsは、ReactベースでありながらAPI Routes機能を備えており、サーバーサイドのロジック（例：OpenAI APIの呼び出しや認証処理など）を同じコードベースで管理できます。

→ これにより、バックエンドを別に立てずに済むため、プロジェクト管理やデプロイがシンプルになります。

## ✅ 2. SSR（サーバーサイドレンダリング）とISR（増分静的再生成）の柔軟な選択
生成AI系アプリでは、ユーザー入力に対して動的にページを生成・更新するケースも多いですが、Next.jsならそれに適したSSRやISRを簡単に選べます。

→ SEOが重要な場合（例：公開するAI生成コンテンツ）や、初期表示の高速化に有利です。

## ✅ 3. Vercelとの親和性が高く、デプロイが容易
Next.jsはVercel社が開発しており、Vercelにデプロイするとゼロコンフィグで最適化されます。Vercelのエッジ関数やストレージとの統合もスムーズ。

→ 生成AIアプリの試作やスモールスタートに最適です。

## ✅ 4. リアルタイム通信やストリーミング表示との相性が良い
OpenAIなどのストリーミングAPI（ChatGPTのストリームレスポンス）を使う場合、Next.jsの  Edge RuntimeやReact Server Components（RSC）がうまく活かせます。

→ ユーザー体験を高めるリアルタイムUXが実現しやすいです。

## ✅ 5. Reactエコシステムとの統合性
生成AIアプリでは、UIや状態管理にReactの豊富なライブラリ（例：Framer Motion、TanStack Query、Recoilなど）を利用することが多く、Next.jsはそれらとの統合に優れています。

## ✅ 6. TypeScript対応やディレクトリ構造が洗練されている
AIアプリでは非同期処理やエラー処理が多く、型安全性が重要ですが、Next.jsはTypeScriptが前提になっていて、エンタープライズでも安心して採用できます。

## ✅ 7. コミュニティと情報量の多さ
生成AIとNext.jsを組み合わせた事例（例：AIチャットボット、文章生成アプリ、音声対話アプリなど）が非常に多く、参考にできるテンプレートやチュートリアルが豊富です。

## 補足
### 生成AI × Next.jsの代表的な構成例
フロント：Next.js（React + Tailwind）

バックエンド：Next.jsのAPI Routes または Edge Functions

認証：NextAuth.js

データベース：Supabase / Firebase / PlanetScale

ストレージ：Vercel Edge、Cloudflare、S3など

生成AI：OpenAI API（GPT-4、DALL·Eなど）
ONES Wikiの注釈（インラインコメント）で効率よくフィードバックしよう！

## はじめに
プロジェクト管理やチームナレッジの共有に便利な[ONES Wiki](https://systemcon.co.jp/products/oneswiki/)。その中でも特に役に立つのが「注釈（インラインコメント）」機能です。

今回は、この機能の特徴と、具体的な使い方をわかりやすくご紹介します。
## ONES Wikiの「注釈（インラインコメント）」とは？
「注釈（インラインコメント）」機能は、ONES Wikiのドキュメント上で特定のテキストや文章に直接コメントを追加できる機能です。

#### 主なメリット
* **ピンポイントな指摘ができる**：特定の文や段落に直接コメントを追加できるので、分かりやすい！
* **リアルタイムのフィードバック**：コメントを見たら、すぐに返信や修正ができる
* **履歴管理も安心**：コメントは履歴として残り、過去のコメントをいつでも確認できるので安心

#### ドキュメントのレビュー時に大活躍！
具体的な場所にコメントを残すことで、メンバーがピンポイントな指摘を追加したり、アドバイスをしたり、疑問な点を尋ねたり、スムーズにドキュメントの品質アップができますよ。

また、コメント付きの箇所は黄色でハイライトされ、クリックで内容をすぐに確認できます。コメントへの返信も、スレッド形式で簡単に行えますよ。

![レビューに大活躍.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/04aa0ec4-fd29-4cf1-ba6d-1c58cb12401e.png)

## ONES Wiki「注釈（インラインコメント）」の使い方

#### 1. 注釈を追加する
1\. コメントを追加したい文字列をドラッグします。
2\. ポップアップが表示されるので「注釈」ボタンをクリックします。

![注釈の追加1,2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/a054b4c0-0189-434a-8157-60bd474e8967.png)

3\. 「注釈」のウィンドウが出たらコメントを入力しましょう。メンションで特定のメンバーに通知も送れます。
4\. コメントを入力したら「確定」をクリックして完了です！

![注釈の追加3,4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/00ed5f92-3c5b-4153-9402-1b2f1d6eb8fa.png)

#### 2. 注釈に返信する（コメントの追加）
1. 注釈（インラインコメント）がある文字列をクリックすると、画面右側に注釈のウィンドウが表示されます。
2. 「注釈を追加」または「返信」アイコンをクリックするとコメントを追加できます。

「返信」をクリックするとメンションが自動で追加されます。または、キーボードの「@」マークの入力でメンバーの指定もできます。状況に応じて使い分けてください。

![注釈への返信.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/8517b806-fa07-46ef-b885-9bbec7a3e55c.png)

#### 3. 注釈を「解決」または「削除」する
レビューや修正が終ったコメントは、残しておくと紛らわしいですよね。黄色のハイライトを消すには2つの方法があります。

**➀解決する場合（通常はこちらを推奨）**
注釈画面の右上にある「✔️」マークをクリック。

![注釈を解決.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/d98acadf-9251-4a2b-b236-21e255d80207.png)

ハイライトは消えますが、コメント自体は「解決済みコメント」として履歴に残ります。

レビューがどのような経緯を経て修正されたのか、履歴の追跡もできるので、「注釈（インラインコメント）」は「削除」ではなく「解決」で処理しましょう。いつでも後から確認できるので安心ですね！

![解決澄みコメント例.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/59633acd-ad8a-4116-9da9-15ce81d50835.png)

また、解決済みの注釈は再オープンもできます。その場合、注釈の右下にある「再開」をクリックします。再オープンすると文字列は再度ハイライトされます。

![再オープン例.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/26b9e17e-95f4-404e-9b32-5355f110a165.png)

**➁削除する場合**
注釈画面の「・・・」をクリックし「削除」を選択します。
「削除」は間違えてコメントした場合に限定しましょう。

![注釈を削除.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3483972/aa1f764b-4a4b-4083-bff7-6a7d0d50075a.png)

## まとめ
ONES Wikiの「注釈（インラインコメント）」機能を使うと、チーム内のコミュニケーションがグッと強化されます。ドキュメントのレビューや修正が効率化でき、プロジェクトのスムーズな進行と品質向上の両立を手助けしてくれます。

ONES Wikiの注釈機能を使って、チームの生産性をアップを実感してみてくださいね！
【dockerとUbuntu コマンド】

Dockerをtbuild使うときは基本build(構築)してから、run(作成、起動)する。（複数コンテナの時はup)

```
./mvnw clean package
(mvn clean package)
```
springbootの場合は、ビルドの前にビルドクリーンをする。
ビルドクリーン→ビルド（構築）→ラン（作成・起動）
`./mvnw`はMaven Wrapper を実行するためのスクリプトで、環境に Maven をインストールしていなくてもプロジェクトのビルドを実行できる。
`clean`は以前のビルド成果物（`target/` ディレクトリなど）を削除するから、クリーンな環境でビルドが開始できる。
`package` は、プロジェクトをビルドして JAR ファイルを作成する。通常、`target/ `フォルダ内に成果物が生成されるらしい。
`mvn clean package`でもOK

```
docker build -t イメージ名　 .　　　　
```
`docker build`がDocker イメージを構築するコマンド。イメージ名を好きに付けられる。
「-t」イメージに名前とタグを付けるオプション

```
docker run --rm イメージ名
```
`docker run`がDockerイメージの作成からコンテナの作成、起動まで行うコマンド。
1度に1つのコマンドしか起動できないので、複数のコンテナを起動するときは`docker compose up`を使う
「--rm」はコンテナを残さない。このオプションを使用することで、コンテナが終了した後に手動で削除する必要がなくなる。（一時的なタスクの作成に便利）

```
docker compose up -d
```
「-d」のオプションをけると、サービスがバックグランドで実行されるので、起動しながら別のコマンドを打つことができる。
`docker compose up`の後に`--build`をつけるとイメージが再構築される。Dockerファイルを編集したら、`docker compose up --build`をしてから`docker compose up`をしないと編集内容が反映されない。
特定のサービスを指定する場合は、`docker compose up`の後に、起動したいコンテナ名を書く。

```
docker-compose stop
```
稼働中のコンテナを停止するが、削除はしない。
`docker-compose down `のコマンドで削除。
`docker-compose start`コマンドで、再起動。

```
tail -f docker logs コンテナ名（orコンテナID)
```
`doker logs 　コンテナ名（orコンテナID)`でもOK

```
docker container exec -it コンテナ名 bash
```
でDockerファイルの中に入れる。

```
ls　-L
```
リスト一覧を表示。（lsだけでもいける。）

```
pwd
```
自分のいる場所を表示する。


```
code .
```
今いるファイルをvsコード上で開く

```
㏅　ディレクトリ名
```
ディレクトリに移動

```
cd ..
```
上の階に移動（戻る）もう一個上に戻る場合は、`㏅　../　..　`って書く。
【 mvnwにアクセスが許可された】

#### ビルドクリーンして出たエラー

```
./mvnw clean package　（mvn clean package）
```

のコマンドを実行した際に、
```
-bash: ./mvnw: Permission denied
```
のエラーが出たら、
```
chmod +x mvnw
```
のコマンドを打つ。chmodはファイル or ディレクトリに対する権限を設定するコマンド「chmod  権限設定 ファイルパス」の形式で使う「+」は後に記述した権限を付加する「x」は実行権限の記号。【 mvnwにアクセスが許可された】
ChatGPTの返信に日時をつけたら快適になった話

(2025/06/11 追記：この方法は日時にズレが生じることがあるようです。対策を検討してみます。ごめんなさい。）

## はじめに
はじめまして、4月から某大学でエンジニアをしています。
ChatGPTの返信に日時を表示するようにしてみたら思いのほか快適度が上がりました。
初投稿ですが、どなたかの参考になれば嬉しいです！

## なぜ日時が欲しくなったか
ChatGPTと一緒にPythonプログラムを作っているとき、
「コードが動くまでにどのくらいかかったかを見返したい」と思ったのがきっかけです。

ですが、デフォルトではチャットに日時が表示されないため、あらためてChatGPTに聞いても合っていたり怪しかったり…。あとは曖昧な記憶に頼るしかなく、ちょっと不安でした。

## やったこと
#### ✅ ステップ1： 毎回のチャット開始時にお願いする
まず最初は、チャットを始めるときにこんな風にお願いしてみました：
```
なお、今後のチャットのリプライの末尾に該当チャットの返信日と時刻を日本時間で付加してください。
```
こうすると、そのチャットセッション中はすべての返信に日時が付きます。
ただし、新しいチャットを始めるとまたお願いしないといけません。これがちょっと面倒…。

#### ✅ ステップ2：カスタマイズ機能で恒久的に設定する
そこで次に試したのが、ChatGPTのカスタマイズ機能を使う方法です。

手順は以下の通りです(Web版の場合)：

1. ChatGPT右上のユーザーアイコンをクリック

2. 「ChatGPTをカスタマイズする」を選択

3. 「ChatGPT にどのような特徴を求めていますか？」の欄に、以下を追加：
```
チャットのリプライの末尾に該当チャットの返信日と時刻を日本時間で付加します。
```
この一文を入れておくだけで、すべてのチャットで自動的に日時が付くようになりました。
私は「日時情報なんて、なんぼあってもいいですからね。」というタイプなので、全ての返信に日時が付くようになり、大満足しています。
有料プランの方はプロジェクト単位での設定も可能なので、「このプロジェクトでは付ける」「このプロジェクトでは不要」といった切り分けもできそうです。

## 実際にやってみてどうだったか
この設定にしてから、次のようなメリットを感じています：

- 「このやりとり、いつだったっけ？」がすぐわかる

- 開発や調査にかかった時間を後で把握しやすい

- チャットログが“記録”として使いやすくなった

- なんか安心感がある！

## おわりに
今回の内容はとても小さな工夫ですが、 **「後でわざわざ確認しなくてもわかる」** 情報が1つ増えるだけで、思っていた以上に快適になりました。

こういう小さな改善が意外と効くかもしれませんので、
「同じこと思ってた！」という方がいたら、ぜひ試してみてください。

## 追記(2025/06/11)
どうも上の方法でChatGPTが付けてくれるタイムスタンプはズレることがあるようです。今のところ「タイムスタンプがズレてますよ」と指摘すると正しい時間に合わせるべく努力はしてくれるみたいですが、毎回時間が合っているかを確認するのはストレスですね。。
time.is から取ってくる方法もまだ上手く行っていません。良い方法が見つかりましたらまたアップデートするようにします。
【pgAdmin4 を使ったpostgeSQL】

#### テーブル作成
```CREATE TABLE 　テーブル名　(
 order_id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 customer_id INTEGER,
 order_date DATE
);
```
INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,はMySQLのオートインクリメントキーと一緒（連続した数値をカラムに自動で設定する機能）

#### テーブルの削除
```
DROP TABLE テーブル名;
```
#### カラム（列）のデータ型変更
```
ALTER TABLE テーブル名 ALTER COLUMN カラム名 TYPE データ型;
```
#### テーブルにカラム（列）を追加
```
ALTER TABLE テーブル名 ADD COLUMN カラム名 データ型;
```
#### テーブルのカラム（列）を削除
```
ALTER TABLE テーブル名 DROP COLUMN カラム名;
```
#### テーブルにデータの追加
```
INSERT INTO テーブル名(カラム名)　VALUES (追加する内容);
```
例）INSERT INTO threads(content,title,user_id)VALUES ('ないよう','タイトル',3);
複数のカラムを追加するときは、（カラム名,カラム名,カラム名）でカンマで区切る
追加する内容はカラムの内容と同じ順番になるようにする。
複数の情報を追加するときは、（カラム名）VALUES VALUES (追加する内容), (追加する内容) ,(追加する内容)；みたいな感じでカンマで区切る。
文字列は。「' '」で囲う。

#### テーブルのデータを取得する（一部のカラムを取る場合）
```
SELECT　列１（カラム）,列２（カラム名）・・・ from テーブル名；
```

#### テーブルのデータを取得する（全ての列を取得したい場合）
```
SELECT * FROM テーブル名;
```

#### テーブルの特定のデータを取得する（WHERE句）
```
SELECT * FROM テーブル名　WHERE 条件;
```

#### テーブルの特定のデータを取得する（ORDER BY句）
```
SELECT * FROM テーブル名　ORDER BY カラム名 ASC;　（昇順）
SELECT * FROM テーブル名　ORDER BY カラム名　 DESC;　（降順）
```

#### クエリの結果セットに返される⾏数を制限する（limit句）
```
-- 最初の10⾏を返す
 SELECT * FROM example_table LIMIT 10;
-- 11⾏⽬から始まる5⾏を返す
 SELECT * FROM example_table ORDER BY price DESC;
```

#### データを更新する
```
UPDATE テーブル名 SET カラム名 = 変更する内容;
```
一括で全部置き換わる

#### データの変更（条件に一致したデータのみ変更）
```
UPDATE テーブル名 SET カラム名 =　変更する内容　WHERE 条件式;
```

#### データの変更（複数のデータ変更）
```
UPDATE テーブル名 SET カラム名 =　変更する内容,カラム名 =　変更する内容　WHERE 条件式;
または
UPDATE テーブル名 SET （カラム名,カラム名） =（変更する内容,変更する内容）　WHERE 条件式;
```

#### データの削除
```
DELETE FROM テーブル名 WHERE 条件式;
```

#### レコード
データベース内のテーブル含まれる１行分のデータ、または関連することの集まり。

#### 統合結合（UNION/UNION ALL）の基本構文
```
SELECT句
UNION／UNION ALL
SELECT句
```
統合結合は、２つ以上のSELECTの結果を統合して取得する。「UNION」は、統合した結果で重複したデータをまとめて表示し、「UNION ALL」は、重複したデータもそのまま全て表示する。複数のSELECTクエリの結果を結合して1つの結果セットとして返すための構⽂だから、各SELECTクエリ は同じ数のカラムを持ち、それぞれの対応するカラムが互換性のあるデータ型でないといけない。

#### 内部結合（INNER JOIN）の基本構文
```
SELECT 項目X,項目a,項目b
FROM テーブルY
INNER JOIN テーブルZ　ON テーブルY.項目A = テーブルZ.項目A;
```
両方のテーブルに一致するレコードのみ取得。（テーブルｙの項目ａとテーブルｚの項目ａに一致してるテーブルｚの項目x、項目ａ，項目ｂを取得）

#### 内部結合LEFT JOIN (LEFT OUTER JOIN)の基本構文
```
SELECT 項目X,項目a,項目b
FROM テーブルY
LEFT JOIN テーブルZ　ON テーブルY.項目A = テーブルZ.項目A;
```
左側のテーブルのすべてのレコードと、右側のテーブルに⼀致するレコードを取得する。右側に⼀致 するレコードがない場合、NULLが返される。

#### 内部結合RIGHT JOIN (RIGHT OUTER JOIN)の基本構文
```
SELECT 項目X,項目a,項目b
FROM テーブルY
LEFT JOIN テーブルZ　ON テーブルY.項目A = テーブルZ.項目A;
```
右側のテーブルのすべてのレコードと、左側のテーブルに⼀致するレコードを取得する。左側に⼀致 するレコードがない場合、NULLが返される。

#### GROUP BY句
```
SELECT [カラム名] 
FROM [テーブル名] 
GROUP BY [グループ化したいカラム名、条件];
```
が基本文。重複しないカラム名を取得する場合は、SELECT name AS 'カラム名' FROM sample01 GROUP BY name;、各カラムのvalue（カラム名）の合計値を取得する場合はSELECT name AS '商品名', SUM(value) FROM sample01 GROUP BY name;等いろんな使い方がある。

#### HAVING句
```
SELECT カラム名, COUNT(*) AS count 
FROM テーブル名 
GROUP BY カラム名　
HAVING COUNT(*) 　条件(>10とか）;
: GROUP BY句でグループ化されたデータに対して条件を指定する
```

#### サブクエリ（副問合せ）
```
SELECT　カラム名１, カラム名２ 
FROM テーブル名 
WHERE カラム名３ = (SELECT カラム名３ FROM テーブル名 WHERE カラム名２ = '加藤');
```
テーブル名のカラム名２が’加藤’であるカラム名３を持つテーブル名のレコードを取得する。
階乗の末尾に 0 はいくつ付く？ 　正規表現 vs 5の因子



Paizaで階乗の末尾の 0 を数える問題に挑戦したら、まさかの“桁数オーバー事件”！

でも、冷静に考えたら意外とシンプルなルールに気づいて解決！

<br>

## 問題概要

- 整数 N が与えられる。
- N の階乗 N! の末尾に 0 がいくつ付くか求め、出力。

<br>

入力例：

    100

出力例：

    24

<br>

https://paiza.jp/works/mondai/loop_problems2/loop_problems2__factorial_zero

<br><br><br>

## ❌ NG例
```js
const rl = require('readline').createInterface({ input: process.stdin });

rl.once('line', (input) => {
  const N = Number(input);

  // 階乗を計算（前回のコード）
  let factorial = 1;
  for (let i = 1; i <= N; i++) {
    factorial *= i;
  }


  // 文字列化して、末尾の0を正規表現で取得
  const zeroMatch = String(factorial).match(/0+$/);

  // nullの場合は末尾に0がないから、カウントは0
  const zeroCount = zeroMatch ? zeroMatch[0].length : 0;

  console.log(zeroCount);
  rl.close();
});
```
- 末尾の連続する 0 を `/0+$/` で取得
-  `.match()` は、見つからないと `null` になるから、
    `zeroMatch ?zeroMatch[0].length : 0` で安全に出力

<br>

## ⚠️ 問題点 ：N! がとても大きくなる

例えば N=100 だと、
100! は 158桁もある巨大な整数になる。

JavaScript の Number型 は 約 16 桁までしか正確に表せない。
（64ビット浮動小数点数のため）

<br>

## 🤔 末尾0の仕組みを考えてみる

→末尾の 0 は「10 の倍数」がいくつ含まれているかで決まる！

末尾に0がつくのは、数字が10の倍数になっているときだよね。
10 = 2 × 5 だから、10を作るために必要な因数「2」と「5」を数えればいい！

<br>

でも、N! には 2 の因子がものすごく多いのに対して、5 の因子はずっと少ない。



例: 10!　：

10! = 1×2×3×…×10
    5 は 5,10 など
        2 は 2,4,6,8,10 などからたくさん出てくる

<br><br>

## 🔥 「5の倍数」で末尾0をカウント！

具体的には、N! に含まれる 5 の因子の数を数えるだけでOK！


でも注意！5の倍数だけじゃなくて、25（=5²）、125（=5³）…と、5の累乗が出てくる数も追加でカウントする必要がある。

例えば、N=100のときの5の因子の数を数える流れはこう。

1️⃣ まず「5の倍数の個数」を数える。
  100/5 = 20（20個ある！）

2️⃣ 次に「25の倍数の個数」も考慮。
  100/25 = 4（25は5×5だから、さらに1つ5が含まれる）

3️⃣ 125は100以下にないから、終了。

合計すると、20+4=24 で、末尾の0は24個になる。

最初に階乗を計算しなくても、こうやって5の因子の個数を足すだけで解決！

<br>

### 🔎 なぜ 25（5²）で割れるものも考慮するのか？

末尾ゼロを生む条件は「10 = 2×5」なので、N! に含まれる「5の数」を数えるんだけど…
N! には 5 の倍数だけでなく、25（=5²）、125（=5³） で割れる数 もある。

たとえば 25! には：

5 の倍数が 5, 10, 15, 20, 25 → 5の倍数は5回

25 は 5² なので、さらに1回カウントされる（5²は5が2回含まれるから）

<br><br><br>

## ✅OK例

そんな気づきから、最終的に書いて正解したコードがこちら。

```js
const rl = require('readline').createInterface({input: process.stdin});

rl.once('line', (input) => {
  const N = Number(input);
  let count = 0;

  for (let i = 5; i <= N; i *= 5) {
    count += Math.floor(N / i);
  }

  console.log(count);
  rl.close();
});
```
- 末尾の 0 は「10 の倍数」がいくつ含まれているかで決まる。
- 10 = 2 × 5 なので、N! に含まれる 5 の数 に注目すればいい。
- 5, 25, 125… の倍数ごとに加算


<br>

## 📝 気づきメモ
- 末尾0の数は「10の因子の数」だけど、2は多すぎるから「5の因子数」で決まる。
- 5, 25, 125…の累乗を考慮するのがポイント！
- JSの浮動小数点数の限界を意識して、計算の方針を変える必要がある。

<br>

## 🎯 まとめ

というわけで、Paizaの「階乗の末尾0」問題は、大きな数の階乗を直接計算しようとすると失敗するってことと、数の性質に注目するのが大事ってことを学んだ！数学チックな問題だった(´;ω;｀)


<br><br><br>[僕の失敗談(´;ω;｀)と解決法🐈](https://paizabeginner.wordpress.com/2025/06/10/paiza%e3%81%a7%e5%9f%ba%e6%9c%ac%e3%83%9e%e3%82%b9%e3%82%bf%e3%83%bc%ef%bc%9a%e9%9a%8e%e4%b9%97%e3%81%ae%e6%9c%ab%e5%b0%be%e3%81%ab-0-%e3%81%af%e3%81%84%e3%81%8f%e3%81%a4%e4%bb%98%e3%81%8f%ef%bc%9f/)
RaspberryPi: SPI が有効かどうかを確認する方法

## SPI を有効にするには

```bash
sudo raspi-config
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/179446/43dda507-26f5-4f70-88c3-9a7fabaaeceb.png)

## 有効になっているのを確認


```text
$ sudo raspi-config nonint get_spi
0
```

```text
$ ls -l /dev/spidev*
crw-rw---- 1 root spi 153, 0 Jun 10 17:00 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 Jun 10 17:00 /dev/spidev0.1
```

```text
$ sudo cat /boot/firmware/config.txt | grep spi
dtparam=spi=on
```

```text
$ lsmod | grep spi
spidev                 20480  0
spi_bcm2835            20480  0
```

## 無効の時の実行結果

```text
$ sudo raspi-config nonint get_spi
1
```

```text
$ ls -l /dev/spidev*
ls: '/dev/spidev*' にアクセスできません: そのようなファイルやディレクトリはありません
```

```text
$ sudo cat /boot/firmware/config.txt | grep spi
#dtparam=spi=on
```

```text
$ lsmod | grep spi
$
```


## 確認したバージョン

```text
$ uname -a
Linux rose 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux
```