OmniAICreator/Qiita-1.07M huggingface dataset:
# ネットワークエンジニアなら知っておきたいFIB/RIBの基礎知識 - 第1回: ネットワークの縁の下の力持ち - FIB/RIBとは


記事を閲覧いただきありがとうございます。
KANGEN Holdingsにてネットワークエンジニアとして従事している山田と申します。

これまでCiscoのオンプレ環境しか経験してきていないという、クラウド全盛の時代としては化石のような人間ですが、、、
そんな自分だからこそ、お伝えできる知識を記事にできたらと思っています。

本連載は「ネットワークエンジニアなら知っておきたいFIB/RIBについて」というテーマで全3回を予定しております。

![Qiita記事用1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951736/044850f3-7aeb-a3b6-f6db-4ff9846548e0.png)


読者ターゲットは「ルーティング設計も経験し普段OSPFやBGPのテーブル、ルーティングテーブルの把握したうえで運用できるようになった」というレベルのエンジニアを対象とします。
普段の業務に対してのレベルアップにつながると幸いです。

## はじめに
普段ネットワークエンジニアとして設計・構築・運用をする際に考えることはなんでしょう。
数多くあるとは思いますが、キャパシティという観点で意識することは何でしょう。
トラフィックはもちろんですが、導入するNW機器において意識すべき**FIB/RIB**という、普段あまり意識されないけれど非常に重要な役割を担っている要素に焦点を当てて解説していきます。


## コントロールプレーンとデータプレーン

FIB/RIBを理解する上で、**コントロールプレーン**と**データプレーン**という2つの要素を理解する必要があります。

- **コントロールプレーン**：ネットワーク全体の制御を行う部分です。ルーティングプロトコル（OSPF、BGPなど）を用いて経路情報を交換し、最適な経路を決定します。
  例：**司令塔** - ネットワーク全体の状況を把握し、どの経路を通るべきか指示を出す
- **データプレーン**：実際にパケットを転送する部分です。コントロールプレーンで決定された経路情報に基づいて、パケットを宛先まで転送します。
  例：**配送業者** - 司令塔の指示に従い、荷物を目的地まで届ける


## FIB/RIBとは何か？

FIB/RIBは、それぞれ
- **FIB (Forwarding Information Base)**： 転送情報ベース
- **RIB (Routing Information Base)**： 経路情報ベース

の略称です。

ネットワークを流れるデータ（パケット）は、目的地まで様々な経路を通って届けられます。
その際、ルーターと呼ばれる機器が「どの経路を通ってパケットを転送するか」を判断します。

FIB/RIBは、この**ルーターがパケットを転送する**ために必要な情報を保持していますが、それぞれ役割が異なります。

### RIB (Routing Information Base)

**RIB**は、**ネットワーク全体の経路情報**を網羅したデータベースです。
ルーターは、RIPやOSPFといった**ルーティングプロトコル**を用いて他のルーターと交換した経路情報や、自分で記述したStaticルートなど全てがこのRIBに格納されます。

例えるなら、RIBは**全国の道路地図**のようなものです。
どこに行くにも、まずはこの地図を見てたくさんある到達可能な道を比較し、どの道を通るのが最適かを判断します。
※最適と判断された経路を業務上ベストパスと呼ぶことが多いように思います。

このRIBは**コントロールプレーン**において動作します。

### FIB (Forwarding Information Base)

**FIB**は、**パケット転送に特化した**データベースです。
RIBから**実際にパケット転送に必要な情報**を抜き出して作成されます。

例えるなら、FIBは**道路地図から目的地までの最適なルートを抜き出したガイドブック**のようなものです。
実際に移動する際には、このガイドブックを見ながら進みます。

このRIBは**データプレーン**において動作します。

## ルーティングテーブルとの関係性

ネットワークエンジニアであれば、**ルーティングテーブル**という言葉はおなじみですね。

ルーティングテーブルは、**パケットの宛先IPアドレス**と、**次にパケットを転送するルーター=ネクストホップ**の対応関係をまとめたものです。

厳密には異なりますが、**ルーティングテーブル＝RIBの**と捉えても現場においては問題ありません。そして重要な点ですが、FIBの元となる情報でもあります。
FIBはルーティングテーブルの中で選抜された**ベストパスの情報**が記載されます。

ルーターはパケットを受け取った際に転送先を知るための参照先が必要となりますが、これがFIBです。
FIB内で宛先IPアドレスを検索し、**実際にパケットを転送するインターフェース**を決定し転送をしています。

★イメージ図
![Qiita記事用2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3951736/bf38669d-8c2f-df0d-f8ad-a79d945487df.png)



## FIB/RIBの重要性

FIB/RIBは、ネットワーク機器における**性能**と**安定性**に大きく影響します。

- **高速なパケット転送**：FIBはRIBを元に最適経路のみが記載されています。FIBによって、受信したトラフィックは選出済みのベストパスに従い転送するのみ＝パケット転送に特化した処理が可能なため(第2回で解説します)、高速な転送が可能です。
- **柔軟な経路制御**：RIBはネットワーク全体の経路情報(RIP,OSPF,Staticなど)を保持しているため、状況に応じて最適な経路を選択できます。
- **冗長性の確保**：複数の経路が存在する場合、RIBは代替経路を保持しておくことで、障害発生時にも迅速に切り替えることができます。



## まとめ

今回は、FIB/RIBの概要と、ルーティングテーブルとの関係性について解説しました。

- FIB/RIBは、ルーターがパケットを転送するために必要な情報を保持するデータベース
- RIBはネットワーク全体の経路情報を網羅したデータベース、FIBはパケット転送に特化したデータベース
- ルーティングテーブルはRIBの一部であり、FIBの元となる情報
- FIB/RIBは、ネットワークの性能と安定性に大きく影響する

次回は、FIB/RIBが実際にどのような場面で活躍するのか、具体的な例を挙げながら解説していきます。
【PySpark】LEFT JOIN時のon句の指定方法による挙動の違いを整理

## 概要
メモ書き的な記事です。PySparkのバージョンの違いでJoin時のエラーを吐く厳しさに違いがあり、その回避のためにJoin時の挙動を整理します。

## 準備
JOIN用のデータフレームを2つ用意。

```Python
from pyspark.sql import SparkSession
from pyspark.sql.types import StructType, StructField, IntegerType, StringType

spark = SparkSession.builder.master("local").appName("JoinTest").getOrCreate()

left_schema = StructType([
    StructField("id", StringType(), True),
    StructField("item_id", StringType(), True)
])
left_data = [
    ("q1", "i1"),
    ("q2", "i2"),
    ("q3", "i3")
]
left_df = spark.createDataFrame(left_data, schema=left_schema)

right_schema = StructType([
    StructField("id", StringType(), True),
    StructField("item_id", StringType(), True),
])
right_data = [
    ("q1", "i1"),
    ("q2", "i2"),
    ("q4", "i4")
]
right_df = spark.createDataFrame(right_data, schema=right_schema)
```

作成されるデータフレームはこんな感じ。

```shell
$ left_df.show()
+---+-------+
| id|item_id|
+---+-------+
| q1|     i1|
| q2|     i2|
| q3|     i3|
+---+-------+

$ right_df.show()
+---+-------+
| id|item_id|
+---+-------+
| q1|     i1|
| q2|     i2|
| q4|     i4|
+---+-------+
```

## left join時のon句指定パターン

### 左右のjoin keyを明示的に指定

```shell
$ left_df.join(right_df, [left_df.id==right_df.id], 'left_outer').show()
+---+-------+----+-------+
| id|item_id|  id|item_id|
+---+-------+----+-------+
| q1|     i1|  q1|     i1|
| q3|     i3|NULL|   NULL|
| q2|     i2|  q2|     i2|
+---+-------+----+-------+
```


### join keyのみを指定

```shell
left_df.join(right_df, 'id', 'left_outer').show()
+---+-------+-------+
| id|item_id|item_id|
+---+-------+-------+
| q1|     i1|     i1|
| q3|     i3|   NULL|
| q2|     i2|     i2|
+---+-------+-------+
```

## まとめ
join keyのみを指定すると、結合後のデータフレームには左側のjoin keyのみが残る。
後々dropする必要がないので、left joinするときは基本join keyのみの指定で良さそう。
AWS（Amazon Web Services）について

![image_processing20200730-1-1jizz0t.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3985982/f05754f0-b53f-2cad-adbe-bcae747d8a55.jpeg)


**AWS（Amazon Web Services）について**

AWS（Amazon Web Services）は、Amazonによって提供されるクラウドコンピューティングサービスの一つで、世界中の企業や開発者に利用されています。AWSは、サーバー、ストレージ、データベース、機械学習、ネットワーク、分析、人工知能など、幅広いサービスを提供しており、企業が自社のインフラを効率的に管理できるようにしています。

### 1. **AWSの主なサービス**

AWSは、以下のような主要なサービスを提供しています。

- **EC2（Elastic Compute Cloud）**: 仮想サーバーの提供サービスで、必要なときにスケールアップまたはスケールダウンが可能です。
- **S3（Simple Storage Service）**: データの保存やバックアップに使えるオブジェクトストレージサービスです。
- **RDS（Relational Database Service）**: クラウド上で関係データベースを管理できるサービスです。MySQLやPostgreSQL、Oracleなどに対応しています。
- **Lambda**: サーバーレスコンピューティングサービスで、コードを実行するためにサーバーを管理する必要はありません。
- **VPC（Virtual Private Cloud）**: 自分専用の仮想ネットワークを構築し、セキュリティやアクセス制御を行うことができます。

### 2. **AWSの利点**

