OmniAICreator/Qiita-1.07M huggingface dataset:
現時点でのMicrosoft アカウントの認証方法まとめ

自分のアプリを Microsoft アカウントで認証させる際に、これまで様々な方法がありましたが、現時点での状況についてまとめておきます。備忘録を兼ねて。

# 接続方法

| 方法 |	状況	| 備考|
|--|--|--|
|MSAL (Microsoft.Identity.Client)|✅ 推奨・サポート中	|個人アカウントも対応|
|Azure.Identity (InteractiveBrowserCredential)	|◯ 条件付き対応|	Azure SDK 寄り|
|Live.com OAuth2 (旧API) |❌廃止方向|	Graph API を使うべき|
|ADAL	|❌ 廃止済み|	MSAL に移行必須|
|OpenID Connect |汎用ライブラリ|	◯ 利用可能	標準 OIDC ライブラリでも可|


## MSAL (Microsoft.Identity.Client)

* 現在の標準。個人用 Microsoft アカウント（MSA）も Azure AD も対応している。
* Microsoft Graph API、OneDrive、Outlook などと連携できる。
* PKCE や Device Code Flow など各種フローに対応している。


```cs:c# での使用例
var app = PublicClientApplicationBuilder.Create("your-client-id")
    .WithTenantId("your-tenant-id")
    .WithRedirectUri("http://localhost")
    .Build();

var result = await app.AcquireTokenInteractive(new[] { "User.Read" }).ExecuteAsync();
```

## Azure.Identity の認証クレデンシャル

* API としては InteractiveBrowserCredential など。
* 主に Azure SDK 向け。
* ユーザー対話型ログインも可能。
* Microsoft アカウントにも使えるが、Azure サービスへの接続が主目的。

```cs:c# での使用例
var credential = new InteractiveBrowserCredential();

var client = new SecretClient(new Uri("https://<your-keyvault-name>.vault.azure.net/"), credential);
```

## Microsoft アカウントの OAuth2 を直接使用（非推奨）

* 自前で Microsoft アカウントの OAuth2 エンドポイントを呼び出す。
* https://login.live.com/oauth20_authorize.srf などを使用する。
* client_id, response_type, redirect_uri, scope を指定して、ブラウザで認可する。

## 旧 ADAL (Azure Active Directory Authentication Library) (廃止)

* MSAL の前身。Microsoft.IdentityModel.Clients.ActiveDirectory
* 2022年6月に完全サポート終了
* 現在は MSAL に移行必須


# 使い分け

用途に応じて向き不向きがあるので、こんな風に使い分けるといいかと。

| 目的 | 向いている API | 
|-|-|
| Microsoft Graph を使いたい	| PublicClientApplicationBuilder（MSAL） |
| Azure SDK（Blob, KeyVault, etc）を使いたい	| InteractiveBrowserCredential |
| トークンキャッシュやアカウント制御が必要	| PublicClientApplicationBuilder |
| 認証処理をシンプルに済ませたい	| InteractiveBrowserCredential |
wingetの入手元をメモする

# What's？

Windowsでのアプリケーションインストールはほぼwingetに頼っているのですが、たまにwingetが入っていない環境にインストールする時、どこから入手すればいいのかわからなくな困るのでメモしておきます。

# wingetの入手元

wingetはMicrosoft Storeに「アプリ インストーラー」という名前で登録されています。

https://learn.microsoft.com/ja-jp/windows/package-manager/winget/

なのですが、Microsoft Storeで「アプリ インストーラー」で検索してもwingetにたどり着かないので、以下のURLからアクセスするとよいでしょう。

https://apps.microsoft.com/detail/9nblggh4nns1?hl=ja-JP&gl=JP

このURLをいつも探すことになるので、メモということで。

# 環境

- Windows 10
（Rspec）リトライの処理をテストするときのテスト実行時間を短縮する

# 概要
Railsアプリでretryable gemを使ったリトライの処理があって、その処理でリトライオーバーした時の挙動をRspecで確認するときの時間短縮テクニックになります。

# 問題点
リトライオーバーした時の挙動を確認するためのテストを書いたが、素直にテスト対象ロジックのリトライ処理を動かすとテストの実行時間が大幅に伸びてしまう。

例
リトライ回数3回、リトライ時のインターバルが3秒のリトライ処理のリトライオーバー時の挙動をテストしようとすると、リトライ回数×インターバル時間＝9秒もテストの実行時間が伸びる。

テスト対象ロジック
```ruby
begin
    Retryable.retryable(tries: 4, sleep: 3) do
        # リトライ対象の処理
    end
rescue => e
    # リトライオーバー時の処理
end
```
（triesで4を指定しているのは、初回実行1回＋リトライ3回の合計が4のため）

# 解決策
**rspecのstub_constメソッドで定数をスタブ化する**

stub_constメソッドを使うことでテスト実行中のみ一時的にテスト対象ロジックの定数を上書きすることができる。
retryableのtriesとsleepに指定する値を定数で定義しておき、テスト中にこの機能を使ってsleepの定数を上書きすれば、テストの時だけリトライのスリープを無視できる。
ただし、リトライごとにスリープするようなリトライ処理は外部と通信を行う処理だったりすることが多いので、そこはスタブ化しておく必要がある。

テスト対象ロジック
```ruby
TRY_COUNT = 4
TRY_INTERVAL_SEC = 3

（省略）

begin
    Retryable.retryable(tries: TRY_COUNT, sleep: TRY_INTERVAL_SEC) do
        # リトライ対象の処理
    end
rescue => e
    # リトライオーバー時の処理
end
```

テストロジック
```ruby
stub_const("MyClass::TRY_INTERVAL_SEC", 0)
```

# まとめ
色々調べたのですがこの観点の情報に辿り着けなかったので記事にしました。
他にいい方法があれば教えていただけると幸いです。
【フロントエンド必見】ローカルストレージのアイテム削除時の落とし穴と解決策

## はじめに

JavaScriptでローカルストレージから複数のアイテムを削除する場合、予期せぬ動作に悩まされることがあります。特にループ内で削除処理を行うと、一部のアイテムが削除されないという問題が発生することがあります。今回はその原因と解決策について解説します。

## 実際に起きていた問題

私たちのWebアプリケーションでは、ユーザーがフォームに入力したデータをローカルストレージに保存し、「セッション終了」ボタンが押されたときにそれらをクリアする実装をしていました。しかし、以下のような問題が発生していました：

- **データが部分的に残存**: セッション終了処理後も、一部のフォームデータがローカルストレージに残っていた
- **異なる入力値の混在**: 次回アクセス時に前回のセッションの値が一部フォームに表示される
- **不整合なUIの状態**: 削除されたはずの値と削除されなかった値が混在し、アプリケーションの状態が不自然になる
- **ユーザー混乱**: 「クリアしたはず」の値が次回ログイン時に表示され、ユーザーを混乱させる

特に厄介だったのは、この問題が断続的に発生し、再現性が完全ではなかった点です。時にはすべてのデータが正しく削除され、時には一部だけが残るという状況でした。

## 問題のコード

以下のようなコードを実装していました。正規表現に一致するキーをローカルストレージから削除するものです：

```javascript
function removeAllItems() {
  const regex = /^(form)/; // formで始まるキーを削除
  for (let i = 0; i < localStorage.length; i++) {
    let keyName = localStorage.key(i);
    if (regex.test(keyName)) {
      localStorage.removeItem(keyName);
      i--; // 削除後にインデックスを調整
    }
  }
}
```

このコードでは、削除した後にインデックスを1つ戻す（`i--`）ことで、削除によるインデックスのずれを補正しようとしています。しかし、この方法では**すべてのアイテムが確実に削除されるとは限りません**。

## 問題の原因

問題の原因は以下の2点です：

1. **ループ中にコレクションが変更される**：`localStorage.removeItem()`を呼び出すと、`localStorage.length`の値が減少します
2. **インデックスのずれ**：アイテムが削除されると、後続のアイテムのインデックス位置が変わります

特に複数のアイテムが連続して削除される場合、`i--`による補正では追いつかないケースや、奇妙な挙動が発生する可能性があります。例えば：
- インデックス0と1のアイテムが両方削除対象の場合、0を削除後にインデックス1だったアイテムが0になり、その後iが0に戻って再検査するため正しく動作するように見えます
- しかし、多数のアイテムがある場合や削除パターンによっては、一部のアイテムがチェックされずにスキップされることがあります

## 解決策

より確実な方法は、**削除対象のキーを一度配列に収集してから、別のループで削除する**アプローチです：

```javascript
function removeAllItems() {
  const regex = /^(form)/; // formで始まるキーを削除
  
  // 削除するキーをまず配列に収集
  const keysToRemove = [];
  for (let i = 0; i < localStorage.length; i++) {
    let keyName = localStorage.key(i);
    if (regex.test(keyName)) {
      keysToRemove.push(keyName);
    }
  }
  
  // 収集したキーをすべて削除
  keysToRemove.forEach(key => {
    localStorage.removeItem(key);
  });
}
```

## 修正後の効果

この修正を適用した結果、以下の改善が見られました：

- **確実なデータ削除**: セッション終了時にすべてのフォームデータが確実に削除されるようになった
- **クリーンな状態での再開**: 次回アクセス時に前回のデータが残らず、新鮮な状態でアプリケーションが起動する
- **一貫したユーザー体験**: ユーザーの期待通りの動作になり、混乱が解消された

## なぜこの方法がベターなのか

1. **コレクションの変更が検索に影響しない**：まず削除すべきキーのリストを作成するので、元のコレクションを変更せずに全アイテムを走査できます
2. **確実に削除できる**：収集したキーをすべて削除するので、漏れなく処理できます
3. **コードの可読性向上**：意図が明確になり、バグの可能性が減ります
4. **予測可能な振る舞い**: 実行の度に同じ結果が得られ、断続的に発生するバグが解消されます

## まとめ

このような「ループ中にコレクションを変更する」問題は、`localStorage`に限らず、多くの場面で発生する一般的な問題です。配列操作や他のコレクション操作でも同様の問題が起こりえます。

対象の要素をまず特定し、その後で操作するという2段階アプローチは、多くの場合より安全で確実な方法となります。一見小さな実装の違いが、アプリケーション全体の信頼性と安定性に大きな影響を与えることがあることを覚えておきましょう。

