OmniAICreator/Qiita-1.07M huggingface dataset:
パソコン詳しくないんだよねっておじさんにもわかってもらえるようにRAGを説明したい

説明に使った時の絵は、別途追加よてい

## はじめに

社内で生成AIに関する活動をしているチームに混ぜてもらった。チームは、生成AIに社内の情報(ソフトウェア設計の過去データなど)を盛り込んで、設計者に使ってもらうことを考えている模様。RAG(AzureのAISearch)を使ってサービスを構築している状態だった。
情報を検索する用のライブラリ(インデックス)を構築するところを行い、ベクトル検索だけできるようになったタイミングで、ワード投げて狙った結果が返ってくるか？を検証してもらうところを、設計者へ協力を依頼することになった。

が、設計者が使うことに全然乗り気じゃなかった。乗り気じゃない理由は
　・時間がない中で、時間とらないとできないことを頼まれても困る
　・最終的にどういった嬉しさがあるのかわかんないと、協力はしづらい
　・パソコン詳しくないんだよね
など。

チンプンカンプンな方がいるってのに気づいたので、何目指して今何をお願いしているのか、ちゃんと理解してもらうことが必要かなと思って、説明できるようにまとめようかなと思った。
そんなに詳しいわけじゃないので間違いもあるかもだけど、あっなるほどねって思ってもらうことを第一に考えてみた。

## 生成AIって？

世の中にある言語情報を、うまいことまとめたデータ(LLM)から、人間らしい対話をもとにして回答を引っ張り出す仕組み。ググるみたいな検索テクが要らなくて、人間臭く聞いても答えを返してくれる、素晴らしいサービス。

## 生成AIを企業で活用するって？

世の中にある情報に企業内の情報は含まれないので、例えば
「ソフトウェア開発の○○機能を実装する際、自社内の過去トラから気を付けることを教えて？」
みたいな質問には答えてくれない。

企業で活用するにあたって、企業内の情報も覚えてもらう必要がある。ケースもある。

## 企業内の情報を覚えてもらう方法は？

たぶん、以下3つがある。

### プロンプトエンジニアリング
生成AIに企業内の過去トラを情報として与えて、その内容に対して回答してもらうようにお願いをする感じの方法。
pdfにまとまってるならpdfファイルを添付するとか、テキストファイルなら対話するウィンドウに後付けで追加するなど。
手っ取り早いけど、毎回毎回ファイルを与えないといけない。

### ファインチューニング
世の中にある言語情報を、うまいことまとめたデータ(LLM)に企業内の情報も入れちゃう感じの方法。
pdfとかテキストファイルをただ与えてあげるのではなくて、質問と回答のセットをとんでもなくたくさん作って、それを学ばせるような感じっぽい。
たくさんの労力がかかっちゃうし、技術も要るので、お金に余裕があるとかチャレンジできる環境がないと難しい気がする。

### RAG (Retrieval Augmented Generation)
質問に対して過去トラから似た情報を集めて、それも使って回答してもらう感じの方法。
過去トラのpdfとかテキストファイルをひとまとめにすることで、毎回ファイルを与えなくてもよくなるし、質問と回答のセットを作るなんていう面倒なことしなくてもよい。
ファインチューニングよりは低コストみたい。ちょっと前からAmazonとかMicrosoftがサービス提供してくれてるので、(お金はいるけど)サッと試すのは比較的容易。

## で、なにするの？
RAGする。協力して。

## 何をすればいいの？
ワード検索の仕組みを提供するから、過去トラの情報をワードを使って狙い通りにとれるかを試してくれませんか？

## なんで？対話は？
質問に対して過去トラから似た情報を集めるところで、ある程度の精度がないと狙った回答が返ってこないってなっちゃうかもしれない。ワード検索で、どうすれば狙い通りにとれるのか？を試して、その結果に基づいて過去トラのデータの持ち方とかを変えていけば、狙い通りに対話する仕組みができるようになると思うからさ。

## 上の話をして、実際どうだったか？
よくわかんないけど協力はするよって言われた。。
【Unity】1つ下の子だけを選択するEditor拡張

# 背景

オブジェクトを円状に並べる際、子を回転させて配置する方法がありますが、子を取り出すのが面倒なので1つ下の子だけを選択する拡張Editorを作りました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307985/c0a6853e-bd8a-0ae5-0399-ac5f3a599143.png)

Editor拡張を入れたら対象のオブジェクトを複数選択し、右クリックすると出るメニューから```Select children one level below```を選択すると、1つ下の子が選ばれます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307985/e55351f3-752c-6b84-84a3-4a870b0cfa4f.png)

### 備考
オブジェクトの配置方法に関しては他にも[専用のEditor拡張を導入したり](https://booth.pm/ja/items/5059254)、[Transformに数式を入力したり](https://creator.cluster.mu/2022/08/22/unity_inspector/)する方法もあるようです。

# コード

``` ChildrenSelectorEditor.cs
#if UNITY_EDITOR
using System.Collections.Generic;
using System.Linq;
using UnityEditor;
using UnityEngine;

public class ChildrenSelectorEditor
{
    private static bool isSelected = false;

    [MenuItem("GameObject/Select children one level below", false, 1000)]
    public static void SelectChildren()
    {
        if (isSelected) return;
        isSelected = true;
        EditorApplication.delayCall += () => isSelected = false;

        var children = new List<GameObject>();
        foreach (var go in Selection.gameObjects.ToArray())
        {
            var transform = go.transform;
            for (int i = 0; i < transform.childCount; i++) children.Add(transform.GetChild(i).gameObject);
        }
        Selection.objects = children.ToArray();
    }
}
#endif
```
レビューの重要性

# はじめに
プロジェクトによってレビューの重要度、優先度が異なるが、どんなプロジェクトでも各工程ごとのアウトプットに対するレビューをしないことはハッキリ言って品質を大きく下げることになる。
さらに言えば、結果的にリードタイムが伸びることになる。

この記事ではレビューの重要性やレビュー基準、レビューを実施しないとどうなるかについて記載していく。

開発チーム内のレビューは、ソフトウェア開発プロセスにおいて非常に重要な役割を果たします。効果的なレビュー手法を導入することで、品質向上、開発効率の改善、そしてチームメンバーのスキル向上につながります。

## レビューの重要性

1. **品質向上**: 
レビューを通じて、潜在的な問題や不備を早期に発見し、修正することができます。これにより、後の開発段階での大きな問題を防ぐことができます。

2. **開発効率の向上**: 
早期の問題発見により、開発の後戻りを減らし、納期までの期間を短縮できます。

3. **チーム全体のスキル向上**: 
レビューを通じて、チームメンバー間で知識や経験を共有することができます。

## 効果的なレビュー手法

### 1. チームレビューとPBRの組み合わせ

- 5人程度の参加者で実施し、各レビューアに特定の視点を割り当てます。
- 設計者、テスター、顧客の3つの視点を必ず含めることが重要です。

:::note info
PBR（パースペクティブ・ベースド・リーディング）
各レビューアに特定の視点を割り当ててレビューを行う手法。
特定の視点のなかで必ず設定すべきは、設計者、テスター、顧客の３つの視点。
この3つ以外の視点は、レビュー対象物の特性に合わせて設定すればよく、例えばシステム運用者の視点などになる。
:::

### 2. レビューの迅速な対応

- レビューへの返信は最長で1営業日以内に行うべきです。
- チーム全体の開発速度向上のために重要です。

### 3. 適切なレビュー基準の設定

- 完璧なコードを求めるのではなく、システムを確実に改善するコードを求めましょう。
- 個人的な好みは排除し、チーム内のルールや言語仕様に基づいて判断します。

### 4. レビューの手順

1. 変更を広く眺め、目的を確認する。
2. クリティカルな問題がないか最初にチェックする。
3. 残りを適切な順序で確認する。

## レビューアの選定

レビューする観点に応じて適切なレビューアを選定することも重要です。例えば、システムの使いやすさを確認したい場合は、普段システムを使ったことがない人を選ぶなど、目的に応じた選定を行います。

:::note warn
レビュアーの人数について
参加者が少なくならざるを得ない状況の場合は、チーム内のメンバで最低限　設計者、テスター、顧客の３つの視点でレビューを行うべき。
　
また、レビュアーは最低１名以上、できれば２名以上で行うべき
観点漏れを防ぐためと、属人化を避けるため複数名でのレビューが必要。。
上記のため１名は避けた方が良い。

そして最もあり得ないのは、時間が無いからといってレビューをしない、と言うことは絶対に避けるべき。
<font color="red">**負債とリスクを常に抱えることになるだけだ**</font>
:::

効果的なレビュー手法を導入し、チーム全体で取り組むことで、開発プロセスの質を大きく向上させることができます。初心者の方々も、これらの手法を意識しながら積極的にレビューに参加することで、自身のスキル向上にもつながります。

適切なレビュー基準の設定は、効果的な開発チーム内のレビューを実施する上で非常に重要です。以下に、適切なレビュー基準の設定に関する重要なポイントを説明します。

## レビュー基準の設定方法

1. **明確な品質目標の設定**
開発プロジェクトの開始時に、明確な品質目標を設定することが重要です。これにより、レビューの際に何を重点的にチェックすべきかが明確になります。

2. **定量的品質出荷基準の設定**
プロジェクトの成果物に対して、定量的な品質出荷基準を設定することが推奨されます。これにより、レビューの際に具体的な数値目標を持って評価することができます。

3. **チェック項目の決定**
基本設計における重要な要素を洗い出し、それに基づいて具体的なチェック項目を設定します。例えば、以下のような項目が考えられます：
- 設計の整合性
- 機能要件の満たし具合
- パフォーマンス要件
- セキュリティ要件

チェック項目をチェックリストとして作成し、メンバがいつでも確認可能なようにすることが重要。

## レビュー基準の適用

1. **成果物の特徴に応じたテーラリング**
個々のレビュー対象成果物に対して、その特徴に応じたレビュープロセスをテーラリングすることが重要です。例えば、成果物のサイズや重要度に応じて、異なるレビュー手法を適用することができます。

2. **網羅性、正確性、わかりやすさの観点**
基本設計レビューにおいては、主に網羅性、正確性、わかりやすさの3つの観点からチェックを行います。これらの観点を基準として、レビューを実施することで、設計の質を総合的に評価することができます。

3. **非熟練者への配慮**
開発経験が2年未満の非熟練者が担当した成果物に対しては、別途レビュー実施手順を定めることが推奨されます。これにより、経験の浅いメンバーのスキル向上にも配慮したレビューが可能となります。

適切なレビュー基準を設定し、それを効果的に適用することで、開発チーム全体の品質向上と効率的な開発プロセスの実現につながります。

以上
DeepSeekモデル利用の基本要件（メモリ各種及び推奨インスタンスタイプ）


本記事は EC2 環境に基づいています。  
DeepSeek の各モデルに必要な GPU、メモリ、および対応する AWS EC2 インスタンスのタイプについて説明します。


https://github.com/deepseek-ai



# DeepSeek的各种模型
| モデル                     | パラメータ数  | GPU 映像メモリ | メモリ（システム） | 推奨 AWS EC2 インスタンス  | GPU タイプ                | vCPU | システムメモリ |
|----------------------------|--------------|---------------|-------------------|---------------------------|--------------------------|------|----------------|
| **DeepSeek-R1 小型モデル**  | 7B パラメータ  | 6GB           | 16GB              | g4dn.xlarge               | 1x NVIDIA T4 GPU（16GB）  | 4    | 16GB           |
|                            |              |               |                   | g5.xlarge                 | 1x NVIDIA A10G GPU（24GB）| 4    | 16GB           |
| **DeepSeek-R1 中型モデル**  | 13B パラメータ | 12GB          | 32GB              | g5.2xlarge                | 1x NVIDIA A10G GPU（24GB）| 8    | 32GB           |
|                            |              |               |                   | p3.2xlarge                | 1x NVIDIA V100 GPU（16GB）| 8    | 61GB           |
| **DeepSeek-R1 大型モデル**  | 30B パラメータ | 20GB          | 64GB              | p3.8xlarge                | 4x NVIDIA V100 GPU（16GB）| 32   | 244GB          |
|                            |              |               |                   | p4d.24xlarge              | 8x NVIDIA A100 GPU（40GB）| 96   | 1.1TB          |
| **DeepSeek-V3 超大型モデル** | 236B パラメータ | 80GB          | 512GB             | p4de.24xlarge             | 8x NVIDIA A100 GPU（80GB）| 96   | 1.1TB          |
|                            |              |               |                   | p5.48xlarge               | 8x NVIDIA H100 GPU（80GB）| 96   | 1.1TB          |



## 注意点

映像メモリの要件：DeepSeekの大規模モデル（30Bや236Bパラメータなど）では、複数のGPUを並列で使用する必要があります。もし単一のGPUで実行する場合、映像メモリが不足することがあり、モデルの分割処理を行うことが推奨されます。

メモリ：映像メモリだけでなく、システムメモリも重要です。特に大規模モデルを使用する場合は、64GB以上のシステムメモリが推奨されます。

EC2インスタンスの選定：大規模なモデルには、複数GPUを搭載したインスタンス（例えばp4dやp5シリーズ）が必要です。小規模モデルの場合、より経済的なインスタンス（例えばg4dnやg5シリーズ）が適しています。
【LoL】LoLのカスタム支援ツールを作ってみた

# システム説明

メンバーのレーン毎の能力を設定・管理
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3992599/b4e69ac6-ec27-0db9-0a49-ca2cf0fc6fb4.png)