AWSの大きな利点の一つは、スケーラビリティと柔軟性です。ユーザーは必要に応じてリソースをスケールインまたはスケールアウトでき、トラフィックの増減に合わせて自動的にリソースを調整できます。これにより、企業は運用コストを削減し、需要に合わせたリソースの提供が可能になります。

また、AWSは高い可用性と耐障害性を備えており、複数のリージョンとアベイラビリティゾーンを活用して、サービスの稼働を確保します。

### 3. **AWSのセキュリティ**

AWSは、セキュリティにも非常に力を入れています。データ暗号化やネットワークセキュリティの対策、アクセス管理など、さまざまなセキュリティ機能を提供しています。さらに、AWSはコンプライアンスに関する認証を取得しており、業界標準に則ったセキュリティ対策を講じています。

### 4. **AWSの利用事例**

AWSは、企業や開発者のニーズに合わせて多岐にわたる利用ケースに対応しています。例えば、スタートアップ企業はスケーラブルなインフラを手軽に導入でき、ゲーム開発者は高性能なサーバーを必要な時に提供できます。さらに、政府機関や医療機関でも、データのセキュリティと可用性を確保しながら利用されています。

### 5. **まとめ**

AWSは、クラウドコンピューティングの分野で最も広く利用されているプラットフォームの一つで、数百万の顧客に対して信頼性の高いサービスを提供しています。AWSを利用することで、企業はコスト削減と業務効率化を実現でき、未来のテクノロジーに対応するための基盤を築くことができます。
福岡出身システムエンジニア誕生記(フリーランスになる)

# はじめに

初めまして、自己紹介させていただきます。

1995年生まれ福岡出身フリーランスエンジニアです。
先日福岡に帰省して、いろいろ自分のこと振り返るの大切だなとおもい、
今回記事を書くことを決断しました。

普通の人間がフリーランスになって生活しているという一例をシェアできたらとおもいます。
誰かの参考になれば幸いです！

今回はフリーランスになる過程を書いてみようと思います。

# 目次
##### ・学生~就活編⇒https://qiita.com/Yutajino/items/bf074102e254457af934
##### ・1年目前半編⇒https://qiita.com/Yutajino/items/37d0ab0cd64d063870b7
##### ・1年目後半編⇒https://qiita.com/Yutajino/items/a4f3ac0e4f6821a3b264
##### ・2年目前半編⇒https://qiita.com/Yutajino/items/fccb4ce3c38186d0eb3b
##### ・2年目後半編⇒https://qiita.com/Yutajino/items/ec6f2895e59343f255b0
##### ・3年目前半編⇒https://qiita.com/Yutajino/items/4961a0983fde122adece
##### ・3年目後半編⇒https://qiita.com/Yutajino/items/a8e6ad643661d669a872
##### ・フリーランスになる編⇒本記事
##### ・経験した失敗編⇒完成次第リンク貼ります
##### ・失敗~現在編⇒完成次第リンク貼ります

# Let's 案件探し
退職届を正式に提出したタイミングでは
フリーランスの案件探しは何も始まっておらず、
何なら、どのように仕事をとっていくのかもわからない状態でした。

今でこそフリーランスで仕事をとってくるにあたって
会社へ売り込みに行ったり、
SNSで募集したりなど色々な手段があると理解してますが、
当時は、前の記事でも少し紹介したフリーランスエンジニアの先輩に聞いて
その通りに動いてみました。

初めてフリーランスとして仕事をする方は、
ほとんどフリーランスエージェントを利用して仕事を探すと思います。

どのエージェントを使うべきなのかわからなかったのですが、
自分の場合は、その先輩に紹介してもらったエージェントを利用しました。

自分の場合、以下の希望出しながら進めていました。
＜希望＞
・働きたい業種、業態、業界
　⇒なんでもOK
・やりたい仕事内容
　⇒SQL、BIツール、DBを扱う業務(というか、それしか触れなかった)
　⇒合わせてプログラミング等を未経験OKで触らせてくれるところ
　⇒PM、PLにこだわらない
・月収
　⇒40万超えたらいいかな
・テレワークメイン、週5勤務、残業できるだけないところ

他にも就業場所についてや、どういうふうなキャリアを歩んでいきたいかなど、
いろいろ質問、相談してもらったので
自分がフリーランスになる上での心配も解消しながら準備を進めることができました。

スキルシートに関しては、1~3ヶ月単位の案件が多く、
1ヶ月で退場させられた？のように思われやすいとの指摘をいただいたので
相談しながら書き方を変えてました。

上記の条件を満たす案件を
営業担当の方から紹介いただき、現場の方とのオンライン面談を実施しました。
初めてのフリーランスとしての面談は緊張しましたが、
スキルシートに沿って経歴を聞かれてどういうスキルがあって、
何に貢献できるかどうかを伝えるような形だったので
就活の時の面接よりは、簡単かなと思いました。
面談中は、現場の方が必要としているであろうスキル、
経験に沿って自分の経歴を話すことを意識しました。

体感ですが、しっかり受け答えをして
自分の経歴について質問された時に詳細に答えることができれば
ほとんどの面談は通ると思います。

無事、一次面談、ニ次面談を通過し、探し始めて1ヶ月程度で案件が決まりました。
決まった時はほっとしました。
退職届を出した後に動き始めてしまったので、収入のない時期が少しあったからです。
自業自得なので、他の方は時期を考えて動かれるといいかと思います笑

# フリーランスになるにあたっての準備
フリーランスになる上で必ずやらなければならないのが、
「開業届の準備」
「国保(人によっては社保)」
そして、フリーランスのメリットを最大限享受するための「青色申告申請書の提出」です。

開業届と青色申告申請書に関しては、
最近では、会計ソフト上で書類作成や手続きの案内をしてくれるので
会計ソフトを利用しながら進めていくと良いかと思います。

国保に関しては、
退職届を出してすぐに動き始めて手続きをした方が良いです。

会社員では発生しない事務作業ですが、
手続き自体は全部簡単でちゃんとやればすぐ終わることなので、
落ち着いて対応すればOKです。

自分は事務作業を蔑ろにしてしまい痛い目みました。
※次回に詳しく書きたいと思います。

いろいろうまく申請できていない部分はありましたが、
事務作業を終えて、無事フリーランスとして現場に入場して働き始めました。

# エージェントについて
どこを選んだらいいのかわからないという方いるかもしれません。
個人的な意見で言うと

ぶっちゃけどこでも良いかと思います。

というのも自分が経験したのですが、
それぞれの現場は、複数のエージェント会社に案件を展開しているので
異なるエージェントを利用して面談した時に、
以前断念した現場にあたり参画につながったこともあります。

どのエージェントを使っても、希望する条件の案件につくことはできると思っています。

違いは、フリーランスエンジニアに対するサポートが整っているかと、
営業担当者の人柄、対応力にあると思っています。

エージェントが提供しているフリーランスに向けての福利厚生制度や保障、
フォロー体制、案件決定までのスピードなど
会社によってさまざまです。

実際にエージェントを利用してみないとわからない部分ではあるので
すでに利用しているフリーランスの方にいろいろ聞いてみて
人が合いそうだな、サポートが充実してそうだなで選んで良いかと思います。

# あとがき
・やらかしたことについて書きたくないですが、次回も頑張って書きます。
・自分が最初に選んだエージェントさんは、
　営業担当ながらスキル面の部分と現場での動きについていろいろ相談乗ってくださって助かりました。
・取引先ではなくても、関係性大事です！単価UPの話もしてもらいやすくなります！
Minecraft コマンド勢が Kotlin / Spigot Plugin に触れるとどうなるか (ちょっとSkriptの話も)

## はじめに
\
Qiitaでは初投稿、_yamipiです。
超適当にコマンド勢がプラグイン(Kotlin)に触れるとどうなるか、容易く乗り換えてはいけない理由をお話しします。

_※ここではコマンドってなんぞや、プラグイン(Kotlin)ってなんぞやという人のための解説は残念ながらございません。_

## 結論
\
前置きがとくに思いつかなったので結論から。**コマンドと同じ感覚では一切通用しないです**。

これに関しては見てもらった方が早いです。

以下はどちらも、**全プレイヤーにメッセージを送信し、音を鳴らします**。上がmcfunction、下がKotlinです

~~~mcfunction:test.mcfunction
tellraw @a "test"
execute as @a at @s run playsound minecraft:ui.button.click master @s
~~~
~~~kotlin:test.kt
Bukkit.getOnlinePlayers().forEach { player ->
    player.sendMessage("test")
    player.playSound(player,"minecraft.ui.button.click",1.0f,1.0f)
}
~~~

Kotlinまだ初心者なのでこんなもんしか書けません。

見てわかる通り、結構行数が増えちゃいます。コマンドはただのゲーム内での話ですが、プラグインとなるとやはり外部の言語に頼ることとなるので仕方ないといえば仕方ないですが。

僕はリアルでプログラミング言語に触れる機会がなんだかんだあるので、まだなんとか喰らいついていけてます。

\
ところで、Skriptなんてものがありますね。あれはどちらかといえばプラグインよりなわけですが、簡単な英語なのでコマンド勢がプラグイン開発する上で最初にすべきことはSkript習得だと思います。僕はほとんど齧らずKotlinに触れているわけですが。

\
とりあえず**プラグイン開発に着手したいなと思ったらSkriptを最初にすべき**、だと思います

\
以下はなんか細かいこと言ってるだけなのでもうお腹一杯の方はブラウザバッグしていただいて結構です。

## コマンドとプラグインの違い
\
**コマンド**
・手軽
・(完成品の)導入が容易
・プレイヤーの**nbt書き換え**ができない
・機能を盛り込むと動作が重くなりがち
・ちょっとバージョン上下すると**すぐ使えなくなる**(互換性が低い)
・外部のAPIなんてものはない