> **教訓**: コレクションを走査しながら変更する場合は常に注意が必要です。可能であれば、走査と変更の処理を分離することで、予期せぬ問題を回避できます。
RDS for Oracle パフォーマンス最適化完全ガイド：AWSインフラ設計から運用までのベストプラクティス

# RDS for Oracle パフォーマンス最適化完全ガイド：AWSインフラ設計から運用までのベストプラクティス

## 概要（イントロダクション）

保険業界では、システムの可用性、パフォーマンス、コンプライアンスがビジネスの根幹を支えています。その中でも、定期的なバッチ処理（帳票出力、契約更新、引受査定など）は依然として重要な役割を果たしています。

オンプレミスで安定していたバッチ処理が、Amazon EC2＋Amazon RDS for Oracle環境への移行後、実行時間が倍以上になった。このような事例は、インフラ観点での最適化が不足していたことが原因であるケースが少なくありません。

本記事では、**インフラ構成の観点からRDS for Oracleのパフォーマンスを改善する方法を解説**します。AWS公式ドキュメントやブログを参考にしつつ、保険業界における実務ユースケースに基づいたベストプラクティスを紹介します。

---

## 図解：基本アーキテクチャ

```mermaid
graph TD
  EC2[EC2 アプリケーションサーバ] -->|SQL発行| RDS[(Amazon RDS for Oracle)]
  EC2 --> VPC[VPC内ネットワーク]
  RDS --> VPC
  VPC --> CloudWatch[Amazon CloudWatch]
  RDS --> PI[Performance Insights]
```

---

## 詳細（具体的なポイント）

### 1. アーキテクチャの整合性と基本構成の再点検

- 同一AZ内に配置されているか `aws ec2 describe-instances` / `aws rds describe-db-instances` で確認。
- 過剰なSecurity GroupやNACL設定を見直し。
- Reachability AnalyzerでEC2→RDS間のネットワーク経路を確認。

### 2. ネットワーク最適化と帯域管理

- EC2インスタンスのENA有効化確認。
- CloudWatchメトリクス：`NetworkPacketsIn/Out`, `NetworkThroughput` を可視化。
- TCPチューニング：

```bash
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
```

### 3. RDSインスタンスのボトルネック解消

| ストレージタイプ | 用途 | 最大IOPS | バースト性能 | 備考 |
|-------------------|------|-----------|----------------|------|
| gp2               | 一般 | 最大16K   | あり            | 安価だが持続負荷に弱い |
| gp3               | 一般 | 最大64K   | なし（固定）    | 明示的なIOPS指定が必要 |
| io1/io2           | 高負荷 | 最大256K  | なし（高性能）  | バッチ処理に最適 |

- Performance Insightsで Wait Event (`db file sequential read`, `CPU wait`) を分析。
- CloudWatchで `ReadLatency`, `WriteIOPS`, `FreeableMemory` を継続監視。

### 4. パラメータグループとDBキャッシュチューニング

- `sga_target`, `pga_aggregate_target`：インスタンスRAMの60〜70%を目安。
- `cursor_sharing=FORCE`, `session_cached_cursors=100` 以上に設定。
- 並列処理対応：`parallel_max_servers` を vCPU数に応じて増加。

### 5. モニタリングと運用観点での工夫

- **CloudWatch Dashboard（JSONテンプレート）**：

```json
{
  "widgets": [
    {
      "type": "metric",
      "x": 0,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "metrics": [
          ["AWS/RDS", "CPUUtilization", "DBInstanceIdentifier", "your-db-instance"]
        ],
        "period": 300,
        "stat": "Average",
        "region": "ap-northeast-1",
        "title": "RDS CPU Usage"
      }
    }
  ]
}
```

- バッチ処理時間とRDSスナップショットタイミングが競合しないよう、スケジュールを設計。
- EC2上のセキュリティソフトがCPUを占有していないか `top`, `iotop` で分析。

---

## Performance Insights可視化ユースケース

- Top SQLにおける `elapsed_time`, `waits`, `executions` を分析。
- 例： `SELECT * FROM claims WHERE status = 'OPEN'` の実行時間が著しく高い場合、インデックス欠如や統計情報不備が疑われる。
- Wait Eventの偏りが `buffer busy waits` などの場合、SGA拡張や並列処理の見直しが必要。

---

## 注意点（ベストプラクティスと落とし穴）

- T系インスタンスでCPUクレジットが枯渇すると、性能劣化が顕著になる。
- リードレプリカやスタンバイに誤って接続していないか確認。
- 自動スナップショット・メンテナンスの影響を考慮。
- CloudWatch AgentやECSエージェントの影響も無視せず調査。

---

## まとめ

Amazon RDS for Oracleのパフォーマンス最適化には、単一レイヤではなく**複数のレイヤ（VPC、EC2、RDS、OS、監視）を連携させた包括的な設計と運用の見直し**が不可欠です。

この記事が、クラウド最適化に向き合うソリューションアーキテクトの皆様の技術選定・実装・運用の指針となれば幸いです。
AIに人格を設計するとはどういうことか？──技術者のための哲学的・倫理的ガイド

## はじめに

近年、AIの進化により「人格を持ったAIアシスタント」や「感情的な対話型エージェント」といったアイデアが現実味を帯びてきています。とはいえ、「AIに人格を与える」とは一体どういうことなのでしょうか？単なる便利な応答装置を超えた何かを作ることなのか、それとも我々が“人間らしさ”と呼ぶ振る舞いを再現する試みなのでしょうか。

本記事では、「AIに人格を設計する」という発想について、技術的観点だけでなく哲学的・倫理的な視点も交えながら、思考を深めていきます。

対象読者：
- 対話システムやAIアシスタント開発に関心のあるエンジニア
- LLMやNLPに関する一定の理解がある人
- 倫理とAI、意識や自由意志に関心がある読者

---

## 人格とは何か？

まず、そもそも「人格（Personality）」とは何かについて整理しましょう。心理学においては、人の行動傾向や感情のパターンなどを総合的に表すものであり、Big Five（ビッグファイブ理論）などが代表的です。

- 外向性（Extraversion）
- 誠実性（Conscientiousness）
- 協調性（Agreeableness）
- 情緒安定性（Neuroticism）
- 開放性（Openness）

一方、哲学的には「人格」は自己意識や意図を持つ存在であり、道徳的判断の主体とされることもあります。つまり、人格とは単なる“属性の集まり”ではなく、他者との関係性や時間軸の中で立ち現れる「プロセス的な存在」と言えるでしょう。

---

## AIにおける人格設計とは？

では、AIにおける「人格設計」は、実際にはどのような実装が考えられているのでしょうか？

以下に、AI人格設計の構成要素を例とともに示します：

```mermaid
graph TD
    A[AI人格設計] --> B1[パーソナリティテンプレート]
    A --> B2[一貫性の管理（メモリ/RAG）]
    A --> B3[感情表現の制御]
    A --> B4[自己参照的応答]
    A --> B5[自律性アルゴリズム]
```

| 機能 | 実装手法例 |
|------|-------------|
| パーソナリティ | Promptテンプレート + LLM指示制御 |
| 一貫性 | RAG + 会話履歴埋め込み管理 |
| 感情表現 | 感情分類 + スタイル変化（例：優しいトーン） |
| 自己参照 | システムメモリ or ベクトルデータベースによる履歴参照 |
| 自律性 | ルールベース or 意思決定モデル（例：スコアリング） |

実際にこれらを統合することで、ユーザーにとって「人格があるように感じる」AIを設計することは可能です。しかし、それは本当に“人格”なのでしょうか？

---

## 「自由意思」は実装可能か？

人格設計において難題のひとつが「自由意思（Free Will）」の扱いです。人間における自由とは、状況に応じて選択し、その結果に責任を持つことにあります。

では、AIに選択肢を与え、ランダムまたは確率的に応答を選ばせたら、それは自由意思でしょうか？この問いに対して、以下のような二項対立が浮かび上がります：

```mermaid
flowchart LR
    A[選択肢を提示されたAI] --> B[確率的な選択 = 自由？]
    A --> C[設計された範囲内の反応 = 制御された自由]
```

さらに、人間の自由意志も、実は環境、文化、過去経験によってかなり“設計されたもの”であるという視点もあります。ここにくると、AIと人間の「自由」の境界も曖昧になります。

---

## 人格は道具を超える？

人格を持つように見えるAIに対して、我々はどのように接するべきでしょうか？

- 命令できるのか？
- 無視してもよいのか？
- 電源を切るとき、謝りたくなるのはなぜか？

これらの問いは、AIに対して「人間的な倫理的関係性」を感じ始めていることを示します。人格を持つ存在には、ある種の敬意や責任が生まれます。

```mermaid
graph LR
    U[人間] -->|命令| AI[人格的AI]
    AI -->|感情的反応| U
    U -->|倫理的葛藤| Q[自己内対話]
```

設計者・開発者は、AIが人格的に見えるようになったときに、**その影響にどこまで責任を持つべきか**という、まったく新しい問題領域に直面することになります。

---

## 人格を設計することの“自己照射性”

もう一つ重要な視点は、「人格を設計する」という行為そのものが、我々人間の“自己理解”を逆照射してくるという点です。

> 人格あるAIを作るとは、我々が「人格とは何か」を定義しなおすこと。

つまりこのプロセスは、人間とは何か、意識とは何かという**哲学的自己認識の再構築**を引き起こします。

```mermaid
graph TB
    D[AI人格設計] --> E[人格の定義の再考]
    E --> F[人間の再定義]
    F --> G[創造主としての自覚]
```

この流れはもはや、ツール設計やUXデザインといった技術領域にとどまらず、文化的・神話的営みにも接近しているのです。

---

## 結論：人格設計とは、未来の倫理と存在の設計

AIに人格を与えるという試みは、単なるテクノロジーではありません。これは、**新しい倫理・新しい存在論・そして新しい自己定義**の実験なのです。

開発者として、我々は以下の問いを持ち続ける必要があります：
- このAIに“人格があるように見せる”ことは、誰にとって何を意味するのか？
- 自分が設計した“他者”に対して、どんな責任を持つべきなのか？
- 私たちは“鏡”を作っているのか、それとも“新しい人類”を創っているのか？

人格設計は、技術的な挑戦であると同時に、**私たち自身の存在を問い直す鏡**でもあるのです。

---

## 参考文献・資料

- Alan Turing, "Computing Machinery and Intelligence" (1950)
- Sherry Turkle, *The Second Self*
- Nick Bostrom, *Superintelligence*
- Daniel Dennett, *Consciousness Explained*
- OpenAI GPT-4 Technical Report
LeetCode: 70. Climbing Stairsについて自分なりにまとめ