カスタム参加するメンバーを指定。
設定した能力値が極力同じになるように、ランダムなレーン・チーム作成が
行われます。
![ランダムなチーム作成.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3992599/7a7de477-5262-03fd-8457-4f56ffa0ed55.png)

試合終了後に、勝利チームを入力することで、ポイントが付与されます。
![勝利チームにポイントを付与.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3992599/62226596-8764-19b7-e451-7098fbe1a899.png)

試合数を重ねる毎に、実際のサーバー内における自分の能力が適正化されていき、バランスのいいカスタムチームが作成できるようになります。

# 導入方法
下記のURLより、DiscordのサーバーにBotを追加してください。

https://discord.com/oauth2/authorize?client_id=1310981081566281728&permissions=2415921152&scope=guilds+applications.commands+bot

サーバーにBot追加後、下記のようなメッセージが表示されるので、
説明通りに進めてもらえれば、使用いただけます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3992599/9ba3fe63-e155-6933-2718-3ba391a118d8.png)


# 開発者

https://x.com/mikipodev

機能追加要望などあれば、Xなどにご気軽にご連絡ください。
DiscordBotをサーバーに追加後、システム内の /request コマンドなどでも、要望いただけます。
「見張る」から「信頼」へ。監査が導くエンジニアの進化論 ✨ 

 ## 監視をやめて、監査で進化しよう！

「監視」って本当に必要ですか？見張られることで生産性が上がるどころか、むしろ下がることも…。  
この記事では、日本企業にありがちな「監視文化」がもたらす問題点と、それを解決する「監査」のメリットについて語ります。  
エンジニアとして、そして人間として成長するために、私たちの働き方を見直してみませんか？✨  

:::note  
本ポエムはChatGPTに95割くらいアシストしてもらってます。  
:::

## 日本企業における「監視」の問題 🕵️‍♂️