\
**プラグイン**
・(上手く使えれば)高クオリティなものが作れる
・バージョンの上下に**影響されずらい**
・イベント検知が豊富
・環境構築が面倒
・**今**なにかいてるのかさっぱりわかんない
・外部のAPIが充実している(使用できる)

コマンドは全体的にみれば簡単で気軽に始められる印象、プラグインは最初大変だけど後はとても簡単で高品質、という印象。Skriptは中間のいいとこどりをしています。いいご身分です。

## プラグインに触れてちょっと困ったこと
\
もともとデータパックの人間です。困ったことぐらいあってもおかしくありません。ということで。
### その1 - 変数の感覚が謎
コマンドで言う変数は、**scoreboardのことを指す**(そうでないことが超低確率であるが)プラグインでいう変数とは、クラス内共通の変数(?理解しきっていない?)というもので、言えばダミープレイヤーのscoreboardみたいなものであるということ。
これ慣れるまで結構時間がかかりました。ついでに、プレイヤー各々に与えられる変数は特殊な宣言が必要らしく、勉強中です。

### その2 - コンフィグファイルとかいうやつ
コマンド勢からしたら、誰???と言わんばかりの存在。どうやら一部分をそのコンフィグから取り出して使用できるらしく、最近実装された動的functionみたいだなーと思っている。コンフィグファイル、最初は理解に苦しんだが使いこなせれば非常に便利。

### その3 - 変数を操作
今となっては当たり前、前は理解すらできなかった。nbtの書き換えを行ってるようなもの。しかしメッセージを送るのも音を鳴らすのもすべて**操作に含まれて言われる**ようで、理解に苦しんだ。

### その4 - 軽量化
データパック作ってるときは結構軽量化を意識して作ってました。しかしどういうわけかKotlinになるとそういうの一切意識できないんですよ。ほんとに。


\
こんなものでしょうか。

## おわりに
Kotlin初心者のひとりごとなので全然無視していただいて結構。
ただ、コマンドからプラグインやるときはSkriptっていう段階を踏んだ方がいいよ～っていう、そういうお話でした。

## なんで今更プラグインを？ (宣伝)