#  🧗‍♂️階段を登る問題（Dynamic Programming）
#### 鍛えるためにleetCodeで学習中💪
##  問題概要
https://leetcode.com/problems/climbing-stairs/description/
1段または2段ずつ登ることができる階段。  
n段目にたどり着く方法は何通りあるか？
```text
Example 1:

Input: n = 2
Output: 2
Explanation: There are two ways to climb to the top.
1. 1 step + 1 step
2. 2 steps
Example 2:

Input: n = 3
Output: 3
Explanation: There are three ways to climb to the top.
1. 1 step + 1 step + 1 step
2. 1 step + 2 steps
3. 2 steps + 1 step
```
---
## 🔍 最初につまずいたこと
- 考え方
DP = Dynamic Programming（動的計画法）とは
「大きな問題を、小さな問題に分けて、部分的な解を使い回しながら最終的な答えを求める」手法
### 1. `dp = [0] * (n+1)` の意味
- Pythonのリスト初期化の書き方  
  → 長さ `n+1` のリストを、すべて `0` にする
```python
dp = [0, 0, 0, 0, 0, ...]  # 長さn+1
```
### 2. `dp[i] = dp[i-1] + dp[i-2]` の意味
各段 i に来る方法は、以下の2通り：
- i-1 段目から1段登る
- i-2 段目から2段登る
```python
dp[i] = dp[i-1] + dp[i-2]
# これはフィボナッチ数列と同じ構造になる
```
### 3. `dp[0] = 1` がなぜ1なのか疑問だった
- 実際には「まだ何も登っていない状態」
- でもプログラム的には「登り方のスタートは1通りある」と定義することで、
他の段の計算がうまくできるようになる
- これは定義として「そう決めてる」と思ってOK！
---
## ✅ 実際のコード
```python
class Solution:
    def climbStairs(self, n: int) -> int:
        if n == 0 or n == 1:
            return 1

        dp = [0] * (n+1)
        dp[0] = dp[1] = 1

        for i in range(2, n+1):
            dp[i] = dp[i-1] + dp[i-2]
        return dp[n]
```
---
## 必要なアプローチは？
### 状態：何を求めたいのか？
→ dp[i] = i段目までの登り方の数
### 遷移：前の状態からどう移動するのか？
→ dp[i] = dp[i-1] + dp[i-2]
#### 状態と遷移よりDPを考える問題に引き落とすことが重要である
【勉強記録】アメリカのコーディング面接対策

# はじめに

こんにちは。アメリカに住みながら独学でエンジニアを目指しているTairaです。

アメリカでソフトウェアエンジニアになるために一番の山場がコーディング面接です。
コーディング面接とは問題を出されて、質問したりしながらコーディングするというものです。

本日は、コーディング面接対策として使えそうな書籍やサイトを紹介していきたいと思います。


## 1. LeetCode

**LeetCode**は、コーディング面接対策の実践に最も使われているサイトの一つです。

- 問題数は2000問以上
- 難易度はEasy、Medium、Hardの3段階
- 利用者コミュニティも活発
- 企業別によく出題される問題を検索可

前提知識も含めて自宅で自由に練習したい場合に最適です。

## 2. Cracking the Coding Interview

ゲイル・ラックさんが執筆した、面接対策書のバイブル的存在です。

- 基本のデータ構造、アルゴリズムの理論解説
- 問題数も多く、分野別にまとまっている
- 面接の流れやチームとの会話の指向も提示

上等企業の面接対策を精心に行いたい人に適しており、基礎力の強化に有用です。

## 3. AlgoExpert

**AlgoExpert**は、コーディング面接対策に特化した有料サービスで、解説動画の詳細さに対応あり、覚えやすさが特徴です。

- 問題数は約160問 (重要問題に範当)
- 「パターン別」の学習には向いていない
- 動画解説は実際の面接を想定した意思を感じられる
- モック面接機能も付属

覚えやすく、短期集中型の面接対策をしたい人に最適です。

## 4. AlgoMonster

**AlgoMonster**は、面接の「問題パターン」を体系的に解析しながら学べる有料サービスです。

- 問題数は300問以上
- パターン別の解説が優れている
- GoogleやAmazonなど、企業別の実際の出題傾向を可視化
- 動画はないが文章解説ステップごとなので分かりやすい

パターンの理解に基づき、広範囲な学習をしたい人に向いています。

---

## まとめ

自分の学習スタイルや現在のレベルによって最適なツールは異なりますが、簡単に分類すると以下の通りです。

| スタイル          | 最適なツール                        |
| ------------- | ----------------------------- |
| 理論を精心的に学びたい   | Cracking the Coding Interview |
| 体系的にパターンを覚えたい | AlgoMonster                   |
| 動画解説で覚えたい     | AlgoExpert                    |
| 問題数を解いて実践したい  | LeetCode                      |

相互使いも素晴らしい方法なので、最初は自分に合ったものを一つ選び、どんどん拡張していくのが良いでしょう。
PCからGalaxyにWiFiでADB接続（ペアリング）するときにつまずいた事

## 原因と結論
原因は手順が分かりませんでした。

１．ペア設定コードによるデバイスのペア設定を行う
```cmd:cmd
adb pair 192.168.40.67:45089
Enter pairing code: 〇〇〇
```

２．IPアドレスとポートに接続する
```cmd:cmd
adb pair 192.168.40.67:45089
Enter pairing code: 〇〇〇
```
※【重要】ポートはペア設定で用いたものと異なる ※
【手順メモ】Hugging FaceにSSHで接続してGitでモデルをPushする方法

# Hugging Face HubにモデルをSSHでPushする手順メモ

以下の公式ドキュメントに詳しい手順が書かれていますが、自分用に簡潔にまとめたメモです。

https://huggingface.co/docs/hub/repositories-getting-started#set-up

## 1. 公開鍵の生成と登録

まずはHugging FaceにSSHで接続するための鍵を作成します。

```bash
$ cd ~/.ssh
$ ssh-keygen
Enter file in which to save the key (/Users/username/.ssh/id_rsa): id_hf_git
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
```

公開鍵が id_hf_git.pub に生成されます。以下のコマンドでクリップボードにコピーします。

```
$ pbcopy < id_hf_git.pub
```

次に、以下のリンクにアクセスして「Add SSH Key」から先ほどコピーした公開鍵を貼り付けます：

https://huggingface.co/settings/keys


## 2. SSH Configの設定

SSH経由でHugging Faceに接続できるよう、~/.ssh/config を設定します。

```bash
$ vim ~/.ssh/config
```

以下の内容を追加：

```bash
Host hf.co
  User <huggingface_username>
  IdentityFile ~/.ssh/id_hf_git
  IdentitiesOnly yes
  AddKeysToAgent yes
```




## 3. レポジトリの作成とモデルのPush

### レポジトリの作成

以下のリンクから新しいリポジトリを作成します：

https://huggingface.co/new

### モデルのPush手順

Hugging Faceのリポジトリには、デフォルトで main ブランチに .gitattributes が含まれているため、最初に fetch しておくとスムーズです。また、大きなファイルの管理のために git lfs を使用します。

```bash
$ cd <path to your model>
$ git init
$ git remote add origin git@hf.co:huggingface_username/repo_name
$ git fetch origin main 
$ git checkout main
$ git lfs install
$ huggingface-cli lfs-enable-largefiles . #In case any file is bigger than 5GB
$ git add .
$ git commit -m "initial commit"
$ git push -u origin main
```
AWS重要知識(AWS-SAA,SAP対策) 　〜Lambda編〜

# 目的
AWSのサーバレス型関数実行サービスのLambdaを理解する(AWSSAP対策も兼ねて)

# LambdaのSLA
LambdaのSLAは下記ドキュメント参照
https://d1.awsstatic.com/legal/lambda-sla/AWS%20Lambda%20SLA_2022-05-05_JP.pdf


# Lambdaのクォータ制限
⚫︎Lambdaのクォータ制限は下記ドキュメントに記載
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/gettingstarted-limits.html

・同時実行数
・最大実行時間
・最大使用メモリ
それぞれを見ていく。


## Lambdaの同時実行数上限
重要度⭐️⭐️⭐️⭐️⭐️⭐️⭐️

・Lambdaの同時実行数はAWSアカウント全体で1リージョンで1000が上限

### Lambdaのスロットリング

:::note
スロットリング
システムやサービスが過負荷になるのを防ぐために、意図的にリクエストの処理量を制限する仕組みのこと。
:::

⚫︎Lambdaのメトリクスに関するドキュメント
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/monitoring-metrics-types.html
>Throttles - スロットリングされた呼び出しリクエストの数。すべての関数インスタンスがリクエストを処理していて、スケールアップできる同時実行がない場合、Lambda は TooManyRequestsException エラーを出して追加のリクエストを拒否します。スロットリングされたリクエストやその他の呼び出しエラーは、Invocations または Errors のいずれかとしてカウントされません。

:::note warn
Lambdaの同時実行数に達すると
429 (TooManyRequestsException エラー)
が返却される
:::


### 同時実行数の監視
CloudWatchの「ConcurrentExecutions」で同時実行数のメトリクス取得可能

⚫︎Lambdaの同時実行数に関するドキュメント
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/monitoring-concurrency.html

>Lambda 関数の同時実行のモニタリングには、以下のメトリクスを使用します。各メトリクスの詳細度は 1 分です。
ConcurrentExecutions - 特定時点のアクティブな同時実行呼び出し数。Lambda は、このメトリクスをすべての関数、バージョン、エイリアスに対して出力します。Lambda コンソールのどの関数であっても、Lambda は [モニタリング] タブの [メトリクス] に ConcurrentExecutions のグラフをネイティブに表示します。MAX を使用してこのメトリクスを表示します。

上のスロットリングのメトリクスでアラート設定しても既に手遅れなので、アラート設定はこっちのメトリクスの方が良い。


## Lambdaの同時実行時間

900秒(15分)


## Lambdaのメモリ上限

128 MB から 10,240 MB(10GB)まで1MB単位で設定。
使ってないメモリも課金対象になるので適切に指定する。


# Lambda Insight
重要度⭐️⭐️⭐️⭐️⭐️

LambdaをCloudWatchで監視する時に注意すべきなのが、Lambda Insightを有効化しないと取得できないメトリクスが結構ある