[![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/6a88d391-119c-1a53-e233-2c3ff19a1a20.png)](https://www.irasutoya.com/2019/12/blog-post_10.html)

日本特有（？）とも言える「リアルタイム監視文化」。 多くの日本企業では、従業員の動作やPC画面をリアルタイムで「見つめる」「のぞき見る」ことを好む傾向があります。  

正直、「その時間で自分の分野のQiitaやStack Overflowでも読めばいいのに」と思うこともありますが、これがある種の性癖のようなものだと考えると、深く追究する気も失せます。  

日本の民主主義は欧米より200年遅れており、その結果としての現象と考えられますが、このような未進化の習慣が根付いていると、以下のような問題が発生します👇：

### **1. 監視者自身が生産性ゼロ**  
他人の作業ばかりチェックして、自分は何もアウトプットできない…。これ、悲しくないですか？  
本来なら、自分のスキルアップや生産性向上に時間を使うべきです。

### **2. 従業員の思考停止モード**  
「常に見られている」というプレッシャーがあると、自由な発想や柔軟な思考がガチガチに固まってしまいます。これでは新しいアイデアも生まれません。

### **3. 経営資源の無駄遣い**  
監視される側＋監視する側＝2人分の人件費。これって投資効果が半減しているどころか、むしろマイナスですよね。

例えば、「あいうえお」と入力しているエンジニアと、それを見て「『ぉ』になってる！」と後で指摘しようと構える監視者。この原始的な状況から何か生産的なものが生まれるでしょうか？答えは明らかにNOです🙅‍♂️。

こうした環境では、生産的なアウトプットが追い付かず、エンジニアや人間として新しいフェーズに進めない「スタック状態」の人をたくさん見てきました。

もしあなたが「技術や仕組みよりも、目の前の人の動作を見るほうが楽しい」と感じ始めたら、それはエンジニアとして終了したサインかもしれません。その場合、別の業種が待っていることでしょう…。

---

## 「監査」による柔軟で論理的な運用体制 🤝
[![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/1c821c6b-747d-aac7-9edd-abdb20194c1a.png)](https://www.irasutoya.com/2020/04/blog-post_53.html)

一方で、「監査」による運用体制はどうでしょう？ここでいう「監査」とは、個人チャットやメール内容などプライバシーに関わるものではなく、履歴管理・ログ取得・アラート設定といったシステム的な仕組みを指します。

例えば：
- ログをテーブル化・ダッシュボード化して、いつでも必要な情報を確認できるようにする。
- 各種アラートを精度高く設定し、不必要な通知を減らす。
- 定期的に運用改善を行い、仕組みそのものを進化させていく。

このような「監査」なら、以下のようなメリットがあります👇：

### **1. 従業員が自由に考えられる環境**  
プライバシー意識が高く、信頼されて働ける環境では、自律的に考えながら効率よく仕事を進められます。信頼こそ最高のモチベーションです。

### **2. 先進的なツール選定が可能**  
監視を前提としないことでアウトプットを重視する組織風土に進化。BIツールや[Markdown対応Webアプリ](https://qiita.com/minoden_works/items/f405f5077761511918d4)など、生産性向上につながるツールを積極的に導入できます。ツール選びに余裕がある組織は強い！

### **3. アウトプット重視の評価体制**  
作業プロセスよりも成果物そのものを評価する文化が育ちます。「何を作ったか」が評価される職場は、生産性もモチベーションも高まります。

## まとめ 🌟
[![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/0f7bae8e-bb0d-22ca-c3c1-7ac3f1c716e7.png)](https://www.irasutoya.com/2014/11/blog-post_81.html)

多くの日本企業で見られる「見張る」文化は、生産性や創造性を阻害し、経営資源まで浪費しています。そこには人間のポテンシャルを信じない、人材を均質な丸太と見る遅れた意識から進化がありません。そして監視している人間の未来をも奪っているのです。

***「監視」から脱却し、「監査」によって柔軟で論理的な運用体制を構築すること。***
それこそがエンジニアリング組織として次なるステージへ進む鍵になるでしょう✨。

そして、その結果として生まれるアウトプットと「信頼」こそが、エンジニアとしても、人間としても成長する道筋なのです🚀

::: note
# ポエム
- ここまで自動的に深掘りして書いてくれるAIしゅごい（こなみかん）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/790864/896e5276-ce1d-dbcd-3359-1d1fd2155b92.png)

:::
ウェブメルカトルの北極・南極判定

ウェブメルカトルの真髄の半分は、単位球を単位平面に展開することである。

ウェブメルカトルの真髄の残り半分は、ズームの概念を導入し、有限桁数の数値によって必要な分解能を得ていくことである。

前者半分に集中して考える場合、ズームレベル z と、n = 2 ** z を捨象して考えれば良い。まずは、話が簡単な x から考えよう。

(lng + 180) / 360

lng の定義域は -180 から 180 なので、上式 は 0 から 1 の間に収まる。

y については、

(1 - log(tan(lat_rad) + (1 / cos(lat_rad))) / PI) / 2

を考えることになる。この値が 0 になる時が北の限界であり、1 になる時が南の限界である。その時の lat_lad の値は解析的には得られないそうである。

他方、 https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames によれば、その値は

±arctan(sinh(π))

であるそうだ。数値的な値は、度単位で言えば ±85.0511 である。

では、与えられた緯度が南北の限界を超えるかどうかは、lat_rad と上記の値を比較することで検査すべきであろうか。私はそうは思わない。むしろ、

y = floor(n * (1 - log(tan(lat_rad) + (1 / cos(lat_rad))) / PI) / 2)

の値が 0 よりも小さくなるか、n = 2 ** z - 1 よりも大きくなるか、を検査した方が経済的であろう。

```ruby
def y(lat, z)
  n = 2 ** z
  lat_rad = lat * Math::PI / 180
  (n * (1 - Math.log(Math.tan(lat_rad) + (1 / Math.cos(lat_rad))) / Math::PI) / 2).floor
end

p y(86, 1)  # -1
p y(-86, 1) # 2
```
アジャイル開発：レトロスペクティブ

# はじめに
アジャイル開発におけるレトロスペクティブ、つまり**振り返り**について記載していく。
レトロスペクティブの重要性について、実施しない場合や失敗例を交えながら記載し、効果的なフレームワークの概要について記載していく。

# レトロスペクティブとは？
アジャイル開発におけるレトロスペクティブは、開発チームの成長と改善のための重要な機会です。簡単に言えば、「振り返り」のミーティングです。

レトロスペクティブとは、スプリントと呼ばれる短期間の開発サイクルが終わるたびに行われる、チームの振り返りのセッションです。このミーティングの目的は、チームの作業プロセスを改善し、次のスプリントをより効果的にすることです。

## レトロスペクティブの重要性

1. **継続的な改善**: レトロスペクティブを通じて、チームは常に自分たちのプロセスを見直し、改善する機会を得ます。

2. **チームの結束**: 全員で振り返ることで、チームの一体感が強まります。

3. **問題の早期発見**: 小さな問題が大きくなる前に発見し、対処できます。

## レトロスペクティブの進め方

典型的なレトロスペクティブは以下のような流れで行われます:

0. **事前準備**: <font color="red">**※地味なことだが事前準備が地味に重要なことなんだ**</font>
必要な道具（ホワイトボードや付箋、オンラインツールなど）の準備
MTGスケジュール調整
レトロスペクティブの意図を事前に関係者にお知らせしておく

1. **雰囲気作り**: 全員が参加しやすい、オープンな雰囲気を作ります。

2. **データ収集**: スプリントの成果や問題点を示すデータを集めます。

3. **アイデア出し**: 改善のためのアイデアをチーム全員で出し合います。

4. **改善策の決定**: 具体的にどのように改善するかを決めます。

5. **終了**: 次のアクションを確認して終了します。

## 効果的なレトロスペクティブのコツ

- **安全な環境を作る**: 全員が自由に意見を言えるよう、批判的にならない雰囲気を作ります。

- **具体的なアクションにつなげる**: 単なる話し合いで終わらせず、必ず次のスプリントで実行する改善策を決めます。

- **時間を守る**: 通常1〜2時間程度で行い、集中力を維持します。

- **定期的に実施する**: スプリントごとに必ず行い、継続的な改善を図ります。

レトロスペクティブは、チームが自らの強みと弱みを理解し、より効果的に協力する方法を見つけるための貴重な機会です。これを通じて、チームは常に成長し、より良い製品を作り出すことができるのです。

# レトロスペクティブのフレームワーク
代表的なものを以下に挙げる

1. **KPT(KPTA)**: 
「Keep(継続)」「Problem(課題)」「Try(今後の挑戦)」「Action(取り組み)」の4つの観点から振り返りを行います。

2. **Fun Done Learn**: 
「Fun(楽しかったこと)」「Done(やったこと)」「Learn(学びを得たこと)」の3つの観点でシンプルに振り返ります。

3. **4L**: 
「Liked(好きだったこと)」「Learned(学んだこと)」「Lacked(欠けていたこと)」「Longed(望んだこと)」の4つの観点から分析します。

4. **What Went Well**: 
「Went Well(うまくいったこと)」「To Improve(改善すること)」「Action Items(アクションアイテム)」の3つの観点で振り返ります。

5. **3匹の子ぶた**: 
「わらの家(課題)」「木の家(改善中)」「レンガの家(うまくいっていること)」という3つの観点で現状を整理します。

6. **スタート・ストップ・コンティニュー**: 
開始すべきこと、停止すべきこと、継続すべきことを明確にします。

7. **マッド・サッド・グラッド**: 
怒り、悲しみ、喜びの感情を通じて振り返りを行います。

これらのフレームワークは、チームの状況や目的に応じて選択し、効果的なレトロスペクティブを実施するのに役立ちます。

# レトロスペクティブを実施しないとどうなる？
レトロスペクティブを実施しない場合、以下のような問題が発生する可能性があります:

1. 継続的な改善の機会の喪失: チームが自らの作業プロセスを見直し、改善する機会を逃してしまいます。

2. 問題の蓄積: 小さな問題が放置され、時間とともに大きな問題に発展する可能性があります。

3. チームの成長の停滞: メンバーが学びや気づきを共有する機会が減少し、チームとしての成長が鈍化します。

4. コミュニケーションの低下: チーム内でのオープンな対話の機会が減り、メンバー間のコミュニケーションが希薄になる可能性があります。

5. モチベーションの低下: 改善の取り組みがなくなることで、チームの士気が低下する可能性があります。

6. 非効率的なプロセスの継続: 非効率的な作業方法や問題のある慣行が改善されずに続く可能性があります。

7. チームの一体感の欠如: 共通の目標に向かって改善を進める機会が失われ、チームの結束力が弱まる可能性があります。

8. 顧客満足度の低下: プロセスの改善が行われないことで、製品やサービスの品質向上が停滞し、顧客満足度に影響を与える可能性があります。

9. アジャイルの原則からの逸脱: 継続的な改善はアジャイル開発の重要な原則の一つであり、レトロスペクティブを実施しないことはこの原則から外れることを意味します。

これらの問題は、チームの生産性や製品の品質に長期的な悪影響を及ぼす可能性があります。したがって、レトロスペクティブは定期的に実施し、チームの継続的な改善を促進することが重要です。

# レトロスペクティブの失敗事例
レトロスペクティブの失敗事例には、以下のようなものがあります:

1. **準備不足**: 必要な道具（ホワイトボードや付箋、オンラインツールなど）の準備ができていない。

2. **時間管理の失敗**: ふりかえり時に適切な時間管理ができていない。

3. **アクションアイテムの曖昧さ**: 改善のためのアクションアイテムの実施時期や期間が明確でない。

4. **過剰な改善策**: すべてのアクションアイテムを一度に実施しようとする。

5. **マンネリ化**: 毎回同じふりかえり手法を使用し、新鮮さが失われる。

6. **専門分野の無視**: 異なる専門を持つメンバーで構成されているチームで、一度のレトロスペクティブですべての課題を議論しようとする。

7. **成果物の遅延評価**: スプリントごとに成果物の進捗を把握せず、長期間経過後に初めて評価することで、手戻りが発生する。

8. **改善の形骸化**: 改善活動が目的化し、実際の課題解決や成長につながらない。

9. **意見が出ない**: チームの雰囲気や個人の性格、セッションの進め方などにより、参加者から意見が出ない。

10. **アクションアイテムの未実行**: レトロスペクティブで決めた対策が実際には実行されず、話し合いだけで終わってしまう。

これらの失敗事例を認識し、適切に対処することで、より効果的なレトロスペクティブを実施できます。


以上
IAMについてまとめてみた。

## はじめに
AWSの資格を残すところアソシエイトとプラクティショナーのみとなったところで改めてIAMについてメモとしてまとめます。

資格についてはすべて問題を暗記し、サービスについて大枠を80%ぐらい理解した形で試験を受けているせいでハンズオンなど実戦形式には役立たないアンチパターンができあがってしまいました・・。

※あくまでメモとして記録に残しているため、上級者の方は知っているよと思われるかもしれないです。ご了承ください。

※参照元はすべて公式ドキュメントから引用しております。


### IAMとは
AWSのIdentity and Access Management（IAM）は、AWSリソースへのアクセス制御を行うための中核的なサービスです。

### IAMユーザー（IAM User）

IAMユーザーとは、AWSリソースにアクセスするためのエンティティであり、個々のユーザーに一意の認証情報（ユーザー名とパスワード、またはアクセスキー）が割り当てられます。これにより、各ユーザーは自身の認証情報を用いてAWSリソースにアクセスできます。

主な特徴
1) 個別の認証情報
各ユーザーは独自の認証情報を持ち、これを使用してAWSにサインインします。
2) アクセス権限のカスタマイズ
ユーザーごとに異なるポリシーを適用することで、必要な権限のみを付与できます。
3) 多要素認証（MFA）の設定
セキュリティ強化のため、MFAを設定することが推奨されます。


### IAMグループ（IAM Group）

IAMグループは、複数のIAMユーザーをまとめて管理するための単位です。共通のアクセス権限を持つユーザーをグループ化することで、効率的な権限管理が可能となります。

主な特徴
1) 一括ポリシー適用
グループにポリシーをアタッチすると、そのグループ内の全ユーザーに同じ権限が適用されます。
2) 管理の簡素化
ユーザーをグループに追加または削除することで、個別のポリシー管理の手間を省けます。
3) 多重所属の許可
ユーザーは複数のグループに所属でき、複数の権限セットを組み合わせることができます。


### IAMロール（IAM Role）

IAMロールは、AWSリソースに対する一時的なアクセス権限を付与するための仕組みです。ロールを引き受けることで、ユーザーやサービスは特定の権限を一時的に取得できます。

主な特徴
1) 一時的な認証情報
ロールを引き受けることで、一時的なセキュリティ認証情報が提供されます。
2) サービス間のアクセス
EC2インスタンスやLambda関数などのAWSサービスが他のAWSリソースにアクセスする際にロールを使用します。
3) クロスアカウントアクセス
異なるAWSアカウント間でのリソースアクセスを許可する際にもロールが活用されます。

### IAMポリシー（IAM Policy）

IAMポリシーは、AWSリソースへのアクセス許可や拒否を定義するJSON形式のドキュメントです。これをユーザー、グループ、ロールにアタッチすることで、アクセス制御を実現します。

主な特徴
1) 詳細な権限設定
特定のアクションやリソースに対する許可や拒否を細かく設定できます。
2) 条件付きアクセス: 特定の条件（例: IPアドレスや時間帯）に基づいてアクセスを制御できます。
3) ポリシーの種類: AWSが提供する管理ポリシーと、ユーザーが独自に作成するカスタマー管理ポリシーがあります。

### IAM Identity Center（旧AWS SSO）

IAM Identity Centerは、複数のAWSアカウントや外部アプリケーションへのシングルサインオン（SSO）を提供するサービスです。これにより、ユーザーは一度のサインインで複数のリソースにアクセスできます。

主な特徴

1) 統合認証
Microsoft Entra ID（旧Azure AD）やOktaなどの外部IDプロバイダーと連携し、中央集権的なユーザー管理が可能です。
2) アクセス許可セット
特定のAWSアカウントやアプリケーションへのアクセス権限を定義し、ユーザーやグループに割り当てます。
3) AWS Organizationsとの連携
複数のAWSアカウントを一元的に管理し、統合されたアクセス制御を実現します。