最初はもちろんプラグインなど触れる予定は一切ありませんでした
しかし[現在開発部としてやらせてもらってるサーバー](https://www.tatamiserver.com/)に参加したところ、プラグイン学んでほしいと言われ、今に至ります。プラグイン嫌いじゃないけど、まぁ使いこなすのは数年先の話になるでしょうね。

_その前に学校でC言語の授業が始まったりするので..._

\
\
それでは。
async/await を使った非同期処理の基本

# 非同期処理とは

非同期処理とは、ある処理が完了するのを待たずに次の処理を実行する仕組みのことです。例えば、サーバーからデータを取得する際、完了するまで待っていると他の処理が止まってしまいます。非同期処理を使えば、データ取得中でも別の処理を進めることができます。

async/await を使うと、非同期処理をより簡潔に書くことができます。

### どんなときに使うのか

- **API からデータを取得するとき**
  - 例: Web サイトで記事一覧を表示するとき
- **データベースにデータを保存するとき**
  - 例: ユーザーがフォームを送信したとき
- **外部サービスと通信するとき**
  - 例: 認証（ログイン・ログアウト）
- **一定時間待つ処理をするとき**
  - 例: 画面の読み込み時にローディングを表示

## async/await の使い方

```javascript
async function getData() {
  try {
    const res = await fetch('https://api.example.com/data');
    const data = await res.json();
    console.log(data);
  } catch (error) {
    console.error('エラー:', error);
  }
}
```

- `async` を関数につけると、その中で `await` が使えます。
- `await` は処理が終わるまで待ちます。
- `try/catch` を使うとエラーが起きても処理を止めません。

## React での非同期データ取得

React では `useEffect` を使って、コンポーネントが表示されたときにデータを取得できます。

### useEffect の基本

`useEffect` は、コンポーネントのライフサイクルに合わせて特定の処理を実行する React のフック

```javascript
useEffect(() => {
  console.log("コンポーネントが表示されました");
}, []);
```

- 第1引数の関数が実行される。
- 第2引数の `[]`（依存配列）が空の場合、最初の1回だけ実行される。

### async/await を使ったデータ取得

以下の例では、Supabase からデータを取得する非同期処理を `useEffect` で実行しています。

```javascript
useEffect(() => {
  const fetchData = async () => {
    try {
      const { data, error } = await supabase.from("study-record").select("*");
      if (error) throw error;
      setRecords(data);
    } catch (error) {
      console.error("エラー:", error);
    }
  };
  fetchData();
}, []);
```

## まとめ

- `async/await` は非同期処理をシンプルに書くための構文
- `try/catch` を使うことで、エラー発生時の対応がしやすくなる
- React の `useEffect` を活用すると、コンポーネントが表示されたときに非同期データ取得ができる
- `useEffect([])` を使うと、初回のみデータを取得できる

 `async/await` と `useEffect` を組み合わせることで、非同期処理を直感的に管理できます。
【Unity初心者】Unityでネットゲームを作りたい【17】パネル間でデータの引継ぎをしたい～どのボタンが押されてるか判断して次のパネルへ～Jsonファイルの読み込みが早すぎる？

https://qiita.com/ysyss5500/items/4aeb23639a8cf3d67376
### パネル間でデータの引継ぎをしたい
前は勝手に　using static PlayFabLogin;　とか出て形？を引き継いでくれたけど
a = 1　とかのデータが引き継がない
毎度おなじみ調べました
[【Unity】変数の受け渡し まとめ【入門】](https://qiita.com/Akarinnn/items/00f58b7cbc7c5d659d92)こちら参照
```
 //Sousaku.csの値を引き継ぐ
 Sousaku sousaku;
 sousaku = Panel.GetComponent<Sousaku>();
 
 GameObject HP = GameObject.Find("HP7");
 Text HP_text = HP.GetComponent<Text>();
 HP_text.text = sousaku.hp;
```
こんな感じで　テキスト　HP7　に表示できた
___
### どのボタンが押されてるか判断して次のパネルへ
ってのをやりたかった
これも調べまくったけど、なんかむずかしい...

そこで考えた
ボタン押したら、今これを押しましたと番号をどっかに保存して、次のパネルで読み込めば？と
PlayerPrefs　これ使えるのかな？　ログイン時に使ってたけど、ID上書きとかしたら大変よなーと触れなかったが、よくよく見ると普通に使えそう
5つのボタンを画像のバックに配置して、選択したら色が変わるようにして...
```
using UnityEngine;
using UnityEngine.UI;

public class Hanten : MonoBehaviour
{
    public int sentaku;
    public void Clickhere()
    {
        //このボタンの色を変える
        GameObject thisButton = GameObject.Find("Button (1)");
        Button btn = thisButton.GetComponent<Button>();
        btn.image.color = Color.cyan;

        // 他の色を白に変更
        GameObject Button_2 = GameObject.Find("Button (2)");
        Button btn_2 = Button_2.GetComponent<Button>();
        btn_2.image.color = Color.white;

        GameObject Button_3 = GameObject.Find("Button (3)");
        Button btn_3 = Button_3.GetComponent<Button>();
        btn_3.image.color = Color.white;

        GameObject Button_4 = GameObject.Find("Button (4)");
        Button btn_4 = Button_4.GetComponent<Button>();
        btn_4.image.color = Color.white;

        GameObject Button_5 = GameObject.Find("Button (5)");
        Button btn_5 = Button_5.GetComponent<Button>();
        btn_5.image.color = Color.white;

        sentaku = 0;
        PlayerPrefs.SetInt("Sentaku", sentaku);
    }
}

```
ボタンを押したら、そのボタンだけ色を変更し、ほかのボタンは白に
で、
```
sentaku = 0;
PlayerPrefs.SetInt("Sentaku", sentaku);
```
このボタンを押したから　sentaku = 0 ですよと
これを次のパネルで　PlayerPrefs.GetInt("Sentaku", sentaku);　呼び出せばOKだ！
他のボタンにも色を変えたのと、数字を1とかに変えたスクリプトをはめ込んだ

うまくいきました

あれ？
これ、さっきのデータ引継ぎに使えるんじゃ？
 PlayerPrefs.SetString("NewHP", sousaku.hp);
これでできました

まぁお勉強ですね
___
### Jsonファイルの読み込みが早すぎる？
配列を入れ替えてJsonファイルに上書き、んで読み込んでこうなりました　とやりたいのだが、変更前のデータが表示されてしまう
遅らせたりいろいろやったのだが、どうもうまくいかない...

あぁこれ、Jsonファイル使わないでPlayFabのプレーヤーデータだけでやり取りしたほうがよさげだ
読込をPlayfabだけにしてみよう

ってやったら成功！

読込んで書き込んで再読み込みがスムーズにできた

そしてここで壁にぶちあたる

←前  [【Unity初心者】Unityでネットゲームを作りたい【16】謎のエラーで悩む～パネルでボタンを押したら、このパネルを消して別パネル表示](https://qiita.com/ysyss5500/items/6b939c5f2badfef63812)

[【Unity初心者】Unityでネットゲームを作りたい【18】Unityで正常、ビルドしてandroidで異常](https://qiita.com/ysyss5500/items/8452034ea1adc65eb14f)　次→

https://qiita.com/ysyss5500/items/4aeb23639a8cf3d67376
衝突を避けるプロジェクト管理：品質とスピードの最適なバランスを見つける

「不具合を指摘しても後回しにされてなかなか対応してもらえない」
「品質向上のために色々提案をしているが、なかなか取り合ってもらえない」
こんな経験ありませんか？
もしかすると、「品質とスピードのバランスの認識」が
摺りあっていないせいかもしれません。

「スピードを重視したい人」と「品質を重視したい人」がいたとしたら
それぞれの思想がぶつかりあい、お互いに消耗してしまうでしょう。

今回はそのような衝突を避けるには、
こういうことをすればいいのでは？という提案を書いてみます。

なお本記事では
「短期的なスピードと品質はトレードオフだが、長期的なスピードと品質はトレードオン」
という筆者の考えに基づき、
スピード＝「数週間～1or2か月程度の短期的なスピード」と定義します

----

結論から言うと、「品質VSスピード」の衝突を避けるための提案とは
「意思決定者に聞く」です。
ただ、それだと何の捻りもないし意思決定者も回答に困ると思うので、
選択肢をAIに生成させてみました。

### 選択肢 1: 品質重視
- **概要**: 品質に最大の重点を置き、バグのない、ユーザー満足度の高い製品を目指します。
- **特徴**:
  - 徹底的なテストとレビューを繰り返す
  - ユーザーフィードバックは慎重に取り入れ、リリース間隔は長め
  - 安定した運用を目指す

### 選択肢 2: バランス重視
- **概要**: 品質とスピードを同等に重視するアプローチ。
- **特徴**:
  - 定期的なリリースサイクル
  - テストと開発を並行で進め、迅速かつ適切なフィードバックループを確保
  - スピードと品質のバランスを調整しながら進行

### 選択肢 3: 速度重視
- **概要**: スピードに最大の重点を置き、早期のフィードバック取得を最優先します。品質は二の次とします。
- **特徴**:
  - 超短いリリースサイクルで頻繁なリリース
  - テストは最小限で、即時のフィードバックを製品改善に反映
  - 早期市場投入や運用フェーズでの迅速な対応を目指す


意思決定者にいずれかを選んでもらうことで、テスト戦略を策定する際のベースにします。

>例）
>「品質重視」なら、企画やエンジニアのテストケースレビューを通すこととする
「速度重視」なら、探索的テストを原則とする

このような形で方針をすり合わせることで、スピードvs品質の衝突を避け
PJに寄り添ったQA活動ができるのではないでしょうか？
また、プロダクトのフェーズによって重視すべきものは異なるので、
定期的に見直しを行うのもいいかもしれませんね。

何かの参考になれば幸いです。

※なお本記事は速度重視で書いたものにつき、
不明点・ご指摘・フィードバックなどあれば是非お願いいたします（笑）
[備忘録] Docker Desktop for Mac がマルウェア判定された際にやったこと

## はじめに

Docker公式による[こちらのissues](https://github.com/docker/for-mac/issues/7527)や[窓の杜での記事](https://forest.watch.impress.co.jp/docs/news/1653265.html)にて報じられた通り、

Docker Desktop for Macアプリがマルウェア判定される問題が発生いたしました。

私の環境ではhomebrew経由で上記のアプリを入れていたので、

今回はその際にやったことについて記事にしてみたいと思います。

### Docker Desktop for Macアプリをアンインストール

まずは、

![スクリーンショット 2025-02-06 18.02.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3634309/962ff7af-a883-86f7-65b1-a97b3722f61b.png)

この通知に従って、上記のアプリをゴミ箱に捨て、ゴミ箱の中身を空っぽにします。

### brewコマンドでインストール

次に、

```zsh
 brew update
 brew reinstall --cask docker
```

上記のコマンドを使ってDocker Desktop for Macアプリを入れ直します。

この時、

パスワードの入力を求められるかと思われますので、それを入力いたします。

最後に、

```zsh
docker --version
```
上記コマンドを実行して、バージョンの表示がされればインストールは完了です。

あとは、先述のアプリをDockに留めているのであればそれを外して、

LaunchPadから新しくDocker Desktop for Macアプリを起動しなおし、

Dockに留めるなどのお好みの調整をしていただければと思います。

### ちょっと困ったこと...💦

今回改めてDocker Desktop for Macアプリを入れ直したところ、

Dockerは無事`running`になったのですが、

kubernetesだけは

```
kubernetes failed to start
```

このようになり、うまくいきませんでした...😣

そのため、

「Settings（⚙️）→  Cluster Reset Cluster」を実行いたしました。

今回はkubernetesで開発をしていなかったので影響はありませんでしたが、

kubernetesで開発をされている方は別の対応策が必要になるかもしれません...

## 参考

https://zenn.dev/marimoofficial/articles/661af29a459423

https://qiita.com/kxn4t/items/05f55acafa85273df0cf

https://docs.docker.com/desktop/release-notes/

https://github.com/docker/for-mac/issues/7527

https://forest.watch.impress.co.jp/docs/news/1653265.html
az login で SSLCertVerificationError が出る場合の対処法

以下のように、`az login` で SSLCertVerificationError が出る環境があります。

```console
PS C:\Users\hanohrs> az login
HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /organizations/v2.0/.well-known/openid-configuration (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)')))
Certificate verification failed. This typically happens when using Azure CLI behind a proxy that intercepts traffic with a self-signed certificate. Please add this certificate to the trusted CA bundle. More info: https://docs.microsoft.com/cli/azure/use-cli-effectively#work-behind-a-proxy.
```

このエラーの解決方法をご紹介します。


## SSL インスペクションが行われている環境で発生する場合

以下の記事の通り、環境変数 `REQUESTS_CA_BUNDLE` に PEM 形式の証明書のパス (`C:\Path\To\SSLInspector.cer`) を設定することで解決するはずです。PEM 形式の証明書の入手方法は記事の最後にご紹介します。

https://learn.microsoft.com/ja-jp/cli/azure/use-azure-cli-successfully-troubleshooting#work-behind-a-proxy

もしくは、`--certificate` オプションにこの証明書を指定してもよいでしょう。


## SSL インスペクションが行われていそうでいない環境で発生する場合

前述のようなトラブルを解消するため、SSL インスペクションが行われている環境では、Python を使う開発者は `REQUESTS_CA_BUNDLE` を設定している場合が多いと思いますが、login.microsoftonline.com が SSL インスペクションの例外として扱われている場合、これが逆に問題を引き起こします。

この場合は、以下のように `REQUESTS_CA_BUNDLE` を空文字列に設定すると解決しました。

```console
PS C:\Users\hanohrs> $env:REQUESTS_CA_BUNDLE=""
PS C:\Users\hanohrs> az login
```

なお、これ以外のマイクロソフトのドメインは SSL インスペクションの対象だという場合は、他の `az` サブコマンドを実行する際には `REQUESTS_CA_BUNDLE` が必要です。


## PEM 形式の証明書の入手方法

PEM 形式の証明書は、以下の方法で入手することができます。

1. certmgr.msc を実行する
1. 信頼されたルート証明機関 > 証明書にある SSL インスペクション用の証明書を右クリック
1. すべてのタスク(K) > エクスポート(E)...
1. 次へ(N)
1. Base 64 encoded X.509 (.CER)(S) を選択して、次へ(N)
1. 参照(R)... でファイルを保存したいフォルダでファイル名を入力して、保存(S)
1. 次へ(N)
1. 完了(F)

なお、信頼されたルート証明機関に証明書が存在する場合を想定しています。
個人的備忘録：AWS Secrets Managerで「シークレットが削除予定」のエラーを解決する方法を紹介してみた

## はじめに
AWS Secrets Manager を使用して RDS のパスワードを管理している際に、「**シークレットが削除予定のため作成できない**」というエラーに遭遇しました。

:::note info
**これは Secrets Manager の仕様によるものですが、削除を強制的に実行する方法や、別名で作成する回避策があります。**
:::

本記事では、エラーの原因と解決策について解説します。

## 書こうと思ったきっかけ
Terraform を使ってインフラを構築する際に、RDS のシークレットが作成できないエラーに直面しました。

:::note warn
***調査すると、Secrets Manager には削除保留期間があるため、同じ名前のシークレットをすぐに作成できないことがわかりました。***
:::

コンソール上で削除されたと思っていたシークレットが、実は復旧期間中だったため、同様の問題を避けるために情報をまとめました。

## 発生していたエラー

```bash
Error: creating Secrets Manager Secret (rds_password): operation error Secrets Manager: CreateSecret, https response error StatusCode: 400, RequestID: bc3c46c7-3650-4b61-bda9-0d2431cc35ee, InvalidRequestException: You can't create this secret because a secret with this name is already scheduled for deletion.

  on main.tf line 466, in resource "aws_secretsmanager_secret" "rds_password":
 466: resource "aws_secretsmanager_secret" "rds_password" {
```

このエラーの原因は、**同じ名前のシークレットが既に削除予定状態になっているため、新しく作成できないこと** です。  

AWS Secrets Manager では、シークレットを削除する際に **一定の待機期間（デフォルトは 7 日間、最大 30 日）** があり、その間は同じ名前のシークレットを作成できません。  

### AWS Secrets Manager における削除の仕組み

> シークレットが持つ重要な特性から、AWS Secrets Manager では、シークレットの削除を故意に困難にしています。Secrets Manager は、シークレットをすぐには削除しません。Secrets Manager は、シークレットをすぐにアクセス不能にし、最短で 7 日間の復旧期間が経過した後に削除されるようスケジュールを設定します。復旧期間が終了するまで、以前に削除したシークレットを復旧することができます。
引用：https://docs.aws.amazon.com/ja_jp/secretsmanager/latest/userguide/manage_delete-secret.html

この仕様のため、Terraform などで同じ名前のシークレットを作成しようとすると、上記のエラーが発生する可能性があります。

## 実態を確認してみた
AWS Secrets Manager のコンソールでは、デフォルトの設定では 削除が保留されているシークレットは表示されません。

削除が保留されているシークレットを一覧に表示するには、以下の手順でコンソールの設定を変更してください。

1. **Secrets Manager のコンソールを開きます。**  

2. **画面右側の歯車アイコンをクリックし、削除予定にチェックを入れます。**  

![Screenshot 2025-02-06 at 17.52.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/95d1acd0-7ad8-52c7-f41c-e1af71268eff.png)

### エラーを解消してシークレットを再作成する方法
エラーを解消し、すぐにシークレットを再作成したい場合は、復旧期間を待たずにシークレットを完全に削除 することができます。

この操作は AWS CLI を使用して実行可能です。

![Screenshot 2025-02-06 at 17.57.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3662571/3525dd1e-e710-8a35-9d92-67ea040b5147.png)

**削除を強制する**

以下のコマンドを実行すると、削除の待機期間なしで **即時削除** されます。

```bash
aws secretsmanager delete-secret --secret-id 削除したいシークレット --force-delete-without-recovery
```

**実行時の注意点**  

- **この操作を実行すると、シークレットを元に戻すことはできません。**  
- `--force-delete-without-recovery` オプションを使用すると、**復旧期間なしで即時削除されます。**  

### **別の名前で Secret を作成する方法**  

もし `rds_password` を完全に削除せず、エラーを回避したい場合は、**Terraform のコードを修正し、別の名前で Secret を作成する方法** もあります。  

Terraform のコードを以下のように変更すると、新しいシークレットを作成できます。

```hcl
resource "aws_secretsmanager_secret" "rds_password_v2" {
  name = "rds_password_v2"
}
```

この方法なら、**既存の `rds_password` に影響を与えず、新しいシークレットとして管理** できます。  

## まとめ
Secrets Manager では、シークレット削除後に一定の復旧期間があり、その間は同じ名前で新たに作成できません。

:::note warn
**エラーを解消するには、CLI で強制削除するか、別の名前でシークレットを作成する方法があります。**
:::

Terraform での運用時には、削除の仕様を考慮し、適切な対応を行うことが重要です。

## 参考文献

https://dev.classmethod.jp/articles/secrets-manager-error-recovery-window/
MERNスタック開発で必須のミドルウェアについて。

MERNでの開発に限らず、モダンなWebアプリケーションで一般的に必要となる基本的なミドルウェア３つを簡単に。

### 1 `express.json()`
```javascript
app.use(express.json());
```
- JSONデータの解析を行うミドルウェア
- クライアントから送られてくるJSONデータを自動的にJavaScriptオブジェクトに変換
- 例：クライアントから`{ "name": "John" }`が送られてきた場合、`req.body.name`で"John"にアクセス可能

### 2 `cookieParser()`
```javascript
app.use(cookieParser());
```
- HTTPリクエストのクッキーを解析するミドルウェア
- クッキーの値を`req.cookies`オブジェクトとして使用可能に
- 例：`req.cookies.jwt`でJWTトークンにアクセス可能

### 3 `cors()`
```javascript
app.use(cors({
  origin: "http://localhost:5173",
  credentials: true,
}));
```
- Cross-Origin Resource Sharing (CORS)の設定を行うミドルウェア
- 異なるオリジン間でのリクエストを制御
- `origin`: アクセスを許可するオリジン（Viteの開発サーバーなど）
- `credentials: true`: クッキーやHTTP認証を含むリクエストを許可

これら3つは、モダンなWebアプリケーションで一般的に必要となる基本的なミドルウェアであり、特にフロントエンドとバックエンドが異なるポートで動作する開発環境では、これらの設定が重要となる。
SATAとは何かをまとめる

## はじめに
自作PCなどで単語だけは見かけて知った気になっていたsataについて深堀して理解を深める。

## 概要
`SATA` 
インターフェース規格の１つ
SSDにおけるインタ―フェイスとは、主にSSDとPCを接続する際に用いる。

なおこれらのインターフェイス規格は通信速度に関わる仕様とセットで表記される。
例: 「SATA Ⅲ」、「6Gbps SATA」など

同一規格内での互換性を有しているため「6Gbps SATA対応SSD」を「3Gbps対応SATAポート」に接続することが可能
但し、遅い方の規格に速度を合わせて通信するので性能が十分に発揮できない場合がある。

## 参考資料

https://blog.ocworks.com/archives/52154292/
Promise のコード言語化

# はじめに
下記のようなコードを見る機会は多いと思いますが、それぞれ何を行っているのか言語化するとなると少々理解するのに時間がかかったため、解説を共有させていただきます。

```.tsx
new Promise(resolve => setTimeout(resolve, 1000));
// new ProiseでPromiseを作成しコールバック関数としてresolveを受け取っている。
// resolveは引数としてsetTimeoutに渡している
// setTimeoutは1秒後にresolveを実行する
```
上記のコードは関数の引数の中にアロー関数を記述しているコールバック関数になっていること、またアロー関数の記述の仕方も省略している部分があることで、更に理解が難しくなっています。
下記のように省略することなく記述したものを見れば、理解しやすくなると思います。
上記コードと同じことを行っています。
```.tsx
new Promise((resolve) => { setTimeout(() => { resolve();}, 1000);});
```

# 最後に
コードの言語化ができれば理解が進みますね。
<br>
[<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3707255/8bfacf61-7d8d-6d27-cb07-98d1f8f27fcd.png"  width=100%>](https://projisou.jp)
CodeIgniter4 Shield のマイグレーションが適用されない問題と解決策


## はじめに
CodeIgniter4 で `Shield` を導入する際、マイグレーションが適用されず、`settings` テーブルが作成されない問題に直面しました。本記事では、その原因と解決策を共有します。

---

## 発生した問題
`php spark migrate:status` を実行すると、以下のように `Shield` と `Settings` のマイグレーションが認識されているにも関わらず、適用されていない状態が続きました。

```
$ php spark migrate:status

+----------------------+-------------------+---------------------+----------+--------+--------+
| 名前空間             | バージョン        | ファイル名          | グループ | 移行日 | バッチ |
+----------------------+-------------------+---------------------+----------+--------+--------+
| CodeIgniter\Shield   | 2020-12-28-223112 | create_auth_tables  | ---      | ---    | ---    |
| CodeIgniter\Settings | 2021-07-04-041948 | CreateSettingsTable | ---      | ---    | ---    |
| CodeIgniter\Settings | 2021-11-14-143905 | AddContextColumn    | ---      | ---    | ---    |
+----------------------+-------------------+---------------------+----------+--------+--------+
```

マイグレーションを適用しようとしても、特にエラーは発生せず `マイグレーションが完了しました` と表示されるものの、データベースには何も適用されていない状態でした。

---

## 原因
原因は **`Myth/Auth` がインストールされていたこと** でした。

CodeIgniter 4 では `Myth/Auth` と `Shield` はどちらも認証ライブラリですが、それぞれ `users` テーブルや `auth_*` 系のテーブルを作成するため、競合が発生します。

`Myth/Auth` のマイグレーションが適用されていると `Shield` のマイグレーションが適用されないケースがあるため、`Myth/Auth` を削除することで `Shield` のマイグレーションが正常に適用されるようになりました。

---

## 解決策

### 1. `Myth/Auth` がインストールされているか確認

```
$ composer show | grep myth/auth
```

上記のコマンドで `myth/auth` が表示される場合、インストールされています。

### 2. `Myth/Auth` をアンインストール

```
$ composer remove myth/auth
```

### 3. マイグレーションのリセット

既存のマイグレーションをリセットします。

```
$ php spark migrate:reset
```

### 4. `Shield` のマイグレーションを適用

```
$ php spark migrate --namespace CodeIgniter\Shield
$ php spark migrate --namespace CodeIgniter\Settings
```

これで、`Shield` と `Settings` のマイグレーションが正常に適用され、`settings` テーブルも作成されるはずです。

---

## おわりに
同様の問題に直面している方の参考になれば幸いです。`Myth/Auth` と `Shield` の競合に注意し、適切なマイグレーションの適用を行ってください。
「AIが支配するSNSの未来？本物とフェイクの境界線が消える日」

### AIが変えるソーシャルメディアの未来：創造と混乱のはざまで

近年、**人工知能（AI）がソーシャルメディアのあり方を劇的に変えています**。コンテンツの作成、キュレーション（整理・配信）、消費のプロセスはAIによって進化し、新たな可能性が広がる一方で、情報の信頼性、フェイクニュースの拡散、そして人間の創造性の希薄化といった課題も浮かび上がっています。AIの進化がもたらすメリットとリスク、その最前線を探ります。

---

## **AI生成コンテンツの急増：便利か、それとも危険か？**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3917980/ac188a4d-9884-eb46-afe4-441422d8e84d.png)

SNSを開けば、AIが作り出したコンテンツが目に入ることが増えていませんか？最近では、AIが自動でテキストを書いたり、画像を生成したり、さらには動画まで作成できるツールが登場し、多くの人が活用しています。

例えば、「Faceless.video」や「AutoShorts.ai」といったプラットフォームでは、**TikTokやYouTube向けのAI生成コンテンツをほぼ自動で作成・投稿**できる仕組みが整っています。日々の投稿をAIに任せることで、**「手間いらずでバズるコンテンツを量産！」**という夢のような環境が整いつつあるのです。

しかし、その便利さの裏で、**コンテンツの「質」や「本物らしさ」はどうなっているのでしょうか？** 視聴者が本当に求めているのは、機械が大量生産したコンテンツなのか、それとも人間のリアルな感情がこもった投稿なのか——今、その境界線が揺らぎ始めています。

---

## **「AI Slop（AIのゴミコンテンツ）」の台頭**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3917980/bbd8e2ae-cd8d-7d26-ff4c-4debbe34ad46.png)

「AI Slop（AIのゴミコンテンツ）」という言葉を聞いたことがありますか？これは、**質の低いAI生成コンテンツがSNS上に溢れかえっている現象**を指します。

なぜこうしたコンテンツが大量に作られるのか？理由の一つは、**収益化の仕組み**です。SNSのアルゴリズムは、**「エンゲージメント（いいね・シェア・コメント）」が多いコンテンツを優遇**します。そのため、多くのクリエイターがAIを活用し、バズりやすいコンテンツを次々と生み出しているのです。

例えば、最近話題になった**「AIが生成した様々なバージョンのイエス・キリストの画像」**は、Facebook上で爆発的に拡散されました。しかし、これらの画像は本当に意味のあるものなのでしょうか？ただエンゲージメントを稼ぐために作られたコンテンツは、SNSを価値あるものにするのでしょうか？

このような現象が続くと、**「本物」と「フェイク」の境界線が曖昧になり、ユーザーが何を信じればいいのかわからなくなる**という問題が生じます。

---

## **AIが作り出す「偽のユーザー」たち**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3917980/d0165d8d-b178-571d-2f4f-7bd8b35cce07.png)

コンテンツだけではありません。**SNS上には、AIが生成した「ユーザー」も登場し始めています。** 例えば、FacebookやInstagramを運営するMeta社は、**「AIキャラクター」を導入する計画を発表**しました。

これらのキャラクターには、**プロフィール写真や自己紹介文**があり、人間のように振る舞います。しかし、実際には彼らは**完全なAIユーザー**。つまり、あなたがやりとりしている「人間」だと思っていた相手が、実はAIかもしれないのです。

この動きが進むと、SNSはどんどん「リアルな人間がいない世界」に近づいていきます。いずれ**「デッド・インターネット（死んだインターネット）」**と呼ばれる状態になり、実際の人間が発信するコンテンツは影を潜め、AI同士のやりとりが支配する世界が訪れるかもしれません。

---

## **AIがもたらす課題と今後の課題**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3917980/647c3de2-8237-7142-64a0-33b405423792.png)

### **1. フェイクニュースの拡散**
AIによって**フェイクニュースやディープフェイク動画**が簡単に作れるようになったことで、真実と嘘を見極めるのが難しくなっています。

### **2. SNSの「本物らしさ」の崩壊**
AIが投稿やユーザーを作り出すことで、SNSのリアルな交流が失われるリスクがあります。「この投稿、本当に人が書いたの？」という疑問を持つことが増えれば、ユーザーの信頼も揺らぎます。

### **3. コンテンツの管理が難しくなる**
SNSプラットフォームは、AIによる**スパム的なコンテンツをどのように管理するか**という課題に直面しています。透明性のあるルール作りが求められています。

---

## **AIとSNSの未来をどう歩むべきか？**
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3917980/70b771ba-447d-8f04-a894-a14114d9f1b0.png)

AIの進化を止めることはできません。しかし、**人間らしさや誠実さを守る方法は、私たち次第**です。

- **AI生成コンテンツには明確なラベルをつける**（例：「この投稿はAIによって作成されました」など）
- **AIが生成したコンテンツを適切にフィルタリングする技術を開発する**
- **SNSユーザー自身が「本物の人間によるコンテンツ」に価値を見出す文化を育てる**

こうした対策が取られない限り、**SNSは「人が楽しむ場所」から「AIが支配する場所」に変わってしまうかもしれません**。

---

## **最後に：AIと共存するために**

AIは、間違いなくソーシャルメディアを進化させています。しかし、**テクノロジーは人間を豊かにするためにあるべきものであり、人間性を奪うものであってはなりません**。

「SNSを開いたら、すべての投稿がAIだった——」

そんな未来を防ぐために、私たちは今、何をすべきなのでしょうか？
2025年1月：Microsoft関連ホットニュース

去年から今年初めにかけてMicrosoft周りに関して、動きがあるので私が把握しているものだけでもまとめさせていただきました。
誰かの役に立ちますように！

---

### マイクロソフト、Microsoft 365のアプリ名称変更でさらなる混乱へ
Microsoft365のアプリ名称が2025年1月中旬よりされる。
関連URLやデザインも変更あり。

https://tech-gadget.reinforz.co.jp/12466#google_vignette

### 「Microsoft アカウント」のサインイン仕様が変更に、2月からは“サインアウト忘れ”に要注意
サインアウトまたはプライベートモードでの閲覧を使用しない限り、サインイン状態が自動的に継続されるようになるとのこと。

https://forest.watch.impress.co.jp/docs/news/1657159.html


### 2025年にサポート終了となるMicrosoft製品をチェック 〜Windows 10が10月に引退へ
2025年にサポート終了となるMicrosoft製品が多いです。
会社によっては、ESUライセンス（サポート延長）の購入も検討必要かと。

https://forest.watch.impress.co.jp/docs/serial/yajiuma/1650515.html

### Microsoft 365の個人向けプランが値上げ　Copilot統合の価値は？
個人向けMicrosoft365がCopilot統合で6400円値上げされるとのこと。

https://www.itmedia.co.jp/enterprise/articles/2502/03/news122.html

### Microsoftが「93日を超えてライセンスの付与されていないOneDriveアカウント」へのアクセスを遮断する予定

https://gigazine.net/news/20250109-unlicensed-onedrive-free-ride-ends/
Ruby 条件分岐　if文

# 初学者のメモ
自分が忘れないようにするためのメモ書きです。
今回は、 **Rubyの条件分岐**に関してです。特に、<font color = "red">**複数の条件分岐、Fizz Buzz**</font>についてです。あくまで、自分の知識の確認ですので、拙い記述です。ご容赦ください。

# 条件分岐とは
プログラム中で、ある条件が満たされているかどうかを判断し、次に実行するコードを変化させるもの。複数の条件を指定したり、特定の値の時の処理などを記述可能。
**if文**もしくは**switch文**で記述する。
今回はif文での記述。switch文はこちら。


# if文の記述方法
以下のような記述方法となる。

```ruby:if文
if 条件式１
    処理    #条件式１を満たしたときの処理
elsif 条件式２
    処理    #条件式１を満たさず、条件式２を満たしたときの処理
elsif 条件式３
    処理    #条件式１，２を満たさず、条件式３を満たすときの処理
else
    処理    #いずれの条件式も満たさないときの処理
end
```
ここで、いくつかの注意点があります。
・elsif文は複数記述可能。
・elsif、elseは不要な時に省略可。
・<font color="red">上から条件の判断が優先されるため、注意（下記参照）。</font>

# Fizz Buzz問題とは
**Fizz Buzz**とは、1から順に数を数え上げていき、3の倍数なら「Fizz」、5の倍数なら「Buzz」、両方の倍数（15の倍数）なら「Fizz Buzz」、いずれでもなければその数を言うゲームです。
元々は海外の言葉遊びでそのルールをプログラムに実装したものです。

プログラミングの初歩的な問題で扱われることが多いです。以下にコードを記述してみましょう。今回は1~15までの数字で試してみcます。

```ruby:Fizz Buzz
for num in 1..15
    if num % 15 == 0
        puts "Fizz Buzz"
    elsif num % 3 == 0
        puts "Fizz"
    elsif num % 5 == 0
        puts "Buzz"
    else
        puts num
    end
end
```
出力は以下のようになります。
```ruby:結果
1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
Fizz Buzz
```

上記コードを細かく見てみましょう。
```ruby
for num in 1..15
```
ここは1~15の繰り返しをfor文で表す。

```ruby
    if num % 15 == 0
        puts "Fizz Buzz"
```
numが15で割り切れるとき、"Fizz Buzz"と出力。

```ruby
    elsif num % 3 == 0
        puts "Fizz"
```
numが3で割り切れるとき、"Fizz"と出力。
```ruby
    elsif num % 5 == 0
        puts "Buzz"
```
numが5で割り切れるとき、"Buzz"と出力。
```ruby
    else
        puts num
```
それ以外は数字を出力。

# 注意点
注意点は、15の倍数の条件分岐を最初にすること。もし最初にしないと、他の条件分岐に進んでしまう。例えば、以下のコードを見てみましょう。（最初と2番目の条件を逆にする）
```ruby:誤答例
for num in 1..15
    if num % 3 == 0
        puts "Fizz"
    elsif num % 15 == 0
        puts "Fizz Buzz"
    elsif num % 5 == 0
        puts "Buzz"
    else
        puts num
    end
end

```
すると、結果は以下のようになる。
```ruby:結果
1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
Fizz # 15で割り切る条件より先に3で割り切れる条件の分岐に進んでしまう
```

結果より、15の時、"Fizz Buzz"ではなく、"Fizz"で出力されてしまっている。
これを防ぐために、より厳しい条件を先に置いた方が有効である。

# おわりに
今回は**if文**についてまとめました。Fizz Buzz問題は有名なので、初学者の方は、基礎固めにやってみるのもおすすめです。次回はswitch文です。

それでは、ばいなら～

#
2025.02.06 執筆
Raspberry pi 5 の ip 固定/解除

# 概要
Raspberry Pi 5 (Raspberry Pi OS 12.7)
で `NetworkManager（nmcli）` を用いて ip 固定 / 解除を行う
今回 `Wired connection 1` を対象として行う

## 状態確認
``` shell
$ sudo nmcli con show
NAME                UUID      TYPE      DEVICE
Wired connection 1  hogehoge  ethernet  eth0
...
```

## 変更の適用
```
$ sudo nmcli con down "Wired connection 1"
$ sudo nmcli con up "Wired connection 1"
```

## 固定（192.168.10.21/24 に固定）
```
$ sudo nmcli con modify "Wired connection 1" ipv4.method manual ipv4.address 192.168.10.21/24 ipv4.gateway 192.168.10.1 ipv4.dns 8.8.8.8
```

## 固定解除
```
$ sudo nmcli con modify "Wired connection 1" ipv4.method auto
```
z/OSMF workflow実施後のdeleteについて

z/OSMFのワークフローを実施後、completedしても、削除しない限り残ってしまいます。
確かに1system上限workflowのinstanceが200個しか存在できませんので、(z/OS v3.1マニュアルにより)
特に問題なく実行完了のworkflowは基本削除という運用になるのかと思います。

その削除の仕方として、筆者が調べた限り、2つのパターンがありそうです。
1. 実行後の削除(原始的なやり方)
2. ワークフロー生成時に実行完了したら削除するのをチェックした上で生成

その2パターンで、
またz/OSMFのdesktopで削除の仕方、Ansible for zのIBM z/OSMF collectionで使う仕方をそれぞれ調査してみました。(序でに、提供したREST APIの書き方も見てみました)

# 実行後の削除パターン

### まずはz/OSMF desktopの場合
極普通に削除対象ワークフローをチェックして、アクションで削除するだけですが。。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/349186/4ece3621-9e34-9f94-2ba6-79bbf33821fb.png)

### REST API
[こちら](https://www.ibm.com/docs/en/zos/3.1.0?topic=services-delete-workflow)のrequestで削除できますね、
`DELETE /zosmf/workflow/rest/<version>/workflows/<workflowKey>`

### z/OSMF collectionで削除する場合
zmf_workflowモジュールを使って、stateパラメータを`deleted`に指定すればok
```
- name: Delete a workflow if it exists
  ibm.ibm_zosmf.zmf_workflow:
    state: "deleted"
    zmf_credential: "{{ result_auth }}"
    workflow_name: "ansible_sample_workflow_SY1"
```
z/OSMF collectionはwokflowkeyではなく、workflownameで指定するだけでも削除してくれます。
↓ドキュメントもこう書いていましたが、コードを見ると、一回nameでlistして該当するworkflowkeyを抽出しているっぽいです。詳細はご自身でコードを確認してもらえばわかるかと思います
```
   Delete the workflow instance specified by workflow_key.
    If workflow_key is not supplied, delete the workflow instance specified by
    workflow_name.
    Return the message to indicate whether the workflow instance does not exist
    or is deleted.
    Return the workflow_key of the deleted workflow instance.
    Return the workflow_name of the deleted workflow instance.

    :param AnsibleModule module: the ansible module
```
まあ、z/OSMF collectionも結局REST APIを発行しているからですね。



# ワークフロー生成時に実行完了したら削除するのをチェックした上で生成

### z/OSMF desktopの場合
workflow instanceを生成するときに、下のDelete workflow on completionすれば、
実行完了のものは勝手に自動削除されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/349186/293c4819-5507-72ee-f8fb-1b0f561af968.png)

### REST API
[マニュアル](https://www.ibm.com/docs/en/zos/3.1.0?topic=services-create-workflow)でこのsampleで提供していまして、requestにこの`autoDeleteOnCompletion`optionを`true`にすればdesktopのチェックボックスと同じ効果
```
POST /zosmf/workflow/rest/1.0/workflows HTTP/1.1
Host: zosmf1.yourco.com
Connection: close
Content-Type: application/json
Content-Length: 203
Authorization: Basic em9zbWZhZDp6b3NtZmFk

{
    "workflowName":"AutomationExample",
    "workflowDefinitionFile":"/usr/lpp/zosmf/samples/workflow_sample_automation.xml",
    "system":"SY1",
    "owner":"zosmfad",
    "assignToOwner" :true,
    "accessType": "Restricted",
    "deleteCompletedJobs" : true
    "autoDeleteOnCompletion" : true 
}
```

### z/OSMF collectionで削除する場合
マニュアルで調べた限り、、特にこのやり方がなく、どしてだろう疑問？
ちょっく調べてみたが、[v2.3のマニュアル](https://www.ibm.com/docs/en/zos/2.3.0?topic=services-create-workflow)では`autoDeleteOnCompletion`optionがありませんでした。
changesも見てみましたが、どのサービスレベルで追加された機能が分からず、、この機能を使うときは要注意かもですね。。
Androidエミュレータ内のCouchbaseデータファイルをローカルにコピーする

# はじめに
自分用メモですが、備忘録として残します。

アプリ自体はNativeScript+Angularで開発、[`@triniwiz/nativescript-couchbase`](https://www.npmjs.com/package/@triniwiz/nativescript-couchbase)を使用しています。


# 取得するファイルのパスを確認する
- 下記コマンドでEmulatorのShellにアクセスする。
```
adb shell
```

- アプリのデータディレクトリに移動する。`com.yourapp.package`にはアプリのパッケージ名を指定する。
```
cd /data/data/com.yourapp.package/databases/
```

- Couchbaseのデータファイル（`.cblite2` や `.sqlite` など）があるか確認する。
```
ls -l
```

- 今回の自分の環境では下記にディレクトリが格納されていた。
	- `/data/data/com.yourapp.package/files/sample-couch.cblite2`

`cd`や`ls -l`実行で`Permission denied`エラーになる場合は、アクセス権限を取得する。
```
run-as com.yourapp.package
```

# adbコマンドを使用しファイルをローカルにコピーする
## ファイルをローカル環境へコピーする
```
adb shell 'run-as com.yourapp.package cat /data/data/com.yourapp.package/files/sample.db > /sdcard/sample.db' && adb pull /sdcard/sample.db ./sample.db
```
## ディレクトリをローカル環境へコピーする
```
adb exec-out run-as com.yourapp.package tar -cf - -C /data/data/com.yourapp.package/files sample-couch.cblite2 > sample-couch.tar
tar -xf sample-couch.tar
```
### コマンドの詳細
- `run-as com.yourapp.package`：アクセス権限を取得
- `tar -cf -` で標準出力 (`stdout`) に圧縮データを送る
- `adb exec-out`でそれをローカルの`sample-couch.tar`にリダイレクトする
- `tar -xf sample-couch.tar`で解凍する
- これにより、`sample-couch.cblite2`ディレクトリがローカルに復元されます。

`~/Downloads`にコピーする場合は以下コマンドを実行。

```
adb exec-out run-as com.yourapp.package tar -cf - -C /data/data/com.yourapp.package/files sample-couch.cblite2 > ~/Downloads/sample-couch.tar
tar -xf ~/Downloads/sample-couch.tar -C ~/Downloads/
```

# おまけ
## エクスポート処理を追加し、Jsonファイルをエクスポートして取得する方法もある
プロジェクトに下記の処理を追加する。

下記例はNativescriptのclassに処理を追加する想定。
```sample.ts
import { Injectable } from '@angular/core';
import { Couchbase } from 'nativescript-couchbase-plugin';
// import { CouchBase } from '@triniwiz/nativescript-couchbase';
import { ApplicationSettings, knownFolders } from '@nativescript/core';
export class CounchbaseModule {
	database = new Couchbase('sample-couch');
	  exportData() {
	    const documents = this.database.query(); // 全データを取得
	    const folder = knownFolders.documents(); // `/data/user/0/{package_name}/files/`
	    const file = folder.getFile("exported_sample-couch.json");
	
	    file.writeText(JSON.stringify(documents))
	        .then(() => console.log("Data exported successfully!"))
	        .catch((err) => console.error("Export failed", err));
	}
}
```

格納した階層から、`add pull`などで取得する。


## `xxx.db`からデータをファイルへ出力する

```
sqlite3 sample-couch.cblite2/db.sqlite3 \
"SELECT id, name, mail, order_no  FROM user;" > output.txt
```
[macOS] VSCodeがアップデートできていなかった件

# 現象

手動で更新をかけると右下に以下のエラーが出ていました。

Cannot update while running on a read-only volume. The application is on a read-only volume. Please move the application and try again. If you're on macOS Sierra or later, you'll need to move the application out of the Downloads directory. This might mean the application was put on quarantine by macOS. See this link for more information.

# 確認したこと

ダウンロードフォルダにあると更新ができないという情報があったので、ダウンロードフォルダを確認したが Visual Studio Code.app はアプリケーションフォルダに正しく存在していた。

# 試したこと

エラーメッセージ中に以下のリンクが記載されていたので

https://github.com/microsoft/vscode/issues/7426#issuecomment-425093469

サイトに記載されていたコマンドを実行して所有者や属性変更など実施したが改善せず。

```
sudo chown $USER ~/Library/Caches/com.microsoft.VSCode.ShipIt/*
xattr -dr com.apple.quarantine /Applications/Visual\ Studio\ Code.app
```

# 解決できた方法

入れ直してみました。
ネットからダウンロードしたものをインストールしていたのですが、homebrew で入れてみます。
homebrew が予め入っている前提です。

## アンインストール

ファインダーからアプリケーションの中にある Visual Studio Code.app を右クリックし、[ゴミ箱に入れる]を実行。

## インストール

```
先に homebrew 自身をアップデートします
brew upgrade

VSCodeのインストールをします
brew install visual-studio-code
```

コマンドで起動
```
code
```

バージョンを確認して新しくなっていることを確認しました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83224/0247d9a4-4bdf-dbe4-e21b-27a09c149787.png)
like vanity links、 slugsとは

### slugs
>スラグは、通常は URL の最後にある Web アドレスの固有の識別部分です。 

https://developer.mozilla.org/ja/docs/Glossary/Slug#:~:text=%E3%82%B9%E3%83%A9%E3%82%B0%E3%81%AF%E3%80%81%E9%80%9A%E5%B8%B8%E3%81%AF%20URL%20%E3%81%AE%E6%9C%80%E5%BE%8C%E3%81%AB%E3%81%82%E3%82%8B%20Web%20%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%AE%E5%9B%BA%E6%9C%89%E3%81%AE%E8%AD%98%E5%88%A5%E9%83%A8%E5%88%86%E3%81%A7%E3%81%99%E3%80%82

>`『https://www.cocoe.co.jp/about』`
>上記のURLの末尾にある『about』がslugにあたります。

https://www.cocoe.co.jp/post/marketing_slug/#:~:text=%E3%80%8Ehttps%3A//www.cocoe,%E3%81%8Cslug%E3%81%AB%E3%81%82%E3%81%9F%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82

### like vanity links
>バニティURLは、マーケティング目的でブランド化され、ユーザーがWebサイトを覚えて見つけやすいようにカスタマイズされた一意のWebアドレスです。

https://docs.oracle.com/ja-jp/iaas/analytics-cloud/doc/vanity-urls.html#:~:text=%E3%83%90%E3%83%8B%E3%83%86%E3%82%A3URL%E3%81%AF%E3%80%81%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E7%9B%AE%E7%9A%84%E3%81%A7%E3%83%96%E3%83%A9%E3%83%B3%E3%83%89%E5%8C%96%E3%81%95%E3%82%8C%E3%80%81%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%81%8CWeb%E3%82%B5%E3%82%A4%E3%83%88%E3%82%92%E8%A6%9A%E3%81%88%E3%81%A6%E8%A6%8B%E3%81%A4%E3%81%91%E3%82%84%E3%81%99%E3%81%84%E3%82%88%E3%81%86%E3%81%AB%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA%E3%81%95%E3%82%8C%E3%81%9F%E4%B8%80%E6%84%8F%E3%81%AEWeb%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%A7%E3%81%99%E3%80%82
データが重くてGitHubにpushできない時の対処法

# GitHubでの大きなファイルのpushエラーを解決する方法

## 何が起こったのか
単純にGitHubへのpushする時の容量が重すぎて拒否されたという体験をしたので何とか対処できないかAIやサイトを見てやっていった結果をここに記していきました。

## 問題の背景

GitHubでは、100MBを超えるファイルは通常のGitで扱えず、pushが拒否されます。この際、以下のようなエラーが発生します：

```
remote: error: File <filename> is <size>; this exceeds GitHub's file size limit of 100.00 MB
remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
! [remote rejected]   main -> main (pre-receive hook declined)
```

このエラーを解決するには、**Git LFS（Large File Storage）**を利用し、大きなファイルをGitHubの制限に合った形で管理する必要があります。

しかし、既存のリポジトリに大きなファイルが含まれている場合、そのファイルを過去の履歴から削除しなければpushできません。この解決方法として、**BFG Repo-Cleaner**を利用します。

## 解決方法のステップ

### 1. Git LFSのインストールと設定

まず、Git LFSをインストールし、有効化します。

#### Git LFSのインストール

- Mac:
  ```bash
  brew install git-lfs
  ```

- Windows:
  [Git LFS公式サイト](https://git-lfs.github.com/)からインストーラーをダウンロードし、インストールします。

- Linux:
  ```bash
  sudo apt install git-lfs
  ```

#### Git LFSの有効化

リポジトリでGit LFSを有効化します。

```bash
git lfs install
```

これにより、Git LFSがリポジトリ内で使用可能になります。

---

### 2. BFG Repo-Cleanerのインストール

BFG Repo-Cleanerは、Gitリポジトリの履歴をクリーンアップするツールです。

#### インストール方法

1. [BFG Repo-CleanerのGitHubリポジトリ](https://rtyley.github.io/bfg-repo-cleaner/)にアクセスします。
2. 最新版の `.jar` ファイルをダウンロードします。
   - 例: `bfg-1.14.0.jar`
3. ダウンロードしたファイルを任意のフォルダに保存します。

#### 必要条件
BFGはJavaで動作します。以下のコマンドでJavaがインストールされていることを確認してください。

```bash
java -version
```

Javaがインストールされていない場合は、[Javaの公式サイト](https://www.oracle.com/java/)からJDKをインストールしてください。

---

### 3. 大きなファイルをリポジトリ履歴から削除

BFGを使って、大きなファイルをリポジトリ履歴から削除します。

#### コマンドの実行

以下のコマンドを使用します。`<path/to/bfg.jar>` をBFGの実際の保存場所に置き換えてください。

```bash
java -jar <path/to/bfg.jar> --delete-files "<filename>"
```

例: 特定の大きなファイル `large_file.pyd` を削除する場合：

```bash
java -jar C:\tools\bfg.jar --delete-files "large_file.pyd"
```

---

### 4. Gitの履歴を整理

BFG実行後、以下のコマンドで不要なオブジェクトをクリーンアップします。

```bash
git reflog expire --expire=now --all
git gc --prune=now --aggressive
```

これにより、リポジトリのサイズが縮小し、不要な履歴が削除されます。

---

### 5. Git LFSで大きなファイルを再追跡

大きなファイルをGit LFSで追跡し直します。

```bash
git lfs track "<filename>"
git add .gitattributes
git add "<filename>"
git commit -m "Track large file with Git LFS"
```

---

### 6. リモートにpush

BFGで履歴を修正したリポジトリは、リモートリポジトリと異なる状態になります。そのため、`--force` オプションを使って強制的にpushします。

```bash
git push origin main --force
```

その後、Git LFSで再追跡したファイルをリモートに追加します。

```bash
git push origin main
```

---

## 注意点

- **BFGの利用は不可逆的です**：変更後は元の履歴に戻せないため、実行前にバックアップを取っておくことを強くお勧めします。
- BFG実行後は、他のコラボレーターにもリポジトリを再クローンしてもらう必要があります。

---

## まとめ

GitHubでのファイルサイズ制限を回避するには、Git LFSとBFG Repo-Cleanerを組み合わせて使用するのが効果的です。大きなファイルを含む履歴を削除し、LFSで正しく管理することで、リポジトリをクリーンで使いやすく保つことができます。

これで、GitHubのサイズ制限エラーに悩まされることなく作業を進められるはずです！
React エラーへの対応方法

# 1. エラーメッセージを確認する

React アプリでエラーが発生した場合、まず最初にブラウザのコンソール（F12 を押して DevTools を開く）でエラーメッセージを確認しましょう。エラーメッセージには、問題の原因や発生箇所のヒントが含まれています。

# 2. よくあるエラーとその対処方法

(1) Module not found エラー

原因: 必要なモジュールがインストールされていない、または import 文のパスが間違っている。
対応方法:

npm install または yarn install で依存関係を再インストールする。

import 文のパスが正しいか確認する。

package.json に該当モジュールが記載されているか確認する。

コード例:
```Typescript
import MyComponent from './MyComponent'; // パスが正しいか確認
```
(2) Cannot read properties of undefined エラー

原因: オブジェクトが undefined の状態でプロパティにアクセスしようとしている。
対応方法:

データが非同期で取得される場合、? オペレーター（オプショナルチェーン）を使用する。

if 文で undefined チェックを追加する。

useEffect フックを使用してデータの取得タイミングを適切に調整する。

コード例:
```Typescript
const user = data?.user; // オプショナルチェーンを使用
```
(3) Invalid Hook Call エラー

原因: フックが誤った場所で使用されている（例: クラスコンポーネント内で useState を使用した）。
対応方法:

フックは関数コンポーネントまたはカスタムフック内でのみ使用する。

React のバージョンが正しいか確認する。

コード例:
```Typescript
function MyComponent() {
  const [count, setCount] = useState(0); // フックは関数コンポーネント内で使用
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}
```

(4) Unhandled Promise Rejection エラー

原因: async/await でエラーハンドリングを行っていない。
対応方法:

try/catch ブロックを使用してエラーをキャッチする。

catch メソッドを使用して .then() チェーン内でエラーハンドリングを行う。

コード例:
```Typescript
async function fetchData() {
  try {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json();
    console.log(data);
  } catch (error) {
    console.error('Error fetching data:', error);
  }
}
```
# 3. デバッガーと React Developer Tools を活用する

(1) デバッガーの活用

debugger; ステートメントをコードに追加することで、ブラウザの DevTools でブレークポイントを設定できます。

Chrome DevTools を使用して JavaScript のステップ実行を行い、変数の値を確認しましょう。

コード例:
```Typescript
function testFunction() {
  let value = 10;
  debugger; // ここでコードの実行が一時停止
  console.log(value);
}
```

(2) React Developer Tools の活用

React Developer Tools を Chrome または Firefox にインストールすると、React コンポーネントの状態やプロパティを直接確認できます。

Components タブでは、各コンポーネントの props や state の値をリアルタイムで変更してデバッグできます。

Profiler タブを使うと、レンダリングのパフォーマンスを分析し、最適化のポイントを特定できます。

# 4. エラーを防ぐためのベストプラクティス

型チェックを活用する

TypeScript を使用することで、未定義の変数や型エラーを事前に防ぐことができる。

エラーハンドリングを組み込む

try/catch を適切に使用し、エラーメッセージをユーザーに分かりやすく表示する。

エラーバウンダリーを活用する

componentDidCatch を使ってエラーハンドリングを行う。

ErrorBoundary コンポーネントを作成して、アプリがクラッシュしないようにする。

コード例:
```Typescript
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    console.error('Error caught:', error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      return <h1>Something went wrong.</h1>;
    }
    return this.props.children;
  }
}
```

# 5. まとめ

React のエラーは、適切なエラーメッセージの確認と、正しいエラーハンドリングの実装によって解決できます。特に、非同期処理のエラーやフックの使い方には注意し、TypeScript やエラーバウンダリーを活用することで、より安全なアプリ開発が可能になります。また、デバッガーや React Developer Tools を活用すると、より効果的にエラーを特定し、迅速に修正できます。