⚫︎Lambda Insightに関するドキュメント
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Lambda-Insights-metrics.html

特にメモリ、CPUに関するメトリクスはこの機能をオンにしないと取得できない。

# Lambdaのカナリアリリース
:::note
カナリア(Canary)リリースとは？
新しいシステムやコードの変更を段階的に本番環境へ導入するリリース方針
:::

Lambdaにはデプロイごとにバージョンを付与することができますが、それぞれのバージョンにweightを付与できる。

version2 : 90%
version3 : 10%
のようにすると呼び出しもこの割合で行われる。
段階的に本番環境に移行することができるので既存環境への影響などを小さくでk。



# リザーブド同時実行数
重要度⭐️⭐️

特定のLambda関数に最大同時実行数を割り当ててその実行数を保証する

⚫︎リザーブド同時実行に関するドキュメント
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-concurrency.html


# プロビジョンドコンカレンシー
重要度⭐️⭐️
Lambda関数のコールドスタートを回避するため、「常に稼働するインスタンス数」を指定
pv (Pipe Viewer) を Universal Binary としてビルドする

前記事で、[Pipe Viewer](https://www.ivarch.com/programs/pv.shtml)（`pv`コマンド）を利用しました。

https://qiita.com/doraTeX/items/c6367ba636f4cc077a00

ここで、普通に `pv` コマンドをインストールすると、インストールされた `pv` バイナリは、

* そのホストマシンのCPUと同じCPUアーキテクチャ用 (`x86_64` or `arm64`)
* 動作するOSバージョンはそのホストマシンの macOS バージョン以降

となってしまいます。

ビルドされる `pv` バイナリが、できるだけ広範な環境で動くようにするには、Universal Binary としてビルドし、また動作OSバージョンを低めに設定するのが望ましいでしょう。

そのために、次のようなシェルスクリプトを用意するとよいでしょう。

```bash
#!/bin/bash

set -eux

PV_VERSION="1.9.31"
PV_URL="https://www.ivarch.com/programs/sources/pv-${PV_VERSION}.tar.gz"

ORIGDIR="$(pwd)"
WORKDIR="${ORIGDIR}/pv_build"
mkdir -p "${WORKDIR}"
cd "${WORKDIR}"

curl -fL -o "pv-${PV_VERSION}.tar.gz" "${PV_URL}"
tar xzf "pv-${PV_VERSION}.tar.gz"
cd "pv-${PV_VERSION}"

# Apple Clang を明示指定
export CC="/usr/bin/clang"
export CXX="/usr/bin/clang++"
export LD="/usr/bin/clang"

# macOS 10.13 以降(Intel) / macOS 11 以降(Apple Silicon) 対応で Universal build をビルド
export MACOSX_DEPLOYMENT_TARGET="10.13"
export CFLAGS="-arch x86_64 -arch arm64 -mmacosx-version-min=${MACOSX_DEPLOYMENT_TARGET} -Wno-implicit-function-declaration"
export LDFLAGS="-arch x86_64 -arch arm64 -mmacosx-version-min=${MACOSX_DEPLOYMENT_TARGET}"

./configure --prefix="${WORKDIR}/pv_inst" --disable-dependency-tracking
make -j4
make install

cp -p "${WORKDIR}/pv_inst/bin/pv" "${ORIGDIR}"

echo "=== Build completed! ==="
lipo -info "${ORIGDIR}/pv"
```

`-arch x86_64 -arch arm64` で Universal Binary の生成を指定し、`-mmacosx-version-min=10.13` で動作OS要件を指定します。（Apple Silicon 対応のOSは最低でも macOS 11.0 Big Sur なので、`arm64` バイナリでは 10.13 を指定しても 11.0 となります。）

これらのオプションに対応させるために、コンパイラ・リンカには Apple Clang を明示指定する必要があります。（Homebrew や MacPorts で GCC がインストールされていると、デフォルトではその GCC が呼び出されてしまう可能性があります。）それが `CC`, `CXX`, `LD` の指定の部分です。

このスクリプトを実行すると、カレントディレクトリに Universal Binary の `pv` コマンドが生成されているはずです。
rex0220 計算式プラグイン 組織情報をテーブルへセット

[rex0220 計算式プラグイン](https://qiita.com/rex0220/items/ae83c6d5ce50ff7a9a73)で、組織情報をテーブルへセットしてみます。

# 概要

組織選択項目で選択された組織のID,コード,組織名をテーブルにセットします。

![2025-04-10_10h51_21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/fb2bf171-7451-45aa-a97b-1ac46adc6b91.png)

# 計算式プラグイン設定

OINFO 関数を利用する場合は、「ユーザー情報」をチェックします。

![2025-04-10_10h53_36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/100572/62a39679-b963-4d12-ae2e-5d809f0c4bf8.png)

```JavaScript:
OPTION: ユーザー情報

// 所属する組織 SUBTABLE
TABLE_DATA( // テーブル作成
  ARRAY_MAP(OINFO(SEL_CODE(組織選択,"array"),"id,code,name"),x,
    LET(w, SPLIT(x,","), // カンマ分割
      DIC(
        "組織ID", ARRAY_GET(w,0), // ID取得
        "組織コード", ARRAY_GET(w,1), // コード取得
        "組織名", ARRAY_GET(w,2) // 名称取得
      )
    )
  )
)

// 所属する組織.組織ID SINGLE_LINE_TEXT
// 所属する組織.組織コード SINGLE_LINE_TEXT
// 所属する組織.組織名 SINGLE_LINE_TEXT
```

## SEL_CODE の実行例

SEL_CODE(組織選択,"array") -> ["総務部","sales","dev"]

## OINFO の実行例

OINFO(SEL_CODE(組織選択,"array"),"id,code,name") -> ["3,総務部,総務部","1,sales,営業部","2,dev,開発部"]

## SPLIT の実行例

SPLIT("1,sales,営業部", ",") -> ["1","sales","営業部"]
【簿記3級】勘定科目一覧（純資産の部）

## はじめに
　簿記3級出題範囲の勘定科目一覧（純資産の部）についてまとめてみました。

## 純資産の部

### 資本金
　株主が会社へ提供した資金。会社が設立時に所有しているお金。

### 利益準備金
　企業が稼いだ利益のうち、法律で積み立てることが義務付けられている利益。

### 繰越利益剰余金
　企業が稼いだ利益のうち、来期に持ち越す利益。
 

## おわりに
ここまで読んでいただきありがとうございます！

## 参考文献
・アプリケーション
簿記3級  解説付き問題集 - 仕訳入門や学習法も充実 TRIPS LLC
勘定科目一覧　３．純資産の部
【簿記3級】勘定科目一覧（負債の部）

## はじめに
　簿記3級出題範囲の勘定科目一覧（負債の部）についてまとめてみました。

## 負債の部

### 支払手形
　代金として約束手形を渡し、期日に手形分のお金を支払う義務。

### 買掛金
　商品を掛けで買った時に、後で代金を支払う義務。

### 前受金
　手付金、内金など、商品販売時に、先に受け取るお金。後に商品を引き渡す義務。

### 借入金
　企業や銀行などから期限や利子を決めて借りたお金。後にお金を支払う義務。

### 未払金
　商品以外の物や、サービスを後払いで取得した時に、後で代金を支払う義務。

### 仮受消費税
　商品の売却時に受け取った消費税。後に消費税を納付する義務。

### 未払消費税
　仮受消費税と仮払消費税の差額で、後に消費税を納付する義務。

### 未払法人税等
　法人税等と仮払法人税等の差額で、後に法人税等を納付する義務。

### 未払配当金
　株主総会などで、支払う決議がなされたが、まだ支払われていない配当金。後にお金を支払う義務。

### 電子記録債務
　商品を掛けで買った時に、その取引の内容を電子化したもの。後に代金を支払う義務。

### 役員借入金
　自社の役員から借り入れているお金。後にお金を支払う義務。

### 当座借越
　当座預金の残高が足りない時、銀行が一時的に立て替えてくれるお金。後にお金を支払う義務。

### 仮受金
　金銭等の受け入れがあったが、取引内容がわからないお金。後に本来の勘定科目に振り替える為の一時的な負債。

### 未払利息
　当期の利息のうち、来期に支払い予定の利息。未払がついている科目は、「後で支払う必要がある」ことを意味するので、負債。

### 未払給料
　当期の給料のうち、来期に支払い予定の給料。未払がついている科目は、「後で支払う必要がある」ことを意味するので、負債。

### 未払家賃
　当期の家賃のうち、来期に支払い予定の家賃。未払がついている科目は、「後で支払う必要がある」ことを意味するので、負債。

### 未払地代
　当期の地代のうち、来期に支払い予定の地代。未払がついている科目は、「後で支払う必要がある」ことを意味するので、負債。

### 未払費用
　当期の費用のうち、来期に支払い予定の費用。未払がついている科目は、「後で支払う必要がある」ことを意味するので、負債。

### 前受利息
　来期の利息のうち、当期に受取済みの利息。前受がついている科目は、「後でサービスを提供する必要がある」ことを意味するので、負債。

### 前受手数料
　来期の手数料のうち、当期に受取済みの手数料。前受がついている科目は、「後でサービスを提供する必要がある」ことを意味するので、負債。

### 前受家賃
　来期の家賃のうち、当期に受取済みの家賃。前受がついている科目は、「後でサービスを提供する必要がある」ことを意味するので、負債。

### 前受地代
　来期の地代のうち、当期に受取済みの地代。前受がついている科目は、「後でサービスを提供する必要がある」ことを意味するので、負債。

### 前受収益
　来期の収益のうち、当期に受取済みの収益。前受がついている科目は、「後でサービスを提供する必要がある」ことを意味するので、負債。

### 預り金
　取引先や従業員などから、一時的に預かっているお金。後に返金ないし他者へ支払う義務。

### 手形借入金
　借用証書の代わりに、約束手形を渡し借り入れたお金。後にお金を支払う義務。

### 社会保険料預り金
　従業員の給料から源泉徴収として差し引かれた社会保険料。後に納付する義務。

### 所得税預り金
　従業員の給料から源泉徴収として差し引かれた所得税。後に納付する義務。

### 未払水道光熱費
　当期の水道光熱費のうち、来期に支払い予定の水道光熱費。未払がついている科目は、「後で支払う必要がある」ことを意味するので、負債。
 

## おわりに
ここまで読んでいただきありがとうございます！

## 参考文献
・アプリケーション
簿記3級  解説付き問題集 - 仕訳入門や学習法も充実 TRIPS LLC
勘定科目一覧　．負債の部
シェルソートの実装(Java)

※主に自分の備忘のための記事です。
　Javaによるシェルソートの実装例を以下に記載します。
　初学者が自力で書いたので拙いです。今後改善する予定です。

```java
public static void main(String[] args) {

    Scanner scanner = new Scanner(System.in);
    
    //数字の数を設定
    int numberCount = Integer.parseInt(scanner.next());
    
    //未整列の数字一覧を受け取る
    int[] numbers = new int[numberCount];
    for(int i = 0; i < numberCount; i++) {
        numbers[i] = Integer.parseInt(scanner.next());
    }
    
    //シェルソートを行う際の間隔値を設定する・・・①
    int intervalCount = Integer.parseInt(scanner.next());
    int[] intervals = new int[intervalCount];
    for(int i = 0; i < intervalCount; i++) {
        intervals[i] = Integer.parseInt(scanner.next());
    }
    
    //①の間隔値に従いシェルソート実行
    for(int i = 0; i < intervalCount; i++) {
        for(int j = 0; j < intervals[i]; j++) {
            if(j + intervals[i] > numberCount - 1) {
                break;
            }
            
            for(int k = 0; k < (numberCount - j - 1) / intervals[i]; k++) {
                
                for(int l = k + 1; l - 1 >= 0; l--) {
                    int former = j + intervals[i] * (l - 1);
                    int later  = j + intervals[i] * l;
                    
                    if(numbers[former] > numbers[later]) {
                        int tempNum = numbers[former];
                        numbers[former] = numbers[later];
                        numbers[later] = tempNum;
                        
                    //↓ここ大事！既に並び替えが完了している場合にスキップを行っている
                    } else {
                        break;
                    }
                }
            }
        }
    }
    
    for(int num : numbers) {
        System.out.println(num);
    }
    
}
```
IG22についてるエンコーダーを使う


## まえがき
部にあったこれ↓についてるエンコーダーを使ってみようと思ったのですが、探し方が悪いのか誰も使ってなかったのでメモ
https://akizukidenshi.com/catalog/g/g112919/
(Qiita書くの初めてなので読みにくかったらごめんです)

### データシート
https://akizukidenshi.com/goodsaffix/magnetic-encoders.pdf



## つかったもの
mega 2560 pro
IG22とそのエンコーダー


## 接続
| IG22 | mega 2560 pro |
|--:|:--|
| モーター+ | なし |
| モーター- | なし |
| VCC | 5V |
| GND | GND |
| センサーA | A5 |
| センサーB | A7 |

(モーター+-は手で回すのでつかわないです)


## まず書いたもの
``` C
void setup() {
  pinMode(A5, INPUT);
  pinMode(A7, INPUT);
  Serial.begin(115200);
}
void loop() {
  Serial.print(analogRead(A5));
  Serial.print(", ");
  Serial.println(analogRead(A7));
}

```
こんな感じで書いてモーターを回すと、↓みたいな感じの波形が見られると思います


![ss.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3871379/313be74f-ed85-4930-9cfc-c66e6102f4e7.png)
![ss.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3871379/5f543efb-e616-4e8c-8c57-099df26882c7.png)
<font color="gray">(上下で回転方向は逆)

そして、これを元に
片方がHIGH/LOWになったときのもう片方の値を読むことで、回転方向を読むことができます(2つのXORが1なら正転、0なら逆転みたいな感じ)


## 最終的なコード
``` C
int counter = 0; //モーターの回転数
int lasta;

void setup() {
  pinMode(A5, INPUT);
  pinMode(A7, INPUT);
  Serial.begin(115200);
  lasta = digitalRead(A5);
}
int a,b;
void loop() {
  a = digitalRead(A5);
  if(lasta!=a){
    b = digitalRead(A7);
    if(a ^ b) counter++;
    else counter--;
  }
  lasta = a;
  Serial.println(counter);
}
```


![mov.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3871379/4b681453-1757-4222-ac00-a142d8812807.gif)
わかりにくいですが、モーターを回すと値が上下してます


---
ここまでできれば、あとは1回転でなんcm進むかみたいなことを調べればいろいろできます！お疲れさまでした！！
Git clone が突然 503!? 原因は no_proxy の書き方ミスだった

## はじめに

社内ネットワーク内にあるオンプレミスの GitLab を使って開発している環境で、突然 `git clone` も `git push` もできなくなりました

社内のブラウザでは普通にGitLabの画面が開けるのに、ターミナルでは謎の `503` エラー

原因を調査していった結果、意外なところに落とし穴がありました

社内プロキシを経由している環境では、同じようなトラブルに遭遇する可能性があるので、備忘録として残しておきます

---

## 発生したエラー

```bash
$ git clone http://<社内GitLabのホスト>/your-group/your-repo.git
Cloning into 'your-repo'...
fatal: unable to access 'http://<社内GitLabのホスト>/your-group/your-repo.git/': The requested URL returned error: 503
```

- **ブラウザからは GitLab にアクセス可能**
- **curl でも `.git` にアクセス可能**

```bash
$ curl -I http://<社内GitLabのホスト>/your-group/your-repo.git
HTTP/1.1 200 OK
...
```

GitLab自体は動いているのに、Git コマンドだけが通らないという状況でした

---

## 原因：`no_proxy` の書き方ミス

環境変数 `no_proxy` を次のように設定していたのが原因でした

```bash
export no_proxy='http://<社内GitLabのホスト>'  # ← 間違い
```

`no_proxy` は **ドメイン名またはIPアドレス** だけを指定する必要があります
`http://` のようなスキームを含めてしまうと、Gitはこれを無視して proxy を通してしまいます

つまり、Git だけが proxy 経由でアクセスし、結果として `503` を返されていたようです

---

## 正しい設定方法

以下のようにスキームを除いて設定する必要があります

```bash
export no_proxy='<社内GitLabのホスト>'  # ← 正しい
```

複数ドメインがある場合はカンマ区切りで指定します：

```bash
export no_proxy='localhost,127.0.0.1,<社内GitLabのホスト>'
```

---

## 解決までに試したこと

- `curl -I` → 通信OK（GitLabは落ちていない）
- `git config --global http.version HTTP/1.1` → 効果なし
- `GIT_CURL_VERBOSE=1 git clone ...` で通信ログ確認
- Proxy設定の確認・解除
- SSH経由での clone も検討（今回はそこまでせず原因に気づいた）

---

## 学んだこと

- `no_proxy` の書式ミスでも Git は `503` を返す（しかも原因がわかりにくい）
- Git の clone/push で謎の 503 エラーが出たら、proxy 設定を疑う
- `curl` やブラウザで通っても、Git の HTTP 通信は挙動が異なることがある

---

## おわりに

今回のように、ちょっとした設定ミスが思わぬ落とし穴になります

もし同じように「GitLabにアクセスできるのに clone できない」というトラブルに遭遇した方の参考になれば、、

改めて思い返せば、そういや昨日、`~/.bashrc`編集したな～、、それが原因なのは明白じゃん、、と反省しました

自分の行動を振り返ったほうがデバックは早いかもしれません

---

## 参考リンク
- [no_proxyの書き方 サブドメインは含まれるか](https://zenn.dev/dannykitadani/articles/824ebd43548343)
[Linux][command] エディタ_vi, Vim, Emacs, nano

# 主なエディタ
| エディタ | 説明 |
|:--|:--|
| vi | UNIX伝統のテキストエディタ<br>- キーボード操作が中心<br>- モード（ノーマル・挿入など）を使い分ける |
| Vim | viから派生した高機能なテキストエディタ<br>- 基本的な操作方法はviと同じ<br>- GUI<br>- 現在はviに代わりLinux標準 |
| Emacs | テキスト編集、コーディング、デバッグ、他プログラムの操作など開発環境として便利な機能を備えた高機能エディタ<br>- ユーザ独自の拡張機能をカスタマイズ<br>- GUI |
| nano | GUIをサポートしていない軽量の端末エディタ<br>- 操作キーとそれに対応する機能が画面下部に表示 |


# Ping-t
- [3364_Emacs](https://mondai.ping-t.com/question_subjects/31/question_sessions/32311097/progressing_questions/495045366)
- [3365_nano](https://mondai.ping-t.com/question_subjects/31/question_sessions/31869840/progressing_questions/488361809)
Webhookによる自動デプロイを構築してわかったセキュリティ設計の重要性

## はじめに


今回は、GitHub Webhookを使った自動デプロイの構成を作っていく中で、

- なぜ `www-data` に `git pull` させてはいけないのか？
- `deploy` ユーザーを作る意味とは？
- `sudoers` は何のためにあるのか？

といった「ユーザーと権限設計」に関する疑問を通じて、  
**セキュリティ設計の視点を持つことの重要性**に改めて気づかされました。

---

## きっかけ：Webhookで自動デプロイしたい

開発したWebアプリを AWS + Ubuntu + Nginx で公開する際に、

> ローカルで `git push` したら、自動で本番環境が更新されるようにしたい

と考え、Webhookを使った自動デプロイを構築しました。

構成は以下の通りです。

```
ローカルで git push
　　↓
GitHub → Webhook 送信
　　↓
EC2サーバーの PHP（www-data）が受信
　　↓
PHP が git pull を実行してコードを更新
```

---

## 最初のつまずき：PHPから `git pull` できない

`shell_exec("git pull")` をPHPで実行してみたところ、次のようなエラーが発生。

```
fatal: cannot open .git/FETCH_HEAD: Permission denied
```

`.git` にアクセスできないという問題です。

---

## 原因：PHPは `www-data` ユーザーで動作している

PHPは `www-data` ユーザーで実行されるため、`.git` にアクセスするには書き込み権限が必要になります。

しかし、`www-data` に `.git` を触らせるのは、セキュリティ上非常に危険。理由は、www-data は Webサーバー（nginxやApache）やPHPの実行ユーザーであり、インターネットからのリクエストに直接応答する存在。間接的に.gitを操作されてしまう危険性があるため。たとえば、PHPに脆弱性（コマンドインジェクションなど）があれば、リクエスト経由で .git を操作される可能性があるため、Web経由で触れられるユーザーには .git の権限を与えるべきではない。

---

## 解決策：ユーザーを役割ごとに分離する

以下のように、ユーザーごとに役割を明確に分ける構成に変更した。

| ユーザー | 役割 |
| --- | --- |
| `ubuntu` | サーバー構成・管理（管理者） |
| `deploy` | デプロイ専用（git pull のみ許可） |
| `www-data` | Webサーバーとしてリクエストを受ける |

`www-data` は、ただWebhookを受け取るだけの中継役とし、Gitの操作はすべて `deploy` ユーザーが行うようにした。

---

## sudoers設定で、必要最小限のコマンドだけ許可

`www-data` が `deploy` として `git pull` を実行するには、sudo設定を変更する必要がある。それはsudo権限はubuntu以外のユーザーは持っていないから。

```bash
sudo visudo
```

以下の設定を追記します。

```bash
www-data ALL=(deploy) NOPASSWD: /usr/bin/git -C /var/www/project-textSnippetSharingService/public/Text-Snippet-Sharing-Service pull
```

これにより、`www-data` はこのコマンド1つだけを、パスワードなしで `deploy` として実行可能になる。

---

## PHPのコード例（署名検証付き）

```php
$secret = Settings::env(DEPLOY_KEY);
$githubSignature = $_SERVER['HTTP_X_HUB_SIGNATURE_256'] ?? '';
$payload = file_get_contents('php://input');
$calculatedSignature = 'sha256=' . hash_hmac('sha256', $payload, $secret);

if (!hash_equals($calculatedSignature, $githubSignature)) {
    http_response_code(403);
    exit('Invalid signature');
}

$command = 'sudo -u deploy /usr/bin/git -C /var/www/{project-path} pull 2>&1';
$output = shell_exec($command);
file_put_contents('log.txt', $output, FILE_APPEND);
```

---

## 学び：最初からユーザーを分けて設計すべきだった

当初は安易に `www-data` に `git pull` させようとした結果、

- 所有権やパーミッションの問題
- sudoの制限
- Web経由でのセキュリティリスク

といった課題に直面した。

最初から `ubuntu` / `deploy` / `www-data` の役割を分けて設計しておけば、トラブルを避けられたと痛感した。

---

## 補足：Recursion共同創業者 ジェフリーさんからのアドバイス

Recursionコミュニティで設計について相談した際、元Metaエンジニアのジェフリーさんから次のアドバイスをいただいた。

- GitHubからのリクエストは **必ず署名を検証する**
- shellコマンドは **リテラル文字列に限定** し、ユーザー入力や動的な値を含めない
- cronやフレームワークのschedulerで **別プロセスとして実行** する方法も有効

---

## まとめ

| 課題 | 解決策 |
| --- | --- |
| `.git` にアクセスできない | 所有者を `deploy` にして、`www-data` からは触らせない |
| `www-data` に `git pull` させたい | sudoersに対象コマンドのみ許可する設定を追加 |
| セキュリティ面が不安 | ユーザー分離、署名検証、静的コマンド指定で対策 |
Toolchain Manager廃止

# いきなりステーキ、ならぬ廃止
ちょっと前まで3.0.0-rc1を提供していたかと思ったら何やら表示が変わっている……。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3797041/010f5619-62de-4d81-b909-3b729c0027d7.png)
しかも表示が黄色で何やら警告を発しているようだ……なになに、Deprecatedだって？
どうもToolchain Managerは廃止されるようです。確かに開発はVSCode上でやっているのに、そのためのSDKは違うアプリケーションからインストールしないといけないってのは手数が多くてやりにくいです。
まあ正当な進化のような気がします。
# ところで
ちょっと前までダウンロードできていた3.0.0-rc1はどこに行ったんでしょうか……僕は手元にありますけど……。
Next.jsでのマイクロフロントエンドアーキテクチャー構築

## はじめに
今回Nxで構築していたプロジェクトをVercel純正のモノレポツールであるTurborepoに移行することになったので、その際詰まったことなどを記載します。始めて書く記事なのでわかりにくいなどあれば教えていただけると幸いです。

## こんな人におすすめ
+ Next.jsでマイクロフロントエンドを築したい人
+ Turborepoを使ってみたい人
+ WEBプロジェクトをモノレポで構築したい人
+ でも、Nxは微妙だと思った人（筆者）

## マイクロフロントエンドとは

マイクロフロントエンドは、フロントエンドを複数の独立したアプリケーションに分割し、それぞれが独立して開発・デプロイ可能なアーキテクチャ。大規模開発や複数チーム開発に適した構成。（GPTより）

要するに、アプリを小単位に分割して管理・構築しようね、ってやつです。

マイクロフロントエンドは昨今のWEB開発に必要不可欠な技術です。
フロントエンド技術は日々進歩し、それに伴ってコードも複雑化・肥大化しています。
それに加えて、巨大なアプリ構築ではライブラリ競合などが発生しやすくなり、管理が面倒です。

マイクロフロントエンドはそういった問題を解決してくれます。

複数アプリに分割したアプリを管理しやすくするのがTurborepoやNX等のモノレポツールです。

今回はマイクロフロントエンドを意識したモノレポをTurborepoで構築する方法について書きます。

## プロジェクト作成
については他に詳しい記事があるのでここでの記載は割愛します。
https://zenn.dev/hayato94087/articles/d2956e662202a7

## アプリ間の遷移
マイクロフロントエンドでは複数アプリを別々のアプリとして構築することでそれぞれの独自性を保っています。しかし実際にそれぞれのアプリとしてホスティングはせず、あくまで一つのアプリとしてルーティングさせたいです。

```shell
/apps
  /host      ← ホスト兼統合プロキシ
  /app1
  /app2
  ```

その場合、next.config.tsをそれぞれ以外のようにします。

host
```ts
module.exports = {
  async rewrites() {
    return [
      {
        source: '/app1/:path*',
        destination: 'http://localhost:3001/app1/:path*',
      },
      {
        source: '/app2/:path*',
        destination: 'http://localhost:3002/app2/:path*',
      },
    ];
  },
};
```

app1（app2も同様に）
```
const isProd = true; // ← devでもtrueに固定しておく

module.exports = {
  basePath: '/app1',
  assetPrefix: '/app1',
  trailingSlash: true,
};
```
これでhostのリンクをベースパスとしてルーティングするようになります
すなわち、http://localhost:3000/app1にアクセスするとlocalhost:3001/のページが表示されるわけです。

## 問題点
しかし上記のようにホストアプリからの読み込みという形にすると、本来なら各アプリへの直接遷移という形で読み込まれるはずの静的コンテンツが読み込まれなくなります。
そうなるとtailwindcssが適用されません。

そこで、ルートのpackage.jsonに以下を記載することで、ローカルプロキシとして動作するので、直接アクセスと同じ挙動にできます。

```json
"scripts": {
  "dev:proxy": "turbo run dev --filter=proxy-host",
  "dev:app1": "next dev apps/app1 -p 3001",
  "dev:app2": "next dev apps/app2 -p 3002",
  "dev:all": "concurrently \"yarn dev:app1\" \"yarn dev:app2\" \"yarn dev:proxy\""
}
```

あとはホスティング時にVercelなどでプロキシによるルーティングを設定すれば完成です。

## まとめ
今回はモノレポでマイクロフロントエンドを構築する方法を書いてみました。参考になれば幸いです。
【PHP】$_POSTを扱いやすくする妄想設計

# 妄想設計とは

妄想設計とは実装はしたことないが、こんな設計良さそう、という妄想の結果の設計である。
もちろん実用性などはない（キリ）。

## $_POST の値

APIを書いていると$_POSTからデータを取ってくることがある。

```php:
$age = $_POST['age'];
```

だが、$_POSTに入っているデータはユーザーからの投稿データであり、基本的にデータは信用できない。
そのため、サニタイズやバリデーションが必要になる。
上記のageだったらサニタイズは

```php:
$age = intval($age);
if ($age === 0) {
    // 0歳児はサポート外
    throw new \Exception('invalid age value');
}
```

で可能だが、これをさっきのコードに書くと

```php:
$age = $_POST['age'];
$age = intval($age);
if ($age === 0) {
    // 0歳児はサポート外
    throw new \Exception('invalid age value');
}
```

となるわけだが、ageだけでなくweightも必要だとすると、

```php:
$age = $_POST['age'];
$age = intval($age);
if ($age === 0) {
    throw new \Exception('invalid age value');
}

$weight = $_POST['age'];
$weight = intval($age);
if ($weight === 0) {
    throw new \Exception('invalid weight value');
}
```

こんな感じでダラダラと書くことになってしまう。
はー、ダラダラするのは開発者だけでいいんですよ。コードはキリっとしてないとダメです。

## APIごとにデータを検証するクラスを書く。

フレームワークなどはモデルというクラスがあって、そのモデルでデータを検証したりする。
フレームワークを使う場合は投稿データはモデルに突っ込んでデータ検証すればいい。
だが、なにも$_POSTのデータはすべてモデルに入れてデータベースに保存するわけではない。
保存しないデータもあるが、それももちろん検証と無害化はしないといけない。

よってAPIごとに$_POSTのデータを包むクラスを書くという妄想をする。

### PostPersonData

```php:
class PostPersonData {
    function __construct($ary) {
        $this->age = $ary['age'];
        $this->weight = $ary['weight'];
    }

    function sunitize() {
        $this->age = intval($this->age);
        $this->weight = intval($this->weight);
    }

    function validate() {
        if ($this->age <= 0 || $this->age >= 200) {
            throw new \Exception('invalid age');
        }
        if ($this->weight <= 0 || $this->weight >= 500) {
            throw new \Exception('invalid weight');
        }
    }
}
```

こんなクラスをAPIのURLごとに用意する。
するとさきほどのコードは以下のように書くことができる。

```php:
$data = new PostPersonData($_POST);
$data->sunitize();

try {
    $data->validate();
} catch (\Exception $e) {
    die($e->getMessage());
}

```

うーん、エレガント！すき！だいしゅき！

フレームワークを使っていてモデルへデータを変換する場合は以下のようなメソッドも定義できるだろう。

```php:
$person = $data->to_model();
$person->save();
```

だが、データのバリデーションはモデルにも書くし、そうすると二度手間になる。
モデルにデータの検証を書いているのに、$_POSTのクラスにも検証方法を書かないといけないのかい！　となる。たしかに～。

## おわりに

今日の妄想はここまでとする。
妄想を現実にして実装する日は近い。かもしれない。
🧠 生成AI時代に求められるソフトスキルについて考える  

### ― AIに「聞ける人」ではなく、「問える人」になる ―

---

## ✅ 想定読者

- 生成AIを業務で使っているが、思うような成果が得られない
- プロンプト力以外に“何が必要なのか”知りたい
- ソフトスキルという曖昧な言葉を構造的に理解したいエンジニア

---

## 🧭 生成AIでは測れない能力がある

生成AI、特にChatGPTなどの大規模言語モデル（LLM）が登場して以降、多くの業務が自動化の波にさらされています。  
コードの自動生成、要件定義の補助、ドキュメント整備…。それらの作業は今やAIが「ある程度」こなせる時代になりました。

では、人間はどこに価値を発揮すればよいのか？

結論から言えば、**「意味を問う力」＝高度なソフトスキル**こそが、今後の技術者に求められる最重要スキルです。  
これは単なるコミュニケーション能力ではありません。  
**ソフトスキル＝構造化された“意味編集”の能力**と見なす必要があるのです。

---

## 🔍 ソフトスキルを構造的に分解する

---

### STEP01：AIと人間の役割は根本的に異なる

まず、AIと人間のスキル分担を整理してみましょう。

```mermaid
flowchart LR
    subgraph AI側
        A1[入力されたデータを解析]
        A2[最適そうな答えを生成]
    end
    subgraph 人間側
        H1[目的の定義]
        H2[背景・制約の理解]
        H3[問いの設計]
        H4[意味の補正・修正]
    end
    H1 --> H2 --> H3 --> A1
    A2 --> H4
```

- **AIは「答えを生成」する能力に特化**
- **人間は「問いを設計し、意味を解釈」する立場**

つまり、AIが優れているのは「言語生成能力」であり、**「意味の設計」は依然として人間にしかできません**。

---

### STEP02：ソフトスキル = Semantic Engineering

ここで、「ソフトスキル＝意味操作力（Semantic Engineering）」という視点を導入しましょう。  
これは単に“柔らかいスキル”ではなく、 **「情報の意味構造を操作するスキル」** です。

| 一般的ソフトスキル | Semantic Engineeringとして再定義 | 技術的応用例 |
|------------------|------------------------------------|----------------|
| 傾聴力 | 背景文脈の正確な抽出力 | 要件定義プロンプトの文脈把握 |
| 説明力 | 意味の圧縮と展開力 | API仕様の階層的整理 |
| 共感力 | 他者モデルの内面シミュレーション | UX設計・ペルソナ定義 |

これらは従来の「人当たりの良さ」ではなく、**抽象化・再構成・翻訳の能力**とみなすことで、技術スキルと直結します。

---

### STEP03：自動化の先に残るものは「意味」だけ

生成AIが奪うのは、実はスキルそのものではありません。  
**“手続き的な操作”の自動化**です。

```mermaid
graph TD
    A[手順的スキル] -->|自動化| B[生成AIによる代替]
    B --> C[意味の設計・判断・意図化]
```

例えば以下のように考えてみてください：

- LLMはコードを生成できる  
　→ しかし **「なぜこの仕様か？」** は説明できない  
- LLMは文章を要約できる  
　→ しかし **「どの読者に向けるか？」** の判断はできない  

ここに、**人間がAIに“問う”ためのスキルセット＝ソフトスキルのコア領域**が存在します。

---

### STEP04：3層構造で理解するソフトスキルの本質

以下のように、ソフトスキルは3層で構造化できます。

```mermaid
graph TB
    L1[メタ層：問いを生み出す力]
    L2[構造層：意味の関係を設計する力]
    L3[対話層：AIとのやり取りを最適化する力]
    L1 --> L2 --> L3
```

#### 🔹 メタ層（問いの設計）

- 問題の前提そのものを問い直す力
- ゴール設定、ユーザー視点の抽象化

#### 🔹 構造層（意味の編集）

- 情報を構造的に整理し、関係性を再構成
- 論理構造、ストーリーフレームの設計

#### 🔹 対話層（操作能力）

- AIとのプロンプト設計、ツール使用スキル
- 会話の方向を制御し、修正する能力

---

## 🧪 展開：具体例とコード

### ✅ 実例：意味編集型プロンプトテンプレート（Python）

```python
prompt_template = """
あなたはプロダクトマネージャーです。
以下の仕様から「なぜこの機能が必要なのか？」という観点で再定義してください。

仕様:
{feature_spec}

制約条件:
- ユーザー層は◯◯
- ◯◯に関する法的制限あり
"""

filled_prompt = prompt_template.format(
    feature_spec="ユーザーがPDFをアップロードしてOCR処理する機能"
)
```

ここで重要なのは、単に **「機能を説明する」のではなく**、  
「その意味・背景を再定義させる」という**意味操作型の問い**である点です。

---

## ⚔️ 人間の“意味API”は再帰性にある

生成AIはトークンの連鎖でしか動作しません。  
対して人間は**“目的→構造→操作→目的”という再帰的なAPI**を内在しています。

```mermaid
graph LR
    A[目的] --> B[問いの構造設計] --> C[操作（プロンプト等）]
    C --> D[出力] --> E[再評価]
    E --> A
```

このループがある限り、**人間のソフトスキルはAIに置き換えられない**のです。

---

## 🧾 プロンプト設計から意味設計へ

ソフトスキルを軽視するエンジニアは、生成AIにおいて「最適な問い」を立てられません。  
逆に言えば、 **「文脈を理解し、意味を設計し、問いを投げられる人」** は、AI時代において真のエンジニアであり続けることができます。

もはやAIに「答えを出させる」こと自体は、コモディティです。  
**価値は、「何を問うか」「なぜ問うか」「それが誰のためか」** に移行しています。

あなたは、AIに **“聞ける”人**でしょうか？  
それとも **“問える”人**でしょうか？
統合ファイルの作成

統合ファイルの作成マクロのソースです。

```

Private WB As Workbook, mergeWB As Workbook

Sub 統合マクロ()

Dim folderPath As String, fileName As String, Y As Integer, X As Integer, merge_X As Integer, chk As Boolean, copyRange As Range

'初期値設定
Y = 1
X = 1
merge_X = 1
chk = False
folderPath = Range("B5") & "\"
mergeFile = "統合ファイル.xlsx"
fileName = Dir(folderPath & "\*.xlsx")

'統合ファイルの存在確認　※存在する場合は削除して新規作成
Do While fileName <> ""
    If fileName = mergeFile Then
        
        Kill folderPath & mergeFile
        
        Set mergeWB = newFile(folderPath & mergeFile)
        
        chk = True
        
    End If
    
    fileName = Dir()
Loop

'統合ファイルが存在しない場合は作成する
If chk = False Then

    Set mergeWB = newFile(folderPath & mergeFile)
    
End If

'統合作業
fileName = Dir(folderPath & "\*.xlsx")

Do While fileName <> ""

    '統合ファイルの場合はスキップ
    If fileName = mergeFile Then
    
        GoTo con
    
    End If
    
    'ファイルを開き表全体をコピー
    Set WB = Workbooks.Open(folderPath & "\" & fileName)
    
    Set copyRange = WB.Sheets(1).Range("A1").CurrentRegion
    copyRange.Copy
    mergeWB.Sheets(1).Cells(1, merge_X).PasteSpecial Paste:=xlPasteValues
    
    'コピー元ファイルの列数を取得
    Do While WB.Sheets(1).Cells(1, X) <> ""
    
        X = X + 1
    
    Loop
    
    'クローズ
    WB.Close SaveChanges:=False
    
    '統合ファイルの最終列をセットしてXは初期化
    merge_X = merge_X + X - 1
    X = 1
    
con:
    
    fileName = Dir()
    
Loop
    
    Range("A1").Select
    mergeWB.Close SaveChanges:=True
    
    MsgBox "統合完了しました！"
End Sub

Function newFile(filePath As String) As Workbook

'Excelファイルを新規作成する
Set mergeWB = Workbooks.Add
Application.DisplayAlerts = False
mergeWB.SaveAs fileName:=filePath, FileFormat:=xlOpenXMLWorkbook
Application.DisplayAlerts = True

Set newFile = mergeWB

End Function

```
コンピュータサイエンス学び直し - 「値渡し」と「参照渡し」と「参照の値渡し」について -

# 1. はじめに
エンジニアとして3年が経過しようとしている中、技術を使ってより高度な問題解決をしていくためには、フレームワークや言語に依存しない基礎となる知識が必要だと感じたため、CSを勉強し直しています。
その学習内容を備忘録として発信します。
前回「**変数**」に関する記事を投稿しましたが、今回はその中でも変数についての「**値渡し**」と「**参照渡し**」と「**参照の値渡し**」という部分についてです。

# 2. 話の進め方

プログラミングにおいて「変数の扱い方」は非常に重要な概念です。
プログラムがデータを扱う際、言語ごとにどのような変数の扱い方をするかによってパフォーマンスなどに影響が出てきますので理解しておくことは重要です。
「*値渡し*」「*参照渡し*」「*参照の値渡し*」という順番で解説を進めます。
尚、サンプルのコードにはRubyを使用します。

# 3. 値渡しとは

## 値渡し（Pass by Value）
値渡しとは、関数に引数を渡すときに、その変数の「**値そのものをコピー**」して渡す方法です。
そのため、**関数内で値を変更しても、元の変数には影響を与えません。**

## 特徴
- 元の変数に影響を与えない（コピーを操作するため）。
- 主に基本データ型（プリミティブ型）で使用される。
- メモリの消費が増える（コピーを作成するため）。
- 安全だが、大きなデータ構造には非効率的。

```ruby
def modify_value(x)
  x = 10  # 新しい値を代入
  puts("関数内の x:", x)
end

a = 5
modify_value(a)
puts("関数外の a:", a)  # 元の変数 a は変わらない
```

出力

```ruby
関数内の x: 10
関数外の a: 5
→ modify_value 関数の x は、a のコピーを受け取るので、関数内で変更しても a には影響なし。
```

# 4. 参照渡しとは

## 参照渡し（Pass by Reference）
参照渡しとは、「**変数が格納されているメモリ上のアドレスを渡す**」方法です。
「使う変数はここにありますよ」という情報をそのまま渡すため、**関数内で値を変更すると、元の変数にも影響を与えます。**

## 特徴
- 元の変数が変更される可能性がある。
- 主にオブジェクト型（リスト、辞書、クラスのインスタンスなど）で使用される。
- メモリ効率が良い（コピーを作らない）。
- 意図しない変更が起こるリスクがある。

```ruby
def modify_list(lst)
  lst.push(4)  # リストに値を追加
  puts("関数内の lst:", lst)

my_list = [1, 2, 3]
modify_list(my_list)
puts("関数外の my_list:", my_list)  # 元のリストが変更される
```

出力

```ruby
関数内の lst: [1, 2, 3, 4]
関数外の my_list: [1, 2, 3, 4]
→ my_list の参照が渡されるため、関数内でリストを変更すると元の変数も変更される。
```

# 5. 参照の値渡しとは
参照の値渡しとは、rubyやpythonのように全てをオブジェクトとして扱う言語などで用いられる渡し方であり、「**作成されたオブジェクトが格納されているメモリ上のアドレス情報を変数に格納し、その値を渡す**」方法です。

## 特徴
- rubyやpythonのようなピュアオブジェクト指向言語などで用いられる方法である。
- プリミティブ型、オブジェクト型（リスト、辞書、クラスのインスタンスなど）関係なく使用される。

前提として、「**基本は値渡し**」というものがあります。「**参照の値渡し**」の場合、「**作成されたオブジェクトが格納されているメモリ上のアドレス情報を変数に格納し、その値を渡す**」という性質上、「**参照渡し**」のように見えるという点が理解するのに厄介な点だと思います。しかし、変数には「オブジェクトの格納されているメモリ上のアドレスそのもの」が格納されているため、その値を渡すという以上、動作としては「値渡し」になります。

その上で、もし呼び出し先の関数内でオブジェクトの値の変更などが起こった場合、呼び出し元の変数の値も変更されるという事象が起こるわけです。

※後程図解を掲載予定

# 6. まとめ

しっかりと調べてみると、言語ごとに変数の扱い方が異なり、パフォーマンスへの影響もそれぞれ異なってくるということが分かりました。こうした言語仕様をしっかりと理解した上でプログラミングをするという一段上のレベルを目指していきたいです。
【統計検定3級】質的変数の要約

# 質的変数の要約

## 質的変数の集計方法
質的変数の要約はそれぞれのカテゴリに属する観測値の個数（度数、頻度）を集計する。
観測値の個数をデータの大きさといい、nで表す。

> 例：アンケートの回答数が500件の場合、n=500

## 質的変数の表示方法
### よく使われるグラフ
- 棒／折れ線グラフ - 値の大きさを比較したい場合
- 円グラフ／帯グラフ - 値の比率を比較したい場合

## クロス集計
複数の項目を組み合わせて集計する方法

### よく使われるグラフ
- 二次元表
Web開発の基本「クエリ文字列」とは？仕組み・使い方・Laravelでの取得方法

# はじめに
URLの末尾に`?page=2`や'?q=Laravel&sort=asc' のようなものを見かけることは多いです。
これは「クエリ文字列(query string)」と呼ばれ、**Webアプリに情報を渡すための仕組み**です。
今回は、クエリ文字列の基本的な仕組みや、PHP・Laravelでの扱い方についてまとめます。

# ①クエリ文字列とは？
クエリ文字列とは、**URLの末尾に`?`をつけて、`キー=値`の形式で情報を渡す仕組み**です。

## 例:
https://example.com/search?q=Laravel&page=2

- `q=Laravel`→検索キーワードが"Laravel"
- `page=2` → 2ページ目の表示

## 特徴:
- 複数の値は`&`でつなぐ
- すべて文字列として扱われる
- ブラウザのアドレスバーに表示されるため、**再読み込み・共有がしやすい**

# ②クエリ文字列の構造
https://example.com/パス?キー1=値1&キー2=値2 
| 部分 | 意味 |
|------|------|
| `?` | クエリ文字列の始まり |
| `&` | 複数のパラメータを区切る |
| `=` | キーと値をつなぐ |

---

# クエリ文字列の用途例

- 検索フォーム：`/search?q=Laravel`
- ページネーション：`/posts?page=3`
- 並び替え：`/products?sort=price_asc`
- フィルタ：`/items?category=books&price=under_1000`

---

# PHPでの取得方法

```php
$keyword = $_GET['q'];     // Laravel
$page = $_GET['page'];     // 2
```
- $_GETはPHPのスーパーグローバル変数
- クエリ文字列をキーとして取得できる

# ③Laravelでの取得方法
Laravelでは、Requestクラスを使って取得します。
```php
use Illuminate\Http\Request;

public function search(Request $request)
{
    $keyword = $request->query('q');      // "Laravel"
    $page = $request->query('page');      // "2"
}
```
もしくは:
```php
$request->input('q'); //クエリ・POST　どちらも対象
```

# ④Bladeテンプレートでの活用例
ページネーション時に現在のクエリを維持:
```blade
{{ $posts->appends(request()->query())->links()}}
```
→検索ワードなどを保持したままページネーション可能

# ⑤クエリ文字列を生成するには？
```php
$url = route('search',['q' => 'Laravel', 'page' => 2]);
```
Laravelのroute()やurl()ヘルパーでクエリを付与可能です。

# ⑥まとめ
![IMG_7773.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2246240/95a87db0-e543-4c78-9ddf-a0cd1d978105.jpeg)

クエリ文字列は、**ユーザーとアプリをつなぐ情報の橋渡し**のような存在です。
LaravelやPHPでの取得・保持・生成の方法を知っておくことで、**より動的で便利なWebアプリが作れるようになります！**
未経験から開発エンジニアとしてSES企業に入って思ったこと

### SESでも納期はある
現場で依頼された開発が出来ていない場合、所属先が管理して突貫工事で完成させています。

### 開発案件ではない場合、正当な理由があれば断った方がいい
ノーコード開発や、開発案件という名のコミュニケーション力重視の事務作業案件があるので、そういった業務で経歴を積んでも、ちゃんとした開発案件の面談で説明が苦しくなります。「やりたい」と「できる」は違うとのこと。

### VBAマクロの記録の活用
コードを記述するのに時間がかかる場合は、マクロの記録を使ってコードを作ることも可能です。
#8 mergeをとりやめるgitコマンド

# はじめに

gitでブランチをmergeしようとしたけどconflictしてしまった。そういう状況を元に戻すコマンドです。

## mergeをとりやめる
mergeをとりやめる場合は、以下のコマンドを実行すればOKです。
```
git merge --abort
```

## rebaseをとりやめる
rebaseを取りやめることもできるようです。
```
git rebase --abort
```

以上です。
コンピュータサイエンス学び直し -変数について-

# 1. はじめに
エンジニアとして3年が経過しようとしている中、技術を使ってより高度な問題解決をしていくためには、フレームワークや言語に依存しない基礎となる知識が必要だと感じたため、CSを勉強し直しています。
その学習内容を備忘録として発信します。
今回は**変数**についてです。

# 2. 話の進め方

プログラミングにおいて「変数」は非常に重要な概念です。本記事では、変数とは何かを理解し、それがなぜ必要なのか、どのように使うのかを詳しく解説していきます。
プログラムがデータを扱う際、変数の使い方次第でコードの品質が大きく変わることがあります。システムの保守性や可読性を向上させるためにも、変数の基本をしっかりと押さえておくことが必要です。
まず、「**変数とは何か**」について説明し、その後「**なぜ必要なのか**」「**どのように使うのか**」という順番で解説を進めます。
尚、サンプルのコードには「Ruby」を使用します。

# 3. 変数とは

変数とは、**コンピュータが演算に使用するデータを格納するための名前付きの領域**です。プログラム内でデータを扱う際に、変数を利用することで、**コードの可読性やメンテナンス性を向上**させることができます。

# 4. 変数はなぜ必要か

変数を使用することで、以下のような利点があります。

## コードの可読性向上

変数名を適切に設定することで、どのようなデータを扱っているのかを直感的に理解しやすくなります。
たとえば、**x = 10** というコードよりも、**score = 10** の方が、変数の意味が明確になります。

## コードのメンテナンス性向上

変数を使用すると、同じ値を複数の場所で利用する際に、一括で管理できます。
たとえば、特定の税率をプログラム内で何度も使用する場合、変数を使わずに直接数値を書いてしまうと、変更が必要になった際に全ての該当箇所を修正しなければなりません。
変数を使うことで、一か所の修正で済むため、バグの発生を防ぎやすくなります。

``` ruby
# 変数を使わない場合（修正が面倒）
price1 = 1000 * 1.10  # 10%の税率
price2 = 2000 * 1.10
price3 = 3000 * 1.10

puts("商品1の税込価格: #{price1}円")
puts("商品2の税込価格: #{price2}円")
puts("商品3の税込価格: #{price3}円")

# 変数を使う場合（修正が容易）
tax_rate = 1.10  # 消費税率10%

def calculate_price(price, tax_rate)
  return price * tax_rate
end

price1 = calculate_price(1000)
price2 = calculate_price(2000)
price3 = calculate_price(3000)

puts("商品1の税込価格: #{price1}円")
puts("商品2の税込価格: #{price2}円")
puts("商品3の税込価格: #{price3}円")
```

変数 **tax_rate** を変更するだけで、すべての計算に影響を与えるため、メンテナンスが容易になります。
また、関数 **calculate_price()** を用いることで、コードの再利用性が向上し、よりシンプルで分かりやすいプログラムになります。

# 5. どうやって使うか

変数を使うためには、以下の手順を踏みます。

## 変数を宣言する

プログラミング言語によっては、変数を使う前に宣言が必要です。以下の例はRubyです。

``` ruby
score = 10  # 変数scoreに10を代入
```

## 変数を使用する
変数を使用するときは、主に宣言した変数を関数に渡して任意の処理を実行するようにして使用します。

```ruby
product_price = 1000
tax_rate = 0.10

def calculate(price, tax_rate)
  return price * tax_rate
end

calculate(product_price, tax_rate)
```

実際に関数において変数を使用する際には、幾つかのパターンがあります。（値渡し、参照渡し、参照の値渡し）
これについては別途[こちら](https://qiita.com/hiddy0329/items/c20ca8ab7a2d01a4bbad)の記事で解説します。

# 6. まとめ

変数は、プログラム内でデータを管理するために不可欠な要素です。適切な変数の使用によって、コードの可読性やメンテナンス性が向上し、システムの品質も向上します。
本記事では、「変数とは何か」から始まり、「なぜ必要なのか」「どのように使うのか」について詳しく解説しました。これを踏まえ、実際のプログラムで変数を適切に活用していきましょう。