## ハンズオン
https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-1st-Step-2022-reg-event.html?trk=aws_introduction_page

今回上記のIAMに関する初心者ハンズオンを実施しました。
中でも「AWS Organizations によるマルチアカウント戦略を試してみる」のハンズオンはかなり興味深かったです。

今まで個人のAWSのアカウントを使用しており、他に使用させる人もいないからルートユーザーでもいいかと思っていました。
でも、AWS Orgazationsを用いてみるとマルチなAWSアカウントを1つのSSOユーザーで扱えるので異なるアカウント間での検証とかでは有用だなと感じました。


## さいごに
今までIAMに関しては混ざって理解していたところがありました。
あくまでIAMポリシーは 「アクセス許可や拒否を定義するルール」 であり、
IAMユーザー、IAMグループ、IAMロールは 「そのルール（ポリシー）によって権限を与えられる側」 であるということがわかりました。

他にも初心者ハンズオンを試しつつ勉強していきます。
ありがとうございます。
rbenvでRubyバージョンを切り替える

## はじめに
自分がインストールして使用しているバージョンとは異なるバージョンをプロジェクトごとに指定する方法があるのかと思い備忘を含めて書きたいと思いました。

## rbenvとは
rbenvは何回か目にしたり、聞いたことはありましたが特に意識せずに学習していました。
rbenvは複数のRubyバージョンを管理、切り替えをするためのツールで、プロジェクトごとに任意のバージョンを設定できます。

## Rubyのインストール
バージョンを指定してインストールできます。
```
rbenv install 3.3.5
```

## インストールしたRubyバージョンの確認
現在インストールされているRubyのバージョンが確認できます。
```
rbenv version
```

## グローバルなRubyバージョン指定
システム全体で使用するデフォルトのRubyバージョンを指定できます
```
rbenv global 3.3.5
```
下記のコマンドを実行するとデフォルトのバージョンを確認できます
```
cat ~/.rbenv/version 
```
## ローカルなRubyバージョン指定
特定のプロジェクトで使用するRubyバージョンを指定できます
```
cd /your/project/path
rbenv local 3.2.2
```

## さいごに
かなり初歩的なことですが、バージョンの互換性があわない場合もあるのでrbenvでのバージョン管理は大切と感じました。
rbenvでプロジェクトごとに適切なバージョンを管理していきたいです。
【UE5】Fabから取得したデータをエディタに反映させよう！（初心者向け）

# やりたいこと
1. Fabから取得した**アイテム**を配置した〜い！
2. Fabから取得した**アニメーション**を配置した〜い！

:::note warn
注意
本記事の目的は備忘録であり、経験者にとっては当たり前すぎる内容です。
お願いクソ記事だからって叩かないで！！
:::

### 環境
 - MacBook Air(Apple M2 Pro)
 - Unreal Engine 5.2

# Fabとは
UnrealEngine等のアイテムを取り扱うマーケットプレイスになります。
無料で利用できるアセットも多く存在しており、一気に制作の幅が広がります！
解説記事は腐るほどあると思うので、詳しく知りたい方は自分で調べてください。

https://www.fab.com/ja

# アイテムを配置した〜い！
まずはFabにアクセスし、適当なアイテムを見繕います。
今回は3Dアイテムのリンゴを探してみました。

ダウンロードを選択し、apple_tefcefala_raw.glbをローカル環境に保存します。
「glb」拡張子はそのままコンテンツドロワーに追加することが可能なので便利です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/9b82141c-4c3a-3509-6162-fd8f50b9dab6.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/1259c3e1-fded-d4d1-80ad-b22f2dc4d89c.png)

UEを開きダウンロードしたリンゴの3Dモデルをインポートします。

コンテンツドロワーの任意の箇所にファイルをD&Dするか、
ファイル　＞　レベルにインポート　で場所を選べばOKです。
※Zipしかない場合でも、解凍後に同様の手順でインポート可能です！

交換パイプラインコンフィギュレーション（シーンのインポート）のウィンドウが表示されますが、特にそのままの設定で問題ありません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/4b7cc691-169b-ffcf-a730-22793f647802.png)

コンテンツドロワー内にデータが表示されればOKです。
一番右に表示されている「スタティックメッシュ」をビューポートにD＆Dすれば完成です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/cf29d71c-006f-573f-eb9e-2da15038ab21.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/1b836944-1d2f-f82c-db0f-2bed29cd0ba9.png)




# アニメーションを配置した〜い！
次は同じ容量でアニメーションを配置してみたいと思います。
この方法はあくまで一例であり、もっと良い方法があるかもしれません。

今回はゾンビを探してみました。
先ほどと同様にダウンロードを選択し、「fbx」形式と記載のあるlow-poly-zombie-game-animation.zipを保存します。

:::note warn
注意
自分の環境ではglb形式でうまく起動しなかったため、fbx形式を利用します。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/4e5c892e-b759-a196-f50b-6eb911573857.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/98e3da6f-252a-beaf-9def-4ff4d1a48e0a.png)

Zipを解凍し、先ほどと同様にUEに取り込みます。
FBXインポートオプションが表示されるので、「Import Animations」にチェックをつけるのを忘れないようにしましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/263897c1-8ee3-13d8-d690-3d2faae95265.png)

Sourceフォルダの中身を確認すると複数のアニメーションシーケンスがあります。
ダブルクリックするとアニメーションウィンドウが開き動作確認可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/dcbb5000-749e-5503-232a-ea33c2e920b9.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/5f7eab4a-b7ed-053a-40e1-0c2c53082f6f.png)

利用したいアニメーションシーケンスをビューポートにD&Dすることで、通常の3Dモデルと同様に配置することが可能です。
FirstPersonのプレイモードで確認しても正常にアニメーションしていました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/6d9d8010-5af2-bb0d-9a42-5c52db5918da.png)
![zombi.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/66614291-6416-4504-31b8-4ddde3e4a6e1.gif)

## 仕上げ

Textureフォルダに含まれているマテリアルをD&Dで割り当てれば完成です。
毎回割り当てるのが大変な場合は、ブループリントを活用すると良いかと思います。
（やる気があれば次回記事で記載します〜）

![zombi2.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3967203/d1235991-880c-18ce-f157-96c0396b84cf.gif)

以上！

# 素材の参照元はこちら
https://www.fab.com/ja/listings/34d0ab78-7287-4d36-954e-c3461231e3a8

https://www.fab.com/ja/listings/061afcd7-81fd-457a-974f-ba19e91727d6
zsh + Wayland 環境で fcitx5 が自動起動しない

初めての記事なので至らぬところがあったら指摘してください．

# ことの発端
Ubuntu 24.04 を普段使っているが，日本語入力に fcitx5 + mozc が良いよと聞いていたため，試してみた．

https://pc.watch.impress.co.jp/docs/column/ubuntu/1524498.html

しかし，ログインしてみると日本語入力が自動起動しないため困っていたが，fcitx をスタートアップに入れて，無理やり立ち上げていた．しかし，それもなんだかスマートではないと感じたため，重い腰を上げて調査してみた．

# インターネット上で同様のバグを調べる
調べてみると，以下のような記事があった

https://forums.ubuntulinux.jp/viewtopic.php?id=22102

私は Gnome を使っているが現象は近いように思えた．
他にも，いくつか調べてみると以下のような記事があった．

https://zenn.dev/armcore/articles/linux-system-imconfig-2

なんとなく，zsh + Wayland が悪いのかなぁと検討をたてて，調査を進めることにした．

# /etc/xdg/autostart/im-launch.desktop
自動起動しているのは上記のファイル．
そこを見ていたら，あることに気づいた．

https://salsa.debian.org/input-method-team/im-config/-/merge_requests/18/diffs

```sh:im-launch.desktop
Exec=sh -c 'IM_CONFIG_CHECK_ENV=1 im-launch true'
```

起動時のシェルスクリプトに渡す環境変数ってこれで合ってるのかなぁ．．．と疑問に思い，im-launch スクリプトを調べてみると，なんとなく違うような気がした．
そこで，以下のように変更して再ログインしてみた．
```sh:command
cp /etc/xdg/autostart/im-launch.desktop ~/.config/autostart/
emacs ~/.config/autostart/im-launch.desktop
diff /etc/xdg/autostart/imlaunch.desktop ~/.config/autostart/im-launch.desktop
3c3
< Exec=sh -c 'IM_CONFIG_CHECK_ENV=1 im-launch true'
---
> Exec=sh -c 'IM_CONFIG_PHASE=1 im-launch true'
```

すると，自動起動するようになった．

# 後日談
色々調査したり，人に相談してUbuntu または debian に報告しようとしたとき，以下のバグレポートを教えていただいた．

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983116

私の拙い英語力だと，「zsh + Wayland はサポート外」，「とりあえず直さないよ」と書かれているように思えた．それに，バグ報告，修正をするのは初めてなのでハードルが高く感じ，自分には手に負えないなぁと感じる今日この頃．
~~しかも，IM_CONFIG_CHECK_ENVやIM_CONFIG_PHASE が何をする変数なのか調査しきれていないため，とりあえず自分が満足したので良いか，と思い供養する．~~

# 追記
man im-configの中に，以下の記述があった．
> If you wish to create a custom configuration beyond what im-config can do for you, please copy one of these initialization code files into ~/.xinputrc or /etc/X11/xinit/xin‐putrc and edit it to suite your need.
> For example, 02_cjkv.rc tells how input method can be customized for each locale.
> This script should be written  to  set  environment variables if "\\$IM_CONFIG_PHASE" = 1 and to start daemon programs if "\\$IM_CONFIG_PHASE" = 2 .

これによると，環境変数を設定するときには1を，デーモンを起動するときには2を設定するように見受けられます．
しかしIM_CONFIG_CHECK_ENVについては特に記載がないため，よくわかりませんでした．

あとは，シェルスクリプトを追いかけて見たところ，気になる点が．私はsystemd経由でXMODIFIERS等の環境変数を設定しているのですが，それが設定される順番かなぁなど，色々気になる点が出てきました．とりあえず，色々と調査したので，ここでまとめておきます．

「今回のファイルが問題なら，bash + Wayland では問題にならないのだろう」と思い，ちょっと調査してみた．そしたら，/etc/profile.d/im-config_wayland.sh というファイルを読み込んでいるためだろうなぁ．ということがなんとなく分かった．つまり，zsh + Wayland がやっぱり本現象の原因なんだろうなぁと思っている．

この辺のGUIのログイン評価順ってどうなっているんだろうなぁと疑問に思いつつ，一旦筆を置くことにした．

もしも，手助けしていただける方がいらしたら，嬉しいと思います．
CloudFrontでALBをオリジンにする際のあれこれ

## はじめに
CloudFrontからWordpressを配信する際に詰まった点を挙げていきます。
作成方法は以下をご参照ください。
[Wordpress環境を進化させたい（構成編）](https://qiita.com/Ryuta_Uchimura/items/f053620ec21f7f91e129)
[Wordpress環境を進化させたい（構築編）](https://qiita.com/Ryuta_Uchimura/items/5eac51f443e2954ebd13)

### ネームサーバーの更新
独自で発行したドメインをRoute53に登録する際にホストゾーンを作成すると思います。Route53はNSレコードで自動でネームサーバーを提供してくれますが、登録済みドメインのネームサーバーと一致していない場合、ドメインが機能しなくなります。

![スクリーンショット 2025-02-08 121913.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3812406/563fbade-b79f-e563-3e93-c826f69791dc.png)
![スクリーンショット 2025-02-08 121841.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3812406/6cad8bfc-638c-4551-5c3b-97b0e0cf77c5.png)


### オリジンの設定
Route53 AレコードのエイリアスでALBにルーティングした場合にはオリジンドメインはALBが提供するDNS名ではなく、紐付けた独自ドメインを設定する必要があります。
![スクリーンショット 2025-02-02 160345.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3812406/b204292f-f5a6-a687-7cf3-f1a2d6517888.png)

### Wordpressのconfig
もし管理画面にアクセスできず、wordpressのGUIでドメインを指定できない場合はwordpressインストール先のconfigファイルで指定することができます。
```
define('WP_HOME','https://xxxxxxxx.com');
define('WP_SITEURL','https://xxxxxxxx.com');
```
## 最後に
次回は同じ環境を作成できるCloudFrontのテンプレートを作成してみたいと思います。
Excelから取得した1900年代の日付がListsに転記したときに1日減る事象について


# Excelの日付に関する使用上の問題
Power Automateを業務で使っているみなさまはExcelの日付データをPower Automateで取得してListsに転記する、というシチュエーションは結構あると思います。

今回は、実務ではあまり起こりにくいものの、市民開発者として知っておいて損はないExcelの仕様についてご紹介します。

## 前提
Excel上のテーブルから日付を抽出しListsに転記する、というケース

## 事象
1900年1月5日、1900年2月10日など1900年の特定の日付を転記しようとしたときにLists上で1日減算されて転記される。

## 再現
Power AutomateでExcelの日付データをSPO Listsに転記するフローを作成して、事象を再現します。

まず下図のようなExcelデータを用意し、onedriveに格納しておきます。
![スクリーンショット 2025-01-31 003826.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939914/45269de0-d2a0-48f2-906c-4914a5434c82.png)

日付、曜日、名称列があるテーブル「日付テーブル」を作成しました。

次に、同じ列名の転記先のListsを用意しておきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939914/931d532e-9cd2-ad3b-a03a-5ac7396bd1e2.png)

:::note info
「タイトル」列がデフォルトで作成されますが、ここでは使用しません。
:::

次にPower Automate クラウドフローをこんな感じで作成します。

Excelのテーブルからデータを取得してListsに転記するシンプルなクラウドフローです。

Excelからのデータ取得のパラメータ
![スクリーンショット 2025-01-31 005152.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939914/67ab6dbf-8ed3-4c75-2c2e-6fb0fd4131e0.png)



Listsへ転記するアクションのパラメータ。Apply to eachは自動で作成されます。
![スクリーンショット 2025-02-08 120935.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939914/b1e2d68d-d4d4-fe32-e918-329801314cac.png)

この状態でテストすると、「日付が正しくない」と怒られました。
![スクリーンショット 2025-01-31 005448.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939914/fb576862-a18d-bc54-7e88-debec28374c3.png)

最初に処理したレコードだけアクションの実行に失敗したようです。Listsの転記結果を確認してみましょう。

![スクリーンショット 2025-01-31 005522.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3939914/d8e5a40a-c3b2-3557-6cc2-3e112d5c4d22.png)

名称を「テスト」にしたレコードが転記されていませんね。そしてテスト2、3、4の日付が1日少なくなっています！！これが今回の事象です。

# 原因
これは、「1900年2月29日という本来存在しない日がExcel上に存在する」ことが原因で発生しています。下記の記事が大変参考になります。

https://www.relief.jp/docs/001333.html

つまり、今回の事象の発生要因は下記の通りです。

**1\.日付が1日減った状態で転記される**
⇒転記元となっているExcelの仕様の問題。Excelでは1900年2月29日という存在しない日付が存在する関係で、それ以前の日付が1日減算された状態で転記されたため。

**2\.1900年1月1日の日付のレコードが転記できない**
⇒1900年2月29日以前の日付であるため、日付が1日減った状態で登録されようとしているが、Listsに転記できるのは1900年1月1日の日付からであり、1899年12月31日のデータは登録できないため。

:::note info
1900年2月29日（実際には存在しませんが）以前の日付が入力されているばあいは1日分日付を加算する処理を加える必要があるので注意しましょう。
:::

~~19世紀の日付を扱うことなんてねえよという至極当然の突っ込みは無しでお願いします。~~
ReactでDOM操作を行う方法

**Reactでは通常、DOM操作はuseStateやuseEffect、あるいはコンポーネントの再レンダリング機能を利用して行うのが基本です。しかし、どうしても直接的にDOM要素を操作しなければならないケースも存在します。この記事では、そんなケースにおいてReactでDOM操作を行ういくつかの方法について解説します**。

# 1. Refsを利用する

DOM操作を行う上で最も一般的な方法として、ReactのRefを利用する手段があります。Refを使うと、DOM要素やReactコンポーネントへの参照を取得できます。

サンプルコード
```Typescript
import React, { useRef, useEffect } from 'react';

function DomManipulationExample() {
  const inputRef = useRef(null);

  useEffect(() => {
    if (inputRef.current) {
      // DOM要素に直接アクセスできる
      inputRef.current.focus();
    }
  }, []);

  return (
    <div>
      <input type="text" ref={inputRef} placeholder="自動でフォーカスが当たります" />
    </div>
  );
}

export default DomManipulationExample;
```

useRefを使ってinputRefを作成します。

useEffectでマウント後にinputRef.currentにアクセスし、実際のDOM要素を操作します。

Reactでは通常、コンポーネントの再レンダリングを通じてUIを更新しますが、Refを使うことで必要に応じて直接DOMにアクセスできます。

# 2. useLayoutEffectの利用

useLayoutEffectは、DOMが変更された直後に実行されるフックです。ユーザーが画面を見たり操作したりする前にDOMを同期的に更新したい場合に使用します。useEffectとはタイミングが異なるため、アニメーション等を行う際にはuseLayoutEffectの方が向いている場合があります。

サンプルコード
```Typescript
import React, { useRef, useLayoutEffect } from 'react';

function LayoutEffectExample() {
  const divRef = useRef(null);

  useLayoutEffect(() => {
    if (divRef.current) {
      divRef.current.style.backgroundColor = 'lightblue';
    }
  }, []);

  return (
    <div ref={divRef} style={{ width: '100px', height: '100px' }}>
      useLayoutEffectを使ったDOM操作
    </div>
  );
}

export default LayoutEffectExample;
```
useLayoutEffect内で直接DOM操作を行うと、描画が行われる前にDOMを更新できます。これは描画タイミングを厳密に制御したいケースに有効です。

# 3. Reactの哲学との整合性について

Reactは、宣言的UIを提供するフレームワークであり、頻繁な直接DOM操作は推奨されません。基本的には状態（state）を変更することでコンポーネントの再レンダリングをトリガーし、これによってUIを更新するアプローチをとるのが望ましいです。過度なDOM操作は、以下のような問題を引き起こす可能性があります。

・Reactの仮想DOMと直接操作したDOMとの不整合

・メンテナンス性の低下

・パフォーマンスの問題

そのため、直接DOM操作はあくまでも最後の手段と考え、以下のような時に限定的に使用すると良いでしょう。

・既存の外部ライブラリを利用する際にやむを得ずDOM操作が必要になる

・フォーカスの制御など、UIイベントを迅速に反映したい

CanvasやSVGなどの特殊な操作（ほかのライブラリとの連携が必要）

# 4. まとめ

Reactでは、宣言的UIを基本とした状態管理による描画更新が推奨されますが、どうしてもDOMを直接操作したいケースでは、RefsやuseLayoutEffectを活用できます。ただし、DOM操作とReactの仮想DOMとの間で整合性が保てなくなるリスクがあるため、設計上しっかりと意図を明確にし、必要最小限の範囲にとどめることが重要です。
node index.tsが成功したので調べてみた

### きっかけ
https://qiita.com/hirokidaichi/items/27c757d92b6915e8ecf7#%E7%BF%92%E6%85%A3%E3%81%AE%E5%8A%9B
この記事を読んでTypeScriptをVsCode上で実行することに興味を持ちました。

普段Chrome拡張機能の開発を行っているのですが、ビルド→拡張機能再読み込み、Webサイト再読み込み→開発者ツールでブレークポイント設定→値を確認という開発サイクルをとっており、効率の向上ができると思いました。

### 調査
vscode上でTSファイルを実行するために、`ts-node`か`tsc`というコマンドをインストールする必要があることを知りました。

`ts-node`は直接TSファイルの実行ができます。　
`ts-node index.ts`
index.tsの中身のconsole.logが実行されたことを確認できました。

`tsc`はTSファイルをJSファイルにコンパイルします。
`tsc index.ts`
index.jsが生成されることを確認できました。
`node index.js`
console.logが実行されたことを確認できました。

### 疑問
試しに`node index.ts`をしてみました。
node上ではTSファイルの実行ができないはずなので、エラーを確認したかったです。
しかし、index.tsの中身のconsole.logが実行されました。

### 確認したこと
・`env | grep NODE`環境変数を見てもnode でts-nodeを参照しているわけではないです。
・package.jsonも確認しましたが、npm init -yしてから何もインストールしていないので初期状態です。

```
{
  "name": "20250208_node",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}
```

・npm list -g
グローバルインストールもしてないです。
```
/Users/hogehoge/.nvm/versions/node/v16.20.2/lib
├── corepack@0.17.0
└── npm@8.19.4
```

### 解決
・TypeScriptの機能を使ったコードを書いてみる
```
// index.ts
interface User {
    name: string;
    age: number;
}

const user: User = {
    name: "Test",
    age: 20
};

console.log(user);
```
![スクリーンショット 2025-02-08 12.40.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3505174/503a16fd-8a0f-9b91-9b39-ff377aa713cf.png)

失敗しました。これが原因のようです。
node index.tsとしても書かれているコードが純粋なJSとして解釈できるものだったら実行されるようです。
識別子とは関係なく、ファイルの中身を JavaScript として解釈しようとすることがわかり勉強になりました。
dockerでreactをやりたくて勘違いしていたこと

## nodeコンテナが立ち上がらなかった
laravelのようにコンテナを立ち上げた後にプロジェクト作成すると思っていて、
空のディレクトリでコンテナを起動しようとしていた。

## 解決方法
まず、ローカル環境でreactプロジェクトを作製する。
```
npm create vite@latest
```
そうすると普通にnodeのコンテナが立ち上がるようになる。
【プラクティス紹介】1分でさらっと分かる「Tシャツ見積り」

![T_shirt.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3526800/47026c0a-0fc8-3fd1-5936-f71bf1fd65c2.jpeg)

## プラクティス名（別名）
Tシャツ見積り　（T-shirt sizing、アフィニティ見積り、サイレントグルーピング、相対見積り）

## プラクティスの目的・狙い
* 迅速にタスクの作業量/総量を見積もる
* どの要件が重め/軽めなのか所感を共有する

## どんな時に使うか
* 短時間で概算見積りを行う必要がある時
* 初期段階で要件が未確定（または変わる可能性が高い）のため、精緻に見積もれない時
* 他の見積り手法を使うといつも議論が長引いて、時間がかかってしまう時

## 実施手順
1. ユーザストーリーが書かれたカードとボード（XS/S/M/L/XL）を用意する
1. 見積り基準とするユーザストーリーを１つ選び、Ｍサイズに置く（＝リファレンスストーリー）
1. 全員で手分けして残りのカードを基準と比較しながら、各エリアに移動させる
　**※この作業は黙って行い、深く悩まずに直感で見積る**
1. 全てのカードが配置されたら、バランスを見て、違和感がある箇所はカードを移動する
　**※この作業も黙って行い、1人1枚ずつ順番に行う**
1. 誰もカードを移動する人がいなくなったら見積りは終了

| サイズ | リファレンスと比較して |
|:-:|:-:|
| XS  | すごく小さい  |
| S   | 小さい  |
| M   | だいたい同じ  |
| L   | 大きい  |
| XL  | すごく大きい  |

:::note info
リファレンスストーリーは中規模のサイズで、作業内容が明確にイメージできるものを選ぶとよい
:::

:::note warn
サイズ調整の段階で、何度も同じエリアを往復するカード（互いに譲らない）が発生した場合は一旦、中間に配置しておき、後で話し合いで解決するようにします
:::

## アレンジ例
* より迅速に見積るため「XS」「XL」を無くし「S/M/L」の3段階にする
* より詳細に見積るため「XXS」と「XXL」を足し、7段階とする
（なお人間特性上それ以上は細かくしない方がよい）
* サイズを一定のルール（変換表）でストーリーポイントに変換する
　　例：XS=1sp、S=3sp、M=5sp、L=8sp、XL=13sp

## アンチパターン
* カードを移動する段階で相談や議論をはじめてしまい、結局、短時間で終わらない

## 参考情報
sekinetさんの記事ではより詳しく解説されています。Ｔシャツ見積りのメリデメや数値見積りとの比較など、より詳しく知りたい方にオススメです。

https://qiita.com/sekinet/items/571054a3b064c502186c

こちらの動画も絵と動きで直感的に理解できるので、分かりやすいです

https://youtu.be/qYpxwICFmNU

## こぼれ話（私的コメント）
同じMサイズ表記のＴシャツでも、日本製と海外製では結構大きさが違ったりしますよね。まぁそれでもＴシャツだとなんとか着れてしまうという、そこらへんのユルさというか気楽さがこの見積り手法のイメージとぴったり一致していて好きです。あくまでもＴシャツ見積りであって、Ｙシャツ見積りではない、という。

なお一般的には基本の3サイズ「S/M/L」に「XL」（エピック？）を足した4段階が多いようですが、個人的には「XS」があった方がMサイズを中心に全体のバランスを見やすいと思うので、本稿では5段階を採用しました。開発の初期段階ではXSと言い切れるほど明確な要件は少ないかもしれませんが。

---
　[アジャイルプラクティス一覧へ戻る](https://qiita.com/kakashi_h5/items/20584998c5ca4594b9ea)
【プラクティス紹介】1分でさらっと分かる「プランニングポーカー」

![plan_poker.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3526800/ff4b92e6-4273-68d6-27ae-a00821b836f3.jpeg)

## プラクティス名（別名）
プランニングポーカー　（見積もりポーカー、相対見積もり）

## プラクティスの目的・狙い
* 開発者の知見を集約し、手早く開発規模を見積る
* 開発者の作業イメージを揃える（認識ズレを是正する）

## どんな時に使うか
* ユーザストーリーの実現に必要な作業量（ストーリーポイント）を明らかにしたい時
* 声の大きな人の意見に偏らずに皆の意見を集約したい時
* 見積り作業をゲームのように楽しみながら行いたい時

:::note info
そもそも『[ストーリーポイント](https://qiita.com/kakashi_h5/items/e41915f097762ffdaa1d)』とは何か？については別記事の方で解説しています。「プランニングポーカー」や「Tシャツ見積り」といった"相対見積り"がなぜ有効に機能するのかという原理についてはそちらを参照下さい。
:::

## 実施手順
1. 見積り参加者に1セットずつ見積り用のカードを渡しておく
 ※カードには「1/2/3/5/8/13/...」とフィボナッチ数が書かれている
1. 進行役が見積対象PBIの内容を読み上げる
1. 実装方針に不明点や疑問点があれば質問し、見積り前提をクリアにする
1. 見積れた人はカードを伏せた状態で場に出す（他の人の判断に影響しないように）
1. 全員出揃ったら、せーので一斉にカードをオープンする
1. 一番大きな数字と小さい数字を出した人に、その理由を説明してもらう
1. 説明を踏まえ、再考し、再度全員でカードを出し直す
1. 全員の数字が一致するまで6～7を繰り返す

:::note warn
何度繰り返しても数字が一致しない時は3回程度で切り上げましょう
:::

:::note warn
ファシリテーターは少数派が「間違った数字を出した人」という印象にならないような雰囲気作りを行って下さい。実際、その人は皆が見落としていることに唯一気づけた人かもしれません。
:::

## アレンジ例
**カードの種類を追加する**
* 「0」⇒ 意味：1spにも満たないすぐに終わる雑務
* 「?」⇒ 意味：情報が少なすぎて見積もれません（or見当もつかない）
* 「∞」⇒ 意味：粒度が大きすぎるので、もっと分割したい（＝エピック）
* 　　　　　　　※13以上をエピックとする場合もある
* 「☕」⇒ 意味：疲れたのでちょっと休憩しませんか？

**オンラインで行う場合**
* zoomなどの場合、せーので一斉に会議チャットに数字を投稿する
* miroなどの場合、共有ボード上にあらかじめ「Ready」「1」「2」「3」「5」「8」...のエリアを設けておき、せーので自分のカーソルやアイコンを「Ready」から数字に移動させる
* プランニングポーカー用のツールを使う（ブラウザで使える無料サイトなどもある）

## アンチパターン
* 全員一致にこだわりすぎて時間がかかる
* 場に少数派に対する無言のプレッシャー（同調圧力）が漂っている
* 「5」と「8」の人が半々なので、間とって「6.5」にする。（＝認識合わせになっていない）

## 参考情報
参考書籍

https://tatsu-zine.com/books/agile-estimating-planning

以下の技術ブログが、ポーカーの雰囲気が分かりやすく書かれていて、オススメです。

https://appresso.hatenablog.com/entry/2016/08/03/181355

## こぼれ話（私的コメント）
作業量が数値化されることよりも、ポインティングを通してDEVの認識が揃う方が個人的には重要と感じています。その場で、どっちの方式で実装する？とか、エラーハンドリングはどこまで？みたいな話が決まっていくこともあるので、設計の要素も含んでいます。また参加者の性格や経験値が如実に表れる場でもあるので、観戦者として見ているだけでも面白いです。けいけＮから初心者への教育の場になったりもします。

ちなみにプランニングポーカー用のカードはトランプで代用することも可能（1組で4人まで）ですが、あまりオススメはしません。理由はトランプを使っていると、知らない人が見た時に「職場で遊んでいる」と誤解されてしまう危険性があるからです。:sweat_smile:

---
　[アジャイルプラクティス一覧へ戻る](https://qiita.com/kakashi_h5/items/20584998c5ca4594b9ea)
UIデザインの教科書 を読んだのでChatGPTと一緒に要点を整理する

## 1. デザインの目的と UI/UX
- **デザインとは設計のこと**
- **UI (User Interface) とは**：ユーザーとデバイスの接点  
- **UX (User Experience) とは**：ユーザーがサービスから受ける全ての体験  
- **UIとUXは別の概念**
  - UIは **客観的**
  - UXは **主観的**

## 2. 物理的制約
- **インターフェースの起点は、デバイスとの物理的な接触から始まる**
- **入力手段の違いが、インターフェースデザインに根本的な影響を与える**
  - **PC**：ホバーが使える
  - **スマホ・タブレット**：ホバーが使えない
  - **PC・スマホ・タブレット**：対象を直接選択する  
  - **TV**：フォーカスを移動して選択する
- **デバイスによる違い**
  - **画面との距離、画面の大きさ、向き**が異なる  
  - **画面の大きさとアスペクト比は固定であり、変えられない**
- **AndroidとiOSの大きな違い**  
  - **戻るボタンの有無**

## 3. ソフトウェアの影響
- **アプリとWebサイトでは最適なUIが異なる**
  - アプリ：OSごとに異なる  
  - Webサイト：環境によらず共通
- **画像の種類による影響**
  - **ラスターデータ画像 (JPG, GIF, PNG)**：解像度の考慮が必要  
  - **ベクター画像 (SVG)**：解像度によらず最適に表示される
- **テキストデータ**：解像度の影響を受けず最適に表示される  
- **パフォーマンス最適化を考慮する**（素早く表示されるように）

## 4. 人間の認知特性（具体例付き）
- **色・形・動きの認知は生得的能力**
  - 例：赤いボタンは「警告・注意」を示しやすい（例：削除ボタン）。

- **インタラクションコストを最小にするのが良いデザイン**
  - 例：ログインフォームで「パスワードを表示」ボタンを追加することで、入力ミスを減らす。

- **共通概念を活用する（逆らうと認知負荷が増す）**
  - 例：「ゴミ箱」アイコンを削除ではなく「保存」に使うと混乱を招く。

## 5. 階層と構造
- **アプリやWebサイトは、縦・横・前後の立体的構造を持つ**
- **インタラクションは前後関係の理解に役立つ**
- **現在地の表現方法**
  - 太さ・色・大きさ・背景色・目印
- **一覧の操作方法**
  - **絞り込み・並べ替え・切り替え**

## 6. ナビゲーションとインタラクション
- **ナビゲーションとは、インターフェースの集合体**
- **最適なナビゲーションは以下の要素で変わる**
  - **コンテンツ量**
  - **画面の自由度**
  - **入力手段**

## 7. デザインを形にする（具体例付き）
- **ミニマルデザイン**
  - **押せる場所を判別できるようにする**
- **デザインガイドライン**
  - **形骸化しないように運用する**
- **プロトタイプ・モックアップの注意点**
  - **作り込みすぎない**
    - **NG例**：最初のプロトタイプでデザインを完璧にしようとして時間をかけすぎる  
    - **良い例**：まずは手書きワイヤーフレームやシンプルなFigmaなどでモックアップを作成し、フィードバックをもらう。それを元に改善していく。
  - **アイデアの価値や方向性を把握する**
    - 例：新しいナビゲーションUIを導入する前に、ユーザーに簡単なテストを実施し、理解しやすいかを確認する。
  - **早めに何度も失敗する**
    - **NG例**：「完璧なデザインを考えてから実装する」と決めると、変更に対応しにくくなる。（サンクコスト）  
    - **良い例**：ABテストを行い、異なるデザインを少人数のユーザーで試しながら最適なUIを決定する。
  - **想定外の問題を解決し、サービスの価値を向上**
    - 例：Google検索の「検索候補表示」は、もともと開発者がテスト中に見つけた使い勝手の改善アイデアから生まれた。（らしい）
【ChatGPT】に、自己認識を深め、思考・感情・習慣を改善する方法を尋ねました。Promptなし。


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

　今回は、自己認識を深め、思考・感情・習慣を改善する方法をChatGPTに尋ねました。

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

　今回は、
　　自己認識を深め、
　　　思考・感情・習慣を
　　　　改善する方法を
　　　　　ChatGPTに尋ねました。

　マイナス思考に陥ると、
　　浮上するのが大変です。

　ちょっとした助言でも
　　前向きになれる場合もあります。

　それで
　　ChatGPTに尋ねてみました。

　それがこちらです。
***
***（ChatGPT）***
### **自己認識を深め、思考・感情・習慣を改善する方法まとめ**


## **1. 自己認識を深める**
### **方法**
✅ **自己対話・ジャーナリング**  
→ 日記を書く、問いを投げかける（例：「私は何が好き？」）  
✅ **価値観を明確にする**  
→ 自分が大切にしていることをリスト化  
✅ **フィードバックを活用**  
→ 他者に「私ってどんな人？」と聞いてみる  
✅ **心理テストを活用**  
→ MBTI・エニアグラムで自己理解を深める  
✅ **新しい経験に挑戦**  
→ 未経験のことを試し、自分の新しい側面を知る  
✅ **瞑想やマインドフルネス**  
→ 感情を客観的に観察する習慣をつける  


## **2. 感情のパターンを探る**
### **方法**
✅ **感情日記をつける**  
→ その日の出来事・感情・トリガー・行動を記録  
✅ **感情の共通点を分析する**  
→ 「よく感じる感情」「特定の状況での反応」を把握  
✅ **トリガーを理解し対処法を考える**  
→ 「なぜこの感情が出るのか？」を掘り下げ、対応策を考える  
✅ **マインドフルネスで感情を客観視する**  
→ 感情に振り回されず「今の自分」を観察する  


## **3. 思考の癖を探る**
### **方法**
✅ **思考を記録する（ネガティブ思考を特に意識）**  
→ 「状況」「思考」「感情」「行動」をセットで記録  
✅ **認知の歪みをチェック**  
→ 「全か無か思考」「自己否定思考」などを見つける  
✅ **過去の出来事を振り返る**  
→ どんなときに、どの思考パターンが強く出るのか分析  
✅ **フィードバックをもらう**  
→ 他者から見た「思考のクセ」を知る  
✅ **思考を修正する**  
→ 「事実」と「解釈」を分ける、ポジティブな視点を探す  


## **4. 自己評価を見直す**
### **方法**
✅ **現在の自己評価を書き出す**  
→ 「自分はどんな人間か？」を言語化  
✅ **認知の歪みをチェック**  
→ 自己評価を低くしている思考パターンを探る  
✅ **他者の視点を取り入れる**  
→ 「私の強みは何？」と周りに聞く  
✅ **成功体験を振り返る**  
→ 過去の「できたことリスト」を作る  
✅ **「結果」以外の視点で自己評価をする**  
→ 「成長」「努力」「周囲への影響」も評価基準に  
✅ **ポジティブな自己対話をする**  
→ 自分への言葉を「励まし」に変える  


## **5. 習慣と思考の関係を探る**
### **方法**
✅ **現在の習慣を記録する**  
→ 「どの思考が、どの習慣を生んでいるか？」を分析  
✅ **思考が習慣に与える影響をチェック**  
→ ネガティブ思考が悪習慣を生みやすい  
✅ **習慣が思考を強化する影響をチェック**  
→ 「運動すると自己肯定感が上がる」などの関係性を探る  
✅ **ポジティブな思考と習慣のサイクルを作る**  
→ 「感謝日記を書く→前向きになる」「小さな成功体験を積む→自信がつく」  
✅ **習慣を変えて思考を再プログラムする**  
→ 1日5分の習慣を追加し、思考を少しずつ改善  


## **6. すべてをつなげて実践する**
### **ステップ**
1️⃣ **自己認識を深める** → 自分の考え・感情・価値観を知る  
2️⃣ **感情のパターンを探る** → 日記をつけ、トリガーを分析  
3️⃣ **思考の癖を探る** → ネガティブ思考を記録・修正  
4️⃣ **自己評価を見直す** → 成功体験を振り返り、ポジティブな視点を増やす  
5️⃣ **習慣と思考の関係を探る** → どの思考がどの習慣を作っているかを分析  
6️⃣ **ポジティブな思考・感情・習慣のサイクルを作る**  


### **結論**
✅ **思考・感情・習慣はすべてつながっている**  
✅ **まずは記録・観察し、パターンを探ることが重要**  
✅ **小さな変化（習慣の改善・思考の修正）から始める**  
✅ **ポジティブなフィードバックを積み重ねると自己認識が向上する**  

**→ まずは「記録する」「小さな成功体験を積む」ことから始めてみましょう！**
***

　あなたの琴線に触れることがあれば、
　　そこを深堀りしてみてください。

　きっと何かしらの
　　ヒントがあるはずです。　　

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

　今回は、ここまで。
【勉強記録】ChatGPT o3-miniを使ってみた

# はじめに
こんにちは。アメリカ在住で独学でエンジニアを目指している者です。
ソフトウェアエンジニアになるための、勉強でChatGPTをよく使用していますが最近o3-miniが出たのでどんな感じで使っているかをまとめてみたいと思います。

## 使ってみた感想
以下はあくまでも私の感想なので参考程度にしてください
* 4o: 質問をざっくり理解し解答する。自分が意図している質問が誤った意図で伝わった場合に思考過程がないのでかなり違う方法に行ってしまう
* o1: しっかり考えて整理して解答する。思考過程があるので誤った方向に行ってもどういう意図でその方向に行ったかがわかるので使いやすい。漠然とした表現ですが解答に忠実に答えるまじめな感じ
* o3-mini: o1同様思考整理の過程があってo1よりもスピーディかつ端的に解答してくれる。ただし、端的過ぎてたまに途中で解答をやめてしまうこともある
* o3-mini-high: コードや論理系に関するモデルみたいですが、かなり複雑な質問を投げても論理が整理つくまでしっかり考えて答えを返してくれる。

これはすべてのモデルに言えることですが、web検索しているが若干情報が古かったり正しいライブラリを参照できていない場合もあるので、その場合は自分で手を動かす必要があります。

## どのように使うことが多いか

エンジニアでやられている方はたくさん使っていると思いますが、わたしもChatGPTは毎日使っていてPlus版にアップグレードしています。
日常づかいはo3-miniかo1を使ってかなり複雑な場合はo3-mini-highを使用しています
以下に私がAIを使用してやっていることをまとめます
* Rubyの演習(o1)
* Rails、Ruby、JavaScript、Linuxなどわからないことをプロジェクトごとに分けて管理(o3-mini)
* Qiitaの記事作成の補助(o1,o3-mini)
* 勉強計画の作成(o3-mini-high)
* 独学をする上でのモチベーション管理(o3-mini)
* 自動化スクリプト等の複雑なコード作成(o3-mini-high)

特にプロジェクトに分けて質問をためることができるのはとても便利で、言語に関してわからないことは毎日あるのでかなりの頻度で使用しています。なのでサーバーダウンされるとかなりの痛手ですね


## まとめ
本日はChatGPT o3-miniについての記事でした。AIがなかったらこんな勉強継続できたか正直怪しいなと思います。
プログラミングの挫折率90％っていわれていますがAI登場してからはもっと減ったんじゃないかなと思っています。
今後あげる予定のGitHub Actionsを使用したシステムをこれらをフル活用して作成しました。
直近でもDeep Thinkingが発表されてまだ使用できていませんが今後使えるようになるのが楽しみです。
DeepSeekをローカルで軽量動作させる理由とは？少ない容量で動かせる仕組み

**ローカル環境でLLMを動かす時代へ──驚きと疑問**

最近、DeepSeekを Ollama を使ってローカル環境で動かしてみました。
クラウドではなく、自分のPCでLLM（大規模言語モデル）を動かすという体験は、まるで「誰のものでもない、自分だけのAIを手に入れたような感覚」を味わわせてくれました。

インターネットに繋がなくても推論ができる。
自分のデータを自由に扱える。
応答速度も意外と速い。

「ローカルAIの時代が来た！」 そう思うとワクワクせずにはいられませんでした。

しかし、そこでふと疑問が湧きました。

「こんなに大規模なLLMが、たった数十GB（軽いものでは数GB）で収まっているのはなぜだろう？」

元々、LLMは数百GB、場合によっては数TBもの膨大なデータを使って学習されているはずです。それにも関わらず、ローカルで動かすモデルのサイズは驚くほどコンパクト。

どうしてこんなに小さくなるのか？ 精度には影響がないのか？

自分なりに調べてみました！
# 先に結論から
先に結論から入ると近年の大規模言語モデルには**量子化**という手法を用いてファイルサイズを削減しています。

# 量子化とは
学習済みモデルの重み(パラメータ)をより少ないビット幅(例:4bitや8bit)で実現し直すことで、モデルのサイズとメモリ使用量を下げる技術。

**例 :** 16bit浮動少数点数で140億パラメータ(14B)ある場合、単純計算すると、少なくとも約28GB程度のサイズが必要にな理がちですが、**4bit量子化**にすると理論上1/4のサイズになって、約7GB前後に圧縮することができる。(多少オーバーヘッドがあるのでサイズが増えることが多い)

※量子化について詳しく説明されている記事を以下に添付しておきます。
[https://www.cloudflare.com/ja-jp/learning/ai/what-is-quantization/](http:)

# 量子化でサイズを圧縮すると精度はどうなる？
通常はある程度の精度低下が生じる。

しかし最近の量子化手法では推論性能をそこまで大きく落とさずに、モデルサイズを大幅に削減できるらしい...
(まだ勉強不足でなぜ落ちないかはまだわからない)

# 他にも容量が少なくて済む理由が
**推論に最低限必要なデータのみを使用**
- 推論に必要な"重み"だけをまとめた軽量ファイル形式(ggmlなど)が活用されている

**llama.cppベースの最適化(CPU推論の効率化)**
- DeepSeek R1 14B なども llama.cpp のエンジンを利用して推論可能な形で提供されている（Ollama を通じて動かすなど）
- llama.cpp は CPU（特に Apple Siliconなど）での高速実行を想定しており、NEON / AVX などのSIMD命令をフル活用している
- 量子化 + CPU最適化により、GPU なしでも「比較的実用的な速度」を出せる

# まとめ
- DeepSeek や Llama 系モデルをローカルで動かすときに必要なストレージが少なく、かつ推論がそこそこ動く要因は、「4bit/8bit量子化」や「推論専用の軽量化されたファイル形式」が普及していることが大きい。
- llama.cpp (Ollama) は CPU 上での推論を効率化する仕組みを備えており、Apple Silicon では特に相性が良い（CPUのSIMDや行列演算ユニットを使える）
- その結果、GPUなしのノートPCでも 9GB ほどのファイルを読み込んで 14B 級のモデルが動かせるようになっている。速度は高性能GPUに劣るものの、対話用途や軽いテキスト生成には実用的なレベル

# 最後に
最後まで読んでいただき、ありがとうございました！

DeepSeek のローカル実行には夢があります。
自分のPC上で動かせるということは、誰にも依存せず、自分だけのAIを持つことができるということ。さらにカスタマイズすれば、例えば 関西弁で返答するモデル を作ったり、ChatGPT の「MyGPT」のようなパーソナライズされたAIを作ることもできるかもしれません。

しかも、量子化技術のおかげで GPUなしのノートPCでも実用的に動く というのは本当に魅力的です。せっかくの環境なので、私も色々試して使い倒していこうと思います！

これからもローカルAIの可能性を探求していきましょう。
ぜひ、皆さんも試してみてください！🚀
Windowsの共有フォルダの作り方

# はじめに
仕事中に共有フォルダの作成を頼まれ、2時間ほど悩んでしまった(もったいない)。その時の備忘録をまとめる。

# 共有フォルダとは
ファイルのバックアップや共有ができるWindowsの基本機能のこと。
ファイルをメールなどで送受信する手間がない。

# 確認すること
- 同じネットワークに所属しているか
- 設定からネットワーク設定をプライベートネットワークにする(パブリックネットワークになっていると共有フォルダにアクセスできない)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528926/6e1cddcd-08e1-ea6d-f9fc-44387521f051.png)

- コンパネからプライベートエリアのネットワーク探索とファイルとプリンターの共有を有効にする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/528926/89315572-6664-4bc8-5a24-ce83c71d98f4.png)
- 共有したいフォルダに共有設定する(この時Everyoneグループを追加しないとアクセスできない)
- 共有したいネットワークアダプタのNetBIOS設定が有効か
- TCP/IP NetBIOS Helperサービスが動作しているか
【Docker】GnuPG で署名鍵ペアをパスフレーズなしで作成する【Alpine ベース】

CI やテストなどで、検証のために <font color=darkorange>**PEM 形式の OpenPGP 署名鍵を `docker` で作成したい**</font>。使い捨て目的の、Alpine Linux ベースで動作する署名鍵の生成シェル（ash 対応）スクリプトと実行例です。

作成される鍵は、パスフレーズなしの Ed25519 です。

:::note info
ちなみに、ローカルで実行したい場合は、以下の通り。詳しくは、下部にある `gen_key_pairs.sh` を参考にしてください。

- 鍵のアルゴリズム: `default` （= `Ed25519`, gpg のデフォルト）
- 鍵の使用目的: `default` （= `cert` & `sign`, gpg のデフォルト）
- 鍵の有効期限: `0` (なし。無期限）

```bash:ローカルで実行する場合のコマンド（パスフレーズなし）
gpg --batch --expert --quick-gen-key --passphrase '' "MyName <my_name@example.com>" default default 0
```
:::

```bash:gen_key_pairs.sh のあるディレクトリで実行
docker run --rm \
    -w "/data" \
    -e TEST_ID="YourName <your_name@example.com>" \
    -v "$(pwd)":/data \
    alpine:latest \
    /bin/sh /data/gen_key_pairs.sh
```

```shell-session:実行例
$ ls
gen_key_pairs.sh

$ docker run --rm -w "/data" -e TEST_ID="YourName <your_name@example.com>" -v "$(pwd)":/data alpine:latest /bin/sh /data/gen_key_pairs.sh
**snip**

$ ls
gen_key_pairs.sh	gpg-ed25519-public.pem	gpg-ed25519-secret.pem
```

下記 `gen_key_pairs.sh` スクリプトは、GnuPG（`gpg`）でパスフレーズなしの `Ed25519` 署名鍵を作成し、マウントされたディレクトリ（スクリプトと同じ階層）に PEM 形式（OpenPGP 互換）の公開鍵と秘密鍵が作成されます。

```shell:gen_key_pairs.sh
#!/bin/sh

# Note: This script is intended to be run inside the Alpine Linux-base Docker
# container.

set -e

# Install GnuPG
apk add --no-cache --no-progress --quiet gpg gpg-agent

# Define arguments
testID="MyName <my_name@example.com>" # default value
[ "${TEST_ID:+defined}" ] && {
    echo "* TEST_ID is defined"
    testID="${TEST_ID}"

    echo "  * User ID: ${testID}"
}

algo=ed25519 # --> equivalent to "default"
usage=sign # --> equivalent to "default". "cert" is by default on, so add "sign" to be "SC"
expire=0
nameFilePubKey="gpg-ed25519-public.pem"
nameFileSecKey="gpg-ed25519-secret.pem"

echo "* Generating a key pair ..."
# Generate a key pair
# Usage:
#   gpg [options] --quick-generate-key USER-ID [ALGO [USAGE [EXPIRE]]]
# --batch : non-interactive
# --expert : extra options
gpg --batch --expert --quick-gen-key --passphrase '' \
    "$testID" \
    $algo \
    $usage \
    $expire

# Print for debugging. Be careful with the output.
echo "* Public Key info"
gpg --list-public-keys "$testID"

echo "* Private Key info"
gpg --list-secret-keys "$testID"

# Export the public key to a PEM file
gpg --armor --export "$testID" > $nameFilePubKey

# Export the private key to a PEM file
gpg --armor --export-secret-keys "$testID" > $nameFileSecKey

```

## 併せて読みたい

- `man gpg`
- [GnuPG チートシート（簡易版）](https://zenn.dev/spiegel/articles/20200920-gnupg-cheat-sheet) @ zenn.dev
- [GnuPGによる鍵対の生成と管理](https://mitome.in/email/keymanagement.html) @ mitome.in

## 動作環境

- OS: macOS 12.7.6, 21H1320
- Docker version 27.5.1, build 9f9e405
- Image OS: Alpine Linux v3.21
    - gpg (GnuPG) 2.4.7
    - libgcrypt 1.10.3
【Vercel × GitHub Actions】An unexpected error occurred in pull: TypeError: Cannot read properties of undefined (reading 'value')の解決方法

# はじめに
`Vercel`と`GitHub Actions`を使って`CI/CD`を行っていた際に、デプロイ時にエラーが発生しました。今回はそのエラーの原因と解決方法についてまとめます。

:::note warn
***この記事は<font color="Red">個人的なアウトプット</font>を目的として作成したものです。そのため、誤った情報や不足している内容が含まれている可能性があります。もし間違いや気になる点がございましたら、ぜひご指摘いただけますと幸いです***。
:::

# 問題
GitHub Actionsの実行時に、以下のエラーが発生しました。

```
An unexpected error occurred in pull: TypeError: Cannot read properties of undefined (reading 'value')
```

![スクリーンショット 2025-02-08 11.03.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3835217/5510d86f-f2e7-7540-60bb-5296a650da21.png)

`Vercel`を利用して`GitHub Actions`経由でデプロイを行っている環境で、このエラーが発生しました。

# 解決方法
このエラーは、Vercelのアクセストークンの有効期限が切れていたことが原因でした。
Vercelのトークンには有効期限を設定できるため、一定期間が経過すると無効になり、GitHub ActionsからVercelへの認証が失敗してしまいます。

## 手順
1. ***Vercelで新しいトークンを発行する***
+ `Vercel`のダッシュボード にログイン
+ `Settings` → `Tokens`に移動
+ 「`Create Token`」 をクリックして新しいトークンを作成
トークンの有効期限を適切に設定し（例: 無期限 or 数か月）、「`Create`」

2. ***GitHub ActionsのSecretsを更新***
+ `GitHub`のリポジトリにアクセス
+ `Settings` → `Secrets and variables` → `Actions`に移動
+「`New repository secret`」 をクリック
+ `Name`を`VERCEL_TOKEN`にし、発行したトークンを入力して保存

1. ***GitHub Actionsのワークフローを再実行***
トークンを更新後、再度`GitHub Actions`のデプロイを実行すると、正常に動作することを確認できました。

https://qiita.com/Kei-dev-1213/items/f48771e78dbbecd46c0e

# 終わりに
`Vercel`のアクセストークンは有効期限を設定できるため、期限切れによるデプロイエラーに注意が必要です。次回は長めの有効期限を設定しようと思いました。

# 参考
『Next.jsプロジェクトをGitHub ActionsでVercelに自動デプロイさせよう！』Qiita

https://qiita.com/Kei-dev-1213/items/f48771e78dbbecd46c0e